Z-Stack: Rewrite device entry in the coordinator's child table if sending fails #680
Conversation
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sometimes the coordinator stops setting the PENDING flag before sending frames to sleepy end devices. Rewriting the device entry in the child table seems to fix this, at least temporarily. If sending a frame fails, try to rewrite the device's entry and try again (if there is already an entry, and only if the device is listed as a sleepy end device, aka CHILD_RFD)
Koenkk
reviewed
Mar 18, 2023
Koenkk
reviewed
Mar 18, 2023
|
This looks very promising, many thanks for diving into this! 🏅 |
|
Thanks! 🚀 |
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
I finally found a workaround for the Z-Stack firmware bug I mentioned in Koenkk/zigbee2mqtt#13478 (comment): I could bring the controller to properly sending the PENDING flag again by rewriting the child entry in the controller child table.
This PR adds this workaround to
zigbee-herdsman. Since it is really hard to thoroughly test these kinds of issues (the devices work fine for up to several days before the issue occurs), I designed the fix as unintrusive as possible. It will only jump in if a device does not respond to a message, the affected device is still in the coordinator's child table and the device is known to the coordinator as a sleepy end device.Together with my previous PR, this should fix Koenkk/zigbee2mqtt#13478 and Koenkk/zigbee2mqtt#16376 and potentially others. I believe there are still a few remaining issues with the pending message queue, but they should now be non-permanent and not require re-pairing or restarting the coordinator any more.