[RELEASE] Universal Enhanced Z-Wave Lock Device Handler for Schlage, Yale, Kwikset, IDLock, Popp, Danalock, August Pro, Keywe, Philia, Samsung

That is for the built in tamper siren which is currently only supported by Schalge Connect, BE469ZP, FE469, BE469 lock models (see first post). Those tiles should be hidden when not supported but instead, due to a bug in the new ST, it shows as unsupported when the lock doesn’t support it.

1 Like

So I have used this and the smart app flawlessly before the migration from the classic app. Now I am trying to disable autolock during certain times when I have a lot of people coming and going. From the lock settings I am able to change the duration for my Yale autolock 5-255 seconds but I can’t seem to find a way to disable it all together.

Hey there. If you’re moving from the Classic app to the new app you may want to update your device handler to get access to the advanced lock controls, which includes the ability to enable and disable auto lock via the new app. Please see the instructions in the link below on how to clear the cache after updating the device handler.


Is there a version of this that works with the 4th gen August lock? It’s wifi not Z wave.

Hi rboy, Great work!
How can we get the Lock history to display more information in the New ST app? A lot more content is displayed in the Classic ST app, but the new app only shows Locked/Unlocked.

It’s a limitation/bug with the new ST app. While trying to cut down on the details in the History tab they also ended up ignoring the information reported by all DTH’s from the event description like the user name and slot. SmartThings is aware of it, last I heard they were going to fix it to show the name of the user or slot used to lock/unlock from the DTH events but it seems to have taken a back seat. It always helps to let ST support know about it so they can prioritize fixing it.


So essentially, just adding a dummy code into slot 1 and moving the actual codes into 2, 3, 4, 5, etc… fixed your issue entirely and your pistons began to work as expected?

Currently, my issue is that I’m technically code1 in smartthings lum. However, in webcore piston code1 isn’t working. Nothing executes. When i manually unlock the lock form inside with the turn lever it executes the action in my piston for code1. I was under them impression it’s code0. So confusing…

Slot 0=Code 0 is a Manual open of the door - turning the knob from the inside or using a key on the outside. I manually set slot 1 (using the lock keypad) to 1 of the default codes that came with the lock. Then all user codes are slot 2 and up and I only use the Smart Lock Guest Access smartapp to add/remove them.

My pistons always had problems with slot 0 or 1 trying to get attribute info other than the slot # even if I had a user code stored there from the SmartApp . My current piston detects which code was used in the lock and then takes specific action…lights and an a voice announcement of who came in…depending on who came in the door. But it has been so long since I wrote the piston I can’t remember exactly what the problem was. Either way…do no attempt to store your user codes in slot 0 or 1.

This is what I use to extract the data I need from the lock. I store Slot names as “name #” where # corresponds to their room. We have a hallway light in front of each room that turns on when the front door opens. So the $args.codeName gives me the first name and the room number of who unlocked the door.

Hope this helps.

This is the whole piston

1 Like

WebCoRE has a bug, it treats the slots 0 and 1 as Boolean (0 as false and 1 as true) which is why the pistons don’t work. Until WebCoRE fixes the bug assign your users starting from slot 2 if you want to use WebCoRE pistons (it doesn’t affect any other apps because this a WebCoRE bug). Keep in mind that smart locks doesn’t allow you to select slot numbers. You should use an app like LUM or RLA to assign codes to specific slots.


I have Schlage Connect. The AutoLock from LUM was working for years for me. Now, the AutoLock is not working. Before updating the DTH and SmartApp from your web page, the AutoLock had been working which is I disabled “AutoLock” from LUM. I do not want LUM to AutoLock at all. After updated the DTH and SmartApp from your web page, my Schlage lock would Autlock every 255 seconds. Is this a bug in the SmartApp or your DTH? Thanks!

That’s neither LUM or the device handler. LUM configures re-lock in minutes (not seconds). The DTH can only enable or disable the hardware autolock. Schlage locks are hard codes by the manufacturer to auto lock in 30 seconds and cannot be changed.

Something else is interfering with your setup.

That’s strange. I could disable AutoLock from LUM before. And my Schlage lock would stay “unlocked” for 3 years, and it never re-lock after 30 seconds. After I migrated to New App, I realized I lost all the UI functionality, so I “finally” upgraded the DTH and SmartApp, then this “AutoLock” started to resurrected. What is really causing to AutoLock?

Hey there @RBoy & @625alex … so, I have the same feature request 4 years later… it’s a combination of updates to the Lock DTH and the ULM SmartApp… I’ve search high and low for years now, and it appears that this hasn’t been solved by anyone since the original Solutions were removed in the original SmartThings app…

Basically, all of us normal people, think of a door as a single object that is open or closed AND locked or unlocked. Unfortunately, SmartThings nor ActionTiles have implemented this device definition… but, there is a very similar example… for garage doors, there is a capability called Door Control… this capability has 4 states (that ActionTiles recognizes) Open, Opening, Closed & Closing…

So, my feature request is to add the Door Control capability to this Lock DTH… Then, in the ULM SmartApp, you already match the door locks to the corresponding contact sensor… I’d propose that ULM monitor changes of the Contact Sensor and the Lock and set the new Door Control capability…

I’d propose that Door Control be set to:
OPEN - when contact is open and lock is unlocked
CLOSING - when contact is closed and lock is unlocked
CLOSED - when contact is closed and lock is locked
OPENING - not used, or possibly used if contact is open and lock is locked (not an ideal combination)

When this is implemented, users of ActionTiles can add this Door Control capability as a Tile and we can customize the tile icon for each of these states, such as:
OPEN - Door Open Icon, Accented
CLOSING - Door Closed Icon, Accented
CLOSED - Locked Home Icon, Normal (or more ideally, with a new Locked Door Icon)
OPENING - not used, or Locked Home Icon, Accented, Blinking

This would allow all ActionTiles users to reduce their door tiles from 2 to 1 for each door, saving space and combining these into 1 logical device… many people have asked for a solution to this… if ActionTiles subscribers are not yet RBoy subscribers, you might find a few extra customers as well…

I would really appreciate your consideration for this feature request… this has seriously bugged me and others for a long time now and you have the best foundation to fix this for many of us. Thanks!

@RBoy @maddie - what do you think about adding the Door Control & Contact Sensor capability? Pretty Please!

Appreciate your thoughts. We can add the Door Control capability for the next major update to the device handler with the new architecture.

The current device handler will create a separate contact sensor device if you lock has a built in contact sensor available (e.g. August Pro, IDLock, Yale with DPS etc) which complies with the current platform architecture.


@rog889, Roger, just to clarify, the auto-lock in your Schlage is configurable to be enabled or disabled, but the auto-lock delay is not configurable. I wonder if a factory reset of the lock would correct its weird behavior.

At what level, LUM is compatible with Alfred on both default ST handler and enhanced Z-wave Handler?

my apologies in advance as my question may have been answered and buried deep on previous posts.

i haven’t been checking in as i used to just because this NEW SMARTHINGS APP is just so frustrating ( i do not think it works as well as the CLASSIC version) .

so i wanted to check the history of our 2 locks like i used to with CLASSIC app and i do not see it anywhere?

how do i get it back? thanks in advance. locks are both SCHLAGE BE469 @RBoy @maddie

Tap the lock and then in the bottom right press history.

Thanks. that’s a start, but i was also looking at getting a log of of who unlocked the doors. thanks.