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:
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.
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?
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.
@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:
(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!
@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.
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.