Release pimatic-raspbee@0.1.6

---

Yes I’m with you and I fear unless the ‘stop’ button from the gui isn’t able to toggle ‘stop’ on the device, all our effort here is for nothing …

Having it only working with 3 commands (open/stop/close) would be sufficient, as then statuses somewhere in between could simply be reached by counting the respective seconds, as I do it already with the 433Mhz shutters. But there the RF-signals are too unreliable … which would be completely other by using ZigBee.

Well, not to drive us nuts here. I already ordered another (in wall) ZigBee shutter switch at AliExpress, which hopefully will arrive end of the month and may work more smoothly. We might continue the testing with this one, what do you think?
… another possibility could also be, that I simply send you my current device via post. Having it here w/o working it will become waste at some point of time …

And if that also will not work, I will set up an MQTT-Server in my summer holidays, anyhow staying at home with that COVID thing, and then do it via WLAN switches, which I already thought about end of last year. More effort to set it up, as I never worked with it before, but I guess an already more solide proved terrain, with tonnes of tutorials …

Is the new one you ordered a different and supported cover device?

It is a different one and as it was not that expensive I just ordered it without checking - in terms of let’s give it a try …
But I will check now on GitHub, as on the official DresdenElektronik page, all the latest adoptions are often not shown …

It’s this one:
https://de.aliexpress.com/item/1005001667151359.html?spm=a2g0s.9042311.0.0.1c0f4c4dFGX0h8

As mentioned earlier, I currently also have another new device on hand here, which is a Heiman siren.
This is already listet on the GitHub list, as I checked this upfront, because of the price of >30€.

I was already able to bind it to deconz / phoscon, but couldn’t test it really further more in Pimatic, as that is not possible in the evenings in a house of 5 …
What I already learned was, that it doesn’t work exactly as a lamp, as the ‘integrators’ in the rest api would have to prevent, that it switches on, when someone is swichting on all the lights.

I just found it:
It is listed here, in the sensor’s area:
https://github.com/dresden-elektronik/deconz-rest-plugin/wiki/Supported-Devices#lights

And below the spreadsheet is noted:
The Heiman Siren is exposed as a light for controlling the siren, and as a ZHAAlarm sensor.

Yes, thats a different device and i hope it will be supported.
To be practical we can wait for that device to arrive and then take another shot at this.

An alternatieve for your current shutter device, could be using shell-execute-buttons.
Per cover command (up,stop,down) your configure a ‘curl put command’.
The advantage is you control the data that is send, and thats easier to debug and customize.

I’ve seen the way a siren can be integrated.
How should the siren work?

shell-exec-buttons might be an idea, I’m already using some to steer the motioneye …
But this goes via the normal network. How shall I send commands via the ConBee to the shutter-switch? - I will spend some research on this …

I already have set up some sensors across the entire house (doors, windows, movement, …) which currently, if alarm is ‘sharp’, toggles a simple Hue plug, with a larger piezo device plugged in.
But this setup currently sometimes has the tic, to just switch on somewhere over the day or night. It’s only for a second, but you may assume, that this always causes some kind of … 'hey father, whats going on here with all that stuff …?"

I have now the hope, that the siren doesn’t have this tic …

Ok, let’s close for today, the night is getting short…

I fear I will be earliest here again Sunday evening, as today some other work has been delivered by the logistics …

And thanks a lot for your effort again! That is great to have such a kind of collaboration here!

CU

No, you sending on your lan the command to de Deconz api.

There are posts on the forum on this, but to give you an idea

curl -X PUT http://<ip deconz>:<port deconz>/api/<api key>/lights/<deconz device ID>/state -d '{"on":true}' -s

This is an example to switch on light with id '4’
The {“on”:true} is the JSON you can play with

For the 3 cover commands the commandlines are

open

curl -X PUT http://<ip deconz>:<port deconz>/api/<api key>/lights/<Cover deconz device ID>/state -d '{"lift":0}' -s

close

curl -X PUT http://<ip deconz>:<port deconz>/api/<api key>/lights/<Cover deconz device ID>/state -d '{"lift":100}' -s

stop

curl -X PUT http://<ip deconz>:<port deconz>/api/<api key>/lights/<Cover deconz device ID>/state -d '{"lift":50}' -s

You need to replace the 4 <…> values with your data.

🤩, thanks a lot!
That really seems to be easy, never hat a look at it before.
Thus I assume, that steering my siren would work similar…

Yes, you can control the siren with these type of command.

The reason for using a plugin is that you can use bidirectional websockets instead of http requests with polling. For getting status and states updates websockets are better. And with a plugin you are integrated in the framework (rules, gui, etc)

Let me know what command lines worked for the cover.

… well I guess this device will drive me crazy …

Having it first set up with your curl commands all went well, besides the fact, that the device cannot be triggered to ‘stop’, but only to ‘close’.

I thought, let’s check the values in the deconz-gui, maybe there anything can be read.
Opened it and switched a bit here and there an saw the value for lift also changing. Interesting was especially, that sometimes it went to 255 (beside 0, 50, 100).
However suddenly the device lost the contact to the conbee stick. I added it the by the phoscon app from the raspi, which can be opened directly from a button in the deconz-gui. And there the mess started …

Afterwards, although having it binded newly 2 times, reconfigured it pimatic checked everything 20 times, the curl commands didn’t work any longer. Also the device we configured the last days wasn’t any longer able to trigger anything on the device. Wondering is, that when triggering the buttons on the device, this is shown in the pimatic device.

As said, that drives me nuts. I will stop for today and maybe reinstall the entire plugins (raspbee and shell) newly ón sunday evening …

… please and don‘t get me wrong, that is all about my own frustration 😉
Nothing at all meant again anyone here 🙃

Some thoughts on your zigbee mess/mesh.
Once a device is added to the zigbee network, you don’t need to add it again.
Before pairing (again) I always reset the device fully (so its removed from the zigbee network).
It can be that a device is disconnecting (battery low or something else) but eventually it will become online again (if battery is ok and the device is reachable)
If you use zigbee lights and powered wall outlet. They also function as zigbee repeaters.
That will extend the network reach.

When a device is added again, it can get a different id. In that case the device in pimatic-raspbee and the curl commands need to be updated. The best way to check/update this, to do a device discover again in Pimatic.

I’m afraid reinstalling raspbee and shell isn’t helping (unless pimatic is broken).
And there’s also a possibility that the zigbee part of the shutter device is broken / defect.

Hi @bertreb,
thanks for all the knowledge around ZigBee. The point at that evening was, that I know about all these facts already, but nevertheless ran into that issues.
The annoying fact with that shutter switch is, that there was no description at ll in it’s package how e. g. to reset completely. I only found out by try end error, how it can be connected to the deConz.
I will do some additional tests this evening …, maybe also with the siren, by putting it into a blanket not to drive the hole family crazy
… I’m also aware of the ID theme within the devices and alreay read it newly into Pimatic, that was why I was thinking about to re-install the raspbee plugin

👍
Good luck with the siren and if you find working commands for the shutter, let me know and i will update the plugin.
You could also try other parameters, like ‘bri’ and ‘on’

Yeah I’ve got it!!!

1. I reset the device via the deConz-Gui to it’s factory config, then joined it newly via Phoscon and got it back also in Pimatic. I have no clue what went wrong last time, but the reset was the key (luckily have found the button for that)

2. According to what I found here: https://github.com/dresden-elektronik/deconz-rest-plugin/issues/3063, written by ebaauw, I was able to set the device via “stop” true, dedicatetly on ‘stop’. The curl command looks like this:

curl -X PUT http://127.0.0.1:8080/api/6C0DB236A2/lights/2/state -d '{"stop":true}' -s

3. I played a bit around with the value by sending a ‘lift’ with the curl command. I would have awaited, the using a low value, 10-20, would trigger e. g. the ‘open’ button for a short time and then automatically would switch back to ‘stop’, but that doesn’t happen. The ‘reset’ to stop takes always the same time.

Out of 2+3 I would assume that the follwoing changes in the raspbee cover device would have be to implemented:

1. ability to send a “stop”, true, when the ‘stop’ button of the raspbee device is pressed
2. if a position with the slider is choosen, in reference to the last known position and according to the new position, ‘open/close’ has to be triggered and then, according to the totally choosen movement time in the config, at a point of time “stop” true has to be send, but the problem I see here is that:
   • the related calculation might not be that easy, and/or
   • ,and I fear this is a larger problem, if due to whatever reasons the last known position might have gone lost, the shutter, resp. the corresponding slider position, will become completely de-adjusted.

Follwoing the last thoughts in 2., I ask myself if it is really meaningful to do this by calculation. I feer such a thing will only work propperly, if the shutter would send back his precise position activly to be then able to steer correctly on such basis. A workaround in such a situation could maybe a kind of reset function: e. g. move the shutter down for ~30sec. and position the slider to 0%…, or that might happen anyhow each time the shutter moves to completely close… (=0% open)
(maybe that is the reason why vendors often produce ZigBee shutters directly incl. the curtain and solo ZigBee devices are on the market a realtively short time only)

3. Following out of that, maybe it is easier, only to use now a more reliable RF technology by ZigBee, but steer the device itself as also currently done (the 433Mhz), by counting seconds …

What do you think?

Something in addition what I noticed in my/your current version:
Open and close are currently mixed and the range of the slider is from 5-95% and not from 0-100%.

Good news that the shutter is working like you would expect.
In the earlier versions of the plugin i used the stop command, but that wasn’t working at that time.
If the shutter rollingtime is accurate, then lift/position can be used. The best way to keep synchronised is when the shutters now and then fully opens or closes. That was also the mechanism I had implemented in the earlier versions (thats why I asked about the end/begin stop of the shutter motor).
So I can reenable those functions.

I don’t understand the mixed and 5-95% issue?