Open susch19 opened 9 months ago
xieqinan
commented
8 months ago @susch19 ,
Could you please attempt to set the channel_mask to ESP_ZB_BDB_CHANNEL_SET_MASK_MINIMUM (only a single channel) and retry again? About 2 seconds are spent on the channel scan when the device rejoins, if you set the channel_mask to ESP_ZB_BDB_CHANNEL_SET_MASK_MAXIMUM.
nomis
commented
8 months ago Is there an API get the channel of the network that an end device has previously been registered on?
Perhaps it could avoid a channel scan on startup if the network is reachable on that channel?
susch19
commented
8 months ago @xieqinan
I actually don't know what you mean with ESP_ZB_BDB_CHANNEL_SET_MASK_MINIMUM, since I can't find it anywhere.
So I just put a single channel inside primary channel and than all channels into secondary.
Now the Bootup Time is roughly 1.2 seconds
I (463) main_task: Returned from app_main()
I (464) ESP_ZB_SLEEP: ZDO signal: ZDO Config Ready (0x17), status: ESP_FAIL
I (467) ESP_ZB_SLEEP: Zigbee stack initialized
I (1214) ESP_ZB_SLEEP: Device started up in non factory-reset mode
I (1215) ESP_ZB_SLEEP: Device rebootedThat's already better, but still double the time the logs of the deep sleep sample take. I would've never guessed, that the end device doesn't remember the channel, because the coordinator does, and the end device could always just try the last known channel, before falling back to the primary and secondary channel configs.
Could I have analyzed since myself without just changing things and hoping for a better result? Or are the inner workings of the Zigbee stack not analyzable for us, except for the log lines that are printed at the beginning?
xieqinan
commented
7 months ago @susch19 ,
That's already better, but still double the time the logs of the deep sleep sample take. I would've never guessed, that the end device doesn't remember the channel, because the coordinator does, and the end device could always just try the last known channel, before falling back to the primary and secondary channel configs.
I have checked the reboot process of the ZBOSS stack and found that it scans channels based on the channel_mask set by the user for rejoining the network. This method seems to trigger the above issue, and it appears to conflict with the Zigbee BDB spec. I will confirm this with the relevant staff members to ensure accuracy.
Could I have analyzed since myself without just changing things and hoping for a better result? Or are the inner workings of > > the Zigbee stack not analyzable for us, except for the log lines that are printed at the beginning?
We plan to provide more logs for users, and I expect this feature to be released within the next two versions. Additionally, the ESP-Zigbee-SDK offers a development mode specifically designed for debugging purposes. You can refer to the documentation for more information on enabling debug mode and trace logging.
Question
How can I analyze, why my ESP32-C6 End Device takes so long during boot up? From multiple logs in this repository I saw, that the bootup should require less than a second after reset or deep sleep. But no matter what I try, the "Device rebooted" Message always takes 3 seconds to appear. I tried multiple samples, multiple Coordinators, and different SDK Configs, but nothing changed the outcome at all.
The Coordinator doesn't have this problem, so restarting the coordinator, everything is finished and command successfully send after just 501ms, with no variation.
I'm testing with an ESP32-C6-WROOM-1-N8
I also tried it with the following combinations:
Additional context.
Sample Output of 5.1.2
Output of 5.3:
Sample of Coordinator Reboot with 5.1.2: