I’ve only had problems with key fob presence sensor, on s8+ note 8, s7 edge, and v20 presence works pretty darn well.
Only problem with that is if like you said, just at neighbors, depending on how close they are could be a problem. Even at it’s best a phones GPS is only accurate to about 3m. Can adjust radius in app but 15 feet could be difference between your living room and your neighbors.
I set it up at my sister’s so that it uses WiFi to determine whether or not home, if connected then home if disconnected for x number of minutes then not. Each way has flaws.
I can’t go ANYWHERE without my phone, my kids can’t either, so that’s not really a concern for me…unfortunately.
Actually, since I’m in a wheelchair, the door is often open for A shorter period of time if I’m just accepting a package.
But even for able-bodied people, I think all bets are off if it’s a pizza delivery and you have to pay for it.
As you say, it’s just one of those things where there may be a lot of tinkering involved to get it just right for each individual household. But that’s why I like the suggestion of using the smart locks so much. There you actually get different information sent to the network depending on whether the door was opened from the exterior or the interior side.
The main objective is to control an intruders alarm.
When door is open from inside, because someone leaves or, as it has been remarked, to receive a visitor or a packet, the alarm must never be triggered. When door is open from outside, the alarm must be triggered, except if some inhibition action has is done a few before or after.
In particular, I’m playing with a raspberry pi 3, bluetooth microphone/speakers, pocketsphinx voice recognition and http client/server to interface with smart-things hub. This solution allows to an automatic system ask “who is ?” when someone opens the door and expects a predefined answer phrase that inhibits the alarm. But this experiment is valid for incoming scenario, not for outgoing one.
My experience is that presence sensor based on mobile phone considers me as “present” even when I’m really far from house (near 1000 m). That means I can not use it to inhibit the intrusion alarm without improve the system with additional information.
I use a Schlage lock that can distinguish between manually unlocking from the inside versus using an entry code from the outside. I have it set so that the door always locks once the door is closed. So this means that most of the time, people have to enter a code to get it, and they have to manually unlock the door to get out. I also have the Smart Home Monitor arm itself when the door is locked, and disarm when the door is unlocked. Unfortunately, z-wave isn’t fast enough to disarm the SHM before the door opens and sets off the alarm. So a mindful occupant would need to wait 2 seconds before opening the door or it would trigger SHM. There are ways to compensate for this by using delay entry smartapps, virtual switches, and/or webCore, but I haven’t taken the time to set it up.
I’m using @Rboy’s DTHs and smart apps. I believe the fact that my disarm is occurring after the door open is detected is just an inherent z-wave behavior. My door contact sensor is hardwired to an ESP8226 running Konnected.io. Perhaps if the door was using a z-wave contact sensor both events would have the same lag and arrive at the hub in the correct order. Maybe I’ll see if I can slow down the konnected.io code a half second or so and see if that helps.
Unfortunately, There’s no forced sequencing with Z wave, it’s the nature of mesh. Messages can bounce around a little while and it’s not predictable. Two sensors on the same door sending a message at the same time might arrive in either order on any given day.
The officials document say scheduling can’t be guaranteed in intervals of less than one minute. People try to get around that with web core, which will allow you to set up a rule for events that are just a few seconds apart, but it may not always work.
I use a simple zwave button mounted at the door on the inside. When the button is pressed the system deactivates (disarmed). Then the door can be opened (less than a second delay). I use presence sensors (phones and ST sensors) to set home from armed (away) to disarmed. Once inside, double press the same button to set the system to armed (home). Seems to work just fine for us.
I revisited my smartapps related to arming and disarming the SHM based on (un)lock events. I decided to rely less on the disarm feature in the rboy smartapp and use core. This seemed to improve response times. I also then repaired my mesh to further improve it. (I had a switch out of wack.) I still have an occasional failure where the contact is faster than the lock. I think I’ll try to code a small delay into the konnect.io lua code or the DTH sensor code.
I wish to set up an automation to turn on my hue lights in the living room when I open my main door upon returning home. I have a contact sensor on my front door which can trigger the lights to turn on. However, I realise that I will also inadvertently trigger the lights whenever I open the door to go out. I am pondering on the feasibility of adding a motion sensor or arrival sensor togther with the existing door sensor. Is there an effective way to achieve my objective?
You can just use an Automation with 2 conditions… If mode changes to home & door opens, turn on the lights. Or if your phones presence changes to present and the door opens, turn on the lights. You’d probably have the best results in webcore so you can add a time limit, such as if mode has changed to home in the past 5 minutes and the door opens, turn on the lights. This would help with any false triggers.