Zigbee Poll Control Cluster

[tmihajloski]

Hi,

I am working with the Zigbee SDK on esp32h2 and I am trying to achieve low power operation and was hoping to use the poll control cluster to help me with the wake-up and sleep timing of the device. However, I noticed that the SDK does not provide the APIs to add and configure the cluster. I can manipulate other clusters, however, not the poll control.

Is this on purpose or a missing implementation?

Thanks!

[fumanchi]

I would like to add support for Poll Control as well. The ZBoss stack appears to provide at least some functionality related to the Poll Control cluster. However, we are unable to add the Poll Control cluster to our endpoint(s) because there is no function or symbol like esp_zb_cluster_list_add_poll_control_cluster available.

I’ve also consulted LLMs such as ChatGPT and Mistral, but they don’t have any relevant information on this either. Do you have any further insights or information regarding this issue?

[xieqinan]

Hi @fumanchi @tmihajloski,

The Poll Control cluster has not been supported in esp-zigbee-sdk v1.6.5 and is not currently included in the upcoming release plan. Unfortunately, there is no available workaround to enable this cluster at the moment.

If this cluster is essential and urgent for your project, please contact our technical support team for further assistance.

[fumanchi]

Re..

Thank you for you fast reaction on that issue.
I actually managed to at least make my esp32c6 announce the poll control cluster. I used the espressif ZBoss API and I do not (yet) know how to correctly write my attribute handler I managed to register. Is there some documentation or some examples available? I used zb_zcl_add_cluster_handlers(ZB_ZCL_CLUSTER_ID_ON_OFF, ZB_ZCL_CLUSTER_SERVER_ROLE, nullptr, nullptr, &on_off_cluster_cmd_handler); to get my on_off_cluster_cmd_handler called with a zb_uint8_t as argument which is a ZBoss buffer id. I would be happy for any assistance :)

[fumanchi]

Re...
I found, that the parameter of the cluster handler is actually a zb_bufid_t pointing onto the commands payload while it is still usable to make the makro ZB_ZCL_COPY_PARSED_HEADER parse the APS/ZCL headers. Sending a checkin message actually makes my zigbee2mqtt coordinator sending a checkin response with arguments as expected. If there are a hole lot of messages pending the checkin-response payload actually triggers fast-polling and if so, a fast-poll-stop command is send after all the pending messages are sent.
The only Problem left is, that the checkin response is queued after all(?) the pending messages. And if there are pending messages thee is a pause of about 2 seconds after a succeeding connecting before the first messages will be sent. If there are no pending messages the checkin-response will directly be sent by the coordinator (so w/o any pause/latency). Do you have any idea?

[xieqinan]

Hi @fumanchi ,

Using unsupported clusters (such as the Poll Control cluster) is not straightforward. I’m currently working on implementing support for the Poll Control cluster, and if everything goes well, it will be included in the next version to be released later this month.
Thank you for your patience.

[fumanchi]

Hi...
Great news. I am looking forward testing the cluster.

I will try to send polling commands after checkin and hopefully make my zigbee2mqtt coordinator to sent it's pending messages as fast as possible. In the end I want to let my esp32 sleep as soon as possible to safe energy...

[fumanchi]

I'm done... it doesn't seam to be possible to set the "rxOnWhenIdle" capability of the endpoint to "0" via zboss lib api. Which will normally be done by calling "esp_zb_set_rx_on_when_idle(ZB_FALSE);" using the zigbee lib api. So i hope you get the feature done...
it might be fine to have a working esp_zb_cluster_list_add_poll_controll_cluster or allow esp_zb_cluster_list_add_custom_cluster to add clusters of "known" cluster ids (here: ZB_ZCL_CLUSTER_ID_POLL_CONTROL).
If this capability is not set to "1", the coordinator always tries to push commands (e.g., on/off states I used for testing), even though I would have preferred to poll for them. When the endpoint is sleeping, the Zigbee2MQTT coordinator backs off for 2 seconds after each failed attempt, which results in a significant delay for the endpoint to receive all its pending messages after rejoining and checking in. :(