Right now, I currently have Philips HUE, (2) Alexa Dots, Harmony Home Hub, Samsung SmartThings, some smart wall switches, outlets, a Wi-Fi Honeywell thermostat, and a Schlage Camelot deadbolt lock (Schlage Connect). I also use IFTTT
Ok…so I’m getting pretty good at setting the house up the way I like and need, although I cannot program…however, (and this may be something obvious that I’m just overlooking) I’m looking for a way to link my door sensors, with my arrival sensors.
I ran into this issue today… I currently have contractors in my home working after a flood. The door was open as they are moving furniture out. I left to work with my arrival sensor in my pocket (which is set to lock the door when I leave)…the door was still open, ST noticed I left, and locked the door the way I want it to…BUT…is there a way that I can prevent this action when the sensor is set to open? So that someone doesn’t end up throwing the door shut, with the deadbolt extended?
Anyways, thank you all in advance, and I look forward to becoming more active here
(ActionTiles.com co-founder Terry @ActionTiles; GitHub: @cosmicpuppy)
What method / SmartApp / Routine are you using to perform this?
If it were up to me, I would not allow users to install a locking automation unless they had a Door Closure sensor connected… But lots of folks are too thrifty to install one.
Regardless, the stock response here will be to use WebCoRE for this. I’m not sure offhand if there is an easier or more streamlined way.
@RBoy’s multilock manager smartapp has a setting that will unlock the door if a lock action is detected while the door is open. This is more of a corrective action, and not a preventive. I think the reason for that approach is that a lot can happen between ST issuing a lock command, and the zwave lock actually performing it. The door could be reopened at that point. So the app notices that the door locked while opened and immediately sends an unlock command. This also helps if someone manually locked the door while it was opened. However, I stopped using the setting for two reasons. First, I had a few instances where my door sensor wasn’t behaving and that resulted in my lock unlocking my closed door shortly after I locked it and left the house. I also think there were a few times where that zwave delay gave me time to unlock the door manually before the app could and by the time the unlock command was recieved, I had already closed and locked the door…then it recieved the unlock command. Just be wary of this kind of setting whether you use @Rboy’s app’s approach or decide to use a preventive approach with a webcore piston… a faulty open/close sensor could prevent your door locking when you assumed it would. I personally recommend avoiding automating any unlock commands or preventing a lock command…stuff happens, and do you want your house left unlocked as a result? Of course you might be able to put in enough redundancy to handle these scenarios…but it may be too much effort and complexity for too little benefit.
But the routine would only run when the door is opened, so it’s already unlocked. If someone were to lock the deadbolt manually while it is open, the routine would then not fire again and re-unlock it. There is nothing to trigger that. The contact is open and stays open, so it would not unlock the lock.
That would not do that. If someone were to extend the deadbolt on the lock itself or through a manual command in ST, the routine would not be triggered to unlock the door because the trigger event is the contact changing from closed to open. You would need a separate operation saying that if the lock changes to locked while the contact is open then unlock it again.
Are you talking about in WeCore? I don’t think that would work the way you are describing. I think you would need another expression saying If locked and if open then unlock. Because, if Open then unlock only looks at open and close, not on locked. The trigger is the open/close which has not changed.
I build an example piston…
If i turn off the dimmer while the contact is open it does not turn back on again. Same principal here.
And if you are talking about routines, then you are also not correct. If you set a routine to turn on a light when a contact is open, if you turn the light off manually it stays off. The routine doesn’t run again to turn it on.
Well, that’s not what he said…he said 2 routines. And that is why I said that if you want to prevent the lock from ever being locked while open, you would need something else. But it would be wiser just to always put having the door closed as a condition of locking the door, that way, you’re safe. In the end though, this is one of the reasons why I haven’t swapped out for connected locks. Just not 100% and that is something that can’t ever fail.
I guess it depends what he intended a “routine” to mean and if he was suggesting it as a way to prevent an event or to correct an event. I don’t disagree with your observations and conclusions based on your interpretation. I guess only Glen knows what he originally intended.
All of that aside, I will just say that these zwave locks don’t always respond faster than the humans interacting with them, and zwave protocol doesn’t guarantee commands arrive at the device in the order they were submitted or visa versa for events…so it’s possible that a command can arrive at the lock and reality has changed to make the command inappropriate. So an auto lock command is issued on a closed door event, but arrives at the lock AFTER someone had opened it again, thus locking an open door. (I’ve observed this with my locks.) The only thing you can “reliably” do is attempt to houseclean after the fact. I think you could use Glen’s “routines” as the guiding principle of a piston that polls every minute. If door is in a closed state, lock the door. (keep it locked). If door is in an open state, unlock the door. (keep it unlocked.) I’d probably add some additional logic to not issue commands that are redundant to the current state of the lock. And I’d still have a separate rule for locking on door close so you don’t wait as long as a minute. With this arrangement, you will ultimately keep the bolt in the ideal position even if real life throws a curveball… but you might have to wait a minute extra or so for it to settle into the right state in a worse case scenario. But I wouldn’t adopt this just because a faulty door reading could unlock the door for uninvited guests. And as I write this, there are other refinements that could handle that event a bit better (if door is open > 5 minutes), but it would never prevent a window of opportunity. My advice is to auto lock for the novelty, avoid auto unlocking as a security precaution, and never 100% trust auto locking to occur. (Press that little schlage button on the lock when you leave.)
Wow… didn’t realize I had to answer to the Grand Inquisitior. lol
Anyway, yes my automations work as I said originally. I’m looking at them now that I’m home.
What I failed to say is that the auto-lock routine I mentioned makes the presence lock routine redundant, and that the presence lock routine should at that point be deleted. Else indeed, you might still end up damaging your deadbolt. I thought that was understood in context of my post, but on reading it back you are correct that it conveys no such thing.
Thanks for holding my feet to the fire so I would clarify.
You don’t have to answer to anyone. But when you post something incorrect, prepare to be corrected. And a ST routine (yes, that word has meaning in ST because it is a function in the architecture) keeps a door unlocked while a contact sensor is open? So, if you open the door and then trigger the lock, the lock will re-open? I would love to see a screen shot of the routine you have doing this. When you say “automations” what do you mean?
At the end of the day, you can think whatever you want but what you are saying is not correct. No one knows what you indented, we only know what you said.
Hey guys… I’m sorry I was away…its been a long day at work.
To answer the question above as to why the bolt would be extended with the door open…
The door is open…(for fresh air…or people moving stuff in/out of the house) I leave the house with the door open while people are home. I have my ST arrival sensor on my keys…I drive away, ST notices I’m not longer “present” and locks the deadbolt after I drive down the road.
Someone goes to close the door, not noticing the locked deadbolt (most people wouldn’t…because why would it be locked and open?) It smashes into door frame…causing damage to 1 or many parts.
You guys gave a lot of detailed info which I’m very thankful for! I will read up on it and respond. Coding and pistons (like in a V8?) are way over my head at the moment…make a pretty competent guy feel dumb why don’t ya
I’ll read up and try to follow allong.
I just want my arrival sensor to not trigger lock if door “front door sensor” is set to open as that’s the main reason why it would lock while open.
Thanks again and I’ll spend some time learning all the code info