ESP32-H2 sleep mode consumption (TZ-296)

[diazmanuel]

Hello!
I am trying to work with the H2 chips in low power mode and I am encountering the following consumption situations

When the chip wakes up due to the KEEP_ALIVE configured at 4000ms it presents a strange behavior. As seen in the image, the chip's current consumption skyrockets (which is understandable) but it remains too long at a consumption of 20ma. During this consumption, the signal ESP_ZB_COMMON_SIGNAL_CAN_SLEEP is generated multiple times.
the handler of the ESP_ZB_COMMON_SIGNAL_CAN_SLEEP signal is as follows

    case ESP_ZB_COMMON_SIGNAL_CAN_SLEEP:
            ESP_LOGI(TAG, "Zigbee can sleep");
            esp_zb_sleep_now();
    ESP_LOGI(TAG, "wake up cause %d", esp_sleep_get_wakeup_cause());
        break;

As seen in the following log, when the consumption is at 20ma it prints the following

On the other hand, when I read or write via Zigbee, the current consumption presents a replica. In the following image you can see the first consumption corresponding to a reading (which has a high consumption) and a short time later the consumption increases again as if it were a "replica" for some reason

Could you help me with these problems?

Thank you so much

[kelin6]

@diazmanuel I've looked at your log, and it seems that the sleep threshold is set very small, just a few milliseconds. Could you increase the threshold using esp_zb_sleep_set_threshold according to README ? Indeed, during the initial network setup phase of the device, there can be prolonged periods of 20mA current. However, once the network stabilizes, this phenomenon is rarely observed. I will continue to investigate the issue of prolonged 20mA current during the device's initial network entry.

There are recurring replica of 100mA current, which appear to be related to Zigbee packet retransmission. This might occur because the packets sent may not receive an acknowledgment from the other side, leading to retransmission. The 100mA current is primarily during the packet sending phase.
Could you provide a detailed description of the reproduction process?

[diazmanuel]

@kelin6 About the esp_zb_sleep_set_threshold threshold, this would only generate the CAN_SLEEP signal being called fewer times, but the problem is that immediately after falling asleep it wakes up. I understand that this threshold only works to guarantee that the chip stays awake for a minimum amount of time.

After analyzing the code I was able to identify the problem, this was occurring due to the log, because the ESP_LOGI() function does not print directly as a print() would do, but instead sends a data to the queue of a task in charge of this action, the chip wakes up immediately after falling asleep since this logging task tells it requires printing, after printing it returns to the CAN_SLEEP handler and went into a sleep and print loop.

I suggest that you put a warning in the example since the same log of the example generates this effect of high consumption and looping

[kelin6]

@diazmanuel Thank you very much for your advice, but at the moment, I haven't encountered the issue of excessive UART printing causing power consumption problems. So, this seems similar to the previous problem sleep replica issue.

Anyway, it appears that this issue has been resolved for now. If you come across any new findings, please do let us know. Thank you.

[diazmanuel]

okey i will reopen this issue if i find something