The exact time between MQTT messages will not necessarily be the delay between scans. The ‘between’ scans item is the delay between each scan of each owner device in the list. Workflow is this:
First Listed Owner Device > Scan > Present? > Wait 30 Seconds > Second Listed Owner Device > Scan > … and so on
So, I would expect that the Tom’s iPhone topic would receive an MQTT message every 90 seconds if you have three owner devices registered. The devices are scanned sequentially to keep the work on the bluetooth hardware down.
At what point does a device go “away”? Is it the first time that the confidence level goes to 0? Trying to understand when the “delayBetweenOwnerScansWhenAway” takes effect?
After some testing tonight with three phones and using the default values from behavior_presence with one instance of presence.sh running (1 Pi), here’s what I am seeing when testing the time it takes to notice that a phone has come back within BT range:
Best case scenario for reporting a re-connection when in BT range (test by turning BT off and then back on) is 1 second or less - GOOD!
Worst case scenario for reporting a re-connection is 70 seconds. Not as good.
The range of re-connection times is caused by the looping of the script and the sleeps - since the script loops through each device, if the phone comes in range right after the script checked for it’s presence, it must wait for the check of the other phones + the time of the wait scan delay (default 30 seconds between phones). This worst case scenario time would be mitigated by the number of instances (Pi’s) that are setup to run the script - so the more Pi’s the better chance the phone has to be scanned during the scanning loops. For every phone that you add into the loop - the worst case scenario would increase by 30 seconds. If the phone’s BT comes within range at just the right time - then detection and subsequent mqtt notification is practically instantaneous.
I understand that by decreasing the delays in the behavior_presence file, I can bring the worst case scenario down, but since I will eventually have a total of 5 phones being checked I’m not sure that the presence detection will be fast enough for my use…
Does this make sense? Am I misunderstanding anything?
Thank you again for your efforts and sharing this project - I’m still hoping to be able to use this to help with my presence detection.
Alas, I have now tried to install this on a Raspberry Pi Zero W twice. Each time I get to step 7 and reboot the RPi. Upon reboot, the wifi on it no longer appears to be working as the RPi is no longer on the network.
@eboon Yes, a device is “away” when confidence goes to 0. Think of the value confidence as "confidence that the user is home.
The delayBetweenOwnerScansWhenAway is an opportunity for you to allow the system to detect “arrival” faster than “departure.” Phrased another way, the system by default will scan more quickly when no devices are at home.
I’m only tracking two devices, but I do understand that five devices may be difficult to track since we’re compounding delays. I’ll investigate that this weekend to see if I can improve the scan times for larger sets of tracked devices.
Thank you again Andrew - I really like the way you are approaching this without the need to do anything to the client devices! One of my must haves is quick detection on re-entry. Instead of scanning one device then sleeping - couldn’t you do a group scan of all devices between sleeps?
Again - thanks for sharing and continuing to accept feedback for features/improvements!
@gumbo Is it possible that when you reboot your router is assigning a different IP address to the Pi? Are you rebooting through sudo reboot or via unplugging (should be the former)? Have you started from a fresh image, or are you trying to follow the instructions over an existing jessie/wheezy installation?
On your suggestion just now, I ran a few tests with hcitool and I think we probably can scan in much more rapid succession. I’ll need to refactor, but it shouldn’t be terribly difficult. Great comment!
This is keyed for a full-stack bluetooth device, like a cell phone, tablet, or laptop. Bluetooth LE devices typically do not respond to name requests.
@jjgadget - i take the above statement back. I’ve added support for bluetooth beacon tracking , and I’ll be releasing an update to version 0.4.00 soon!
I start with a newly formatted sd card and install the latest version of raspbian lite. I set the time zone, locale, and expand the file system via sudo raspi-config. I then follow the steps on your instructions. I literally copy and paste the commands listed. The only deviation I make is to get the version of bluez.
Speaking of which, are you using bluez-5.49.tar.xz dated 10-Mar-2018?
it’s a mystery to me. Definitely not the first time I have used a Raspberry Pi Zero W. I am just not seeing where the problem happens.
Yes, I’m using 49. Does this happen each time you reboot? Are you able to stay connected to Wi-Fi at all on reboot? Not sure this would have anything to do with the instructions if you’re successfully adding the supplicant file… :-/
I would connect to wired if available to check that something strange did not happen to the wireless config - if that’s a no-go, hook it up directly to a monitor and make sure it is booting up properly.
edit: Oh wait… it’s a Zero - that might be difficult … nvm
Thank you Andrew for the updates to this script - the detection time now when a new (or disconnected device) comes back in range is very good - about 15 seconds worst case. That is with 4 phones being scanned in the owner_devices file.
One very odd anomaly that I am seeing though, is that when the service is running, my Pi B becomes very lagy and unresponsive through my SSH session. CPU (as observed by top) never goes over 1%, but keystrokes may take anywhere from 0 - 10 seconds to display in the terminal (mostly more towards the top end) - basically unusable. Wondering if anyone else is seeing anything like this. I am using a brand new install of Jessie lite on a Pi B with nothing else running - I created from scratch. Very odd…???
Yes. It rebooted fine after I went through the sudo raspi-config routine. I checked with a different SD card - installing the brand new raspbian lite and putting on the ssh and wpa_supplicant files. The WiFi just refuses to work anymore. I even swapped out the power supply. Boots up (at least the light flashes and stays on) but will not show up on the network.
