Lock fails to initialize and is added as new device at each start

[not4smurf]

I have a Schlage z-wave lock that works just fine in Home Assistant as a generic z-wave device. It also works fine from Google Home via the Matter Bridge with one small exception - each time the Matter Bridge starts I get a notification in Google Home that a new device (Door Lock) has been added to my Home, but it works fine after that.

I see in my logs:

2026-08-01, 8:21:50 a.m.
WARN
[BridgeEndpointManager] [lock.front_door_lock] Caused by: Validating c3e353261660416db49c5d708af65871.aggregator.lock_front_door_lock.doorLock.state.sendPinOverTheAir: Conformance "[!USR & PIN]": Matter does not allow you to set this attribute (135)

2026-08-01, 8:21:50 a.m.
WARN
[BridgeEndpointManager] [lock.front_door_lock] Behavior error [1/1]: Error initializing c3e353261660416db49c5d708af65871.aggregator.lock_front_door_lock.doorLock

2026-08-01, 8:21:50 a.m.
WARN
[BridgeEndpointManager] Failed to add endpoint for lock.front_door_lock: Behaviors have errors

which I am interpreting as there was some issue validating the existing lock but as it works, I'm assuming that it then proceeds to add it as a new lock - which generates the Google notification.

I have not configured any PIN either hardware in the device, or Matter - I simply paired to Home Assistant at the z-wave level and used it.

Edit to add - this is a relatively new issue. I've been using Matter Bridge for a long time and this didn't always happen. I can't say when it started because at first I didn't think anything of it - because the lock still worked.

[RiDDiX]

You read the log right. Versions 2.0.7 through 2.0.16 stored a lock setting (sendPinOverTheAir) that later versions made invalid, and that leftover fails the lock's validation on every start; the retry then comes up under a fresh endpoint number, which is why Google announces a new device each boot. Fixed on alpha, it cleans the leftover out of the store automatically, nothing to do on your side. Next release will have it.