Bluetooth Beacon Signal Strength Detection?

Has anyone had any success using BLE beacons to estimate range from their Openhab server? I’m looking to solve the age-old problem of detecting when the bins are in or out.

I’ve tried a couple of cheap “key finder” tags, and they all seem to suffer the same way. They appear in the inbox, I can add them, they get a few updates but then stop updating - anecdotally, the problem seems to get worse if you try to use two beacons at once. I can use the same beacons with the (cheesy) phone app quite successfully.

I’ve tried hcitool lescan and I can see my tags in that list from time to time (that can’t apparently tell me the RSSI/signal strength though). As I say, the BT binding seems to find the tags (eventually) too, although sometimes they have their product name (eg. IFind_C02F) and sometimes they’re called things K…(something)…BroadcomCorp. I can on occasion even get a few different range measurements from them, but one way or another, they always seem to stop working shortly afterwards. Is there a way to log BLE beacons or something that might help me debug this?

My other problem is that when a beacon stops sending useful information, Openhab seems to invent data points for it. That is, an “analyse” graph will show data points for every minute with the same value (eg. -86dbm). It seems that at the very least it should stop adding data points, or else change them to NaN or something. Am I just doing something wrong here? - it seems like a pretty basic problem.

Lastly, there seems to be a lot to read about the Bluetooth binding, and to a lesser extent BLE beacons. Most of it’s pretty old though, so I’m wondering what’s the state of things now we’re in 2023? Am I just trying to do something that’ll never work with OpenHab, and should I look to alternatives instead? I see a lot of people doing various levels of scripting, which I’m not adverse to if I have to.

If it matters, I’m using Openhab 3.3.0, on a Raspberry Pi4 (running Openhabian).

Espresence. With esp32s. That’s what I’m going with.
Let me get you a couple of links to get you sorted…

@Pedro_Liberal
I also trying to use Espresense but it seems not accurate enough for me to trigger event.

Situation:
At initial, my iphone or watch close the ESP32 around 0.2m. Then walk away it to 1m just in 1 second.
But the response show that the distance still keep in 0.2m, 0.2xm, 0.2xm, 0.3m…1m (it takes around 8-20s to adjust it and finally it get the correct distance)

Observation:

  1. The rssi(-32) > rssi@1m(-65) (e.g ) when my device near the ESP around 0.2m
  2. The rssi(-65) ~= rssi@1m(-65) (e.g ) when my device move away from the ESP around 1m (change it significantly )
  3. The raw(0.9~1.9) when my device near the ESP around 1m (change it significantly but unstable)

Conclusion/ Question/ Problem:
rssi or raw can reflect the latest status of my device (although I don’t know what is “raw”, i think it likely similar to distance but it is unstable). And It is strange that why “distance” can not reflect the current status and it needs time to change it slowly (0.2 → 0.2x, 0.3 → 0.3x → …-> 1). Suppose the formula of distance is base on rssi.

do you have such problem or anything I need to config it?

10:19:52
{"id":"irk:____","disc":"071897c6e5","idType":200,"rssi@1m":-65,"rssi":-34,"raw":0.13,"distance":0.15,"speed":-0.00,"mac":"430e33182fc7","interval":492}
{"id":"irk:____","disc":"071897c6e5","idType":200,"rssi@1m":-65,"rssi":-41,"raw":0.21,"distance":0.15,"speed":0.00,"mac":"430e33182fc7","interval":491}
{"id":"irk:____","disc":"071897c6e5","idType":200,"rssi@1m":-65,"rssi":-52,"raw":0.43,"distance":0.15,"speed":0.01,"mac":"430e33182fc7","interval":491}
10:19:54
{"id":"irk:____","disc":"071897c6e5","idType":200,"rssi@1m":-65,"rssi":-72,"raw":1.58,"distance":0.16,"speed":0.06,"mac":"430e33182fc7","interval":491}
{"id":"irk:____","disc":"071897c6e5","idType":200,"rssi@1m":-65,"rssi":-72,"raw":1.58,"distance":0.20,"speed":0.09,"mac":"430e33182fc7","interval":491}
{"id":"irk:____","disc":"071897c6e5","idType":200,"rssi@1m":-65,"rssi":-69,"raw":1.30,"distance":0.26,"speed":0.06,"mac":"430e33182fc7","interval":489}
{"id":"irk:____","disc":"071897c6e5","idType":200,"rssi@1m":-65,"rssi":-70,"raw":1.39,"distance":0.28,"speed":0.06,"mac":"430e33182fc7","interval":492}
{"id":"irk:____","disc":"071897c6e5","idType":200,"rssi@1m":-65,"rssi":-66,"raw":1.07,"distance":0.36,"speed":0.06,"mac":"430e33182fc7","interval":490}
{"id":"irk:____","disc":"071897c6e5","idType":200,"rssi@1m":-65,"rssi":-64,"raw":0.94,"distance":0.37,"speed":0.04,"mac":"430e33182fc7","interval":491}
{"id":"irk:____","disc":"071897c6e5","idType":200,"rssi@1m":-65,"rssi":-64,"raw":0.94,"distance":0.37,"speed":0.04,"mac":"430e33182fc7","interval":491}
{"id":"irk:____","disc":"071897c6e5","idType":200,"rssi@1m":-65,"rssi":-63,"raw":0.88,"distance":0.40,"speed":0.03,"mac":"430e33182fc7","interval":493}
{"id":"irk:____","disc":"071897c6e5","idType":200,"rssi@1m":-65,"rssi":-66,"raw":1.07,"distance":0.52,"speed":0.04,"mac":"430e33182fc7","interval":492}
{"id":"irk:____","disc":"071897c6e5","idType":200,"rssi@1m":-65,"rssi":-68,"raw":1.22,"distance":0.53,"speed":0.04,"mac":"430e33182fc7","interval":492}
{"id":"irk:____","disc":"071897c6e5","idType":200,"rssi@1m":-65,"rssi":-78,"raw":2.35,"distance":0.61,"speed":0.07,"mac":"430e33182fc7","interval":494}
{"id":"irk:____","disc":"071897c6e5","idType":200,"rssi@1m":-65,"rssi":-74,"raw":1.81,"distance":0.70,"speed":0.09,"mac":"430e33182fc7","interval":497}
{"id":"irk:____","disc":"071897c6e5","idType":200,"rssi@1m":-65,"rssi":-74,"raw":1.81,"distance":0.81,"speed":0.06,"mac":"430e33182fc7","interval":495}
{"id":"irk:____","disc":"071897c6e5","idType":200,"rssi@1m":-65,"rssi":-69,"raw":1.30,"distance":0.85,"speed":0.03,"mac":"430e33182fc7","interval":496}
{"id":"irk:____","disc":"071897c6e5","idType":200,"rssi@1m":-65,"rssi":-69,"raw":1.30,"distance":0.90,"speed":0.02,"mac":"430e33182fc7","interval":498}
10:20:13
{"id":"irk:____","disc":"071897c6e5","idType":200,"rssi@1m":-65,"rssi":-75,"raw":1.93,"distance":1.00,"speed":0.05,"mac":"430e33182fc7","interval":496}

I did wonder about using an ESP to do this, and the MQTT linkage looks pretty easy. Thanks for the links, I’ll check it out, but I think I’d rather something on the OpenHab server if I can (just to save a device, and the wifi setup, etc).

As for accuracy, what I can see so far is that the tags broadcast and the server listens and measures the signal strength. From that, you can estimate distance (calibrated to a particular tag type). The broadcast message also includes battery level, which you’d also need to use, as if the battery is very low, it’ll likely affect signal strength. The cheesy app the tags come with can “connect” to the tags, and then can do two-way comms with them to get them to do more frequent broadcasts (and so you can make the tag beep or whatever). With more frequent broadcasts, you can smooth out inaccuracies a bit better if you need to “zero in” on a tag.

My use case is to see if the bins are out on collection day (or not!), so I don’t suppose I need the two-way comms. I haven’t checked, but I hope that connecting to the tag means no one else can connect to it, which would be useful to avoid anyone else connecting and making the tags beep, or just use up all their battery or whatever.

For now though, I’ll check out the ESP links you provided, but also a python library which looks like it could be the basis of a server app: GitHub - IanHarvey/bluepy: Python interface to Bluetooth LE on Linux. I’m still very much open to any OpenHab-native ideas though - it seems like it’s close to what’s required, but I’m not quite there yet (and I think solving the phantom data points thing would be useful in all cases).

Humm… then… why not a simple door sensor? From what you’re describing, the bins don’t wander around right? Either they are outside or not. So maybe stick a door sensor on the bin, and a magnetic :magnet: pad on the ground, in such a way that when the bins are on top of it, the sensor is “closed”.
Take them out, sensor is “open” - thus bins are outside.

Simple, no?

the bins don’t wander around right?

You’d be surprised :wink:

I’ve looked at a few other options, and honestly, they’re either messy or prone to problems (like if the bin isn’t exactly over its sensor). I guess if the sensor was a large pad that wouldn’t be a problem, but then it won’t meet with Wife Acceptance Factor (even putting a small sensor into the surface of the top of the driveway isn’t ideal).

I looked at NFC and some magnetic options, and also at an ultrasonic option, but as I say, a relatively small mis-positioning of the bin and it starts to misread its location. Simple is/was very attractive, but it doesn’t seem to cope well with the realities of our bin usage. Much googling later, and using beacon tags seemed like a possible solution that looked like it could be simple - it turns out OpenHab doesn’t make it simple though.

Thanks all for your help with this. Much digging later, and I’ve found…

  • The BLE chip in a Raspberry Pi 4 isn’t terrible, but it’s not brilliant either. A £10 external USB dongle does at least as well - and has the advantage that you can move it about (which can help a lot)
  • Using bluepy (or equivalent tools), doing an “active” scan seems to return very few broadcasts. Doing a “passive” scan returns all of them (if you’re in range). Even with 4 tags and whatever other devices are around (quite a few around here, it seems), you seem to be able to receive every broadcast
  • BLE specs have a max spacing between broadcasts of 10.1 seconds, so you ought to be receiving lots of broadcasts from any device. My particular ones seem to send about 1 per second
  • Openhab’s binding doesn’t seem to get many broadcasts - I suspect it may be doing an active scan, and there doesn’t seem to be a way to change that. This makes it unsuitable for this kind of work :frowning:
  • Scripting isn’t hard, but obviously requires something external to Openhab. The start of my solution is here: GitHub - coofercat/ble2mqtt: Bluetooth BLE Beacons to MQTT if anyone wants something similar (it puts messages onto MQTT, which Openhab can consume pretty easily)

Lastly, the cheap “key finder” tags I’ve got work pretty well, but even when sat next to each other on the desk, they all have different signal strengths. I guess cheap ones don’t get calibrated, or even made all that well. Their signal strength seems to vary with temperature, prevailing weather and other factors. I’ve yet to read battery level from them, which I think, when combined with signal strength should give a reasonable reliable “range” indicator (as battery is also temperature sensitive).

All in all though, the basics of what’s required here are now working - not quite as elegantly as I’d have liked, but by no means too hacky either :slight_smile: