The difference between a feature and a bug is, that a bug should be fixed fast. A feature is something, that may be implemented and maybe not but won’t discussed by nuki before.
And apart from the wording. A local control depending on a cloud server connection is useless. Especially if it isn’t reliable even if there is a cloud connection!
Yes, of course it would make sense. There is no strategic reason not to have it. We also understand and see the need, but unfortunately this is not an easy change but a rather massive rewrite of the whole connect / reconnect logic which needs thorough testing too. As you correctly pointed out human resources are not infinite and as we love our very technically aware users, they do not represent more than a single digit percentage of our whole user base (The ones that have a problem that the Smart Lock still synchronises its time and loads firmware updates from Nuki servers is again a subset of them).
Therefore i keep reiterating to vote for the corresponding feature request. The more votes the more visibility. And there is a reason why there is one vote per user. Writing the same stuff 100s of times across all possible threads by the same few people here in the forum does not increase the awareness. It just polutes the forum and disctracts.
I see that the discussion is about cloud connection … or not…
In my case, the NUKI 3 Pro MQTT is pointing “locally” to my HA server (with internal IP address)… and anyway it disconnects after some time… and it never reconnects automatically until you manually type again the password in the Nuki APP (MQTT settings)
Are we sure we are talking about the same issue (or, better, the same bug)?
No because of this:
In order to move forward with your problem: Please join the beta fw tester group and DM me the Nuki ID of your Smart Lock once you have the beta running.
I had a very strange issue today, not sure if it is related or not.
It looks I had a disconnection from Nuki Web, not sure why as Internet connection and Wi-Fi are OK
So the smart lock disconnected from MQTT, as expected.
But it reconnected, then disconnected again without reconnecting anymore until I plug the battery out and in the smart lock again.
My MQTT broker, Mosquitto, did not stop.
Even unlocking/relocking my smart lock did not make it reconnect to my MQTT broker.
There’s a Cloud outage, also see:
Thanks a lot for this reply and the insights.
@everyone affected by the outage today, here’s the right place to vote: 
You’re right. As seen today, it’s definitely a bug if I can’t use my lock locally, cause the (not needed) manufacturer cloud server are down.
Hi Jürgen,
I’ve sent a PM to you asking about joining Beta FW program…
Waiting your news
Thanks
Joined… I will see if something changes with new FW… when it will arrive
Just updated with Beta FW (ver 3.8.1) and the problem of disconnecting MQTT just happened now - after about 2 hours with no reason (no cloud disconnection, no HA reboot/connectivity problem)…
So the problem is still there…
UPDATE: It’s even worst… now it doesn’t accept anymore to connect… even if I put again the data (as I was doing in the past to reconnect) it doesn’t reconnect and gives a generic error
So now my MQTT connection is totally broken!
2nd UPDATE: now it always gives error 8E… I suspect that now the syntax for host name has changed… isn’t it?
3rd UPDATE: after some time I was able to login again with usual syntax… so it was a temporary problem… but… why???
4th UPDATE: and after few hours again disconnected… totally unreliable
5th UPDATE: Here is some HA logs that could help to identify the issue…
2023-11-09 18:50:33: New connection from 172.30.32.2:58296 on port 1883.
2023-11-09 18:50:33: Client closed its connection.
2023-11-09 18:52:24: Client 17EM6gXHNr3gNIKNd5sAEc has exceeded timeout, disconnecting.
2023-11-09 18:52:33: New connection from 172.30.32.2:49014 on port 1883.
2023-11-09 18:52:33: Client closed its connection.
2023-11-09 18:52:42: New connection from 172.30.32.1:52811 on port 1883.
2023-11-09 18:52:42: New client connected from 172.30.32.1:52811 as 17EM6gXHNr3gNIKNd5sAEc (p2, c1, k60, u’mosquitto’).
2023-11-09 18:54:35: New connection from 172.30.32.2:60054 on port 1883.
2023-11-09 18:54:35: Client closed its connection.
2023-11-09 18:54:48: Client 17EM6gXHNr3gNIKNd5sAEc has exceeded timeout, disconnecting.
2023-11-09 18:56:35: New connection from 172.30.32.2:45248 on port 1883.
2023-11-09 18:56:35: Client closed its connection.
2023-11-09 18:57:11: New connection from 172.30.32.1:50623 on port 1883.
2023-11-09 18:57:11: New client connected from 172.30.32.1:50623 as 0PxVAMFEcTwlusTLIESQCk (p2, c1, k60, u’mosquitto’).
2023-11-09 18:58:39: New connection from 172.30.32.2:39834 on port 1883.
2023-11-09 18:58:40: Client closed its connection.
2023-11-09 19:00:41: New connection from 172.30.32.2:50292 on port 1883.
2023-11-09 19:00:41: Client closed its connection.
2023-11-09 19:02:44: New connection from 172.30.32.2:58798 on port 1883.
2023-11-09 19:02:44: Client closed its connection.
2023-11-09 19:03:51: Saving in-memory database to /data//mosquitto.db.
2023-11-09 19:04:46: New connection from 172.30.32.2:57944 on port 1883.
2023-11-09 19:04:46: Client closed its connection.
2023-11-09 19:06:46: New connection from 172.30.32.2:58220 on port 1883.
2023-11-09 19:06:47: Client closed its connection.
2023-11-09 19:08:47: New connection from 172.30.32.2:53110 on port 1883.
2023-11-09 19:08:47: Client closed its connection.
2023-11-09 19:10:47: New connection from 172.30.32.2:51586 on port 1883.
2023-11-09 19:10:47: Client closed its connection.
2023-11-09 19:12:47: New connection from 172.30.32.2:55686 on port 1883.
2023-11-09 19:12:47: Client closed its connection.
2023-11-09 19:14:47: New connection from 172.30.32.2:44076 on port 1883.
2023-11-09 19:14:47: Client closed its connection.
2023-11-09 19:16:47: New connection from 172.30.32.2:37672 on port 1883.
2023-11-09 19:16:47: Client closed its connection.
2023-11-09 19:18:47: New connection from 172.30.32.2:47146 on port 1883.
2023-11-09 19:18:47: Client closed its connection.
2023-11-09 19:20:47: New connection from 172.30.32.2:37738 on port 1883.
2023-11-09 19:20:48: Client closed its connection.
2023-11-09 19:22:48: New connection from 172.30.32.2:54116 on port 1883.
2023-11-09 19:22:48: Client closed its connection.
2023-11-09 19:24:48: New connection from 172.30.32.2:42308 on port 1883.
2023-11-09 19:24:48: Client closed its connection.
2023-11-09 19:25:42: Client SL3P_36E3866C has exceeded timeout, disconnecting.
2023-11-09 19:26:48: New connection from 172.30.32.2:59024 on port 1883.
2023-11-09 19:26:48: Client closed its connection.
2023-11-09 19:28:50: New connection from 172.30.32.2:56986 on port 1883.
2023-11-09 19:28:51: Client closed its connection.
UPDATE
It seems the solution arrived… 
I’ll keep you posted once I am sure the problem is really solved…
UPDATE
I singed victory to soon… 
Problem is still there and I am struggling to get some concrete support…
Really sad
I have the exact same problem. For a few days, my Nuki lock status was not available in home assistant (it’s integrated thanks to MQTT).
I’ve removed it on both home assistant and the Nuki app. Now I can’t connect to home assistant’s mqtt broker anymore, I always get error 85.
It’s worked like a charm for several months but is now unusable for me, even though I haven’t changed anything in my setup, besides the usually flawless home assistant updates.
Maybe it’s error 8E ?
No, I’ve re-tested, and it is error 85 indeed and it’s another error. Sorry for the noise, it was another issue in my case (the SL3 Pro could not re-connect to the wifi, and that was the root cause).
Ok so there is more then one problem with MQTT…
I am so negatively surprised that Nuki is totally ignoring these issues not providing any kind of even basic support…
Maybe we should start making noise with some more visible communication channels?
EDIT: it seems that they are now only taking care to provide some support to the new just released Nuki 4… forgetting that there are many Nuki 3 users out there
It is now 2 days that it doesn’t reconnect at all … NEVER!
MQTT always fails to connect to my HA system… always 8E error
Questions:
I confirm there is really an issue with automatic reconnect.
I had to reboot my Odroid N2+ to upgrade Armbian to 23.11 for more than three hours now and my smart lock still not reconnected.
Manually moving the ring does not change anything, changing the state with smart phone also does not change anything.
I had to unplug then plug the powerpack again to allow the smart lock to reconnect to my MQTT broker.
Fortunately not the same as @spanzetta but it is really a regression.
Hi @Nardol,
Thanks for sharing your experience…
In my case I did never tried to unplug power of my Smart Lock to get MQTT working again … for me it is not an option
I really hope that Nuki developers will be able to fix the issue asap
Thanks
Todays 3.8.2 beta firmware contains - next to some other improvements - a reworked reconnect mechanism which does retries sooner and more often:
Nice. Would be perfect if smart lock check MQTT connection and reconnect in case of state change I.E. turning the ring, press the button or (un)lock/open using the Nuki app or other remote solution.
Yesterday I had to reboot my Odroid where Mosquitto runs and my SL3P reconnected after a little more than 20 minutes which is sooner for sure, but in this interval we unlocked, opened the door and locked twice and the smart lock did not reconnect which mean missed events in Home Assistant.