Bluetooth binding for presence detection

Hi everyone,
I’m quite new to OH. I was able to configure things using the MQTT and Zwave bindings for temperature and humidity sensors.
But I failed to setup a simple presence detection using OH-Bluetooth binding (OH running on Raspberrypi3). I want to use my family members smartphones and not dedicated beacon devices.
For this purpose I installed “BLE Scanner” app on my smartphones.
OH detected the beacons sent by the smartphones and I was able to create bluetooth:beacon things for them.
Unfortunately those things are identified by the Bluetooth Mac address and not by the uuid (e.g. ‘d009dda6-3ba6-4e70-9226-0199d0058f19’). Due to the anti-sniffing feature of randomized Bluetooth-Mac addresses on smartphones, the configuration of the OH item is incorrect after a few minutes because it does not match the modified smartphone Mac anymore. This shouldn’t be a problem if one uses dedicated beacon devices like key finders, but I’d prefer to rely on the smartphone only.
Would it be feasible to add an additional configuration parameter UUID to OH’s Bluetooth binding which would enable the use of (pure, just with the Bluetooth beacon app installed) smartphones for presence detection?

I learned that there are various other possibilities out there for presence detection e.g. based on network binding looking for the WLAN connection of the particular smartphone or using the ESPresense solution but I’d like to strive to a pure OH-Smartphone solution without the need of additional gadgets or a running WIFI router.

Cheers Chris

The whole reason that phone rotate their MAC addresses is a privacy feature and it’s a good good thing. Without that you can be tracked everywhere you go in public. It used to be the case, at least on Android phones, that you could turn the MAC randomization off for BT but I don’t know if modern phones allow that.

I haven’t kept up with this space for a few years but I did spend a lot of time trying to get BT tracking of phones to work for presence detection working and have since abandoned it. I just don’t think it can ever work with just phones with the privacy features phones employ these days.

The reason those other solutions exist is because a “pure OH-Smartphone” solution simply isn’t feasible. You need something running on the phone to tell OH where it is, or you need something on OH to detect the phone despite the MAC randomization.

Personally, I have Android phones and the openHAB Android app will report the currently connected SSID to an Item in OH. I find that to work better than everything else I’ve ever tried. And I’ve tried:

  • BT tracking including using third party tracking using ReelyActive
  • FIND which worked great but requires an app on the phone and a service running and doesn’t work with “fruit” phones. But the precision was down to the room which was cool.
  • ARPing from the networking binding and from an external script
  • Custom BT code to parse through the broadcast packets (I learned a lot about Dexcom CGM that way though).
  • GPS based using Tasker + Autolocation, just Tasker, and GPSTracker
  • Bayesean based reasoner: Bayesian Group Suite - Activation Rule
  • Various combinations of all of the above

Nothing has been as reliable and easy to set up as just having the phone report what SSID it’s connected to.

I can tell a very similar story. At this point I use the SSID feature of the Android app as well. But, I admit, with increasing “battery optimizations”, it gets harder with every generation to keep this working in “real time”. Right now, I’d say it’s works 80% of the time within the timeframe I’d like, but there are certainly plenty of times that when I get home, I leave my bike at the top of the driveway, go get the mail, stop and check on the front yard plants, maybe say a quick hi to the neighbors before I’m finally deemed “home” and the garage door opens.

One of the things moldering on my long term to do list is to try the multi-find server version which as I understand it should fix both the app requirement and the fruit problem.

Yes, nothing I’ve tried has worked well enough for timely arrival detection. For the garage door I use Tasker which pops up a dialog asking if I want to open the garage when I get close(ish) to the house. Sometimes it happens when I get to the stop sign near the house, sometimes not until I get to the driveway.

But I don’t really even use that so much any more because the new car has Android Auto so I don’t have my phone up where I can see it (wish Tasker had Android Auto support). I just use Google Assistant to open the garage when I get to the driveway now (which might be going away soon too as Gemini takes over :angry: Gotta love Google’s propensity to replace services with less capable ones).

Definitely post a tutorial if you do! :smiley:

Hi Rich and Justin,

thank you very much for your quick and valuable answers.
Interesting, that presence detection is somehow complicated. I really underestimated the effort because of my poor knowledge of Bluetooth beacons and Android’s (I guess IPhones do the same) anti-sniffing mechanism.
I agree it’s an important feature of nowadays smartphones to change their Mac-address every few minutes in order to preserve privacy of their owners.
I didn’t find a possibility to switch of the Mac-address randomization in Android, maybe I’d need to root the phone for that purpose, which I don’t want to.
Probably OH’s Bluetooth binding works fine for presence detection if one buys a regular beacon device like a key finder (I didn’t try because I don’t own such gadget). Currently I don’t want to buy each member of my family such a device. Therefore I prefer the additional “beacon”-app running on the phones.
Maybe I extend OH’s bluetooth binding one time to support such use-case (beacon simulated by smartphone app for presence detection directly in OH), if this makes sense to you and there are other users who want to use “smartphone”-beacons for that purpose.
For the time being l replicate the ESPresense functionality somehow (I prefer picos over ESP) because I have already some picos running in other rooms of my apartment, communicating to Mosquitto MQTT.

Again, thank you for your support! Great to find such a vital community in OH!

Chris

Don’t get stuck in an XY Problem. Your problem is detecting presence. Your problem is not necessarily detecting presence through Bluetooth. Don’t trap yourself by preselecting your solution space.

Be sure to expand beyond Bluetooth.

If you are going to go that far, you may was well consider WiFi, GPS, or a combination of them. Heck, Tasker can even do geolocation based on the cell towers it can see.

I had a look for it in my Samsung Z Flip 5. I can still disable WiFi MAC randomization in the Developer settings, but there’s nothing for Bluetooth.

Adding to what Rich said, note that Bluetooth range is roughly 33ft in a best-case scenario, while 2.4Ghz WiFi range is up to 150ft. Houses aren’t best-case scenarios. Depending on what you want to automate, that extra 5x range may be highly beneficial.

The other thing to keep in mind is that phone-based presence detection requires that the devices be reliably available. It breaks down when:

  • the phone is left behind at home or somewhere else
  • the phone’s battery dies
  • the phone is in Airplane Mode or has its WiFi/BT turned off

As is often the case, humans are the weak point. You’ll need to train them (and yourself) to ensure that they can be tracked by openHAB…and it’s still easy to forget. I recently turned my phone’s WiFi off, because it was trying to connect to a store’s mediocre public WiFi and no data was coming through. I didn’t remember to turn it back on until long after I got home.

All this is to say that presence detection is one of the hardest things to do well in home automation. And by “do well”, I mean “works exactly as intended 99% of the time”. Any less than that and it becomes more of a hinderence than a help.

I am using this soap client with my Fritz.Box and it’s pretty reliable…I tested also several implantation but best was the soap client implementation

#!/usr/bin/php
<?php
if(empty($argv[1])){
        die("MAC address missing");
}else{
        $mac = $argv[1];
}
if(empty($argv[2])){
        die("BOX IP or IPs  missing");
}else{
        $ipList = explode(":",$argv[2]);
}
function checkDevice($ip,$mac){
        $result = "";
        $uri = "urn:dslforum-org:service:Hosts:1";
        $location = "http://".$ip.":49000/upnp/control/hosts";
        $client = new SoapClient(
            null,
            array(
                'location'   => $location,
                'uri'        => $uri,
                'noroot'     => True,
                'login'      => "",
                'password'   => "",
                'connection_timeout' => 5
                )
        );
        try{
                $query = $client->GetSpecificHostEntry(new SoapParam($mac,'NewMACAddress'));
                $result = $query['NewActive'];
        }catch(SoapFault $fault){
                $result = 0;
        }
        return $result;
}
function checkAllDevices($ipList,$mac){
        $result = 'OFF';
        foreach($ipList as $ip){
                $resultCheck = checkDevice($ip,$mac);
                if($resultCheck == 1){
                        $result = 'ON';
                }
        }
        return $result;
}
echo checkAllDevices($ipList,$mac);
?>

If I wasn’t fighting so much with the somehow half-baked HA MQTT discovery implementation in openHAB at the moment, I’d suggest using our presence/device tracker implementation in Theengs Gateway.

For anyone using manual things and item definitions, as I do, it is a very reliable and very fast local Bluetooth detection with universally compatible MQTT publishing. So fast and reliable that I use it daily to activate/deactivate the alarm system when leaving the house or coming back home through my Apple Watch.

It works really well with randomly changing bluetooth MAC addresses when using the Identity MAC and the corresponding Identity Resolving Key for Apple devices.

With Android phones being somewhat quieter on the bluetooth front, the best solution there is to install a beacon app like Beacon Simulator, When using a pre-defined uuid

546865656E67732D69426561636F6E31

with such an app, Theengs Gateway also automatically recognises them for publishing under the Theengs iBeacon Tracker type.

For Android or any other device with randomly changing Bluetooth MAC address an IRK is also required.

I’m still planning on writing up an instruction here once I figure out how to properly make the MQTT discovery work with openHAB as well, but for any other controller without an y discovery there is also the possibility of having the settings

"discovery": 0,
…
"general_presence": 1,

which will send an MQTT message

{"id": “AA:BB:CC:DD:EE:FF”, "presence": "present"}

when a device comes into Bluetooth range, and

{"id": “AA:BB:CC:DD:EE:FF”, "presence": "absent"}

when the device has been out of Bluetooth range for the specified

"tracker_timeout": 120,

seconds in the settings.