Love this solution, much better than anything else I've tried.

I don't seem to be able to delete the entities for previous proxies even if the proxy device itself has been removed.

The "Distance to XXX" and "Unfiltered Distance to XXX" entities can only be hidden for each device. Is there a way to actually remove legacy proxy entities?

This is the primary goal of this integration, but the first milestones to hit are:

• Sensors to state the Area of a device, based on the Area of the closest bluetooth receiver
• Implement the device_tracker_ble functionality of providing home|not_home state for Person entities.
• UI for configuring device selections and options

The milestones for this feature are:

• Improve filtering of distance estimates for accuracy and stability. Currently thinking Extended Kalman Filters with FilterPy? I wonder if Wouter is looking for projects :) (current filtering seems reasonably stable while also responsive. I don't think Kalman is well-suited to the noise distribution, so this is "good enough" for now).
• Using beacon-receiver distances, "solve" all receiver-receiver distances using Triangle Inequality
• Using those solved "edges", estimate solutions for a 2D plane with all devices
• UI/Config Flow:
  • Allow user to choose an "origin" beacon and a vector beacon to place the solution in a constrained space.
  • Allow entry of 1-metre rssi calibration offsets for both receivers and devices.
• Create new sensors to provide location data (also lat/long?)

Extension goals:

• Solve for 3D space (some peeps have multiple floors, and as of HA 2024.4 floors are now a "thing")
• Smarter solutions.

Hi, first of all thanks for the great integration! Fantastic for all of us scatterbrained people 😄 I noticed a bug that logs a lot of errors but seems to have otherwise no negative influence on the integration. At least for me it is working nonetheless 😄

Version of the custom_component

v0.6.3

Configuration

{ "entry_id": "c1d71095933bfefc238d9e214b54354c", "version": 1, "minor_version": 1, "domain": "bermuda", "title": "Bermuda BLE Trilateration", "data": { "source": "user", "scanners": { "d4:d4:da:XX:XX:XX": { "name": "Soil Sensor Living Room", "local_name": null, "prefname": null, "address": "d4:d4:da:XX:XX:XX", "options": { "max_area_radius": 4.0, "smoothing_samples": 20, "max_velocity": 3.0, "devtracker_nothome_timeout": 30, "attenuation": 4.0, "ref_power": -60.0, "configured_devices": [ "C9E2A754C371431AB0E67D0E3B518C3E_100_40004" ] }, "unique_id": "d4:d4:da:XX:XX:XX", "mac_is_random": false, "area_id": "living_room", "area_name": "Living Room", "area_distance": null, "area_rssi": null, "area_scanner": null, "zone": "unavailable", "manufacturer": null, "connectable": false, "is_scanner": true, "beacon_type": "not a beacon", "beacon_sources": [], "beacon_unique_id": null, "beacon_uuid": null, "beacon_major": null, "beacon_minor": null, "beacon_power": null, "entry_id": "7777deea1f987874b1d954473cd14d76", "create_sensor": false, "create_sensor_done": false, "create_tracker_done": false, "last_seen": 0, "scanners": {} }, "d4:d4:da:XX:XX:XX": { "name": "Motion Sensor Floor", "local_name": null, "prefname": null, "address": "d4:d4:da:XX:XX:XX", "options": { "max_area_radius": 4.0, "smoothing_samples": 20, "max_velocity": 3.0, "devtracker_nothome_timeout": 30, "attenuation": 4.0, "ref_power": -60.0, "configured_devices": [ "C9E2A754C371431AB0E67D0E3B518C3E_100_40004" ] }, "unique_id": "d4:d4:da:XX:XX:XX", "mac_is_random": false, "area_id": "floor", "area_name": "Floor", "area_distance": null, "area_rssi": null, "area_scanner": null, "zone": "unavailable", "manufacturer": null, "connectable": false, "is_scanner": true, "beacon_type": "not a beacon", "beacon_sources": [], "beacon_unique_id": null, "beacon_uuid": null, "beacon_major": null, "beacon_minor": null, "beacon_power": null, "entry_id": "d106528ad5b57b5a8550bf88e8f798c3", "create_sensor": false, "create_sensor_done": false, "create_tracker_done": false, "last_seen": 0, "scanners": {} }, "d4:d4:da:XX:XX:XX": { "name": "Soil Sensor Dining Area", "local_name": null, "prefname": null, "address": "d4:d4:da:XX:XX:XX", "options": { "max_area_radius": 4.0, "smoothing_samples": 20, "max_velocity": 3.0, "devtracker_nothome_timeout": 30, "attenuation": 4.0, "ref_power": -60.0, "configured_devices": [ "C9E2A754C371431AB0E67D0E3B518C3E_100_40004" ] }, "unique_id": "d4:d4:da:XX:XX:XX", "mac_is_random": false, "area_id": "dining_area", "area_name": "Dining Area", "area_distance": null, "area_rssi": null, "area_scanner": null, "zone": "unavailable", "manufacturer": null, "connectable": false, "is_scanner": true, "beacon_type": "not a beacon", "beacon_sources": [], "beacon_unique_id": null, "beacon_uuid": null, "beacon_major": null, "beacon_minor": null, "beacon_power": null, "entry_id": "7d10c8c909b4505e962d84ff4463b6ed", "create_sensor": false, "create_sensor_done": false, "create_tracker_done": false, "last_seen": 0, "scanners": {} }, "d4:d4:da:XX:XX:XX": { "name": "Motion Sensor Kitchen", "local_name": null, "prefname": null, "address": "d4:d4:da:XX:XX:XX", "options": { "max_area_radius": 4.0, "smoothing_samples": 20, "max_velocity": 3.0, "devtracker_nothome_timeout": 30, "attenuation": 4.0, "ref_power": -60.0, "configured_devices": [ "C9E2A754C371431AB0E67D0E3B518C3E_100_40004" ] }, "unique_id": "d4:d4:da:XX:XX:XX", "mac_is_random": false, "area_id": "kitchen", "area_name": "Kitchen", "area_distance": null, "area_rssi": null, "area_scanner": null, "zone": "unavailable", "manufacturer": null, "connectable": false, "is_scanner": true, "beacon_type": "not a beacon", "beacon_sources": [], "beacon_unique_id": null, "beacon_uuid": null, "beacon_major": null, "beacon_minor": null, "beacon_power": null, "entry_id": "b888edcee67442db6ef1266d929b38fc", "create_sensor": false, "create_sensor_done": false, "create_tracker_done": false, "last_seen": 0, "scanners": {} }, "d4:d4:da:XX:XX:XX": { "name": "Motion Sensor Storage Room", "local_name": null, "prefname": null, "address": "d4:d4:da:XX:XX:XX", "options": { "max_area_radius": 4.0, "smoothing_samples": 20, "max_velocity": 3.0, "devtracker_nothome_timeout": 30, "attenuation": 4.0, "ref_power": -60.0, "configured_devices": [ "C9E2A754C371431AB0E67D0E3B518C3E_100_40004" ] }, "unique_id": "d4:d4:da:XX:XX:XX", "mac_is_random": false, "area_id": "storage_room", "area_name": "Storage Room", "area_distance": null, "area_rssi": null, "area_scanner": null, "zone": "unavailable", "manufacturer": null, "connectable": false, "is_scanner": true, "beacon_type": "not a beacon", "beacon_sources": [], "beacon_unique_id": null, "beacon_uuid": null, "beacon_major": null, "beacon_minor": null, "beacon_power": null, "entry_id": "79f345abb3b207ae246a9999e0adc469", "create_sensor": false, "create_sensor_done": false, "create_tracker_done": false, "last_seen": 0, "scanners": {} }, "08:d1:f9:XX:XX:XX": { "name": "Light Sensor Bedroom", "local_name": null, "prefname": null, "address": "08:d1:f9:XX:XX:XX", "options": { "max_area_radius": 4.0, "smoothing_samples": 20, "max_velocity": 3.0, "devtracker_nothome_timeout": 30, "attenuation": 4.0, "ref_power": -60.0, "configured_devices": [ "C9E2A754C371431AB0E67D0E3B518C3E_100_40004" ] }, "unique_id": "08:d1:f9:XX:XX:XX", "mac_is_random": false, "area_id": "bed_room", "area_name": "Bedroom", "area_distance": null, "area_rssi": null, "area_scanner": null, "zone": "unavailable", "manufacturer": null, "connectable": false, "is_scanner": true, "beacon_type": "not a beacon", "beacon_sources": [], "beacon_unique_id": null, "beacon_uuid": null, "beacon_major": null, "beacon_minor": null, "beacon_power": null, "entry_id": "b07076d5fb15b5817eaaef463191ea20", "create_sensor": false, "create_sensor_done": false, "create_tracker_done": false, "last_seen": 0, "scanners": {} } } }, "options": { "max_area_radius": 4.0, "devtracker_nothome_timeout": 30, "attenuation": 4.0, "ref_power": -80.0, "configured_devices": [ "C9E2A754C371431AB0E67D0E3B518C3E_100_40004" ], "max_velocity": 3.0, "update_interval": 10.0, "smoothing_samples": 20 }, "pref_disable_new_entities": false, "pref_disable_polling": false, "source": "bluetooth", "unique_id": "bermuda", "disabled_by": null }

Describe the bug

The Integration logs thousands of errors in short time. The error is a comparison error in:

Debug log

Version of the custom_component

v0.6.5

Describe the bug

I'm seeing errors in the logs that I believe are related to a BLE proxy that I removed from Home Assistant, but apparently Bermuda is still looking for it? If I am correct, I'm unsure how to remove it. I can't find any related devices/entities in HA.

Debug log

This error originated from a custom integration.

Logger: custom_components.bermuda
Source: custom_components/bermuda/init.py:169
integration: Bermuda BLE Trilateration (documentation, issues)
First occurred: 6:25:48 PM (390 occurrences)
Last logged: 8:51:04 PM

Failed to find config for scanner b84a63eaf58f89218e88c58c06b3dafd, this is probably a bug. (40680 previous messages suppressed)
Failed to find config for scanner b84a63eaf58f89218e88c58c06b3dafd, this is probably a bug. (41276 previous messages suppressed)
Failed to find config for scanner b84a63eaf58f89218e88c58c06b3dafd, this is probably a bug. (40742 previous messages suppressed)
Failed to find config for scanner b84a63eaf58f89218e88c58c06b3dafd, this is probably a bug. (41172 previous messages suppressed)
Failed to find config for scanner b84a63eaf58f89218e88c58c06b3dafd, this is probably a bug. (8038 previous messages suppressed)

Version of the custom_component

0.6.1

Describe the bug

After upgrading, the PrivateBLE devices are picked up beautifully. Nice job on finding this method to bring in IRK devices.

However, once the PrivateBLE entities are picked up, all the PrivateBLE entities seem to belong to Bermuda and there is no way to enter the PrivateBLE device (clicking on an entity inside PrivateBLE takes you to the Bermuda device). This may not be such an issue as all entities seem configurable except for:

• Renaming the device renames all Bermuda and PrivateBLE entities
• There are now two device_tracker entities named exactly the same, just the ID of the Bermuda one has _2 on the end. This is confusing for writing automations, etc.

I think ideal would be for the entities to remain in their own integrations if this would work. If not easy, then maybe just adding the word "Bermuda" to the name and ID of the newly created entities. As it is it seems they all get created with the name and id of the PrivateBLE device.

I also have a suggestion to mitigate the jumping between rooms we see in the screenshot. I'll add that to #134.

Version of the custom_component

0.4.3

Configuration

N/A

Describe the bug

I have two ESPHome Bluetooth proxies when I test. The last one added keep on loosing the area after a restart of HA and then the integration gets upset and logs errors about missing area
At first I suspected it was the ESPHome integration.
But then I uninstalled the Bermuda integration (because of the flooding of logs and unstable performance I raised in previous bug report today, and the problem went away. I have restarted HA at least 10 times and no loss of area for the new BT proxy.

Are you sure this integration does not accidently write to the field for area where it should read? Like a = instead of == type of bug? (I am not a Python programmer but in other languages this is a classic mistake).

I should try to install the integration again to verify the issue comes back but it is too late and I wanted to raise this before others loose their area assignments

Debug log

Nothing in the HA log that indicates the area is lost because of an error.

Is your feature request related to a problem? Please describe.
When I restart HA when the trash bins are already out, they do not show as away, but as 'unavailable'

Describe the solution you'd like
If there is no signal from the tracker for some time, I'd like it to show as 'away' (or at least have the option to do that)

Describe alternatives you've considered
Alternatively, I would treat 'Unavailable' as away in my automations.

Additional context

Logs show:

This error originated from a custom integration.

Logger: custom_components.bermuda
Source: custom_components/bermuda/__init__.py:314
Integration: Bermuda BLE Triangulation (documentation, issues)
First occurred: 25 August 2023 at 19:58:13 (1967 occurrences)
Last logged: 01:26:08

Unexpected error fetching bermuda data: 'XX:XX:XX:XX:XX:XX'
Traceback (most recent call last):
  File "/usr/src/homeassistant/homeassistant/helpers/update_coordinator.py", line 283, in _async_refresh
    self.data = await self._async_update_data()
                ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/config/custom_components/bermuda/__init__.py", line 314, in _async_update_data
    self.devices[discovered.scanner.source].area_id,
    ~~~~~~~~~~~~^^^^^^^^^^^^^^^^^^^^^^^^^^^
KeyError: 'XX:XX:XX:XX:XX:XX'

Where XX:XX:XX:XX:XX:XX is the MAC address of the USB bluetooth adaptor installed in the system.

Version of the custom_component

All versions up to v0.2.1 inclusive.

Describe the bug

Faulty logic in _refresh_scanners fails to find bluetooth usb adaptors.

First big thanks for the integration, I just googled for ideas how to solve my problem with a deaf dog I have...he was hit by a motorbike few weeks ago because he ran on the street and the gateway was open beacuse my kids didn't close the gates...anyways long story short I was looking for triangulation (trilateration) for a beacon on my dog's collar. Thumbs up!

I have 1 question:
When setting up integration the windows for username / password poped up... what is this? Where can I get the credentials?
Thanks!

Version of the custom_component

0.3.1 (note this is 0.0.0 in the const.py file and should be set correctly?)

Describe the bug

The sensors created for distance are missing state_class and unit_of_measurement properties and so they are shown as text rather than graphed.

These properties seem to be missing in the distance sensors:

      state_class: measurement
      unit_of_measurement: m

Debug log

2023-10-30 19:02:14.641 DEBUG (MainThread) [custom_components.bermuda] Finished fetching bermuda data in 0.035 seconds (success: True)
2023-10-30 19:02:19.632 DEBUG (MainThread) [custom_components.bermuda] Finished fetching bermuda data in 0.026 seconds (success: True)
2023-10-30 19:02:24.631 DEBUG (MainThread) [custom_components.bermuda] Finished fetching bermuda data in 0.025 seconds (success: True)
2023-10-30 19:02:29.633 DEBUG (MainThread) [custom_components.bermuda] Finished fetching bermuda data in 0.027 seconds (success: True)
2023-10-30 19:02:34.631 DEBUG (MainThread) [custom_components.bermuda] Finished fetching bermuda data in 0.026 seconds (success: True)
2023-10-30 19:02:39.639 DEBUG (MainThread) [custom_components.bermuda] Finished fetching bermuda data in 0.033 seconds (success: True)
2023-10-30 19:02:44.631 DEBUG (MainThread) [custom_components.bermuda] Finished fetching bermuda data in 0.025 seconds (success: True)
2023-10-30 19:02:48.594 ERROR (MainThread) [homeassistant.config_entries] Error unloading entry Bermuda BLE Trilateration for sensor
Traceback (most recent call last):
  File "/usr/src/homeassistant/homeassistant/config_entries.py", line 565, in async_unload
    result = await component.async_unload_entry(hass, self)
             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/src/homeassistant/homeassistant/components/sensor/__init__.py", line 132, in async_unload_entry
    return await component.async_unload_entry(entry)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/src/homeassistant/homeassistant/helpers/entity_component.py", line 202, in async_unload_entry
    raise ValueError("Config entry was never loaded!")
ValueError: Config entry was never loaded!
2023-10-30 19:02:48.685 DEBUG (MainThread) [custom_components.bermuda] Device None now in Garage
2023-10-30 19:02:48.686 DEBUG (MainThread) [custom_components.bermuda] Device bhyve_2619B3 now in Bedroom - Master
2023-10-30 19:02:48.687 DEBUG (MainThread) [custom_components.bermuda] Finished fetching bermuda data in 0.038 seconds (success: True)
2023-10-30 19:02:48.767 DEBUG (MainThread) [custom_components.bermuda] Device None now in Garage
2023-10-30 19:02:48.768 DEBUG (MainThread) [custom_components.bermuda] Device bhyve_2619B3 now in Bedroom - Master
2023-10-30 19:02:48.768 DEBUG (MainThread) [custom_components.bermuda] Finished fetching bermuda data in 0.032 seconds (success: True)
2023-10-30 19:02:48.779 ERROR (MainThread) [homeassistant.config_entries] Error setting up entry Bermuda BLE Trilateration for sensor
Traceback (most recent call last):
  File "/usr/src/homeassistant/homeassistant/config_entries.py", line 399, in async_setup
    result = await component.async_setup_entry(hass, self)
             ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/src/homeassistant/homeassistant/components/sensor/__init__.py", line 126, in async_setup_entry
    return await component.async_setup_entry(entry)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/src/homeassistant/homeassistant/helpers/entity_component.py", line 187, in async_setup_entry
    raise ValueError("Config entry has already been setup!")
ValueError: Config entry has already been setup!
2023-10-30 19:02:48.844 DEBUG (MainThread) [custom_components.bermuda] Finished fetching bermuda data in 0.034 seconds (success: True)
2023-10-30 19:02:53.347 ERROR (MainThread) [frontend.js.latest.202310050] Uncaught error from Chrome 118.0.0.0 on Mac OS 10.15.7
TypeError: Cannot read properties of undefined (reading 'id')
_keyFunction (src/components/data-table/ha-data-table.ts:362:56)
keyFunction (src/virtualize.ts:116:41)
r (src/directives/repeat.ts:56:28)
ct (src/directives/repeat.ts:93:52)
update (src/directive.ts:134:16)
_$AS (src/lit-html.ts:1085:23)
S (src/lit-html.ts:1362:12)
_$AI (src/async-directive.ts:366:18)
setValue (src/virtualize.ts:139:13)
dispatchEvent (src/Virtualizer.ts:802:23)
2023-10-30 19:02:53.550 DEBUG (MainThread) [custom_components.bermuda] Finished fetching bermuda data in 0.030 seconds (success: True)
2023-10-30 19:02:58.547 DEBUG (MainThread) [custom_components.bermuda] Finished fetching bermuda data in 0.026 seconds (success: True)
2023-10-30 19:03:03.543 DEBUG (MainThread) [custom_components.bermuda] Device None now in Garage
2023-10-30 19:03:03.544 DEBUG (MainThread) [custom_components.bermuda] Finished fetching bermuda data in 0.025 seconds (success: True)
2023-10-30 19:03:08.546 DEBUG (MainThread) [custom_components.bermuda] Finished fetching bermuda data in 0.026 seconds (success: True)

So I just thought, I have a lidarr area mapping device right here that I can also stick an ibeacon on top off. Would a dataset with robot vacuum coordinates (incl areas) combined with Bermuda data be useful?

It may provide a way to map proxies to coordinates on the map instead of just tying proxies to areas.

Learn pytest.

Make it work.

Get the Actions passing, then start increasing test coverage.

Is your feature request related to a problem? Please describe.
My headphones generate a random mac address every boot. making them difficult to track.
Describe the solution you'd like
The mac address changes every time, but the name is always the same. so i would like to be able to track by name like we can track by uuid.

Describe alternatives you've considered
I could make an automation that handles this, but it would be gross

Raised in particular consideration of Shelly's that might be dropping out or not reporting adverts for upwards of 30 seconds.

DEVTRACKER_TIMEOUT only applies to device_tracker entities, and since departure on those is typically less latency-sensitive, a simple timeout up to or beyond 180 seconds is typically adequate for dealing with advert gaps (and especially since we can get a perfectly valid Home indication from any proxy).

However, the simplistic Area detection is using the filtered rssi_distance, which currently uses the hard-coded default DISTANCE_TIMEOUT of 30 seconds to persist a "valid" measurement for 30 seconds after a proxy stops reporting that device.

Smoothing/filtering is still done over that time, so if the last report happened to be more distant than the one before, the smoothed value will approach that latest reading over the 30 seconds.

This works ok-ish when a proxy gets a weak advert as the device leaves the area, but can make the area "too sticky" if the device leaves quickly enough that the proxy doesn't hear any distant adverts - the stale "close" reading prevents another proxy from winning the device until it gets closer to that proxy than it was to the old one, at least for the next 30 seconds.

For users with misbehaving proxies that go offline for long periods, it would be helpful to be able to increase DISTANCE_TIMEOUT to compensate for longer reporting delays, although the core issue is probably with the proxy or its backhaul (wifi).

Revisit the logic, as it adds more latency than it should (when proxies are behaving well), but shortening it will make proxy drop-outs more annoying.

Perhaps have it assume the device left at peak velocity, and assume increasing distances on that basis, which might still give time for a slow/delayed/rebooting proxy to reclaim the device before it switches, but will also allow other proxies to "win" sooner if they are starting to see closer readings.

The above only applies to the simplistic area matching we do currently, for trilateration we should be able to weight the reading with decreasing confidence as the reading ages. I think.

Hey. Great project!

This is just a small bug report. Bermuda told me in logs to assign area for one of my proxies. I did that, and it clearly works as I can see that devices are marked with that area. But on every reload of integration, I still see the log about missing area for my proxy:

Area assigned to the device:

Log:

I restarted HA, reload Bermuda several times, but I still see the message about missing area in the logs.

Totally different thing, this sentence with scissors reads funny:

I mean, sure, scissors can naturally increase humans walking speed twice as much - maybe my English comprehension is just bad though 😄 !

Jaymunro noted:
I have found the new code restores updates on the area and distance sensors when the device returns home, even after a HA restart. However if there is a restart, the device_tracker also goes unavailable but does not recover when the device returns home. A Bermuda reload is required while the device is home.

Originally posted by @jaymunro in #99 (comment)

I think to replicate:

• out-of-range (unplug) a device that is being tracked
• restart HA
• note state of device_tracker entity
• power-up / in-range device
• note state of device_tracker entity does not update
• after reload of Bermuda, device_tracker resumes updating.

Work out why. Fix it.

Version of the custom_component

v0.6.4

Configuration

Describe the bug

After upgrading to v0.6.4, making ANY changes on the configuration page of Bermuda results in a full HA frontend crash. Once this happens, I can only access the HA instance via SSH and must issue a reboot command before normal functionality is restored. This is repeatable. I have reinstalled the integration with no change. I have not yet downgraded to v0.6.3, but that will be my next step to see if the issue persists.

Debug log

I'm uncertain on the best way to grab logs here. Once the issue occurs, I don't seem to be able to get any logs, and they're gone after the SSH reboot. Happy to provide them if you have any instruction or suggestions.

Is your feature request related to a problem? Please describe.
I want to know if at least a single device is in an area.

Describe the solution you'd like
Per-Area occupancy sensor (true/false), optionally with a list of devices currently in that area and a "cooldown time".

Describe alternatives you've considered
It would probably be possible to do this with automations and helpers "by hand", but that is no elegant solution.

Not too sure if this is still in scope for bermuda though.

(from a discussion I was having with myself while writing a comment)

Create per-proxy distance sensors for each beacon so that I can easily use the history tool to visualise what's happening with the data, including missing packets. The current distance and area sensors are good, but their data makes it clear that:

• missing packets are causing spurious area switches
• noisy data makes it hard to choose between nearby areas that are open plan (line-of-sight)
• having multiple proxies in one area really helps with both issues (graph showing (effectively) area-of-nearest-proxy and distance-to-nearest-proxy over time for my watch):
  

Currently the distance sensor is showing the distance from the currently "winning" proxy, which makes analysis difficult. By adding a sensor per-proxy I'll be able to see the fuller picture (with the aid of HA's wonderful history graphing) and get visual feedback on improvements with distance filtering. While the raw data is available from the service it's more difficult to visualise.

TL/DR:

• Allow certain proxies (or local bluetooth adaptors) to be excluded from Bermuda's calculations
• Provide per-receiver calibration via a ref_power_offset setting to account for varying receiver sensitivity
• Provide per-device ref_power setting to allow overriding the default ref_power value.

This will allow us to account for varying beacon and receiver sensitivities caused by radio design, antenna and enclosure variations, while still allowing use of defaults for easier basic setup.

Original description:

Currently all devices use the global ref_power setting, and device names only come from local_name advertisement data, which seems unreliable but is also limiting for users, especially when doing initial setup.

Effective ref_power is a function of these variables

• device transmitter power (as well as "reported" device tx power)
• device antenna design, placement and enclosure
• receiver sensitivity
• receiver antenna design, placement and enclosure

It makes sense to be able to specify a ref power @1m value for each transmitter (device), and also an offset value for each receiver (or receiver type).

Devices:

• Allow the user to specify a name for the device (helpful if local_name isn't known, and save renaming sensors later) (no, just let them rename in the UI. Naming seems stable now).
• Global ref_power should be set to match one's most common transmitter/beacon.
• Each device can optionally have a custom ref-power defined.
• Unsure if better to define per-device setting as an offset from global ref_power or as an absolute. The latter might be less confusing.

Scanners:

• Will eventually need a setting for co-ords anyway
• A ref_power_offset makes more sense for scanners, since one is likely to have multiple identical scanners, but a wide range of devices. Also an absolute value wouldn't make sense as it's a function of the combination of tx/rx pair.
• max_radius as a per-area setting makes sense, so you don't need to enter an adjacent area in order to no longer be in "this" area.

Version of the custom_component

0.6.6

Configuration

no changes / default config

Describe the bug

When adding a device Bermuda hangs in a loop trying to add the area and distance sensors and the device tracker. HA 2024.6.0b6 (yes, beta) reports that the ID is not unique. Bermuda does not stop trying to add the sensors and the device tracker. HA can not be restarted from within HA anymore.

Debug log

2024-06-04 00:20:06.381 ERROR (MainThread) [homeassistant.components.sensor] Platform bermuda does not generate unique IDs. ID 7c:2f:80:b9:6b:d1 already exists - ignoring sensor.bermuda_7c_2f_80_b9_6b_d1_area
2024-06-04 00:20:06.382 ERROR (MainThread) [homeassistant.components.sensor] Platform bermuda does not generate unique IDs. ID 7c:2f:80:b9:6b:d1_range already exists - ignoring sensor.bermuda_7c_2f_80_b9_6b_d1_distance
2024-06-04 00:20:06.386 ERROR (MainThread) [homeassistant.components.device_tracker] Platform bermuda does not generate unique IDs. ID 7c:2f:80:b9:6b:d1 already exists - ignoring device_tracker.bermuda_7c_2f_80_b9_6b_d1_bermuda_tracker
2024-06-04 00:20:06.420 ERROR (MainThread) [homeassistant.components.sensor] Platform bermuda does not generate unique IDs. ID 7c:2f:80:b9:6b:d1 already exists - ignoring sensor.bermuda_7c_2f_80_b9_6b_d1_area
2024-06-04 00:20:06.421 ERROR (MainThread) [homeassistant.components.sensor] Platform bermuda does not generate unique IDs. ID 7c:2f:80:b9:6b:d1_range already exists - ignoring sensor.bermuda_7c_2f_80_b9_6b_d1_distance
2024-06-04 00:20:06.427 ERROR (MainThread) [homeassistant.components.device_tracker] Platform bermuda does not generate unique IDs. ID 7c:2f:80:b9:6b:d1 already exists - ignoring device_tracker.bermuda_7c_2f_80_b9_6b_d1_bermuda_tracker
2024-06-04 00:20:06.460 ERROR (MainThread) [homeassistant.components.sensor] Platform bermuda does not generate unique IDs. ID 7c:2f:80:b9:6b:d1 already exists - ignoring sensor.bermuda_7c_2f_80_b9_6b_d1_area
2024-06-04 00:20:06.461 ERROR (MainThread) [homeassistant.components.sensor] Platform bermuda does not generate unique IDs. ID 7c:2f:80:b9:6b:d1_range already exists - ignoring sensor.bermuda_7c_2f_80_b9_6b_d1_distance
2024-06-04 00:20:06.468 ERROR (MainThread) [homeassistant.components.device_tracker] Platform bermuda does not generate unique IDs. ID 7c:2f:80:b9:6b:d1 already exists - ignoring device_tracker.bermuda_7c_2f_80_b9_6b_d1_bermuda_tracker
2024-06-04 00:20:06.502 ERROR (MainThread) [homeassistant.components.sensor] Platform bermuda does not generate unique IDs. ID 7c:2f:80:b9:6b:d1 already exists - ignoring sensor.bermuda_7c_2f_80_b9_6b_d1_area
2024-06-04 00:20:06.502 ERROR (MainThread) [homeassistant.components.sensor] Platform bermuda does not generate unique IDs. ID 7c:2f:80:b9:6b:d1_range already exists - ignoring sensor.bermuda_7c_2f_80_b9_6b_d1_distance

Version of the custom_component

0.6.5 (and tried main)

Describe the bug

Directly after I set up the integration, Home Assistant experienced significant performance drops. I restarted, but the restart was no longer possible (the core did not start anymore) and I had to force shutdown the machine.
Unfortunately, I don't have any logs because of this.
After removing the integration, everything ran normally again with the usual performance.

I have 8 BT proxies (ESP) and 1 BT adapter (ASUS). None of them are assigned to areas.

Is this a known issue or has anyone had similar experiences?

Describe the solution you'd like
I'd like a "last seen" sensor for each tracked device. This sensor would have the last contacted proxy and a timestamp. This would be useful in a "find my device" approach to get an idea of where the item was last known to be and when.

Describe alternatives you've considered
I could create this with a triggered template sensor for each tracked device, but it would be nicer if this was an available entity from the integration so it would show up on the device pages and could be enabled/disabled for each device as desired.

A continuation of the fruitful chat with @jaymunro in #99 which lead up to the v0.5.0 release today.

I've been finding the elimination of peaks to be pretty promising thus far.

v0.5.1

Describe the bug

Reported by Adizanni at https://community.home-assistant.io/t/bermuda-bluetooth-ble-room-presence-and-tracking-custom-integration/625780/59?u=agittins

Another question, how to refresh the name and or area assignement when a scanner is moved to another area ?

It looks like the area_name and area_id are being persisted in CONFDATA_SCANNERS and the mechanism that's meant to freshen it isn't working.

Reload and [re]Configure both failed to apply a change in scanner area.

Hi,
I am still determining if this is an issue or by design since the Installation instructions are clear and work.
However, as on the top of the page, the big blue buttons (OPEN HACS REPOSITORY) you see twice don't work without adding the custom repo manually; I would personally add that step as part of the pullet points under What you need for simplicity and clarity.

Thanks for the work!

Version of the custom_component

0.0.0 as in const.py
0.3.1 in HACS

Configuration

Add your logs here.

Describe the bug

Integration will not load. Has the errors:

Setup failed for custom integration 'bermuda': Unable to import component: cannot import name 'monotonic_time_coarse' from 'homeassistant.util.dt' (/usr/src/homeassistant/homeassistant/util/dt.py)

and

Error occurred loading flow for integration bermuda: cannot import name 'monotonic_time_coarse' from 'homeassistant.util.dt' (/usr/src/homeassistant/homeassistant/util/dt.py)

This seems to have been caused by the PR: Remove monotonic_time_coarse datetime helper released with 2024.1

Debug log

Setup failed for custom integration 'bermuda': Unable to import component: cannot import name 'monotonic_time_coarse' from 'homeassistant.util.dt' (/usr/src/homeassistant/homeassistant/util/dt.py)
Traceback (most recent call last):
  File "/usr/src/homeassistant/homeassistant/setup.py", line 251, in _async_setup_component
    component = integration.get_component()
                ^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/src/homeassistant/homeassistant/loader.py", line 822, in get_component
    ComponentProtocol, importlib.import_module(self.pkg_path)
                       ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/usr/local/lib/python3.11/importlib/__init__.py", line 126, in import_module
    return _bootstrap._gcd_import(name[level:], package, level)
           ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "<frozen importlib._bootstrap>", line 1204, in _gcd_import
  File "<frozen importlib._bootstrap>", line 1176, in _find_and_load
  File "<frozen importlib._bootstrap>", line 1147, in _find_and_load_unlocked
  File "<frozen importlib._bootstrap>", line 690, in _load_unlocked
  File "<frozen importlib._bootstrap_external>", line 940, in exec_module
  File "<frozen importlib._bootstrap>", line 241, in _call_with_frames_removed
  File "/config/custom_components/bermuda/__init__.py", line 37, in <module>
    from homeassistant.util.dt import monotonic_time_coarse
ImportError: cannot import name 'monotonic_time_coarse' from 'homeassistant.util.dt' (/usr/src/homeassistant/homeassistant/util/dt.py)

From https://community.home-assistant.io/t/bermuda-bluetooth-ble-room-presence-and-tracking-custom-integration/625780/135?u=agittins

iBeacon entries in the select device drop-down doesn't include the (current) MAC address of the beacon. This means searching by MAC address (visually or by typing part of it to filter) makes it hard/impossible to find the correct device.

Add the (current) MAC address to (the end of?) the iBeacon option so that it can be found visually and by typed filter.

Version of the custom_component

v0.6.6 and earlier

Version of the custom_component

0.3.1

Describe the bug

The device_tracker sensor is absent in the UI and also does not get renamed like the other two when the device is renamed.

The related device_tracker.bermuda_dc_2c_6e_12_fa_df entity is not present in the registry however it does get listed in Developer tools > STATES

From https://community.home-assistant.io/t/bermuda-bluetooth-ble-room-presence-and-tracking-custom-integration/625780/62?u=agittins

Scott8586 Scott Presnell
I’m using the current version, 0.5.1, and I’m seeing a constant stream of this in my log file (e.g. more than one a second):

2024-03-20 20:22:56.040 WARNING (MainThread) [custom_components.bermuda] Using freshest advert but it's still too old!

Any hints on debugging this further?

Suspect we're copying the wrong source device's data to metadevice, and should be checking for a "fresher" one (or the last_seen stamp is being updated from somewhere else).

initial response

Thanks Scott, I think it might be a logic error on my part - this will happen for iBeacons where Bermuda has chosen the "wrong" source address to copy some metadata from, or if the iBeacon's timestamp is somehow updated from some other source. All of this is internal to Bermuda though, so not a configuration issue on your end.

Any given iBeacon might have multiple MAC addresses advertising it, typically because devices randomise their MACs for privacy, so there should be a single "current" source mac. It looks like Bermuda is choosing an "older" source mac, so the timestamps on that device's advertisements are older than the "last-seen" stamp on the beacon.

The other possibility is that I'm updating the timestamp on the beacon's record from somewhere other than the most recent source device.

Do you have a local bluetooth device attached to your HA machine? If you have bluetooth proxy devices, are they esphome or Shelly Plus units?

I should have a chance in the next 24 hours or so to take a proper look at this, and will hopefully have a release to fix it soon.

It would seem possible to create virtual areas to represent rooms without ESPHome base stations. Observed distances from each base station would localize to a point in the center of the virtual area. A radius or range of distances would define the room.

Is this a planned or available feature?

Person = n
Base station = A, B, C, D, E
Distance = d
dAn = distance between base station (A) and person (n)
dAn1 = distance between base station (A) and person (n) in the desired room, closest to base station (A)
dAn2 = distance between base station (A) and person (n) in the desired room, furthest from the base station (A)
Virtual location = (dAn, dBn, dCn, dDn)
Virtual Area/Room = (dAn1 < dAn <dAn2, dBn1 < dBn < dBn2, dCn1 < dCn < dCn2, dDn1 < dDn < dDn2)

Task to track getting Bermuda into the HACS default repo

• Project structure and manifest
• Use releases
• Ensure HACS action runs OK
• Ensure Hassfest action runs OK
• Get tests working - see #22
• Have logo and icon accepted into HA Brands repo - see home-assistant/brands#4772
• PR#2443 Pending hacs/default#2443

For Bluetooth presence detection, I'm looking into using a few shelly plugs with Bluetooth and Bermuda to do device triangulation. My catch however is that I can't use Bluetooth from Home Assistant directly due to the way I'm running it. However, with the scripting on the Shelly plugs I can do the detection and send the information over MQTT to HA instead of Bluetooth.

The device detection and shipping it to MQTT works. What is currently missing however is in which format to send it to MQTT. Unless I'm blind, which wouldn't be the first time, there isn't information in the wiki on the data format expected. Can someone point me in the direction to that?

Version of the custom_component

Latest as of writing

Configuration

I was hoping my bluetooth mac UUID would show up here, but it dosen't.

Describe the bug

I'm having trouble making my esp32 to pickup my phone, i have HA companion on the phone (android) and setup a BLE sender with with a unique ID/UUID and all that.
Phone: xiaomi T11

This is the esp chip i'm using and the esphome config of it, shortened down a bit:

Chip is ESP32-D0WDQ6 (revision v1.0)
Features: WiFi, BT, Dual Core, 240MHz, VRef calibration in efuse, Coding Scheme None


--------------------------------------------
esphome:
  name: esphome-web-aadec8
  friendly_name: esphome-web-aadec8

esp32:
  board: esp32dev
  framework:
    type: esp-idf
    version: recommended

# Enable logging
logger:
  level: VERY_VERBOSE
  logs:
    esp32_ble: VERY_VERBOSE

#captive_portal:

# Define a simple HTML page to display the number of cores
# web_server:
#   port: 80
bluetooth_proxy:
  active: true

I've also tried the config with "framework arduino" with the same result.

I get a lot of bluetooth trafic / mac addresses in the debug log but not the mac address from my phone and no UUID from HA companion either.

I also installed ibeacon and same thing. would not work.

I'm not sure how/if i can get IRK (resolvable keys) to test that and see if that help, please advise.

small sample of the esp32 log:

[12:32:35][VV][esp32_ble_tracker:423]: Parse Result:
[12:32:35][VV][esp32_ble_tracker:440]:   Address: 08:3A:F2:7B:79:D2 (PUBLIC)
[12:32:35][VV][esp32_ble_tracker:442]:   RSSI: -85
[12:32:35][VV][esp32_ble_tracker:443]:   Name: ''
[12:32:35][VV][esp32_ble_tracker:451]:   Ad Flag: 6
[12:32:35][VV][esp32_ble_tracker:457]:   Manufacturer data: 01.05.00.0B.05.20.0A.D0.79.7B.F2.3A.08 (13)
[12:32:35][VV][esp32_ble_tracker:473]: Adv data: 02.01.06.10.FF.A9.0B.01.05.00.0B.05.20.0A.D0.79.7B.F2.3A.08 (20)
[12:32:35][VV][esp32_ble_tracker:423]: Parse Result:
[12:32:35][VV][esp32_ble_tracker:440]:   Address: 08:3A:F2:7B:79:D2 (PUBLIC)
[12:32:35][VV][esp32_ble_tracker:442]:   RSSI: -86
[12:32:35][VV][esp32_ble_tracker:443]:   Name: 'ShellyPro4PM-083AF27B79D0'
[12:32:35][VV][esp32_ble_tracker:451]:   Ad Flag: 6
[12:32:35][VV][esp32_ble_tracker:457]:   Manufacturer data: 01.05.00.0B.05.20.0A.D0.79.7B.F2.3A.08 (13)
[12:32:35][VV][esp32_ble_tracker:473]: Adv data: 02.01.06.10.FF.A9.0B.01.05.00.0B.05.20.0A.D0.79.7B.F2.3A.08.1A.09.53.68.65.6C.6C.79.50.72.6F.34.50.4D.2D.30.38.33.41.46.32.37.42.37.39.44.30 (47)
[12:32:35][W][component:232]: Component esp32_ble_tracker took a long time for an operation (66 ms).
[12:32:35][W][component:233]: Components should block for at most 30 ms.
[12:32:36][V][esp32_ble:314]: (BLE) gap_event_handler - 3
[12:32:36][VV][esp32_ble_tracker:423]: Parse Result:
[12:32:36][VV][esp32_ble_tracker:440]:   Address: 7A:9A:CA:D4:09:AF (RANDOM)
[12:32:36][VV][esp32_ble_tracker:442]:   RSSI: -70
[12:32:36][VV][esp32_ble_tracker:443]:   Name: ''
[12:32:36][VV][esp32_ble_tracker:454]:   Service UUID: 0xFE9F
[12:32:36][VV][esp32_ble_tracker:457]:   Manufacturer data: 13.8C.CA.7C.01.E5 (6)
[12:32:36][VV][esp32_ble_tracker:468]:   Service data:
[12:32:36][VV][esp32_ble_tracker:469]:     UUID: 0xFE9F
[12:32:36][VV][esp32_ble_tracker:470]:     Data: 00.00.00.00.00.00.00.00.00.00.00.00.00.00.00.00.00.00.00.00 (20)
[12:32:36][VV][esp32_ble_tracker:473]: Adv data: 03.03.9F.FE.17.16.9F.FE.00.00.00.00.00.00.00.00.00.00.00.00.00.00.00.00.00.00.00.00.09.FF.E0.00.13.8C.CA.7C.01.E5 (38)
[12:32:37][V][esp32_ble:314]: (BLE) gap_event_handler - 3

Running #5b25fdc I have just started encountering an issue where my Infinitime watch no longers updates the Area or Distance sensors configured for it.

My current theory is that the way I try to keep the device named using the local_name is causing an issue, possibly due to infinitime only sometimes sending the name (I think it does so when active scanning is on, ie the host sends a scan info request).

I'm back to waving my arms around to trigger the PIR because Bermuda isn't triggering the lights any more :-)

I've avoided the template since this is a question, rather than a bug report: this is probably me needing a direction and/or documentation, rather than something needing fixing in Bermuda itself.

I'm currently trying to configure a new device under https://my-home-assistant/config/integrations/integration/bermuda, and the entry mask that has the placeholder="List of Bluetooth devices to specifically create tracking entities for." is only allowing selection of MAC addresses that it has already "seen".

I'm wondering if:

• it is possible to enter MAC address that HA Bluetooth has not yet seen (effectively skipping the UI validation)
• I'm doing something wrong while trying to get HA to see some of my devices

Further context

• I'm trying to pair my Pixel 5 phone, and I understand that phones are tricky / fiddly due to potential MAC randomization.
• I have a very noisy environment due to many Philips Hue devices using BLE themselves

My the phone is not being picked up by passive scanning: it is pairable from my main work computer, so I managed to extract its BT MAC address via bluetoothctl paired-devices there.

I was wondering if I could just take that MAC address and ask Bermuda to create a device from it, or if that's nonsensical because Bermuda must first have seen the device, for some reason.

Just deployed yesterday and It is working great!
Just one challenge:
I have four ESP32 proxys around my house, plus the Pi4 Bluetooth radio. The issue that I am facing is that the Pi4 captures most of the activity from the BLE devices nearby.

For example, while my smart watch is 1-2 meters from the Kitchen ESP32, the Pi4 (8-10 meters away) picks up a stronger signal and provides a false location.

It would be helpful to be to select which radios to utilize.

Thank you

Native IRK support via Private BLE Device will come later, I think I will split this issue to a new one to track IRK support.

Originally posted by @agittins in #44 (comment)

• I need to flash an esp32 with the key-grabbing tool so I can register the iOS devices floating around here.

Is your feature request related to a problem? Please describe.
The thing I am tracking (my cat) often shows as in my living room, despite being closer to another BLE Proxy. I believe this is because the USB Bluetooth adapter in my living room reports very different distance/rssi/velocity data to the BLE Proxies around my house.

Describe the solution you'd like
I have BLE proxies scattered throughout my house, including in the same room as the HA server with USB Bluetooth adapter.
As all my BLE Proxies use the same brand/model of ESP32 (providing very consistent BLE data), and are much more flexible in terms of physical placement and configuration, I would like to be able to "ignore" the USB Bluetooth adapter for this integration.

The reported distance for the USB Bluetooth adapter is vastly different than the ESP32-based BLE Proxies.
As the reference power and attenuation settings for this integration are global, it makes more sense to use identical BLE Proxy devices wherever possible.

Describe alternatives you've considered

1. Removing the BLE Proxy from the same room as my HA system/USB Bluetooth adapter
   • I find the ESP32-based ESP Proxies to be more reliable than the USB Bluetooth adapter in some situations, due to being able to alter the BLE scan interval and window settings in ESPHome.
2. Removing the Bluetooth USB Adapter from the HA machine
   • Some native HA features/integrations appear to only be available via a genuine adapter (I may be wrong about this, I cannot find a specific example)
3. Making the reference power and attenuation settings per-adapter instead of global, to allow normalization of values
   • This is likely to require a considerable amount of code refactoring, and would make the integration overly complex for the average user.

Additional context
I can foresee situations where the user may also want to ignore specific other BLE proxies (eg a different brand), therefore the "ignore" option may be best to be generic and allow the user to ignore all data from any specific Bluetooth source(s).

Currently the config of which devices to create device_tracker entities for, and to create sensors for tracking the Area are hard-coded in init.py.

Create a config flow that allows the user to define which devices to monitor and in what way(s). Adding user-control over the entity id's and names would be nice, too.

Version of the custom_component

Bermuda 0.6.7
HA 2024.06.04

Configuration

Describe the bug

Bermuda is failing to start

Debug log

2024-06-28 10:22:32.733 ERROR (MainThread) [custom_components.bermuda] Unexpected error fetching bermuda data
Traceback (most recent call last):
  File "/usr/src/homeassistant/homeassistant/helpers/update_coordinator.py", line 312, in _async_refresh
    self.data = await self._async_update_data()
                ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/config/custom_components/bermuda/coordinator.py", line 446, in _async_update_data
    device.beacon_type.add(BEACON_IBEACON_SOURCE)
    ^^^^^^^^^^^^^^^^^^^^^^
AttributeError: 'list' object has no attribute 'add'
2024-06-28 10:22:42.488 INFO (MainThread) [homeassistant.components.mqtt.discovery] Found new component: binary_sensor cc01e1da-0848-485f-a4cd-a1119c539078 812beee8-fd95-489c-89a3-6ec214119e19_motion
2024-06-28 10:22:55.567 INFO (MainThread) [hass_nabucasa.google_report_state] Timeout while waiting to receive message
2024-06-28 10:22:58.152 ERROR (MainThread) [custom_components.bermuda] Unexpected error fetching bermuda data
Traceback (most recent call last):
  File "/usr/src/homeassistant/homeassistant/helpers/update_coordinator.py", line 312, in _async_refresh
    self.data = await self._async_update_data()
                ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/config/custom_components/bermuda/coordinator.py", line 446, in _async_update_data
    device.beacon_type.add(BEACON_IBEACON_SOURCE)
    ^^^^^^^^^^^^^^^^^^^^^^
AttributeError: 'list' object has no attribute 'add'

2024-06-28 10:29:35.061 ERROR (MainThread) [custom_components.bermuda] Unexpected error fetching bermuda data
Traceback (most recent call last):
  File "/usr/src/homeassistant/homeassistant/helpers/update_coordinator.py", line 312, in _async_refresh
    self.data = await self._async_update_data()
                ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
  File "/config/custom_components/bermuda/coordinator.py", line 446, in _async_update_data
    device.beacon_type.add(BEACON_IBEACON_SOURCE)
    ^^^^^^^^^^^^^^^^^^^^^^
AttributeError: 'list' object has no attribute 'add'
2024-06-28 10:29:35.062 DEBUG (MainThread) [custom_components.bermuda] Finished fetching bermuda data in 0.005 seconds (success: False)
2024-06-28 10:29:35.062 DEBUG (MainThread) [custom_components.bermuda] Coordinator last update failed, rasing ConfigEntryNotReady

Version of the custom_component

Latest

Configuration

Worked on latest on 2024.3.x

Describe the bug

A clear and concise description of what the bug is.

Debug log

Add your logs here.

Is your feature request related to a problem? Please describe.
I have 2 Bluetooth Proxies in my living/dining room (which is one open area). There is about 10 meter distance between both sensors. If someone is sitting at the end of the living room (around the blue line), he's in the middle of both sensors, causing the reading to bounce between 2 locations.

Describe the solution you'd like
I would like to be able to add a penalty to specific proxies. Lower the receiver strength (if that's possible) or something like that.
Anything to correct/alter positioning.

eg. I would like to add 3 meters to the distances to all discovered devices from proxy 0a1b2c

This way, if someone is sitting in between the living room and the dining room, it'll measure it as:
'Living room: 5 meters'
'Dining room: 8 meters'

Instead of both 5 meters.

Because a picture says a thousand words:

• 2 Bluetooth Proxies in both corners (blue circles)
• Blue line is center of the room and is when I get equal distance readings from both proxies
• Red line is what I consider the border between livingroom and dining room

So what I want is to be able to make some sort of correction to alter measurements so that the red line becomes the tipping point for determining the area a beacon is in, instead of the blue line.

When I set the area to 10 meters (30 feet), areas farther than 10 feet away become unknown. When I set the area to 25 meters (75 feet), the unknown areas reappear.

My house is neither 25 meters nor even 10 meters long or wide, so I believe there might be an issue with the conversion from meters to feet.

HA Versions
Core: 2024.5.4
Supervisor: 2024.05.1
Operating System: 12.3
Frontend: 20240501.1
Bermuda
Version: 0.6.6

I'm not sure how to retrieve the logs for this issue.

Version of the custom_component

0.4.3

Configuration

Installation via HACS using custom repo agittins/bermuda

Describe the bug

The new updates on main added 18 hours ago are not showing as a new version in HACS.
Choosing "Redownload" does a redownload but the code downloaded does not have the new changes (which look great btw)

Troubleshooting further, I see in https://hacs.xyz/docs/publisher that:

• https://hacs.xyz/docs/publish/action shows .github/workflows/validate.yml is needed, but this is not in the Bermuda repo
• https://hacs.xyz/docs/publish/start shows there may be some missing keys in hacs.json:

The default branch main is showing in the download list so "hide_default_branch": true
You mentioned the zip seems it was not being downloaded. This may because the following is needed:

"zip_release": true,
"filename": "bermuda.zip"

I'll change my fork and make a pr

For devices that don't have a static MAC, or who don't advertise their name it would be useful to ID them via the UUID they broadcast.

(user report from Steven @ https://community.home-assistant.io/t/bermuda-bluetooth-ble-room-presence-and-tracking-custom-integration/625780/2 notes HA Companion app sending beacons has stable UUID but no name listed against MAC).

Check if best to integrate with iBeacon integration or with jc2k's https://next.home-assistant.io/integrations/private_ble_device/ Private BLE Device integration rather than reinventing wheels (I think it only works with iOS currently).

• assess if better to tie in with an existing integration no for ibeacon, yes for IRK.
• ✔️ if not, split out the IRK/iOS parts and make this issue just about adding devices by UUID

Version of the custom_component

Version 0.4.3

Configuration

I have one device configured via UI and you do not use YAML for config

Describe the bug

I have just setup two ESPHome BT Proxies and I have no local BT device on HA. I have one noname small BLE iBeacon device.

At first the integration seems to work great and as expected. But then the device suddenly appear unknown and when that happens the HA log gets flooded as seen below

Debug log

2024-01-09 21:34:46.850 WARNING (MainThread) [custom_components.bermuda] Device changed TX-POWER! That was unexpected: f6:0a:34:1a:0d:03 10dB
2024-01-09 21:34:46.852 WARNING (MainThread) [custom_components.bermuda] Device changed TX-POWER! That was unexpected: cb:d1:5c:2e:17:0e -127dB
2024-01-09 21:34:51.652 WARNING (MainThread) [custom_components.bermuda] Device changed TX-POWER! That was unexpected: f6:0a:34:1a:0d:03 -127dB
2024-01-09 21:34:51.652 WARNING (MainThread) [custom_components.bermuda] Device changed TX-POWER! That was unexpected: fe:1f:3b:98:cc:e6 -127dB
2024-01-09 21:34:56.652 WARNING (MainThread) [custom_components.bermuda] Device changed TX-POWER! That was unexpected: f6:0a:34:1a:0d:03 10dB
2024-01-09 21:34:56.652 WARNING (MainThread) [custom_components.bermuda] Device changed TX-POWER! That was unexpected: fe:1f:3b:98:cc:e6 10dB
2024-01-09 21:34:56.652 WARNING (MainThread) [custom_components.bermuda] Device changed TX-POWER! That was unexpected: dd:7a:8c:77:be:df 10dB
2024-01-09 21:34:56.652 WARNING (MainThread) [custom_components.bermuda] Device changed TX-POWER! That was unexpected: cb:d1:5c:2e:17:0e 10dB
2024-01-09 21:35:01.652 WARNING (MainThread) [custom_components.bermuda] Device changed TX-POWER! That was unexpected: f6:0a:34:1a:0d:03 -127dB
2024-01-09 21:35:01.652 WARNING (MainThread) [custom_components.bermuda] Device changed TX-POWER! That was unexpected: dd:7a:8c:77:be:df -127dB
2024-01-09 21:35:01.652 WARNING (MainThread) [custom_components.bermuda] Device changed TX-POWER! That was unexpected: cb:d1:5c:2e:17:0e -127dB
2024-01-09 21:35:06.652 WARNING (MainThread) [custom_components.bermuda] Device changed TX-POWER! That was unexpected: d2:18:8c:f7:4f:93 -127dB
2024-01-09 21:35:06.653 WARNING (MainThread) [custom_components.bermuda] Device changed TX-POWER! That was unexpected: dd:7a:8c:77:be:df 10dB
2024-01-09 21:35:11.651 WARNING (MainThread) [custom_components.bermuda] Device changed TX-POWER! That was unexpected: d2:18:8c:f7:4f:93 10dB
2024-01-09 21:35:11.652 WARNING (MainThread) [custom_components.bermuda] Device changed TX-POWER! That was unexpected: dd:7a:8c:77:be:df -127dB
2024-01-09 21:35:16.652 WARNING (MainThread) [custom_components.bermuda] Device changed TX-POWER! That was unexpected: d2:18:8c:f7:4f:93 -127dB
2024-01-09 21:35:16.653 WARNING (MainThread) [custom_components.bermuda] Device changed TX-POWER! That was unexpected: dd:7a:8c:77:be:df 10dB
2024-01-09 21:35:16.653 WARNING (MainThread) [custom_components.bermuda] Device changed TX-POWER! That was unexpected: e7:b6:6a:84:73:bc -127dB
2024-01-09 21:35:16.653 WARNING (MainThread) [custom_components.bermuda] Device changed TX-POWER! That was unexpected: cb:d1:5c:2e:17:0e 10dB
2024-01-09 21:35:21.651 WARNING (MainThread) [custom_components.bermuda] Device changed TX-POWER! That was unexpected: d2:18:8c:f7:4f:93 10dB
2024-01-09 21:35:21.652 WARNING (MainThread) [custom_components.bermuda] Device changed TX-POWER! That was unexpected: f6:0a:34:1a:0d:03 10dB
2024-01-09 21:35:21.652 WARNING (MainThread) [custom_components.bermuda] Device changed TX-POWER! That was unexpected: e7:b6:6a:84:73:bc 10dB
2024-01-09 21:35:26.654 WARNING (MainThread) [custom_components.bermuda] Device changed TX-POWER! That was unexpected: dd:7a:8c:77:be:df -127dB
2024-01-09 21:35:26.655 WARNING (MainThread) [custom_components.bermuda] Device changed TX-POWER! That was unexpected: e7:b6:6a:84:73:bc -127dB
2024-01-09 21:35:26.655 WARNING (MainThread) [custom_components.bermuda] Device changed TX-POWER! That was unexpected: cb:d1:5c:2e:17:0e -127dB
2024-01-09 21:35:31.653 WARNING (MainThread) [custom_components.bermuda] Device changed TX-POWER! That was unexpected: dd:7a:8c:77:be:df 10dB
2024-01-09 21:35:31.653 WARNING (MainThread) [custom_components.bermuda] Device changed TX-POWER! That was unexpected: e7:b6:6a:84:73:bc 10dB
2024-01-09 21:35:36.652 WARNING (MainThread) [custom_components.bermuda] Device changed TX-POWER! That was unexpected: f6:0a:34:1a:0d:03 -127dB
2024-01-09 21:35:41.653 WARNING (MainThread) [custom_components.bermuda] Device changed TX-POWER! That was unexpected: d2:18:8c:f7:4f:93 -127dB
2024-01-09 21:35:41.654 WARNING (MainThread) [custom_components.bermuda] Device changed TX-POWER! That was unexpected: fe:1f:3b:98:cc:e6 -127dB
2024-01-09 21:35:41.655 WARNING (MainThread) [custom_components.bermuda] Device changed TX-POWER! That was unexpected: dd:7a:8c:77:be:df -127dB
2024-01-09 21:35:46.653 WARNING (MainThread) [custom_components.bermuda] Device changed TX-POWER! That was unexpected: d2:18:8c:f7:4f:93 10dB
2024-01-09 21:35:46.654 WARNING (MainThread) [custom_components.bermuda] Device changed TX-POWER! That was unexpected: f6:0a:34:1a:0d:03 10dB
2024-01-09 21:35:46.655 WARNING (MainThread) [custom_components.bermuda] Device changed TX-POWER! That was unexpected: fe:1f:3b:98:cc:e6 10dB
2024-01-09 21:35:51.652 WARNING (MainThread) [custom_components.bermuda] Device changed TX-POWER! That was unexpected: f6:0a:34:1a:0d:03 -127dB
2024-01-09 21:35:51.653 WARNING (MainThread) [custom_components.bermuda] Device changed TX-POWER! That was unexpected: cb:d1:5c:2e:17:0e 10dB

v0.6.3 (possibly earlier) breaks the dump_devices service, likely due to advertising data dict not being cast correctly for json output.

Calls with device filter arguments still work (maybe only sometimes) but call without options causes

  File "/config/custom_components/bermuda/__init__.py", line 1385, in service_dump_devices
    out[address] = device.to_dict()
                   ^^^^^^^^^^^^^^^^
  File "/config/custom_components/bermuda/__init__.py", line 599, in to_dict
    scanout[address] = scanner.to_dict()
                       ^^^^^^^^^^^^^^^^^
  File "/config/custom_components/bermuda/__init__.py", line 483, in to_dict
    for uuid, thebytes in self.adverts:
        ^^^^^^^^^^^^^^
ValueError: too many values to unpack (expected 2)

Discovered in #157 during troubleshooting another issue.

Version of the custom_component

v0.6.7

Configuration

Describe the bug

Installed the repository through HACS and when I try to add the integration (after HA restart) I get an error:

Error occurred loading flow for integration bermuda: cannot import name 'EventStateChangedData' from 'homeassistant.core' (/usr/src/homeassistant/homeassistant/core.py)

Debug log

Logger: homeassistant.config_entries
Source: config_entries.py:2444
First occurred: 18:50:57 (21 occurrences)
Last logged: 19:02:29

Error occurred loading flow for integration bermuda: cannot import name 'EventStateChangedData' from 'homeassistant.core' (/usr/src/homeassistant/homeassistant/core.py)

HA version info:
Core
2024.3.0
Frontend
20240306.0

On bermuda configuration devices list, there is no my device, while it is showing in esphome logs with:

esp32_ble_tracker:
text_sensor:
  - platform: ble_scanner
    name: "BLE Devices Scanner"

Don't know where to find other hints for this issue. Maybe type of my devices is odd ..its 3rd party AirTag like device. I think that its Mac can be dynamic too..