Zigbee Sleeping Configuration for Battery-Based Remote Implementation on nRF52840

Hi everyone,

Environment:

  • nRF Connect SDK v2.8.0
  • Light Switch example

I’m currently working on implementing a Zigbee Sleepy End Device (SED) for a battery-operated remote control using the nRF52840.

Requirements:

  1. The device should wake up from sleep mode upon a switch press and immediately serve its functionality.
  2. After waking up, the device should rejoin the Zigbee network and continue operating.

Current Progress:

  • I’m using the Light Switch example as the base.
  • I have successfully operated switches and joined the device to the Zigbee network.

Problem:

The current implementation results in high battery consumption, as I noticed that the system sleep mode is not enabled by default in this example.

Request for Guidance:

As I’m new to nRF development, I would appreciate any suggestions for:

  1. Examples or code snippets demonstrating Zigbee Sleepy End Device configurations.
  2. Documentation or guides specifically for enabling sleep modes in Zigbee applications using the nRF Connect SDK.
  3. Tips on optimizing battery life for such applications.

Rgeards,

Suresh

  • Hi Suresh,

    The Zigbee Light switch sample can run with SED behaviour if you boot the device while pressing button 3. Are you using the sample in the SED mode? If not, please see the relevant sample documentation here.

    If you want the application to configure the SED behaviour by default you can modify the sample to call the zigbee_configure_sleepy_behavior(true) function regardless of the state of button 3.

    For general information on SED behaviour and tips for saving more power, please see the Sleepy End Device behavior documentation. Since the light bulb sample has the SED behaviour enabled when booting while button 3 is pressed, further power saving steps can be taken to reduce the sleep current to ~1.8 uA. See the Power saving during sleep section to see those steps.

    Also refer to the sleep current table in the nRF52840 product specification for expected values for different sleep modes.

    Best regards,

    Maria

  • Hi  

    Thanks for your suggestions.

    I have now updated the SDK to version 2.9.0.

    Using the power-off API on a standalone device, I was able to reach ~5 µA. However, for the Zigbee remote-control use case this is not suitable, because on every wake-up cycle the ZED needs to reconnect and forward the packet.

    I also tested the suggested Zigbee Light Switch sample with sleepy mode enabled. In this SED configuration I am able to achieve around ~500 µA (power profiler image attached). With this value, the battery life is still not sufficient for the remote-control application.

    Could you please confirm whether ~500 µA is the expected baseline for the default ZED/SED example, or should we expect significantly lower consumption?

    Additionally, I am enabling Bluetooth for onboarding, then disabling it before Zigbee starts. This BLE onboarding phase consumes around ~8 mA, but after Zigbee joins successfully the idle current stabilizes at ~500 µA.

    For reference, I am using the following configuration:

    CONFIG_SERIAL=y
    CONFIG_RAM_POWER_DOWN_LIBRARY=y
    
    And the Zigbee initialization code:
    
    zb_set_ed_timeout(ED_AGING_TIMEOUT_64MIN);
    zb_set_keepalive_timeout(ZB_MILLISECONDS_TO_BEACON_INTERVAL(3000));
    zb_set_rx_on_when_idle(ZB_FALSE);
    
    zigbee_configure_sleepy_behavior(true);
    
    if (IS_ENABLED(CONFIG_RAM_POWER_DOWN_LIBRARY)) {
        power_down_unused_ram();
    }
    
    zigbee_enable();
    zb_secur_ic_set(ZB_IC_TYPE_128, s_test_install_code);
    
    

    Please let me know if additional configuration is required to reach the lower sleep current mentioned in the documentation, or if further optimizations are recommended.

    Thanks,
    Suresh

  • Hello,

    Maria is currently out of office. 

    Did you try to disable logging?

    I am seeing around 55µA using the attached light_switch sample from v2.9.0. I did some modiifications in prj.conf, as disabling logging (and setting the channel to a fixed channel, that I also do in the network coordinator sample, to reduce connection time).

    Additionally, I skipped the button check, and enabled low power mode in main.c. Have a look, and see what current consumption you are seeing.

    light_switch_lpn.zip

    Best regards,

    Edvin

Related