Looks like as if 172.16 is not recognized as a private Adress!! Can you please add
172.16.0.0 to 172.31.255.255
to the list please.
1 Like
All RFC1918 ranges are added. This is not your problem.
Maybe this helps: I can't connect to my mqtt broker with the Nuki - #3 by Juergen
Don’t work for me. Already at the installation, no connection was possible. Mqtt connect not possible
This also doesn’t help for me, my broker has no password.
But I’m also on a 172 network and can’t get it working.
Is there anything else to test or information we can supply?
I also requested access to the MQTT beta group, no idea if this is still active or used.
I’m also already on the nuki testflight beta program
edit:
I also tried running Mosquitto (newest version 2.0.18) in a docker container, on a plain VM and on my Macbook using homebrew.
All different IPs and different machines and OS type / versions.,
everytime the same error “Die Aktion konnte nicht ausgeführt werden. Bitte versuche es erneut.”
What’s interesting: There’s now a nuki topic n all 3 MQTT brokers I tried.
Which means the connection to MQTT worked at least for a short time (and it shouldn’t be a authentication problem, as the nuki wouldn’t be able to post data to the broker otherwise).
1 Like
Any chance to get logs from your MQTT Broker to see what the SL is doing and/or how far it is comming? It will log in and then pusblish some topics and subscribe to topics.
Btw: I have a 172.16.16.x network and the SL connects to MQTT without problems.
Thanks for the fast response. I will try get you some logs later. 
Hi Jürgen,
not sure if I completely understand the private message system of the forum, and whether I replied to myself today or if you can see the message. 
So you should have received 2 messages:
-
One yesterday about the connection to the Broker being still active even that the app shows the MQTT activation error (based on MQTT broker logs)
-
And another one from today, showing that I sometimes even receive lockactionevents in the broker without a successful MQTT activation in the app (but with a lot missing topics).
If you didn’t receive both messages, just tell me here.
Ok, I’m at the state again to say “the IP range is the root cause for the MQTT connection problems”.
Sorry Jürgen.
I did some very time consuming debugging today where I disconnected all repeaters and devices in the house from my Fritzbox and changed the IP range of the Fritzbox several times.
First, I started with disconnecting the other floors (with their repeaters) beside the basement where the Fritzbox is located.
Then I just connected the receiver next to the Nuki and shut down all other devices that connect to it.
So the only devices listed in the Fritzbox was my Macbook, my iPhone, the mesh repeater and the Nuki.
Then I rebootet all of them and checked the connection state of the Nuki.
After that I started a mosquitto broker on my Macbook in verbose mode to see incoming connections and messages.
It resulted in the known error message, even that a few topics was filled by the Nuki.
Knowing, that most (if not all) people that reported the same problem here in the forum were also on a 172.x.x.x network, I thought I try to change my ip range (as the kids were sleeping and my wife wan’t at home tonight, so nobody would kill me because of missing internet or smart home functions).
So I created a backup of my Fritzbox and changed the IP range from 172.17.2.x to 192.168.0.x
Then I restarted all connected devices (Fritzbox, Macbook, iPhone, Repeater, Nuki) again, starting with the Fritzbox and then the repeater.
I checked the connection state of the Nuki, started the MQTT broker on the Macbook and magically, the smartlock connected to the broker on the first try. 
I thought it might be related to changing the IP range to whatever and deleting all the known devices and fixed IPs.
So without restoring my Fritzbox backup, I changed the IP range back to 172.17.2.x
After that I repeated the steps above with disconnecting and restarting the devices in the same order.
Then I tried to connect to the restarted MQTT broker on my Macbook and it failed again. 
I restored my Fritzbox backup in the end, as I need a different and not-so-usual ip range in my network,
as I often need to connect through VPN from outside and from other countries to my home network.
And as you can’t reach devices in your VPN, if the remote network you’re connected to has the same IP-range, I have to avoid 192.168.0.x at home.
The end of the story:
I know that you have a test network running with 172.16.x.x, but it might be a nasty bug that doesn’t show up always.
So I hope to convince you, that it might be worth to check that again … 
Btw. I installed the beta on the smartlock earlier today and I’ve sent you a photo with the nuki id the last days as a direct message.
Not sure if you get detailed logs from the beta devices that might help …
1 Like
Hi Juergen,
my configuration is 172.20.0.0/24 and it does not work! Both the lock and the broker have 172.20.1.x IP addresses. When I try to connect it does not even try to. It just errors out. When I add a fake 192.168.x.x address it takes a while and errors out. When I take a public IP it behaves the same as when I use my local private subnet. It really looks like an issue in your setting for local IP address range.
I have now added an additional broker connected to another wifi router using 192.168.2.x and what should I say if connect right away without any issues!
Please test in your test environment the 172.20.0.0 255.255.254.0 setting and let me know if that works in your test environment, I assume you have one 
Did some additional testing on the same hardware where I was able to connect successfully.
172.17.0.0 with subnetmask 255.255.254.0 did not work!
172.17.1.0 with subnetmask 255.255.255.0 did not work!
172.16.1.0with subnetmask 255.255.255.0 WORKS!
172.16.1.0with subnetmask 255.255.254.0 WORKS!
My conclusion! Your local network identification filter has a bug!
It only accepts 172.16.x.x and that is not like RFC1918 that you mentioned earlier. Please, please, please check the code and test in 172.16+ subnets!
I reported this 21st of March and it is not fixed and has not been tested.
Thanks,
Devid
1 Like
I also reconfigured my whole network in the meantime from 172.17.2.x to 192.168.24.x including a lot SmartHome Rules and manually configured IPs …
MQTT connects without a problem now.
That would take me a month, the product should just work the way they described it
I am also in the programming space and typically you have test cases for that 
3 Likes
This problem is apparently known, but no help is available. I still can’t add my lock via mqtt. It is probably a UI error.
We’ve been able to identify the problem behind the issue. It has been fixed in yesterdays 4.0.31 release for Smart Lock 4th gen and will be fixed in the next (beta) release for 3rd gen devices too.
1 Like
Works on 4 pro now thanks!
Wow, that’s good news. I’m really looking forward to the new firmware or beta
@Juergen Are you saying that the disconnection problem of Nuki 3 Pro will be solved by next Beta Fw?
Hi there, the MQTT-Support was the only reason to choose the nuki 3 Pro. Would be great to see the new beta FW in the next few days.
I think the nuki is a great product, but for the mainstream-no-Tech-People only. If you build your own Homeautomation, you want to change IPs to static, use non-standard IP-Ranges and eventually run your system without cloud-connected devices. All this seems to be impossible at the moment with the Nuki
1 Like
GitHub - technyon/nuki_hub: Use an ESP32 as a Hub between a NUKI Lock and your smarthome. fixed my problems and works like expected until my 3.0 Pro does this too, maybe…
1 Like