Hi,
I’ve got into home automation through wifi devices and switches. Some time after, I hit the ceiling of my wifi network and after some suffering I switched to ZigBee.
I though I did well with my research but recently learned that there are various ZigBee devices out there.
There are at least two platforms that I know of: tuya and 2MQTT.
I know that tuya is a closed platform and it needs it’s own tuya ZigBee hub and ZigBee devices but don’t know much about 2mqtt apart of it’s being open source.
So, could some point me to some resource where these two are compared or tell me about the advantages and/or disadvantages.
I have tuya all over the place. Should I switch to 2MQTT or keep the existing tuya stuff and build with 2mqtt from then on?
If I understand right 2mqtt is not compatible with tuya switches at all. Is that right?
What about ZHA? That’s the “native” Home Assistant integration.
The difference between ZHA and Z2M is that ZHA aims to integrate all Zigbee devices “out of the box”, providing they implement the specification correctly. Unfortunately a lot of them don’t, and Z2M is often better at supporting these because each different device has its own handler. You still need to research devices before you buy them, however, because neither integration covers everything. There are some useful resources here:
Tuya do not produce devices, they’re more of a development platform for IoT devices used by various manufacturers, wi-fi as well as Zigbee. The Tuya badge is not an indication of quality.
Zigbee2MQTT is compatible with Zigbee Tuya switches, and if you find one that is not compatible, you can file a feature request for a new convertor.
The big difference between a Tuya Hub and Zigbee2MQTT/ZHA is that a Tuya Hub is limited to Tuya Zigbee devices, while Zigbee2MQTT/ZHA works with a wide range of Zigbee devices from Tuya, Aqara, Ikea, Philips Hue, etc…
While it is true that Z2M often has better support, you do make it sound worse than it is. ZHA assumes the device is standard. If it is then it works out of the box, without ZHA needing to do work on it. ZHA will only support the standard bits. If it does not work, ZHA needs to develop a quirk to implement non standard behavior for that device. So new devices that are built well work right away, but they may not recognize or support every setting there is for the device.
Z2M will not assume anything. If it does not know the device, it will not work. Someone needs to write (or augment) a handler for it to work. So for new devices, it may take Z2M a little longer to support it, but once it does it is tailor made. That is why the Z2M support, once there, is often more feature complete and robust. Plus the people behind it do a great job.
In terms of painless integration, get a supported zigbee coordinator (USB or ethernet based options exist) and use it with either ZHA or z2m (zigbee2mqtt). This way your (supported) zigbee based tuya (or other) devices are natively supported and just work, without any talking to tuya’s cloud services (even completely offline), no tuya zigbee hub needed (the ZHA/ z2m zigbee coordinator takes that job).
The above only applies to zigbee based tuya devices, wifi based tuya devices do not work without tuya’s cloud services.
Yes, this is a bit scary for your first steps - but in practice it works really well.
Thanks!
I’ve been looking at the deconz based raspbeeII adapter because that pretty much seems an easy yet solid solution without much hassle.
The only drawback I see is that the adapter doesn’t support backup.
Does this mean the of the adapter fails and I need to replace it I need to repair all the devices?
I’ve made quite good experiences with EmberZNet adapters (Silicon Labs) zigbee coordinators so far, including the the not-recommended zb-gw04 (for a cheap test platform).
Sadly zigbee is quite bound to the coordinator hardware - and even backup/ restore is not without side effects (you effectively do clone the old coordinator, its UUID, not a problem if you throw the old coordinator away, but a real problem if you want to continue using both coordinators), so re-pairing everything is the only reasonable course of action anyways.