[ISSUE] Sync attempts exceeded

[flyize]

What happened?

I added a new slot. It does work, but I keep getting an error with it.

This error originated from a custom integration.

Logger: custom_components.lock_code_manager.domain.sync
Source: custom_components/lock_code_manager/domain/sync.py:779
Integration: Lock Code Manager (documentation, issues)
First occurred: 12:26:29 PM (2 occurrences)
Last logged: 12:26:43 PM

01KETEHBDW3Z26MFS5EMYY3304 (House Locks): lock.front_door_lock slot 5: Sync attempts exceeded (3 in 0:05:00 window), suspending slot
01KETEHBDW3Z26MFS5EMYY3304 (House Locks): lock.back_door_lock slot 5: Sync attempts exceeded (3 in 0:05:00 window), suspending slot

This is what I see in the UI

Steps to reproduce the issue

...

Home Assistant Version

2026.08

What version of Lock Code Manager are you running?

4.4.0

Lock make and model

No response

Debug logs (paste)

Debug logs (upload)

No response

Lock Code Manager diagnostics (upload)

No response

Lock integration diagnostics (upload)

No response

Diagnostics (paste)

Browser console logs (paste)

Browser console logs (upload)

No response

Screenshots

No response

Anything else?

No response

[raman325]

Thanks for the report — the screenshot turned out to be the most useful part of it.

What the error means

"Sync attempts exceeded" is a circuit breaker. LCM writes the code to the lock, then reads the lock back to confirm it landed. When three write-then-verify cycles in a row fail to confirm within 5 minutes, LCM stops retrying and suspends the slot rather than hammering the lock forever.

What your screenshot shows

In the Back Door Lock card, slot 5 has a small clock icon that slots 1–4 don't have. That icon renders in exactly one situation: LCM has a PIN configured for the slot, but the lock is reporting no code in that slot. (A code the lock reports back masked or write-only renders differently, so this isn't that case.) The dots next to it are LCM's own configured PIN being shown as a placeholder — not a value read from the lock.

Put that together with "it does work": the code is physically on the lock and opens the door, but when LCM reads slot 5 back it comes up empty. So LCM concludes the write didn't land, writes again, fails to confirm again, and after three rounds suspends the slot.

So this is a genuine bug and not a spurious warning. What I can't tell yet is where the code actually lives from the lock's point of view.

What I need to narrow it down

There are two candidates, and they need different fixes:

1. The lock genuinely reports slot 5 as unoccupied — which would mean the code landed under a different slot/user number than LCM believes.
2. The lock reports slot 5 as occupied but won't hand back the code value — LCM currently has no way to represent that state and falls back to treating the slot as empty.

The diagnostics distinguish these in a single field, so if you can attach the following I should be able to tell which one you're hitting:

1. Lock Code Manager diagnostics (most important) — Settings → Devices & Services → Lock Code Manager → ⋮ next to your "House Locks" entry → Download diagnostics. PINs are masked in this file.

2. Z-Wave JS device diagnostics for one of the locks — Settings → Devices & Services → Devices → Front Door Lock → ⋮ → Download diagnostics.

3. Debug logs covering one suspend cycle. Add under logger → logs:

   logger:
     default: warning
     logs:
       custom_components.lock_code_manager: debug
       homeassistant.components.zwave_js: debug

   Then restart HA, set slot 5 to a new throwaway PIN (changing the PIN re-arms a suspended slot and starts a fresh sync), wait a minute or two for it to suspend again, and upload the log.

   ⚠️ Please use a throwaway PIN for this test. LCM masks PINs in its own logs, but zwave_js debug logging records the raw Set command, so your real code would appear in cleartext in anything you upload here.

4. Your Z-Wave JS driver version — Settings → Devices & Services → Z-Wave JS → Configure (shown at the top).

5. Lock make/model — I'm assuming Kwikset 620 based on [ISSUE] How do I clear out unmanaged codes? #1307; please confirm, and let me know if the two locks are different models.

Two quick questions in the meantime

• If you set slot 5 to a completely different PIN, does it converge, or suspend again the same way?
• In Z-Wave JS UI (or wherever you can see the lock's own user-code list), does slot 5 show as occupied?

[flyize]

Sorry, I ran out of time at lunch. I'll get the rest to you later. Just to confirm, in #2 you want the diagnostics for the lock from the ZWave integration, not the LCM integration.

config_entry-lock_code_manager-01KETEHBDW3Z26MFS5EMYY3304.json

[raman325]

Your diagnostics were enough — you can skip the rest of what I asked for, including the Z-Wave JS device diagnostics. Answering your question anyway for the record: yes, #2 was the Z-Wave JS device diagnostics rather than LCM's, but I no longer need them.

What was happening

Your file shows slot 5 reading as empty on both locks, while slots 1–4 read back correctly. And the PIN you configured for slot 5 doesn't appear at any slot on either lock. Combined with "it does work," that means the code is physically on the lock but the lock isn't handing the value back when LCM reads it.

The relevant detail is that your locks report the slot as occupied but withhold the code value. The Z-Wave driver, when it can't read a value back, drops the slot from its report entirely instead of saying "occupied, value withheld." LCM took that omission at face value and recorded slot 5 as empty.

From there the loop was inevitable: LCM sees a configured PIN and an empty slot, writes the code, reads back, still sees empty, concludes the write failed, and tries again. Three rounds and the breaker suspends the slot — exactly the error you saw, on both locks, at the same slot.

Worth noting this only bites when the lock's own post-write check is inconclusive. When a write comes back cleanly acknowledged, LCM already trusts it and tolerates an unreadable slot. Your locks were landing in the ambiguous path, which skipped that safety net.

The fix

#1408 makes LCM treat the lock's occupancy flag as the authority on whether a slot is in use, and the code value as a separate question. An occupied slot whose value can't be read is now recorded as "occupied, value unknown" rather than "empty," so it stops looking like a failed write.

Practically, for you: slot 5 will stop suspending and will show as unreadable rather than showing the clock icon. LCM will still re-write it once after a restart (it can't verify the value, so it can't rule out a PIN change), then leave it alone. Clearing a slot still works normally — a cleared slot reports itself available, which is unambiguous.

Once it's released, if slot 5 is still suspended, changing the PIN will re-arm it.

One thing I want to flag separately: your back door lock has a code in slot 10 that LCM doesn't manage and that doesn't match any of your configured PINs. That's the same oddity from #1307. It's unrelated to this bug and doesn't need action, but I mention it so it isn't a surprise if you see it in the UI.

Thanks for the report and the diagnostics — the screenshot and that one file are what made this findable.

[raman325]

Correcting myself: I overstated the diagnosis above, and I do need that Z-Wave JS diagnostics file after all. Sorry for the runaround.

What I got wrong. I said your locks report slot 5 as occupied while withholding the code value. That is one explanation for what your diagnostics show, but it is not the only one, and I asserted it as though I had confirmed it. I hadn't.

When I traced the driver to check, I couldn't find a normal way for a lock to end up in that state — the driver writes the slot's status and its code together, or removes both, so "occupied with no value" shouldn't normally arise. Which leaves a second explanation that fits your diagnostics equally well: the lock is reporting slot 5 as available/empty on read-back, despite the code working on the keypad.

Both look identical in the LCM diagnostics you sent. They need different fixes, and #1408 only helps with the first one.

What settles it. A single field — the lock's own userIdStatus for slot 5. That's in the Z-Wave JS device diagnostics, the file I told you to skip:

Settings → Devices & Services → Devices → Front Door Lock → ⋮ → Download diagnostics

No debug logging, no re-test, no throwaway PIN needed — just that one file, for either lock. It contains no PINs in cleartext.

Where that leaves the fix. #1408 is still worth having: LCM was treating "I can't read this slot" as "this slot is definitely empty," which is a real bug in its own right and the reason a slot marches to suspension instead of settling. I've removed the claim that it closes this issue, so #1397 stays open until we know it actually helped.

If it turns out to be the second explanation, the fix is a different one — LCM would need to stop letting a slot it can never confirm run all the way to suspension — and your diagnostics file is what tells me which to build.

[raman325]

sorry, let Claude respond and I always forget how wordy they can be... Update to the latest and see if that resolves the issue, but the zwave_js diagnostics for the lock would close the loop on what could be going wrong here. Please share if you are still facing issues!