I know @andrewjfreyer is a clever guy, so yeah, if it had been that easy, then I am sure there would have been a flag/setting somewhere to do it
I went through the pastbin log I had posted earlier, and added every single MAC from it to the ignore list, was 25 or so, so it should have covered anything that was static in the house causing it. I also changed the setting you suggested above, Not sure what it really changes though,
and since then, I havenāt had a tablet disconnect yet, but its early days. I still have all 5 mac address in the known file, I have been constantly pinging them from my windows machine, and they do obviously lag a little when it is doing an arrival scan. I havenāt setup a trigger yet on my door for departure scanās yet, kinda wanted to and get the interference down to a minimum first, which is seems to be slowly getting there, before I setup the departure side.
My tablets are only connected via 2.4ghz, they are a Ā£30 no name android tablet with a IEEE 802.11b/g/n chipset only. I just use them as exampleās of the interference, as itās easy to screengrab the history of them. Unfortunately I also have Sonoffās around the house that are 2.4ghz only I believe, the Xiaomi is also in my collection, and both of those setās of devices also have problems with the interference.
If I could swap everything over to 5Ghz, it would solve a lot of problems.
Iāll monitor how it goes from now, and see what happens.
I seem to be running into an issue with iBeacons.
I have 2 rpi 0Ws at each end of the house, one master and one slave running "monitor.sh -m -r -b -x " and āmonitor.sh -m -b -x -tā respectively.
The issue Iām having is that I can detect iBeacons, but after pulling the batteries/switching them off, I cannot get confidence in either instance of monitor to drop to zero. All iBeacon instances in the log report at 100 confidence, and I have yet to see any expire and set to 0. My script preferences are all at the default too.
Am I doing something wrong with the script arguments?
Rodon, I see the same behaviour with two Kontakt iBeacons. Only way Iāve had them working is by adding them to the known_static_addresses file and pickup the MQTT by MAC address in HASS. Think the problem is that monitor.sh is reporting the 100% confidence on the iBeacon UUID address mqtt topic and everything else on MAC address mqtt topic.
Donāt know if you fixed this,but otherwise you should check if she got any device paired with her iPhone. I think I heard about the same thing happening, and it was caused by no paired device on iPhone, then it dosnāT send out messages
Thanks, no I never did find a solution. So you are saying that if she has never paired a device before, then it wonāt work properly? Can it be any device?
The concept on which monitor is built is brilliant. Kudos to @andrewjfreyer!
Iām pretty new to Home Assistant (<10 days) and even newer to monitor (3 days). I may, therefore, be asking the dumbest question. Iāve searched for the answer but so far without luck, so Iāll ask anyway.
Iāve been able to set up monitor so that it publishes cell phone presence via MQTT to Home Assistant. However, since Iām building up my HA system, I restart it regularly and Iāve noticed that the MQTT sensor in HA is āunknownā after HA restart. It changes to āpresentā or ānot presentā if when the RPi detects a change (if the phone arrives or departs), but not until that happens. Iāve tried to āforceā detection by publishing ARRIVE or DEPART to MQTT to trigger monitor to scan, but it appears that monitor does not publish anything to MQTT until it detects a change (from āpresentā to ānot presentā or vice versa).
Restarting monitor.service after restarting HA does the trick, of course, but thatās obviously cheatingā¦
Iām confident that thereās a trick Iām missing and would be grateful if someone could point me in the right direction.
Iām a really noob too so donāt know if this would fix your problem, but maybe @benjimattās answer, running location/scan/restart above can help you on the way.
In the past 24 hours the two devices I have running monitor have made 4,530 requests to api.macvendors.com. Is this really necessary? Do I have something configured incorrectly to be hammering this api so frequently? Thatās an average of 3.14 requests every minute from the two devices.
so it looks like there is a section of @andrewjfreyer code that is called
ādetermine_manufacturer ()ā
#IF CACHE DOES NOT EXIST, USE MACVENDORS.COM
if [ -z "$manufacturer" ]; then
local remote_result=$(curl -sL https://api.macvendors.com/${address:0:8} | grep -vi "error")
You could probably ommit this in the code if you wanted. But if you want a quicker solution you could make a static route on your router that redirects requests going to https://api.macvendors.com* to 127.0.0.1. its up to you.
i suppose it could be an issue for beacons ā¦ if you read the monitor.sh file it looks like if it cannot get a manufacturer it will report it as unknown. This is happening when the message is published to the MQTT server. I mean personally it would affect any name scans that I am doing. This isnt something id ārecommendā but for people that really want to control their bandwidth it doesnt seem like it will affect muchā¦
I just tested a restart of HA and then published to location/scan/restart and that did the trick. I will investigate the effects of monitor -a and monitor -x as well.
Just popped in to say thanks @andrewjfreyer. I had been monitoring (no pun intended) this thread for awhile but not being great in bash hadnāt tried using monitor yet. Your readme.md is pretty comprehensive though - and I was able to start tracking our cell phones very quickly. A few days of comparing state changes fand I should be able to (finally) uninstall GPSlogger from my phone!
Iām pulling my hair off, trying to figure out the usage of triggered scans, especially for arrival.
Iāve read almost the entire thread, but was only able to find something about the use case for triggered departure.
Iām getting the point of using the trigger for departure (-td), which has a number of advantages, less 2.4G activity, no fail drops and so on.
But I canāt figure out why I would use triggered scans for arrival scanning. Iām having 2 RPI, one will be configured as the master, and one as the slave.
If I let the master to take action on announcement, but the slave to only run arrival scans on trigger, what will the case be if Iām not visible for the slave when I enter my house, then the slave will never see that Iām home?
Iām just trying to figure out the best working case for me. Iām living in a one floor house, with one RPI in each end of the house.
Iām thinking about running both the slave and master with the option -td, and triggering departure by the doorsensors. But if any other options could be better Iām all ears.
What in behavior preferences do I change to make my arrival speed up? PREF_ARRIVE_SCAN_INTERVAL=45? Would this make any change even if iām running in -td mode? Donāt know what they refer to with āperiodic scanningā Itās fairly quick now but want to try and make it even quicker if possible.
And one more thing - Can you setup monitor so it only runs really quick arrival scans when known_devices are 0. In my case all the things I want to track are in there, since I dont run any generic beacons. And that would able me to run more arrival scans when not home, but when home having monitor not do anything + not cause any wifi interference and just waiting for mqtt departure?
