How a light sleep device wake up from sleep? (TZ-806)

[acha666]

Question

I'm checking this example, accroading to the example output, the device seems continue go into sleep and then wake up.

I saw esp_zb_sleep_now() is triggered when receiving ESP_ZB_COMMON_SIGNAL_CAN_SLEEP signal, that seems make the device sleep.

https://github.com/espressif/esp-zigbee-sdk/blob/1efb22b3ebd68c494534625aab2b140af3e0080b/examples/esp_zigbee_sleep/light_sleep/main/esp_zb_sleepy_end_device.c#L136

But why the device wake up so frequently? The only wake up source configured in file is the button gpio, I think.

Additional context.

No response

[susch19]

It gets woken up by the underling zigbee stack implementation. You can check the ED_KEEP_ALIVE define, which is used for the zigbee config. https://github.com/espressif/esp-zigbee-sdk/blob/1efb22b3ebd68c494534625aab2b140af3e0080b/examples/esp_zigbee_sleep/light_sleep/main/esp_zb_sleepy_end_device.h#L30

So whenever the sleep function is called, a specific timer is used for the next wake-up. It will not always be the maximum timeout, since different situation require different timeouts. For example during boot up or interviewing the device will wake up way more frequently, so that the communication can be completed in a timely fashion.

If you want the device to wake up even less than in the example you would have to call the zb_zdo_pim_set_long_poll_interval function. This defines how often the device should poll the parent for new message. If you set a value like 30000 the device will only wake up every 30s, if there is no other reason to wake up earlier that is. A higher polling rate may affect the correct function, because a message might time out, since the end device was offline for too long.

One thing i forgot to mention is: This is also the reason why you have to call the esp_zb_sleep_now function, because if you do it the non zigbee way, the device won't wake up and the zigbee communication will be broken

[acha666]

@susch19

Thank you for your explanation. But there is still one question for me: if I need to implement some extra function, e.g. sensor sampling or screen gui by lvgl, how should I modify the code? Would you mind posting some simple code examples?

Thank you.

[xieqinan]

@acha666 ，

Could you please provide more details about the implementation of sensor sampling? If it's not directly related to this issue, it might be better to open another issue to discuss it separately.

[acha666]

@xieqinan

Just a simple I2C temperature&humidity sensor like SHT4x. Currently, I'm working on a HA sensor project, and the device is powered by battery so the sensor will not take measurement continuously.

[xieqinan]

@acha666 ，

I think the temperature sensor is helpful for you to implement your temperature&humidity sensor in ZCL layer. and you can refer to https://github.com/espressif/esp-zigbee-sdk/issues/200#issuecomment-2071746221 to get the wake up way from I2C for light sleep device.

[acha666]

@xieqinan ,

Thank you very much. However, I am still not clear about the principles of light sleep in the ESP32 series.

From my understanding, in the light sleep example of this repository, the device enters light sleep when the Zigbee protocol stack throws the ESP_ZB_COMMON_SIGNAL_CAN_SLEEP signal, and is awakened by a timer to handle Zigbee protocol-related content.

Since my sensor implementation requires waking up and reporting once every certain interval (like one minute), I would like to ask:

1. Is it appropriate for the Zigbee protocol stack to wake up the device at a frequency of once per minute?
2. How should the sensor tasks, GUI tasks, and Zigbee tasks communicate with each other to ensure the device only enters sleep when all tasks are idle?

[xieqinan]

@acha666 ,

Is it appropriate for the Zigbee protocol stack to wake up the device at a frequency of once per minute?

It depends on your requirements; the frequency of waking up is not limited by the Zigbee stack. However, note that the maximum sleep time in the Zigbee stack is one day.

How should the sensor tasks, GUI tasks, and Zigbee tasks communicate with each other to ensure the device only enters sleep when all tasks are idle?

Regarding the issue, it is custom approache for application layer. For instance, if the device is a sleep device, you can adjust the priority of the Zigbee tasks. When other higher-priority tasks are idle, the RTOS can call the Zigbee task to run and put the device into sleep. By the way, the above approach serves only as a reference.

[acha666]

@xieqinan

Thank you again.

Another question is about how to make sure the device sleep and wake up in an accurate period(in this case, 1 minute perhaps), in order that the sensor task can take measurements just after the device wake up.

Maybe I can set zb_zdo_pim_set_long_poll_interval to 60000? But I think some internal logic of the zigbee stack will affect that period.

[xieqinan]

@acha666

Maybe I can set zb_zdo_pim_set_long_poll_interval to 60000?

If so. Typically, the device will wake up after 60000 ms under normal conditions if there are no other interrupts or events, such as scheduler events or interrupts from external. In summary, the Zigbee stack or external signals can affect the wakeup period, but I recommend testing it first and providing feedback with your test results.

[acha666]

@xieqinan

I noticed that the ESP-IDF documentation mentions an Auto Light-sleep mode. Is this mode used in Zigbee implementations? I ask because I saw that the CONFIG_FREERTOS_USE_TICKLESS_IDLE setting is enabled in the defconfig file of the related examples.

[xieqinan]

@acha666 ,

I noticed that the ESP-IDF documentation mentions an Auto Light-sleep mode. Is this mode used in Zigbee implementations?

Yes, you are right.

[acha666]

This is also the reason why you have to call the esp_zb_sleep_now function, because if you do it the non zigbee way, the device won't wake up and the zigbee communication will be broken

Is the auto light-sleep mode compatible with maintaining Zigbee connections?

I'm considering enabling it and simply using vTaskDelay to implement a 60-second wait after each operation. This approach might be more efficient than crafting custom sleep logic.