What is interesting is that using the scheduled door lock app, if the door is already locked, it will beep like it is locking the door, but the motor doesn’t turn.
Looks like I will stick to that instead of Autolock, just to make sure door isn’t unlcoked overnight.
Still wish there was a simple app that allows customized time for autolocking, but checks to make sure door is unlocked before it autolocks.
Any SmartApp should work fine with this DTH. SmartApps use capabilities (commands and attributes) that do not matter whether the DTH is Z-Wave or ZigBee.
Is the reason why the Autolock tops out at 180 secs is because of hardware limitations? I have a Yale Zigbee keypad lock.
Based on spec, much higher numbers can be used. However, I’ve not had luck with Yale locks above 255 seconds. I’m unable to test more at the moment but I can get back to you after I do.
I was not able to input a value in Autolock time over 180 seconds.
In the code, this is what I changed:
preferences {
section ("Lock Properties"){
input "autoLock", "number", title: "Auto Lock Timeout (5-180 Seconds)", description: true, defaultValue: 30, required: false, range: "5..180"
input "wrongLimit", "number", title: "Wrong Code Entry Limit (1-10 Invalid Entries)", description: true, defaultValue: 5, required: false, range: "1..10"
"
I changed 5…180 to 5…1800
In the app, when I input a value over 180, it will not let me enable autolock.
is there anywhere else in the code I need to change?
So as I stated before, the Yale locks I’ve tested don’t allow for a value above 255 seconds. Anything higher and the lock won’t accept it. The ZigBee spec allows for higher values but the Yale firmware does not.
There should not be a need to change anything else in the code to enable higher values.
I understand. I would settle for 255, but I am not able to get above 180.
I remember 240 working and 360 not so I assumed 255 (as everything goes by hex). You can try 240.
Actually it was 240 that I tried, and it would not allow me to enable Autolock after setting it at 240, even 181 doesn’t work. Only 180 or lower.
Different locks have different maximum values, e.g. NexTouch have a max value of 127 seconds where as Keyfree goes upto 180 etc.
That’ why I was hoping it is possible to write a smartapp based autolock, instead of depending on the built in hardware autolock function. Would it be possible to write a smartapp that triggers when a lock is unlocked, waits a certain amount of time (user changeable), checks if the door is locked (manually or otherwise), and if it remains unlocked after that time, then lock it? Does an app like that exists?
There is the Enhanced autolock in the marketplace but that requires a door sensor, which i don’t have nor plan on getting.
This is working perfectly for me. Awesome work.
@superhuynh You should be able to do this with CoRE if you have not tried. The only downside over Autolock is that it will only work when the cloud/internet is available.
I just started fiddling around with my smart things, and using webCoRE. I am using this handler for my Yale locks. I was wondering if there was a command in here that would let me trigger the tamper alarm for example if a contact sensor is opened. Thanks.
The tamper alarm will activate when any alarm condition is sent by the lock (forced open, jammed, unit pried opened). Unfortunately I do not have a command in the DTH to trigger the alarm manually. I don’t know if it would be the best idea to do so as then you wouldn’t be able to determine if the alarm was set off by the lock or something else. As this DTH is just for the lock, I’d recommend some other tool for notification. Perhaps CoRE or WebCoRE.
Version 1.6 released. Only major change is the additional support for the Yale YRD226 and YRD246 locks. Otherwise no upgrade is needed.
Updated to 1.6a. Version 1.6 introduced a bug, 1.6a fixes it. If you are on 1.6 please update as soon as possible, otherwise this new version is optional.
What bug was introduced?
There are multiple checks in the code to make sure you are not trying to set a code with a slot number greater than the max number of allowed codes. With the change in 1.6, it was possible that the max number of codes returned was a string (instead of an integer). This was throwing an exception.
This bug broke the updateCodes and setCode commands.
Why does my lock keep sending update code commands seemingly more that two times every minute?
