@MadMonkey . I just updated my ConBee II stick and had to restart the deCONZ docker container. This resulted in a lot of devices showing a red triangle with the error websocket down. Most of these eventually recover but not my light groups. Because of this I can not control this group from Homey anymore. But when controlling them through Phoscon I can see the status being updated in Homey. So it seems to me there is a bug in your deCONZ app where it does not recover the group from a temporary disconnection and the group remains unavailable even though the connection has been restored. Want me to submit an issue on GitHub for this?
Hey @Jeff1
Currently there is only a generic plug driver which should work but does not support measure_power or meter_power. If the device is however properly supported in deconz I am glad to provide support for that device, please create an issue in my github repo (please include the json of the light and the sensor resource).
Hey @Phuturist
Yes it should recover automatically, either if the device pushes an updated state or using the internal scheduler. Have you tried to restart the app?
Yes I did. I eventually forked your repo and added this.setAvailable() in the group driver device.js to have the group enabled again. This saved me re-pairing the group and rebuilding my flows.
I have an idea where the problem could be, in fact it is all about the fact that a group isn’reported as unreachable by deconz (which makes sense). I have a look at it an provide a fix, but it might take some days as I am in holidays😄
To what version? I’m currently using the following:
If i look at the site it seems to be a different version:
And I did somewhere see a .76 if I remember correctly, but cannot find it anywhere anymore.
Did find: https://deconz.dresden-elektronik.de/deconz-firmware/deCONZ_ConBeeII_0x264a0700.bin.GCF , seems like the Conbee II fw, right?
edit: It’s 27 may 2019… haha… let’s not do this version 
Right, docker image got updated to .77… so that’s a lot easier. Thanks
No problem, my workaround is fine for now. Enjoy your holidays.
I updated my ConBee stick to firmware version deCONZ_ConBeeII_0x26580700.bin.GCF .
For docker the instructions to do this can be found here: https://github.com/marthoc/docker-deconz#updating-conbeeraspbee-firmware
Yes, was just reading it, but mine does not find it. Did you put it somewhere manually?
I’m currently migrating to your version of the app @MadMonkey, nice work! One question, I noticed that the 4x press option For the Aqara button (lumi.sensor_switch.aq2) disappeared with the migration to the new button scheme.
Was there a specific reason and is it possible to add the 4 times press again?
No, it was in the directory as mentioned in the documentation. Perhaps you need to first restart the container and then look in the container logs to see if the latest firmware is retrieved (as mentioned in the docs as well).
Well, I must be doing something wrong. It keeps saying this:
root@NAS:/volume1/docker/deCONZ# docker logs deCONZ-77 | grep firmware
11:01:15:633 Device firmware version 0x264A0700
13:26:10:770 Device firmware version 0x264A0700
13:28:41:703 Device firmware version 0x264A0700
13:35:53:567 Device firmware version 0x264A0700
No matter where I put the file. So I must be missing something.
I exposed 2 folders, the data folder and /root/otau
The description mentions the following: /usr/share/deCONZ/firmware/
But this folder I don’t have.
The deCONZ firmware is part of the Docker container, so make sure that is up to date (and don’t confuse is with device firmware, which is what you place in /root/otau).
Yes, if I understand correctly there are a couple of parts.
- FW of Conbee II device which now should be the one @Phuturist mentioned and I’ve downloaded from the site.
- FW of Zigbee devices, recently updated Repeater of IKEA with FW and put that into /root/otau
- Software version of Phoscon which now should be on .77 which is a bugfix release of .76 (as why i couldn’t find it anymore).
I’m trying to do the first… according the steps on https://github.com/marthoc/docker-deconz#updating-conbeeraspbee-firmware .
Docker logs may get truncated, hence the suggestion to restart the container and look for log lines containing “firmware”. I updated mine earlier today and this is what gets logged:
deCONZ | 11:47:09:501 GW update firmware found: /usr/share/deCONZ/firmware/deCONZ_Rpi_0x26350500.bin.GCF
deCONZ | 11:47:09:501 GW firmware version: 0x26330500
deCONZ | 11:47:09:501 GW firmware version shall be updated to: 0x26350500
(for a ConBee I)
Yup, did the reboot 4 times, those lines I posed are the 4 boots of the container. All of which i tried putitng the FW in a other folder /root/otau, creating the folder structure as mentioned in the manual and olso just another reboot…
I don’t understand:
-
/root/otauhas nothing to do with this - there is no folder structure to create; the folder
/usr/share/deCONZ/firmware/is part of the container image, you don’t need to create it (or use a volume for it) - as shown, there should be more lines matching
firmware
Try docker restart deCONZ-77 followed by docker logs -f deCONZ-77 | grep firmware
Yes, I understand all of above.
Doing the command shows the exact same result als a couple of posts above:
root@NAS:/volume1/docker/deCONZ# docker logs -f deCONZ-77 | grep firmware
11:01:15:633 Device firmware version 0x264A0700
13:26:10:770 Device firmware version 0x264A0700
13:28:41:703 Device firmware version 0x264A0700
13:35:53:567 Device firmware version 0x264A0700
Thats why I don’t get it.
The timestamps don’t make sense. I don’t use docker but docker-compose, and logfiles are re-created after a restart, which doesn’t seem to be the case with you (because it’s showing the same timestamps as before) or the container just isn’t being restarted (which is more likely, because the last timestamp, even if UTC, seems too old).
Now updating with my Windows machine, that works, thanks for you helpt, both!
