WTH is there no native PIN management UI for locks in home assistant?

There are a few HACS out there but why is there no native Z-wave, Zigbee, Thread/Matter pin management UI / control in HA?

I am talking about very easy but very basic UI elements that let you set a few pins and preferably group / sync them between locks.

There are some HACS projects for this but nothing native, which seems odd since locks would seem to be such a common smart device, particularly Z-wave and Zigbee?

Yes please add a building block integration component to allow unified user code management for locks, (i.e. please add building block integration component to allow unified user code management for locks).

Paraphrasing based on the idea from this architecture discussion → Native lock code functionality · home-assistant/architecture · Discussion #1000 · GitHub which was started over a year ago by @raman325 who a little time after that also started coding and maintaining a “Lock Code Manager” (a custom component that currently only works with the Z-Wave JS integration). See forum thread about that custom component here:

And the code for that custom Lock Code Manager component in its GitHub repository:

Suggested in a built-in lock platform (built-in integration building block) that would natively allow users to control the lock state of a lock (i.e. smart lock control), but it is currently not possible, at least natively, to manage user codes for the lock (i.e. users PIN-codes management). While not all locks have this functionality, many integrations/protocols does support this, including the built-in Z-Wave JS, ZHA (Zigbee Home Automation), and the Matter integrations, as well as some proprietary WiFi/BLE smart locks.

Today, those integrations are forced to more or less handle all lock code management on their own, (as an example, there are zwave_js specific services to manage user codes, but there isn’t a native UI that makes them easily manageable). As a result, there are custom integrations like GitHub - FutureTense/keymaster: Home Assistant integration for managing Z-Wave enabled locks which hack together a solution using a combination of the Home Assistant packages functionality, input helpers, and automations. In addition to generating a lot of artifacts which pollute a user’s instance, the UI that gets created is not optimized for the use case and is quite complex given what it’s trying to accomplish.

PS: Also check out the extended feature request about locks that was posted a few months ago here:

Paraphrasing based on the idea from this architecture discussion → Native lock code functionality · home-assistant/architecture · Discussion #1000 · GitHub which was started over a year ago by @raman325 who a little time after that also started coding and maintaining a “"Lock Code Manager” (a custom component that currently only works with the Z-Wave JS integration). See forum thread about that custom component here:

The built-in lock platform (built-in integration building block) natively allows users to control the lock state of a lock (i.e. smart lock control), but it is currently not possible, at least natively, to manage user codes for the lock (i.e. users PIN-codes management). While not all locks have this functionality, many integrations/protocols does support this, including the built-in Z-Wave JS, ZHA (Zigbee Home Automation), and the Matter integrations, as well as some proprietary WiFi/BLE smart locks.

Today, those integrations are forced to more or less handle all lock code management on their own, (as an example, there are zwave_js specific services to manage user codes, but there isn’t a native UI that makes them easily manageable). As a result, there are custom integrations like GitHub - FutureTense/keymaster: Home Assistant integration for managing Z-Wave enabled locks which hack together a solution using a combination of the Home Assistant packages functionality, input helpers, and automations. In addition to generating a lot of artifacts which pollute a user’s instance, the UI that gets created is not optimized for the use case and is quite complex given what it’s trying to accomplish.

PS: Also check out the extended feature request about locks that was posted a few months ago here:

2 Likes

THIS! WTH? I know this doesn’t get many votes, but it does keep coming up in WTH year after year…

Home Assistant needs an integrated Door Lock Manager. Most door locks support setting custom PINs and most home automation systems (SmartThings even) have an option for this. There is a HACS integration (which I assume is pretty good, but I can’t test it as it only supports Z-Wave not Zigbee) but nothing for Zigbee, and I think Wifi/BLE/ etc as well.

I managed to ditch my Smarthings hub after working out that I could send PIN commands manually via HA devices developer mode, but it’s confusing and manual. By now HA should have a GUI where I can just enable a PIN on certain days when the cleaner comes, or for a few weeks when family visits etc.

Pleeeease! Happy to put the requirements doc together.

1 Like

This WTH request could be integrated into the “2025 Year of Security” concept, which has WTH No Access Control as the main driver.

3 Likes

I have been asking for this for years. It’s a pain point for anyone wanting to control their smart locks with Home Assistant. Locks are crucial to any smart home environment.
I appreciate the HACS efforts to address PIN code management, but this really needs to be baked into the UI.

Is that a thing for 2025?

No, it’s not, but if you read the thread I linked to, a lot of people are suggesting it to be. I agree with them. The HA folks said 2024 would be the year of voice, and they delivered. The point is that if the team focuses their attention on a single important theme then it’s achievable. In order for HA to graduate from a “cool open-source project/hobby” to a viable product then it needs to focus on security and privacy at the local level (the actual home). Lock management falls into that category, IMO.

Yeah that would be amazing if it happened. Keen to see the voice stuff continuing too though.