Yes, but it is a potential cause for errors and not well solved from a UI perspective.
Topic is already noted.
This depends on the type of outage. For some outages there is a much quicker reconnect already in place (e.g. wifi or internet connectivity drop) and even for the MQTT connection drop the lock already tries to immediately reconnect. Looks like this does not work so well, maybe because the broker is still down at that time. Topic is also already noted and in our backlog.
Hi @ianlockhead,
changing from „port“ to „listener“ did not do the trick for me. Maybe you can provide your mosquitto.conf file?
thank you!
oliver
Hi @ianlockhead,
sorry for my late reply. Unfortunately your solution did not work for me. My mqtt.conf did already include “listen” instead of “port”. Your config is pretty simular to mine.
Also have listener in mosquitto.conf, also not working for me.
New nuki 3.0 pro owner, had a v2 for years, was excited to use mqtt and inbuilt wifi, but mqtt connection is dropping and not re-connecting. I can go into Nuki app and re-enable the mqtt connection and it then works again.
I don’t think reconnection after an hour is great, particularly - understand battery constraints but some will be using with the battery unit plugged in like me.
I have username and no password configured, happy to help test if that would be useful.
I confirm this behavior with my Home Assistant setup (currently I have the latest 2023.10.4).
After some time (variable… it can be few hours up to some days) need to reconnect MQTT by typing again password and save … before doing that I see the red cross.
Will it be fixed?
Thanks
PS I have Nuki 3 Pro with 3.7.7 firmware
can anyone else confirm?
confirmed 
Thanks @nics … can we expect a solution anytime soon?
I have exactly the same as Oliver Eiber describes (Homeassistant, Mosquito Broker, restarting Homeassiatant and/or MQTT broker causes MQTT disconnected NUKI with red cross for some time, up to an hour).
Is there a way (without physically removing the battery of the NUKI) to get MQTT to reconnect again, without waiting an hour?
Unlocking/locking the lock should also reconnect except if I miss-understood, no need to touch the battery.
Or is it only the case for wi-fi?
So are you saying that this is a kind of “normal behaviour” ??
And why with Amazon Ring MQTT Integration this problem never happens?
IMHO this is a Nuki bug that should be solved
I don’t see what make you asking that… 
I personally only suggested something to try to avoid touching the battery, as a Nuki user to help other Nuki user, nothing more.
For nuki, it’s a feature, that the 3.0 Pro disconnects its WIFI connection if your internet connection or their servers are down, so you can’t use it locally anymore.
Cause of that I changed to the ESP32 - nuki Hub by @technyon and haven’t had any problems anymore.
Maybe this could be a solution for you too.
Thanks for the confirm… I was suspecting this… at least now we have the confirm
This is not true. No one ever said that.
Hmm… But you said:
See Local MQTT connection fails there is no connectivity to Nuki Cloud Servers - #2 by Juergen
If a feature request is needed to change the behavior, it has to be a feature the way it works actually. Cause if it is a bug, why a feature request should be needed to fix it? 
—
To be fair. In 2020 the same behavior of the internet bridge was considered a bug and fixed without a feature request.
So I can’t understand what’s the difference this time and why you need a feature request voted for to (maybe) fix a bug. 
To clarify. Is the Wi-Fi disconnect of the 3.0
Pro without a (stable) internet connection/accessibility of your cloud servers a bug that will be fixed (hopefully soon) or a feature and for changing this behavior a (high-voted) feature request is needed, @Juergen?
When we started out with the development of the MQTT API this was the goal:
There is nowhere an intependent mode as requirement mentioned in which the MQTT API still has to work even when someone isolates the Smart Lock from the internet or that there is a switch to turn off the Smart Locks server connection. That’s why adding it is a feature request and not a bug.
So if my local control can’t work without a (manufacture-controlled) cloud server connection it’s no bug?
In which world this could be called local control if it depends on the cloud?! Especially cause Connecting to remote MQTT servers is no goal of your mqtt function, as you’ve written in the category description.
And please tell me if I’m wrong. But to constantly check the connection to your cloud servers and disconnect wifi if no connection was possible was coded as a feature, or wasn’t it?
The bridge after fixing the bug in 2020 is checking the connection to the (local) gateway, if I’m not mistaken.
In other words. Why was this feature coded, if it’s no feature? 
A bug is an unintended software error. A feature is an intended functionality . Bugs disrupt the user experience and appear under specific conditions. Features should enhance the user experience.
Bug vs feature: what’s the difference? (guide + examples) - Canny Blog.
Is the wifi disconnect without a cloud connection an intended functionality (for nuki)? It’s obviously disrupting the user experience.
