v0.6.4 — Stop inventing an MQTT client identity
Completes the MQTT correction started in v0.6.3. If you took v0.6.3, take this one too: on its own, v0.6.3 does not get as far as I said it would.
The bug
The getHeartbeatTime API call returns a client_id. That value turns out to be the device id the request sent it, echoed straight back, not an identity the server assigned. This integration treated it as real and used it to build the MQTT broker username as {client_id}_{email}, which means the broker was handed an identity assembled from a Home Assistant config entry id.
It rejected that outright with rc=5. Ignoring the echo and sending the plain account address instead gets the connection accepted.
Verified on hardware: the returned client_id is byte-identical to the config entry id sent in the request.
What this means in practice
With the broker address fixed in v0.6.3 and the username fixed here, the connection now behaves as documented:
| Stage | Result |
|---|---|
| CONNECT | accepted |
SUBSCRIBE to server |
refused (SUBACK 0x80) |
Real-time push still does not work. The subscription refusal is untouched by this release and remains the open problem. State continues to update at startup and after commands from HA.
What changes is where the failure happens. Previously the broker rejected the connection because we were sending it a made-up client identity and talking to the wrong host. Now the connection succeeds and the subscription is refused, which is the actual unknown. Your logs will show broker REFUSED the subscription to 'server' in place of connection refused rc=5.
That is not a fix for push, but it is an honest failure rather than a self-inflicted one, and it puts the remaining work in the right place.
A correction to the v0.6.3 notes
Those notes said to expect the connection to be accepted and the subscription refused. That only became true with this release. v0.6.3 corrected the broker address but left the invented username in place, so it still failed at rc=5. Apologies if that sent anyone looking for a change that had not happened yet.
Unchanged
Silent polling still needs hub firmware build 422 or newer, and locks with no hub are still unsupported. See v0.6.0 for the full picture.