You just select a different one like Zwave lock in the drop down list when you select edit on the device. Then click update.
I hope that’s the right names I’m just going by my old man memory.
If not I’m sure someone will correct me and bail me out.
3 Likes
Is there any reason why I’m not seeing the code slot used for unlocking my Yale Conexis in the SmartThings history? I can see the detail in the Device Events “displayed text” in the IDE, but not in the tile history in ST app. I’ve tried updating and swapping the device handlers between this DH and the default “z-wave lock”, but still no detailed history. I’m using the unlock notifications smart app and I get the detailed notifications.
It’s a display bug with the new ST app, it doesn’t display that information correctly (not related to any DTH or SmartApp which is why you get the notifications correctly and the information in the IDE). It’s been reported to ST and hopefully they’ll eventually fix it. You could send in a report to support@smartthings.com with screenshots and let them know that History page isn’t showing the descriptionTextfor lock/unlock events like the Classic app used to.
1 Like
Will do. Many thanks.
You are the man!!! You saved me, possibly many more people in the future! I had the same problem, couldn’t see the new UI, then I followed your instruction, and it worked!!! Thanks thanks thanks a billion!!!
1 Like
Universal Enhanced Z-Wave Plus Lock Device Handler - Version 05.02.00
- (Enhanced) Programming Popp keypads (requires re-pairing for the changes to take effect)
- (New) Ability to change code length for Schlage Connect, BE468, BE469, BE469ZP, BE468ZP locks. Note: changing the code length causes all existing codes to be removed from the lock. If you’re using LUM or RLA, these apps will try to reprogram the users so be sure to update the users with the correct pin codes lengths.
Please make sure that your lock is within 20ft of a buffering device/repeater for best performance and reliability.
NOTES
- If you’re upgrading from version 4.x or older: the UI may not reflect the new changes due to platform caching. One way to force the cache to clear is to change the device handler to a “Z-Wave Lock” and then back to this enhanced device handler from the IDE, then sign out of the ST mobile app and sign back in. If nothing else works, you may need to exclude your device, delete the device handler and reinstall it if the UI does not update after 24 hours.
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.
3 Likes
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.
4 Likes
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.
2 Likes
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!