Give the network about an hour, and if the far end of the house is still dead, stop waiting and force the rebuild. Home Assistant’s ZHA documentation says devices normally rejoin within an hour and that power cycling speeds it up. Beyond that, waiting rarely fixes it on its own, because routes are rebuilt by devices noticing a path has failed, and a device that is not being asked to do anything has no reason to notice.
Why a mesh does not reroute the moment you unplug something
The promise of a self-healing network sets an expectation the reality does not quite meet, and the gap is where most of the frustration lives.
Routes are not recalculated continuously. A device learns a working path and keeps using it, because constantly re-deriving the route would cost power and airtime for no benefit while the path still works. When you pick the hub up and carry it to another room, nothing announces that. The devices still hold the route they learned, and they only discover the problem when they next try to use it and it fails.
The Zigbee2MQTT FAQ names this cause explicitly: a route can be lost because of moving the coordinator to another place at home, and its recommended recovery step is to restart the device. Restarting is what discards the stale route and forces a fresh one to be found.
So the network is not being slow. It is being efficient, in a way that happens to be exactly wrong for the thing you just did.
Self-healing needs somewhere to heal to
The second correction matters more than the first, because no amount of patience overcomes it.
Rerouting works by finding another path. If another path exists, the network will get there. If it does not, there is nothing to find, and a device at the far end of the house will keep failing no matter how long you wait or how many times you restart things.
This is why the layout of your mains powered devices matters more than the count. Devices strung out in a single line down a hallway give you exactly one route, with a single point of failure at every link along it. Moving the hub can break that line at the first link and leave everything past it stranded, with no alternative to fall back on.
If you are not certain which of your devices are carrying traffic in the first place, which of your devices actually repeat the signal is worth reading before you spend an evening restarting the wrong things.
The restart order that actually rebuilds routes
Here is the framework. Two things about it are worth stating plainly before you follow it.
The documented part is the restart itself: Zigbee2MQTT recommends restarting the device to recover a route lost by moving the coordinator, and Home Assistant’s ZHA documentation recommends power cycling end devices to speed up reconnection.
The order below is reasoning from how routes are formed, not an instruction printed by either platform. It follows from the fact that a device can only find a path through neighbors that are themselves already reachable.
- Confirm the hub itself is settled and running in its new position. Everything else depends on it. If it is not fully up, everything you restart next will fail to find it and you will do the work twice.
- Restart the mains powered devices, starting with the ones physically nearest the hub and working outward. These hold routes too, and they are the ones nobody thinks to restart. Each one that comes back with a fresh route gives the next one out something valid to attach to.
- Then wake the battery devices. Power cycling, or pressing the device’s own button so it reports, is the documented way to speed this up. Doing these last means they are attaching to a mesh that has already re-formed rather than one still in pieces.
- Leave it alone and check again later. Restarting things repeatedly while routes are still forming makes the picture harder to read, not better.
The devices nobody restarts are the ones holding the stale route
This is the part almost every page on this subject leaves out.
Search results for a mesh that will not heal overwhelmingly tell you to power cycle the battery devices. That advice is correct and incomplete. A mains powered device holds routing state too, and it can be holding a route through a hub position that no longer exists. The battery sensor downstream of it may be behaving perfectly, faithfully sending its reports to a neighbor that no longer knows where to forward them.
If you have restarted every battery device twice and something is still unreachable, the mains powered device between it and the hub is the thing to look at next. It is the least intuitive step and it is frequently the one that resolves it.
When it is not the mesh at all
Before committing to a full rebuild, rule out the cases where routing was never the problem.
If everything went offline at once rather than just the far end, the hub itself is the more likely cause, whether that is the move having disturbed a cable or a power supply, or the hub not having fully come back up. If devices are unreliable everywhere including next to the hub, that pattern points at contention with your Wi-Fi rather than at routes, covered in where Zigbee and Wi-Fi channels overlap. If you changed the channel at the same time as moving the hub, separate the two, because the recovery behavior is different and is covered in changing your Zigbee channel.
The general order for working out which layer is failing is in why a smart device that was working starts dropping off.
How long to wait before deciding it failed
Published settling times for this vary wildly. You will find pages confidently quoting anything from a couple of hours to two weeks, and they disagree with each other by more than an order of magnitude, which is a good reason to trust none of them individually.
The one figure with a primary source behind it is Home Assistant’s ZHA documentation: devices normally rejoin within one hour, and power cycling can accelerate that.
A workable standard, then: give it the documented hour before doing anything. If devices are still missing, work the restart order above rather than waiting longer. And after that, judge the result over a day rather than over five minutes, because a device that reports once every few hours cannot tell you it is fixed any faster than its own reporting schedule allows.
FAQ
Should I just move the hub back?
If you have the option and the previous position worked, that is the fastest test of whether the move caused it. It also tells you something useful: if moving it back does not restore things, the move was not the cause and you have been debugging the wrong event.
Does my hub have a “heal” or “repair” button, and does it do anything?
Some do, and what it does varies by platform. Where one exists it is worth trying before manually restarting things. Check your hub maker’s own documentation for what their button actually triggers, because the same word covers quite different operations across platforms.
How far can I move a hub before this happens?
There is no threshold to quote. What matters is not the distance moved but whether the devices that were routing through the old position can still reach the new one. Moving it one room can break more than moving it a floor, depending on what is between.
Will the devices eventually sort themselves out if I ignore it?
Some will. Anything with no alternative path will not, and that is the case where waiting is simply lost time.
Do I need to re-pair anything?
Usually not. A lost route is not a lost pairing, and restarting a device is a much smaller operation than re-pairing it. Treat re-pairing as the last resort after the restart order has been worked through.
Sources referenced in this article
- Zigbee2MQTT, FAQ.
https://www.zigbee2mqtt.io/guide/faq/(accessed 2026-08-05). Source of: a route being lost because of moving the coordinator to another place at home, and restarting the device as the recovery step. - Home Assistant, Zigbee Home Automation (ZHA) integration documentation.
https://www.home-assistant.io/integrations/zha/(accessed 2026-08-05). Source of: devices normally rejoining within one hour, and power cycling end devices to accelerate that.
This article describes a general order of operations. Bloggent has not moved a hub and observed a mesh rebuild, and no product-specific steps are given. The restart order in step 2 is reasoning from documented routing behavior, not a vendor instruction, and is labeled as such in the text.
Review interval: 12 months.