How Do XBee Routers Sleep When the Coordinator Is Off?

On the panel or API host, the coordinator disappears, incoming samples stop, and the four remote nodes continue trying to send every 50 ms. Their radios stay active because they are routers. Cutting coordinator power cannot send a final sleep command, and a powered-down coordinator cannot later transmit a wake command.

Start with the transmit result at each remote node. That reading separates a coordinator outage from a local radio, route, or application fault.

Read the transmit status first

Capture the ZigBee Transmit Status frame type 0x8B for every outgoing API transmission. Do not infer coordinator state only from missing application replies; an application can stop responding while the RF path still works.

A likely failure value for the coordinator-off condition is 0x24. Branch on success versus failure rather than coding the entire design around that one value: log the actual status produced by the installed radios and use the product documentation to decode it.

Do not react to one failed transmission. RF retries and route repair can produce isolated failures while the coordinator remains available. Use consecutive results or a time-based loss decision selected from the application's acceptable detection delay. Record the threshold instead of hiding it in logic.

Prove that the coordinator is unavailable

Take two readings: the sequence of 0x8B results and the coordinator power state during a controlled test.

1. Run the network at its normal 50 ms sample interval and confirm successful delivery from all four remote nodes.
2. Remove coordinator power in the same way used by the operator.
3. Record when each remote node begins returning failed transmit statuses.
4. Restore coordinator power and record when each node first reports success again.

If all four nodes change from success to repeated failure with the power event, use transmit status as the local coordinator-availability signal. If failures start independently of that event, fix the network path first. Sleep logic would conceal the underlying communication fault and make recovery slower.

A broadcast, application acknowledgement, or orderly shutdown message is not a dependable trigger here. Direct power removal gives the coordinator no time to send it. Repeating transmissions every 50 ms after loss also wastes energy without creating a route to an unpowered destination.

Decide whether each node must remain a router

That is the architectural branch. ZigBee routers normally remain awake because they may forward traffic for other nodes. A sleeping router cannot relay frames while its radio is off.

• If a remote node only reports its own samples, make it an end device and use its supported sleep behavior.
• If it must forward traffic for another node, keep the router role and control its activity from the local host.
• If a downstream node depends on it, do not remove power indefinitely. The downstream path will remain broken even after the coordinator returns.

Converting a router to an end device changes network behavior, not merely a power flag. Verify parent availability, rejoining, and application latency for the installed topology. Read the applicable sleep and network-role settings from the module documentation; no universal parameter values follow from API mode alone.

Trying unrelated coordinator API commands wastes time. The coordinator cannot command sleeping or unpowered radios, and it cannot announce shutdown after its supply has already disappeared.

Select the local fallback action

Once repeated transmit failures declare the coordinator unavailable, choose one of three local actions.

• Reduce the reporting rate: keep the router awake for routing but stop generating samples every 50 ms. This saves host and transmit activity while preserving mesh service.
• Power-cycle the radio locally: remove radio power, wake it periodically, send a probe or normal sample, and inspect the returned 0x8B status.
• Use end-device sleep: let the node wake from its own timer, test communication, and return to sleep after failure.

No coordinator-originated signal can wake a radio whose receiver has no power. Recovery must start from a local timer, controller, or supported end-device wake source. If the sealed enclosure has no controllable supply and the existing router cannot sleep, this feature requires a hardware or network-role change.

Do not invent a fixed wake interval from the 50 ms reporting period. Select the interval from the permitted discovery delay and energy budget. Likewise, keep each trial awake long enough to join or restore routing and receive a definitive transmit result; measure that duration on the installed network.

Account for multi-hop recovery

Read which nodes recover first after coordinator power returns. Directly reachable routers can succeed before routers that require intermediate devices.

With locally power-cycled routers, recovery can form a cascade. An intermediate router must be awake before a farther node can rebuild a path through it. If the farthest node repeatedly wakes while its intermediate router is off, it may never see a successful delivery even though the coordinator is running.

• If every router reaches the coordinator directly, each node can make its own availability decision.
• If nodes use other routers as hops, keep forwarding routers awake or coordinate their local wake windows.
• If topology changes during operation, verify recovery from each expected physical location instead of relying on a bench test.

Do not treat a failed probe immediately after coordinator startup as proof that it is still off. Network formation and route restoration occur before application traffic becomes dependable. Continue the low-duty retry policy until a successful transmit status proves that the path is usable.

Apply the control sequence and verify it

1. Log 0x8B for each outgoing frame while operating normally.
2. Declare coordinator loss only after the chosen consecutive-failure or elapsed-time threshold.
3. Stop the 50 ms sample stream.
4. For required routers, either retain low-rate operation or remove power under local control. For end devices, enter the supported sleep state.
5. Wake locally at the selected interval and transmit one probe or application sample.
6. If its transmit status fails, return to the low-power state.
7. If its transmit status succeeds, keep the node awake and restore the 50 ms sampling behavior.

Verify four transitions: normal delivery, coordinator power loss, sustained low-power behavior, and automatic recovery after power restoration. Repeat the test for each remote node. For a multi-hop layout, begin with all remote radios in their low-power state and confirm that intermediate routers recover early enough for the farthest nodes to regain successful status.

Also test a temporary RF interruption while coordinator power remains on. The node should enter the same conservative fallback state, retry locally, and recover without manual access to the sealed enclosure.

FAQ