ISSUE: v0.1.0-b1 not all locks are available

[tykeal]

Describe the bug My ZWave network has 7 locks on it. When I first migrated to v0.1.0-b1 I managed to see all 7 locks initially during setup. I got one of the locks configured. Ever since then I cannot see that lock as an available lock to setup (not that I need to) nor can I see one other lock. All of my other locks are visible and I have managed to them up.

I raise this as a problem as the lock that I can't see in the configuration flow is getting the codes reset out of it as if it's being managed by keymaster even when it isn't configured which means that the lock is effectively dead to management at present! Even if I stick codes in via ZWave-JS UI they get cleared out with in 30 seconds.

Environment (please complete the following information):

• OS: Home Assistant OS
• Type of system that HA is running on: Home Assistant Yellow
• Home Assistant version: 2025.8.0
• Hassio/Docker/Core? Hassio
• Component version: v0.1.0-b1
• Z-Wave integration name: ZWave-JS UI
• Lock make and model: Kwikset HC620 and 912 are not showing up. I have other 912's that I've configured

Logs I've enabled debug logging and am unable to acquire anything relevant during the configuration flow that would explain this

Screenshots Config flow showing the available locks to add

All lock devices in HA (note they are all ZWave locks)

Additional context I'm aware that there a lot of locks in this system. I originally just tried to do the upgrade / migration from v0.0.99 to v0.1.0-b1 but the system hung on the migration and my ZWave network basically started dropping packets all over the place and nodes kept reporting back dead due to the amount of traffic generated. I eventually removed all of the Keymaster configuration entries gave the system a reboot and have since been trying to get everything back up and running.

One of the locks I managed get configured (the front door lock) doesn't even show up in the pick list anymore. It's working, but it's concerning. I really need the one lock that isn't configured (lock.office_door) to be configured as it looks like it's getting codes wiped every 30 seconds by KM but I don't even see it happening when I turn on debug logs!

[tykeal]

Correction to my last statement KM is resetting lock on me I managed to see this scrolling by in the large number of debug logs:

2025-08-08 15:10:04.135 DEBUG (MainThread) [custom_components.keymaster.coordinator] [connect_and_update_lock] office_door: node_status: 4
2025-08-08 15:10:04.136 DEBUG (MainThread) [custom_components.keymaster.coordinator] [update_lock_data] office_door: usercodes: [{'code_slot': 1, 'name': 'User Code (1)', 'in_use': False, 'usercode': ''}, {'code_slot': 2, 'name': 'User Code (2)', 'in_use': False, 'usercode': ''}, {'code_slot': 3, 'name': 'User Code (3)', 'in_use': False, 'usercode': ''}, {'code_slot': 4, 'name': 'User Code (4)', 'in_use': False, 'usercode': ''}, {'code_slot': 5, 'name': 'User Code (5)', 'in_use': False, 'usercode': ''}, {'code_slot': 6, 'name': 'User Code (6)', 'in_use': False, 'usercode': ''}, {'code_slot': 7, 'name': 'User Code (7)', 'in_use': False, 'usercode': ''}, {'code_slot': 8, 'name': 'User Code (8)', 'in_use': False, 'usercode': ''}, {'code_slot': 9, 'name': 'User Code (9)', 'in_use': False, 'usercode': ''}, {'code_slot': 10, 'name': 'User Code (10)', 'in_use': False, 'usercode': ''}]

So the coordinator is finding the lock but it's not available in the config flow (yes I've restarted HA a few times) which means I can't manage the codes.

KM should not be touching locks that it's not configured to manage.

[tykeal]

A little more data on this. I've had to completely remove all Keymaster integrations from my property that has 7 locks. When I do that and give Home Assistant a restart then all locks are visible for configuration at first. The moment one is configured then the locks available for configuration always drops to 5 which means that 2 locks disappear from the options. If I open enough tabs to start the configuration on all the locks then I can, with some difficulty since configuring one puts a lot of strain on my ZWave mesh, get all the locks configured.

That being said, given how badly it behaves just getting configured for so many locks I'm currently manually programming codes to my locks all via ZWave-JS UI instead

[firstof9]

The moment one is configured then the locks available for configuration always drops to 5 which means that 2 locks disappear from the options.

That is very odd, there's nothing in the code limiting the number of locks from the lock domain to be returned.

[zanix]

I'm having the same issue, all lock entities I have show up in the config flow if I haven't added any locks. But once I add the first one, only 4 show up and it's not the one I want to add.

My Front Door and Garage Entry have the same lock brand and model

All of the locks

Here, lock.garage_entry doesn't show up if lock.front_door is already added into keymaster.

[zanix]

I edited config_flow.py and commented out the section that generates the list of locks in use and now I can see my Garage Entry lock.

def _get_locks_in_use(hass: HomeAssistant, exclude: str | None = None) -> list[str]:
    if DOMAIN not in hass.data or COORDINATOR not in hass.data[DOMAIN]:
        return []
    data: list[str] = []
    # coordinator: KeymasterCoordinator = hass.data[DOMAIN][COORDINATOR]
    # data.extend([kmlock.lock_entity_id for kmlock in coordinator.data.values()])
    # if exclude:
    #     with contextlib.suppress(ValueError):
    #         data.remove(exclude)

    return data

[firstof9]

I edited config_flow.py and commented out the section that generates the list of locks in use and now I can see my Garage Entry lock.

Thanks for this, I'll take a look at the function, at a quick glance it should be ok, but apparently it isn't.

[tykeal]

Looking over how the _get_locks_in_use function is being used it's supposed to be returning a list of all the locks that are already configured for KM (excluding the lock that may be the one that is being edited). I suspect the intent is to limit KM to only being able to manage a lock one time, which is a fairly valid point of view. But I suspect that KM is somehow configuring some of the locks to be managed when no configuration has happened (for instance my lock.office_door keeps getting managed even when it hasn't been configured)

The entire logic flow there probably needs to be reworked some.

[tykeal]

The root issue of this appears to be failed configuration or migration of locks causing one or more versions of locks that may not be yet properly managed being in the keymaster_kmlocks.json file. This configuration cache is written out upon changes to the lock definition as well as values for the defined slots. Deletion of old locks appears to be a cleanup action that does not happen as soon as a lock is removed which means there is a potential race condition for if the end user restarts HA or the integration before the data has been cleaned up leaving behind stale data that never gets cleaned up.

[tykeal]

Related to #460 (likely same root issue)

[sckissel]

I still have this issue with one of my 3 locks. It was around the time I moved to the beta as the release was not working properly with the newer 2025.8.0 HA at the time. On latest beta. I can still see the old lock reference in the .json, so cannot add it back when attempting to, as it does not show up in the list. I did try comment out the .py section and it did show up, and I was able to add it, but then the locks pins were adding and deleting and adding and deleting, so I again removed the lock from keymaster and put the .py back to its previous state, and then the lock pins were stabilized.

Is it possible I could just delete that lock from the .json and then re-add it through the UI? Or are there other files/components where the entry would be stored?

[zanix]

@sckissel Try following this https://github.com/FutureTense/keymaster/issues/460#issuecomment-3191692112

I went a bit further and removed everying from .storage After doing all that, I ended up adding my locks without parents so they are separated. I still need to test if adding my second lock as a child still has the issue.

[firstof9]

It's not recommended to go rummaging around in .storage, if you do so make sure you have a backup first.

[zanix]

It's not recommended to go rummaging around in .storage, if you do so make sure you have a backup first.

Yes, very true

[sckissel]

@sckissel Try following this #460 (comment)

Yes, I did see that one too. Eventually I just edited the .json and removed the lock, restarted HA, then was able to add the lock through Keymaster. Unfortunately, it would not connect and sync as a child, but Keymaster is happy to manage it separately. It seems there is some commonality amongst a few of us in that state.