Repository navigation
Zigbee Lock: make code sync more robust - #3330
hcarter-775 wants to merge 9 commits into
Conversation
|
Invitation URL: |
Test Results 73 files ± 0 550 suites ±0 0s ⏱️ ±0s Results for commit e721024. ± Comparison against base commit 528c7fb. This pull request removes 2 and adds 14 tests. Note that renamed tests count towards both.♻️ This comment has been updated with latest results. |
|
zigbee-lock_coverage.xml
Minimum allowed coverage is Generated by 🐒 cobertura-action against e721024 |
3e1a17a to
34df795
Compare
ctowns
left a comment
There was a problem hiding this comment.
If we are adding this here, would we want it for Z-Wave too?
This adds some resiliency to the driver, but do we have an idea of how often we might see a case that requires this? I would guess it is rare, but I still agree it's good to make the driver more robust.
nit: could we update the title of this PR to something more accurate? This isn't really increasing the sync frequency, but rather adding some robustness and retries to confirm that the sync actually completes. It's more of a backup than something periodic that would happen frequently
@ctowns, yes, we should probably add this to Zwave too, but I wanted to put that in a separate PR after this merged, to ensure that is as smooth a thing as possible and that I'm not just sitting for 2 same PRs at once. |
2ddd790 to
b5203db
Compare
1eab2cd to
528c7fb
Compare
- skip sync while the device is busy (expiring stale busy state so a stalled sync can be retried) rather than clobbering a command in flight - advance the sync from the persisted code index and ignore responses for any other index - clear the persisted index when it was started under a different CODES_SYNC_VERSION - clear the consecutive unoccupied counter when a sync completes - move continue_code_sync into lock_utils' sync section - start the init sync after a 15s delay (so NumberOfPINUsersSupported is known) and drop the duplicate from doConfigure Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
A non-success Default Response to GetPINCode may be transient. Retry the same index once before treating the slot as unoccupied, so a transient failure does not count toward ending (and permanently completing) the sync early. Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
Also document how CODES_SYNC_VERSION bumps trigger a re-sync. Co-Authored-By: Claude Sonnet 5.5 <noreply@anthropic.com>
b5203db to
e721024
Compare
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. Also, we should sync codes from 0, since this is technically an index that can be valid, depending on the device.
Summary of Completed Tests
Tested on-device. Unit tests updated and added.