Those devices use 2.4ghz, so the interference will still cause problems. If you want to use Monitor configuring it to only run on triggers is the only way to solve the problem.
Hi,
Still trying to get my Apple Watch 4 to be recognized by monitor but with no luck.
I have tried with sudo monitor.sh -g and by placing the MAC in known_beacon_addresses (I have also tried it in the known_static_addresses but the result is the same).
When I run this command against my iPhone 7 I get a response: sudo hcitool name MAC
But when I run the same command against my Apple Watch 4 i don’t get a response.
I’m trying with the MAC from Watch App - General - About - Bluetooth.
Thanks!
Just checking in to give many thanks to @andrewjfreyer for making this fantastic script and all the people here who provided some much needed hints to get my installation started. I’ve installed Monitor on one RasPi ZeroW, will be doing another one for the first floor. Great job all and thanks again!
2 Likes
Forgive my ignorance - but won’t that be an issue with any bluetooth device? or am I missing something?
I don’t get what you mean. Are you asking if any BT device could mess your WiFi? If that’s the case, then, the answer would be yes and no.
“Yes” because any BT device doing super frequent scans will “pollute” and mess with other devices on the same frequency, and “no” because most BT product simply are not trying to discover or scanning 24/7 nonstop.
At least that’s my understanding of the situation.
1 Like
I replied by mistake thinking you’d replied to my question! 
hence the delete.
From my very limited knowledge I agree with what is said about pollution of 2.4
What kind of range have people had with this? So far I’ve got this on 2 Pis and it’s not quite picking me up fast enough. Debating getting another pi and putting it in the garage as my intended use at this point is to open/close my garage door for me but I’m not sure this is going to have sufficient range/be fast enough.
Are you sure about this? Are you suggesting everyone in this thread happily using Monitor is using 5Ghz WiFi ? I was under the impression (might be wrong…) some WiFi chips were more resilient to ignoring BT interference than others?
1 Like
What I don’t get about this interference is that 2.4 GHz Wifi has about 13 separate channels. We all know how to limit our wifi AP to one channel. Is it not possible to have the wifi and bluetooth on separate channels and reduce interference? (I may be showing my ignorance of BT technology here!)
1 Like
This is intereting teading about bt v wifi https://serverfault.com/questions/7883/will-we-have-interference-or-reliability-issues-with-many-bluetooth-devices-in-a. As you can see bt hops over 79 channels and cant be set
“picking up” doesn’t necessarily have to do with bad connection. How I experience it is that is also has something to do with the broadcast and scan intervals.
Even when I’m right next to the monitor device it doesn’t always “see” me right away.
It’s not really a problem for me because I don’t use the detection to for instance turn on a light.
I am restarting all monitors automatically every 24hours because stability goes down after a while as mentioned earlier in this thread as well.
I actually cancel the scan when the door is open not closed. At least that is what its suppose to do.
So it seems that running Monitor alongside by 2.4Ghz WiFi WILL cause slowdowns and/or packet loss. Damnit!! Is there any way to only do an environment scan every 20 seconds or so? That might mitigate the problem, and only to the detriment of the immediacy of the update…?
Just change the intervals if you think it’s needed: https://github.com/andrewjfreyer/monitor#advanced-configurations
I see dropping WLAN connection on my both raspi zero w very realiable. Only running monitor script. The logs show always carrier lost for wlan0 after an arrival scan was triggered. The WLAN is restored automatically, however often causing the first mqtt message not to arrive at my hassio as the wlan0 was down during the send. Here is what I have consistantly in the logs for the “carrier lost” situation:
08:01:29 raspberrypi bash[430]: 0.1.675 08:01:29 am #033[1;32m[CMD-INFO]#011#033[1;32m**** Started arrival scan. [x2 max rep] **** #033[0m
Jan 4 08:01:29 raspberrypi bash[430]: 0.1.675 08:01:29 am #033[1;32m[CMD-SCAN]#011#033[1;32m(No. 1)#033[0m F0:76:6F:89:5B:49 arrival? #033[0m
Jan 4 08:01:37 raspberrypi bash[430]: 0.1.675 08:01:37 am #033[1;32m[CMD-SCAN]#011#033[1;32m(No. 2)#033[0m F0:76:6F:89:5B:49 arrival? #033[0m
Jan 4 08:01:42 raspberrypi dhcpcd[425]: wlan0: carrier lost
Jan 4 08:01:43 raspberrypi dhcpcd[425]: wlan0: deleting address 2002:1f13:f680::12/128
Jan 4 08:01:43 raspberrypi avahi-daemon[218]: Withdrawing address record for 2002:1f13:f680::12 on wlan0.
The wlan0 carrier lost occurs everytime the arrival scan message is seen in the logs?
Is there any hint on that? This causes a lot of mqtt messages to be lost because it might take 1-2min until the wlan has been recoverd.
Any ideas how to solve and avoid this wlan0 carrier lost due to the arrival scan trigger?
Thanks & Regards,
Lars
No, I’m saying that people who are experiencing troubles with interference, be it because they’re using the -r parameter or because they live in a very crowded BT environment, might consider upgrading to a 5GHz band OR using triggers to determine arrival or departure. Sorry if I wasn’t clear enough.
Are you running the master branch or the beta?
how often is the sensor.home_occupancy_confidence supposed to update? every time there’s a mqtt pusH?
also it doesn’t seem to be picking up my iphone7+ even though its right next to the rasberry pi 
confidence level is still showing 0 and sometimes 18…
Is there any way of using the rssi data published to he MQTT topics to give some idea of distance from each of the detectors? I understand it would probably be a pretty low confidence in terms of distance, but may be useful to feed into the “confidence” %?
1 Like
That was the master branch. I wasn’t aware there was a beta branch so I’ve switched to that and it seems to be working well now.
1 Like