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

Agreed - as soon as I saw it announced I knew it was going to be massively useful. All the framework and what might be seen as “rigidity” in HA was I am sure, hard graft to beat into shape over time. But then being able to layer a super-flexible user-driven thing like labels over the top of it really unlocks a lot of benefits.

Hi @doktormerlin, sorry I thought I had replied to your post earlier, but it seems not!

What you are experiencing seems fairly unusual, I’ve not seen that sort of behaviour before - at least that I can recall. There was one instance where someone found Bermuda no longer updated a device they had set up via Private BLE Device, and they worked out it was because they’d disabled the sensor for it, which caused private ble device to no longer update itself, so Bermuda couldn’t either.

The 9am pattern is very odd. Bermuda should still be trying to track devices even when they’re away. You mention it says they show up as “unavailable” but not “unknown”, while the history log shows them as “unknown” for long periods. Are they at the “unavailable” status for shorter periods not shown in that screenshot, or do the sensors show up differently in the log?

I think I’ll need a lot more data to work out what’s going on for you. Would you mind opening an issue on the github, and including the result of a “download diagnostics”? The diagnostics can be pretty slow to generate, but if you reload Bermuda first, wait a few minutes, then do the download it will finish a lot faster (it gets slowed down having to trawl through anonymising all the old mac addresses, which can take a while if the system’s been up for several days).

It’s possible that there’s an interaction if you have only Private BLE Devices and no manually-specified devices in Bermuda itself - it should still work fine but that’s the only thing I can think of off the top of my head that could potentially cause this sort of behaviour.

But if you can provide a diagnostics that will get us a long way to working out what’s going on.

Mayabe a stupid question, but why are my iphone very often go to unkown.
I would like to use it turn on somthing during the time my phone is in a room, if it leaves it should turn off.
But now when going to unknown the things i’m not in the room.

Is this a setting ?

Bermuda tries to stick to what it can “prove”. So if it gets a signal, it will make some assertions about that (device_tracker becomes Home, area sensors update). But in the absence of a signal, it’s impossible to “prove” if the device stopped transmitting, or if it’s now out of range of all proxies, such as when you take the phone to work etc.

Likewise if your phone stops transmitting, but then you take it to another room, it’s better (in my opinion) to be “unknown” than to remain at that last area. That at least lets you combine more sensors to build an accurate picture (eg, if watch is in bedroom or watch is unknown and phone is in bedroom…)

Based on that, I think it’s better that the area go to “unknown” rather than holding on to a value that may no longer be true.

That said, it is an opinionated choice on my part :slight_smile: and there is an open feature request for including a “Last seen area” sensor, which will be implemented. mogorman also shared their workaround using a template:

{% if state_attr('sensor.lina_area', 'area_name') == None or is_state_attr('sensor.lina_area', 'area_name', 'unknown') or is_state_attr('sensor.lina_area', 'area_name', 'unavailable')  -%}
{{ states('sensor.lina_filtered') }}
{%- else %}
{{ state_attr('sensor.lina_area', 'area_name')  }}
{%- endif %}

For things like lights, I’d suggest having area change being a trigger that starts a timer, rather than tying the off-state directly to the thing you are controlling. But it all depends on your use-case as to which method will be most suitable.

1 Like

doesn’t a device periodically send a package.

Sure they do.

  1. when was that timer in comparison to Bermudas internal refresh? (config screen for Bermuda)

I think my android companion was pinging every 30 seconds. When I set everything up I played around with max distance to report and how long to keep a device marked in. An area until most everything stabilized.

Ashley, I get why they’re asking for the last area sensor. I originally planned to do that myself what I found is instead keeping the device marked in area for about 2x or 3x as long (60s)as my longest reporting interval for BLE beacon (30 s) gave me a good debounce effect as long as the range was set wide enough. (basically don’t drop the area unless it misses two consecutive reports)

The problem is everyone starts not knowing those values and the default calibration in the config is probably a lot bit too tight so it’s flapping a lot.

How do you permanently remove a scanner that was previously a Bluetooth proxy but no longer is a Bluetooth proxy? I had an existing ESPHome device that I enabled the proxy function on but decided I didn’t want a proxy in that area and now it always shows with a skull and crossbones in the configuration. I’d like to remove it for good, but I haven’t been able to figure out how.

I have a Samsung Galaxy Active 5 Pro watch and it seems to struggle to ping the BLE beacons as it only seems to advertise with ultraLow power. Is it at all possible to set the power transmitting for it higher? I know you can do it with the phone, but I can’t work out how to make the watch perform better. :frowning:


the BLE receive wouldn’t be more than 1m away

I’m confused.
I don’t understand why you would use Private BLE Device integration if you only have Android phones.
From what I can gather Android phones don’t advertise themselves continuously. They do if they are put into pairing mode and are scanning but otherwise don’t advertise even if BT is turned on. Or am I wrong?
If I use the HA Companion App I can create an iBeacon with a fixed UUID-major-minor and can track that. I assume I could do the same with any iBeacon app but that defeats the object of using IRK doesn’t it?
If I am correct then I see no point in getting the IRK and using Private BLE Device integration for an Android phone. Can anyone enlighten me?

If you’re using the Home Assistant companion app on an Android Phone, I agree you don’t need the IRK or Private BLE device integration. I’m using Bermuda with just that configuration.

Thanks for your response, much appreciated.
But if you don’t have the HA Companion App or another iBeacon app on the android phone, will Private BLE Device integration using IRK work if bluetooth is on on the phone but not scanning/pairing? That’s my confusion - I don’t think it would but …

I believe you are correct. For example, Espresense, a competing tool to Bermuda, states that Android phones must install an app or the HA Companion App.

Beacons | ESPresense

Thanks for clarifying that. Saved me a lot of mucking about proving it myself.
Cheers

I don’t think you can. I accumulated four or five skull and crossbones. They don’t seem to do any harm, but I ended up re-installing the integration and starting again, they got so annoying. That worked.

I have a pretty good way of handling this, but it works best if you have more than one tracked device (I have three; phone, watch and a tag on my keys). Based on these I use the Bayesian integration to work out the probability of my being in each room, and the highest probability wins.

An advantage is that you can make use of other factors as well - movement, time of day, is the Xbox in use and so on. It started out as an amusing exercise but it turned out to be very accurate and quite responsive. Even with devices becoming “unknown” or flipping between rooms, or the phone being left on the kitchen counter when I go to bed, HA still seems to know (or guess) where I am.

It’s a bit creepy, actually. :thinking:

3 Likes

I was actually leaning into doing this you just convinced me it’s worthwhile

1 Like

I bought a handful of these for my house,

Is there a full example of the yaml config I should be putting on each device within esphome? I have them set to static ips, is that the right thing to do too?

I think I have all other aspects working. I have obtained my irk keys and the iPhone and watches detect which area I am in, but occasionally they go to unknown and I think it’s because I all missing some keys steps in the yaml of my Bluetooth proxies.

Thanks :pray:

I suggest reading the BLE Tracker setting part on ESPHome Configurations · agittins/bermuda Wiki · GitHub, maybe that will help :slightly_smiling_face:

Thanks! Yeah, I’ve had a read through all of the docs and I see where there are some suggestions for yaml config, but I am just not exactly sure where to put that and I don’t want to make a mistake. Here is what I currently have -

substitutions:
  name: esphome-web-70681c
  friendly_name: Sam Desk BLE

esphome:
  name: ${name}
  friendly_name: ${friendly_name}
  min_version: 2024.6.0
  name_add_mac_suffix: false
  project:
    name: esphome.web
    version: dev

esp32:
  board: esp32dev
  framework:
    type: arduino

# Enable logging
logger:

# Enable Home Assistant API
api:

# Allow Over-The-Air updates
ota:
- platform: esphome

# Allow provisioning Wi-Fi via serial
improv_serial:

wifi:
  ssid: *******
  password: *****

  # Optional manual IP
  manual_ip:
    static_ip: 192.168.**.**
    gateway: 192.168.0.1
    subnet: 255.255.255.0

# In combination with the `ap` this allows the user
# to provision wifi credentials to the device via WiFi AP.
captive_portal:

dashboard_import:
  package_import_url: github://esphome/example-configs/esphome-web/esp32.yaml@main
  import_full_config: true

# Sets up Bluetooth LE (Only on ESP32) to allow the user
# to provision wifi credentials to the device.
esp32_improv:
  authorizer: none

# To have a "next url" for improv serial
web_server:

bluetooth_proxy:

I am sure I am missing some things within my config, so thought I would check before I adopt my additional esp bluetooth proxies.