The mqtt connection problem in the private network with the ip: 172.20… has been fixed in the current beta version 3.8.2. It really took a long time. Thanks anyway.
Guys… it seems that this FW did the job…
I don’t want (again) to sing victory too soon… but for now (after the FW update of yesterday) the MQTT disconnection problem is not happening anymore…
In the HA logs (Mosquitto MQTT) I see that it disconnect but then it reconnects… which is what it should do without manually enter again credentials in the APP…
If this is confirmed in the next hours/days I am very very happy…
We waited so long… but … at the end the solution came out…
3 Likes
Does this update also apply to the new generation of locks? (Normal/pro 4th gen.)
Unfortunately I have to say differently… as it is not totally solved…
It was definitely keeping the connection for longer time with this new beta FW … but this morning I found it again disconnected!
:◇
When I tried to manually reconnect it (again the credentials) I found something new: while I was getting the usual 8E error (many times, at each attempt) I tried to manually open the door with the button and immediately it connected without error…
At this point I am quite sure that the problems (disconnection without reconnection, error 8E while manually reconfiguring MQTT) has to do with Power Management… it’s like the communication goes in “sleep mode” when the Lock is not used for many hours (like during the night)…
If this is the right assumption … maybe developers can solve it?
1 Like
Yes, there was also a beta released for the 4th gen locks (4.0.34) which contains the same changes. A thread with release notes for 4th gen devices will follow soon.
1 Like
I installed the latest beta yesterday. The connection to 172.23.0.0/16 works now.
But it disconnects and reconnects periodically the MQTT connection. It seems to lose and reconnect the wifi connection too, but less.
2023-12-08 07:35:47: Client SL3P_3761947C closed its connection.
2023-12-08 07:36:30: New connection from 172.23.107.29:52497 on port 1883.
2023-12-08 07:36:30: New client connected from 172.23.107.29:52497 as SL3P_3761947C (p2, c1, k300, u'nuki').
2023-12-08 08:09:12: Client SL3P_3761947C closed its connection.
2023-12-08 08:10:06: New connection from 172.23.107.29:52499 on port 1883.
2023-12-08 08:10:06: New client connected from 172.23.107.29:52499 as SL3P_3761947C (p2, c1, k300, u'nuki').
2023-12-08 08:41:25: Client SL3P_3761947C closed its connection.
2023-12-08 08:41:39: New connection from 172.23.107.29:52500 on port 1883.
2023-12-08 08:41:39: New client connected from 172.23.107.29:52500 as SL3P_3761947C (p2, c1, k300, u'nuki').
And it’s not because of the wifi strength. The access point is 3 - 5 m away without a wall or something else.
If not already done, you can try to set the Smart Lock > Settings > Features & Configuration > Battery > Energy-saving mode to “Medium”.
Very similar situation in my case (my IP is in the typical class of 192.168.1.x) where it disconnect regularly and it reconnects (now with latest FW… before it was NOT reconnecting) typically after few seconds but in some case it takes much longer… see below at 08:45 where it did reconnect after over 20 minutes… and I am not sure if it did reconnect because I manually used the lock in that disconnect timeframe (my impression is that the device goes in some kind of “sleep mode” and this cause the problem, but I am speculating)…
Also in my case the wifi signal strength is NOT an issue as my Lock is at less then 3mt from the router with NO obstacles in the middle…
As @Juergen suggested I already did setup the battery Energy-saving mode to “Medium”
Unless this is considered by Nuki as “normal behavior” (for me it’s not) that it disconnect regularly and then it reconnects (not always immediately… and generating sometimes functionality interruption) I would like to ask/suggest to @Juergen to “use” someone of us (I am sure that there is some people available to do that, starting by me) to generate some useful logs for your developers to deeply analyze and solve once for all (at root cause) the problem, by enabling (I am sure it is possible) some kind of low level debug mode…
You just need to give us (privately of you don’t to spread up too much these debug information) some instructions and for sure we will cooperate with you to provide some usefull more detailed logs
@Juergen what do you think about?
1 Like
I’ll try, but it says it’s about Bluetooth and I’m using Wi-Fi.
Edit:
It doesn’t help but make it worse. Now it reconnects every 15 minutes or less. (And now only disconnects and doesn’t reconnect.)
So I’m waiting for the next update. Maybe then the disconnect problems will be fixed. The connection problem to private IPs is solved. Thanks for that.
What is the new delay to reconnect automatically if I E.G. reboot the machine where Mosquitto is running?
I had to reboot after Debian update, more than 20 minutes after the smart lock has still not reconnected to MQTT, even if there were some activity on the smart lock itself, it has been unlocked and locked a couple of time.
EDIT: it is now connected again, but not reconnecting even when state has changed is not really reliable in my opinion, I understood the smart lock should reconnect in the case of physical activity but it does not look to be the case for now or there is a bug.
EDIT2: I also observed perturbations to use the smart lock using smart phone (Android) without Bluetooth durring this time.
Smart lock state was very slow to be displayed and some (un)lock operations were not successful.
1 Like
Hi,
I wanted to bring to your attention that there seems to be an issue with the WiFi in the new Nuki 4.0 Pro.
A friend of mine, who has multiple Airbnb apartments, bought a 4.0 Pro and loses the WiFi connection regularly when used in combination with a Fritzbox. At the same time, the other 15 Nuki 3.0 Pros run normally.
I have the same issue at my home. I bought a Nuki 4.0 Pro with a Telekom Speedport 4 and experience the same regular issues with lost WiFi. After manually opening via key or Bluetooth connection, the WiFi works again until it breaks again.
We both run the latest stable firmware.
Once the SL has detected that the MQTT connection is broken (which can take up to 5min) it starts with 5s, 10s, 20s, … reconnect tries until it reaches the maximum interval of 1h.
That was a specific problem in your case that was not related to the MQTT retry mechanism. We’re looking into it.
1 Like
We appreciate any feedback, but this is a beta tester forum. If you want to contribute, please sign up for the beta and report the problems/findings in the 4th gen beta thread.
1 Like
This is not feasible because there is no single “root cause” to solve. The Smart Lock requires certain power saving mechanisms to work (otherwise the batteries would be empty within a few days). There are millions of different combinations of routers, home lan/wifi settings, internet providers out there. Our goal is to work with most of them, but we’re also realistic and know that it will never work perfectly fine with all of them. Some will always work better (= more stable and lower power consumption) than others. Debugging one single setup does not solve the problem of all others.
1 Like
Ok … clear…
I confirm that in my case now it is ALWAYS reconnecting… even if it disconnects regularly with apparently no reason (or the reason is the power mechanism)…
For me now it is acceptable…
Thanks for your effort
To get valid results and to tell if it’s a Wi-Fi or MQTT Problem, I activated a ping from Home Assistant, every 10 seconds.
An hour later I changed to uptime kurma, to get better statistics.
And now, there haven’t been any disconnects since then. Two disconnects around 3 a.m. for 1 second. But this could have been the Wi-Fi channel change too.
I’m not sure if it’s the Wi-Fi connection itself or in some way Nukis Wi-Fi connection, which is kept alive by this ping. Or maybe there was another change/update I haven’t recognized (don’t think so).
But for the last 10 - 12 hours it was stable. And that is a really big change since it disconnected at least 1-3 times an hour before.
@spanzetta maybe try also a ping to see if this fixes your disconnect problems. HA ping Integration sends a ping every 30 seconds, which should be enough.
I’m using an SDN with TP-Link Omada. The nuki is connected to an EAP225. But other devices don’t show this disconnect behavior or I don’t recognize it, cause it doesn’t matter so much to be connected constantly without any delay.
But the ESP Bridge was connected to the same EAP and had only the Bluetooth delay, I think. 
Never mind. I’m really happy, at the moment. Maybe a ping could be a workaround or at least a hint of a solution.
Update:
It worked for more than 24 hours without a reconnect. Then I changed the ping to 60 seconds and got a downtime again.
Now, with a ping every 30 seconds, it kept alive. Not sure how this is draining the battery, but it works. 
1 Like
Since yesterday morning, I cannot use the Android app to use my smart lock if not connected to the smart lock by Blue Tooth.
MQTT works correctly, only remote actions using the Nuki app are not possible.
I tried to unplug/plug the battery with no change.
When I check in the app in integration section then Nuki Web near my smart lock it shows the smart lock is connected to my Nuki Web account.
Is someone facing the same issue?
EDIT: it becomes available again two days ago but this morning it occured again.
It looks cold weather is the only common point I see but I don’t remind I had the same issue last year.
I also had to re calibrate my smart lock this morning, it looks it occurs more often.
With this latest beta FW auto unlock feature stopped working…
Anyone else with same problem?
Nop.
But I notice some strangeness E.G. smart not calibrated anymore sometimes and it is fixed when unplugging and plugging again the battery.
I had not this with previous firmware but difficult to know if it is this version, even if last time it occurred, temperature was not so cold, 8°C outside just behind the door.