Bermuda - Bluetooth/BLE Room Presence and tracking [custom integration]

Yeah it’s a good question. For things like BTHome it (can be) built-in and automatic, but lots of devices will not advertise their battery level, but instead you need to connect to it and query the battery status. I think there’s a standard (GATT?) service for that, so I think it should be possible for an integration to offer that for any known / desired device supporting the spec-compliant way of doing it, but I don’t know of one. I think it is usually left up to the individual integration that supports a given device to handle this. That’s fine for a weather station or door sensor where you want some other integration to support features, but for beacons there’s not much other than Bermuda or some other passive listener that you would normally need.

I might be gradually talking myself into something here, so I’d better shut up. :rofl:

So… as it stands, I don’t know of any “generic” way of getting BLE battery stats into HA other than via device-specific integrations.

If you want, feel free to jump into NRFConnect on your phone, “connect” to the device and see what services etc it offers. If you pop some screenshots in here I’m happy to look at what it’s doing/offering and have a bit of think about what options there might be.

Thanks for the reply.

I don’t know what I’m doing :upside_down_face:, but I cracked the RAW code looking for different data between the 2 devices and found the information below:

0x0201061AFF4C000215FDA50693A4E24FB1AFCFC6EB0764782
6271
B4CB9C90D095
550000000000000000000001016425241 
63 > For Decimal number: 99 Battery percentage?
C69387039397
0406060000
0x0201061AFF4C000215FDA50693A4E24FB1AFCFC6EB0764782
5271
B4CB9C90D095
0756E746F000000000000001016425241
60 > For Decimal number: 96 Battery percentage?
D109546D93D1
0406060000

I’m going to turn on the third device and check if the data above really refers to the battery.

If I looked in the right place in NRFConnect, I didn’t find anything that could be useful.

EDIT:
It’s definitely the battery status.
Now I need to find a way to recover the information.

0x0201061AFF4C000215FDA50693A4E24FB1AFCFC6EB0764783
0271
B4CB9C90D094
86F6C792D494F54000000001016425241
64  > For Decimal number: 100% 
D0CE83E9650E
0406060000

Edit 2:

I got it with the help of this link:

Ex:

bluetooth_proxy:
  active: True

esp32_ble_tracker:
  scan_parameters:
    interval: 320ms
    window: 300ms 
  on_ble_service_data_advertise:
    - mac_address: D0:CE:83:E9:65:0E
      service_uuid: "5242"
      then:
        - lambda: 'id(ble_sensor).publish_state(x[1]);'

sensor:
  - platform: template
    name: "Holy-IOT"
    id: ble_sensor
    device_class: "battery"
    unit_of_measurement: "%"
    entity_category: "diagnostic"
    accuracy_decimals: 0

binary_sensor:
  - platform: ble_presence
    mac_address: D0:CE:83:E9:65:0E
    name: "Holy-IOT"
    timeout: 60s

Result:

At the moment I am having to use a “double trigger” to fire a room entry automation.

When “X presence sensor” is triggered and/if confirm “Apple BT watch BT is in area Y” then trigger automation.

This ensures no false triggers (due to BT device wandering between rooms without me!) and only me (rather than the dog or wife etc) fires the automation

Without this double test, I get false triggers as the sensor/device wanders between scanner devices drifting/wandering from room to room (when I am not actually in it). So what is the best way to improve this? Will just calibration fix it? Or is it going to be simply more effective to add two BT fixed scanner proxies in the one room?

Thanks!

1 Like

Yeah, that’s a bit tricky. It depends on the layout of your rooms etc. For my office I use PIR and Bermuda - either will trigger the lights or extend the run-time. So anyone who walks in gets light, but also means when I am sitting still for hours on end(!) Bermuda makes sure the lights stay on.

For your case, I’d say that calibration would not be likely to fix it, unless the proxy in your room is particularly more sensitive than the other receivers. What might work better is having more proxies elsewhere - the more proxies you are close to that are not that room, the less likely you are to get false positives on that room.

That said, I do have two proxies in my office, but the other places I tend to spend much time in puts me closer to two other proxies than the office ones.

You could add some distance restrictions on the automation, so it only triggered when you are actually pretty close, but this will reduce the responsiveness, most likely.

1 Like

I’ve got iPhones and Apple watches already integrated using Private BLE. I fired this up and wanted to say this is one of the most useful custom components I’ve seen in a long time. Entities got auto-added and just work, and are snappy as hell. Thanks for this!

My only problem is I don’t have a BT proxy in every room, so being in the kitchen registers as being in the living room (there’s just no proxy in that room).

Now I’m off to buy a couple more GL-S10s and ESP32s to get coverage in every room :grimacing:.

4 Likes

Yep it’s a fantastic integration! Agree. Ive got Apple watch and iphone up running as well (same way) :grinning:

2 Likes

hey. just found out about this integration. For those who have several of these esphome proxies installed around the home, do you see device jumping to different rooms even though the device has been stationary in one particular room the whole time?

I do, yes, but I imagine that it’s mostly due to poor config on my part. I need to spend some time fine-tuning, I suspect.

I have six or seven proxies around my house and I jump around a little bit. As I start building out automation I just plan to condition them with “has the device been in that area for at least X seconds.”

1 Like

That is a good idea. Please post your code when you have accomplish this if you don’t mind.

1 Like

Yes. The developer has given an answer why that is and how to go about solving it. 1/ Calibrate will help a bit - but not “solve it”. 2/ Adding more proxies will help (decreasing the distance between them all). Don’t underestimate Shelly. If you already have some BT capable Shellys (the more recent hardware) they can be very easily added as BT nodes (proxies) in there own right. This is really really cool, because they are always invariably powered. And very easy to integrate as BT proxies with very little config. They are also seen easily (labelled Shelly) in the Bermuda BT “available” list when adding nodes. In the meantime (while I wait to get more BT proxy hardware to reduce this problem) I am trying automations that fire with 2 triggers. So both conditions have to me met 1/ general presence detected by another (non Bermuda) device and 2/ BT sensor device (iphone/watch/tage etc) present in the room. That way the automation won’t fire if it is jumping around different rooms…

Bluetooth Proxy — ESPHome In the ESPHome BT Proxy manual, it states HA “only supports up to 3 active ESP connections”. My questions are 1/ Do Shelly devices that are set up as BT proxies count as “active devices” in this limit of 3? 2/ Do Shellys set up like this use the esp-idf or Arduino framework? 3/ How many Shelly devices could be set up as BT proxies (for the purpose of providing fixed Bermuda sensors) without getting into resource problems? 4/ Would adding separate (non Shelly) ESP32 boards (like say an M5Stack BT node) get around this issue? Thanks!

HA doesn’t have a hard limit on active connections, the docs says that the esp32 can provide a max of 3 to HA. So that’s 3 active connections, per esphome proxy. I can see how the wording isn’t exactly clear on that, but it’s very much ESPHome’s max, not HA’s:

The Bluetooth proxy of ESPHome provides Home Assistant with a maximum number of 3 simultaneous active connections.

Shelly devices (as at the last time I looked) provide 0 (zero) active connections. That is, they don’t offer full connection proxying, they only proxy advertisements.

From Bermuda’s perspective, this doesn’t matter at all, because Bermuda does not use any active proxy connections.

The “active connections” being referred to are for where HA needs to actually connect to a device in order to communicate with it. In esphome this is a feature turned on or off with the active parameter of the bluetooth_proxy: section.

This is NOT the same thing as the active parameter of the esp32_ble_tracker section, which controls whether the proxy attempts to find out the names of devices that don’t include their names in the initial advertisement. This feature is the same functionality that is controlled with the active feature of Shelly’s bluetooth proxy integration.

It’s unfortunate that they’ve chosen “active” as the term for both cases, as it’s quite confusing.

Anyway, no need to be concerned with respect to Bermuda, since we are “passively” listening for adverts.

I’m not sure, but they are not using ESPHome (although you can flash esphome on most shellys). The actual advert proxying is implemented in the scripting language their firmware supports.

A few dozen, easily. A few hundred, probably. A thousand… I’d expect to encounter difficulties. :slight_smile:

The only downside of Shelly’s for Bermuda, as far as I know, is that the Shelly firmware doesn’t re-send adverts if it has seen the same one in the last 3 seconds. So you might find that things are a bit less responsive with Shelly than they are with ESPHome. This might change in future firmware updates, I don’t know. I am also fairly sure that the listening window/interval on the Shelly’s is the same as ESPHome’s defaults, but we can easily change the esphome defaults to get a higher percentage of “listening time”. ESPHome Configurations · agittins/bermuda Wiki · GitHub

2 Likes

Nice one! Thanks for the time putting together to explain things and that awesome reply! I will now get a few more Shellys and a couple of ESP32 BT proxies to tighten up my “triangulation”. :+1:

1 Like

To figure out “has the sensor been on in the same room for 2 minutes” this is the template to use:

{{ (is_state('sensor.iphone_private_ble_device_area', 'Office')) and 
(now() > states.sensor.iphone_private_ble_device_area.last_changed + timedelta(minutes=2)) }}
4 Likes

hi Ashley couple more questions.

1/ Double story houses. Triangulation can also work up/down so how do you separate a room above another one? Can you somehow implement the HA concept of "floors’?
2/ Maps of houses. Will there be a day when each BT beacon/sensor/device can be accurately portrayed on a map that is easy to implement in our home assistant projects?

Thanks!

Bermuda will use HA floors when it can support floors. It’s a work in progress, but also an extension beyond initial trilateration. I’d like to support it from the outset, but it’s important to understand that the Z axis is always going to be less reliable than X and Y. Much like with GPS the altitude measurement is far less accurate.

If six proxies (say) achieved good accuracy on one floor, simplistically you could say you’d need thirty-six to give good accuracy over two floors. In fact it’s not quite that bad because we don’t need a full altitude reading, just a decision on which floor, but it will still be a non-trivial problem to solve (I’ve plenty of ideas, but ideas are not much use until we have something to try them out on).

So, it’s definitely on my mind, but I would caution against too much optimism for how reliable it will be.

  • Accurately? Never. Rssi is just not capable of accuracy, for most definitions of accurate. But best-effort, yes.
  • Ability to plot on a map? Definitely. Possibly on a 3d model, if anyone wanted to take up that goal.
  • Easy to implement? Hopefully. Ideally built-in.

The way I have broken it down in my head is to achieve:

  • basic trilateration, resulting in X, Y, and hopefully Z co-ordinate estimates for each device. The co-ordinate space for those values will probably be scaled and translated to some real-world measurements (such as the measured distances between a set of proxies or devices).
  • an image entity in Bermuda that plots those co-ordinates onto a canvas - hopefully a transparent svg, so that it can be layered on top of a user-created map. Possibly one per “floor” but hard to say until we get closer to that. This probably isn’t a terribly useful thing, but it sure would be sexy, and serves as a visual confirmation that things are working, and offers inspiration for ideas from there.
  • some way to define areas with a bounding box of co-ordinates, so that given the x/y/z co-ordinates from above, we can derive what “room”/area a beacon is in. This is the big step from our current simplistic “a device is in the area belonging to its closest proxy” to “we estimate this device is within this physically-bounded space”.

ESPresence has a tool which does the third point already, and some interesting ideas have already been brought up in that area.

But of course, these are all just ideas and intentions, and that’s the easy part. The real effort is in the implementation, and the reality is that we might hit the wall of what’s possible using rssi at any point. Probably better that I spend time working on it rather than talking about it! :smiley:

2 Likes

^ I knew you’d be onto it!!. Happy to help trial along that journey. I share the vision :grinning:

Hey dude… Hue LED bulbs (with inbuilt bluetooth) work great as “beacons” (fixed devices). They show up as “hue color lamp” in Bermuda select device discovery. This is awesome!

2 Likes

Something which I’m not sure has been raised before or not:

If I restart HA and thus Bermuda whilst away from the house then none of my tracker entities ever become available even once I return home. Basically I have to restart the integration whilst all tracked devices are available in the house. Is there anything that can be done to prevent that?