locks: record capacity and clear semantics

This commit is contained in:
Donavan Fritz
2026-07-16 20:45:33 -05:00
parent ccca08caaf
commit 11c5ae486c
2 changed files with 13 additions and 13 deletions
+1 -1
View File
@@ -46,7 +46,7 @@ user-invocable: true
<references> <references>
<reference file="reference/locks.md" <reference file="reference/locks.md"
summary="Door locks: two zwave_js keypads, 8 shared codes with per-door enable toggles, lock_sync_slot + full/self-healing sync, usercode-cache fix, nightly git backup" summary="Door locks: two 250-slot HC620 keypads, 8 managed shared codes with per-door toggles, clear-on-disable sync + self-heal, nightly git backup"
categories=["home-automation"] categories=["home-automation"]
keywords=["lock", "locks", "door code", "door codes", "usercode", "code slot", "keypad", "lock_sync_all_codes", "set_lock_usercode", "zwave", "front door", "bunkhouse"] /> keywords=["lock", "locks", "door code", "door codes", "usercode", "code slot", "keypad", "lock_sync_all_codes", "set_lock_usercode", "zwave", "front door", "bunkhouse"] />
</references> </references>
+12 -12
View File
@@ -1,9 +1,10 @@
# Door Locks & Codes # Door Locks & Codes
<overview> <overview>
Two Z-Wave (zwave_js) keypad locks: `lock.lodge_front_door_lock` (node 3) and Two Kwikset HC620 Z-Wave (zwave_js) keypad locks:
`lock.bunkhouse_frontdoor_lock`. 8 shared code slots, managed from the `lock.lodge_front_door_lock` (node 3) and `lock.bunkhouse_frontdoor_lock`
"Lock Management" Lovelace view via helpers: (node 8). Each supports user-code slots 1250; the automation and "Lock
Management" Lovelace view manage shared logical slots 18 via helpers:
`input_text.lock_slotN_user`, `input_text.lock_slotN_code`, `input_text.lock_slotN_user`, `input_text.lock_slotN_code`,
`input_boolean.lock_slotN_lodge_enabled`, and `input_boolean.lock_slotN_lodge_enabled`, and
`input_boolean.lock_slotN_bunkhouse_enabled` (N = 18). `input_boolean.lock_slotN_bunkhouse_enabled` (N = 18).
@@ -13,12 +14,11 @@ hidden from the dashboard.
</overview> </overview>
<sync> <sync>
All code writes go through `script.lock_sync_slot` (fields: `slot` 18), the All code changes go through `script.lock_sync_slot` (fields: `slot` 18), the
single source of truth. Per slot and door it resolves the code (slot's own code single source of truth. Per slot and door it refreshes the User Code CC cache,
if that door's toggle is on, else the slot-1 family code), refuses an invalid then writes the validated slot code when enabled or calls
effective code for only that door with a door-specific notification, then does `zwave_js.clear_lock_usercode` when disabled. Every Z-Wave call uses
a UserCode CC `get` followed by `zwave_js.set_lock_usercode`. Every Z-Wave call `continue_on_error`, so one door never blocks the other.
uses `continue_on_error`, so one door never blocks the other.
- `script.lock_sync_all_codes` — warns (persistent + `notify.mobile_app_donavan_s_iphone_16_pro`) - `script.lock_sync_all_codes` — warns (persistent + `notify.mobile_app_donavan_s_iphone_16_pro`)
if a lock's `*_node_status` sensor isn't alive/asleep, then runs if a lock's `*_node_status` sensor isn't alive/asleep, then runs
@@ -29,9 +29,9 @@ uses `continue_on_error`, so one door never blocks the other.
- `automation.lock_codes_full_sync_self_heal` — full sync daily 04:00 and - `automation.lock_codes_full_sync_self_heal` — full sync daily 04:00 and
10 min after HA start, so transient failures heal within a day. 10 min after HA start, so transient failures heal within a day.
Each disabled door slot is overwritten with the family code, so the family code An HC620 clear is confirmed by a refreshed `in_use: false` readback. Do not
exists in multiple slots. Slot 1's toggles are no-ops because its fallback is overwrite disabled slots with the family PIN: the lock rejects a duplicate PIN
its own family code. without changing the slot even when the service call returns successfully.
</sync> </sync>
<troubleshooting> <troubleshooting>