Skip to content

v0.7.3 — MQTT capability ordering, parse crash fix, honest push docs

Choose a tag to compare

View all tags
@Forcky Forcky released this 12 Sep 04:04
· 17 commits to main since this release
v0.7.3
ce67830

A bug-fix release, driven almost entirely by two users testing WiFi-native locks. Thank you both.

Fixes

Capabilities were read too early on the MQTT command path. When senddata is refused and the integration falls back to the broker, it now reads the lock's capabilities after the status query rather than before. That query is where the real lock type is learned, and it can differ from the guess made off the lock list. Reading it too early meant the first command could be built with the wrong command code: a type-105 lock that needs 0x52 was getting the default 0x22. Found and diagnosed by the reporter of issue #3 on two hubless Lockly Visage locks.

A credential frame from a PGD728FN no longer crashes the parser. Its layout is not one this parser fully models, and the field walk ran off the end and raised a ValueError in the log. It now stops cleanly and falls back to the cloud copy of the password, which is what already happened, just without the traceback.

Docs: real-time push, stated accurately

Earlier notes implied real-time push might work on a suitable hub. That was too broad. Two things share the MQTT connection and only one reaches Home Assistant:

  • State that comes back right after an HA lock or unlock is correct. That reply is routed to our own client topic and is verified.
  • A change made at the keypad, in the Lockly app, or over Matter is not reflected in HA. The server only pushes those to a client registered through Lockly's Firebase notification service, which needs a token a third-party client cannot get.

So state is accurate after you act through Home Assistant, and otherwise updates on the next command or successful poll. This is now documented plainly in the README and docs/api.md.

Where WiFi-native locks stand

Both hubless models under test (PGD728FG25 and PGK728WRHK) now reach their locks over the broker and are rejected with 0xFF (wrong password) using the cloud credential. The transport and frame appear correct; the credential value is the open problem. Tracked in issues #2 and #3.

Unchanged

Silent polling still needs hub firmware build 422 or newer, and signal readings are only available on PGH260 (Matter) hubs.

Assets 2
Loading