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.
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…
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.
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.
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)?
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.
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.
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).
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
