v0.6.2 — Recover from a hub outage without restarting

A bug-fix release, and one worth taking if you have more than one lock or a hub that occasionally drops out.

The bug

When a lock failed its initial status query, v0.6.1 retried a few times and then gave up for good. That lock stayed stateless, with its door sensor entity unavailable, until Home Assistant was restarted. Nothing ever checked again.

That turned out to be too brittle, because the failure it guards against is often temporary. On the hardware this was found on, a hub refused every request with cod=930 for about five days and then recovered entirely on its own. The three locks behind it stayed dead the whole time and for days afterwards, purely because nothing was asking any more.

What changed

Locks that have been given up on now get one quiet retry every 30 minutes, so a hub coming back is noticed without a restart. Recovery is logged, and the retry stops once the lock answers.

It is deliberately a single attempt rather than the burst of three used at startup. This repeats for as long as the outage lasts, and every attempt wakes the lock, which is audible on models with the beep enabled. Simulated over 24 hours of polling, a permanently unreachable lock is woken about twice an hour. For comparison, the poll loop that caused an earlier beeping regression woke locks twelve times an hour.

Nothing changes for healthy hardware. A lock that answers on the first attempt is queried exactly once and never retried.

Also worth knowing about cod=930

If your logs show cod=930 ("hub/Secure LINK not associated with this lock"), it is worth knowing that this can be a temporary hub-side condition rather than a permanent misconfiguration. It was observed appearing spontaneously on a PGH220 hub whose lock records were entirely intact, persisting for five days, and then clearing with no intervention. The message suggests checking your hub binding in the Lockly app, which is still the right first step, but a working binding and a 930 are not contradictory.

This release is also what makes that case recover by itself.

Verified

Four PGD628FN locks behind two PGH220 hubs. The retry logic was exercised in simulation across four scenarios: a persistent 24-hour outage, a hub recovering after two hours, a healthy lock, and a single transient failure. All four behave as intended, including the transient case that a real lock hit at startup and which the retry rescued.

Unchanged

Real-time push still does not work, silent polling still needs hub firmware build 422 or newer, and locks with no hub are still unsupported. See v0.6.0 for the full picture.