Zigbee Channel changes

Hi All, From a quick search it seems both HA and Zigbee2MQTT both requires a network rebuild in the event of a zigbee channel change with an established zigbee network.

Will Core allow a zigbee channel change on an established network without needing to re-pair devices?
And is this channel change without a re-pair of devices an officially supported Zigbee standard?

I’m asking as I have bad experiences with changing zigbee channels on established zigbee networks, and some really odd behavior afterwards, which makes me feel like it’s not officially supported.

Thanks

1 Like

I’m no expert but I’ve not seen a way to force the devices to find the new channel on command. I’ve seen the mesh heal itself with HE but it takes up to 24 hours so I suspect that’s just the devices “realizing” they’ve been abandoned and then going through the channels until they find the new one. I also know that with HE, and I assume it’s true with any controller (radio), that you can put the devices into “panic” mode by turning the radio off for at least 30 minutes after which the mesh rebuilds itself, perhaps with better routing than before.* Since I don’t believe HE is going anything special I have to think the 30-minute “panic” thing will work with any Zigbee controller attached to any system.

*I did this a few months ago with HE and it did not fix a stupid route like I hoped it would. I have a Hue outdoor motion sensor at the outskirts of my mesh that would drop off at least once/week because it usually connected directly to HE some 40’ and several walls away even though there is an excellent repeater just 15’ and one wall away.

In the last 3 weeks I have moved a third of my devices to Zigbee2MQTT and now the sensor connects to the expected repeater and hasn’t dropped even once. Whether it’s because the radio is different or that HE isn’t as smart as Zigbee2MQTT I can’t say.

YMMV

1 Like

I’m guessing this is correct. HE has a seriously underwhelming zigbee implementation, imo

2 Likes

Changing the channel really isn’t the best way to go. I know that interference can pop up at any time, but the actual recommended way that will remain stable and reliable is to re-pair the devices.

Will it work if you change it? Yes. But not reliably. Not without trouble. I know that’s not what you wanted to hear, but my recommendation is to move to the channel of preference before pairing.

There are reasons that stable environments recommend this. Just because it can be done doesn’t mean that it’s a good idea, and anyone recommending this shortcut is setting you up for failure and frustration. Pairing zigbee devices is not that hard. I paired 72 devices to my network fairly quickly. Set the pairing time out to a ridiculous number and move through the house. Do a quick name using your phone and then go back and name them on your computer. THAT is how a stable environment should be able to do this. That’s how CORE is able to do it.

3 Likes

Form me the device to be paired needs to be really close to the repeater/Hub … is this something that is different with core?

It’s been so long since I built my meshes on HE that I don’t remember the needed proximity but I can say that both Zigbee and Zwave mesh building with the Z^2M apps has been painless. As always, it’s important to build from the radio out with repeaters so that the mesh coverage is good but as long as there was good signal strength at the device I was adding it happened very quickly, like 5 seconds.

But that is not the whole story. Once the device is added to the mesh the controller “interviews” it and this takes about a minute, give or take. Is this faster than with HE? It feels like it is but that may be because HE gives you NO feedback until the interview has completed. That’s what I assume is going on anyway.

The real difference I see is that the meshes are not fragile with the Z^2M apps. With HE I have to reboot weekly because the data returned from Zigbee devices goes, literally, off the charts I have in Grafana between 8-10 days after the last reboot (This may have improved with more recent platform versions). Not only do the maps (yes, there are maps) show sensible routes given the device’s location, but the reporting feels^ faster and the data includes everything the manufacturer has made available. Plus, at least with battery level^^, it’s more precise than with HE from the experience I have so far.

^I say “feels” because I’ve not found a way to measure, for example, the instant a motion detector sends the information to the instant a light switch receives the “turn on” command. I suppose that with both Z*2M apps running on the same machine I can find the events in their logs, which is as close as I know how to get to the devices, and correlate them to get a “response” time but I’ve not done that yet. Certainly, IMO, timing the events in node-red is useless for response times. (BTW, it’s a millisecond or less :wink:)

^^I’ve measured the open-circuit voltage of a handful of CR2’s and I see that fresh ones can read as high as 3.2V. I removed one from an Iris V2 motion sensor that was showing it was down to 5% in Zigbee2MQTT and it read 2.85V. Zigbee2MQTT appears to report every 1% change.

EDIT: Replaced asterisks with ^ so the text isn’t italicized :roll_eyes:

1 Like

Hue bridge never failed me after a change of channel but that’s light link standard.

1 Like

I moved to Zigbee2MQTT about 6 months ago when I finally grew tired of having to reboot HE at least once a week because it would just stop responding. Best move I ever did, it has been rock solid since and it’s great to have stuff just work :grinning:

5 Likes

“Zigbee network offline” is a message I can’t wait to never see again

4 Likes