It was strange, mine was on a standalone RPI3 and it was fine until I added my 30+ Hue bulbs. Then it kept hanging every few days. I tried wifi, hard wired, but still every 2-3 days it hung. In the end my ‘dirty’ solution was to have a smart plug on the RPI and when it went unavailable I had a Node Red automation that rebooted the Pi.
Since moving to a VM it has been flawless.
Anyone got the Sonoff Basic ZBR3 (motion sensor) working? I have received to of them, but they just refuse to pair. They do show up in Phoscon VNC and are linked to one of my Zigbee lights. But Phoscon never says that a new component has been added and also no entries in HA.
The official deCONZ Github says ‘added initial support’. Does this mean, it’s detectable but doesn’t work yet and a newer update will properly support it? Or am I just having bad luck?
Running Home Assistant 0.114.4 (Hassio) on RPI 4 with latest deCONZ add-on and Conbee II with latest firmware.
The deconz addon always uses the stable deconz release. Since the latest stable was in mid May, the support for the new Sonoff won’t make it into the addon until we see another stable release from Deconz.
Edit: Looks like the addon is running 2.05.79 at the time of writing which is a beta release.
That’s pretty confusing then since the add-on itself clearly states this at the changelog with 6.0 update: * Bump deCONZ to 2.05.79. Your link says it in may they updated to 2.05.76.
Apologies! You are correct.
I will edit my comment.
Please see this PR. The addon hasn’t yet been updated to the newest deCONZ version because there are issues with that release.
Thanks, this clears it up! I’ll just wait for the stable to hit then. Pretty sure it’ll work as advertised then 
All my instability problems solved…by putting the Conbee II on a USB 2.0 port. It needs to be written somewhere explicitly, stickied and in large font that you should never plug a Conbee stick into a USB 3.0 port or hub.
I’ve been running into a few issues lately with Deconz. The first one started I guess about the time I added a few more Trådfri bulbs to my system, but it could be caused by something else as well. I think I have now 23 lights, most are Trådfri but a few Philips hue bulbs as well. Added probably like 5 to 8 bulbs a few weeks ago. The issue is that when I’m applying scenes via automations, some lights are not going to the correct state (brightness or color temperature). Sometimes the bulbs even remain turned on at low brightness, even though Home Assistant and Deconz both report the bulb as off. Weird.
Okay, so the second issue is that after updating the Deconz add-on and ConBee II stick firmware, when applying scenes I get this error: “failed to call service scene/turn_on. /lights/20/state parameter, xy, not available”. I’ve read somewhere that the color_temp variables (and Kelvin) would not be supported anymore, hence I have been using the xy-values for a long time now, but with the latest updates I started getting this issue that xy would not be available. Otherwise the automations etc. work fine, but the color temps are causing issues. Hue bulbs seem to work fine with xy, but Trådfri does not. I tried to comment out the xy definitions but I still get the same error message after refreshing my automations! Maybe I’m missing out something. Actually, maybe I forgot to restart home assistant after commenting those out as they are in scenes and not automations, haha. In any case, I think the Ikea’s should support the XY color definition or what should I use? They are not RGB so probably not that one either.
Edit: another idea I got would be to give up on scenes and change those to scripts, but I think scenes would be tidier.
The problem with scenes and groups in Home Assistant (and any other hub) is that it will always have to send the messages to each lightbulb one by one. That goes well with a few. But if you try to change many at once, the zigbee channel gets flooded and messages lost or discarded.
There are two ways to avoid this.
Either run your scenes in smaller chunks with fewer lights with a few seconds between. Or define groups in the Zigbee hub
It is easy in deconz. You simple define a group in the Phoscon app and reload devices or restart HA. The groups show up as lights in HA. And then you add this group to the scene. What happens is that HA sends ONE message to Deconz to turn on the light group. And Deconz then sends ONE zigbee message to the light group. No flooding. Much more reliable. It fits well with the trouble starting when you added more bulbs.
The Conbee can easily handle up to 200 devices. I have 101 now. Just avoid talking to all of them one at a time at once
I can confirm this. Months before, when Hassio provided the scenes first, I moved all the scenes of the light groups to hassio and configured them there. The result: most of the scenes didn’t work reliable. Nearly every time some bulbs weren’t switched.
Then I read this behavior described by you Kenneth everywhere in another thread or maybe here month ago .
I moved back all my scenes to deconz and everything is ok again.
Now, I have only a few scenes managed by HA in order to play around. All others are managed by deconz and are rock solid.
Another point to mention is, that some bulbs have obviously less memory then others. In the livingroom I have around 10 different scenes. The hue lights can handle them. But tint bulbs i.e. can only handle 5 scenes. That could lead to confusion as well.
Actually this is not specific to HA, zll group messaging. It’s because deconz doesn’t open it up for HA to use. Or it is and HA isn’t using it. There are other hubs out there who use the zll group messaging. Hue bridge has also incorporated it in the api, though HA doesn’t use it.
Ha uses both zigbee groups and scenes from Deconz so it can very well use those mechanisms. Just not through hole assistant specified groups or scenes
You mean only on a scene or group made in phoscon? If that is the case then it’s not implemented in my opinion. Phoscon will make the zll group message and not HA if you ask me. I think it should work also on lightgroups in HA and in scenes. But also my opinion.
How would that be possible? A light group in HA could also include lights which are not available in deconz.
Thanks for the input! It makes sense and I will definitely try that next. I don’t see any drawback of managing the groups and perhaps also scenes on Deconz side so should be a nice solution. Hopefully it will also fix the issue with the xy_color definition/error.
While troubleshooting, I realized that I have quite old firmware versions on my Trådfri bulbs. I’ve been trying this before and now again, but I am unable to update the firmware through Deconz. I see that all of the recent firmware files show up in the VNC user interface (which is nicely now embedded in the HA add-on) so there shouldn’t be a need to separately transfer the firmware files I think. I thought I managed to do the updates yesterday by individually clicking first query (state went to show idle) and then update and after few seconds the percentages started rolling. However, after the update is complete and it states “done” the bulb still shows the old version number on the VNC and on Phoscon. I also read somewhere that this upgrade process should be automatic after a power cycle of bulbs, but I’ve had the bulbs for a while now and there’s been many power cycles so it does not seem to work. I checked the old Phoscon UI and confirmed that the OTAU server checkmark is ticked. Any ideas? Could I try the update if I plugged the Conbee stick into a Windows PC and try the same from there?
Edit: changed HA light groups to Deconz light groups and did a HA restart. Everything seems to work much faster now and I do not get that xy-error anymore. Definitely looks like this solved my original issues. Still curious about the Deconz Trådfri update process though.
Sorry, that is not for me to figure out. My former hub (which I had different problem with), Hubitat, could do it. So it is possible, in whatever way.
With deconz? I don’t think so
OK, I think I just figured out my Trådfri update issue. The bulbs are actually updated correctly, but it is just super confusing that even though Ikea seems to sell two variety of GU10 bulbs: one are full white spectrum and the other one with only dimmable yellow color temp. But checking the image codes in Deconz it actually shows that some of my bulbs are 0x4204 and others 0x4103, even though both types are full white spectrum. I think the other ones are the ones that came bundled with the GU10 3x set (incl. controller) and the others are sold separately. Technically I think they have the same specs but just a different build. Maybe it’s done like that because the set comes pre-paired to the controller. The version numbers are completely different though, so not sure if the other ones are just not updated by Ikea or if they just go on different version number tracks. Both files seem to be recent, so should be good. Weirdly enough the 0x4103 image code seems to be the image also on E27 type of bulbs.
