Skip to content

Zigbee Lock: make code sync more robust - #3330

Open
hcarter-775 wants to merge 9 commits into
simplify-reported-cred-managementfrom
improve-zigbee-sync-codes
Open

hcarter-775 wants to merge 9 commits into
simplify-reported-cred-managementfrom
improve-zigbee-sync-codes

Conversation

@hcarter-775

@hcarter-775 hcarter-775 commented Nov 4, 2026 •

Copy link
Copy Markdown
Contributor

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.

@github-actions

github-actions Bot commented Nov 4, 2026

Copy link
Copy Markdown

@hcarter-775 hcarter-775 changed the title zigbee lock: try codes sync more often Zigbee Lock: try code sync more frequently Nov 4, 2026
@github-actions

github-actions Bot commented Nov 4, 2026 •

Copy link
Copy Markdown

Test Results

   73 files  ± 0    550 suites  ±0   0s ⏱️ ±0s
3 368 tests +12  3 368 ✅ +12  0 💤 ±0  0 ❌ ±0 
5 407 runs  +12  5 407 ✅ +12  0 💤 ±0  0 ❌ ±0 

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.
doConfigure: SLGA_MIGRATED device with lockCredentials sends bind/configure then calls sync_device_state after 2-second delay
infoChanged: switching from non-lockCodes to lockCodes+lockCredentials profile triggers full SLGA migration and two syncs
default_response: first failure to GetPINCode during sync retries the same index
default_response: repeated failure to GetPINCode at the same index continues to the next index
default_response: repeated failures complete the sync
default_response: success to GetPINCode does not advance the sync
doConfigure: SLGA_MIGRATED device with lockCredentials sends bind/configure and does not start a sync (init handles it)
get_pin_code_response: clears the consecutive unoccupied counter when the sync completes
get_pin_code_response: ignores a response that does not match the sync code index
get_pin_code_response: persists the sync code index while sync is in progress
infoChanged: switching from non-lockCodes to lockCodes+lockCredentials profile triggers full SLGA migration and syncs once
init: migrated device whose codes have already synced does not sync again
…

♻️ This comment has been updated with latest results.

@github-actions

github-actions Bot commented Nov 4, 2026 •

Copy link
Copy Markdown

zigbee-lock_coverage.xml

File Coverage
All files 94% ✅
/home/runner/work/SmartThingsEdgeDrivers/SmartThingsEdgeDrivers/drivers/SmartThings/zigbee-lock/src/configurations.lua 95% ✅
/home/runner/work/SmartThingsEdgeDrivers/SmartThingsEdgeDrivers/drivers/SmartThings/zigbee-lock/src/lazy_load_subdriver.lua 57% ❌
/home/runner/work/SmartThingsEdgeDrivers/SmartThingsEdgeDrivers/drivers/SmartThings/zigbee-lock/src/init.lua 99% ✅
/home/runner/work/SmartThingsEdgeDrivers/SmartThingsEdgeDrivers/drivers/SmartThings/zigbee-lock/src/legacy-handlers/migrate.lua 98% ✅
/home/runner/work/SmartThingsEdgeDrivers/SmartThingsEdgeDrivers/drivers/SmartThings/zigbee-lock/src/legacy-handlers/init.lua 95% ✅
/home/runner/work/SmartThingsEdgeDrivers/SmartThingsEdgeDrivers/drivers/SmartThings/zigbee-lock/src/lock_utils/tables.lua 98% ✅
/home/runner/work/SmartThingsEdgeDrivers/SmartThingsEdgeDrivers/drivers/SmartThings/zigbee-lock/src/lock_utils/utils.lua 96% ✅
/home/runner/work/SmartThingsEdgeDrivers/SmartThingsEdgeDrivers/drivers/SmartThings/zigbee-lock/src/legacy-handlers/yale/init.lua 92% ✅
/home/runner/work/SmartThingsEdgeDrivers/SmartThingsEdgeDrivers/drivers/SmartThings/zigbee-lock/src/lock_handlers/zigbee_responses.lua 88% ❌
/home/runner/work/SmartThingsEdgeDrivers/SmartThingsEdgeDrivers/drivers/SmartThings/zigbee-lock/src/lock_handlers/capabilities.lua 89% ❌
/home/runner/work/SmartThingsEdgeDrivers/SmartThingsEdgeDrivers/drivers/SmartThings/zigbee-lock/src/samsungsds/init.lua 89% ❌

Minimum allowed coverage is 90%

Generated by 🐒 cobertura-action against e721024

@hcarter-775
hcarter-775 force-pushed the improve-zigbee-sync-codes branch 2 times, most recently from 3e1a17a to 34df795 Compare November 4, 2026 22:06

@ctowns ctowns left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

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

@hcarter-775 hcarter-775 changed the title Zigbee Lock: try code sync more frequently Zigbee Lock: make code sync more robust Nov 5, 2026
@hcarter-775

Copy link
Copy Markdown
Contributor Author

If we are adding this here, would we want it for Z-Wave too?

@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.

@hcarter-775
hcarter-775 changed the base branch from main to simplify-reported-cred-management November 5, 2026 20:05
@hcarter-775
hcarter-775 force-pushed the improve-zigbee-sync-codes branch 2 times, most recently from 2ddd790 to b5203db Compare November 6, 2026 17:56
@hcarter-775
hcarter-775 force-pushed the simplify-reported-cred-management branch from 1eab2cd to 528c7fb Compare November 6, 2026 19:59
hcarter-775 and others added 9 commits November 6, 2026 14:00
- 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>
@hcarter-775
hcarter-775 force-pushed the improve-zigbee-sync-codes branch from b5203db to e721024 Compare November 6, 2026 20:00
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants