v0.7.0-rc2 — a failed connect now says why (validation build)

Release candidate for 0.7.0, replacing v0.7.0-rc1. Install through HACS → Redownload → Show beta versions, restart Home Assistant, then run the checks below. Tag the final only if they pass.

Same six commits as rc1 plus one: the reason a failed connect gives for failing.

What changed since rc1

A failed connect now says what failed. The handler logged the exception's message, and the asyncio.timeout guarding the connect raises a TimeoutError whose str() is the empty string — so the line read mesh connect failed: and stopped there. The one message that could have explained the 2026-09-05 21:56 stall, which only a Home Assistant restart cleared, carried no reason at all. The exception type is now part of the reason.

It was also logged at debug, which was the wrong level for a failure that takes the integration unavailable. Only the miss that crosses UNREACHABLE_THRESHOLD warns — the ones below it are routine on a lamp with a single proxy slot, and probing carries on for as long as the link is down, so warning on every retry would bury the first one.

Before running these checks, consider narrowing custom_components.bluetooth_mesh: debug in configuration.yaml. At the current frame-level debug output the log turns over in seconds, and the new warning — the whole point of this candidate — would be buried in bearer RX/TX lines long before you read it. custom_components.bluetooth_mesh.coordinator: debug alone keeps the useful half.

What to check, and what a failure looks like

1 — The first click after a restart is fast. With keepalive_seconds: 0, restart Home Assistant, wait for the lamp to become available, then toggle it. It should act immediately.
Failure is visible as: a multi-second pause before the lamp moves — the startup probe released the link instead of keeping it, which is the old behaviour this release removes.

2 — A timed keep-alive still releases the link. Set keepalive_seconds to something small (30), restart, toggle the lamp, then leave it alone past the timeout and confirm the vendor app can still take the lamp. Set it back to 0 afterwards.
Failure is silent, and this is the check worth the most: if the link is now held for a timed keep-alive too, nothing in any log says so — you only find out because the vendor app can no longer connect. That option exists precisely to hand the lamp's single slot back.

3 — Availability survives a Home Assistant shutdown. Restart Home Assistant and read the log during the CLOSE stage.
Failure is visible as: reconnection attempts, or Insufficient authorization, logged while the core is already shutting down — the watchdog chasing a link nobody wants back.

4 — Colour temperature and brightness are read back, not assumed. Never run against rc1, and this is what the final tag is waiting on.

Read this before running it: with keepalive_seconds: 0 the link is held permanently, and a mesh node has a single proxy slot — so the vendor app cannot see the lamp at all, and the check as written in rc1 was impossible to perform. Either use a wall remote (its changes travel the mesh and need no slot), or free the slot first:

1. set keepalive_seconds to 30 and restart Home Assistant;
2. leave the lamp alone past the timeout, so Home Assistant hands the slot back;
3. from the vendor app, change both brightness and colour temperature, then close the app to release the slot;
4. click the light in Home Assistant, or wait for the probe, so the link is re-established;
5. set keepalive_seconds back to 0.

Failure is visible as: Home Assistant showing the value it last sent rather than the lamp's own. Nothing in this release touches that path, which is exactly why confirming it did not is the cheap half of the validation.

The gap that still gates the final tag

One behaviour has never been observed live: a lost link recovering on its own, outside a Home Assistant restart — the probe on the fast interval plus the next advert triggering a connect. It is covered by tests only, and it cannot be forced on demand.

The 2026-09-05 21:56 stall is the same gap seen from the other side: the link went and nothing brought it back until Home Assistant was restarted, and the log said nothing about why. v0.7.0 should not be tagged until a link loss is seen to recover by itself. If that happens while this rc is installed, the log now names the exception type that caused it — that line is the observation the final release wants.

Everything else has been running on the author's Home Assistant since 2026-09-04 19:47 with keepalive_seconds: 0 throughout. As of 2026-09-07 the entry reports available: true, connected: true, no active repair.