v0.6.1 — Retry the initial status query

A bug-fix release. Worth taking if your hub does not support the cachedstatus endpoint — which is every hub below the silent-polling firmware minimum, and where this bug does its damage.

The bug

When the hub's cache endpoint is unavailable, the integration falls back to querying each lock directly to seed its initial state. That query was attempted once per lock per session and then discarded, whether or not it worked. A lock that happened to fail that single attempt was left with no state at all until Home Assistant restarted — and with its door sensor entity unavailable, which is worst for the locks that actually have a sensor fitted.

The single attempt was deliberate: querying a lock wakes it, and some models beep when woken, so an earlier version that retried on a timer made locks beep every few minutes. The fix is a bounded retry rather than an unbounded one.

What changed

• The initial status query now retries, once per poll cycle, up to three attempts, and stops as soon as one succeeds. Three attempts at startup is the whole budget — this never becomes a poll loop, and a lock is never woken repeatedly during normal operation.
• Exhausting those attempts now warns, naming the lock. Previously the failure was invisible at default log level: the entity simply never appeared.
• A lock error is decoded instead of counted. When a lock answers a status query with a bare error byte, the log now names the error rather than reporting payload not AES-aligned (1 bytes) at debug level.
• Extra diagnostic fields in the per-lock debug line — gateway model and version, otlkmod, ekeyType, secondAdm, and whether iotdm and clientId are populated. This is to help diagnose reports where the cloud refuses to relay to a lock. Credentials are still never logged, and the two identity fields are reported as present/absent rather than by value.

Verified

On four PGD628FN locks behind PGH220 hubs. On the first restart after the fix, one lock's initial query failed with a hub relay timeout and succeeded on the retry — under v0.6.0 that lock would have had no state for the whole session. A second lock, which had been stuck stateless for ten hours, came back immediately and its door sensor with it.

A third lock exhausted all three attempts with repeated relay timeouts and logged the new warning, which is the give-up path behaving as intended. That lock appears to have a marginal BLE link to its hub — a hardware condition, not something more retries would fix.

Unchanged

Everything else is as in v0.6.0: 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.