[REQUEST] Add full Zigbee lock management with ability to manage users for locks and their PIN codes via ZHA to replicate the new Matter lock manager in Home Assistant?

[Hedda]

Home Assistant 2026.4 release (currently in Beta) added a Matter lock user and credential management services feature which allows you to manage your lock users and PIN codes directly from within the Home Assistant UI if you have have a Matter-compatible smart lock. This change adds the ability to manage Matter lock codes from within Home Assistant via the new "Manage Lock" menu added to Home Assistant's frontend (UI):

• https://www.home-assistant.io/blog/2026/04/01/release-20264/#matter-lock-manager

Would it be a good or bad idea to take inspiration from this feature and try to reimplement or match the required functionality specifically for for Zigbee devices used via Home Assistant's ZHA integration component to help Zigbee users gain similar user-experience? Could and should this be achieved after adding any/all missing functions depending on the zha or zigpy libraries?

That is, enable ZHA user code management for Zigbee locks via commands and allow users to use a Zigbee lock manager in UI:

• https://www.home-assistant.io/blog/2026/04/01/release-20264/#matter-lock-manager

  

• On the device page of your Matter lock, you’ll find a new "Manage lock" option. It opens a dialog where you can see all configured users, add new ones, edit existing ones, or remove them. When adding a new user, you give them a name, set a PIN code, and choose an access type: full access (can lock and unlock anytime) or one-time access (the code works once and is then automatically deleted by the lock).

  

• Under the hood, this is powered by a new set of Matter lock actions that are also available for use in your automations and scripts. You can, for example, create a one-time PIN code for a guest and send it in a notification, all from an automation! The available actions include creating and removing users, setting and clearing credentials (like PIN codes and RFID tags), and querying the lock’s capabilities.

  

This awesome contribution to Home Assistant's Matter inteation was initiated by @Ahbrown41. See related frontend and backend pull reqeusts:

• Add Matter lock user and credential management services home-assistant/core#161936

  The new capability supports the adding and removing of both permanent and single use users for now (Scheduling etc can come later). This new ability builds on recent changes to the backend dev branch that implement the backend matter functionality for managing lock codes etc.

• Matter lock manager home-assistant/frontend#28672

  Adds 7 entity services for Matter lock user and credential management, aligned with the Matter DoorLock cluster specification (Application Cluster Spec, Chapter 5.2). These services expose the DoorLock cluster's user and credential commands as Home Assistant actions, accessible from automations, scripts, and Developer Tools.

This concept initially started as a discussion about PIN management for Matter Door Locks under the feature requests discussion section here:

• https://github.com/orgs/home-assistant/discussions/551

this is plumbing work to allow other things to build on top of it. I had a fully working backend with an API, actions and events along with a fully functioning UI, I was asked to strip out all extra stuff which I did and so this is now completely bare bones. I can do more, I could come up with an abstraction layer but it would sit on these bones anyway.

All I want is Matter pin/user management so I do not have to use another tool, it has been years that I have been waiting for native not external support for pin/user mangement so I took it on myself to do it. The UI I had was comprehensive and tested and clould use single user, scheduled and perminant users.

I can do changes to the global lock object but it is very unlikely this PR would get approved with that change from what I see

I agree it will probably be a tougher sell to make changes to the core Lock object model, but I wanted to note it down to memorialize.

I was also tired of waiting for native pin management and provided a scripted approach https://github.com/orgs/home-assistant/discussions/551#discussioncomment-15471048 to the community a few weeks ago, completely unaware of this epic and work.

PS: I understand that that initial Matter lock manager "only" adds some parts of underlying work that is needed to enable other enhanced lock management features s to build on top of this to allow usercode management of doorlocks (i.e. managing user permissions for locks and PIN-usercodes). However I still think that implementing this bacis functionality for Zigbee lock credentials and lock PIN-codes in ZHA for Home Assistant could direcctly determine or have indirect influence on future architecture that at least the extended and more advanced cross-platform concepts and principles discussed in this related architecture discussion:

• Native lock code functionality home-assistant/architecture#1000

Note! Also see related roadmap discussion which raised by mkerstner which discusses longterm benefits of having a unified code management system(s) and a shared credential UI for all integrations (i.e. a cross-platform and protocol-agnostic global foundation that suits a range of protocols) that includes codes for both locks and alarm control panels:

• Leverage a more consistent credential management approach OpenHomeFoundation/roadmap#8

and the related epic tracker for protocol-agnostic credential management:

• Evaluate a stable foundation for protocol-agnostic credential management home-assistant/epics#28

By the way, if implementated for Zigbee locks then perhaps same or similar solution could also be done for alarm control panel?

[Hedda]

Note! Also see related roadmap discussion which raised by mkerstner which discusses longterm benefits of having a unified code management system(s) and a shared credential UI for all integrations (i.e. a cross-platform and protocol-agnostic global foundation that suits a range of protocols) that includes codes for both locks and alarm control panels:

• Leverage a more consistent credential management approach OpenHomeFoundation/roadmap#8

FYI, apparently product managers from the Open Home Foundation has already noted that this is a wanted feature, initially with credentials are tied to the lock itself (not to a Home Assistant user), and at least added credential management for Z-Wave locks to Home Assistant's roadmap (however there is not yet a maching roadmap for Zigbee):

• Credential management for Z-Wave locks OpenHomeFoundation/roadmap#70

  In scope

  • CRUD (Create, Read, Update, Delete) actions for PINs and user codes.
  • Credentials are tied to the lock itself, not to a Home Assistant user.
  • Manage everything from the device page and show events in the device activity log.
  • Allow codes to be enabled or disabled without having to delete them.

• Z-Wave door lock code management home-assistant/epics#31

At same time they opened that roadmap issue tracked for Zwave they closed credential management for Matter locks roadmap:

• Credential management for Matter locks OpenHomeFoundation/roadmap#69

(I know that just because they added it to their roadmap does not mean that someone is actually working on it or even planning to ever work on it yet, however it does look like they today assigned AlCalzone to investigate Z-Wave roadmap issue and decided to add support for a unifying credential API in Z-Wave JS).

Update: Z-Wave JS app/addon for Home Assistent has since added a new API to manage credentials across a range of legacy and modern devices.

Anyway, his first draft introduces a initial Z-Wave JS “Access Control” (credential/user) management via new lock entity services, helper logic, and accompanying UI strings/icons plus tests.

• Add support for Z-Wave credential management home-assistant/core#168360

  • feat(cc): implement User Credential CC commands and API zwave-js/zwave-js#8629

  • feat: add unified API to manage users and credentials zwave-js/zwave-js#8738

  • feat: support new credential API in Z-Wave JS 15.23.4, bump schema to 48 zwave-js/zwave-js-server#1544

Update: Z-Wave JS 15.23.0 to 15.23.5 added a new unified API to manage credentials across a range of legacy and modern devices

https://github.com/zwave-js/zwave-js/blob/master/CHANGELOG.md

• Add unified API to manage users and credentials across User Code CC and User Credential CC
• Support User Credential CC V1/V2

15.23.1 (2026-04-14) The unified API for credential management introduced in v15.23.0 is now accessible through endpoint.accessControl instead of living directly on the endpoint. This change paves the way for similar high-level feature APIs to be added in the future without polluting the Endpoint class signature.

This is technically a breaking change, but Z-Wave JS developer expect that this API is not being used yet, so we're going to do some emotional versioning for this release and call it a patch.

15.23.2 (2026-04-15) This release iterates on the new endpoint.accessControl again, making that property undefined when none of the required command classes are supported.

15.23.3 (2026-04-22) This release continues to iterate on the new endpoint.accessControl API:

• Credential slots are considered global per device, not user specific.
• Set-type credential management methods return specific error types that give more information about what failed.

PS: FYI, odlund did submit these PRs recently to modernize lock service actions for the Z-Wave integration in Home Assistant's core:

• Z-Wave lock service action modernization home-assistant/core#162967

• Add get_lock_usercode service to zwave_js integration home-assistant/core#162057

[Hedda]

Also see this indirectly related effort by raman325 to try adding a ZHA lock provider to his custom Lock Code Manager component:

• Add ZHA (Zigbee Home Automation) lock provider raman325/lock_code_manager#739

  • [REQUEST] Support effort to add ZHA lock provider to Lock Code Manager integration (available via HACS) #618

Originally posted by raman325 in raman325/lock_code_manager#739

Proposed change

Adds support for ZHA locks by accessing the zigpy DoorLock cluster (0x0101) directly. This enables user code management for Zigbee locks via:

• get_pin_code command (0x06) for reading codes
• set_pin_code command (0x05) for setting codes
• clear_pin_code command (0x07) for clearing codes

Push Updates (Battery Saving)

Subscribes directly to zigpy cluster events to receive real-time notifications:

• programming_event_notification (0x21): Fires when PINs are added/deleted/changed → triggers coordinator refresh
• operation_event_notification (0x20): Fires on lock/unlock with user ID → fires code slot event for automations

This eliminates polling for locks that support these notifications, significantly reducing Zigbee traffic and improving battery life.

Capability Detection

Checks the lock's programming event mask attributes (keypad_programming_event_mask, rf_programming_event_mask, rfid_programming_event_mask) to determine if it supports programming event notifications:

• Supported: Disables drift detection entirely (relies on push notifications)
• Not supported: Enables 1-hour drift detection interval as fallback

Also adds "zha" to after_dependencies in manifest and zigpy to test dependencies.

Type of change

• New feature (which adds functionality)

Additional information

• This PR is related to issue: Enable the integration for Zigbee locks. raman325/lock_code_manager#371

[Hedda]

Do you think that Aqara would send one of each of their newer lock models for free to you ZHA devs if could get in contact and ask them?

• https://www.aqara.com/en/product/door-lock/
  • Aqara Smart Door Lock A100 Zigbee
  • Aqara Smart Door Lock D100 Zigbee
  • Aqara Smart Door Lock N100 Zigbee

Perhaps they have stock of their older Aqara Door Lock S1, Aqara Door Lock S2, or Aqara Door Lock S2 Pro models to test as well(?).

• https://zigbee.blakadder.com/Aqara_ZNMS13LM.html
• https://zigbee.blakadder.com/Aqara_ZNMS12LM.html
• https://zigbee.blakadder.com/Aqara_ZNMS11LM.html

By the way, for additional reference, Zigbee2MQTT have a huge list of supported Zigbee lock products, (which does include Aqara Door Lock S1, Aqara Door Lock S2, or Aqara Door Lock S2 Pro, but not yet the newer Aqara Smart Door Lock A100, Aqara Smart Door Lock D100, or [Aqara Smart Door Lock N100 lock models from Aqara).

• https://www.zigbee2mqtt.io/supported-devices/#e=lock

Nimly lock from Onesti with a Zigbee module looks otherwise be very popular product in Europe:

• https://www.zigbee2mqtt.io/devices/Nimly.html

Exposes:

• lock (state, lock_state)
• battery, sound_volume
• voltage
• last_unlock_source
• last_unlock_user
• last_lock_source
• last_lock_user
• last_used_pin_code
• auto_relock
• auto_relock_time
• max_pin_users
• min_pin_length
• max_pin_length
• pin_code

@elupus suspect that this would need that this would also need there to be support for event platform in Home Assistant's ZHA, or?

• Add initial event support for zha home-assistant/core#157853

Which in turn depends on one of this being merged?

• Add event platform for client cluster #594

or alternativly this?

• RFC: Event platform #419

For reference, it was mentionedin this other pull request that adding elupus's event entity support pull request first is the way to go:

• [RFC] Replace cluster handlers with entity attributes #657

FYI, the Home Assistant 2026.4 release added new triggers and conditions, including “event entities” which could probably be used for that(?). As events are signals that are emitted when something happens, for example, lock was unlocked and which code was last used to open the lock or last lock user.

• https://www.home-assistant.io/blog/2026/04/01/release-20264/#more-triggers-and-conditions-for-existing-domains

  "Event entities now have a generic trigger that fires when any event is received."

IIRC they quickly menationed in yesterday's Home Assistant 2026.4 Release Party video that you can now automate with those.

• https://www.youtube.com/live/5B6VBQ9QyYg?si=5G0O0U3BsWl0pmAS

I am also guessing that the lock entiry might as well need to be extended to expose more properties if want to log history stats(?)

• https://www.home-assistant.io/integrations/lock/

  • https://developers.home-assistant.io/docs/core/entity/lock/

I know that some Zigbee locks like example Nimly Tocuh Pro/Ultimate (from Onesti) expose these properties:

• last_unlock_source
• last_unlock_user
• last_lock_source
• last_lock_user
• last_used_pin_code
• auto_relock
• auto_relock_time
• max_pin_users
• min_pin_length
• max_pin_length
• pin_code

[Hedda]

FYI, for reference, mkerstner mentioned in OpenHomeFoundation/roadmap#70 that he has written down some notes on a first scope for the way forward for credential management (which includes locks and alarm control panels across Zigbee, Z-Wave, and Matter protocols) which he outlined in this initial document:

• https://docs.google.com/document/d/1kHqgRYzKV_FWDjPqZkr_D4B4jG2tf6nGhHUH0W7nBM4/edit?pli=1&tab=t.0#heading=h.3dxiy9s5z2m6

  "At the heart, we aim to fully support door locks / keypads / alarm panels (or “openings” in general) natively from within HA without requiring a 3rd party ecosystem/app and independent of the protocol used. This includes credential management but also of course options to automate upon (scheduling, etc.). The reality as of now is that we are missing some basic functionality for:

  • managing codes (PIN, credentials)
  • RFID tags / fingerprints
  • event logs

  Or at least only have partial support on selected protocols (Z-wave, Zigbee) and rely on using community provided apps and configurations, which generally don’t seem to be that user-friendly for the broader community (e.g. KeyMaster and the amount of entities created).

  From a user’s perspective, coming from ecosystem apps like SmartThings CRUD actions on codes and at least basic audit logs (e.g. who unlocked the door) are mandatory. Going further, extended base use cases like managing multiple users and temporary codes or scheduling need to be included in a sensible baseline as well..

  All major protocol standards like Matter do support this (e.g. Door Lock User / Door Lock Credential clusters for Matter) so implementing it should be possible in HA as well."

Note that the section on "Access Tracking & History" there focus on event logging and actions on events..

[Hedda]

FYI; mkerstner created a new WIP (work-in-progress) roadmap item issue to track the expansion of credential management for locks:

• Expand on credential management for locks OpenHomeFoundation/roadmap#109

For reference, in it he also links to an updated document with his notes on way forward for credential management in Home Assistant which does mention Zigbee:

• https://docs.google.com/document/d/1kHqgRYzKV_FWDjPqZkr_D4B4jG2tf6nGhHUH0W7nBM4/edit?tab=t.0#heading=h.iup5wfolvtoy

PS: Again this is directly related to these other new WIP roadmap items/ideas and tracked epics from the Open Home Foundation:

• Further shape Zigbee support by implementing missing features in ZHA while retaining choice OpenHomeFoundation/roadmap#93

• Leverage a more consistent credential management approach OpenHomeFoundation/roadmap#8

• Further shape our coherent device and protocol support OpenHomeFoundation/roadmap#6

  • Evaluate a stable foundation for protocol-agnostic credential management home-assistant/epics#28

• Credential management for Z-Wave locks OpenHomeFoundation/roadmap#70

  • Z-Wave door lock code management home-assistant/epics#31

[Hedda]

Also see this indirectly related effort by raman325 to try adding a ZHA lock provider to his custom Lock Code Manager component:

• Add ZHA (Zigbee Home Automation) lock provider raman325/lock_code_manager#739

  • [REQUEST] Support effort to add ZHA lock provider to Lock Code Manager integration (available via HACS) #618

For reference, FYI, @raman325 has now merged a new PR that add a ZHA lock provider to his Lock Code Manager (custom component/integration for Home Assistant):

• feat: add ZHA (Zigbee Home Automation) lock provider raman325/lock_code_manager#1091

This will close these feature requests to enable that lock_code_manager integration to support ZHA for Zigbee locks:

• Enable the integration for Zigbee locks. raman325/lock_code_manager#371

  • [REQUEST] Support effort to add ZHA lock provider to Lock Code Manager integration (available via HACS) #618

Proposed change

Adds support for Zigbee locks connected via ZHA. This is a complete rebuild of raman325/lock_code_manager#739 against the current codebase (the old branch was 116 commits behind main with significant API changes).

What it does

Communicates with Zigbee locks through the zigpy DoorLock cluster for PIN code get/set/clear operations.

• Push updates via cluster listeners for operation events (lock/unlock with user ID) and programming events (PIN code changes)
• Programming event detection via event mask attributes, with hourly drift detection fallback when unsupported
• Code slot events for automations (keypad unlock → fire event with user ID)

Architecture

Single-module provider (providers/zha.py) following the same pattern as other providers. Uses managed_slots property, source parameter on async_set_usercode, and the current BaseLock interface.

Test coverage

17 unit tests covering properties, connection checks, cluster access, usercode operations, push subscription lifecycle, and programming event support detection.

PS: Lock Code Manager README.md file has been updated to reflect that a ZHA provider has been added for Zigbee devices:

• https://github.com/raman325/lock_code_manager/blob/main/README.md