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

Devices & Integrations Community Created Device Types
, , , ,
#1502

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.
image

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

image
image1178×1992 194 KB

1 Like
#1503

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.

2 Likes
Yale lock Yrd256 fail
#1504

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!

#1505

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.

#1506

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?

#1507

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!

#1508

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

#1509

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.

2 Likes
#1510

@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.

#1511

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

#1512

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

[RELEASE] Lock User Management (LUM)
#1513

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

#1514

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

#1515

In the lock user management smart app, I have it setup to send push notifications & text messages when a door is unlocked. If you have this setup, then you can probably see logs in the IDE. I don’t see a way to view such info in the ST app. If the notifications aren’t setup then IDK if they’ll be an entry in the logs in the IDE. I suppose there could be.

#1516

In the old app it logged those push notifications with the lock but the new app sadly does not. So you don’t know who opened the lock when looking at history.

#1517

thanks. i may have to check.

#1518

Strange… I thought my Schlage w/ LUM was able to delay auto-lock before my recent replacement.

Now, my auto-lock activates sooner than I would like.

#1519

@RBoy Any plans to bring different VID to different locks like you do on other DTH?

So we can get a more clean display and remove any unnecessary/unsupported tiles for different locks. And add more features like the smoke sensor for the ID Lock.

I also see that you dont have the automation section defined for you custom capabilities. Any plans to add this so we can use the built automation tool in the ST app for custom capabilities?

#1520

This DTH VID uses a more advanced conditional display for its controls, so they shouldn’t show up when not supported which makes this very flexible and future proof. However conditional displays are broken and it’s still pending a fix from ST. Maybe @nayelyz can provide an update on the status on conditional displays in VID

#1521

Screenshot_20210402_100532_com.samsung.android.oneconnect
Screenshot_20210402_100532_com.samsung.android.oneconnect1080×2340 176 KB

Something has changed now. But not all unsupported tiles are greyed out