Replies: 8 comments 5 replies
-
|
Hi @fumanchi ,
Based on the information above, the |
Beta Was this translation helpful? Give feedback.
-
|
Hi @xieqinan , thanks for your response... So, the controller gets a checkin-request: And decides against fast-poll and send an appropiate response: But don't get the default response matching its response-request: So it is the endpoint which does not respond appropriately, isn't it? Thanx for your support! |
Beta Was this translation helpful? Give feedback.
-
|
Let's install a sinffer to identify which process is failing. The install steps can refer to https://docs.espressif.com/projects/esp-zigbee-sdk/en/latest/esp32/developing.html#sniffer-and-wireshark |
Beta Was this translation helpful? Give feedback.
-
|
I managed to get a sniffer up and running... Lets take a closer look ontot the poll control conversation: ... ... So, the default response from the endpoint on the coordinators checkin-response (from endpoint to coordnitor) has a "Failure" status :( Do you need more infos? |
Beta Was this translation helpful? Give feedback.
-
|
OK, based on the log above, I think the failure status may be triggered by the condition described in the ZCL specification: 
Could you please try using |
Beta Was this translation helpful? Give feedback.
-
|
I see... I did not manage to correctly bind my poll control cluster to any related endpoint (which is the coordinator aka zigbee2mqtt). There is no destination endpoint. I tried the following code but it crashes: In the end my coordinator (zigbee2mqtt) might not (at least not fully) support the cluster. Even though it succeeds to receive and decodes the incoming checkin request: and later intentionally declines fast polling: What i actually tried to accomplish using the poll control cluster is to make sure, the coordinator does not try to send "buffered" messages to my sleepy end device while its in deep sleep (with rx off). Doing this (so: sending messages to the sleeping endpoint) leads to timeouts and quite long backoff times (2 second). So waking up and joining the zigbee network takes about 3-5 seconds while I often get the first "buffered" message around another 2-3 seconds later. Even though the coordinator (now) receives the following ZDO response: |
Beta Was this translation helpful? Give feedback.
-
|
So, there are two questions: (1) a default response failure to the Poll Control Check-in Response, and (2) a long backoff time when the coordinator sends buffered messages to the sleepy device. Let’s focus on the second one:
Typically, a parent (coordinator) only sends messages to its sleepy children after receiving a request from them (e.g., a Data Request). I’m confused about why the coordinator would attempt to send messages during the device’s rejoin process. Could you please share the complete sniffer capture (in .zip) for analysis? |
Beta Was this translation helpful? Give feedback.
-
|
Hi @xieqinan here's the dump you asked for: To achieve the sniffed conversations and logs above. I manually triggered some commands (open/close/stop) of the window covering cluster the endpoint exposes while its asleep :) In case the dump is still encrypted, I used the following zigbee_pc_keys: |
Beta Was this translation helpful? Give feedback.
-
|
Based on the sniffer log, everything works fine except for the default response failure to the Poll Control Check-in Response. Let’s summarize this issue again: You intend to use the Poll Control cluster to adjust the poll rate of the sleep device in order to reduce the rejoin time when it wakes up, correct? Are you sure that the 2-second backoff is caused by a buffered message from the coordinator? It might actually be triggered by an incorrect configuration on the sleep device (for example, scanning all channels). From what I observed in the log, the time from the Rejoin Request to the Device Annce is only about 0.5 seconds, which is normal. |
Beta Was this translation helpful? Give feedback.
-
|
I am sure it's the backoff time after a failing message/command delivery due to the end points deep sleep... the esp's "uptime" is around 3 secs when it successfully rejoins. But the first messages (depending on the timing) might be received another 2-3 seconds later as the coordinator still waits for its retry. Sometimes messages even gets lost or send some seconds after the next rejoin. I decided to use the poll control cluster capability to ensure the coordinator does not send anything but waits for a poll request. |
Beta Was this translation helpful? Give feedback.
-
|
Sorry, I’m still a bit confused by your question. I need to confirm your issue again. The root of issue is not related with the poll control cluster. You think that a “buffered message” from the coordinator increases the rejoin time for the sleep device, and you expect to reduce this time to lower power consumption. Could you please point out which “buffered message” is triggering the backoff? From what I see, everything looks normal—the coordinator only sends messages after it receives a Data Request. 
|
Beta Was this translation helpful? Give feedback.
-
|
Not exactly... I do not think that the rejoin time changes due to pending/buffered messages... the rejoin time itself is quite consistent... but pending messages will not be send right after rejoining but after some backoff time as the coordinator tried to send them while my end device was asleep. So I tried to ensure that the coordinator always waits for the end device polling for its messages by utilizing the poll control cluster. I expected (if everything is set up correctly) the coordinator then does not try to send message while the endpoint is in deep sleep but waits for the device to send its poll control cluster checkin request. Lets take a look into the logs... maybe I can clear up things by pointing out the lines. The following lines of Zigbee2MQTT log shows the coordinator gets some "set" commands via MQTT and enqueues corresponding requests (here: window covering cluster messages) into the endpoints sending queue: Later, the coodinator finds its request has not been answered correctly (reason: the end device was asleep) so it backs off and waits for 2 seconds: After some retries, the device woke up and announced itself: The the coordinator received the devices checkin request and answers with its checkin response: And it takes about 2 precious seconds before the coordinator sends the pending window covering cluster commands: Afterwards the coordinator sends its pending checkin response message: Now the sniffer log of the conversation... It gets rejoin and checking messages: But it takes almost 3 seconds before the window coverage cluster (clusterid=0x0102) commands are send: Afterwards the checkin response will be send... so might have been enqueued in the sending queue even after the commands: |
Beta Was this translation helpful? Give feedback.
-
|
Understood. As you mentioned, the issue seems to originate from Zigbee2MQTT. |
Beta Was this translation helpful? Give feedback.
Uh oh!
There was an error while loading. Please reload this page.
-
I opened a new discussion on that topic as I was not able to reopen discussion #635.
@xieqinan closed the previous discussion as he implemented poll cluster support. But i still was not able to set up a sleepy endpoint with poll control :(
I do this to create and add the poll control cluster to the endpoints cluster list:
and
esp_zb_cluster_list_add_poll_control_cluster(cluster_list, esp_zb_poll_control_cluster_create(&zb_zcl_poll_cfg), SP_ZB_ZCL_CLUSTER_SERVER_ROLE);before
Then, when my device is safely joined (signal
ESP_ZB_BDB_SIGNAL_DEVICE_REBOOTorESP_ZB_BDB_SIGNAL_DEVICE_FIRST_START), i do:to send a check-in request to the coordinator (here zigbee2mqtt). I sadly get my registered action handler not called for the coordinators check-in response. And the zigbee-sdk does not (at least not transparently) react correctly on the response message, as far as the coordinator log suggests:
Could you please provide some hints or even an example how to correctly implement the now supported poll control cluster using the zigbee-sdk only? Or do i need to mix ZBoss and zigbee-sdk anyhow?
My current environment is:
But i am using the newest esp-zigbee-sdk (at least the esp-zigbee-lib is at 1.6.6):
Beta Was this translation helpful? Give feedback.
All reactions