Presence detection using Bluetooth trackers with Raspberry Pi

I’ve been working on a project for a while, and finally got around to cleaning it up and publishing it. While I’ve really simplified the process a lot, it is a bit of a project to setup and is really only for those familiar with things like Raspberry Pi/Node-Red/etc…

The overall design is pretty simple:

  • There are any number of Scanners (raspberry Pi devices) that you can place around your house to provide coverage. Each scanner simply reports on what BTLE devices it sees.
  • Processing node which uses a Node-Red flow for each BTLE device you want to monitor.

I’ve created the repo here.

If anyone is interested in giving it a shot, I’d be happy to help and further develop the documentation for it.

1 Like

Looks interesting… there was a similar project using a “scanner” app but I think it was abandoned, so this might make it worthwhile for some people (paging @JDRoberts).

I think I started playing around with a similar solution using Noble and Node, but I’m too lazy to actually tackle a problem that is not like immediately on my face, so I’ll see what I can get out of this. :slight_smile:

1 Like

Yea, I started this last year because I was looking for something “simple”. And I ended up with this!

Feel free to open up any issues on the repo or reach out to me for anything on it. There were a number of challenges I had to work with (some I tried to document). But would be happy to help out. There might be an easier node-red BTLE scanner but I didn’t try any others…

So far (been running for over a year) works great. I have a few pi Zeros around the house doing the scanning, and one doing the actually processing.

1 Like

Can I ask a question…why did you decide to go the MQTT route? Why not a direct call to ST?

It’s actually a clever solution, better than what I was thinking about implementing for micro-location.

My idea was a variation of the solution that was developed, where you’d have beacons in the rooms and a scanner / phone checking for nearby items and calculating your location based on which beacons where closer – a whole mess of RSSI math and nasty bits.

But this solution is more elegant, and it could probably be implemented for indoor tracking fairly easily. With the low cost / footprint of a Pi Zero W you’d have “sensors” around the house and you would carry the beacon (instead of beacons around the house and you carry the sensor).

The only concern about this is how finicky BLE devices are when it comes to transmissions being interrupted by anything.

Absent a chip implant, none of this works if you’re a nudist.

1 Like

it just seemed easier at the time to do MQTT since I already needed it to aggregate the sensors.

So far with the limited BT devices I have tried (PebbleBee Honey & Trackr Pixel) they both are really solid. I would expect most of the trackers to be that way (otherwise they wouldn’t really track?)

One thing you can add to the flow is some kind of notification (e.g. email or logging) so you can see exactly when the events are triggered.

1 Like

Well technically that depends on how far you’re willing to go… there are other methods of having a sensor “on” your person… :slight_smile:

I think this has potential, particularly because the trackers like the pixel are tiny and work relatively well.

With that said, the reliance on the MQTT bridge might turn off some people, since that’s “yet another thing” that would need to be configured. Sure, if you already have it or you don’t care about doing the work then it’s not a big deal, but for others it might be… a bridge too far. HA!

Is the bridge a separate device that you set up on a Pi or some such and all the “sensors” report to it, do you have one of the sensors doing double duty as the bridge, etc?

Your instructions are a little on the light side, particularly for us that are much too lazy. I have all the hardware, but I’m looking at it and saying “man, this looks like A LOT of work” :slight_smile:

The sensor work is not a lot, so in my case I have one of my sensors running MQTT and the other node-red flows.
The problem I was trying to solve with all this, was we have a pet sitter that comes to our house when we are on vacation. And the regular ST presence sensor just went through batteries too quickly to be useful. The BT trackers often can last a year or two before requiring a new battery. So, in this case I just give that person the tracker and they have it on their key-chain.

@viguara - I wasn’t sure how much detail to put into the docs (I did much of the work over a year ago… so…) and I wasn’t sure if anyone would really be interested. It actually isn’t as bas as it sounds. And I’d be happy to try to automate some of it (as a result of documenting all the specific steps).

If there are folks that are interested I could create a slack team (I am on slack all the time) for communications and help someone through the process. I could use that as an opportunity to better document the steps.

My feelings towards SmartThings presence sensing are well documented :slight_smile: and I think the fact that MANY solutions exist – WRT-based, a separate Android app, Life360, SharpTools and the like, tells me that I’m not the only one that’s not entirely happy with the reliability issues that have plagued SmartThings since the beginning.

Not only that, but this solution would be more adequate for tackling indoor presence, even if it requires some tweaking. You can find many, many previous efforts to handle this via room occupancy monitoring using motion sensors, pressure sensors, and the like.

I’ll have to look into this though because it just creates a lot of questions in my head… :slight_smile:

How are you handling multiple sensors being able to detect a single tracker, for example? I know in my house I can be standing in the middle of the family room and the official Trackr app can still detect a device in the middle of the kitchen. Are you doing any sort of work around which sensor is detecting the device as being closer?

Yea, Life360 works great for my family, but I couldn’t really use any of those options for a guest. There was another tool (OwnTracks) which did a really good job with location detection and also could tie into your own MQTT service. But again, I was looking for something that didn’t require running an app on a guests phone…

It works great for presence detection, indoor or close by (the trackers I’ve been using have pretty good range).

So each scanner reports on all the BT devices it sees and they all get aggregated to a single MQTT topic. Duplicates are fine, and as long as one of the scanners “sees” the sensor it knows it is “present”.

Yeah that’s what I thought… and I guess my idea was to have something a little more precise, although I’m sure this works well for your use case.

Some of the work that I’ve seen uses Noble, because you can scan for devices and access their metadata. This gist shows you how they grabbed the device information, including RSSI.

https://gist.github.com/eklimcz/b37c05b29d9ac7cdd040#file-gistfile1-js

In Noble, the perihperal.uuid is the MAC address. The actual uuid can be parsed out of the advertisement packet using the manufacturerData payload. This is useful because some devices like the Gimbal which keep messing around with their MAC address as a security feature.

Anyway, my thoughts were that a sensor would scan for devices, and figure out how far that device is based on RSSI. As always, someone has already done this and it’s well documented all over the interwebs…

So in an ideal world, you would have the “master” sensor that runs the MQTT bridge. Every “room sensor” so to speak would figure out what devices it sees (as you do now) but also how far that device is and pass that to the master. Abracadabra beep beep boop boop and you know that “item x is in room y.”

So instead of just knowing that the device is present, you would know that it’s present and that it’s closest to a particular sensor / room.

It all sounds great on paper of course. :slight_smile:

Yea, that would work I assume. I think you’d have to figure out how to map those to the actual physical space (knowing the RSSI is just one factor).

I made a crack at a setup script. I basically started with a clean Stretch mini install and tried to keep track of the commands I needed. This is what I have so far, and I think it’s pretty complete (both the scanner & processor together. Scanner only would be mostly the same but without MQTT)

Anyone want to take a crack at it?

I think with that, then importing the flows you’ll be mostly there.

Oh! I just discovered a similar solution someone put together where all the presences detection is done via an external script. Looks really similar to what I put together except that it does less work within Node-Red.


I’ll try to give this a try sometime. I suspect it would result in a MUCH easier integration (and it sounds like he figured out how to detect other kinds of BLE devices (phones, fitbit, yada yada).

I’ll report back once I’ve done an assessment, but looks really promising!

1 Like

I remember paying with this at some point. It worked well, but it was really suited towards that particular solution that they had in mind… a Pi Zero in every room that would publish the discovered devices to the same topic. It was more like “one of the devices is near one of the computers” and it would get sorted out by the automation in Home Assistant.

The one thing that I never got around to solving was how to tie the MQTT bridge back to report to ST. In the old version of the app (called Presence instead of Monitor), someone had to modify the mqtt python script in the support folder to publish the “present” event back to the bridge, instead of the confidence level.

I got distracted by something else and never went back to it :slight_smile:

Yea, it looks like he has a better solution for scanning than I had.

What I might do at some point (since we don’t have any snow) is to work on a Node Red node to incorporate all the logic to make it easier to deploy.

ST presence sensing is not location-specific enough to do room-to-room. That said, I’ve found the weakness of the ST fob to be its size. Admirable attempt on their part to try to make it available on a keychain, but the reality is it just gobbles up batteries and the battery replacement process quickly breaks down the coin battery holder.

If you have the means to carry a small box that holds four AA batteries (such as in a briefcase or purse, or in the trunk of a car), you can use two AAs plus insert the circuit board of the fob into that box. My presence detection is perfectly reliable for more than four months at a time now.

But that all is beside the point. The point here is room-to-room presence. So back to the topic at hand!

Actually room-to-room presence is a different problem all together and probably belongs on a separate thread (please).

1 Like