In Webcore, I had a piston that would turn on the entry light when the door was unlocked, but only if it was unlocked with a code, meaning coming INTO the house rather than leaving… Is this possibleto accomplish this with a RULE? I don’t see it’s possible with the app automations as lock code is not exposed, but maybe with the RULEs API, or maybe an changed by attribute to tell if it was locked/unlocked manually (inside going out), code or zwave function (unlocked by an automation or rule or scene) in addition to which code or name associated to that code as defined in the smart lock guest access
I am looking for a solution similar as your use case. I put a test json to see if I can match lockCodes to identify a specific person but it seems not working.
It would be useful to know how webCore got this information. I’m guessing it was thanks to a custom attribute in the DTH. Do you have an example of DTH used by the device which you could get this info from?
The SmartLock SmartApp you mention is the one from Rboy?
This is hard to answer, I can open a feature request but I need the correct details and it will depend on the team’s analysis, that’s why I asked for more info.
And, there’s a SmartApp in the ST app called “SmartThings Lock Guest Access” that helps you define the lockCodes for the device but it doesn’t have the info you mention.
Also, something important to note is that:
The team can create a new standard capability or edit the current one which takes some time but this doesn’t mean that existing devices will have it.
For it to populate as you mention “locked/unlocked by code, manual, hub command”, the device handler (driver or else) would have to process the command received and determine where it comes from which wouldn’t be possible because all sources generate the same event and it doesn’t include any field to define the source (this happens for all capabilities).
By this, I mean: If you click the button to “lock” in the app, it would generate a command having the following info:
If you send a command from the API / Rule, you need the same info.
If a device sends an update to the Hub that the status has changed, it will be processed and to generate the capability event, it will include only the new lock status and the component where it changed.
So, they cannot be differentiated from each other automatically, especially because, when you change a device status from the app, its controller will send a message/command to it and the device will respond with the updated status, each integration developer would have to apply some logic to somehow identify that better.
I can help you there. The information about the code used etc is carried in the lock event data and that is where webCoRE was able to read it from. There is nothing custom about it, that is the standard way it is handled in ST.
Unfortunately the event data isn’t exposed to Rules based automations.
Sorry for the delay.
Thank you for the information. Now that I see the events, this is clearer now.
The values are in the emitted event, so, if you check the device status, you should see the data of the latest event. Can you help me confirm, please?
You can use this command:
smartthings devices:status deviceID
I’ll ask the team about this to see if there’s a way to accomplish this using a Rule.
it seems that the Driver is about 90%. i just tested this, i locked the door with my code (#1) and then checked the status. the code used to lock the lock (or unlock) does not seem to have an attribute, but the lockCodes and names are… which is a good thing,
now just need to see the code# that was used to perform the lock\unlock function. the “how it was locked or unlocked” is of lesser importance to me, but would still be very useful. if the lock was unlocked\locked by a rule, then there could be different behavior versus if I came home (i want the lights to be turned on just inside the door area)
it could be, that if the code is not populated, then a user wasn’t directly involved so it could be inferred that the lock was either locked by the manual knob or button on the outside, OR by automation, either way specific actions based on that may not be needed
if by automation, that automation\rule could have all the other tasks to perform.
if by manual knob, then user is leaving (most likely, so less likely any actions were needed)
right now, the Driver is only exposing the ‘lock’ capability and not the lockCodes capability. that and which code was used to perform the action. is the battery capability exposed too?
in fact, the value is indeed there… in the event data, the value is codeId
2023-02-14T20:15:54.226835528+00:00 TRACE Z-Wave Lock Received event with handler unnamed
2023-02-14T20:15:54.231296195+00:00 INFO Z-Wave Lock <ZwaveDevice: 364da5c0-25cb-4865-869e-986c92aa3841 [97] (Garage Door Lock)> received Z-Wave command: {args={alarm_level=2, alarm_type=19, event="KEYPAD_UNLOCK_OPERATION", event_parameter="\x02", notification_status="ON", notification_type="ACCESS_CONTROL", v1_alarm_level=2, v1_alarm_type=19, z_wave_alarm_event="KEYPAD_UNLOCK_OPERATION", z_wave_alarm_status="ON", z_wave_alarm_type="ACCESS_CONTROL", zensor_net_source_node_id=0}, cmd_class="NOTIFICATION", cmd_id="REPORT", dst_channels={}, encap="S0", payload="\x13\x02\x00\xFF\x06\x06\x01\x02", src_channel=0, version=3}
2023-02-14T20:15:54.273287195+00:00 TRACE Z-Wave Lock Found ZwaveDispatcher handler in zwave_lock
2023-02-14T20:15:54.651939195+00:00 INFO Z-Wave Lock <ZwaveDevice: 364da5c0-25cb-4865-869e-986c92aa3841 [97] (Garage Door Lock)> emitting event: {"attribute_id":"lock","capability_id":"lock","component_id":"main","state":{"data":{**"codeId":"2"**,"codeName":"Code 2","method":"keypad"},"value":"unlocked"}}
2023-02-14T20:15:54.678194862+00:00 TRACE Z-Wave Lock Found ZwaveDispatcher handler in zwave_lock
2023-02-14T20:15:54.679058862+00:00 TRACE Z-Wave Lock Found ZwaveDispatcher handler in zwave_lock
2023-02-14T20:15:54.680271528+00:00 TRACE Z-Wave Lock Found ZwaveDispatcher handler in zwave_lock
2023-02-14T20:15:54.686731528+00:00 DEBUG Z-Wave Lock Garage Door Lock device thread event handled
2023-02-14T20:15:57.575883863+00:00 TRACE Z-Wave Lock Received event with handler unnamed
2023-02-14T20:15:57.577395863+00:00 INFO Z-Wave Lock <ZwaveDevice: 364da5c0-25cb-4865-869e-986c92aa3841 [97] (Garage Door Lock)> received Z-Wave command: {args={alarm_level=1, alarm_type=21, event="MANUAL_LOCK_OPERATION", event_parameter="", notification_status="ON", notification_type="ACCESS_CONTROL", v1_alarm_level=1, v1_alarm_type=21, z_wave_alarm_event="MANUAL_LOCK_OPERATION", z_wave_alarm_status="ON", z_wave_alarm_type="ACCESS_CONTROL", zensor_net_source_node_id=0}, cmd_class="NOTIFICATION", cmd_id="REPORT", dst_channels={}, encap="S0", payload="\x15\x01\x00\xFF\x06\x01\x00", src_channel=0, version=3}
2023-02-14T20:15:57.681717530+00:00 TRACE Z-Wave Lock Found ZwaveDispatcher handler in zwave_lock
2023-02-14T20:15:58.444180864+00:00 TRACE Z-Wave Lock Found ZwaveDispatcher handler in zwave_lock
2023-02-14T20:15:58.446421197+00:00 TRACE Z-Wave Lock Found ZwaveDispatcher handler in zwave_lock
2023-02-14T20:15:58.448735530+00:00 TRACE Z-Wave Lock Found ZwaveDispatcher handler in zwave_lock
2023-02-14T20:15:58.450950197+00:00 DEBUG Z-Wave Lock Garage Door Lock device thread event handled
when i attempted to create a rule with codeId as an attribute to the lock capability, it barfed…but i expected that as that isn’t documented in the production capabilities for lock
Error: Request failed with status code 422: {"requestId":"CB263434-86BE-4E1B-9E4B-CE0409B4E9FE","error":{"code":"ConstraintViolationError","message":"The request is
malformed.","details":[{"code":"ConstraintViolationError","target":"{\"devices\":[\"364da5c0-25cb-4865-869e-986c92aa3841\"],\"component\":\"main\",\"capability\":\"lock\",\"attribute\":\"codeId\"}","message":"invalid
attribute","details":[]}]}}
Based on the events, the info about the method used to open the lock and the codeID is saved in a sub-property of the lock attribute called “data”, so, as the CLI presents all values into a table, it might not be including them. Please, add -y or -j at the end of the command to see the complete info in YAML or JSON format respectively.
The problem is that we can know for sure if the method manual or keypad was used because the device sends a different type of event for each, but there won’t be a difference between the SGLA or a Rule.
I asked some members of the team about this and we think it’s not possible to create a Rule with the current configuration because “data” is not a direct attribute of the capability and its content is an object with the properties we need as a condition inside.
So, I’ll create a feature request, to get feedback from the Rules team.
@philh30 did something similar in his beta version of the Z-Lock driver to show you the unlock method or code name used for unlocking on the device panel and history. He added a capability in Main for exposing who/how the door was unlocked.
? Select a component. 1
────────────────────────────────────────
# Id
────────────────────────────────────────
1 battery
2 lock
3 lockCodes
4 platinummassive43262.unlockCodeName
5 refresh
────────────────────────────────────────
6 tamperAlert
────────────────────────────────────────
? Select a capability. 4
──────────────────────────
Attribute Value
unlockCodeName "Locked"
──────────────────────────
2/11/2023, 10:17:17 AM main platinummassive43262.unlockCodeName unlockCodeName manual
2/11/2023, 10:17:17 AM main lock lock unlocked
2/10/2023, 8:50:44 PM main platinummassive43262.unlockCodeName unlockCodeName Bruce and Teri
2/10/2023, 8:50:44 PM main lock lock unlocked
2/10/2023, 8:50:36 PM main platinummassive43262.unlockCodeName unlockCodeName Locked
2/10/2023, 8:50:35 PM main lock lock locked
Using Routines is certainly a lot more user friendly that having to write Rules. So @nayelyz, his work could be incorporated (or be a model for an implementation) into the stock drivers for Z-Wave and Zigbee locks so that it is available without having to use a community Edge driver. Frankly, I think all of his work that exposes more capabilities for Schlage and other locks should become part of the stock drivers.
Is this just with the beta version, or his other (stable?) version too? Do you know if this capability works for all brands, or is it part of the enhancements specifically for Schlage?
My locks and CT-100 thermostat are the only things left to switch over to Edge, and this sounds good enough to make the jump for. I’ve been hoping RBoy would at least release drivers at some point, but I’m done waiting and this would fix the last piece of LUM that I haven’t been able to substitute.
Only the beta driver has the lock code name enhancements AFAIK. I don’t know if he did it specifically for Schlage locks or not because 1) I only have Schlage locks and 2) he has not made the source code for the beta driver available in his public Github. @philh30 Can you integrate the enhancements from the beta driver back into the released driver?
i also have Schlage locks, and switched to the beta driver and i have the capability. i did see the fingerprint file seems very complete, but cannot confirm that the specific lock code capability is available to all.