Can you please DM me the detailed steps to reproduce the issue? Finding a bug is much easier if we can reproduce it by our own.
Reproducing the issue is quite easy:
- Mosquitto broker 2.0.17 (installed via Home Assistant Addon-Store)
- Configure user for nuki smartlock (let say username nuki)
- Connect nuki doorlock to mosquitto broker, using its ip address and username nuki
- Controlling doorlock via mqtt works fine
- After restarting the mqtt broker you wonāt be able to control the doorlock anymore
- In the nuke app mqtt broker is shown as disconnected (red cross)
- After waiting aprox. 1 hour, the doorlock reconnects to the broker, controlling the doorlock via mqtt works
- Removing the lockās battery will also force reconnecting to the mqtt broker
Thanks, but the question from @ianlockhead was specifically about the lock trying to connect without password. We could not reproduce this yet.
I want to chime in on this as well.
In my case, Nuki 3 pro is also not reconnecting its MQTT on its own. It remains offline in Nuki app with a Red Cross. As soon as I just tap the MQTT settings in the app and hit save, it immediately reconnects and turns to a green checkmark.
How can I help to fix it?
1 Like
I cannot confirm this behavior. The lock does remember the password, but the iOS app doesenāt:
When the lock gets disconnected, because of an broker restart, removing the battery or waiting for max 1 hour brings back the lock to the mqtt broker. This means, the lock is remembering the password. But when you try to connect the lock manually to the broker, using the app, you have to fill in the password manually, because the app doesenāt remember it.
I think this is just fine, because of security purposes.
But the root cause of my problem is, the lock waits an hour to reconnect to the broker.
As @Lukasss already mentioned, this behavior results, people getting locked out at this time.
Maybe it is suitable, the lock tries to reconnect every few minutes or make the reconnect timeout configurable, using the app.
Maybe another solution would be, using mqtt websocket connection to determine a broken connection immediately.
@Juergen thank you for your help!
Hi guys, I can confirm that the issue with not reconnecting the Nuki lock to MQTT broker after some type of broker outage (i.e. power outage, force restart of the docker server etc.) has been fixed on my side. I found out that the configuration of MQTT broker (Mosquitto docker in my case) has to be set with ālistenerā parameter and not āportā parameter which I had in the configuration file at time of the issue. So maybe the lock try to find and reconnect on defined IP and port (1883) but the MQTT broker must have correct config file to accept the reconnection on that listener. I figured out that issue because my Homebridge server warned me about incorrect configuration with āportā 1883 and not ālistenerā 1883. The MQTT server correctly work with āportā parameter but maybe accepted only forced connections and the automatic reconnections needs ālistenerā parameter. After fixing that in my MQTT config works everything like a charm. But I can confirm that Nuki tries to reconnect in ~55mins after MQTT server outage. It will be nice to shorten this interval to 5mins for example.
FYI @Juergen
Thank you! Iāll give it a try this evening. Gonna keep you informed 
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.
1 Like
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?
1 Like
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.