I’ve been dealing with some random Zigbee slowness and lost commands since I was around halfway in the process of migrating to HA. I believe the issue is rooted in more than one single cause, but stacked together they’re causing these symptoms. For example, I definitely have congestion on the Zigbee channel I’m using. I’ve reconfigured my WiFi to avoid interfering, but cannot change that of my close neighbors. And apparently, cannot change Zigbee channel either.
In the process I’ve discovered a couple curious things that I want to share in case others run into these similar situations…
First, some perspective… My ZB network is HUGE and dense with 204 devices connected. It is using the HUSBZB-1 (6.6.5 firmware) and source routing. I’ve have overridden some of the EZSP defaults for performance reasons (based on logging). Of those devices, 61 are SmartPlugs and act as routers which works out to roughly 2.4 SEDs (battery-powered devices) for each routing device, far below any density constraints.
The biggest detrimental impact I discovered was that the ZHA component was spamming the Zigbee network polling power readings from Smart Plugs every 60 seconds. I find that odd since the ZHA component also configures power attribute reporting on each plug. In addition to automatic reports to HA about once per minute they being polled by HA as well. This was generating major bursts of traffic slowing the entire network and occasionally resulting in lost messages. I suspect this is a bug. My short term solution was to clone ZHA as a custom component, and disable polling for the power measurement channel in the code. After disabling this polling, my ZB network immediately stabilized and has been super-responsive since. In fact, it is much faster than anything I’ve seen in Hubitat or SmartThings, using the same devices.
This one is not HA’s fault… Zigpy/Bellows does not support changing Zigbee channels. I’ve seen some references but all solutions require re-pairing devices. The proper way to change channels is to issue a NWK update informing nodes of the channel change, increment the network version, then change radio channels. These solutions skip the first 2 steps and just brute-force change the channe. Since the ZDO spec & Ember libraries facilitate changing channels I find this omission curious. I’ve changed ZB channels before on other platforms never lost a single device in the process. With over 200 devices this limitation is more than an annoyance… In dense urban environments it may become necessary to periodically change channels to dodge your neighbors WiFi. I’ll probably submit a feature request on GitHub to look at this one.
This wasn’t intended as a complaint, but to share what I’ve learned in hopes that others may benefit in the future.