1 = “Manual” in all other API specs that use trigger.
Most likely a relict from early beta testing of the function where it was not clear whether a manual lock action by turning the key or the knob would trigger such an event at all. Thanks. Will fix it in the spec.
hallo Jürgen,
thanks for update. sorry, that I came so late to participate on testing/debugging/proposing on the MQTT implementation.
I use for my home automation the mosquitto/nodered/influxdb/grafana stack, lot of my devices are running Tasmota FW, integration with Ikea Tradfri, Google Home (directly or via SmartNora)
/MfG
ZoloN
I’m using MQTT on my smart lock pro 3.0 locks since it was added as a feature in firmware 3.5.11. It’s connected to my Mosquitto on my Raspberry pi device, to connect to Openhab.
I notice when I restart my router / disconnect the netwerk to the smartlock, The lock doesn’t reconnect to MQTT. I own 2 locks, but it looks random.Sometimes the front door lock isn’t connected anymore after router restart, sometimes the backdoor lock isn’t connected anymore to MQTT. Problem can be resolved by removing the batterypack and inserting it again. I give it several hours to reconnect but unfortunate it doesn’t.
Could this be a bug and is there a way to check the log’s from the lock why it doesn’t connect to MQTT?
After about 4 to 5 hours, the lock is suddenly connected. So i’m curious if this is intentional. And still curious if I could check some logging somewhere.
I use a smart lock pro with firmware 3.5.11. When I restart the mqtt broker, the lock reconnects within short but somehow it won’t react to commands via mqtt after that.
The current state gets updated, but I can’t issue any commands as they are ignored by the lock.
Everything works fine after restarting wifi.
App betas with MQTT provisioning support have started to roll out:
If you participated in the MQTT beta already, please turn off debug mode of the Smart Lock prior to provisioning MQTT through the App.
Works perfectly for me.
Can MDNS/DNS host name be used or is it only enabled for hard-coded MQTT connection?
Because the field name is “Host name” I suppose it is possible almost for DNS name but I prefer to be sure in the case I would have to switch from IP to host name for any reason.
.local domains will be treated as MDNS domains and will be resolved as such. All other domains use standard DNS.
This approach can lead to some troubles if you don’t distinguish between “mqtt.local” and “mqtt.<< domain >>. local”. Lot of companies, and not only, use “.local” as TLD for their internal DNS/AD domain for separation from internet.
/MfG
ZoloN
Which is wrong as .local is reserved special-use domain name for multicast DNS and should not be resolved using standard DNS.
I’m seeying strange behaviour on the lockActionEvent after replacing my lock.
I’m parsing this event in Home Assistant to identify which user or system performed which action. This was always working fine. But I had to replace my Nuki SL3 Pro due to a mechanical failure. After setting up the new lock in exactly the same way it now always reports 0 on the CodeID parameter (which is unknown), even when a defined / authorized keypad code was used to open the lock. On my previous lock it always reported a specific code based on which keypad code was used.
So my question, is this a bug that was introduced in the MQTT implementation or is it something specific to my refreshed setup. Either way, how can I fix it?
Yes and no. Look here: .local - Wikipedia
Lot of companies have .local as their internal TLD and to change this is connected with lot of effort. So, even when not suggested anymore, is still (and will remain) in use
/MfG
ZoloN
Thanks for reporting. We’ll have a look at it. Could be that adding another code might temporaryily fix it (i.e. it could be that the codeid index starts at 0 for the first code).
Thanx, seems spot on. Already had a code for guests which was created after our famliy code which had ID 1 and after testing did return a proper value for CodeID. Creating another code added it with ID 2.
hallo Jürgen,
do you have any news?
/MfG
ZoloN
Yes, problem is identified and will be fixed in an upcoming firmware update (most likely 3.6.2).
Which is not up to Nuki to solve.
it depends. just read the wikipedia article again, (please note the difference between “name ending with .local” and “domain name ending…”) or look into the RFC 6762 Chapter 3:
this document allows any computer user to
elect to give their computers link-local Multicast DNS host names of
the form: "single-dns-label.local."
that means, “mqtt.local” and “mqtt” should be resolved via mDNS exclusively, but “mqtt.mydomain.local” via traditional DNS query.
rule of thumb: if it ends with “local” and there is more than one dot, it’s not mDNS name 
/MfG
ZoloN
Hey there,
I own a Nuki 2.0 and would buy ne Nuki 3.0 Pro. Is the MQTT API usable without internet? So it’s okay to block the connection in my router?
Thanks 