High Power Consumption of Zigbee SED After Parent Loss – Need Guidance on Controlling Polling and Rejoin Behavior

Hello Nordic Support Team,

I’m developing a Zigbee-based light switch using a Sleepy End Device (SED) configuration with ZBOSS. I've encountered a critical issue related to power consumption after the parent (coordinator/router) becomes unavailable.

Here’s a detailed description of the behavior:

  1. When the SED loses connection to its parent, it initiates around 10 Data Request attempts, each repeated 3 times.

  2. After that, the device continues consuming approximately 4 mA, presumably because the radio remains in an active state.

  3. During this period, I observe repeating ZB_BDB_SIGNAL_DEVICE_REBOOT signals with decreasing frequency.

  4. Eventually, the stack reports ZB_BDB_SIGNAL_TC_REJOIN_DONE with an error (status -1), but the device remains in the high-power state (~4 mA).

  5. If I power on the coordinator later, the device does not reconnect automatically. Only after pressing a button on the SED (which triggers a report or bind), the power consumption drops to ~10 µA and I receive ZB_SIGNAL_JOIN_DONE.

During high current draw, ZB_COMMON_SIGNAL_CAN_SLEEP continues to be emitted regularly. I respond with:

ZB_ERROR_CHECK(zigbee_default_signal_handler(bufid));
After ZB_BDB_SIGNAL_TC_REJOIN_DONE with failure, I additionally try:
zigbee_configure_sleepy_behavior(true);
zb_set_rx_on_when_idle(ZB_FALSE);
zb_sleep_now();

However, this doesn’t seem to reduce current consumption.


My use case:

  • The switch doesn’t need frequent polling — it only needs to notify the parent when a button is pressed.

  • If polling could be disabled entirely (or minimized), and binding/reporting used when needed, I could achieve much better battery life.

  • Unfortunately, due to the above behavior, a power outage longer than 24 hours fully drains the battery, as the device never re-enters deep sleep.

  • This makes the current implementation impractical in real-world deployments (e.g., leaving home over a weekend).


My question:

Is there a supported way in ZBOSS to:

  • Change or disable the polling/rejoin behavior after parent loss?

  • Manually handle parent loss (e.g., catch ZB_ZDO_SIGNAL_LEAVE with ZB_NWK_LEAVE_TYPE_NO_PARENT) and prevent the stack from entering the high-consumption state?

  • Fully control radio and sleep state after failed rejoin attempts, to allow the SED to stay in deep sleep until user interaction?

I’ve already used ZB_AF_SET_ENDPOINT_HANDLER() in other parts of the app and I’m open to handling parent loss manually if possible.

I would appreciate any guidance, workarounds, or configuration options to resolve this — or any hints on what ZBOSS constants or behavior could be overridden. I’m also willing to modify the default signal handler or extend stack behavior if needed.

Thank you very much in advance!

Best regards,
Andris Matveev
(Latvia)

Parents
  • Hello,

    I've encountered a critical issue related to power consumption after the parent (coordinator/router) becomes unavailable.

    This sounds to be expected. Without a parent, the ZSED can't maintain it's role as a sleepy end device.

    If I power on the coordinator later, the device does not reconnect automatically. Only after pressing a button on the SED (which triggers a report or bind), the power consumption drops to ~10 µA and I receive ZB_SIGNAL_JOIN_DONE.

    This is also expected since it is how the firmware is written.

    https://docs.nordicsemi.com/bundle/addon-zigbee-r23-latest/page/lib/zigbee_app_utils.html#zarco-network-rejoin One option is to not call start_network_rejoin() if you loose the connection with the parent and/or the device fall outside of the network, or you can call stop_network_rejoin() to stop the procedure. In this case you can always turn of the radio manually either through the 802.15.4 driver or zigbee related APIs (if there exists one for this purpose).

    W.r.t your first question, you can increase the sleep threshold https://docs.nordicsemi.com/bundle/addon-zigbee-r23-latest/page/lib/zigbee_app_utils.html#zigbee_stack_sleep_routines 

    Kind regards,
    Andreas

  • Dear Andreas,

    Thank you for your prompt and helpful reply.

    I’d like to clarify my situation and ask a follow-up regarding the possibility of reducing power consumption after parent loss, ideally without modifying the SDK internals.


    Wrench My current setup and findings:

    • I’m using a Zigbee Sleepy End Device (SED) powered by a small battery.
    • Polling every 5 seconds is acceptable in my use case; I do not plan to increase the polling interval.
    • The device functions as a light switch and primarily needs to notify the coordinator on button presses. However, it must also be available to respond to attribute reads, binding, reporting, interview, FOTA, and similar requests from the coordinator.
    • I understand that once the parent is lost, the device can no longer maintain SED behavior and enters a rejoin procedure — but I want to avoid unnecessary energy consumption in this case.

    test tube Power trace analysis (see attached screenshot):

    I’ve recorded the device’s current draw during the event and divided it into five zones:

    First green zone
    The device loses its parent and performs 12 data request attempts. This is expected and the current consumption is acceptable.

    Yellow zone
    After the final attempt, the current draw rises to ~4 mA.
    After ~500 ms, I receive multiple ZB_BDB_SIGNAL_DEVICE_REBOOT signals.
    At the end of this phase, a failed ZB_BDB_SIGNAL_TC_REJOIN_DONE event is received, and the device stops transmitting anything over the air — but power consumption remains high, which I’d like to avoid.

    Red zone
    I power on the coordinator again and send requests to the switch, but it does not respond or reconnect. Current consumption still remains ~4 mA.

    Purple zone
    I press a button on the switch, triggering a Zigbee message. Only then does the device reconnect and resume normal behavior.

    Final green zone
    The device returns to low-power mode (~10 µA), as desired.

    Question My question:

    • You mentioned calling stop_network_rejoin() as a possible solution. However, when I attempt to call this function directly in my application, I get a compilation error — the symbol is not declared.
    • Before I resort to patching the SDK or copying internal logic, may I ask:
    • Is there a supported way to stop or influence the rejoin process from application code, or at least hook into the logic to prevent high power consumption?
      (It’s not critical to stop rejoining — but I want to avoid unnecessary current draw while it’s happening or after it fails.)
    • Alternatively, can I use the ZB_BDB_SIGNAL_TC_REJOIN_DONE event with failure status to shut down the radio and enter deep sleep (timer- or button-based wakeup), as a workaround?

    Dart My goals:

    • Avoid increased power consumption after losing the parent.
    • Resolve the issue without modifying the Zigbee SDK or internal symbols, if possible.
    • Maintain SED behavior and long battery life, even in case of prolonged disconnection (e.g., weekends).
    • Thank you again for your support and detailed suggestions.
      I’m open to further advice and can share more traces or source code if needed.

    Best regards,
    Andris Matveev
    Latvia

Reply
  • Dear Andreas,

    Thank you for your prompt and helpful reply.

    I’d like to clarify my situation and ask a follow-up regarding the possibility of reducing power consumption after parent loss, ideally without modifying the SDK internals.


    Wrench My current setup and findings:

    • I’m using a Zigbee Sleepy End Device (SED) powered by a small battery.
    • Polling every 5 seconds is acceptable in my use case; I do not plan to increase the polling interval.
    • The device functions as a light switch and primarily needs to notify the coordinator on button presses. However, it must also be available to respond to attribute reads, binding, reporting, interview, FOTA, and similar requests from the coordinator.
    • I understand that once the parent is lost, the device can no longer maintain SED behavior and enters a rejoin procedure — but I want to avoid unnecessary energy consumption in this case.

    test tube Power trace analysis (see attached screenshot):

    I’ve recorded the device’s current draw during the event and divided it into five zones:

    First green zone
    The device loses its parent and performs 12 data request attempts. This is expected and the current consumption is acceptable.

    Yellow zone
    After the final attempt, the current draw rises to ~4 mA.
    After ~500 ms, I receive multiple ZB_BDB_SIGNAL_DEVICE_REBOOT signals.
    At the end of this phase, a failed ZB_BDB_SIGNAL_TC_REJOIN_DONE event is received, and the device stops transmitting anything over the air — but power consumption remains high, which I’d like to avoid.

    Red zone
    I power on the coordinator again and send requests to the switch, but it does not respond or reconnect. Current consumption still remains ~4 mA.

    Purple zone
    I press a button on the switch, triggering a Zigbee message. Only then does the device reconnect and resume normal behavior.

    Final green zone
    The device returns to low-power mode (~10 µA), as desired.

    Question My question:

    • You mentioned calling stop_network_rejoin() as a possible solution. However, when I attempt to call this function directly in my application, I get a compilation error — the symbol is not declared.
    • Before I resort to patching the SDK or copying internal logic, may I ask:
    • Is there a supported way to stop or influence the rejoin process from application code, or at least hook into the logic to prevent high power consumption?
      (It’s not critical to stop rejoining — but I want to avoid unnecessary current draw while it’s happening or after it fails.)
    • Alternatively, can I use the ZB_BDB_SIGNAL_TC_REJOIN_DONE event with failure status to shut down the radio and enter deep sleep (timer- or button-based wakeup), as a workaround?

    Dart My goals:

    • Avoid increased power consumption after losing the parent.
    • Resolve the issue without modifying the Zigbee SDK or internal symbols, if possible.
    • Maintain SED behavior and long battery life, even in case of prolonged disconnection (e.g., weekends).
    • Thank you again for your support and detailed suggestions.
      I’m open to further advice and can share more traces or source code if needed.

    Best regards,
    Andris Matveev
    Latvia

Children
No Data
Related