ZHA vs Zigbee2Mqtt - which is the most stable?

Configuration Zigbee
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.

45

@neildsbm No! Just no! That is wrong in everyway possible, and not supported in any bay in the Zigbee specification, Zigbee gateways, or by Zigbee Coordinator makers. The serial interface protocol on those Zigbee stack firmware not a bus, the serial connection is exclusive. Such a bad idea it borders on trolling trolling, especially when you bring this up in a thread that is specifically about stabilty.

You always need to use a separate dedicated Zigbee Coordinator for each Zigbee Gateway, period!

And as a wrote in the post above, using a network-attached Zigbee Coordinator adapter is a dirty workaround regardless that even when only using a single Zigbee Gateway 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.

46

I have to disagree with this. LAN-based coordinators that are strictly Ethernet based are usually more powerful in terms of mesh processing and coordination and are not susceptible to USB3 interference like a USB coordinator can be. Yes, using a RJ-45 adapter can place the USB coordinator far away from interference sources and is a viable solution.

Yes, however, almost all LAN connections are very stable and the TCP/IP protocol itself (even used over Ser2Net) has redundancy built-in to handle any kind of packet loss. Even then, it’s usually a case of a bad Ethernet cable or possibly a port that will cause problems. USB-based coordinators suffer from the same issue though; A bad extension cable or port will also cause issues for the user.

Both of the links you posted talk about WiFi, not LAN based (Ethernet) connections. In that case, yes, WiFi based LAN coordinators are very bad and I never have recommended those. In fact, most users that say they are using WiFi based LAN coordinators are told to stop using that and go with a directly connected Ethernet coordinator.

This is completely incorrect. While Ethernet does not have a start bit, it does use start-of-frame and either scrambling or Manchester encoding so that a clock wire isn’t required. The transmitter encodes clock data and the receiver decodes the clock data. The ONLY time this would be even remotely accurate is if the user is on something like token-ring or some other ancient technology. Any modern router produced in the past 20 years will use either encoding method with start-of-frame/end-of-frame packets to ensure synchronous delivery. I would suggest learning the OSI layered network model before making claims like this as it is wrong.

Again, no one ever suggests using a LAN based coordinator over WiFi or VPN. We actively discourage that in all of our support mediums. It’s the same for using HA itself over a WiFi connection. We never, ever recommend WiFi for either LAN-based coordinators or HA itself. Nowhere have I ever seen someone (including myself) recommend WiFi/VPN based coordinators.

If you could provide some statistics showing how a LAN-based coordinator behaves when packets are dropped (which, again, TCP/IP handles internally in the stack through re-transmission), I’d be happy to change my opinion here. However, after many years of being in the networking space, I can tell you first hand that what you are describing rarely happens except in the worst of circumstances. Even on very cheap consumer networking gear, the TCP/IP protocol is still operates the exact same way.

1 Like
47

“No one”? At least “XZG Firmware” (which is used by several network-attached Zigbee Coordinator adapter manufacturers including ZigStar) and “SMLIGHT” Zigbee network-adapters both have WiFi configuration as well as a VPN client built-in available via easy-to-use settings in the UI. They are marketing them as " Key features" without any warnings about why it is a bad idea to use those feature, instead just making it easy for users to believe it is a good idea to use them WiFi and/or VPN. I have not checked but think there are other similar firmware that at least have WiFi configurations built directly into the UI too simply because the ESP32 chip they use has Wi-Fi capability(?).

I mean, if a feature is there then why should a user not assume that it should work without any problems.

IMHO best would be if the XZG Firmware developers would just remove those any Wi-Fi and VPN features completely from their firmware as using them can give users a bad experience and put an extra strain on the developers of Zigbee Gateway project whose users buy those.

Much better to not make it easy to create a bad setup.

After many years of me helping many ZHA and Zigbee2MQTT end-users here in this community forum or other support channels for those two projects I can tell you from my own first-hand experience that while it is true that most users do tend to use stable wired Ethernet LAN connection and therefore those often seem to have no problems there are still many end-users here reporting issues and asking for help here where it turns out that they connecting a network-attached Zigbee Coordinator adapter over Wi-Fi or VPN (which is why that warning against using Wi-Fi or VPN had to be added specifically).

These are are just a few examples:

And as I do not follow all other projects that uses such adapters what I have seen is only a fraction of the recorded cases, which I guess should mean that there is a multitude of number of unrecorded cases that are using a network-attached Zigbee Coordinator adapter over Wi-Fi or VPN, and might be having problems because that today or in the future, which in turn can create an unfair reputation via word-of-month, etc. the ZHA and Zigbee2MQTT projects being unstable when the root cause is really the users network or setup not being stable enough for a network-attached Zigbee Coordinator adapter.

1 Like
48

“No one” meaning us as helpers/experts here on the forums, Discord, Reddit and FB. Yes, the companies market those features, but in terms of what WE can control and suggest, myself and many others always discourage WiFi/VPN usage. Granted, we cannot control what the user does with their device, but generally speaking, they either end up here or on one of the other support mediums when they have issues. Case in point, I had a user on Discord just about a week(?) ago asking about a WiFi connected Sonoff coordinator and major instability on their mesh. Lots of discussion back and forth and finally got them to understand what the problem was with their mesh and it was the WiFi coordinator that was causing the majority of their issues. Once explained why it was bad, the user decided to get another coordinator and connect it via LAN. This happens more often than not.

Yup. Same. I almost always defer to you for Zigbee related matters when it comes to mesh communication and interference issues. With that said, pretty much the first question I ask is what coordinator and how it’s connected. When I see WiFi/VPN, I launch into a tirade of “STOP THAT” comments. Usually after a few minutes of explaining, I get the point across. :wink:

I get what you’re saying and I do agree about the WiFi/VPN connected coordinators 100%. But, lumping in all LAN-based coordinators isn’t correct or accurate. At the end of the day, most users that have issues with their mesh ends up here or on the other support channels and we usually have to reiterate what our experiences are with Zigbee equipment “as experts”.

4 Likes
49

Just to chime in here:

We fork XZG (previously UZG) for our cod.m ZigBee Coordinator (CZC) and are currently working on a new release. We will put a disclaimer on the page of the Wi-Fi and WireGuard settings in the webinterface to discourage users to use it and try to explain why this is not a good idea.

Already updated our documentation for the coordinator: Overview - cod.m Knowledge Base

Our coordinator - as well as every variant with a appropriate chip out there - will support working as a Thread border router, so the Wi-Fi option makes sense. At least for that use case. Correct?

1 Like