-
Notifications
You must be signed in to change notification settings - Fork 59
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
APDU instances are not released #348
Comments
Are you able to identify which is not re-releasing the PDU ? |
I can throw off the full log of communication with zigate and sniff when pairing |
Even without pairing, after several restarts the device started sending Data request -> 0x0000 and ZCL identify -> Broadcast Example
ZiGate does not send messages, but after the next request, 0x9999 with status 0x81 began to arrive
|
with some devices, zigbee pro stack can't manage many endpoint.
@fairecasoimeme , I think that the recent changes tested last week shows a correct behaviour on teh Schneider Wiser for instance. Not sure if it will address all cases |
pretty good improvement made @fairecasoimeme . do not see further leak on PDU with the recent code |
Firmware 31e |
Firmware latest COORDINATOR (APDU Instances 9) along with PR #342 , but sometimes APDUs are not released (further constantly u8getapduuse: 7). Seen by messages 0x8000 .
Below is a part of the log. This occurs after the RawAPSDataRequest 0x0530. It is also noteworthy that in the messages there was nothing about 5,6 immediately after u8getapduuse: 4 turned out to be 7 and hung in this position. In the 0x8000 messages at the end, I also added PDUM_u8GetMaxNpduUse u8GetMaxApduUse for debugging.
After that, messages 0x9999 with a load of 0x81 often start arriving, sometimes 5-10 times in a row.
This behavior was previously on firmware 3.1 c before the fix 42bdd0b
But even now, when the maximum APDU is reached, messages 0x8000 with the status A6 are received
The text was updated successfully, but these errors were encountered: