[Custom integration] BlueSight — what is actually holding your Bluetooth proxy slots

Share your Projects! Custom Integrations
,
1

:round_pushpin: News and support live on GitHub

I maintain this integration alone and unpaid, so everything is tracked in one place: report a bug or ask a question.

New versions no longer need announcing here: HACS offers you the update, release notes included. Otherwise, the RSS feed https://github.com/dasimon135/ha-bluesight/releases.atom, or Watch → Releases on the repository.

This thread stays open for user-to-user help. The README is the reference and stays current — this post does not.

Hi everyone,

I’ve published a custom integration for a problem that cost me a lot of time and for which I could not find any existing tool.

Repo: GitHub - dasimon135/ha-bluesight: See the invisible: read-only Home Assistant integration that surfaces ESPHome Bluetooth-proxy GATT slot allocations and detects deadlocks (core issue #176516), ghost slots, and pairing storms. · GitHub

Home Assistant shows you which devices a Bluetooth proxy can hear, but not which ones are holding its GATT connection slots. An ESP32 proxy has only three by default. When one gets stuck on a dead device, your other Bluetooth entities go unavailable with no error — you restart the proxy at random and it happens again.

BlueSight reads the slot data Home Assistant already tracks internally and turns it into diagnostics: deadlock (a device connected to two proxies at once — core issue #176516), ghost slot, pairing storm, missing pairing key, plus proxy offline/stalled/reboot-storm detection. Everything shows up as sensors plus a notification naming the fix, not just an error code. An optional ESPHome component upgrades the heuristics to measured evidence — details in the README.

Everything is read-only — it observes and advises, never touches a slot.

Requirements: Home Assistant ≥ 2025.7, one or more ESPHome Bluetooth proxies (or local adapters).

Installing: not yet in the HACS default store — add https://github.com/dasimon135/ha-bluesight as a custom repository (category Integration). The Lovelace card ships with the integration, nothing to add by hand.

Feedback wanted, especially false positives and larger multi-proxy setups I can’t test myself. Issues and questions welcome here or on GitHub. :blue_circle:

3 Likes
2

Update: the Lovelace card is now included — added it back in v0.4.0, my mistake for saying otherwise earlier. Just install/upgrade through HACS and it’ll be there.

Also, as of v0.5.0, BlueSight now speaks French too (should pick up your HA language automatically). More languages can follow if there’s interest — happy to take PRs for translations.

Release notes here if you want the details:

  • v0.4.0 — Lovelace card added
  • v0.5.0 — French translation

Let me know if you run into anything after updating :slightly_smiling_face:

2 Likes
3

Update — v0.6.5, and the roadmap item above has shipped.

card_en
card_en534×650 14.9 KB

The “next up” in my Roadmap section is done: there is now an optional ESPHome component for the proxies themselves. Two blocks pasted into a proxy config you already run, no change to the radio and no slot consumed — it is a passive observer on the BLE event stream:

external_components:
  - source: github://dasimon135/[email protected]
    components: [bluesight]

bluesight:

It publishes three things Home Assistant cannot see at all: SMP (pairing) failure counts, the proxy’s NVS bond store, and per-connection idle time.

What that buys:

  • pairing-storm detection stops being a heuristic and becomes a count;
  • a new diagnosis, missing pairing key — a device whose pairing keeps being refused by a proxy that holds no key for it. The remedy is exact, and that is the point: re-pair through that specific proxy, because bonds are per-central and pairing through whichever proxy HA picks next will not help. It found a thermostat here that had been unreachable for hours for exactly that reason, while the proxy that did hold the key sat idle;
  • a ghost slot can now be judged for a device Home Assistant does not manage at all.

Evidence is replaced per proxy, so a mixed fleet degrades gracefully: a flashed proxy is judged on measurements, an unflashed one keeps the heuristic, and everything works with no proxy running it. Flash one node and compare before deciding.

It has also been wrong twice, which is the part I want help with. A thermostat working normally was reported as needing a re-pair because a different proxy had refused it in the past — the count was the firmware’s lifetime counter, so the incident could never clear. 0.6.4 made it a count inside a rolling window. And a BLE Mesh proxy link, healthy but silent for nine hours and invisible to HA’s device registry, was flagged as a stuck slot.

Both are the same class of mistake, and it is the one that matters here: an alarm on something that is fine teaches you to ignore the tool, and you do not get that back. I would rather hear about one false positive than ten confirmations — especially on BLE devices Home Assistant does not manage, where the only evidence is how long a connection has been quiet.

Also since the original post: the Lovelace card ships with the integration and registers its own dashboard resource (0.4.0 — the manual steps described above are gone), the card names the device holding each slot, and the interface and notifications follow your language, English and French.

Releases: Releases · dasimon135/ha-bluesight · GitHub