Matter Door Lock in SmartThings App

h0ckeysk8er · October 3, 2026, 7:19pm

Ok, looking at both your logs and the current SmartThings Matter lock driver code, I think this makes sense now.

First, you’ve confirmed that the lock supports multiple PIN credentials per user. User 5 now has two PIN credentials and both work, so the 35 PIN capacity is usable even though the lock only supports 11 Matter users.

The reason you can’t create another user is also apparent in the logs. When adding a user, the SmartThings driver walks the Matter user indexes looking for an available slot. Your lock reports all 11 user indexes as occupied, so the driver eventually returns resourceExhausted.

What’s interesting is that only users 4–11 appear in the SmartThings lockUsers capability. But, the lock itself also reports users 1–3 as occupied:

User 1 has an RFID credential and is a REMOTE_ONLY_USER.
User 2 has two RFID credentials plus a PIN credential and is an UNRESTRICTED_USER.
User 3 has two RFID credentials and is an UNRESTRICTED_USER.

So the lock is reporting those users and credentials to SmartThings. They just aren’t being exposed through the lockUsers/lockCredentials capability state.

Looking at the current driver code, that appears to be intentional rather than the lock failing to report them. lockUsers isn’t being used as a complete inventory of every Matter user discovered on the lock. The driver maintains the SmartThings-managed users there, while still querying the actual Matter user table when it needs to find a free user slot.

Similarly, lockCredentials is specifically implemented around Matter PIN credentials. The driver can see the RFID credentials returned by the lock, but it doesn’t expose them through lockCredentials.

That doesn’t mean SmartThings has ruled out non-PIN credentials altogether. The newer driver already has separate support for Aliro credentials through the lockAliro capability. So it appears SmartThings is treating different access technologies separately rather than making lockCredentials a generic container for every Matter credential type. I don’t see an equivalent capability today for managing the RFID credentials your lock is reporting.

Since the lock is also connected to Apple Home, it’s possible that users 1–3 and their RFID credentials are associated with Apple Home/Home Key or some other access mechanism, but the logs don’t establish their origin.

The important part is that those users still occupy real Matter user slots even though SmartThings doesn’t display or manage them. That’s why you see 11 users supported, only 8 users in the SmartThings capability, but still get resourceExhausted when trying to create another user.

So for now, grouping multiple PINs under the existing SmartThings users looks like the practical way to make use of more of the lock’s 35 PIN credential capacity.

I’ve filed issue The lockUsers capability does not appear to accurately represent the Matter Door Lock user database on the Kwikset Halo Select Plus. · Issue #3259 · SmartThingsCommunity/SmartThingsEdgeDrivers · GitHub with Smartthings.

mbs_MA · October 3, 2026, 8:59pm

Thanks so much for your help and insights! I can confirm userids 2,3 are associated with homekeys….I captured some device context in a Sharptools rule that triggers on unlock and see that userid 2 is my phone and userid 3 is my wife’s. Both show method: “rfid”

Userid 1 may remain a mystery .

h0ckeysk8er · October 4, 2026, 2:49am

And a related issue where the ST abstractions could misrepresent the actual lock state:

github.com/SmartThingsCommunity/SmartThingsEdgeDrivers

Users created through `addCredential` can be invisible in Manage Users when `userName` is not populated

opened 02:47AM - 04 Oct 26 UTC

bpinsky123

### Issue: Users created through `addCredential` can be invisible in Manage User…s when `userName` is not populated This appears related to, but distinct from, #3259: **#3259 — `lockUsers` does not accurately represent the underlying Matter Door Lock user database** In this case, the issue occurs when using `addCredential`. The documentation notes that when `addCredential` is used, `userName` is not automatically populated. It recommends subsequently calling `updateUser` to assign a name because the SmartThings app only displays named users in **Manage Users**. This creates a problematic state where a valid Matter user and credential can exist on the lock and in the SmartThings device/driver state, while the user is completely absent from the SmartThings app. For example: ```text Matter lock User 4 └── PIN credential = valid │ ▼ SmartThings device/driver User 4 exists Credential exists userName = null │ ▼ SmartThings App Manage Users └── User 4 DOES NOT EXIST (from user's perspective) ``` The resulting workflow can be particularly confusing: ```text addCredential succeeds ↓ userName isn't populated ↓ user absent from Manage Users ↓ user assumes add failed ↓ tries Add User again ↓ duplicate/conflicting credential/user state ``` ### Expected behavior A valid Matter user should remain visible in **Manage Users** regardless of whether `userName` has been populated. If `userName` is null or empty, the app could display a placeholder such as: ```text User 4 Unnamed User ``` The user could then be renamed through the normal UI. Alternatively, if SmartThings requires every user exposed through Manage Users to have a name, then `addCredential` should ensure that the associated user receives an appropriate default name or otherwise prevent the operation from leaving the user in a state that the SmartThings app cannot display. ### Why this matters This is more than a display issue. The operation has succeeded and the user/credential consumes real resources on the Matter lock. Hiding that user from Manage Users makes the SmartThings application's representation of the lock inconsistent with the actual Matter user database. More generally, **SmartThings capability state and the SmartThings app should accurately reflect the state of the underlying Matter lock**. If the lock reports that a user exists and that user has valid credentials, the SmartThings representation should not make that user effectively nonexistent merely because a display-oriented field such as `userName` has not been populated. Otherwise there can be three different views of the same device: ```text Matter lock state ↓ SmartThings capability/driver state ↓ SmartThings App state ``` Those views should remain consistent. A user or credential that exists and consumes resources on the lock should not disappear as it moves through the SmartThings abstraction layers. The current behavior can also lead directly to additional operations being attempted because the user has no indication that the original operation succeeded. This is similar to the problem described in #3259, where valid occupied Matter user records affect resource allocation but are not represented in `lockUsers`/Manage Users. In both cases there can effectively be different views of the lock: ```text Actual Matter user database ≠ SmartThings user/capability state ≠ Users visible through SmartThings ``` The specific causes are different: * **#3259:** Valid Matter users can occupy user slots but not be exposed through SmartThings, including users created or used by another ecosystem and users associated with credential types that SmartThings does not currently expose/manage, such as RFID. * **This issue:** A valid user associated with a successfully added credential can become invisible because its `userName` is not populated. In both cases, however, the underlying Matter user continues to exist and consume lock resources while being absent from some portion of the SmartThings representation. ### Suggested behavior The SmartThings device state and **Manage Users** UI should reflect the authoritative user state reported by the Matter lock. If a Matter user exists and is known to SmartThings, that user should be represented in `lockUsers` and should remain visible in Manage Users regardless of whether optional descriptive information such as `userName` is present. An empty or null `userName` should therefore result in an **unnamed but visible user**, not an invisible user. More broadly, the SmartThings capability and application layers should preserve the distinction between: * **Whether a Matter user exists** * **Which credentials are associated with that user** * **Whether SmartThings supports management of those credential types** * **Whether the user has a friendly display name** None of the latter three conditions should cause SmartThings to incorrectly represent whether the underlying Matter user exists. This would keep the SmartThings capability state, application state, and actual Matter lock state consistent and prevent valid but invisible users from consuming resources without being represented to the user. ### Potential additional failure path A related case may occur when a Matter user already exists on the lock but is not exposed by SmartThings because it is associated with an unsupported credential type, such as RFID. If `addCredential` is then used to add a SmartThings-supported PIN credential to that existing `UserIndex`, the operation could succeed while the underlying user remains absent from `lockUsers` and Manage Users. The potential sequence is: ```text Existing hidden Matter user └── RFID credential ↓ addCredential(UserIndex, PIN) succeeds ↓ Matter user now has RFID + PIN ↓ User may still be absent from SmartThings ``` Resulting in: ```text Matter lock User 2 ├── RFID credential = valid └── PIN credential = valid │ ▼ SmartThings device/driver User 2 exists PIN credential exists userName = null/not represented │ ▼ SmartThings App Manage Users └── User 2 DOES NOT EXIST (from user's perspective) ``` This should be tested, but if confirmed it would demonstrate that even adding a SmartThings-supported credential does not necessarily reconcile the SmartThings user state with the actual Matter user state. It would also reinforce the underlying issue: **the Matter lock state, SmartThings capability/driver state, and SmartThings App state can diverge even though they are all representing the same underlying user resource.**

Topic		Replies	Views
Added Door State to Matter lock driver Projects	22	926	February 3, 2026
Matter enabled smart lock Devices & Integrations	127	4800	November 15, 2024
Door Locks Fully Supported by ST's Connected Things	176	29722	February 4, 2018
Smart Locks Home Solution? Did miss something? SmartApps & Automations dashboard , locks	47	10081	November 27, 2018
[OBSOLETE] Lock User Management (LUM) Community Created SmartApps smartapp_security , smartapp_locks , project_locks , rboyapps , lum	2407	274856	April 22, 2025

Matter Door Lock in SmartThings App

Related topics