What Happens to Battery-Powered Zigbee Sensors When You Unplug Their Nearest Mains Router: A Mesh-Healing Timeline

Unplugging a mains-powered Zigbee router is the cheapest experiment in a smart home, and the one most likely to be misread. The sensor in the next room goes quiet. Nothing in Home Assistant turns red for hours. You conclude the mesh is broken, or that it healed, and either conclusion may be wrong.

The useful question is narrower than “how long does the mesh take to heal.” It is: did this specific battery device lose its parent, and what did it do about it? The answer is observable, but only if you set up the observation before you pull the plug.

The failure is a single link, not a mesh

In Zigbee, an end device has exactly one parent — either the coordinator or a router, generally whichever was closest when it paired. All traffic to and from that device passes through that parent. End devices do not route traffic for others, and they may sleep, which is what makes them suitable for battery operation. Routers are mains-powered and never sleep. The coordinator is a special router that forms the network. The Zigbee2MQTT network documentation states this plainly: “An end device only has one parent, either the coordinator or a router, generally the closest device when it was paired. All communications to and from the end device is via their parent.”

That single-parent property is the whole story. When the parent router goes offline, the same documentation says: “all traffic to its children will cease until those end devices time out and attempt to find a new parent.” There is no alternate path held in reserve at the sensor. The mesh has redundancy at the router layer; the battery sensor does not.

This is why “the mesh is self-healing” is true and unhelpful at the same time. The Connectivity Standards Alliance describes Zigbee as a “proven, self-healing mesh network” that “eliminates single points of failure.” That describes the topology’s design intent. It does not promise that a given sleepy end device will reselect a parent on a schedule you can rely on. For the device on your windowsill, the relevant behavior is firmware-specific, and the documentation is explicit that some models never reseek a parent at all.

Two device classes, two different clocks

Before diagnosing anything, separate the devices by power source, because they fail and report differently.

Routers are mains-powered, always awake, and expected to be reachable. In ZHA, the default window before a mains-powered device with no activity is considered unavailable is 7,200 seconds — two hours. That is a reasonable alerting threshold for a plug or bulb that should be chatting constantly.

Battery end devices sleep. They may report only when triggered, or on a slow periodic schedule. ZHA’s default unavailable window for battery-powered devices is 21,600 seconds — six hours — and the documentation explicitly suggests raising it for sleepy sensors that only report when triggered. Zigbee2MQTT’s availability feature is stricter in one sense and looser in another: it is disabled by default, and when enabled, passive (battery) devices must check in every 25 hours by default or be marked offline.

Those defaults are not bugs. They are the vendor’s acknowledgment that silence from a battery sensor is normal. The consequence for diagnosis is important: a battery sensor that has not reported in the last ten minutes tells you almost nothing. If you unplug a router and start watching for an immediate offline flag, you are watching the wrong instrument.

Build the observation layer before the experiment

You need two things recorded, and they are not the same measurement.

Availability is a derived online/offline state. In Zigbee2MQTT it publishes to zigbee2mqtt/[FRIENDLY_NAME]/availability as a retained message, and it is off by default — you must set availability: enabled: true in the configuration. For battery devices the default timeout is 1,500 minutes. In ZHA the equivalent is the battery-device unavailable window described above. Availability is what you want for alerting, because it is already a threshold decision.

Last seen is a raw timestamp of the most recent Zigbee message from the device. In Zigbee2MQTT it is controlled by the last_seen option under advanced, whose default is disable; setting it to ISO_8601 or epoch adds the attribute to MQTT messages. This is the instrument for a timeline, because it gives you a time, not a verdict.

One subtlety matters when you interpret last_seen: a check-in is “any kind of Zigbee message from the device that reaches Zigbee2MQTT (even internal updates that are not displayed/reported),” per the availability documentation. So a device can be alive and checking in while producing no user-visible state change. A quiet sensor is not necessarily an orphaned sensor.

Before unplugging anything, record which router each battery sensor is parented to. In Zigbee2MQTT the network map shows this; in ZHA the network visualization does. Write it down with a timestamp. Without that baseline, the later timeline is uninterpretable — you will know a sensor went silent but not whether it was ever a child of the router you removed.

The timeline, read correctly

Here is what the evidence supports, and where it stops.

At the moment of unplug: traffic to the router’s children ceases. There is no graceful handoff message. The children do not know yet.

Minutes to hours: a sleeping end device wakes on its own schedule — a button press, a periodic report, a poll — and discovers its parent is gone. What happens next depends on firmware. The Zigbee2MQTT documentation is blunt: “Some models of end device, notably Xiaomi, don’t attempt to find a new parent so will remain isolated until re-paired with the network.”

Beyond that: I will not give you a healing time, because the sources do not support one. A contributor on the Zigbee2MQTT issue tracker stated that end devices discover a new path “for up to 24 hours,” but that is one person’s statement in a forum thread, not a specification, and the same thread contains reports that conflict with it. Another user described Xiaomi Aqara sensors that did not search for a new path “even after days” until the button was pressed once. A third described devices still disconnected after 30 minutes and multiple button presses, which reconnected immediately when the original router was restored. These are anecdotes about specific models and firmware, and they point in different directions. Treat them as evidence that behavior is model-dependent, not as a schedule.

What the sources do support is the mechanism. A Texas Instruments forum contributor described the orphan process: when a sleeping end device loses its parent, it enters orphan status and sends rejoin or beacon requests to find a new parent; if a router answers, it joins that router and will not switch back to the original parent even after it returns. That is a description of the protocol’s rejoin path, not a promise about timing, and it is a forum answer rather than a specification. It does explain a pattern many people see: the device comes back on a different parent and stays there.

Triage: three branches, in order of invasiveness

The mistake to avoid is re-pairing first. Re-pairing destroys the evidence you need to know whether the device would have recovered on its own, and on some models it is the only thing that works — which means you learn nothing about the rest of your network.

Branch A — the device checks in on its own

Watch last_seen. If a new timestamp appears after the unplug, the device found a path. Record the elapsed time and the new parent from the network map. Do not generalize that number to other devices; it reflects this model’s wake schedule and this network’s router density. The useful output is a note: this sensor recovered in X, via router Y.

Branch B — the device is silent and you suspect a dead parent

First, rule out the boring explanations: dead battery, device out of range of every remaining router, or a coordinator that is itself unhealthy. Then trigger a report. On many models a button press causes a transmission, which is both a test and, on some devices, the event that prompts a rejoin attempt. The community reports above describe exactly this: Xiaomi sensors that stayed isolated until a button press. But the same thread includes a user for whom a short press did not help and only re-pairing worked. So treat the button press as a low-cost probe, not a guaranteed fix.

If a button press produces a check-in, you are done. If it produces nothing after a reasonable wait — and “reasonable” here means at least one full wake cycle for that model, which for a sleepy sensor can be hours — escalate to re-pairing. Re-pairing is the documented remedy for the models that never reseek a parent.

Branch C — the network is at capacity

If devices are failing to rejoin even though routers are present, check whether those routers are full. Each router has a finite child capacity, and the Zigbee2MQTT issue thread includes a contributor noting that a device will keep trying to find a path to the coordinator but fail if capacity is exhausted, with the fix being more routers rather than repeated re-pairing. ZHA’s documentation makes the same structural point: “Zigbee networks depend heavily on having multiple Zigbee Router devices to expand coverage and increase device capacity.” If you have one router covering a floor, unplugging it is not a mesh-healing test; it is a capacity test you will fail.

A repeatable procedure

1. Baseline. Enable availability and last_seen in Zigbee2MQTT, or confirm the ZHA unavailable windows are set to values that fit your sensors. Record the current parent of every battery sensor from the network map, with a timestamp.
2. Mark the event. Note the exact time you unplug the router. If you can, note which sensors were its children.
3. Do not expect an immediate offline flag. The passive timeout is measured in hours by design. An offline state within minutes is more likely a different fault than parent loss.
4. Watch last_seen, not adjectives. A new timestamp is proof of life. No new timestamp is not yet proof of orphaning.
5. Probe with a report. Trigger the device — a button press, a door opening, a forced report — and watch for a check-in. This is the least invasive escalation.
6. Wait one full wake cycle before concluding the device is stuck. For a sensor that reports every few hours, that means hours.
7. Re-pair only if the probe and the wait both fail. Note the model, because the outcome tells you whether this device class reseeks parents in your network.
8. Record the result. Elapsed time, new parent, and whether a probe was needed. That record is the only reliable healing timeline you will have — your own, for your models.

What this means for maintenance

The design property to accept is that every battery sensor is one unplug away from silence, and the mesh’s redundancy does not extend to the parent link. You cannot eliminate that; you can map it. Know which sensors depend on which mains routers, and set your availability thresholds so that a genuinely dead sensor is distinguishable from a sleeping one. If a sensor’s normal reporting interval is six hours, a six-hour unavailable window will produce false alarms; raise it, and accept slower detection of real failures.

There is also a case for not solving this with Zigbee at all. If a door sensor guards something that matters — a basement door, a medication cabinet — a battery radio with a single parent and model-dependent rejoin behavior is a weaker guarantee than a wired contact on a plain switch or a mechanical timer. The tradeoff is real: the Zigbee sensor is cheaper to install and easier to move, and it is less certain to report after its parent disappears. For low-stakes convenience, that is fine. For anything you would call an alarm, the documentation’s own caveats are a reason to prefer a path that does not depend on a sleepy device reselecting a parent.

If you are auditing which of your small systems quietly run your week, this parent-child mapping belongs in that inventory. The audit guide covers the broader method; the Zigbee-specific addition is to record, for each battery sensor, the router it depends on and the last time you verified it could recover without you.

FAQ

Does unplugging a router break the mesh permanently? No. Routers route for each other and the topology can reconverge. The failure mode is specific to battery end devices whose single parent was that router, and even then many will rejoin on their own. The uncertainty is in the timing and in whether a given model reseeks at all.

Why didn’t Home Assistant show the sensor as offline right away? Because the default unavailable window for battery devices is long — six hours in ZHA, 25 hours in Zigbee2MQTT’s availability feature — precisely because sleepy sensors are silent by design. An immediate offline flag would be wrong most of the time.

Is last_seen the same as availability? No. Availability is a derived online/offline state with a threshold; last_seen is a raw timestamp. Use last_seen to build a timeline and availability to alert. In Zigbee2MQTT both are off or disabled by default and must be turned on.

Do all Xiaomi sensors refuse to find a new parent? The Zigbee2MQTT documentation says some models, notably Xiaomi, do not attempt to find a new parent and remain isolated until re-paired. Community reports are not uniform — some describe a button press as sufficient, one describes only re-pairing working. Treat it as model-specific and test your own devices rather than assuming.

Should I just add more routers? If your problem is capacity or coverage, yes — that is the structural fix. If your problem is a single sensor that will not reseek a parent, more routers will not change its firmware behavior. The two fixes address different failures.