Page 1 of 1

Zigbee SDK action_handler does not have addressing information

Posted: Tue Apr 29, 2025 2:01 pm
by jdurkan
Hi all,

When I send a command using esp_zb_zcl_read_attr_cmd_req, for instance, the response is received by the registered action handler. What happens if I call esp_zb_zcl_read_attr_cmd_req multiple times to read attributes from multiple devices in turn. Say I have a bunch of lights and I want to request from each of the them their current brightness setting. How would that be done? I would have expected that I would be able to issue a bunch of requests and have asynchronous replies from each light carrying the requested brightness attribute value as well as information indicating which device is replying.

The registered action handler does not include any parameter containing information about the source of the messages it receives. The underlying ZBOSS sdk does have this information so someone decided to not forward that information. Why? Is this not useful, important even?

Right now all I can do is wait after each call to esp_zb_zcl_read_attr_cmd_req until the reply comes back before I send the next request to the next device. If there are lots of lights in the network this will take far too long.

Any help is much appreciated.

/J

Re: Zigbee SDK action_handler does not have addressing information

Posted: Wed Apr 30, 2025 9:23 am
by jdurkan
After digging deeper that I expected, I discovered the root of my problem. It turns out that there are two possible parameter types provided to the action handler and I missed the second type.
The following is the text from the SDK docs. The first type, with the esp_zb_device_cb_common_info_t member does not have the addressing information. This type, however, is not the one that is provided when reading from remote peers. The second one is the one that is used and it does contain addressing information.
The callback ids without CMD in their names would provide messages of the following structure:

typedef struct xxx_message_s {
esp_zb_device_cb_common_info_t info;
...
} xxx_message_t;

While the callback ids with CMD in their names would provide messages of the following structure:

typedef struct xxx_message_s {
esp_zb_zcl_cmd_info_t info;
...
} xxx_message_t;
Hope this helps others who might similarly have been caught out.
/J