v0.7.1 — Build MQTT commands from a fresh nonce and the lock's own password
Follow-up to v0.7.0. If v0.7.0 reached your lock over MQTT and the lock refused the command, this is the fix.
What was wrong
v0.7.0 sent commands over the broker when senddata failed, and that transport worked: the server delivered the frame and the lock answered. The lock then rejected it.
The reason was in the same log, two lines earlier. On an account where senddata returns cod=930, it returns 930 for everything — including the status query that supplies the command's nonce, and the credential query that supplies the host password. So the command was transported correctly and built from a nonce hours old and the cloud's stale copy of the password. The lock was right to refuse it.
The fix
The broker's reply carries the lock's own response, which means it can relay any frame this integration builds, not just lock and unlock. The command path now fetches a fresh nonce and reads the host password from the lock over the same transport before building the command, instead of trusting values that came from a channel known to be failing.
A correction to v0.7.0
v0.7.0 logged lock command acknowledged whenever the server replied with code: 0. That was wrong: code: 0 only means the server delivered the frame to the lock. The lock's own verdict is inside the reply, and in the first real-world test that verdict was a rejection being reported as a success.
The reply is now decoded and the outcome reported honestly. Lock state is only updated optimistically when the lock actually accepted the command.
If you saw lock command acknowledged on v0.7.0 and your door did not move, that message was the bug, not your setup.
Still unverified
I cannot confirm this opens a door. The hardware available to me is not on the MQTT channel at all, so the fix addresses the exact reason the first attempt failed without proving the next one succeeds. Every part of the frame is verified code — the same builders and parsers used by the senddata path, which is confirmed working — but whether the lock accepts the corrected command is unknown until someone with an affected account tries it.
If senddata fails for you with cod=930 while the official app works normally, this release is aimed at you, and a report either way is genuinely useful.
Also
The request/response handling is covered by tests, including the case where the broker delivers the same reply more than once, which it does for every exchange observed so far.
Unchanged
Real-time push still depends on your hub being connected to the MQTT channel. Silent polling still needs hub firmware build 422 or newer.