The profile may not be the problem, it uses the “lock” capability and the driver can specify the source of the operation (see the “data” associated to the lock attribute in the capability, it supports a few reasons like manual, keypad, auto, face, rfid, etc.). So, the information is there and the SmartThings platform knows.
But you’re right and it’s not available for the user because SmartThings didn’t create a user interface for that. Just like happens with the brightness transition time for lights or the relative volume for Sonos, the production capability supports it but they never made the user interface for those features. In fact, you can’t even create custom capabilities with multiple arguments in one action, only the first argument will appear in the presentation.
Regarding the “new-matter-lock” driver, I guess the point is eventually making it the main one, otherwise it would not be called “new” but something more meaningful or feature-specific. Indeed, it’s hardcoded to only support a couple Aqara locks and one from VDE.
Well, a few things here. Since ST has already added some of the features you need as a part of the new subdriver, you could add the fingerprints for your device to fingerprints.yml file, create a profile for your lock, and add the fingerprints to the subdriver code yourself. That would get you any feature that your lock supports that is already defined and handled in the matter-lock driver/subdriver. You would still need to submit those changes to the ST repo in order for them to be included in the stock driver (see below).
For any feature not already supported, you would need to define the custom capabilities and develop handlers to be added to the matter-lock driver. Prior to Matter, if you were working to get the “Works With SmartThings” designation, you could then submit a PR against the ST Edge Driver repo to get your code submissions added to the existing drivers. I’m not clear how that works now with CSA certification and if you still need WWST designation in order to submit code the ST repo. @nayelyz would likely be able to provide more insight since she is in ST Developer Support and would know the process(es) better than I would.
Yes, the CSA certification is different than WWST, the last one verifies that all the functionalities of the device work correctly in SmartThings to guarantee a good user experience. However, if it’s necessary to implement custom capabilities, it won’t be eligible for WWST since they are not supported in that process.
You can still develop your driver and share it with users through a Driver Channel invitation but you won’t be allowed to use the SmartThings logo to indicate it’s supported in the platform.
So, if his driver uses only stock/production capabilities and can make use of the features of the matter-lock driver/subdriver, can he add the fingerprints and create a profile and do a PR or does someone from ST have to submit those changes?
Note: This is only when a new sub-driver/profile is needed, if only the fingerprint needs to be added, a PR is not necessary, only the certification request and follow all the steps.
After that I installed the new packge on my hub, now I can see Manager users option and able to set users and code. Also able to use code on lock. But I am not getting schedules and battery information on SmartThings app as previously I was getting battery level with base-lock.yml.
What do you mean by schedules?
About the battery report, I see you have the capability included and I’m guessing you’re using the default handlers, right?
Have you checked if the device is configured correctly during the joining process? That should be seen in the driver logs (logcat command)
@nayelyz I mean lockSchedules and yes I am using default handlers.
For battery I get this in logs (Matter Lock Attempted to generate event for a41c4757-39e4-423a-b6fe-48246a2df513.main but it does not support capability Battery)
Have you queried the profile used by that device? For this, you need to get the device’s details and you’ll find the profile ID it’s using
I’ve seen that message appear when the capability
Ah, do you mean the capability called “lockSchedules”? Can you describe what you’re trying to do and what doesn’t work, please?
This is a capability that has the status of “proposed” and the engineering team has mentioned that this type of capabilities can have some bugs.
I want to set schedules from SmartThings app. but there is not option in ST app to set schedules. Please refer to matter specification and see door lock to find about use of schedules.
SmartThings Guest Access does not work with the Matter lock we just bought to try this out. There is a separate interface on the device screen itself that allows you to set and delete pins, SLGA simply errors:
I’m trying to use the Advanced console to see what commands are used for adding pins to Matter locks, but I do not see any events being shown for these commands I enter within the app to create guest codes. I also cannot find any documentation anywhere that explains how you use the ST API to replicate what is happening in the Matter lock device itself.
Has anyone used a Matter lock and have any experience with how you can control pins using the ST API or even see the commands in the event logs?
Yes, Matter locks are transitioning from using centralized locks codes via SLGA and the lockCodes capability to lock codes managed on the device card itself. To support that, two new capabilities are being used, lockUsers and lockCredentials. You should see those capabilities in the Attributes section of the AWA for your lock. You should also see commands associated with those capabilities in the Commands section of the AWA. Now commands are not events in and of themselves, so you may not see anything in the history as to what command is being used for what function, but rather just the outcome of that command such as “User Bob added to Lock Foo”. Given what’s in the source code, I would expect there to be commands for:
main.lockUser.add
main.lockUser.update
main.lockUser.delete_user
main.lockUser.delete_all_users
main.lockCredentials.add
main.lockCredentials.update
main.lockCredentials.delete_credential
main.lockCredentials.delete_all_credentials
For determining which API calls are being used for commands associated with the lockUsers and lockCredentials capabilities, I suggest installing the ST CLI on a Linux/Windows/macOS computer and issuing commands with the debug mode enabled via " SMARTTHINGS_DEBUG=true smartthings ". This will show you the API calls being issued for a command. Here is an example:
bep@debian12: SMARTTHINGS_DEBUG=true smartthings devices:commands
...
...
? Enter capability index or id 3
[2025-05-09T12:48:05.071] [DEBUG] login-authenticator - authentication - enter
[2025-05-09T12:48:05.072] [DEBUG] rest-client - making axios request: {"url":"https://api.smartthings.com/capabilities/lockCodes/1","method":"get","headers":{"Content-Type":"application/json;charset=utf-8","Accept":"application/json","User-Agent":"@smartthings/cli/1.10.2 linux-x64 node-v18.5.0","Accept-Language":"en-US","Authorization":"Bearer 2cae7e32-xxxx-xxxx-xxxx-xxxxxxxxxxxx"}}
Commands:
───────────────────────────────────────────────────────────────────
1 setCodeLength(length<integer>)
2 reloadAllCodes()
3 unlock()
4 unlockWithTimeout()
5 setCode(codeSlot<integer>, codePIN<string>, codeName<string>)
6 updateCodes(codes<JsonObject>)
7 lock()
8 requestCode(codeSlot<integer>)
9 deleteCode(codeSlot<integer>)
10 nameSlot(codeSlot<integer>, codeName<string>)
───────────────────────────────────────────────────────────────────
? Enter command 2
[2025-05-09T12:48:23.941] [DEBUG] login-authenticator - authentication - enter
[2025-05-09T12:48:23.942] [DEBUG] rest-client - making axios request: {"url":"https://api.smartthings.com/devices/95130d4e-xxxx-xxxx-xxxx-ad6013361692/commands","method":"post","headers":{"Content-Type":"application/json;charset=utf-8","Accept":"application/json","User-Agent":"@smartthings/cli/1.10.2 linux-x64 node-v18.5.0","Accept-Language":"en-US","Authorization":"Bearer 2cae7e32-xxxx-xxxx-xxxx-xxxxxxxxxxxx"},"data":{"commands":[{"component":"main","capability":"lockCodes","command":"reloadAllCodes"}]}}
Command executed successfully
Thanks for the info, this is very helpful. I was playing around using Postman and was able to get ST to accept the command, but the lock never did anything, and without events being generated, I can’t see anything anywhere that tells me anything about why the command didn’t work.
I don’t see any events to give me feedback on the issues, and don’t see any other apparent way to determine the issue. Any suggestions on what may be going on here, or how I can see the status of the command ST executed after it received my request?
Also, I’m not sure I understand addCredential and addUser. In the case above, I’m adding a pin to the lock as a guest. But I can’t associate a name with that pin using addCredential, and addUser doesn’t allow me to associate the name with the pin or the slot, so I have no idea how I can keep credentials organized with names associated to them.
Does anyone know how this is supposed to be used and how you can manage pins in a meaningful way with names associated to them?
Typically, there should be an event emitted after the command is executed. So, after adding a credential like a PIN, you should see an event in history to indicate that something happened. You should also be able to look at the capability in the Attributes section of the AWA and see that the capability has been updated with the info you added.
Another way to do some checking on what is happening is using driver logging in the ST CLI. You can issue the command “smartthings edge:drivers:logcat” and select the matter-lock driver. Issue your command via the API/AWA/CLI and you should see the request come to the driver, the driver issue the command to the lock, and the lock respond. You would also see the driver emit the event for the action that was performed.
So, looking at the Matter spec, there is a notion that a lock can support a user and that a user can have multiple credential types. Here is an excerpt:
5.2.4.1. PINCredential Feature
If the User Feature is also supported then any PIN Code stored in the lock SHALL be associated with
a User.
A lock MAY support multiple credential types so if the User feature is supported the UserType, UserStatus
and Schedules are all associated with a User index and not directly with a PIN index. A User
index may have several credentials associated with it.
Now, I don’t have a Matter lock to do some fiddling with, so I can’t really do some experimenting to figure out how it might work. I would suggest using either the CLI or the AWA to issue commands vs noodling with the API because both of those offer structuring of the commands via their UI. What I mean is that you will be prompted for the specific attributes required to execute that command. Here is an example of adding a lock code for a Z-Wave lock via the AWA:
