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

Share your Projects! Custom Integrations
264

So for the proxies, there are two things that might be referred to as their “Area”. There’s the Bermuda sensor, named “Area”, and that will be the one you are seeing bouncing around. For moving devices (watches etc) you use this sensor for automating against, as it gives you an idea of where it is being detected. But on a proxy, it serves no purpose and should not be being used by anything unless it’s doing something rather unusual.

The other “Area” is the actual area assigned to a device through the configuration in HA. This setting is not changed by Bermuda, but for proxies Bermuda uses this setting to understand what area each proxy is in.

So the area sensor is a bit of a nonsense for a proxy device, since it will change based on whichever other proxy thinks it is closest to. In that context, it’s a bug because it can cause confusion, and isn’t conveying anything useful. You shouldn’t be creating any automations against a proxy’s area sensor unless you are doing something interestingly unusual.

The device’s actual “Area” is static, defined by the user when configuring the device in HA.

I would suggest disabling the Area sensor on your proxies if it’s causing confusion, and making sure you only refer to the actual device area if creating automations - however most automations would only need to refer to the area sensor of bluetooth devices, not of the proxies.

A few screenshots might help clarify:

image
image631×617 29.1 KB

image
image631×761 44.5 KB

So essentially, you probably shouldn’t be using the proxy’s area sensor for anything.

As an aside, currently it’s only the Shelly’s that show up at all as a bermuda “device” at all, by default. This is because they are the only proxy that also sends out bluetooth advertisements, hence they’ll appear in bermuda’s “Select devices” drop-down. So the area sensor reflects their role as a “device” as opposed to their role as a “proxy”. This isn’t directly relevant to your issue, just pointing out some extra context. ESPHome proxies are getting this capability too, so they’ll behave similarly in future, and I’ll be adding some logic to make this a bit less confusing in future, but it’s not a “functionality bug”, just one of confusion, imo.

Does this answer your issue, or is there some follow-on affect that is being caused by this? If you are experiencing tracked devices bouncing between areas then note that this is not the cause of that - only correlation, rather than causation :slight_smile:

1 Like
265

Thanks for all this Ashley - I’ll take a look in detail at the settings when I can and learn to understand your terminology of “area” in more detail and how it works within the integration
Things have settled down a bit after removing a rogue ESP32 chip based device I last added some BT YAML too…
Trial and error with this sort of rollout… if things aren’t working as they should, always remove what you last added… :slightly_smiling_face:
Just for clarity…yes nomenclature is important.
I think of “Beacons” as something fixed… as in an Aeronautical beacon, a light house beacon - something broadcasting a signal (from a known and fixed) point
I think of “Sensors” as something that moves…(In this case my watch) that “senses” the signal coming from a beacon… (even though I know that is not exactly what is happening). I am well aware Bermuda trilateralises (for want of a better word) the location of the sensor because the sensor (itself) is broadcasting a uuid “signal”…
Actually when adding the specific uuid of a BT signal you want to “broadcast” (as you know) coming from an ESP32 chip installed via ESPHome… the YAML code you add via HA and ESPHome is called “Beacon” - in fact iBeacon is specified… That is how you “find” it (as you know) via the app and add it (as a fixed point) in an area
I think of “area” as something definitely fixed within home assistant nomenclature as a defined room in a house…(as you said)
Yes the terminology is confusing… that is for sure… even amongst native English speakers (albeit from different parts of the world) :grinning:

266

Update: It looks like a follow on effect of a rogue esp32 chip…

267

So like this then? ITs better?

substitutions:
  name: "Woonkamer Plug"
  friendly_name: Woonkamer - Plug ESP32
  relay_restore_mode: ALWAYS_OFF

packages:
  Athom_Technology.Smart_Plug_V3: github://athom-tech/esp32-configs/athom-smart-plug.yaml

esphome:
  name: ${name}
  name_add_mac_suffix: false
  friendly_name: ${friendly_name}

wifi:
  ssid: !secret wifi_ssid
  password: !secret wifi_password
  ap:
    ssid: "ESP32 Fallback Hotspot"
    password: !secret esp32_ap_password

esp32:
  framework: 
    type: esp-idf

text_sensor: !remove

time:
  - id: !remove sntp_time
  - id: homeassistant_time
    platform: homeassistant

bluetooth_proxy:
268

@agittins Ashley what is the point of assigning a Home assistant “Area” to an Applewatch BT signal (on an object that will move) by clicking that pointer top right?

As you move around the Apple watch changes its physical location as you move around wearing it on your wrist.

How is that location going to change in Home Assistant logic if you (the user) have assigned it a specific area?

Does this make sense?

I dont get why you would do this? (Assign an area for the Apple watch)

What I have done in automations is triggered them by using one of the attributes of the BT “area” sensor of the applewatch (I think this is what you describe as the “area set by Bermuda”) - first example above

The attribute Area name didn’t trigger the automation only the attribute Area ID did :

(lAttributes
Area ID
master_bedroom

Area name
Master Bedroom)

Ashley have I done the wrong thing?

269

I am triggering Automations using the sensor area of my Apple watch that is “set by Bermuda”
This sensor area switches to the correct room as the watch physically moves into a new room (which is trilateralised by fixed beacons)
How is it logical to do anything else?
It seems paramount to me that this sensor “area set by Bermuda” of the watch doesn’t wander…

1 Like
270

ok i need a little bit of help here :slight_smile: I’ve set up the esp32 blug.
I flashed it like above.
All is working and HA sees it.
I installed bermuda…
I also changed BLE transmitting on my phone and it says its transmitting
Back to bermuda
It says:
Bermuda can currently see 0 active of 42 bluetooth devices, reported across 0 active of 2 bluetooth scanner devices. No bluetooth devices are actively being reported from your scanners. You will need to solve this before Bermuda can be of much help.

When i click on devices , i get a list of devices, but i dont see my phone in there… i see a lot, but not the phone (nor the id).
Any ideas what i do wrong?

271

Your config didn’t have the esp32_ble_tracker section, nor the esp32-c3 settings that are recommended in the wiki. So this is probably why Bermuda says “0 active of 2 bluetooth scanner devices”, as the last flash stopped bluetooth proxy from working.

I’ve created a generic “package” for esp32-c3 to make this a lot easier, can you try this and see how that goes? I changed the name since you had capitals and spaces. This config should be everything you need to flash the athom plug with bermuda-compatible bluetooth as well:

substitutions:
  name: woonkamer-plug
  friendly_name: Woonkamer - Plug ESP32
  relay_restore_mode: ALWAYS_OFF

packages:
  Athom_Technology.Smart_Plug_V3: github://athom-tech/esp32-configs/athom-smart-plug.yaml
  Bermuda.c3: github://agittins/bermuda-proxies/packages/bermuda-proxy-c3.yaml

esphome:
  name: ${name}
  name_add_mac_suffix: false
  friendly_name: ${friendly_name}

wifi:
  ssid: !secret wifi_ssid
  password: !secret wifi_password
  ap:
    ssid: "ESP32 Fallback Hotspot"
    password: !secret esp32_ap_password

text_sensor: !remove

time:
  - id: !remove sntp_time
  - id: homeassistant_time
    platform: homeassistant
272

You don’t assign an area to the watch, you do it to each BT Proxy so Bermuda knows which room you are in based on the area assigned to the BT Proxy that is closest.

An example automation trigger I have is:

  - platform: state
    entity_id:
      - sensor.daves_phone_bermuda_tracker_area
    to: Bedroom
273

^ lol now I’m totally confused!
What’s illogical about my way?!
Nobody said I was allocating a HA “area” to the watch! I haven’t done that.
It’s been pretty stable for 2-3 weeks and real quick and responsive
Like I say as long as the area Bermuda “gives” the watch doesn’t “wander”
It hadn’t been wandering (with 2-3 beacons in each room)
It only started doing it when I added a “rogue one”
Anyway
That’s why I asked for a blueprint!

SJ

274

In any case can’t the “wandering” issue be sorted in an update?

275

IMG_4892
IMG_4892750×1334 89.4 KB

IMG_4893
IMG_4893750×1334 89 KB

IMG_4894
IMG_4894750×1334 94.3 KB

This trigger and logic has been working great for me.

IMG_4896
IMG_4896750×1334 106 KB

276

The watch / the watch signal… same same.

The point is, you assign the BT Proxy an area so Bermuda can say the watch is in that area whilst it is closest to that particular BT Proxy.

Anyway, you seem to have it working. I just wanted to clarify.

277

Hi
Oh
I used the yaml from @EdwardTFN
If im wright, he said it was all i need…

Thx for the new yaml, i will test it…

Edit: does it still function as BT proxy then?
Cause i see u taken that out?

278

That’s part of one of the packages

Bermuda.c3: github://agittins/bermuda-proxies/packages/bermuda-proxy-c3.yaml

Look at the yaml config: bermuda-proxies/packages/bermuda-proxy-c3.yaml at cb1012cb9e2220f8b3570f482494b5fd15f63bad · agittins/bermuda-proxies · GitHub

2 Likes
279

OK flashed the device.
Inside the integration I can’t see my phone. Although HA app is transmitting BT signal, I can’t see the right device.
I don’t see UUID of it.
I do see one ibeacon but not sure what it is.
How do I know which one is correct. I do see shelly device and other numbers I don’t know

280

^ skank I haven’t been following your problem in detail.
Some general Bermuda set up comments :
If it’s an iphone, Apple changes the broadcast uuid multiple times a day. This is for privacy reasons and to stop yr phone being hacked. There are ways around this. Search is yr friend
Specific YAML code concerning the uuid broadcast from an esp32 chip can be written onto the esp32 chip. You generate a unique uuid then copy that into the code. Search beacon bluetooth home assistant for details. Or read this. ESP32 Bluetooth Low Energy Beacon — ESPHome
Once you know what that unique code is, it’s very easy to find it in the Bermuda integration configuration. Bermuda>Configure>Select devices

281

@agittins Concerning your above quote : “There’s the Bermuda sensor, named “Area”, and that will be the one you are seeing bouncing around”. Ok. This is the sensor I am tracking on the watch and using for automations. There is way less “bouncing around” the more fixed “Beacons” I add. Ideally with a combination of Shelly, ESP32 chips and the BT signal from Hue smart globes (all of which are easy to find and add in the configuration, don;t change their uuid and remain in fixed positions…that’s why I call them “Beacons!”) - I will have 3-4 fixed “Beacons” close to corners of a room and the “bouncing around” becomes way way less of a problem. But I have a question. Future Bermuda firmware upgrade. Are you planning some way of reducing this “bouncing” from occurring? Or is this simply impossible due to constraints with the entire “concept” of Bermuda?

282

The bluetooth_proxy component already loads the esp32_ble_tracker (which is the one required by Bermuda), so you can add just the tracker if you are not gonna use the proxy and that will save a bit of memory.
If you wanna both, you can add both or you can just add only the proxy, as it will include that anyways.

1 Like
283

That code propose by @agittins includes the bluetooth_proxy component, so you will be good with that just like on the example provided.
That option have an advantage of managing the BLE to not start until the Wi-Fi is connected, which is a good approach for this device.

1 Like