Raw Command Handler Not Triggered After Update to Version 1.5.0 (TZ-1102)

ahmetcobanoglu commented 2 months ago

Answers checklist.

[X] I have read the documentation ESP Zigbee SDK Programming Guide and tried the debugging tips, the issue is not addressed there.
[X] I have updated ESP Zigbee libs (esp-zboss-lib and esp-zigbee-lib) to the latest version, with corresponding IDF version, and checked that the issue is present there.
[X] I have searched the issue tracker for a similar issue and not found a similar issue.

IDF version.

v5.1.3

esp-zigbee-lib version.

1.5.0

esp-zboss-lib version.

1.5.0

Espressif SoC revision.

ESP32-H2

What is the expected behavior?

After registering a raw command handler using esp_zb_raw_command_handler_register, the handler should be triggered whenever a new message arrives. This was functioning as expected in versions prior to 1.5.0.

What is the actual behavior?

Starting with version 1.5.0, the registered raw command handler is no longer triggered when a new message is received. This issue persists despite confirming that the handler registration completes successfully. Additionally, the gateway endpoint was registered without a client cluster, which may be contributing to the problem.

Steps to reproduce.

Register a raw command handler using esp_zb_raw_command_handler_register.
Register a gateway endpoint without a client cluster.
Send a new message to the ZB coordinator (our device).
Observe that the handler is not triggered. ...

More Information.

The issue started occurring after the update to version 1.5.0. The handler was functioning correctly in previous versions. The raw command handler is used specifically because manufacturer-specific attributes of common clusters do not trigger ESP_ZB_CORE_REPORT_ATTR_CB. There are no apparent error messages during registration or message receipt.

AttributeReportwithManufCode

xieqinan commented 2 months ago

@ahmetcobanoglu ,

Regarding this issue, I believe it is triggered by the new optimization in v1.5.0, where we moved the attr_report handler before the raw_command handler. This change allows the gateway endpoint, even without a client cluster, to handle the attr_report command.

The new message (attribute report) received by the coordinator will trigger the ESP_ZB_CORE_REPORT_ATTR_CB_ID callback, which you can handle within this callback.

ahmetcobanoglu commented 2 months ago

The string length of the attribute report sent from the sensor is incorrect. I need to work around this error. Since the callback is not triggered, I think the message is dropped after the attr_report handler. In the image I added, you can see the message from the APS layer and the message sent to the ESP_ZB_CORE_REPORT_ATTR_CB_ID callback. The attribute with id 0xFF01 dropped. @xieqinan

xieqinan commented 2 months ago

@ahmetcobanoglu

The string length of the attribute report sent from the sensor is incorrect. I need to work around this error.

From the image you provided, it looks like the sensor is reporting data with a string type, and the length is 0x15, which seems incorrect. You are expecting to receive the complete string from the sensor, right? If that's the case, you can modify the APS data for this attribute of the cluster on the specific endpoint as a workaround. For example, asdu[8] = asdu_length - 8;. As a result, the ESP_ZB_CORE_REPORT_ATTR_CB_ID callback can report the all data from the sensor.

ahmetcobanoglu commented 2 months ago

@xieqinan I applied workaround by modifying ASDU data in APS data indication handler but ESP_ZB_CORE_REPORT_ATTR_CB_ID is still not called for attribute 0xFF01. You can see the log output of the corrected APS frame in the image I will add below.

ahmetcobanoglu commented 2 months ago

From the image you provided, it looks like the sensor is reporting data with a string type, and the length is 0x15, which seems incorrect. You are expecting to receive the complete string from the sensor, right? If that's the case, you can modify the APS data for this attribute of the cluster on the specific endpoint as a workaround. For example, asdu[8] = asdu_length - 8;. As a result, the ESP_ZB_CORE_REPORT_ATTR_CB_ID callback can report the all data from the sensor.

@xieqinan Actually, the attribute with the incorrect length is not the one you mentioned. The second reported attribute with id 0xFF01 in the same message is reported with an incorrect length.

xieqinan commented 2 months ago

@ahmetcobanoglu ，

My mistake, the APS indication's ASDU is a deep copy and does not affect the actual APS ASDU. Another solution is to refactor the unexpected APS ASDU in zb_aps_data_indication_handler to correct it, then call esp_zb_aps_data_request() to send the correct APS ASDU to the device itself.

mw75 commented 2 months ago

This issue explains much of the struggle i have! Is there an estimate, when the root cause will be fixed @xieqinan ? How to downgrade dependencies and pin the version with idf.py?

chshu commented 1 month ago

@mw75 You can pin the version by changing the code here: https://github.com/espressif/esp-zigbee-sdk/blob/main/examples/esp_zigbee_HA_sample/HA_on_off_light/main/idf_component.yml#L3:

  espressif/esp-zboss-lib: "1.4.0"
  espressif/esp-zigbee-lib: "1.4.0"

chshu commented 1 month ago

@ahmetcobanoglu @mw75 The Raw command handler is a temporary solution, could you share what's your requirement that needs to handle the raw data? We can support the feature with the official data model APIs.

espressif / esp-zigbee-sdk