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.
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!
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
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.
Hello, I’m using the Lock multi user code management ver 5.05. Under lock/unlock actions I am trying to setup a scenario where SHM is automatically disarmed when the door is unlocked. Right now I have “Disarm Smart Home Monitor” enabled, I also have a routine which deactivates SHM running when the door is unlocked. However, my SHM keeps detecting intrusions after unlocking the door. Any suggestions?
Sounds like you have a timing issue there. When the Door is Unlocked, the SHM is still Armed and when the Routine executes, it disarms the system after the door is unlocked. The way I am running my inside garage door lock that is being monitored by SHM as well is the following.
I have my Disarm Routine that when my GPS (Geofence) is within the perimeter, automatically open my Garage Door (MyQ) and when my Garage door opens, Disarm system and set Mode to Home, and when my Garage Door Sensor is Open and my Mode is Home, Unlock Garage Door. That’s using just standard ST routines.
Although I don’t have Core or WebCore setup, that may have different timing parameters to bypass the timing issues you have, but if you have another way as I described above to trigger routines and something not monitored by SHM you can do it the way I am doing.
Just some thoughts.
Yes, geofencing works well for disarming SHM. However, that requires the smartthings app installed. For example, if I have a babysitter that comes every so often but doesn’t have the smartthings app, (and don’t want to give out access to all of my smartdevices on smartthings), disarming using geofencing can’t work. I would probably have to get one of those arrival sensors no? Or, tell whoever is opening the door to wait a few seconds after keying in code before opening the door.
That’s definitely one way. Giving her an Arrival Sensor would work, but you still have the timing issue if you are going to try and Disarm and Unlock the Door using a single Routine.
Without getting overly complex if you were to go that route and give her a Physical Arrival Sensor, I would create two routines.
-
When her Arrival Sensor is Present and system is in whatever Armed State, Disarm SHM, and set the Mode (create a custom mode called her name or something) and set the system to that.
-
2nd routine, when her Arrival Sensor is Present and the Mode is “her name”, unlock the door.
Just a thought. You can also do something like this without giving her an Arrival Sensor. The Echosistant @SBDOBRESCU @bamarayne App has a Device Handler that allows you to add a Virtual Presence Device that you can within ST set to Present or Not Present simply by clicking on it so you can still keep control of your system without giving her anything. You would have the same routines above and when she says she is at your place, you can click on the virtual device to Present and the routines will fire. I’m only giving you some very basic ideas without having to put a whole lot of time and energy in, because there are more complex and powerful ways to execute some of these things with some other SmartApps that are available.
Also for that Device Handler I mentioned, I don’t believe you have to setup everything for Echosistant. You can just create the new Device Handler in your IDE and then create the Device in IDE with that Device Type Handler and that will target what I described in my previous post.
However, mentioning Echosistant, if you don’t already have this App and you have an Echo, I strongly recommend you take a look at the whole SmartApp. Having two way intercom conversations with your babysitter while you are away (with all the new features of the latest Alexa release). Sending Notifications, alerting your Babysitter with predefined voice notifications at a specific time while she is there. You can have a field day.
Actually, would a smartbutton work like a the xiaomi smart button? I guess the question is, if i’ve already triggered an “intrusion” which i’ve set a delay before the siren goes off, and I run a routine that disarms the alarm, does that disarm the alarm that has been set off?