Unplug One Mains-Powered Bulb and Six Sensors Go Quiet: Watching a Zigbee Mesh Re-Route in Real Time

You unplug a lamp to move a chair. Within a few minutes, a door sensor, two motion sensors, and a temperature sensor stop reporting. The lamp is not on any automation that matters. The sensors are. This is the ordinary failure mode of a mesh network that depends on mains-powered routers: remove one router, and every end device currently parented to it loses its path to the coordinator.

The goal is not to prevent that outage. It is to measure how long the mesh takes to recover, confirm which devices actually moved, and avoid trusting automations until every affected sensor is reporting again.

Why one bulb can silence six sensors

Zigbee distinguishes between two roles. A Zigbee router device is always mains-powered, such as an outlet or a bulb. A Zigbee end device is typically battery-powered, such as a remote or a motion sensor. Routers pass messages to other nearby devices, which is how the mesh extends range and increases the number of devices a single coordinator can support. Zigbee networks depend heavily on having multiple router devices for exactly this reason (Home Assistant ZHA documentation).

When a battery sensor joins the network, it picks a parent — usually a nearby router. If that router disappears, the sensor has no direct path to the coordinator unless it can find another parent. Some end devices re-parent quickly. Some wait. Some stay stuck until they are re-paired or until a new router appears nearby.

That is the whole mechanism. The bulb was not special. It was simply the parent of record for those six sensors at the moment you unplugged it.

First instrument: the mains-powered unavailability timer

In ZHA, the default time after which a mains-powered device with no activity is considered unavailable is 7200 seconds (2 hours). The default for battery-powered devices is 21600 seconds (6 hours). Both are configurable under Settings > Connectivity > Zigbee > Options.

Two hours is a long time to wonder whether a bulb is dead or the mesh is re-routing. The ZHA documentation explicitly suggests lowering the mains-powered value — for example, to 3600 seconds (1 hour) — if you want faster detection when a plug or bulb loses power. That is the first tuning step I would make on any small mesh where a router loss is plausible.

Lowering the battery-powered timer is riskier. Sleepy sensors that only report when triggered can legitimately go quiet for hours. The documentation warns that raising this value prevents repeated false unavailability, and lowering it gives quicker notification when a battery runs out. Pick a number that matches how often your quietest sensor actually reports, not a number that sounds aggressive.

Second instrument: the network information page

Before you touch anything, record the baseline. ZHA’s network information page shows the channel, PAN ID, extended PAN ID, coordinator IEEE address, radio type, serial port, and baudrate. Channel is the only field you can change from that page; the rest are reference values you will want when comparing before and after.

Write those down. If you later move the coordinator, change the channel, or swap a radio, you will want to know what the network looked like when it was working.

Third instrument: the Zigbee2MQTT network map

If your stack runs Zigbee2MQTT rather than ZHA, the equivalent diagnostic is the network map. Send an MQTT request to the bridge topic zigbee2mqtt/bridge/request/networkmap to retrieve a map of the Zigbee network including routes (Zigbee2MQTT documentation).

The map is most useful as a comparison. A single map taken during the incident tells you which devices are currently orphaned. A map taken before and after a controlled outage tells you which end devices actually moved and which stayed stuck. The second comparison is the one that changes your maintenance plan.

What the map is telling you

Look for end devices whose previous parent is gone. Then look at where they are now. Three outcomes are possible:

• Re-parented to another router. The mesh recovered on its own. Note which router took over and whether it is in a sensible location.
• Still pointing at the missing parent. The device has not re-routed. It may recover eventually, or it may need help.
• Disappeared from the map entirely. The device may be offline, out of range, or in a state where it is not responding to route requests.

The distinction matters because the fix is different in each case. A device that re-parented needs no action. A device that is stuck needs either a new router nearby or a re-pair. A device that vanished needs a physical check before you assume the network is at fault.

When re-routing does not happen

Zigbee2MQTT notes that almost all AC-powered devices will serve as a router, with exceptions being most AC-powered relays that do not require a neutral wire. That exception is worth remembering: a smart switch without a neutral is not a router, no matter how convenient its location.

Zigbee2MQTT also warns that some routers are of mediocre quality and may not harmonize well with the network. Some versions of the SONOFF Smart Plug S26R2ZB are specifically called out as limited, and may yield message routing errors. If your mesh has one of those in a critical location, it is not a reliable parent.

The practical fix when a device stays stuck is to add a known-good router nearby and re-pair the affected device with Permit join restricted to that router. Zigbee2MQTT describes this approach directly: add additional routers of better quality and bind devices to them by re-pairing with Permit join restricted to the new or better router.

That is more work than moving a lamp. It is also more durable than hoping the mesh figures it out.

Broadcasts and why they matter here

Route discovery uses broadcasts. Zigbee2MQTT states that Zigbee can only sustain an average rate of 1 broadcast per second, and that multiple broadcasts within a short timespan increase latency. The same source recommends using broadcasts sparingly.

This is why a mesh that is already busy with group commands, Green Power devices, or frequent network management tasks may re-route more slowly than a quiet one. It is also why triggering a network map request during an incident adds traffic to a network that is already trying to recover. Take the map, then wait.

Coordinator placement is not a side issue

Both ZHA and Zigbee2MQTT warn against running the coordinator over Wi-Fi, WAN, or VPN. ZHA states that the coordinator requires a stable, local connection to its serial port interface without drops in communication with the Zigbee gateway application. Zigbee2MQTT notes that network adapters connected via Wi-Fi might have reduced stability because the serial protocol does not have enough fault-tolerance to handle packet loss or latency delays that can normally occur over Wi-Fi connections.

If your coordinator is on a USB extension cable a meter from the host, that is fine. If it is on a Wi-Fi bridge across the house, the mesh has a second single point of failure that has nothing to do with the bulb you unplugged.

A repeatable procedure

This is the sequence I would use on a small residential or small-office mesh. It assumes you can tolerate a brief controlled outage.

1. Record the baseline. Capture the ZHA network information page or request a Zigbee2MQTT network map while everything is working. Save it with a date.
2. Lower the mains-powered unavailability timer. In ZHA, set it to 3600 seconds if the default 7200 is too slow for your tolerance. Leave the battery-powered timer alone unless you have a specific reason to change it.
3. Choose a router to remove. Pick a mains-powered device that you believe is acting as a parent. Do not pick a device that is itself an end device.
4. Unplug it and start a timer. Note the time. Do not immediately re-plug it.
5. Watch the affected sensors. Check whether they report again, go unavailable, or simply stop updating without an unavailable state.
6. Request a network map after the unavailability timer has expired. Compare it to the baseline. Identify which end devices moved and which did not.
7. Re-plug the router. Wait for it to rejoin. Request another map.
8. Confirm every affected sensor reports again. Do not re-enable paused automations until you have seen fresh data from each one.

The point of the exercise is not to prove the mesh is fragile. It is to know which devices depend on which routers, and how long recovery actually takes in your space. That number is specific to your layout, your device mix, and your traffic. I have not seen a reliable published figure for re-route time that applies across networks, and I would be suspicious of anyone who gives one without measuring.

When a plain switch is the better answer

If the lamp you unplugged is in a location where people will unplug it regularly — a floor lamp by a chair, a table lamp on a switched outlet — it is a poor router. The mesh will lose it repeatedly, and you will keep diagnosing the same outage.

In that case, the smarter choice is a mechanical timer or a plain switch for the lamp, and a dedicated router in a location that does not get unplugged. A small mains-powered Zigbee outlet behind a piece of furniture that nobody touches is a better parent than a lamp that moves with the furniture.

This is not a failure of the mesh. It is a mismatch between the physical habits of the room and the assumptions of the network.

What to document

For each router in your mesh, record:

• Its location and what it is plugged into.
• Whether it is a known-good router or a device with a history of routing issues.
• Which end devices were parented to it at the last map.
• Whether it is on a circuit that gets switched off regularly.

That list is the difference between a mesh you understand and a mesh that surprises you. It also makes the next outage faster to diagnose, because you already know which sensors to check first.

If you want a broader audit of the small systems that quietly run your week, the approach in How to Audit the Small Systems That Quietly Run Your Week applies here: inventory what depends on what, then test the dependencies before they fail on their own schedule.

FAQ

How long should I wait before assuming a sensor will not re-route?

There is no universal number. The ZHA mains-powered unavailability timer defaults to 7200 seconds, and the documentation suggests 3600 seconds for faster detection. Use that as your observation window, then check the map. If the device has not moved by then, treat it as stuck.

Can I force a device to re-parent without re-pairing it?

Not reliably from the coordinator side. The practical method described by Zigbee2MQTT is to add a better router nearby and re-pair the device with Permit join restricted to that router. Some devices will re-parent on their own after a power cycle, but that is device-specific and not something to count on.

Does changing the Zigbee channel help with router loss?

No. Channel selection addresses interference from Wi-Fi and other 2.4 GHz devices. It does not change which parent an end device chooses or how quickly it re-routes after that parent disappears.

Will increasing coordinator transmission power fix this?

Not necessarily. Zigbee2MQTT notes that increasing transmission power can yield weird behavior if messages reach an end device but responses do not reliably reach the coordinator. A router in the right place is a more predictable fix than a louder coordinator.

Is a smart bulb a good router?

It can be, if it stays powered. The problem is not the radio; it is the human habit of unplugging lamps. If a bulb is in a location where it will be switched off or unplugged, it is a poor router regardless of its hardware quality.