Usually you do not have to re-pair everything, and the widespread belief that you do comes from confusing two different operations. A channel change is broadcast to the network, and devices that were awake follow it. Battery powered devices that were asleep at the time switch the next time they wake up. Only the ones that still do not respond after being woken need a manual re-pair. Changing the network key is the operation that forces a full re-pair, and that is a different setting.
What the change actually does to a running network
A channel change is not a rebuild. The network announces the move and the devices follow.
The Zigbee2MQTT documentation describes the mechanism plainly: the change is broadcast as a network update, and devices on the network act on that broadcast. There is no step where you go around the house re-introducing things one at a time, which is what most people picture when they hear the word “channel change” and quietly decide to live with the drops instead.
The Home Assistant ZHA documentation puts a number on the aftermath: it might take up to an hour for all devices to reconnect to the new channel. That is the figure to plan around. It is their published figure, not a measurement of ours, and it is the only documented number we found that both major platforms are consistent with.
So the honest expectation is: make the change, walk away for an hour, then look at what did not come back.
The devices that lag, and why they are almost always the battery ones
The hour is not the network being slow. It is a consequence of how battery devices behave.
A device running on a coin cell or a pair of AAs cannot afford to listen constantly, so it sleeps and wakes on its own schedule. If the broadcast goes out while it is asleep, it does not hear it. Zigbee2MQTT states this directly: devices that are asleep during the broadcast, usually battery powered end devices, will not switch immediately, but will the next time they wake up.
That is why a door sensor nobody opened for six hours can still be missing long after the mains powered devices are all back. It is not broken. It has simply not woken up yet.
You can shorten the wait. The Home Assistant ZHA documentation’s advice for speeding this up is to power cycle your Zigbee end devices, which in practice usually means pulling and replacing a battery, or pressing the device’s own button to make it report. Which of your devices fall into this category is covered in which of your devices are actually repeating the signal.
The ones that genuinely will not follow
A small number of devices do not handle the change and need a manual re-pair. That is real, and it is worth expecting so it does not feel like a failure.
The Zigbee2MQTT documentation sets the threshold for deciding: if a device remains unresponsive several minutes after the change, and after having been triggered or woken up, you may have to re-pair it manually. Note the order in that sentence. Waking the device comes before concluding it needs re-pairing, and skipping that step is how people end up re-pairing things that would have recovered on their own.
So the realistic outcome for a household of thirty devices is not thirty re-pairings. It is most of them following within the hour, several battery devices needing a nudge, and a handful genuinely needing to be re-paired.
The channel is not the network key, and only one of them forces a full re-pair
This is the correction worth carrying away from the whole article.
The Zigbee2MQTT documentation states that changing the network key requires re-pairing of all devices. That is unambiguous, and it is the operation the “you have to re-pair everything” warning actually describes. Somewhere between the documentation and the forum posts, that requirement got attached to the channel setting instead, which sits next to it in the same configuration section and is a completely different thing.
| Changing the channel | Changing the network key | |
|---|---|---|
| Broadcast to the running network | Yes | No |
| Full re-pair required | No | Yes, all devices |
| Typical time to settle | Up to an hour per Home Assistant’s ZHA documentation | However long it takes you to re-pair each device by hand |
| Battery devices catch up on their own | Yes, on next wake | No |
If someone told you that moving channels means redoing all thirty devices, they were describing the other setting.
Before you change it: know whether your setup supports it at all
The capability is platform-dependent rather than universal, and this is the check to run before committing an evening.
Zigbee2MQTT documents channel changing as supported only for the zstack and ember adapters, which is a real constraint rather than a formality. Home Assistant’s ZHA has its own channel migration path. Other hubs vary: some expose the channel in an advanced settings screen, some expose it only during initial setup, and some never expose it at all.
We have not run this procedure on any hub, and this article gives no menu path for any specific product on purpose. Find your hub maker’s own documentation for the exact steps, and check three things in it before you start: whether the channel can be changed after setup at all, whether the platform warns about any specific device types, and whether there is a documented way to see which devices have followed the move.
If your channel is not exposed and cannot be changed, that is a real answer too, and it moves your effort to the Wi-Fi side of the problem, covered in where Zigbee and Wi-Fi channels overlap.
After the change, give the network room to settle
Once devices reconnect, routes still have to re-form, and that is a separate process from rejoining. If some devices come back but a far corner of the house stays unreliable afterward, the pattern and the fix are the same as rebuilding a mesh after moving the hub.
If devices were already dropping before you touched anything, work through why a device that was working starts going offline first. A channel change is worth doing for the right reason, and is wasted effort for the wrong one.
FAQ
How long should I wait before deciding a device did not follow?
The Home Assistant ZHA documentation says up to an hour for all devices to reconnect. Zigbee2MQTT’s threshold for a device that has already been woken is several minutes. In practice: give the network the hour, then wake anything still missing, then wait several more minutes before concluding it needs re-pairing.
Will I lose my device names and settings if a device does need re-pairing?
That depends entirely on your hub’s software, not on Zigbee. Some platforms recognize a returning device and restore its identity, others treat it as new. Check your hub maker’s documentation before you re-pair, because the answer changes what order you want to do things in.
Can I change the channel back if it makes things worse?
It is the same operation in reverse, with the same expectations. That said, changing it twice in quick succession gives battery devices two broadcasts to miss, so let the first change settle fully before judging it.
Do I need to be home for this?
For the change itself, no. For waking the battery devices that did not follow, yes, since that usually means physically pressing a button or reseating a battery.
Does changing the channel affect my Wi-Fi devices?
No. They are separate networks that happen to share the band. Moving the Zigbee channel changes which frequencies your Zigbee devices contend for, and leaves your Wi-Fi devices where they were.
Sources referenced in this article
- Zigbee2MQTT, Zigbee network configuration documentation.
https://www.zigbee2mqtt.io/guide/configuration/zigbee-network.html(accessed 2026-08-05). Source of: the broadcast network update mechanism; sleeping battery end devices switching on next wake; the “several minutes after being triggered or woken” threshold for manual re-pairing; that changing the network key requires re-pairing of all devices; and that channel changing is supported only for thezstackandemberadapters. - Home Assistant, Zigbee Home Automation (ZHA) integration documentation.
https://www.home-assistant.io/integrations/zha/(accessed 2026-08-05). Source of: “It might take up to an hour for all devices to reconnect to the new channel” and the advice to power cycle end devices to speed this up.
This article describes a general order of operations. Bloggent has not performed this procedure on any hub, and no product-specific steps are given. Follow your own hub maker’s documentation for the actual settings.
Review interval: 12 months (hub interfaces and platform capabilities change).