Repository navigation
zwave lock: make sync codes more robust, add it to refresh handling - #3339
Merged
Merged
Conversation
|
Channel deleted. |
|
zwave-lock_coverage.xml
Minimum allowed coverage is Generated by 🐒 cobertura-action against 65f06c8 |
Test Results 73 files 571 suites 0s ⏱️ Results for commit 65f06c8. ♻️ This comment has been updated with latest results. |
ctowns
force-pushed
the
zwave-lock/harden-sync-codes
branch
from
November 12, 2026 16:47
e6cd227 to
6aa1ce1
Compare
Contributor
|
Rebased changes. Made a few small updates to match the zigbee equivalent changes in #3330 , but they were mostly already the same. Claude found a bug in AI review that I added a patch for, but otherwise the original two commits are unchanged. |
12 tasks
hcarter-775
commented
Nov 12, 2026
hcarter-775
left a comment
hcarter-775
left a comment
Contributor
Author
There was a problem hiding this comment.
cannot approve my own pr, but @ctowns I approve the changes made- I have checked that they are 1-1 with the Zigbee logic, altered of course to fit the Zwave particularities.
ctowns
approved these changes
Nov 13, 2026
Base automatically changed from
zwave-lock/standardize-cred-user-management
to
main
November 13, 2026 18:49
Match the zigbee-lock sync handling merged in #3330. During a code sync, user_code_report compared the reported user ID status, rather than its user identifier, against the expected code index, so a report for a different slot was taken as the result for the current one. A late or duplicate report could record an occupied code at the wrong slot and skip the slot actually being checked. - A report for an index below the current one has already been processed: log it and return without advancing the sync. - A report for any other unexpected index is logged and treated as an unoccupied slot, so the sync continues. - add_reported_credential returns the result of the add, as in zigbee-lock. Adds tests for both cases, and ports the zigbee-lock tests for persisting the sync index, clearing the unoccupied counter on completion, and retrying a stalled sync after the busy window expires. Co-Authored-By: Claude Opus 5.5 <noreply@anthropic.com>
ctowns
force-pushed
the
zwave-lock/harden-sync-codes
branch
from
November 13, 2026 19:13
6aa1ce1 to
65f06c8
Compare
Contributor
|
Rebased due to conflicts, but the changes were either due to command ordering or test cases, no functional conflicts |
hcarter-775
added a commit
that referenced
this pull request
Nov 13, 2026
This reverts commit 91a7498. Conflicts with later changes (#3337, #3339, #3346) in the zwave-lock tests were resolved by dropping the tests added by #3323 and keeping the lock_utils require and Schlage mock device that remaining code and tests still use. Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
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
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.
Description of Change
Attempt a re-sync of lock codes after migration is completed as a backup measure, in case our local lockCodes cache missed. Also, retry lock codes migration on every driver init, until the sync has actually completed at least once. Finally, include code syncing in refresh to allow users some retry functionality in the case that something fails.
Summary of Completed Tests
Tests updated. Tested on a Yale lock with a fresh onboard.