Repository navigation
JBD: retry a timed-out status read when a MOS change is pending - #423
Merged
Merged
Conversation
Owner
|
Thanks for testing on real hardware. #423 looks good: the retry only applies with a change pending, and a second timeout still leaves it queued. Merging. |
fl4p
added a commit
that referenced
this pull request
Oct 18, 2026
…t fragment can succeed A timed-out reply that lost its tail left its head in the notification buffer; the next reply was appended to it, failed its checksum, and the #423 retry timed out too. Tests drive the real handler and pin the retry to once and to pending switches only.
fl4p
added a commit
that referenced
this pull request
Oct 18, 2026
This file contains hidden or 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
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
2 participants
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 found this while testing the JBD switch changes from the previous review. The requested changes worked on the physical BMS with
keep_alive=False: I turned charging off and back on, and both states were confirmed by the BMS.I also ran into a separate edge case during that work. If the first status read times out while a charge or discharge change is waiting, Batmon leaves the change queued until a later poll.
This adds one retry when a MOS change is pending. If the retry also times out, the change remains queued so it can be tried again later. Polls without a pending change behave as before.
I added tests for a successful retry and for two consecutive timeouts. The full BMS test suite passes with 1183 passed and 9 skipped.
I tested the command path through Home Assistant on a JBD 14S BMS running firmware 3.2. The timeout did not happen again during the patched hardware test, so the retry itself is covered by the automated test. The physical test confirmed that both charge changes were written and read back correctly.