read and write command request callback is not generated if the destination is not reached

[diazmanuel]

Answers checklist.

• I have read the documentation ESP Zigbee SDK Programming Guide and the issue is not addressed there.
• I have updated my IDF branch (master or release) and ESP Zigbee libs (esp-zboss-lib and esp-zigbee-lib) to the latest version and checked that the issue is present there.
• I have searched the issue tracker for a similar issue and not found a similar issue.

IDF version.

v5.1.1-588-gc1c843f5e2

esp-zigbee-lib version.

1.0.2

esp-zboss-lib version.

1.0.2

Espressif SoC revision.

ESP32-H6

What is the expected behavior?

the expected behavior is to ALWAYS generate a callback if a command request is made, in case the request cant reach the destination the generated callback must have a error status (esp_zb_zcl_status_t), for example a ESP_ZB_ZCL_STATUS_TIMEOUT status if the device is within the network but cant reach the destination for some time or a device not found if the mac address is not found.
But also generate the same list of attributes in the esp_zb_zcl_read_attr_resp_variable_t struct list as the one sent in the read/write attribute list command request. this is highly needed because is the only way i have to match the sent request with the callback because i do not have a sequence number to mach as mention in #135

What is the actual behavior?

the actual behavior is that the callback is not generated if the mac address is invalid (there is not in the zigbee network) or the destination device is disconnected from the network (i mean taking off the power of the device, but its still remain in the zigbee network).
in the other hand if i send a read attribute command request of an inexistent attribute the device crashes and restart. if i comment the registration of the handler (esp_zb_core_action_handler_register(zb_action_handler);) they do not crash, but of course the callback handler is not called . also this project is from a gateway so the clusters it have declared are not the ones trying to be read.

Steps to reproduce.

1. Step
2. Step
3. Step
   ...

More Information.

No response

[chshu]

We will add the send command request callback in next release, which will also address the issue #135

[simonborje]

We will add the send command request callback in next release, which will also address the issue #135

@chshu Hi, have the changes addressing this issue and issue #135 been released in any release since then or will that be part of a later release? I couldn't find any changes directly related to these issues in the latest releases but maybe I missed something.

[chshu]

We will add the send command request callback in next release, which will also address the issue #135

@chshu Hi, have the changes addressing this issue and issue #135 been released in any release since then or will that be part of a later release? I couldn't find any changes directly related to these issues in the latest releases but maybe I missed something.

It will be supported in the next release. The last version (1.0.6) mainly addresses some urgent requests from one customer.

[diazmanuel]

We will add the send command request callback in next release, which will also address the issue #135

hello @chshu could you explain me how does the new send command request callback works ? and in witch cases i have to use it ?

Will this callback solve the crashes of reading a non-existent attribute?

Will this callback be called only when the destination cant be reached?

[xieqinan]

Hello @diazmanuel ,

Firstly, you can utilize the esp_zb_zcl_command_send_status_handler_register() to register the ZCL send status command callback. It will return a message indicating whether the command was sent successfully. A transaction sequence number (TSN) is included in the message.

Secondly, when you call any ZCL command request, such as esp_zb_zcl_read_attr_cmd_req(), it will also return a TSN that can be used to match one in the first case.

Thirdly, the ZCL command response or default response message will also be received with the TSN. It can be used to determine which request the response is for.

[xieqinan]

Will this callback solve the crashes of reading a non-existent attribute?

If you use esp_zb_zcl_read_attr_cmd_req() to read an attribute, esp_zb_zcl_command_send_status_handler_register() will indicate whether the command was sent to the remote device, and esp_zb_core_action_handler_register() will provide the status of the reading with the flag ESP_ZB_CORE_CMD_READ_ATTR_RESP_CB_ID.

By the way, in which case does the crash occur when the attribute you read does not exist?

Will this callback be called only when the destination can't be reached?

Any ZCL command request that is sent will trigger the esp_zb_zcl_command_send_status_handler_register() callback.

[diazmanuel]

crashes when trying to read an attribute that does not exist on a surveyed device