It should work absolutely fine. The DH supports Z-Wave plus secure commands.
1 Like
I have a couple YRD246s that I’m using RBoy’s DH/apps with - easy setup & integration, and it all works great together.
1 Like
I have 2 YRD120 T1L’s (Electronic key pad, completely keyless, and Z-Wave built in) and they have worked flawlessly with @RBoy Universal DTH. When I had installed originally, this Yale lock was lacking a way to disable the user keypad (except directly on the lock) and also the number of invalid entries attempted (if I have the keypad enabled), and now those additional items have since been added giving this lock even that much more capability from within ST.
1 Like
@RBoy I can’t believe I’m back here again with the same issue. About 2 years ago I posted on here about my Schlage Touchscreen deadbolt having issues relocking immediately when the door closed. A hard rest and reinstalling everything seemed to fix the issue but not permanently. I eventually just decided to live without that feature working. Out of the blue, I decided to update to your latest firmware (about a month ago) and BAM the relock on door close was working again. Well, unfortunately for me, I’ve moved to a different apartment since then and had to reinstall the lock. Now that it’s set back up, relocking is again not working. I tried your newest firmware again to no avail. I’ve factory reset the lock, uninstalled your app and device handler, and reinstalled everything. Nothing is working. For some reason, I have open and close the door twice for it to lock no matter what. I can leave the door open for 30+ seconds the first time and close it and that lock still won’t relock until I do it a second time. It’s MADDENING. Looking at the ide logs shows that the lock is reporting that it’s busy that first time. That makes no sense as the lock has nothing to do with how many times the contact sensor opens and closes. To be transparent, I initially used a new contact sensor when I moved (IRIS) but then tried the old one (Smartthings) to see if the sensor was the issue. Neither work. What on Earth could be causing this lock to not relock unless I open and close the door twice? This happens in your app and C0RE.
I drove my wife crazy trying to get this to work a few months ago. Open door, close door, sometimes it would lock, other times I would swear obscenities: rinse and repeat. I ended up modifying the code to wait 5 to 7 seconds when the SmartApp was configured to “immediately” lock when closed. (There were two places in the code where I increased the delay.) While that is by no means immediate, it seems to be sufficient time so that the lock command consistently works and doesn’t get ‘dropped’. This seems to be something quirky about the Schlage connect locks. I have not tried more recent versions of the SmartApp since I made my modification.
1 Like
What’s infuriating is that it was working before I moved. Also, I can’t reason how the amount of times I open the door and close it is tied to the lock relocking. If it was simply a time issue then holding the door open longer before closing it would work the first time. But no, I have to open it, close it, open it, and then close it again for it to work. I wish there was a way of pulling the log from back before I moved so I could compare the two.
If I recall correctly, my issue was as follows: I have a front door lock and a back door lock. The relock on close would only work the first time I tried it. But if I tried it again on the same door it wouldn’t work. I can’t recall if locking the door manually reset the experience or not. Frankly, I might be confusing some of the details with another locking automation that drove me crazy…locking both doors when only one of the doors was manually locked. The “automatic lock on close” eliminated the need for that automation, but I definitely had problems with “lock on close” not working consistently, and adding a few seconds to the delay in the smartApp code did ‘fix’ the issue ever since. I think it could have to do with your location’s z-wave mesh, and other factors that @Rboy could explain much better than I could.
1 Like
Are the smartthings contact sensors z wave or zigbee? That’s what I was using at the previous location but have switched to the IRIS sensor which I believe is zigbee. Correct me if I’m wrong but they shouldn’t have any affect on the z wave lock if they are zigbee right?
My sensors are hardwired to an ESP8226 wifi board so they aren’t using zigbee or zwave. I guess it’s possible that’s why adding the delay to the code worked for me. But I think this may have more to do with the lock than the sensors, as illogical as that seems. Your experience with the lock being ‘busy’ is extremely familiar to me. I’m not sure how to easily share my modified smartApp code if you want to try it. This is probably far out there, but have you tried closing the door slowly and gently as to not vibrate the lock? Or better yet, simulate the open/close with the sensor without physically moving the door? Also, might you have a CoRE piston or other smartApp trying to do something at the same time with the lock causing a conflict?
With my Yale lock I ended up putting a 5 sec delay between commands as it
would sometimes miss one. With the delay works perfect.
My lock is zwave and my door sensor is zigbee, I have no issues at all.
Correct I’m assuming this discussion is about the SmartApp software based autoLock
The hardware based autolock is controlled by this device handler where as the software based autolock is used in combination with the door open/close sensor by the above SmartApp. The reliability of the autolock feature depends heavily on the quality of the Z-Wave mesh and location of the lock. It also depends upon how the lock processes the commands, some locks don’t accept too many command too quickly. Hence the safest option is to use the delayed locking mechanism provided in the SmartApp which waits for a seconds to autolock the door (it also checks the door status before locking). This is also preferable practically since if you suddenly reopened the door, even with an immediate relock option it can take a second or so to lock it and in a immediate reopen scenario it could extend the deadbolt while the door was reopened. Delayed relocking the most reliable option.
Other things to look at to improve reliability
- Reboot the ST hub (using the IDE reboot command)
- Repair the Z-Wave mesh (using the IDE Repair command)
- Add a few active Z-Wave device (repeaters) around the house/between the lock and hub.
###Universal Enhanced Z-Wave Lock and Schlage Lock, Yale Lock, Kwikset Lock, IDLock and DanaLock Device Handler - Version 03.03.01
- Updated color scheme to match ST’s new recommendations for locks, contacts and tamper/smoke
###Schlage Lock Alarm Mode and Sensitivity Change and Monitor - Version 01.02.01
- < no change >
###Please refer to the previous post for details on new features in release 03.02.00
rboy. Happy to make a donation - I sent you message, I have a new yale conexis lock. I have tried everything to get it to connect to my smarthings hub but nothing.
I have the Zwave Module and tried the instructions to get it to connect.
The instructions state
remove batteries
insert module
insert batteries
click R X 3
then add a thing
the smarthings simply doesn’t find it.
Will your smartapp and device handler help with this
apologies I am not very good with techy stuff
Mike
How close is the lock to your hub or another z-wave device (most of which should be able to act as a range extender/repeater)?
In many cases, a new lock may be in a spot outside of your current z-wave range.
Prior to attempting a pairing, it may help to perform a “z-wave network repair” from within SmartThings - this will force your z-wave network to refresh.
RBoy’s apps & DHs are really great, but they can’t fix a z-wave range/connection issue - there isn’t a software fix for range issues.
If you suspect range may an issue, try getting a cheap z-wave outlet plug that has repeater capability, put it somewhere in the middle, and then do a z-wave network repair to refresh the network prior to pairing the lock.
Good luck!
1 Like
I could not for the life of me get my Conexis lock to connect. In the end, I switched out my module from my other Yale Smart lock that was already paired with ST and it worked straight away (along with Rboy’s smartapp and DH). Hope you get it working
1 Like
Had it working but took it out, didn’t think was that safe with my geo fence
Thanks for the reply RBoy. Two things;
-
Correct me if I’m wrong but the soonest I can schedule an auto lock other than “immediate” in your app is 1 minute. How would i get that down to something less without editing your code?
-
Even if the delay is the issue. Can you help me understand why keeping the door open for 30 seconds then closing it doesn’t work but opening and closing the door twice no matter how slow or fast I do it works every time? Just thinking about the logic of it all, there has to be something going on where that lock is ignoring the first command.
Also, I have a z-wave switch between the hub and the lock. That should be sufficient right? They are all in the same open room.
Also, would there be a way of building into your app a notification for if the door is left unlocked too long? Similar to your door left open too long notification?
Correct, this is by design as ST does not guarantee execution timing in seconds so providing that option (as was done earlier) only leads to confusion and depends heavily on the platform performance.
ST is an event driven environment and it depends heavily on the quality of the z-wave mesh. If events are being queued up that could possibly explain what’s happening. One thing to do would be to reboot your hub and do z-wave repair and that tends to help. Also having active z-wave devices around the house acts as repeaters which strengthen’s the mesh.