I do not agree from my experience, yes the usb Zigbee dongle works good and is powerfull but Phoscon lacks support for (cheap) devices.
I bought some tuya zigbee devices (wall switches and power plugs) and they were not recognized by the software.
So I added a zigbee2mqtt instance with a zigbee donge and also they were not recognized.
I just let them be, and after 2 weeks made an update and poef it’s recognized by zigbee2mqtt!
Fully!! (switch, energy measurements, etc).
So, in my experience it’s a bit more complex to setup (no real discovery of new devices in OH3) but I think zigbee2mqtt the best supported platform.
Here’s my best tip after a lot of hassle with ZigBee in openhab:
More important than the coordinator (in my case zzh) are the routers.
I played around with osram plugs, too but I always had long delays or drops. Then I switched to the innr plugs and now I have a rock stable network.
One bad router effects the whole network, so remove any router with bad ZigBee implementation.
You can check the network nicely in the web frontend which can be enabled in the zigbee2mqtt configuration.
I use zigbee2mqtt cause the supported hardware is really huge.
I am using zigbee2mqtt with 2 Ikea’s zigbee repeaters and 1 Ikea lightbulb as routers. I haven’t had any issues with my zigbee network. My zigbee devices are almost all Xiaomi aqara battery powered sensors (motion, contact, button, thermometer)
The nice thing about zigbee is that so long as a device follows the standards (and I appreciate not all do!) then there will be good support for them. The zigbee binding doesn’t require device definitions - it reads the functionally supported by devices and provides channels based on this information. This is generally a better approach than needing to add a device definition as used in mqtt.
Of course there are times when devices don’t follow the standards, and then these definitions may be needed, and here mqtt does win - this is often the case for the cheaper Chinese devices which often use non-standard functionality (sadly). The zigbee binding can also support this if people add the definitions, but this does become a maintenance “nightmare” (this is how the zwave binding works due to the zwave binding being quite a bit older, and OH did not support the newer functionality used in the zgibee binding, when it was written, and it’s really a bit of a pain).
Personally, I recommend sticking to compliant/certified devices - they are more likely to work within the mesh, and interact properly when communicating to other devices. This doesn’t just include communications to OH - but if you want devices to be able to communicate with eachother even when OH isn’t running (eg to have your motion sensor directly turn on a light without sending the command to OH, then using an OH rule to send the command to turn on the light).,
I totally agree, only my conclusion is different: I love the cheap Chinese zigbee devices (Aqara…). They really work good and are ridiculously cheap. So buying, testing and throwing in the shelf if it doesn’t work causes no pain.
Zigbee2mqtt is used by several platforms like openhab, home assistant, domotic, so I think that’s the reason why the supported hardware is so huge. Even my Livolo zigbee light switches (beautiful but awful ZigBee implementation) work perfect.
Another point is that with zigbee2mqtt your really get a good overview over the topology of your whole ZigBee mesh, seeing how routers and endpoints are connected. This is really helpful if something does not work and ZigBee is quite woulnerable if one element (especially a router) goes crazy.
But overall the nice thing about openhab is that there are many ways and solutions which all work and it’s up to you which one you prefer.
Well, many people find that isn’t the case - they are certainly problematic.
That’s for sure
Again, that’s probably up for debate. You might be able to afford the time and money to do this when things don’t work, but many people probably can’t, and sticking to certified devices provides a much more assured result.
This is also available with the Zigbee binding, it’s just that the UI doesn’t display this, but all the information is provided.
Of course there are many ways to do things, and for the DIYer, the mqtt route has some advantages. IT is however more complex - the zigbee binding was written for commercial use (eg Qivicon in Germany) where more compliant devices tend to be used. It’s just up to people to make their decision of course, and different people will decide differently based on whats important to them (as you have)
