I had read in the original thread that Bluetooth Low Energy would work as a fall back. I have 4 Pi Zero W around my house, works really well! My wife is however prone to not bringing her phone with her, shes one of THOSE people.
Is there a way to use Bluetooth Low Energy? I grabbed a beacon from Amazon and plan to just throw it in her purse.
@andrewjfreyer thank you so much for putting this out there and the ongoing active development. This is a really awesome solution to presence IMO.
Two questions:
Are you still using node-red w/this solution, or did that change with the switch to the monitor approach?
If you’re still using node-red, would you be willing to share an export of the flow you’re using? I know you describe in detail what the nodes are doing, but translating that to the same in node-red is still quite a feat (to me at least).
I’m running a setup similar to yours (5 nodes: 1 upstairs, 3 on the main level (including garage), 1 in basement). Right now they are all running with the default arguments. You mention using -tad, -tr, etc depending on which node it is. Is this an important configuration to consider? Should I expect things to be too chatty & cause interference if all 5 nodes are running w/defaults?
@andrewjfreyer, Thanks for all your work on this, when i found this I thought “great this is just what I need”. However if you could add a couple of updates to the original post…
First it would have saved me a lot of time if it said that Monitor is a more feature rich development of this project and should be considered first.
The general consensus seems to be add a WiFi or BT dongle if you need both working simultaneously.
My own experiences include days of trying to diagnose unreliable WiFi connectivity, the rejection of a Pi Zero W as faulty and much gnashing of teeth. Not only have I found that connectivity to the Pi Zero W is impaired by running both but it also creates issues between other devices on the same access point. Running an iperf3 test between two devices on 2.4 GHz drops to 0 data transferred when a 3rd device (pi) starts a Bluetooth scan when on WiFi. Turning off WiFi on the pi and using a USB Ethernet (wired) dongle and there is NO impact to the iperf3 test. So the Bluetooth scan does not seem to be adversely impacting 2.4GHz WiFi per se.
These tests have been with the latest releases of software/firmware and UniFi AP-AC-Pro Access Point on latest code.
It would be useful if some others experiencing performance issues could corroborate this behaviour.
If this has been covered in one of the 795 replies to this post (i only got through half of them) then it adds to the need for this to be an edit to the original post.
I write this to hopefully help others not criticise an excellent contribution to Hass.
Best Wishes
A while back I switched back to standard automations to change an input boolean. This was when my node-red server was less reliable. I’m now running a node-red container on a much more stable host, and I may switch back, but it works well.
Yes, the tdr/tad/tar/ta options are for “still in the house so we didn’t leave, but we’ll never arrive here” nodes. My third floor node is -tad, so it listens to the behavior of the other nodes only. First, second floor and garage are -tdr, which means they’re listening for arrival advertisements, but will only scan for depart when an mqtt message is sent to monitor/scan/depart.
My front door and my garage door trigger these depart alerts. I do use node red for this, see the monitor thread for more detail.
For five nodes, unless your house is giant, I would set most of your nodes to -tad.
Yes, it’s a known issue. However, mqtt messages sent from montor are so short, it doesn’t much matter or impact performance in my and other user’s testing.
But yes, monitor’s purpose is to reduce interference with 2.4GHz as much as possible by reducing the number of times that a bluetooth scan occurs.
@andrewjfreyer, Thanks for your fast response acknowledging that it is a known problem with the Pi hardware/firmware.
You say that “it does not much matter or impact performance in your or other user testing” but there are 33 replies to this post mentioning interference and many others citing network performance issues. It also confusing that it is repeatedly referred to in this thread as “Interference” when correctly operating WiFi and BT devices do not have a problem co-existing on 2.4Mhz. I love my Pis but i do think we should call it out when there is a design or implementation problem rather than suggesting it is just the nature of two protocols sharing a frequency.
I applaud your herculean efforts to get round this problem in Monitor and will no doubt try it but I would still urge you to add notes to the original post pointing new Hass users like myself to Monitor and the Pi WiFi/BT problem.
Thanks
There isn’t one problem here, nor is there only one solution. Bluetooth and Wifi are both operating on 2.4GHz bands, and they are known to interfere with one another (quick google search can easily verify). Since Wi-Fi is a higher-throughput protocol, it is less noise tolerant.
Users in this thread have experienced problems with presence causing problems with other wifi systems, unrelated to raspberry pi. It is not just an issue related to Pi.
So, to sum:
• Yes, co-operation of wifi and bluetooth on Pi can cause problems with the pi. Probably could be designed better or probably could upgrade the chipsets to be more noise tolerant.
• Yes, noisy bluetooth devices can cause interference with 2.4GHz Wi-Fi networks in general.
The first is a small problem for users of presence or monitor. The second is a major problem for some users of presence.
That said, for $5 - $10, I’m not going to blame the raspberry pi foundation’s design choices or learning curves They’re providing a great service to the DIY community by getting any hardware out there at this price point.
My objective is only to highlight what seems to be a major issue with using a Pi Zero W for WiFi and Bluetooth concurrently that does not seem to have been widely discussed.
All I can say for sure is that I can run bandwidth tests (iperf3) between 2 machines over 2.4GHz WiFi reliably until I startup a Pi (3rd machine) running WiFi and a Bluetooth scan and then the performance test looses data and ssh’s become unresponsive and time out. The pi affects all devices on the 2.4GHz WiFi not just the Pi. It looks like the Pi just splats across everything.
For me turning off WiFi and moving to, in my case, wired Ethernet dongles was a transformation. I now have 3 x Pi Zero W’s each doing Bluetooth scans every 6 seconds and my 2.4GHz WiFi is back to being steady as a rock. Plus random reports of Hue lights going unavailable has stopped as well.
I believe it could be a transformation for other users too and have not seen it as a suggested work around. I would like to see some other users try it and report back their experiences.
With regard to the Raspberry Pi Foundation, I too am a big fan, but when there is a problem they should be encouraged to be open about issues. I have been very surprised how difficult it has been to find out about this problem and had i known in advance i would probably have purchased Pi 3B’s rather than Pi Zero W’s because I now have dongles hanging out of the cases.
I am really only trying to be helpful!
Best Wishes
Below is the output from a 30 second iperf3 test between one Pi Zero W and a windows desktop.
On a second Pi Zero W connected to the network over WiFi I start a single Bluetooth scan for 2 non present devices after interval 9-10.
You can see that for the next 11 seconds communication between the first 2 independent devices is trashed. Moving the second Pi Zero W to a wired connection and the independent transfer does not miss a beat! I can add a log of that but there is nothing to see except a constant 40+ Mbps
Regards
Look, the point isn’t that 2.4 interference happens for everyone on every network in every circumstance at all times. Depends on hardware, depends on channel use, depends on traffic, etc.
It’s good to hear your network is unaffected. I still recommend monitor over presence because by running either script you are causing interference with adjacent devices using 2.4GHz spectrum, whether on your network or otherwise. If these devices are modern, it’s highly unlikely the interference will matter. On the other hand, if neighboring devices are older, cheap, or otherwise have lower noise tolerance, the constant scanning operation of presence can throttle performance or knock services offline.
Your single datapoint here doesn’t reflect the experience of a substantial number of users. It doesn’t mean that other users don’t understand the “real” problem or that other users haven’t tried switching interfaces. It also doesn’t mean that your neighbors are unaffected by your presence node. Do any of your neighbors have a baby monitor that runs on 2.4GHz? There’s a chance that constant scanning is causing that baby monitor to lose connection with the base for extended periods of time. Switching to monitor substantially mitigates that risk by reducing the number of name scans to a bare minimum.
… I’m really not sure what purpose we’re serving here by trying to rank and compare two different issues.
TL;DR Interference exists. Wi-Fi issues on a $5 computer exist. monitor is better suited for almost all circumstances than presence.
I’ve searched the thread and haven’t seen anyone with this issue yet. I have monitor up and running on a pi zero and it is reporting to my mqtt broker and updating the sensors in HA like it should. However, the only way it will update is to issue the sudo bash monitor.sh command from ssh. Once I do that I can see the whole process running and everything updates as it should.
I also have two scripts on HA to start the depart and arrival scans. These scripts work while I’m running the bash monitor.sh. But if I exit out of ssh and try them, nothing updates.
Also tried a reboot of the raspberry pi but that doesn’t seem to work. It’s like monitor is only running when I issue the command to start it. Is this normal? What else can I check?
I get this:
raspberrypi systemd[1]: monitor.service: Failed with result ‘exit-code’.
Also, when I do a sudo service monitor status I get this:
● monitor.service - Monitor Service
Loaded: loaded (/etc/systemd/system/monitor.service; enabled; vendor preset: enabled)
Active: activating (auto-restart) (Result: exit-code) since Sat 2019-02-16 23:09:22 GMT; 9s ago
Process: 12474 ExecStart=/bin/bash /home/pi/presence/monitor/monitor.sh & (code=exited, status=210/CHROOT)
Main PID: 12474 (code=exited, status=210/CHROOT)
So I did a clean re-install from scratch and it appears to be working now. Initially I was using presence. I uninstalled presence and installed monitor but I guess something got messed up in the process. Clean install seems to have fixed it.
Ah ha! As I stated, I was using presence prior. That path is not right and probably where I messed up. Which is why a clean install fixed it. Totally my mistake.
All is good now. Been up and running for the last 8 hrs with no issues.
sudo service monitor returns
monitor.service - Monitor Service
Loaded: loaded (/etc/systemd/system/monitor.service; enabled; vendor preset: enabled) Active: active (running) since Sun 2019-02-17 02:53:15 GMT; 8h ago
They’re providing a great service to the DIY community by getting any hardware out there at this price point.