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
1 Like
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?
1 Like
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.
1 Like
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? 
1 Like
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.
1 Like
Yes, because it was an intended functionality. E.g. to save energy, when there is no cloud server available. Or to properly reset the WiFi module and reestablish a working LAN & WAN link if something is stuck. This was all developed long time before the work on the MQTT API started.
Yes, because it was an intended functionality which did not work in this software version of the bridge. i.e. it was a bug.
I won’t continue this discussion, because it does not bring any additional value. Whether it’s deemed bug or feature does not bring the functionality to live. Writing the same thing in every other thread also not.
1 Like
Right. So it is or was a feature, which turned into a bug now.
You can keep it as a (formerly intended) feature or accept it as an (actual) bug and fix it.
But telling us, that it’s neither a bug nor a feature, but it would be a (new) feature to fix this annoying bug because it is no feature (anymore), is a little bit schizophrenic. 
Thanks. Exactly what I’m talking about.
It’s the same now, cause you said, that the (old) behavior isn’t an intended feature in the actual software version with MQTT support anymore. So it has to be a bug now.
1 Like
So can we expect a solution?
When approximately?
Despite the previous explanation… right now my Nuki 3 Pro just disconnected from my Home Assistant system without any connectivity issue (before I was assuming that the connection was lost during my HA system restart… but this time it disconnected without any HA restart)…
So it looks it disconnect even without any
connection/accessibility issue to cloud server…
2 Likes
Perhaps there is too much focus on the distinction between feature and bug.
Multiple things can be true at the same time.
MQTT and other local APIs where not always supported, it was implemented at some stage.
However at the same time people may by buying the product now specifically due to MQTT support.
Development and human resources are not infinite, so managing them and prioritizing is something every company must do.
However at the same time people will be surprised even when a perceived goal of the product is not met, and then classified as a feature instead of a bug.
Perhaps @Juergen could comment on whether this change request (feature or bug) would make sense at all for this product or if this is not going to happen.
I feel like people read between non existent lines here.
1 Like
I’m totally with you @lukastribus on so many points.
Feature or bug should not be discussed that much, however the willingness to implement/fix should be clarified by Nuki.
I also bought it because of the support of MQTT and was really astonished and disappointed by the fact it requires an access to Internet (something that you discover too late)
We should not however minimise the service provided by Nuki : being connected to the internet brings a great added value, but this should remain a choice and not something we have to accept.
3 Likes
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!
1 Like
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.
3 Likes
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)?
2 Likes