Fix compatibility with Bermuda - #10
Open
FezVrasta wants to merge 5 commits into
Open
Conversation
- Derive a stable locally-administered MAC from the config entry ID via
SHA-256 so the scanner source is a valid MAC address instead of a raw
UUID string. Bermuda's mac_norm() / mac_math_offset() then work
correctly and the device registry lookup succeeds.
- Fix device_info identifier key from ("entry_id", …) to (DOMAIN, …).
- Add bluetooth connection to device_info so HA's bluetooth integration
device entry merges with the companion proxy device entry, allowing
Bermuda to read the area assignment for distance calculations.
Co-Authored-By: Claude Sonnet 4.6 <[email protected]>
Co-Authored-By: Claude Sonnet 4.6 <[email protected]>
The Android app sends a Unix epoch timestamp in milliseconds. Passing it (divided by 1000) directly as advertisement_monotonic_time made Bermuda report "last seen ~1.7 billion seconds ago" because HA expects a time.monotonic() value (machine uptime), not wall-clock time. Convert by computing the age of the advertisement and subtracting from time.monotonic(). Fall back to time.monotonic() when no timestamp is provided. Co-Authored-By: Claude Sonnet 4.6 <[email protected]>
Co-Authored-By: Claude Sonnet 4.6 <[email protected]>
Converting the phone's Unix timestamp to a local monotonic time assumes the phone and HA server clocks are in sync. Any drift is added to the computed advertisement age; a phone running 10 s behind the server makes every advertisement appear 10 s stale in Bermuda. Using time.monotonic() stamps each advertisement as received "now" by HA. The maximum error is the app's batch interval (≤ 3 s), which is negligible compared to Bermuda's staleness thresholds. Co-Authored-By: Claude Sonnet 4.6 <[email protected]>
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
1 participant
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
The upstream integration registers the scanner with
source = entry_id— a 32-character UUID string. Several parts of HA and third-party integrations assume the scannersourceis a MAC address, which causes two problems:1. Bermuda BLE Trilateration cannot use the scanner
Bermuda calls
mac_norm()andmac_math_offset()on every scanner'ssourceto look up the device in the HA device registry. Applied to a UUID string these produce garbage values, the lookup returns nothing, and Bermuda raises a "scanners without areas" repair issue for the proxy. The scanner is never usable for distance calculations.Fix: A stable, locally-administered MAC address is deterministically derived from the
entry_idvia SHA-256. The first 6 bytes of the digest are taken, the locally-administered bit is set and the multicast bit is cleared, giving a consistentxx:xx:xx:xx:xx:xxaddress that is stable across restarts without persisting any extra state.2. The device entry does not merge with HA's bluetooth integration entry
Since HA 2025.2,
async_register_scannercreates a device registry entry withconnections = {("bluetooth", source.upper())}. The upstreamsensor.pyregistered the companion device with identifier key"entry_id"(non-standard) instead ofDOMAIN, and without a matchingbluetoothconnection, so the two entries never merged. This prevented area/name information from being shared between them.Fix:
device_infonow uses(DOMAIN, entry_id)as the identifier and addsconnections = {("bluetooth", source_mac.upper())}, allowing HA to merge the two device entries. Once you assign an area to the device, Bermuda picks it up automatically.3. Bermuda shows last advertisement as ~55 years ago
The Android app includes a Unix epoch timestamp (milliseconds) with each advertisement batch. The upstream code divided this by 1000 and passed it directly as
advertisement_monotonic_time, but HA expects atime.monotonic()value — seconds since machine boot, typically a small number. Passing ~1.74 billion seconds made every advertisement appear to have been received 55 years in the past, so Bermuda reported distances as stale and unusable.Fix: The advertisement age is computed as
time.time() - ts_ms / 1000and subtracted fromtime.monotonic(), correctly anchoring the phone's wall-clock timestamp to the local monotonic clock.