Migrated from ZHA to Z2M, now struggling with stability issues

Hey all,

I recently had ZHA running via a ZBDongle-E, and other than a couple of quirks such as not getting power readings from my Woolley smart plugs and ping-ponging on/off statuses of my of iolloi light switches everything else was rock solid, eg. instant motion updates from my Hue sensor and door updates from my Smartthings multipurpose sensor.

But those quirks were annoying me so over the weekend I took the opportunity to destroy the ZHA network, flash the ZBDongle with the silabs MultiPAN firmware, and setup my 21 devices again using Z2M and the Silicon Labs Multiprotocol addons.

However, while some things are now working better, automations that rely on instant sensor updates such as those from the aforementioned motion and contact sensors have become incredibly unreliable and I’m struggling to figure out what the cause is. The only assumption I’ve been able to reach is that the sensors are sending updates out, as nothing has changed insofar as their placement etc, but that somewhere along the chain the messages are getting lost.

I’m completely stumped and hoping there might be some pearls of wisdom available here. Perhaps some settings that can improve reliability somewhere in either the multiprotocol, Z2M, or MQTT addons?

For what it’s worth I’m running HAOS in a VM on a Synology 1821+, but that also hasn’t changed from when I was running the ZHA network.

Appreciate any thoughts or advice. especially if it will avoid me having to scrap and setup the network for a third time! Thanks.

Firstly, advice you to buy and connect a USB 2.0 hub and a long USB extension cable to use with Zigbee Coordinator to get it away from EMF/EMI/RMI, see → Zigbee networks: how to guide for avoiding interference and optimize for getting better range + coverage

Secondly, advice you to buy a Sonoff ZBDongle-P (based on Texas Instruments CC2652P) and move to use that Zigbee Coordinator radio adapter instead as the Sonoff ZBDongle-E (which is based on Silicon Labs EFR32MG21) as that only has experimental support in Zigbee2MQTT, and best is to start from scratch again with a new Zigbee network but could try migrating by following this → migrating coordinator from ZBDongle-E to ZBDongle-P · Koenkk/zigbee2mqtt · Discussion #16478 · GitHub

PS: Multi-PAN/Multi-protocol setup has also proven to not be stable with larger Zigbee networks so that is also just experimental.

Thanks. I do already use a USB extension cable, which again worked great under ZHA, but I’m not ruling out a reposition of the dongle. Meanwhile I’ve been reading up on it some more today and have somewhat improved performance through tweaking the reporting interval of certain devices, but it’s still nowhere near as responsive as ZHA.

I have a suspicion that reverting to the non-multiPAN firmware and removing the multiprotocol addon as the major link in the chain is going to be the best fix that doesn’t involve buying a whole new dongle, but I have a couple of things still to try. Namely:

  • Change the VM’s virtual USB port from v3 to v2.
  • Change the channel from 11 to 25 and re-pair everything.
  • While I’m at it, change the encryption key from the default (though this won’t help performance of course)

Thanks for the feedback. I’ll keep the ZBDongle-P in reserve as the final nuclear option!

I’m not counting my chickens just yet but I think I may have cracked it.

I deleted everything from the network and then changed the channel, network key, and pan IDs (for good measure), and set the virtual USB port to USB2. Started methodically re-joining everything and testing as I went but ran into the same issues again quite early on. I then tried changing the firmware on the stick to the un-recommended 7.3.2 and stability seemed to improve, right up until I tried to pair something new and it crashed entirely!

I had pretty much given up at this point and was trying to find out which Zigbee-only firmware to flash for connecting to Z2M directly when I spotted another thread where someone suggested disabling the Open Thread Border Router addon. I didn’t have that as an addon but had spotted that an integration for it had appeared, and it turns out that it’s built into the Silicon Labs Multiprotocol addon and is turned on by default. So I disabled that, deleted the integration, and flashed the controller back to 7.3.1.

So far so good! Everything seems to be reporting state changes quickly and without messages going missing. I’ll see where we stand tomorrow but it looks like that may well have been the key.

1 Like