Release pimatic-raspbee@0.1.6

---

I checked on the 7-3 differences and made 2 small changes. You can update raspbee.coffee to check if this helps.

ok, but I guess I will have to exchange device-config-schema.coffee also back to the latest version, right?

No, because i added the extra option to select the deviceType.
device-config-schema.coffee isnt the issue

On the TS130F.
I got a physical TS0302 type of device, and the gui responds to buttons pushed on the physical device. But only after an action is completed!
The countdown/up doesn’t work, because the shutter sends the info after the action is finished

regarding TS130F, I’m aware about this behavior, but this didn’t work any longer with the old versions I pulled back from my ‘bak’-folder

regarding TS0302, now the former behavior, earlier the evening, is back: pushing/sending ‘close’ when pressing ‘stop’ in the gui

and what I meant was: Shall I use again the latetest device-config-schema.coffee, as by exchanging it also against the old version, now it’s still in usage, w/o the option to make a device-choice and also without inverting I guess?

Ok, last try for this evening, please update raspbee.coffee.

no, I’m sorry, no success. Same behavior with TS0302

I also re-activated again the last device-config-schema.coffee, which makes again the TS130F propperly working.

Let’s close for today then, maybe some new ideas will come over night

Ok, im thinking there’s another difference we don’t see.

You say: ‘regarding TS0302, now the former behavior, earlier the evening, is back: pushing/sending ‘close’ when pressing ‘stop’ in the gui’

In the debug log there should be the following lines (containing):

• ChangeStateTo stop
• ChangeActionTo { @_sendState: ‘stop’: true }
• New value send to device …
  if ok - { bri: 127 }
  if wrong - {bri: 254}

And this is for the next debug session

really my last post for today, the nights are becoming to short overall

23:11:33.546 [pimatic-raspbee] debug: ChangeStateTo stop
23:11:33.551 [pimatic-raspbee] debug: changeActionTo, @_sendState: {
23:11:33.551 [pimatic-raspbee] debug:>  "stop": true
23:11:33.551 [pimatic-raspbee] debug:>}
23:11:33.589 [pimatic-raspbee] debug: New value send to device Shutter01
23:11:33.593 [pimatic-raspbee] debug: { bri: 127 }
23:11:33.620 [pimatic-raspbee] debug: new message received
23:11:33.623 [pimatic-raspbee] debug: {
23:11:33.623 [pimatic-raspbee] debug:>  e: 'changed',
23:11:33.623 [pimatic-raspbee] debug:>  id: '2',
23:11:33.623 [pimatic-raspbee] debug:>  r: 'lights',
23:11:33.623 [pimatic-raspbee] debug:>  state: { bri: 0, lift: 0, on: false, open: true, reachable: true },
23:11:33.623 [pimatic-raspbee] debug:>  t: 'event',
23:11:33.623 [pimatic-raspbee] debug:>  uniqueid: 'ec:1b:bd:ff:fe:8f:10:92-01'
23:11:33.623 [pimatic-raspbee] debug:>}
23:11:33.625 [pimatic-raspbee] debug: Received values: {
23:11:33.625 [pimatic-raspbee] debug:>  "id": 2,
23:11:33.625 [pimatic-raspbee] debug:>  "type": "event",
23:11:33.625 [pimatic-raspbee] debug:>  "event": "changed",
23:11:33.625 [pimatic-raspbee] debug:>  "resource": "lights",
23:11:33.625 [pimatic-raspbee] debug:>  "state": {
23:11:33.625 [pimatic-raspbee] debug:>    "bri": 0,
23:11:33.625 [pimatic-raspbee] debug:>    "lift": 0,
23:11:33.625 [pimatic-raspbee] debug:>    "on": false,
23:11:33.625 [pimatic-raspbee] debug:>    "open": true,
23:11:33.625 [pimatic-raspbee] debug:>    "reachable": true
23:11:33.625 [pimatic-raspbee] debug:>  },
23:11:33.625 [pimatic-raspbee] debug:>  "uniqueid": "ec:1b:bd:ff:fe:8f:10:92-01"
23:11:33.625 [pimatic-raspbee] debug:>}
23:11:33.627 [pimatic-raspbee] debug: move From: 20, To: 0
23:11:33.628 [pimatic-raspbee] debug:  +--> transitSeconds: 4, positionStep: -5
23:11:33.640 [pimatic-raspbee] debug: updatePosition: 15
23:11:34.643 [pimatic-raspbee] debug: updatePosition: 10
23:11:35.649 [pimatic-raspbee] debug: updatePosition: 5
23:11:36.655 [pimatic-raspbee] debug: updatePosition: 0
```

Thanks that explains the problem.
When sending a stop to the shutter (bri:127) the shutter sends back bri: 0
The gui then changes to up or down (depending on invertedIn value)

When you go back to the working 7-3 version, you can check the same log and see the differences

I saw in the 7-3 version that the TS0302 commands are based on the normal api: lift, stop and open, and not on ‘bri’. That is also what you would have seen in you did the 7-3 test.
So i changed it in the newest version of raspbee.coffee

Hi @bertreb, you did it!!!

Just did a quick first test and both shutter devices seems working perfectly in both (sending) directions.
(Percentage-) Status is also propperly shown in the gui.

Super

… have to run now, will come back later here again

I just verified the results and all works propperly.

I again also connected quickly the in-wall device, which is by Phoscon discoverd as TS130F. I was wondering about that, as it earlier (2 weeks ago) also was working already on basis of the TS0302 setup.
However it seems running regardless which model one chooses in the device config. Maybe as in-wall device, w/o any buttons, it only receives and doesn’t send anything!?

Beyond this, maybe it would be great if now the implementation into a official raspbee version could start …

Thats good news.
All 2 deviceTypes are getting now the same commands for both device types.
The response is handled a bit different per deviceType.
A response can come:

• when you push one of the physical shutters buttons: up, stop or down
• at the end of the physical devices rollertime (when up or down finishes)

If you would do more testing on both devices and both deviceTypes, you can conclude what works.

I will publish pimatic-raspbee-plus the next days.
Pimatic users then can choose the current stable pimatic-raspbee or pimatic-raspbee-plus when they need also the extra devices.

That sounds good

I guess I will set then simply set up another clone of my current setup and use your new plus version.

Sure there are some minor things in the background, as ever :

• Getting some more of this devices for all shutters (one additional is still on it’s way)
• Having set up today an addtional issue (#4597) on deconz-rest-plugin on Github, to tackle problems with the adjustment of the rollertime (currently it’s 1 minute, better than too short, but adjusting it to ~30sec would be better)
• Finding a method to get the front-frame of the shutter switches smaller, to let them better fit into my electric-switch-series (they both have a glas front)
• Finding the time to exchange all the devices distributed in the entire house …

Thus thanks home automation, life never gets boring

Sounds good.
I could set the rollertime of TS130F via the phoscon app. You can’t?

It is about the TS0302, where in the deconz gui the attributes are shown as writable, but they aren’t.

For the TS130F that worked propperly via the deconz gui, but how did you do that via Phoscon? - i didn’t recognize any respective features there…?

I close for today - looking forward … bye

Sorry, i could edit a node (and calibrate) only in deconz.

Ah ok, I was already wondering

What popped up in my mind:
I guess you will set up a short docu?
If so, I could support you in terms of collecting all the device info together (Shutters, Siren and Plug) and provide it.
If that helps …

Yes, the readme needs to be extended.
The basis will be the current readme of treban/pimatic-raspbee (version 0.1.7).
If would be nice if you want to write the concept for the readme for smartplug, warning and cover. I will combine and publish it.
There are more small changes i will put in the history