[ST EDGE] Z-Wave Lock PH

I need turn off the lights when the door is locked by pressing the Schlange button on the keypad (not by entering a code)

The driver doesn’t expose how or by what code or code name the lock is locked. Only the code name used to unlock is exposed. SLGA provides a notification of which lock code name is used to lock the door, however, there isn’t a way to write a Routine based on that notification in the ST app.

That said, you should be able to use the 3rd party tool sharptools.io to create a rule based on the event data emitted by the lock event to do what you want (requires their premium service). Here is an example:

1 Like

I understand, Thank you

Hi everyone - I briefly read through the thread but couldn’t find anything on this (if there is can you point me at it) but is anyone else getting “unlock” events when the locks are actually “locked”?

I get these via Smart Guest Lock Access, and I’m also getting it as events in SharpTools

Haven’t seen that. Which version of the driver are you using, the 1.0 or the Beta? What lock do you have? Can you please get driver logging from the ST CLI using the command “smartthings edge:drivers:logcat” and post here?

Hey there - I’m using the PH BETA driver, lock is a Schlage BE469

Here are the command line events for when I manually lock the lock

2023-05-24T16:16:14.460053779+00:00 TRACE Z-Wave Lock PH BETA  Received event with handler unnamed
2023-05-24T16:16:14.462634820+00:00 INFO Z-Wave Lock PH BETA  <ZwaveDevice: XXX-XXX [1E] (Front 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-05-24T16:16:14.555246737+00:00 TRACE Z-Wave Lock PH BETA  Found ZwaveDispatcher handler in zwave_lock -> Schlage Lock -> Schlage BE469
2023-05-24T16:16:14.555975279+00:00 INFO Z-Wave Lock PH BETA  <ZwaveDevice: XXX-XXX [1E] (Front Door Lock)> emitting event: {"state":{"value":"locked","data":{"method":"manual"}},"capability_id":"lock","attribute_id":"lock","component_id":"main"}
2023-05-24T16:16:14.566519570+00:00 INFO Z-Wave Lock PH BETA  <ZwaveDevice: XXX-XXX [1E] (Front Door Lock)> emitting event: {"state":{"value":"Locked"},"capability_id":"platinummassive43262.unlockCodeName","attribute_id":"unlockCodeName","component_id":"main"}
2023-05-24T16:16:14.567366112+00:00 DEBUG Z-Wave Lock PH BETA  Front Door Lock device thread event handled
2023-05-24T16:16:14.703078195+00:00 TRACE Z-Wave Lock PH BETA  Received event with handler capability
2023-05-24T16:16:14.712671404+00:00 TRACE Z-Wave Lock PH BETA  Z-Wave command(462cae7d) queued for radio transmission: CC:Door Lock, CID:0x01
2023-05-24T16:16:14.714323987+00:00 INFO Z-Wave Lock PH BETA  <ZwaveDevice: XXX-XXX [1E] (Front Door Lock)> received command: {"component":"main","capability":"lock","command":"unlock","positional_args":{},"args":{}}
2023-05-24T16:16:14.716359987+00:00 TRACE Z-Wave Lock PH BETA  Found CapabilityCommandDispatcher handler in zwave_lock
2023-05-24T16:16:14.717521654+00:00 INFO Z-Wave Lock PH BETA  <ZwaveDevice: XXX-XXX [1E] (Front Door Lock)> sending Z-Wave command: {args={door_lock_mode="DOOR_UNSECURED"}, cmd_class="DOOR_LOCK", cmd_id="OPERATION_SET", dst_channels={}, encap="AUTO", payload="\x00", src_channel=0, version=1}
2023-05-24T16:16:14.726422070+00:00 DEBUG Z-Wave Lock PH BETA  Front Door Lock device thread event handled
2023-05-24T16:16:14.727107279+00:00 DEBUG Z-Wave Lock PH BETA  driver device thread event handled
2023-05-24T16:16:16.148668654+00:00 TRACE Z-Wave Lock PH BETA  Z-Wave command(462cae7d) transmit status: TRANSMIT_COMPLETE_OK
2023-05-24T16:16:16.466970487+00:00 TRACE Z-Wave Lock PH BETA  Received event with handler unnamed
2023-05-24T16:16:16.467526571+00:00 INFO Z-Wave Lock PH BETA  <ZwaveDevice: XXX-XXX [1E] (Front Door Lock)> received Z-Wave command: {args={status="TRY_AGAIN_LATER", wait_time=0}, cmd_class="APPLICATION_STATUS", cmd_id="APPLICATION_BUSY", dst_channels={}, encap="S0", payload="\x00\x00", src_channel=0, version=1}
2023-05-24T16:16:16.476326654+00:00 DEBUG Z-Wave Lock PH BETA  Front Door Lock device thread event handled
2023-05-24T16:16:18.937091487+00:00 TRACE Z-Wave Lock PH BETA  Z-Wave command(d2b826b4) queued for radio transmission: CC:Door Lock, CID:0x02
2023-05-24T16:16:18.938545612+00:00 INFO Z-Wave Lock PH BETA  <ZwaveDevice: XXX-XXX [1E] (Front Door Lock)> sending Z-Wave command: {args={}, cmd_class="DOOR_LOCK", cmd_id="OPERATION_GET", dst_channels={}, encap="AUTO", payload="", src_channel=0, version=1}
2023-05-24T16:16:18.941746071+00:00 DEBUG Z-Wave Lock PH BETA  driver device thread event handled
2023-05-24T16:16:20.388771571+00:00 TRACE Z-Wave Lock PH BETA  Z-Wave command(d2b826b4) transmit status: TRANSMIT_COMPLETE_OK
2023-05-24T16:16:20.656493988+00:00 TRACE Z-Wave Lock PH BETA  Received event with handler unnamed
2023-05-24T16:16:20.657049613+00:00 INFO Z-Wave Lock PH BETA  <ZwaveDevice: XXX-XXX [1E] (Front Door Lock)> received Z-Wave command: {args={door_condition=0, door_lock_mode="DOOR_SECURED", inside_door_handles_mode=0, lock_timeout_minutes=254, lock_timeout_seconds=254, outside_door_handles_mode=0}, cmd_class="DOOR_LOCK", cmd_id="OPERATION_REPORT", dst_channels={}, encap="S0", payload="\xFF\x00\x00\xFE\xFE", src_channel=0, version=1}
2023-05-24T16:16:20.676494946+00:00 TRACE Z-Wave Lock PH BETA  Found ZwaveDispatcher handler in zwave_lock
2023-05-24T16:16:20.676927571+00:00 INFO Z-Wave Lock PH BETA  <ZwaveDevice: XXX-XXX [1E] (Front Door Lock)> emitting event: {"state":{"value":"locked"},"capability_id":"lock","attribute_id":"lock","component_id":"main"}
2023-05-24T16:16:20.679668863+00:00 DEBUG Z-Wave Lock PH BETA  Front Door Lock device thread event handled

when i manually unlock this is fired:

2023-05-24T16:17:32.190122539+00:00 TRACE Z-Wave Lock PH BETA  Received event with handler unnamed
2023-05-24T16:17:32.193096539+00:00 INFO Z-Wave Lock PH BETA  <ZwaveDevice: XXX-XXX [1E] (Front Door Lock)> received Z-Wave command: {args={alarm_level=1, alarm_type=22, event="MANUAL_UNLOCK_OPERATION", event_parameter="", notification_status="ON", notification_type="ACCESS_CONTROL", v1_alarm_level=1, v1_alarm_type=22, z_wave_alarm_event="MANUAL_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="\x16\x01\x00\xFF\x06\x02\x00", src_channel=0, version=3}
2023-05-24T16:17:32.252801330+00:00 TRACE Z-Wave Lock PH BETA  Found ZwaveDispatcher handler in zwave_lock -> Schlage Lock -> Schlage BE469
2023-05-24T16:17:32.258336580+00:00 INFO Z-Wave Lock PH BETA  <ZwaveDevice: XXX-XXX [1E] (Front Door Lock)> emitting event: {"state":{"value":"unlocked","data":{"method":"manual"}},"capability_id":"lock","attribute_id":"lock","component_id":"main"}
2023-05-24T16:17:32.259420289+00:00 INFO Z-Wave Lock PH BETA  <ZwaveDevice: XXX-XXX [1E] (Front Door Lock)> emitting event: {"state":{"value":"manual"},"capability_id":"platinummassive43262.unlockCodeName","attribute_id":"unlockCodeName","component_id":"main"}
2023-05-24T16:17:32.261959705+00:00 DEBUG Z-Wave Lock PH BETA  Front Door Lock device thread event handled

So, I see the following:

  • The lock is manually locked and the driver emits the events
  • The driver receives a command (from App/CLI/API) to unlock the lock
  • Z-Wave command to unlock is sent
  • Driver receives a Z-Wave command of “Try Again Later” which seems to be indicate that the lock was not able to unlock
  • Driver sends a Z-Wave command to retrieve the state of the lock
  • Driver receives Z-Wave command with the status
  • Driver emits event indicating that the lock is locked

So, it looks like the unlock fails and then the locked is reported as locked. Is that what you are seeing?

2 Likes

I am manually locking the lock and then I receive an alert on my phone via SLGA that the lock was “unlocked”.

I’m not kicking off any command via the App or CLI… so I am now wondering if I have something using the API to react to the manual lock… or if this is SLGA

Next, I would look at a couple of other places:

  • Check the SLGA History to see what it thinks is happening
  • Check ST History (3 bar menu)->History to see what might be triggering the unlock
  • Check the lock’s device history to see what it thinks is happening
  • Check the Routines tab on the lock’s device panel to make sure there aren’t any Routines you’ve forgotten about

Do you have the Schlage Skill for Alexa installed? If so, make sure there aren’t any Alexa routines in play as well.

So it was a routine that was a bit too aggressive on triggering for presence - added a bit of a wait on a state and that did the trick.

Thank you again for the help

1 Like

Hi @philh30

Just checking in to see if the Beta Drivers will be folded into the Main Driver anytime soon?

I’ve been using (loving) your Z-Wave Lock PH v1.00 drivers for quite some time. I wanted to utilize some of the features of your Beta Drivers, but am concerned about losing my Custom Code Names. I’ve read mixed results of some users transitioning and losing them, while others have retained them.

Thanks!

anyone get unlock codes as a trigger in a routine working for the yale assure with z wave?

@philh30 - I’m a little late to the game here. Is the “Locked” logic due to limitations or just an assumption that nobody cares? I could be an edge case, but routines based on how the door is locked and lock code used are incredibly useful and equally important as unlock. Perhaps the most simple example is leave routines. When locking from the outside with a certain code, arm STHM and perform other “away” activities (turn off lights, ensure all locks are locked. Simply locking a door manually from the inside should not trigger the routine. Going back through this thread, there seems to be some interest in this capability and I’d prefer not to introduce another layer such as sharptools if possible.

@Perigord My Schlage lock reports different code for inside and for outside
When we lock/unlock from inside it’s reporting Manually
When we lock from outside it’s reporting Master Code
And all users are reported by their names
This is one day’s example


You can build routines based on this, however locking Manually or by Master Code is not different with current driver.
If @philh30 can add that, then you could build routines for locking for inside and outside.
If I remember limitation came from amount of capabilities that devices can have. Only way this could be solved if Lock State can be modified to show Locked Manually and Locked by Master Code. This is something that only @philh30 knows.
.

It’s sort of a technical limitation. There is no capability in the default lock handler that captures and exposes the slot code name used for lock/unlock events. Phil kindly created a custom capability for exposing the unlock slot code name but didn’t create one for locking slot code name. So, even though you see the slot code name in history for lock events, that’s just a logging event that doesn’t persist the name for other purposes.

We could certainly ask Phil to create a custom capability for the lock that exposes the name for the lock events, however, he is primarily working on stuff for Hubitat and may not have the time or interest to do it. The other option would be to get him to publish the beta version code so someone can do the coding and either do a pull request against his repo or do a derivative of his work and publish a new driver.

If someone absolutely needs actions triggered by the slot code name for locking events, there are two options that I know of. 1) the Rboy driver claims to support slot code names in Routines, but I haven’t tried it because the author is charging for the driver (@bthrock may be able to comment). 2) Sharptools rule engine supports variables and allows you to access the slot code name that is part of the Z-Wave event data for lock/unlock events. Two things with this solution is that you have to pay for their premium service and the routines run in their cloud and call the ST APIs to invoke actions.

1 Like

You can only build Routines based on the slot code name for unlock events. That’s the capability Phil created. The names you see in history are just event data put into logging messages. Nothing is persisted for other activities.

See my post above for more details.

So a limitation of the driver in its current state and not something SmartThings suppressed from driver developers, although I’m sure it’s not well documented. Tremendously appreciate the work @philh30 has done for this and other drivers - light years ahead of stock drivers from SmartThings. Looking like I’m heading towards one of the other paths. I must have missed something with rboy’s driver, but the community discussion implies Phil’s driver is superior. I’ll give a re-read.

Having a problem with the auto lock function showing on my ZWP Schlage locks. I’ve trien both PH v1.00 driver and beta, neither will show the auto lock function on all 3 of my locks. Because of this, I get the “device hasn’t
updated…” error every time I open any of my 3 locks. Any suggestions? Thanks


Create a scene to change the auto-lock and run it (no need to save). The driver should poll and update just that feature.

1 Like

Have you tried:

  1. Battery pull
  2. Hub Reboot
  3. Switching Drivers to Stock; then back to Lock PH?