v0.7.0 — Correct MQTT topic, and a second command transport

This release corrects a mistake in v0.6.5 and adds a second way to reach locks that senddata refuses.

Real-time push was never impossible

v0.6.5 said push could not work, and explained why at length. That was wrong.

The integration had been subscribing to the topic server. That topic is publish only — the official app posts commands to it and never reads from it. The broker was correctly refusing our subscription every time. Replies and state callbacks arrive on client/<client_id> instead.

Verified against the live broker:

• subscribing to the client topic is granted (qos=0)
• a published command is acknowledged
• the server replies on that topic

The Firebase Cloud Messaging dependency described in v0.6.5 is real, but it governs the app's phone notification registration, not the MQTT device channel. It was a correct finding attached to the wrong feature, and a single publish test undid the whole conclusion. Apologies to anyone who read those notes and gave up on push.

Whether push actually reaches you still depends on your hub. A granted subscription means the integration is listening; the hub has to put state on the channel. A PGH220 on firmware build 417 does not — the broker answers commands for it with 3005 device is offline. Newer hubs appear to be connected, since the official app uses this channel to control locks over WiFi.

So expect the subscription lines in your log either way, and judge push by whether lock state changes when you use the keypad.

A second command transport

When senddata refuses a lock or unlock, the integration now retries the same command over the MQTT broker as a lockCommandRequest.

This matters if you are one of the users whose logs are full of cod=930 while the official app works normally. That combination is explained by the app reaching those locks over the broker rather than through senddata.

This is implemented but not confirmed to open a door. The only hardware available to test it reports device is offline on that channel, so the publish is accepted and goes nowhere. The frame sent is byte-for-byte the one senddata carries, which is verified, so nothing new is being guessed at — but the transport itself is untested end to end. No optimistic state update is applied on that path, since a queued publish is not an acted-on command.

If you have a newer hub and senddata has been failing, please report whether this works. That is the one piece of evidence still missing.

Also

A refused subscription no longer tears down the connection. The broker was observed delivering a message without granting a subscription, so dropping the session on a refusal threw away a working connection.

Unchanged

Silent polling still needs hub firmware build 422 or newer, and locks with no PGH hub are still unsupported.