Feature Request: Built-in Room Stability Filters and BLE Scan Optimization

First of all, thank you for Bermuda. In my opinion it is currently one of the most capable Bluetooth room presence systems available for Home Assistant.

Over the last weeks I have been testing Bermuda extensively in a real installation, trying to optimise both room detection accuracy and overall ESP32 performance.

My installation consists of:

9 ESP32 ESPHome Bluetooth proxies
Home Assistant
UniFi WiFi infrastructure (multiple APs)
iPhones used as tracked devices
ESP32 nodes that also perform additional tasks (lighting control, sensors, UART devices, etc.)

The tests revealed two different but closely related issues.

1. Room bouncing caused by normal BLE fluctuations

The current Bermuda algorithm always selects the room with the best instantaneous estimate.

This is perfectly reasonable, but in real environments BLE is inherently noisy.

Typical causes include:

RSSI fluctuations
missed advertisements
temporary WiFi latency
human bodies blocking the signal
doors opening/closing
reflections
ESP32 scan scheduling

The result is that two adjacent rooms may alternate every few seconds even though the phone never moved.

For example:

Desk
Bedroom
Desk
Bedroom
Desk

while the phone remained on the desk all the time.

Current workaround

The only practical solution I found was implementing an additional Home Assistant template sensor.

Instead of using Bermuda's area directly, all automations use a filtered sensor called:

iPhone Area Stable

[iphone_Area_Estable.txt](https://github.com/user-attachments/files/30291100/iphone_Area_Estable.txt)

This sensor implements:

temporal hysteresis
distance filtering
delayed unknown transitions

The improvement is dramatic.

False room transitions almost disappear.

Example implementation

The template uses different confirmation rules depending on signal quality.

A room change is accepted immediately only when the estimated distance is clearly inside the target room.

Otherwise Bermuda must keep reporting the same room for a longer period before the transition is accepted.

In simplified form:

if distance << room_limit:
accept after 2 seconds

elif distance slightly below room_limit:
accept after 20 seconds

else:
keep previous room

Unknown transitions are also delayed.

This produces a "sticky room" behaviour while still allowing very fast transitions when the user actually walks into another room.

Distance filtering and temporal hysteresis together work much better than either technique alone.

Why this belongs inside Bermuda

The Home Assistant template only has access to:

current room
current estimated distance

Bermuda already has much more information available:

advertisement timestamps
RSSI history
scanner update rate
previous room confidence
distance history
proxy quality
missed advertisements

Therefore Bermuda can make much better decisions internally than any external automation.

2. BLE scanning has a significant impact on ESP32 WiFi responsiveness

The second issue is related to ESP32 coexistence.

Most Bluetooth proxies are not dedicated devices.

They simultaneously perform:

Bluetooth scanning
WiFi communication
ESPHome API
UART devices
sensors
relays
lighting control

Increasing BLE scan intensity significantly affects WiFi responsiveness.

This not only impacts Bermuda itself but also every other ESPHome service running on the node.

The effect becomes visible as:

slower API responses
delayed entity updates
slower Home Assistant automations
increased WiFi latency
Measurements

I performed several controlled tests using continuous ICMP ping against every ESP32 while changing Bermuda scan parameters.

The installation contains:

9 ESP32 Bluetooth proxies
Home Assistant
UniFi network

Infrastructure remained stable during all tests:

UDM SE:
~0.2 ms average latency

Home Assistant:
~0.4 ms average latency

Therefore the bottleneck is not the WiFi infrastructure itself.

The latency increase occurs inside the ESP32 due to BLE/WiFi coexistence.

Typical ESP32 latency during BLE scanning ranged between:

40 ms
100 ms average

occasional peaks:
1–3 seconds

depending on scan parameters.

Final scan configuration

After many experiments the configuration that provided the best balance was:

esp32_ble_tracker:
scan_parameters:
interval: 500ms
window: 150ms
duration: 4s
active: false
continuous: false

with scans started every: 7 seconds

This produced good room detection while keeping WiFi latency acceptable.

Scan config WiFi latency Room stability
600 /100 / 4 / 8 Very Good Good
500 / 120 / 4 / 7 Very Good Better
500 / 150 / 4 / 7 Very Good Better

Important observation

Once the "Stable Area" template was introduced, scan frequency could actually be reduced.

The temporal and distance filtering compensates for the lower BLE update rate.

In other words:

Instead of increasing scan intensity to fight room bouncing, it is often better to:

perform slightly less BLE scanning
apply intelligent stability filters

This gives:

lower ESP32 load
better WiFi responsiveness
more stable room tracking

at the same time.

Possible Bermuda features

Something like:

room_stability:

room_change_delay: 5s

unknown_delay: 10s

distance_hysteresis: 0.5m

or any equivalent implementation.

Alternative idea

Instead of always selecting the closest room, Bermuda could score each candidate.

For example:

score =

estimated_distance
+ room_change_penalty
+ previous_room_bonus
+ recent_change_penalty
+ scanner_quality_penalty

This would naturally prevent bouncing while still allowing immediate transitions when the user genuinely moves.

Benefits
More stable room tracking
Better out-of-the-box behaviour
Less Home Assistant complexity
Reduced need for custom template sensors
Better coexistence with multi-purpose ESP32 nodes
Lower BLE scan frequency without sacrificing user experience

I hope this real-world experience is useful.

I'd be happy to test any experimental implementation or provide additional logs if that helps.