Describe the bug
I'm not entirely sure when this started happening since there isn't an actual error, but I started investigating after I noticed two of my locks batteries dying more quickly than usual.
I've got 3 Schlage locks, 2x BE469 and 1x BE469ZP, the 2x BE469 are having a UserCodeCCGet command issued to them once every 60 seconds even though nothing has changed with the codes.
I've pasted the first part of the debug logs below, but there isn't any obvious differences between the front and garage entry locks (BE469) and the back lock (BE469ZP) to determine why these 2 are being polled so frequently. I'm assuming it's likely another issue related to masking *s returned by UserCodeCCGet (see below).
It's hitting this call every time due to usercode being 10 *s: https://github.com/FutureTense/keymaster/blob/main/custom_components/keymaster/coordinator.py#L1735
I've tried manually resetting the slots on these locks and repopulating them to get them to sync (which seems to happen fine) but they still are polled every 60s. The actual changes make it to the lock just fine and the UI reflects the current status, and matches between both the BE469s and the BE469ZP.
Environment (please complete the following information):
- OS: [e.g. HassOS/Raspbian/CentOS] HAOS 17.1
- Type of system that HA is running on: [e.g. RPi3/NUC/Synology] NUC
- Home Assistant version: [e.g. 0.105.5] 2026.3.4
- Hassio/Docker/Core? HAOS
- Component version: [e.g. 0.1.2] 0.2.1
- Z-Wave integration name: [e.g. zwave_js] ZWave JS
- Lock make and model: [e.g. Schlage BE469] Schlage BE469
Logs
Keymaster
2026-03-26 09:37:11.013 DEBUG (MainThread) [custom_components.keymaster.coordinator] [connect_and_update_lock] front_door: Provider still connected
2026-03-26 09:37:11.014 DEBUG (MainThread) [custom_components.keymaster.coordinator] [update_lock_data] front_door: usercodes count: 30
2026-03-26 09:37:12.612 DEBUG (MainThread) [custom_components.keymaster.coordinator] [connect_and_update_lock] back_door: Provider still connected
2026-03-26 09:37:12.612 DEBUG (MainThread) [custom_components.keymaster.coordinator] [update_lock_data] back_door: usercodes count: 30
2026-03-26 09:37:12.613 DEBUG (MainThread) [custom_components.keymaster.coordinator] [connect_and_update_lock] garage_entry_door: Provider still connected
2026-03-26 09:37:12.613 DEBUG (MainThread) [custom_components.keymaster.coordinator] [update_lock_data] garage_entry_door: usercodes count: 30
2026-03-26 09:37:15.346 DEBUG (MainThread) [custom_components.keymaster.coordinator] [save_data] No changes to kmlocks. Not saving.
2026-03-26 09:37:15.347 DEBUG (MainThread) [custom_components.keymaster.coordinator] Finished fetching keymaster data in 4.334 seconds (success: True)
ZWave JS
2026-03-26 10:24:34.591 DRIVER » [Node 002] [REQ] [SendData]
│ transmit options: 0x25
│ callback id: 24
└─[SecurityCCCommandEncapsulation]
│ nonce id: 63
└─[UserCodeCCGet]
user id: 1
2026-03-26 10:24:34.889 DRIVER « [Node 002] [REQ] [ApplicationCommand]
└─[SecurityCCCommandEncapsulation]
│ sequenced: false
└─[UserCodeCCReport]
user id: 1
id status: Enabled
user code: **********
Describe the bug
I'm not entirely sure when this started happening since there isn't an actual error, but I started investigating after I noticed two of my locks batteries dying more quickly than usual.
I've got 3 Schlage locks, 2x BE469 and 1x BE469ZP, the 2x BE469 are having a UserCodeCCGet command issued to them once every 60 seconds even though nothing has changed with the codes.
I've pasted the first part of the debug logs below, but there isn't any obvious differences between the front and garage entry locks (BE469) and the back lock (BE469ZP) to determine why these 2 are being polled so frequently. I'm assuming it's likely another issue related to masking *s returned by UserCodeCCGet (see below).
It's hitting this call every time due to
usercodebeing 10 *s: https://github.com/FutureTense/keymaster/blob/main/custom_components/keymaster/coordinator.py#L1735I've tried manually resetting the slots on these locks and repopulating them to get them to sync (which seems to happen fine) but they still are polled every 60s. The actual changes make it to the lock just fine and the UI reflects the current status, and matches between both the BE469s and the BE469ZP.
Environment (please complete the following information):
Logs
Keymaster
2026-03-26 09:37:11.013 DEBUG (MainThread) [custom_components.keymaster.coordinator] [connect_and_update_lock] front_door: Provider still connected
2026-03-26 09:37:11.014 DEBUG (MainThread) [custom_components.keymaster.coordinator] [update_lock_data] front_door: usercodes count: 30
2026-03-26 09:37:12.612 DEBUG (MainThread) [custom_components.keymaster.coordinator] [connect_and_update_lock] back_door: Provider still connected
2026-03-26 09:37:12.612 DEBUG (MainThread) [custom_components.keymaster.coordinator] [update_lock_data] back_door: usercodes count: 30
2026-03-26 09:37:12.613 DEBUG (MainThread) [custom_components.keymaster.coordinator] [connect_and_update_lock] garage_entry_door: Provider still connected
2026-03-26 09:37:12.613 DEBUG (MainThread) [custom_components.keymaster.coordinator] [update_lock_data] garage_entry_door: usercodes count: 30
2026-03-26 09:37:15.346 DEBUG (MainThread) [custom_components.keymaster.coordinator] [save_data] No changes to kmlocks. Not saving.
2026-03-26 09:37:15.347 DEBUG (MainThread) [custom_components.keymaster.coordinator] Finished fetching keymaster data in 4.334 seconds (success: True)
ZWave JS
2026-03-26 10:24:34.591 DRIVER » [Node 002] [REQ] [SendData]
│ transmit options: 0x25
│ callback id: 24
└─[SecurityCCCommandEncapsulation]
│ nonce id: 63
└─[UserCodeCCGet]
user id: 1
2026-03-26 10:24:34.889 DRIVER « [Node 002] [REQ] [ApplicationCommand]
└─[SecurityCCCommandEncapsulation]
│ sequenced: false
└─[UserCodeCCReport]
user id: 1
id status: Enabled
user code: **********