[presence] Reliable, Multi-User, Distributed Bluetooth Occupancy/Presence Detection

Ha! This logic is, ostensibly, a percentage based on how many repetitions remain to be performed before a device is considered ‘away’. This is not particularly elegant or inspired, haha.

Yes, I have looked at the bayesian sensor, but I haven’t implemented it yet as a replacement for the simple max_min average. Likely a good idea to experiment with.

For the git command, you could stash, pull, and pop your changes back. Like this:

git stash
git pull
git stash pop

This would restore any files you modify.

Just updated. Hmmmm …

Well, I suppose it’s possible that the scan duration doesn’t change. :slight_smile: Though what happened on that second line seems odd.

presence/owner/IanStudy/40:98:AD:xx:xx:xx {"confidence":"100","name":"BunnyHop","scan_duration_ms":"108704","timestamp":"Wed Apr 18 2018 17:34:14 GMT+0100 (BST)"}
presence/owner/IanStudy/40:98:AD:xx:xx:xx {"confidence":"0","name":"Unknown","scan_duration_ms":"108704","timestamp":"Wed Apr 18 2018 17:34:44 GMT+0100 (BST)"}
presence/owner/IanStudy/40:98:AD:xx:xx:xx {"confidence":"100","name":"BunnyHop","scan_duration_ms":"108704","timestamp":"Wed Apr 18 2018 17:35:21 GMT+0100 (BST)"}

Hmm. Scan durations are not quite that consistent on my end. I’ll see what’s going on with that. I’m not seeing this behavior on mine and it shouldn’t really be possible based on the loops.

@PianSom - found the bug relating to duration. Thanks for pointing this out. Corrected. I have not been able to narrow down why your second line is failing.

1 Like

Maybe a dumb question, but does mosquito get installed to every Raspberry Pi Zero W you use in this project? If one has mosquito already in use for other things, does it still need to be installed on any of the Raspberry Pi Zero W’s used in this project?

Thanks.

The instructions on github are for a complete soup to nuts installation. If you already have mosquitto successfully installed, there’s no need to reinstall.

Thanks for replying. I really didn’t think so but wanted to clarify. Interesting project. I hope to try it out soon.

Any issues or gotchas running on a regular old Pi B instead of a zero? I have a few unused Pi Bs around doing nothing …

Thanks for this - looks really intriguing!

Tom

2 Likes

@andrewjfreyer - latest version working smoothly; no blank lines atm. I’m slightly curious what scan_duration_ms means if a device isn’t found, but that’s not really important. I’m seeing quite a wide (factor of 5) variety of times while seated still, so it seems to be of little value.

UPDATE - just saw the following sequence fro my wife’s iPhone:

presence/owner/IanStudy/D0:C5:xxxx{"confidence":"100","name":"IbbleDibble","scan_duration_ms":"2090","timestamp":"Wed Apr 18 2018 20:12:07 GMT+0100 (BST)"}
presence/owner/IanStudy/D0:C5:xxxx {"confidence":"80","name":"IbbleDibble","scan_duration_ms":"5148","timestamp":"Wed Apr 18 2018 20:13:18 GMT+0100 (BST)"}
presence/owner/IanStudy/D0:C5:xxxx {"confidence":"60","name":"IbbleDibble","scan_duration_ms":"5147","timestamp":"Wed Apr 18 2018 20:13:31 GMT+0100 (BST)"}
presence/owner/IanStudy/D0:C5:xxxx {"confidence":"40","name":"IbbleDibble","scan_duration_ms":"25034","timestamp":"Wed Apr 18 2018 20:14:03 GMT+0100 (BST)"}
presence/owner/IanStudy/D0:C5:xxxx {"confidence":"20","name":"IbbleDibble","scan_duration_ms":"22","timestamp":"Wed Apr 18 2018 20:14:10 GMT+0100 (BST)"}
presence/owner/IanStudy/D0:C5:xxxx {"confidence":"0","name":"IbbleDibble","scan_duration_ms":"21","timestamp":"Wed Apr 18 2018 20:14:17 GMT+0100 (BST)"}
presence/owner/IanStudy/D0:C5:xxxx {"confidence":"0","name":"Unknown","scan_duration_ms":"","timestamp":"Wed Apr 18 2018 20:14:24 GMT+0100 (BST)"}

(Don’t ask me, I don’t know why she calls her phone IbbleDibble)

@gumbo and @eBoon - I’m running the script on a Pi that I use as my Mosquitto broker (and Appdaemon machine, and pihole server) with no issues. I installed following the excellent instructions from Step 3, omitting Step 8. Obviously you need a Pi with Bluetooth!

1 Like

Awesome! - now I have a use for those Pis that are just sitting around gathering dust! Installing now…

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

1 Like

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

1 Like

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.

1 Like

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:

  1. 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!
  2. 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.