Not sure if there is already a Solution for this but ill post my workaround. If in the rare occasion my phone dies I have the monitor script stopped so this does not happen.
Basically after the door is trigger a timer starts and an input Boolean is set to Off. After the 4 min timer stops the input Boolean is set to ON. This is paired with a condition that says if both devices are home for 4 min and input boolean is set to ON stop the Monitor service on all of the PI’s.
The monitor instances are started once a door sensor is triggered again. So far it seems to be working pretty well. Its nice to know if my phone turns off and on later my front door wont open up.
Sorry I don’t get. You want the system to be able to tell when your phone is dead?
Still don’t get the idea of why you stopping the service. And you run it when the door opens? Can you kindly elaborate?
Also I would still like to know how you determine the system should scan when you get home, since it won’t open the door until you close. Will like to see if its something I look into.
@Odianosen25 I think what @benjimatt is describing is a failsafe for auto-unlock of his doors. It sounds like he is using monitor to detect when his phone arrives and, in response, HA unlocks his doors.
For the edge case where he is home and his phone dies, HA will probably try to lock the doors (if they needed locking) just like if he had left the house. No big deal. However, when he plugs his phone in, eventually the phone will boot back up and monitor will report that the phone has arrived and the door will unlock. That could be bad, especially @benjimatt’s system doesn’t automatically re-lock doors that haven’t been physically closed. His workaround stops monitor entirely if both devices are home and the door hasn’t been used for the last four minutes. This means that “away” detection will be slowed down a bit while monitor boots back up on the devices, but not by much.
@benjimatt - I have a working solution to your problem in testing right now. Essentially, I’ve added an option to only depart scan after a specific trigger.
Thanks for the explanation @andrewjfreyer , but based on what you said, will it completely solve the problem? This will potentially solve when both are in, how about if just him is in and the phone dies? Or if there are multiple ppl in the home like a guest? (which at this point, is scary in thought considering the security risk).
I think the best approach is some extra form of intelligence in the management script, and not just forcing monitor to scan depart only. Whereby if a device declared away, and yet the door wasn’t opened within the timeout period with an offset if -30 seconds. There will be use cases for that of course, like if everyone is home, no need scanning arrival for extra security.
Better still for added security I think, have a sensor at the door that tells it someone is in front of it, either via a proximity or step sensor or something. So a device declared as Arrived with the door sensor being active tells it someone wants to get in. This was part of the reason I wanted to know how it was being activated from the door before monitor is instructed to scan.
Yes, I understand. The thinking is that the phone whose battery dies will not be recognized as having left at all. As a result, it won’t “arrive” when it’s plugged in again. Does that make sense?
I wanted to implement depart only scanning, so for both my scanning devices I used: monitor.sh -t -x
And a depart scan is triggered when I open my apartment door.
However, I’m afraid that if I’m still in range when the scan is done, I’ll never be marked as away.
Is there a way to scan on depart AND to also scan periodically, but not too often?
My main scanning device sits close to the street with lots of people always passing through and if I let it triggered by unknown MAC addresses, it is scanning all the time
Does anybody have any false negatives? I have occasions where my phone will report 0% on both Pis after being stationary in the same spot for over an hour. This then fires my ‘away’ or ‘home’ automation’s which is troublesome.
Yes I do used to get it, and I had a chat with @andrewjfreyer on it. In one of his updates, he added a feature that after the main monitor senses below a certain confidence level, before it gets to zero it has instructed the others to scan. This way if at the other end of the home, you could still be picked up.
As a fail safe, in addition to the above, my system has its own timeout, before declaring that I am away when below a confidence level. So when my device is sensed to be below my stated confidence level, within my timeout I instruct the system to do another Arrival scan again, so to be sure its not a False negative. Since Arrival scan is quick, this is quickly completed within the timeout and it checks again if I am truly out before doing anything.
Just run it as default, or monitor.sh -x if you want the retain. Fill put in your MAC address into the known_devices file and it should only scan for you but when triggered and periodically.
You can increase the number of arrival scans from the default of 2 and increase the time between scans from the default of three to effect a similar change
Is there any way to get monitor to output the MAC’s that aren’t in the known_devices list that it sees more than once? I seem to have a lot of random bluetooth devices triggering arrival scans and it seems to be throwing things off. I’m not sure if its just all of the random devices I have in my house or its picking up some neighbors phones/devices too.
can the scan start/end topics be changed a bit? - I think having it be generic (location/scan {"status":"start"}) with a payload to indicate the status fits better into many use cases, particularly HA where you may want to easily setup a mqtt binary sensor to indicate the state of the scan(s)
Yes, harmonizing MQTT topics with standards is definitely on my list. But… it’s a pretty major breaking change for a lot of people, so I’ve been putting it off.
