No, it won’t save it
You need to change the startup script, whatever you’re using.
I’m using whatever the install is using. I just installed it and thr docs says it would restart on its on after reboot (which it does)
I use the following automation to restart monitor whenever HA restarts:
- id: '0000000000002'
alias: Restart Monitor service on HA startup
initial_state: 'on'
trigger:
platform: homeassistant
event: start
action:
- service: mqtt.publish
data:
topic: "monitor/scan/restart"
3 Likes
Thanks appreciate it
I use to have this problem but I ended up solving it by doing a doing the depart scans on trigger only. This way once a user is home the automation takes place but the depart automation will not be attempted unless the garage door to the house is triggered.
my girlfriend likes to let her phone die and everytime it died and eventually woke from charging my front door would open lol.
That’ll likely be a systemd unit file then, in /etc/systemd/system, likely called monitor.service
You need to edit that (using sudo nano /etc/systemd/system/monitor.service, then when you’re done reload the service with sudo systemctl daemon-reload
I’ve been using this for a while, and have it set up to trigger departures only on an event (front door), but I’m finding that “something” must be happening to make my phone lose Bluetooth occasionally and when this happens the script triggers anyway and my automations will run (presumably because it sees my phone arrive).
At the moment I run with -x -td. I’m thinking I might just change it to -tad so that it only ever scans for arrivals or departures on trigger. Is there any reason I haven’t thought of why having arrivals on a trigger is a problem?
I might also get rid of the -x as I don’t think I really need it to retain mqtt messages (because I want a live snapshot of the current state right, not delayed info?)
Edit: Unless -x is useful for when HA/Monitor is rebooted?
I have two monitor systems and they both use tad, and its been good. Monitor I think is built to continuously carryout an arrival scan at intervals… So the main one scans, and instructs the others to do same. I used trd before for the main one, and tad for the other. Will be adding a third soon.
I get around using using tad for both by using my door sensor to trigger both arrive and depart scans as needed, and motion sensors for arrival scans only within the house. So this way, my system doesn’t do an arrival scan unnecessarily. As if we all sleeping at night, why scan? So to me, it helps with reduced interference.
Though the honest reason I went with motion sensors trigger, was as I use the RSSI for room locations (still perfecting it), I needed a way to get updated state. As I got motion sensors around the house for lights, well felt I may as well use it. As if motion is detected, it means someone has moved across rooms.
For when HA restarts, I simply send an empty payload to the topic monitor/KNOWN DEVICE STATES which will reload the state of the devices. Though right now, the reloaded states don’t have device names added to what is reported, but Andrew has promised to add this in later.
Regards
Yep thanks. I think I’ll switch it to -tad as it should (hopefully) cut out these instances of false positives, and as we only have the one entrance (that we use anyway). Though thinking about it, I guess that means I won’t be detected when walking towards the house any more (I did have an automation set up to offer to unlock the front door when Monitor picked up that I was close), but to be honest it was too slow to respond anyway (zwave issues I think) so whatever.
I’ll try just setting it to tad for a while and see how it behaves.
Well I am of the view that if you to have monitor automatically detect you on time when you get close your home, it means it needs to scan very often which in itself I am not certain its a good idea. And many times its just scanning when it doesn’t need to.
If I was to implement something like that, I will have some form of ultra sonic or PIR sensor at the door, for which can detect when someone is close. Once it senses it, at that point in time will it then send instruction for it to scan. This way before I get to the door, it would definitely detect me.
That’s my take anyway
I have confused myself. Can someone explain exactly what monitor.sh -tr does? Does it scan like normal, but will update the other devices that are using monitor.sh -t[ad]? I think that is what it does, but I have seen a few comments that have made me doubt myself.
From the built in help:
usage:
monitor -h show usage information
monitor -R redact private information from logs
monitor -S silent operation (no logging)
monitor -c addr create connection to bluetooth device
monitor -C clean retained messages from MQTT broker
monitor -V print verbose/debug logging messages
monitor -v print version number
monitor -d restore to default behavior_preferences
monitor -u update 'monitor.service' to current command line settings
(excluding -u,-V, -F, and -d flags)
monitor -s report all mqtt messages to a single topic with
$mqtt_topicpath/$mqtt_publisher_identity (defined in MQTT preferences file)
monitor -f format MQTT topics with only letters and numbers
monitor -a report all known device scan results, not just changes
monitor -x retain mqtt status messages
monitor -b report bluetooth beacon advertisements (e.g., generic beacons, ibeacons, and so on)
monitor -t[adr] scan for known devices only on mqtt trigger messages:
a $mqtt_topicpath/scan/ARRIVE (defined in MQTT preferences file)
d $mqtt_topicpath/scan/DEPART (defined in MQTT preferences file)
r send ARRIVE or DEPART messages to trigger other devices to scan
monitor -D [dir] use alternative directory for configuration files
So, -tr says to automatically do arrival and departure scans, and to notify others when it does.
I read this, and maybe I am being dense, but where does it say it does automatic arrival and departure scans?
The implication is that the default is to scan for both automatically.
No real concern on the battery – so far so good!
Nice! Toying with moving away from my Unifi device_tracker and only to this one. Just need more time to play with it.
@davosian @rompca7 did you guys ever get this to work with your garmin watches? I’ve got a vivoactive3 and cant get it to work… Keep seeing messages like this:
Jun 23 12:09:58 pizero1 bash[16869]: [+] 0.2.197 23-06-2019 12:09:58 pm [CMD-NAME] F2:E4:81:91:B6:2E JonsGarmin Unknown
Thank you for all your work on this script! It´s amazing.
I just want to let you know that i have found what I believe is wrong behavior by the script. If i run ‘sudo bash monitor.sh -r’ (version 0.2.197) and only one phone is listed in ‘known_static_addresses’, this is what happens:
- The script does a fisrt arrival scan and detects the phone;
- The script then starts doing departure scans;
- If I now turn the phone´s bluetooth off, the script will detect it;
- However, the script will not do now any more arrival scans. If I turn on blueetooth on the phone, the script will not detect it.
In my case, I have solved this problem by modifying the beginning of the ‘perform_complete_scan’ function:
#IF WE DO NOT RECEIVE A SCAN LIST, THEN RETURN 0
if [ -z "$1" ]; then
#SET DONE TO MAIN PIPE
printf "%s\n" "DONE" > main_pipe
#log "${GREEN}[CMD-INFO] ${GREEN}**** Rejected group scan. No devices in desired state. **** ${NC}"
return 0
fi
I do not know if this is the right way to solve the problem, but I hope it is been helpful. Let me know if you have any questions.
Once again thank for your hard work.
Any luck finding an answer to this? I was wondering the same thing
That’s from the dev …I think this indicates that no automatic scans occur with -t. Which brings to mind the question of a situation I have where it takes a while for one of the two Pi’s at each end of the house to pick me up. I think when I walk from one end of the house to the other one loses me but it takes awhile for the other to find me. This shows me away which is a problem. I thought maybe the -r option might help but idk if I want all the scans to be triggered. I think somethings have changed and it’s a bit confusing heck the -r flag had a different purpose in the beginning but was deprecated to the newer purpose