v0.7.2 — MQTT command transport confirmed working

A documentation release. No code changes from v0.7.1, but it records the first confirmation of something this project has been chasing for a long time.

The MQTT command transport works

A user whose senddata calls all return cod=930 can now lock and unlock their doors from Home Assistant. Their account is a PGD728FN behind a PGH260 hub, and every REST command the integration sends is refused by the cloud.

That case previously had no path at all. If your logs are full of cod=930 while the official Lockly app controls your locks normally, this is your situation, and v0.7.1 or later should work for you.

Worth knowing why it needed two attempts. On such an account senddata refuses everything, including the status query that supplies a command's nonce and the credential query that reads the host password. v0.7.0 sent a correctly transported command built from stale inputs, and the lock rejected it with BLE error F3. v0.7.1 fetches both over the same channel first.

What is still not routed that way

The periodic status query and the access log still go through senddata. On an affected account that means lock state can be stale even while commands work. Moving those across is the next step, and the transport underneath is now proven rather than theoretical.

For hub-less locks

Locks with no PGH hub, including WiFi-native models like the PGD728FG25 tracked in issue #2, have the same underlying problem: senddata relays through a hub they do not have. The MQTT channel does not use senddata at all, so it is now a working candidate rather than a guess. Untested on that hardware — if you have such a lock, a report would be valuable.

Also in this release

The README did not document this feature at all. The entry written for v0.7.0 was lost to an editing mistake on my part, so two releases shipped a significant capability that was only mentioned in release notes. It is now in the feature table and Known Limitations, along with the caveat about stale state above.