-
Notifications
You must be signed in to change notification settings - Fork 25
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Raw Command Handler Not Triggered After Update to Version 1.5.0 (TZ-1102) #419
Comments
Regarding this issue, I believe it is triggered by the new optimization in v1.5.0, where we moved the The new message (attribute report) received by the coordinator will trigger the |
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 |
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, |
@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. |
@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. |
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 |
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? |
@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:
|
@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. |
Answers checklist.
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.
...
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.
The text was updated successfully, but these errors were encountered: