unable to write a "large" string (TZ-546) #202
Labels
Comments
github-actions
bot
changed the title
|
The upcoming version will support the frame fragment feature, which should meet the above requirements. It is scheduled for release later this week. |
|
Hello, @xieqinan, |
|
The simple implementation is as followed: |
|
hi @xieqinan ,Thanks for the reply, |
|
The writing and reading are the same with the custom cluster request, only if the data type of attribute is supported. |
|
but why can't I declare an attribute of type string in a custom cluster and write and read it with the esp_zb_zcl_write_attr_cmd_req() and esp_zb_zcl_read_attr_cmd_req() functions? The length of the string according to the Zigbee 3.0 standard is supposed to be at least 255 characters, but in practice when I try to write or read something longer than 40 characters it starts to have errors. I leave you a screenshot of the zigbee documentation
Is it possible to solve this problem so that the complete string can be used as indicated in the documentation? |
3 tasks
|
Large data for custom clusters, both reading and writing, is now supported in esp-zigbee-sdk v1.2.1. You can test this functionality using the |
hello, thanks you, we will test this update after fixing the error with the custom clusters #285 |
Hello, we still haven't been able to get it to work, depending on the message, some arrive well and others don't. Message 1: Message 2: Message 3: Message 4: Message 5: Message 6: Results: Each message was sent multiple times giving the same results, meaning that the messages that are truncated do so systematically and in the same place. Could you reopen this issue to follow up? thank you |
|
Hi, @diazmanuel , I have created a simple example to test this issue, which is attached here. Could you please also verify it? |
|
hello, @xieqinan On the other hand, in the coordinator, I replaced the way in which the character string is generated as follows: After sending the message from the coordinator, the endpoint receives the following message It was possible to observe that the string of characters is cut, and analyzing the print by bytes it is seen that some bytes at the end are found as split (0x45 0x4c 0x56 0x 0 0x 0 0x 0 0x 0 0x a 0x42 0x52 0x54 0x45 0x45 0x4e) , something strange that I cannot explain, and I do not understand how this case can occur but I interpret it as that the message was corrupted, which results in the last value read by the print or the log function being 0x, which it interprets as \0, meaning the end of the chain. This explains why I noticed that the chain was breaking, it could also explain why it sometimes crashed in my code but this requires further analysis. Another thing I noticed in your example is that if I modify the length of the message you originally sent, changing the CUSTOM_STRING_MAX_SIZE parameter to 150, the program crashes, I understand that because it is of type string it should be able to send up to 255 as specified by the standard, I don't know if there is a limitation on this topic Anyway here you can see that the data is being corrupted. |
|
hello, @xieqinan |
|
Could you update the esp-idf version to v5.1.3 for testing again? I also will test the examples provided by you and give you feedback ASAP. |
The issue has been confirmed as a stack issue, and we will fix it in the next release. The root cause of this issue is that the I/O buffer does not have sufficient capacity for the input data, resulting in data being overwritten at the end.
Have you made any modifications to the code I provided? I tested it with a length equal to 150 case, and it worked successfully. |
|
hello @xieqinan,
I'm glad to hear you were able to identify the problem.
No, the only changes I made were those I mentioned above, and I also used an H2 chip in one case and a C6 in the other. I think the only difference may be the versions of the SDK. In a previous comment I attached the modified project, there you can check the dependencies file. Anyway, I'll try it again and let you know if the error continues to appear. |
This issue has been fixed in the v1.2.3 version. Could you test it again? |
|
Thanks, we tried it and now it works correctly |
This was referenced May 7, 2024
|
I am wondering if it can be used with Arduino IDE, I am new to both Zigbee and ESP32H2 in general and I would like to used it for some projects, so is it possible . |
|
@diazmanuel any help I will be highly appreciated. |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Answers checklist.
IDF version.
v5.1.1-588-gc1c843f5e2
esp-zigbee-lib version.
1.0.7
esp-zboss-lib version.
1.0.7
Espressif SoC revision.
ESP32-H6 and ESP32-H2
What is the expected behavior?
I'm trying to write a string attribute with a length of like 150-200 characters. The behavior I expect is that it always arrives and the content is correct
What is the actual behavior?
The current behavior is that sometimes the write callback on the destination device is not activated or when it is activated the content is truncated or damaged
Steps to reproduce.
just send a string with a 150-200 characters
More Information.
I think it may be due to an internal buffer in the sender or in the receiver, is there any limitation on the number of characters? reading the zigbee 3.0 documentation I did not find a limit on the maximum length
The text was updated successfully, but these errors were encountered: