I am unable to send commands over MQTT

Hi Nuki,

I am unable to send commands lock/unlock over MQTT. Nuki is connected to my broker. But when I send from other client “nuki/mydevid/lock” topic with payload “true” nothing happens (QoS=2, retain=false).

Can you please advise me, what am I doing wrong?

Regarding documentation, I’d recommend to add there some examples of commands. And I am a bit confused, if MQTT support is released or in Beta still.

Attaching traces from my broker:
– moment when locks connect to my broker
2023-07-08 13:27:12.5682|17656|61|TRACE|Hub|Account: ******, Pwd:
2023-07-08 13:27:12.5967|17656|54|TRACE|Hub|MQTT Client Authentication 'SL3P_AABBCC99(Peter Kornalsky): OK
2023-07-08 13:27:12.5967|17656|54|TRACE|Hub|Client Connected:, SL3P_AABBCC99, V311
2023-07-08 13:27:12.7505|17656|14|TRACE|Hub|Server Message Not Consumed: SL3P_AABBCC99, homeassistant/lock/nuki_AABBCC99_lock/config, {"~":“nuki/AABBCC99”,“avty_t”:"~/connected",“pl_avail”:“true”, “pl_not_avail”:“false”,“dev”:{“ids”:"[AABBCC99]",“mf”:“Nuki”,“name”:“Svarogus”,“mdl”:“Smart Lock 3.0 Pro”},“name”:“Svarogus”,“uniq_id”:“AABBCC99_lock”,“cmd_t”:"~/lockAction",“pl_lock”:“2”,“pl_unlk”:“1”,“pl_open”:“3”,“stat_t”:"~/state",“stat_locked”:“1”,“stat_locking”:“4”,“stat_unlocked”:“3”,“stat_unlocking”:“2”,“stat_jam”:“254”,“val_tpl”:"{% if value in (“5”,“6”,“7”) %}3{% else %}{{value}}{% endif %}"}
2023-07-08 13:27:12.8014|17656|62|TRACE|Hub|Server Message Not Consumed: SL3P_AABBCC99, homeassistant/binary_sensor/nuki_AABBCC99_lock/config,
2023-07-08 13:27:12.8740|17656|14|TRACE|Hub|Server Message Not Consumed: SL3P_AABBCC99, homeassistant/sensor/nuki_AABBCC99_battery_percent/config, {"~":“nuki/AABBCC99”,“avty_t”:"~/connected",“pl_avail”:“true”, “pl_not_avail”:“false”,“dev”:{“ids”:"[AABBCC99]",“mf”:“Nuki”,“name”:“Svarogus”,“mdl”:“Smart Lock 3.0 Pro”},“name”:“Svarogus Battery”,“uniq_id”:“AABBCC99_lock_battery_percent”,“dev_cla”:“battery”,“ent_cat”:“diagnostic”,“stat_t”:"~/batteryChargeState",“stat_cla”:“measurement”,“unit_of_meas”:"%"}
2023-07-08 13:27:12.9811|17656|14|TRACE|Hub|Server Message Not Consumed: SL3P_AABBCC99, homeassistant/binary_sensor/nuki_AABBCC99_lock_battery_critical/config, {"~":“nuki/AABBCC99”,“avty_t”:"~/connected",“pl_avail”:“true”, “pl_not_avail”:“false”,“dev”:{“ids”:"[AABBCC99]",“mf”:“Nuki”,“name”:“Svarogus”,“mdl”:“Smart Lock 3.0 Pro”},“name”:“Svarogus Battery critical”,“uniq_id”:“AABBCC99_lock_battery_critical”,“dev_cla”:“battery”,“ent_cat”:“diagnostic”,“stat_t”:"~/batteryCritical",“pl_off”:“false”,“pl_on”:“true”}
2023-07-08 13:27:13.0822|17656|62|TRACE|Hub|Server Message Not Consumed: SL3P_AABBCC99, homeassistant/binary_sensor/nuki_AABBCC99_battery_charging/config, {"~":“nuki/AABBCC99”,“avty_t”:"~/connected",“pl_avail”:“true”, “pl_not_avail”:“false”,“dev”:{“ids”:"[AABBCC99]",“mf”:“Nuki”,“name”:“Svarogus”,“mdl”:“Smart Lock 3.0 Pro”},“name”:“Svarogus Battery charging”,“uniq_id”:“AABBCC99_battery_charging”,“dev_cla”:“battery_charging”,“ent_cat”:“diagnostic”,“stat_t”:"~/batteryCharging",“pl_off”:“false”,“pl_on”:“true”}
2023-07-08 13:27:13.1833|17656|54|TRACE|Hub|Server Message Not Consumed: SL3P_AABBCC99, homeassistant/binary_sensor/nuki_AABBCC99_door_sensor/config,
2023-07-08 13:27:13.2856|17656|14|TRACE|Hub|Server Message Not Consumed: SL3P_AABBCC99, homeassistant/binary_sensor/nuki_AABBCC99_door_sensor_battery_critical/config,
2023-07-08 13:27:13.3885|17656|62|TRACE|Hub|Server Message Not Consumed: SL3P_AABBCC99, homeassistant/binary_sensor/nuki_AABBCC99_keypad_battery_critical/config,
2023-07-08 13:27:13.4918|17656|14|TRACE|Hub|Server Message Not Consumed: SL3P_AABBCC99, homeassistant/button/nuki_AABBCC99_unlatch_button/config, {"~":“nuki/AABBCC99”,“avty_t”:"~/connected",“pl_avail”:“true”, “pl_not_avail”:“false”,“dev”:{“ids”:"[AABBCC99]",“mf”:“Nuki”,“name”:“Svarogus”,“mdl”:“Smart Lock 3.0 Pro”},“name”:“Svarogus Unlatch”,“uniq_id”:“AABBCC99_unlatch_button”,“cmd_t”:"~/lockAction",“pl_prs”:“3”}
2023-07-08 13:27:13.6958|17656|62|TRACE|Hub|Server Message Not Consumed: SL3P_AABBCC99, homeassistant/button/nuki_AABBCC99_lockngo_button/config, {"~":“nuki/AABBCC99”,“avty_t”:"~/connected",“pl_avail”:“true”, “pl_not_avail”:“false”,“dev”:{“ids”:"[AABBCC99]",“mf”:“Nuki”,“name”:“Svarogus”,“mdl”:“Smart Lock 3.0 Pro”},“name”:“Svarogus Lock ‘n’ Go”,“uniq_id”:“AABBCC99_lock_n_go_button”,“cmd_t”:"~/lockAction",“pl_prs”:“4”}
2023-07-08 13:27:13.7986|17656|14|TRACE|Hub|Server Message Not Consumed: SL3P_AABBCC99, homeassistant/button/nuki_AABBCC99_lock_n_go_unlatch/config, {"~":“nuki/AABBCC99”,“avty_t”:"~/connected",“pl_avail”:“true”, “pl_not_avail”:“false”,“dev”:{“ids”:"[AABBCC99]",“mf”:“Nuki”,“name”:“Svarogus”,“mdl”:“Smart Lock 3.0 Pro”},“name”:“Svarogus Lock ‘n’ Go with unlatch”,“uniq_id”:“AABBCC99_lock_n_go_unlatch_button”,“cmd_t”:"~/lockAction",“pl_prs”:“5”}
2023-07-08 13:27:13.8998|17656|54|TRACE|Hub|Server Message Not Consumed: SL3P_AABBCC99, nuki/AABBCC99/connected, true

– here I see it subscribes to lock and unlock actions
2023-07-08 13:27:13.8998|17656|61|TRACE|Hub|Client Subscribed: SL3P_AABBCC99, nuki/AABBCC99/lockAction
2023-07-08 13:27:13.8998|17656|60|TRACE|Hub|Client Subscribed: SL3P_AABBCC99, nuki/AABBCC99/lock
2023-07-08 13:27:13.9981|17656|62|TRACE|Hub|Client Subscribed: SL3P_AABBCC99, nuki/AABBCC99/unlock

– here different client send the command.
2023-07-08 13:27:45.7581|17656|68|TRACE|Hub|MQTT Client Publish: Topic = nuki/AABBCC99/unlock, Payload = true
2023-07-08 13:27:47.4382|17656|74|TRACE|Hub|MQTT Client Command: waiting…

– lock does nothing and reports connected, false
2023-07-08 13:27:48.2135|17656|81|TRACE|Hub|Server Message Not Consumed: SL3P_AABBCC99, nuki/AABBCC99/connected, false

Kind regards,

To answer your question, I haven’t yet seen a release for firmware with mqtt. These are Beta releases, due to the youth of the solution with integrated mqtt (I suppose).
It’s been a few months since I last followed them, so if there’s anything new, I’m interested too.
The latest doc I found is spec 1.4 for mqtt.

If I understand correctly, you have random behavior. You were able to control the lock via mqtt but at a certain point, when you send a lock or unlock, it disconnects. correct?

the mqtt broker has no tls, no acl. correct?

Is the smartlock’s wifi connection stable? if the lock doesn’t have access to the nuki server, it will disconnect (not related to lock/unlock, but it’s always a hint). :slight_smile:

Ok, so lets live with Beta for a while.

I would not call the behaviour random. Now it is 100% that it disconnects from broker after command. Yesterday I had a moment (15 mins) right after I calibrated the lock that everything worked as expected.

mqtt broker has no tls, no acl. (tls is not supported according spec.)

wifi is stable, lock is right next to my laptop on the table. wifi signal is -56 dBm.

“if the lock doesn’t have access to the nuki server, it will disconnect (not related to lock/unlock, but it’s always a hint).” - this makes no sense - I want MQTT exactly because I want to be disconnected from nuki server. What is it then good for?

Even if I didn’t add my nuki web credentials it keeps connected to my broker until first command.

when the lock connects to the network, the first thing it does is try to reach the server (ping or whatever, I don’t have the details). The mqtt connection is, in fact, intended to be independent of nuki but, as of today, it doesn’t seem to have a parameter to tell the lock to deny connection to the server. Maybe this is a feature to ask for. (I don’t have the details on this point, it’s a deduction linked to the doc and still seems to apply).

Do you have another machine that can run the broker? (rule out possible pc limitations).
I agree with you that if the topics and payloads are the same, it’s not the message that seems to be the cause of the problem.

I assume it’s mosquitto you’re using?
Does the lock reconnect after being disconnected and if so directly afterwards? If so, instability in the lock would be the most realistic.

Unfortunately, I don’t have any other suggestions at the moment.

ok, I will keep my nuki web account there. but I already tryed it, and didn’t help.

yes, I do have another PC, will give it a try, but I don’t think it will help. I mean instead of guessing I’d like to see some traces from the lock, if it is possible.

No, it is not mosquitto, I’ve programmed my own broker and running it successfully with Shelly switches.

Does the lock reconnect after being disconnected and if so directly afterwards? - No it takes some time < 1h (which is absurd by the way). I am usually not that patient and I reconnect it form app.

Thanks for suggestions anyway. I am looking for real technical support - without reading traces from the device it will always be guessing. I’d like to download and read the traces from the lock.

MQTT for the Smart Lock 3Pro is not beta anymore for some months now, stable firmware version provide MQTT.
And it is the same for apps if I remember correctly.

Nuki server is used to see if there is network connection, to be sure not to use a way which could be blocked by a firewall rule.
IMHO some other way could be used but it is the choice they made at Nuki.

If there is a so long delay, it means your smart lock is not disconnected from Nuki servers but only from your MQTT broker.
I also think one hour is too long and we might suggest to make it shorter. To reconnect your smart lock you could just turn it to change its state then it should reconnect to your broker to publish it, I hop it is not only the case of a cloud disconnection but you might try instead of reconfigure MQTT from the app which could avoid you loosing so much time.