@eBoon nope! I’m running this also on an original pi that has an adapter. The only difference for installation is to note whether you’re running jessie or wheezy.
@PianSom The scan duration is the duration that takes for hcitool to return a scan. If it doesn’t find anything, it’ll timeout after about 5 seconds, default. That’s what you’re seeing with the 5000ms just after you turn bluetooth off on her phone.
In some cases, I’ve noticed the same behavior - that hcitool returns nearly immediately. I’d guess this is internal caching, but I’m not sure I care enough to investigate.
I agree that the time to scan appears to be - at best - only moderately interesting. It seems to be loosely correlated to distance in my testing, but not by much.
OK - initial install looks promising - seems to be working as advertised. I’m an AppDaemon user so going to work on using with AppDaemon apps.
One question (so far) - any way to add comments in the owner_devices or guest_devices file?
Thanks for this - it looks really good!!
Anything after a hash should be treated as a comment, but I haven’t tested.
I get this:
Apr 18 21:09:43 raspberrypi bash[1062]: Error: Invalid publish topic 'location/owner/kitchen/# Tom's iPhone', does it contain '+' or '#'?
This is with adding a comment above each MAC with the name of the phone.
Thanks!
Yeah, that’s probably because I’m reading these files in. I’ll look into comment support sometime soon.
With these default values in behavior_presence:
delayBetweenOwnerScansWhenAway=7
delayBetweenOwnerScansWhenPresent=30
delayBetweenGuestScans=5
verifyByRepeatedlyQuerying=5
I was expecting to see an mqtt message every 30 seconds, but I only see a message about every 90 seconds. Is that the expected behavior?
location/owner/kitchen/xxx {"confidence":"100","name":"Tom's iPhone","scan_duration_ms":"412","timestamp":"Wed Apr 18 2018 23:04:51 GMT+0000 (UTC)"}
location/owner/kitchen/xxx {"confidence":"100","name":"Tom's iPhone","scan_duration_ms":"299","timestamp":"Wed Apr 18 2018 23:06:23 GMT+0000 (UTC)"}
location/owner/kitchen/xxx {"confidence":"100","name":"Tom's iPhone","scan_duration_ms":"2381","timestamp":"Wed Apr 18 2018 23:07:56 GMT+0000 (UTC)"}
location/owner/kitchen/xxx {"confidence":"100","name":"Tom's iPhone","scan_duration_ms":"1126","timestamp":"Wed Apr 18 2018 23:09:30 GMT+0000 (UTC)"}
location/owner/kitchen/xxx {"confidence":"100","name":"Tom's iPhone","scan_duration_ms":"727","timestamp":"Wed Apr 18 2018 23:11:04 GMT+0000 (UTC)"}
Thanks!
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.
That makes sense - indeed I do have three devices (I removed the other two for clarity in my example).
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.
Any guesses as to what went wrong?
Thanks.
@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!
More than happy to help you test whenever you have something ready. Thanks!
Cool. Appreciate it!
Does this only work on standard BT or will it also track a BLE device like my Xiaomi MiBand?
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!
UPDATE - 0.4 is on github! @jjgadget