So I went ahead and ordered some PIR sensors, found a script that works pretty well (through limited initial testing) here and I think I am pretty happy with this two-for-one setup. The mqtt pir sensor is quite quick to respond (I have some battery powered Zwave PIR sensors and they have a 3-5 second lag, whereas this is within 1 second) The only thing I need to figure out now is how to get this python script to always run. I am sure it is a stupid question and I don’t mean to hijack the thread, just thought someone in this thread might know the most efficient way. Could it be added to the ‘presence.service’ file? Still new to all this.
Yeah, no problem adding it to the same service. There’s probably value in being able to separately start and stop.
Please pardon if these questions are simple or dumb but I will ask anyway.
In the write up it says to post the following in the mqtt_preferences file:
mqtt_address=“ip.address.of.broker”
mqtt_user=“your broker username”
mqtt_password=“your broker password”
mqtt_topicpath="location"
mqtt_room=“your pi’s location”
The first three lines are no problem. Is the fourth line entered verbatim or should location be something like garage, kitchen, etc.? Because that is what I thought would go between the quotes on the fifth line.
My other question at the moment concerns the following lines:
- platform: mqtt
state_topic: ‘location/owner/garage/00:00:00:00:00:00’
In the state_topic line, what MAC address is used in place of 00:00:00:00:00:00?
Thanks for any and all help.
leave it as “location” unless you are changing the mqtt sensor from
state_topic: ‘location/owner/garage/00:00:00:00:00:00’
to something else.
00:00:00:00:00:00 needs to be replaced with the bluetooth MAC of your phone (you can find it in settings). and also needs to be in the ‘owner_devices’ file
1 Like
Thank you for the information. I made the necessary modifications. Restarted everything but still see nothing.
Would the following request work to see the updates on the broker?
mosquitto_sub -d -u user -P password -t location/owner/garage/xx:xx:xx:xx:xx:xx with xx.xx etc being the bluetooth MAC address?
All I see is sending PINGREQ and received PINGRESP.
Thanks.
Andrew, where did you get the server, api-call-service, and api-current-state nodes? I don’t see them at flows.nodered.org.
thanks for the info.
created a separate service and it is working!
thanks again for creating this
1 Like
is everything configured correctly? i would start there and make sure it is finding the bluetooth MAC address you put in
run
sudo systemctl status presence.service
the output should give you the name of your phone like so:
Apr 24 03:39:09 raspberrypi bash[245]: location/owner/bedroom/xx:xx:xx:xx:xx:xx { confidence : 100, name : Jake’s iPhone, scan_durat......
if not you have a bluetooth problem not an mqtt problem
after that you can ensure the mqtt info is set up properly
One thing to watch out for is the version of mosquitto_pub that ships with Raspbian is old and uses a slash as part of the MQTT client ID. Newer versions of the broker will reject that client ID and mosquitto_pub won’t complain.
These are part of the node-red-contrib-home-assistant node.
Looks like I broiught it to life in HA as well. Now will experiment a little to see how many Zeros I might need.
Also planning to implement it on my NUC on which HA is running.
Regarding lagging network I made the following observation: network is not constantly slow, but typing away in ssh hangs every few seconds or so for a short moment, a little less than a second maybe.
Have others experienced the same?
Lars
P.S. Really smart idea and great contribution. Thanks !
1 Like
Fantastic solution @andrewjfreyer. You have the same scenario as I do.
As a matter a fact, I started a script (python) a few weeks ago to do pretty much what you do, but it is in its early stages.
One big problem that I have is that every time that the Bluetooth scans (even with your code), it interferes with my wifi. It gets even worse when the target is not home, causing a lot of packages drops and increase the ping time.
Have anyone else had a problem with this? Its just impossible to play online games. I have tried to change wifi channels, moving things around… nothing helped.
On my script, the workaround was to increase the time to 10m when there is someone home and 1m when there is nobody home. But I naturally loose precision.
Another thing I do to save Bluetooth scans is to try a simple ping to the phone ip first. If the phone is not in the “resting” state, it works fine.
Another thing I do is right after one raspberry scan and find someone, it publishes on a topic and notifies every other raspberry, so they skip the current scan.
1 Like
I have been seeing similar symptoms. How did you determine it was WiFi interference?
1 Like
From my laptop I started to ping another computer on the network. I then started to trigger bluetooth scans manually. Ping times skyrocket and/or a few packages drop.
The original symptom was an online game, that became unplayable on the same weekend I started to poll for bt devices.
2 Likes
I cannot replicate that result.
I have a Pi B and a Pi Zero with Andrew’s script on, with default settings. From a third (wired) Pi I ping a wireless 2.4GHz printer across the house. I see no obvious change in ping times/reliability when I start or stop the service on both machines.
Odd.
Can you try to ping a device that it’s not available? It seems that when it can’t find a device, it tries harder and the wifi signal goes nuts. I lost 4 packages in a row and the pings around it went higher than seconds. I was pinging 2 devices. One was present, and another one wasn’t
1 Like
Many users have reported the same symptoms. I have not noticed it myself, but I do have a robust multi-AP Ubiquiti network that mostly uses 5GHz at home.
I think a solution may be to enable and/or disable scanning based on subscription to an MQTT topic posted to the same broker. Perhaps trigger presence scanning when someone is home only if an exterior door is opened, else presume that the user remains home.
I’ll investigate. Thank you for this very useful datapoint.
1 Like
Good idea for testing. I am seeing similar results. Running presence on one Pi B and then pinging 8.8.8.8 from another Pi B - here are my results:
Tue Apr 24 08:19:43 2018 64 bytes from 8.8.8.8: icmp_seq=247 ttl=59 time=23.8 ms
Tue Apr 24 08:19:44 2018 64 bytes from 8.8.8.8: icmp_seq=248 ttl=59 time=21.5 ms
Tue Apr 24 08:19:45 2018 64 bytes from 8.8.8.8: icmp_seq=249 ttl=59 time=20.5 ms
Tue Apr 24 08:19:46 2018 64 bytes from 8.8.8.8: icmp_seq=250 ttl=59 time=17.7 ms
Tue Apr 24 08:19:47 2018 64 bytes from 8.8.8.8: icmp_seq=251 ttl=59 time=61.5 ms <===
Tue Apr 24 08:19:49 2018 64 bytes from 8.8.8.8: icmp_seq=252 ttl=59 time=1187 ms <===
Tue Apr 24 08:19:49 2018 64 bytes from 8.8.8.8: icmp_seq=253 ttl=59 time=199 ms <===
Tue Apr 24 08:19:53 2018 64 bytes from 8.8.8.8: icmp_seq=254 ttl=59 time=2785 ms <===
Tue Apr 24 08:19:53 2018 64 bytes from 8.8.8.8: icmp_seq=255 ttl=59 time=1707 ms <===
Tue Apr 24 08:19:53 2018 64 bytes from 8.8.8.8: icmp_seq=256 ttl=59 time=720 ms <===
Tue Apr 24 08:19:53 2018 64 bytes from 8.8.8.8: icmp_seq=257 ttl=59 time=28.0 ms
Tue Apr 24 08:19:54 2018 64 bytes from 8.8.8.8: icmp_seq=258 ttl=59 time=26.0 ms
Tue Apr 24 08:19:55 2018 64 bytes from 8.8.8.8: icmp_seq=259 ttl=59 time=31.3 ms
Tue Apr 24 08:19:56 2018 64 bytes from 8.8.8.8: icmp_seq=260 ttl=59 time=21.4 ms
Tue Apr 24 08:19:57 2018 64 bytes from 8.8.8.8: icmp_seq=261 ttl=59 time=19.3 ms
Tue Apr 24 08:19:58 2018 64 bytes from 8.8.8.8: icmp_seq=262 ttl=59 time=18.6 ms
Tue Apr 24 08:19:59 2018 64 bytes from 8.8.8.8: icmp_seq=263 ttl=59 time=16.0 ms
Tue Apr 24 08:20:00 2018 64 bytes from 8.8.8.8: icmp_seq=264 ttl=59 time=22.4 ms
Tue Apr 24 08:20:01 2018 64 bytes from 8.8.8.8: icmp_seq=265 ttl=59 time=15.7 ms
Tue Apr 24 08:20:02 2018 64 bytes from 8.8.8.8: icmp_seq=266 ttl=59 time=24.0 ms
Tue Apr 24 08:20:03 2018 64 bytes from 8.8.8.8: icmp_seq=267 ttl=59 time=28.6 ms
Tue Apr 24 08:20:04 2018 64 bytes from 8.8.8.8: icmp_seq=268 ttl=59 time=28.0 ms
Tue Apr 24 08:20:05 2018 64 bytes from 8.8.8.8: icmp_seq=269 ttl=59 time=21.5 ms
Tue Apr 24 08:20:06 2018 64 bytes from 8.8.8.8: icmp_seq=270 ttl=59 time=22.8 ms
Tue Apr 24 08:20:07 2018 64 bytes from 8.8.8.8: icmp_seq=271 ttl=59 time=12.2 ms
Tue Apr 24 08:20:08 2018 64 bytes from 8.8.8.8: icmp_seq=272 ttl=59 time=31.4 ms
Tue Apr 24 08:20:09 2018 64 bytes from 8.8.8.8: icmp_seq=273 ttl=59 time=19.9 ms
Tue Apr 24 08:20:10 2018 64 bytes from 8.8.8.8: icmp_seq=274 ttl=59 time=24.0 ms
Tue Apr 24 08:20:11 2018 64 bytes from 8.8.8.8: icmp_seq=275 ttl=59 time=24.0 ms
Tue Apr 24 08:20:12 2018 64 bytes from 8.8.8.8: icmp_seq=276 ttl=59 time=153 ms
Tue Apr 24 08:20:13 2018 64 bytes from 8.8.8.8: icmp_seq=277 ttl=59 time=25.0 ms
Tue Apr 24 08:20:14 2018 64 bytes from 8.8.8.8: icmp_seq=278 ttl=59 time=18.9 ms
Tue Apr 24 08:20:15 2018 64 bytes from 8.8.8.8: icmp_seq=279 ttl=59 time=17.6 ms
Tue Apr 24 08:20:16 2018 64 bytes from 8.8.8.8: icmp_seq=280 ttl=59 time=20.8 ms
Tue Apr 24 08:20:18 2018 64 bytes from 8.8.8.8: icmp_seq=281 ttl=59 time=804 ms <===
Tue Apr 24 08:20:18 2018 64 bytes from 8.8.8.8: icmp_seq=282 ttl=59 time=43.8 ms <===
Tue Apr 24 08:20:19 2018 64 bytes from 8.8.8.8: icmp_seq=283 ttl=59 time=215 ms <===
Tue Apr 24 08:20:23 2018 64 bytes from 8.8.8.8: icmp_seq=284 ttl=59 time=2805 ms <===
Tue Apr 24 08:20:23 2018 64 bytes from 8.8.8.8: icmp_seq=285 ttl=59 time=1805 ms <===
Tue Apr 24 08:20:25 2018 64 bytes from 8.8.8.8: icmp_seq=287 ttl=59 time=1574 ms <===
Tue Apr 24 08:20:25 2018 64 bytes from 8.8.8.8: icmp_seq=288 ttl=59 time=574 ms <===
Tue Apr 24 08:20:25 2018 64 bytes from 8.8.8.8: icmp_seq=289 ttl=59 time=24.8 ms
Tue Apr 24 08:20:26 2018 64 bytes from 8.8.8.8: icmp_seq=290 ttl=59 time=23.4 ms
Tue Apr 24 08:20:27 2018 64 bytes from 8.8.8.8: icmp_seq=291 ttl=59 time=31.4 ms
Tue Apr 24 08:20:28 2018 64 bytes from 8.8.8.8: icmp_seq=292 ttl=59 time=26.3 ms
Tue Apr 24 08:20:29 2018 64 bytes from 8.8.8.8: icmp_seq=293 ttl=59 time=18.4 ms
Tue Apr 24 08:20:30 2018 64 bytes from 8.8.8.8: icmp_seq=294 ttl=59 time=31.5 ms
You can see two presence scan cycles in the ping results - I tested using two windows - one with the ping and another with the mqtt messages (to see when presence was scanning) perfect correlation to scan and increased ping time.
Very interesting …
1 Like
I am running a Linksys Velop mesh system (which is really awful - I cannot recommend it). This has a bluetooth capability at each node, so it may be that my wifi is optimised against BT interference
I just had another Pi Zero arrive, so installed it from fresh following your instructions. I thought that the script created behavior_preferences but got the MQTT message:
{"confidence":"100","name":"timeout: invalid time interval ‘hcitool’
When I checked, behavior_preferences was a zero byte file owned by root. Deleting it and putting my own in solved the issue