[Monitor] Reliable, Multi-User, Distributed BT Occupancy/Presence Detection

automation
mqtt
Tags: #<Tag:0x00007f1b975e1d98> #<Tag:0x00007f1b975e1b90>

#688

Can I just ask - I’m about to splurge about £70/$90 on some new WiFI sensor nodes which I’m hoping will be a lot more resilient to ignoring the bluetooth interference generated by the Pi Zero W running Monitor. Just looking for some reassurance from folks who currently DO run a few WiFi nodes themselves, like Wemos D1 Mini, Particle Photon, ESP8266, NodeMCU etc etc etc alongside Monitor? Thanks
(Currently using Spark/Particle Cores which cannot cope with being run alongside Monitor)


#689

Anyone have any good hints on a BE Tracker or iBeacon that could be used for pets? Ideally waterproof with changeable battery - am in the UK.

Currently considering this one: https://www.alibaba.com/product-detail/2-6mm-Ultra-Thin-Beacon-Eddystone_60277697830.html?spm=a2700.details.maylikever.10.32117c4dyPRQRx


#690

make sure you don’t have to click it for it to send an update. I have one that only powers itself up when clicked.


#691

Yeah that’s what I’m trying to avoid. It’s quite hard to know from the descriptions. I think this one allows you to configure broadcast up to 1 sec intervals.


#692

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.


#693

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!


#694

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!


#695

Forgive my ignorance - but won’t that be an issue with any bluetooth device? or am I missing something?


Trying to get MQTT to work on ubuntu "server"
#696

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.


#697

I replied by mistake thinking you’d replied to my question! :joy: hence the delete.

From my very limited knowledge I agree with what is said about pollution of 2.4


Why can't pi w [monitor] talk to my mqtt hassio addon?
#698

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.


#699

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?


#700

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!)


#701

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


#702

“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.


#703

I actually cancel the scan when the door is open not closed. At least that is what its suppose to do.


#704

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…?


#705

Just change the intervals if you think it’s needed: https://github.com/andrewjfreyer/monitor#advanced-configurations


#706

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


#707

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.