I just tested the MQTT functionality of the Nuki lock. With the firmware 3.5.12 no Username and Password are send when the lock tries to connect to the broker.
Does anyone have a idea or solution for this problem?
You need to disable the debug mode if you use the provisioning of the Nuki App.
The debug mode is not enabled. I also tried to start and end the debug mode.
I have the exact same problem. No debug mode enabled.
Same issue! Still not able in FW 3.7 it always tries to establish a connection with no user and password. And that even fails to connect. I just see it in mqtt logging. Tried with IPhone, Android phones. Tested with different router. Did a factory reset nothing solved the issue. Even testen multiple MQTT broker.
How can I enable debugging to see what nuki does?
Maybe an issue with my ip range or how nuki checks it. 172.20.x.x
It checks private IP ranges. If your’s would not match, it would not try to connect at all.
Maybe this is the problem: MQTT only accepts passwords up to 32 chars
Password length is not an issue! The one I use is for test only and very short 
It looks like I am affected by the same issue. I tried to connect to a MQTT broker (mosquitto) in my local network without sustainable success.
I tested:
- Pairing with Android / iPhone
- Mosquitto installed via deb packages
- Mosquitto running in docker
- Mosquitto running on another machine
- Nuki connected to the same subnet as the broker
- Shorter MQTT credentials
As result, the lock behaves always the same … strange. On the first look there is a connection and initial messages are sent. But this state does not persists. After a while (cannot tell whether its minutes or hours) no more updates are sent. Commands (lock/unlock) via MQTT never worked. In debugging mode of the broker, I see that the lock never sends credentials. It always “authenticate” anonymously, no matter what I set in the app.
I reported that to Nuki almost 2 month ago. But the support just asked questions I already answered. In my opinion the MQTT feature has not even reached the beta stage there are still too many “edge” cases which has not been considered. There might be exact one setup in which the MQTT stuff work, but Nuki does not communicate how that should look like. Maybe a Home Assistant instance is required I don’t have?
It is really great that Nuki tries to make the lock open for local solutions and this was actually my the feature why I bought a Nuki. But the way how the bugs with MQTT are just ignored is very sad and disappointing.
1 Like
Why it is limited only to private IP range? I am running my own mqtt broker publicly on digital ocean and I really want to connect my nuki to public cloud and I am aware of all the risks it brings. I simply do want to manage it remotely not only from local network.
Is there any way how to allow whole IP range?
I had the same issue, but you can easily bridge a local MQTT broker to your MQTT broker in the cloud.
When (if) it will be available, you would also be able to cache local messages in case of temporary local network disconnection. This requires clean session and qos that are not yet available in Nuki configuration.
I even have the same IP address and suspect the same as you. I just posted my problem, see above
Hi everyone. I’m a new nuki user and pretty happy untill now. I seem to also have MQTT connection problems (Smart Lock 3 pro won’t connect).
what I tried:
- Because I had 172.168… I changed the IP-Range of my whole infrastructure, after reading this: MQTT API Specification v1.3 - #3 by GeminiServer
- Connecting to mosquitto version 2.0.15 running on my local NAS
- Connecting to HiveMQ running on my PC
- Connecting to HiveMQ instance running in the cloud
- tried different users, also user nuki with SHA256-hashed wifi-pw as password
usually I get error 8E in the app and the server says: Client SL3P_3XXXXXXX disconnected, not authorised.
Interestingly, when I change mosquitto to allow anonymous connections, I see one time
the nuki topics in MQTT Explorer, but the connection immediately closes:
1695068584: New connection from 172.20.X.X:52461 on port 1883.
1695068584: New client connected from 172.20.X.X:52461 as SL3P_3XXXXXXX (p2, c1, k300).
1695068587: Client SL3P_3XXXXXXX closed its connection.
I’m out of ideas, pretty sure it has to do something with the credentials (as others posted before). If I can try something else, please tell me 
1 Like
Maybe this helps: I can't connect to my mqtt broker with the Nuki - #3 by Juergen.
In addition if you own a FritzBox7590AX you might run into this problem: FRITZbox 7590 ax issue with Wi-Fi smart lock 3.0 pro - #84 by Juergen
It there any progress on this issue?
I did further investigation and made a network trace of the communication handshake between Nuki 3.0 Pro (firmware 3.7.7) and the MQTT broker (mosquitto). Since MQTT on port 1883 isn’t encrypted it is easy to decode. The trace shown in the screenshot is made during the “activation” with the Android app. All fields including username/password were set.
For no reason, the initial message of the Nuki lock does not include an username or password. Of cause, the connection request is denied because the broker does not permit anonymous connections. The broker is in the same IP subnet as the lock, therefore I do not see any reason why this should not work.
Can somebody with knowledge about the lock make a statement here? What else is required to activate MQTT support?
Thanks in advance!
Yes. We found something that could cause the connection problems with IP ranges in the 172.17.x and up range. There will be a fix included in the next beta update (for 3rd and 4th generation devices).
4 Likes
Also having this issue with Nuki 4. Firmware 4.0.31
Username and password are not recieved on the server.
Username and password are valid. Can connect with when with other mqtt clients.
Log on MQTT Server
1702928925: New connection from 10.0.0.226:60804 on port 1883.
1702928925: Client SL3P_******* disconnected, not authorised.
User and password only transmitted during connection phase.