Repository navigation
If your Lockly has no hub (a WiFi-native Visage, for example) and sits at unknown after every Home Assistant restart until someone uses it, this release is for you. Found on #16 and #10.
The state is read over the broker
After a restart the integration reads each lock's state, with up to three tries, then re-probes every 30 minutes until one answers. All of those reads went through senddata, which relays through a Secure LINK hub, so for a hubless lock they could only ever fail with cod=930. The broker carries the same status query to these locks, and the startup read and the re-probe now use it. A hubless lock shows its real state within a minute or so of a restart. Its battery comes back at the same time, and so does its Door entity if the door is shut. Matter-hub (PGH260) locks fall back to the broker if senddata fails.
The re-probe stays silent when a lock doesn't answer, as before. Hubless locks are no longer sent cachedstatus or senddata calls that can only fail, so those cod=930 warnings disappear. One remains: the lock-log query still uses senddata, so you'll see one cod=930 per lock at startup.
No more rc=5 at startup
With every REST read failing by design, the first poll after a restart decided the login had gone bad and dropped the token, two seconds before MQTT connected with it. MQTT went in with no password and was refused with rc=5 until the 0.7.15 fresh-login retry rescued it. Hubless locks no longer count towards that check, and MQTT now logs in first if it ever finds no token.
A closed door is proof however it arrives
The Door entity only appears once a lock has reported its door closed, because a lock with no sensor fitted always reads open. Until now only a Bluetooth status query counted, so after a restart the entity could stay unavailable for hours while magnet=closed callbacks arrived over MQTT unused. Those callbacks count now.
Unchanged
Locks behind a PGH220 hub behave exactly as before.