v1.5.5 - the light frees itself from a stuck Bluetooth link

Fluval BLE v1.5.5

v1.5.5 lets the integration free a light that a Bluetooth proxy is still holding
after the proxy itself has forgotten the connection.

Fixed

• A light stuck behind a "ghost link" now frees itself. After a proxy glitch, the
  proxy's radio can keep the light's connection even though the proxy has forgotten it.
  The light thinks it is still connected, stops advertising, and nothing can reach it
  (on another light in the same house this lasted 22 hours). Now, if the light has not
  been heard by any proxy for 3 minutes since its link ended, the integration asks the
  proxy that last held it to drop its connections one at a time and stops as soon as the
  light is heard again. If the light is still silent (it may simply be unplugged), it
  tries again after 30 minutes, then 2 hours, then every 6 hours.

Notes

This needs the proxy action force_disconnect_handle on the ESPHome proxy. A proxy
without it is left alone and the light keeps retrying as before. A light that is
heard but cannot be connected (for example all proxy slots busy) is never touched.
No settings, entities or actions were added; the Connection sensor gains two
attributes, ghost_links_freed and last_ghost_try, which also appear in diagnostics.

v1.5.4 - restarts no longer wait on the light

Fluval BLE v1.5.4

v1.5.4 fixes the last thing that made Home Assistant's restart wait on the
Fluval light: about 30 seconds lost at every start.

Fixed

• Restarts no longer stall for about 30 seconds. When Home Assistant started,
  the integration's first "set the light's clock" step got stuck waiting for the
  connection to the light, while the connection itself was waiting for that same
  step to finish. Neither could move until a 30-second timer broke the tie. Anything
  else that wanted to talk to the light during startup (an automation, for example)
  had to queue behind it, and Home Assistant waited for those too. The two steps no
  longer wait on each other, and the clock step now finishes in a fraction of a
  second.

• The first check now waits for the light to connect instead of getting in the
  way of the connection. If the light never connects (switched off or out of range)
  the check still runs after 15 seconds and reports it as unreachable, as before.

• A check that was skipped is no longer lost. If the light connected while a
  check was already running, one more check now runs right after it instead of
  waiting for the next scheduled one.

• Clock and status steps give up after 10 seconds instead of 30, so a stuck step
  clears sooner.

Notes

No settings, entities or actions changed.

v1.5.3 - safer connection teardown

Fluval BLE v1.5.3

v1.5.3 fixes two rare problems that could show up after the faster-startup
changes in v1.5.2: a Bluetooth proxy keeping a stale "listener" for the light,
and a light staying connected after a reload.

Fixed

• A stuck connection step is now ended the polite way. When a Bluetooth
  proxy was slow to answer the light, the integration used to give up by
  cancelling its own wait. With ESPHome proxies that can leave a stale listener
  behind until the proxy restarts. It now tells the proxy how long to wait
  (4 seconds for a subscribe, 8 seconds for a read), so the proxy cleans up
  after itself. The old 10-second cut-off stays only as a safety net.

• Reloading can no longer leave the light's connection open. If Home
  Assistant reloaded the integration (or you used fluvalble.release_link) at the
  moment a stuck connection was being dropped, the disconnect could be skipped.
  The light would then stay connected, which blocks the new copy of the
  integration and the Fluval phone app. Dropping a connection now always
  finishes, even if the task that started it is cancelled.

Notes

No settings, entities or actions changed.

v1.5.2 - startup never waits on the light

Fluval BLE v1.5.2

v1.5.2 makes sure the Fluval light can never slow down a Home Assistant restart,
even when the light is switched off, out of range, or the Bluetooth proxy is busy.

Fixed

• Restarts no longer wait for the light. The first "is the light in the right
  mode?" check, and the one-time old-schedule conversion, used to be tasks that
  Home Assistant waited for before it said it had finished starting. Because that
  check connects to the light, a light that did not answer could hold startup open
  for a long time. They now run quietly in the background, so Home Assistant starts
  right away and the light's entities fill in as soon as it connects.

• A stuck Bluetooth connection gives up faster. If a connection attempt or a
  single Bluetooth step hangs, it is abandoned after 10 seconds (it used to be 30
  and 15) and tried again, so a light recovers sooner after a proxy hiccup.

Notes

No settings, entities or actions changed. The light is still kept in the right
mode by the schedule guardian, exactly as before.

v1.5.1 - Reloads during shutdown can no longer reconnect the light

Fluval BLE v1.5.1

v1.5.1 closes two gaps in the automatic Bluetooth release added in v1.5.0, so a
Home Assistant restart can never leave the Fluval light on a stuck connection.

Fixed

• A reload during shutdown can no longer reconnect the light. Once Home
  Assistant has started shutting down, the integration now refuses to set up
  again (including reloads and the delayed re-setup that fluvalble.release_link
  schedules). Previously a reload at exactly the wrong moment could open a fresh
  connection after the release had already run, and nothing would close it.
  A single process-wide "shutting down" marker, set at the very start of
  shutdown and never removed, now guards every setup and every delayed re-setup.

• Pressing "Return to schedule" during shutdown is no longer counted as a
  failure. The press is simply ignored, so it cannot raise a "schedule
  problem" repair that has nothing to do with the light.

Notes

No settings, entities or actions changed. fluvalble.release_link works as
before.

v1.5.0 - Clean Bluetooth release on every Home Assistant shutdown

Fluval BLE v1.5.0

v1.5.0 makes every Home Assistant restart let go of the Fluval light's
Bluetooth connection cleanly, so a restart no longer leaves the light stuck on
a "ghost" connection.

Changed

• The Bluetooth link is now released automatically when Home Assistant shuts
  down - from the restart menu, an update, or anything else that stops Home
  Assistant. Before this, only running the fluvalble.release_link action
  first (the safe_restart script) avoided the stuck-light problem.

  It happens at the earliest point of shutdown, while Bluetooth and the ESPHome
  proxies are still running, and covers both cases: a link held open on purpose
  (the Hold connection option) and a short-lived one opened for a schedule
  check or a command. The light and its entities stay in place - only the
  connection is dropped.

• Once shutdown has started, the integration will not open a connection again:
  health checks, keep-alive pings, reconnect attempts, and button or light
  commands are all refused. The "light unreachable" countdown and its repair are
  switched off first, so the deliberate disconnect is never reported as an
  outage.

• Releasing is limited to 8 seconds per light and can never block or break
  shutdown; a warning is logged if the disconnect does not finish in time.

Notes

fluvalble.release_link is unchanged and still works, so safe_restart can
keep calling it until you are happy the automatic path does the job. A
"Released BLE link to at shutdown" line in the Home Assistant log
confirms it ran.

1.4.1 - held link survives a timed-out check

Fixed

• A held link no longer dies permanently after a timed-out check. A guardian check or command that hit its deadline reset the connection, which also cancelled the reconnect supervisor and left no client. In hold mode nothing reconnected afterwards until a user command ran - even while the fixture kept advertising. Observed live: disconnected for hours with no reconnect attempt logged.
• In hold mode an advertisement now re-arms the hold exactly once (never while a reset is still tearing down). Idle installs are unchanged.

832 tests pass; the new regression test fails on 1.4.0.

v1.4.0

Fluval BLE v1.4.0

v1.4.0 adds one option: Preferred proxy, which pins the fixture's Bluetooth
link to the ESPHome proxy you choose instead of letting Home Assistant re-pick
by signal strength on every connect.

Added

• Preferred proxy (options flow, dropdown of the proxies Home Assistant can
  currently see; leave it empty for the previous behaviour).

  Home Assistant's Bluetooth stack ignores the device an integration hands it
  and re-scores every available route on each connect, so the fixture can be
  carried by a proxy two rooms away even when one sits beside it. That is not a
  cosmetic detail: every ghost link observed on this network between 2026-09-09
  and 2026-09-17 formed on exactly such a marginal long link, where the
  disconnect handshake fails to complete and the fixture is left believing it is
  still connected - it stops advertising, and nothing can reach it until the
  proxy's controller is made to drop the link.

  Fallback is bounded and automatic. The preferred proxy is used only when
  it is currently advertising the fixture, can accept a connection, and has not
  failed the last three attempts in a row. Otherwise Home Assistant's default
  selection runs completely unchanged - no route is ever blocked, and the
  preference applies again as soon as that proxy succeeds once. A proxy that is
  offline when you open the options form is still offered, so a choice already
  made is never silently dropped.

  The Connection sensor gains preferred_proxy and via_preferred_proxy
  attributes, so it is visible whether a live link actually took the preferred
  path or fell back.

Notes

Implemented by specialising only Home Assistant's backend-selection step; all of
its connection bookkeeping (slot accounting, in-progress tracking, failure
counts) is left intact. If a future Home Assistant release changes that internal
hook, the option disables itself with a warning in the log and default routing
applies - it cannot break connections.

v1.3.1

Slim: remove proxy-reboot/reload guards and diagnostic noise; keep hold-connection reconnect. Link issues are now informational only (no restart_proxy / power_cycle paths).

1.1.3

Fluval BLE v1.1.3

v1.1.3 corrects the schedule-write verification introduced in v1.1.2.

Fixed

• Schedule writes are verified with a settle-then-poll readback (0.5 s, 1 s,
  2 s, 2 s) instead of a single immediate read. The AquaSky answers a status
  read issued right after a schedule write with the previous schedule and
  reports the new one a second or two later, so v1.1.2 rejected correct writes
  as "did not confirm" (observed live three times on 2026-09-05). A regression
  test replays a stale-then-correct readback sequence.