ZHA vs Zigbee2Mqtt - which is the most stable?

Configuration Zigbee
25

Yes, I’m trying to center my home automation/monitoring around HA.

To me, adding additional hardware, a new protocol, additional wiring, power, network connection and another integration would be far from “simple.” It would also involve a learning curve and several more hardware and software components subject to ongoing maintenance and support.

My first and most important tip to new users would be this: Minimize the number of different types of components, protocols, integrations and external dependencies (especially, “cloud” dependencies) to the extent possible.

As I said, we all like to tinker. But there’s a downside to jumping on every new (or existing) technology which strikes your fancy. Building complexity builds a long-term support commitment.

4 Likes
26

Just wondering, you would need 2 different Zigbee gateways for this to work, correct? I am now using ZHA, but I have one device that does not work on ZHA, and I do see it available in Zigbee2MQTT so would also like to use both.

27

Yes, you need two gateways (coordinators).

28

ZHA all the way, my friend.
I have experience with both, and I ended up trashing zigbee2mqtt.
ZHA is very well-tuned for home assistance.
I would even say the conbee 2 works so well with ZHA in comparison to zigbee2mqtt.

29

Agree to avoid zigbee2mqtt if you have the conbee. It’s always had issues with it and for awhile was listed as “experimental”. It still has ongoing issues.

I do use zigbee2mqtt with the zzh usb stick still and haven’t had a problem, but, like I posted higher up, zigbee2mqtt seems fussier with adapters vs zha

30

Hi, since two years i use zigbee2mqtt with a CC2650 usb key and sometime i had to restart, i lose all my zigbee network, i just bought a new sonoff usb key and it does the same in just two days, so i decide to switch to ZHA yesterday, i will told you if it’s better or not.

31

It’s a bad time to switch to ZHA since that integration currently broken (keeps going into an initialisation loop) for many users.

1 Like
32

I am only one user but I have never had an issue with ZHA. I don’t have a very big network so not certain if that helps. My biggest problem was the Ikea devices I started with needed new batteries before they were reliable.

1 Like
33

Day-to-day stability mostly depends on a combination of the Zigbee Coordinator adapter hardware/firmware setup, Zigbee devices you add to your Zigbee network and most importantly following best practices to avoid interference + adding enough (well-working) Zigbee Router devices, see these tips → https://community.home-assistant.io/t/guide-for-zigbee-interference-avoidance-and-network-range-coverage-optimization/515752 …if you do all that not buy brand new devices directly when they are first released then you should not have too much trouble regardless of which Zigbee gateway solution you are using.

Before following those best practices I had loads of connectivity problems in the beginning when started to use Zigbee due to interference and too few Zigbee Router devices. Now I advice all to use a long USB extension cable to USB 2.0 port (or USB 2.0 hub) and add at least three “known good” Zigbee Router devices in strategic places around your home before start adding any other devices.

1 Like
34

Running ZHA for a few years and it hasn’t failed so far. It never broke for me and I keep it up to date.

I’m using Hue, Ikea, Innr, Sonoff and Aqara and everything works so far. https://zigbee.blakadder.com/ contains a list of compatible devices. I guess ZHA and ZigBee2MQTT will both work for most users.

Edit: I’m aware of the ZHA hotfix this month. It just didn’t seem to affect me.

1 Like
35

FYI; @BeardedConti posted this pros and cons video about ZHA versus Zigbee2MQTT for new users:

While it does not cover all caveats/ limitations in different scenarios, I think he does a great job at very quickly presenting a summarized comparison based on the current state of these two Zigbee gateway solutions for use with Home Assistant.

I do however think that it should be added that the development of these two projects (and the code components that they depend on) is moving relatively fast, so what is a fact on how they work today might have changed in a year from now, especially on the user-interface and end-user experience sides which become more and more mature in these projects.

Regardless, I highly recommend all Zigbee users read these to get a better general grasp on the caveats and limitations in common setups and different scenarios:

4 Likes
36

not really - https://smarthomescene.com/guides/how-to-use-zigbee2mqtt-and-zha-with-a-single-coordinator/

37

Is there any disadvantage to using this type of network coordinator over a USB coordinator that everybody seems to be using?

38

Disadvantages? No. Advantages? Plenty.

1 Like
39

I use a SLZB-06M, my HA is in a VM, so a network coordinator is best for my use case

1 Like
40

Thanks for the link, I’ll check this out.

I’m running a VM too, and that makes sense about a network coordinator being simpler to integrate.

I had an issue with something in Proxmox getting broken when I made what I thought was an unrelated change for a new USB pass through. It was a little bit of a PITA to figure out and fix. Made me want to avoid those configurations at all cost.

1 Like
41

:ok_hand:t3: thank you!

1 Like
42

Are you doing all of your automations in NR outside of HA?

Part of my quest to tame the beast that is home automation is to bring all automations into one platform. There is nothing more frustrating than to have a light turn on/off through an automation but not be quite sure which automation did it.

(ie. Lutron has a countdown timer for lights to auto turn off, and my Hue motion sensor has an HA automation to turn lights on temporarily if it is dark when someone approaches, and smartthings puts everything to “bed” at midnight, so who turned out the lights? lol)

I am currently mostly using automations within HA, but like the way NR looks for visualizing flows, but have been wary of dipping my toes into it as having three ways to control stuff within HA isn’t any better than three separate apps.

43

hello
yes, except literally a few I’ve created at the very beginning or borrowed from somewhere (like sending notifications about system restart) all my automations are in NodeRed.

I agree with you that scattering automations across different places and/or technologies is far from optimal, and in extreme situations might lead to race conditions.

44

Sorry but you are very wrong here and I like to ask you to please stop recommending network-attached Zigbee Coordinator adapters to everyone, (especially when the topic is specifically about stability).

There can definitely be some disadvantages to using a network-attached Zigbee Coordinator adapter, and that is why I persoanlly do not recommend them to most users and instead think those should only be used as the exception in edge cases when it is not at all practically possible to just use a very long USB extension cable instead, epecially when you can simply convert any Ethernet-cable into a extremly long USB extension cable, see my Zigbee Coordinatoir adapter recommendations here → Zigbee buyer's guide - #2 by Hedda.

If a network-attached Zigbee Coordinator adapter is used and the users LAN is a little unstable or drop any packages for whatever reason then they will have problems and troubleshooting Zigbee Coordinator issues due to unstable LAN connection can be hard and will give the users an unnessesary bad experience which is not the fault of the Zigbee Gateway software and can put a strain on ZHA and Zigbee2MQTT developers, which is why there are now warnings against using network-attached Zigbee Coordinator adapters like that onder WiFi or VPN in both the ZHA and Zigbee2MQTT documentation:

Most users of Zigbee find out sooner or later that Zigbee can be very finicky/fussy about its needs and requirements even without adding the extra complexity that tunneling/piping serial over LAN adds. See:

To quote myself: “in a few edge cases it might be worth looking at a network-attached Zigbee Coordinator adapter (also referred to as Zigbee LAN adapters) like the Zigbee-to-Ethernet/USB Serial Coordinator solutions from TubeZB, and similar products from ZigStar, SMLIGHT, or cod.m as another alternative way to workaround the problem of relocating a Zigbee Coordinator radio adapter to a remote location for better reception, but please understand and respect that I personally think that using a such network-attached Zigbee Coordinator adapter should a solution should only ever be the exception when there is no other solutions and not the go-to rule, as please note that all those are proxy-servers uses Serial-over-IP tunneling which adds a little more complexity than simply using a very long USB extension cable (which I personally recommend using instead). I therefore personally believe that in most use bases it will be both easier and better to just use a very long shielded USB extension cable and a tip there is that you can easily achieve up to around 30 meters by using inexpensive “USB Ethernet RJ45 Extender Adapter” converters which easily and practically convert any single CAT5e/CAT6 shielded Ethernet cable with RJ-45 connectors into a very long passive USB extension cable (as it does not use LAN or IP but only converts an RJ45 Ethernet cable to a dumb USB extension cable). With such a solution you can use any Zigbee Coordinator USB dongle and easily replace the USB dongle later too (which should make for a less expensive solution in the long run). See example → https://www.amazon.com/Male-RJ45-Female-Extension-Adapter/dp/B083W3D65G Note! An additional caution warning about using Zigbee Coordinator network adapters over Wi-Fi/WAN/VPN. Be aware that using a Zigbee Coordinator via a Serial-Proxy-Server (also known as Serial-to-IP bridge or Ser2Net remote adapter) over a Wi-Fi, WAN, or VPN connection is not recommended. Serial protocols used by the Zigbee Coordinator do not have enough robustness, resilience, or fault tolerance to handle packet loss and latency delays that can occur over unstable connections. A Zigbee Coordinator requires a stable local connection to its serial port interface with no drops in communication between it and the Zigbee gateway application running on the host computer.”

Before buying such adapters users of those adapters should at least be aware those products are just Serial-over-LAN applicances with proxy server software that only uses Serial-over-IP to pipe/tunnel the serial communication port over a TCP/IP connection unchanged. Meaning that the serial data need to arive in-time and still serialized (in synchronous order with a start bit and and end bit), while Ethernet/LAN tecnology is asynchronous so does not have a start bit or is coded in a way that facilitates clock recovery which can cause tranfer delays and data packets being dropped because they did not arrive in time. There is nothing the makers of network-attached Zigbee Coordinator adapters can do to ensure that it can deal with stability issues of that connection as the serial protocol that is piped/tunneled is proprietary from the Zigbee stack firmware manufacturer (e.i. Silicon Labs and Texas Instruments), so it is not like makers of network-attached Zigbee Coordinator adapters can add buffers or other technology that could help ensure that the connection remains stable.

So from a technical and architecture point-of-view it is a bad idea to use a network-attached Zigbee Coordinator adapter as not only does it add extra complexity and dependencies that your LAN is stable but more importantly the developers who wrote the Zigbee stack applications interface serial communication protocol that is running in the Zigbee Coordinator firmware have designed the serial communication protocol as a synchronous data transfer protocol and made specifically for a direct-connection and thus it expects to have a 100% stable connection, as such the Zigbee stack firmware developers at Silicon Labs and Texas Instruments, etc. have not added much software fault tolerance, robustness, and resilience into the Zigbee stack applications interface serial communication protocol to deal with latency delays or packet loss that are more likely to occur if you use a serial stream proxy server over TCP/IP tunnel to pass-though that communication over a LAN.

Now most experienced Home Assistant users probably have such a network-attached Zigbee Coordinator adapter connected via a near 100% stable wired Ethernet LAN and will therefore not see problems often, but there will be problems for those users who do not have a a near near 100% stable wired Ethernet LANm and even worse for those who connect it via a Wi-Fi network or via VPN over WAN/internet connection, (because Wi-Fi network or a VPN are features built-in to some network-attached Zigbee Coordinator adapter firmware and the makers of is marketing as available without any warnings in the product or its documentation)

Sure the Zigbee gateway connection might recover if there is a total disconnect but the result will be worse when it only drops some packages intermittently and that will make troubleshooting much harder for the end-users and developers of Zigbee Gateway host appllications such as Zigbee2MQTT and the ZHA integration. Thus the end-users must be warned and recoomened to try to connect a network-attached Zigbee Coordinator over WiFi or to a remote WAN/VPN. That applies to a DIY solution using Ser2Net or any other Serial Proxy/Forwarding Tunnel is not supported for normal operation. This it should never be recommended to use a Zigbee Coordinator via a Serial-Proxy-Server / Serial-over-IP solution over a WiFi, WAN, or VPN connection.