MQTT Automatic reconnect, force publishing

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

1 Like

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… :slight_smile:
I’ll keep you posted once I am sure the problem is really solved…

UPDATE
I singed victory to soon… :frowning:
Problem is still there and I am struggling to get some concrete support…
Really sad

2 Likes

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 ?
:wink:

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

2 Likes

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:

  1. Is it possible to know what does it mean 8E error?
  2. Is there someone else in the same situation?
1 Like

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.

1 Like

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

1 Like

Todays 3.8.2 beta firmware contains - next to some other improvements - a reworked reconnect mechanism which does retries sooner and more often:

3 Likes

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.

Hi, has this issue been resolved? I found this thread, but I cannot write an answer there.

I have a nuki 4.0 pro since a few days and mqtt was working fine until it just disconnected (all related entities in homeassistant were “not available”) for no reason yesterday afternoon and did not reconnect “by itself” for about 3 hours. I also don’t know what caused it to reconnect, I think there was no interaction involved. More than 20 other mqtt devices were communication fine during that time and I was able to access the nuki via bluetooth and via wlan, the connection tab in the app was showing green lines from the phone via server via wlan to the lock, so I guess servers were online. I didn’t know about the status page, next time I will check it.

Any advice on how to troubleshoot this kind of behaviour? Should the nuki send LWT or can that be configured? It would at least be nice to automate a warning message…

Same issue as Arno here: suddenly MQTT info is ‘lost’. No connection in HA anymore, always have to resave the MQTT credentials in de Nuki app.

After that, only a matter of minutes later, the connection is lost again.

Very frustrating, and the chat doesn’t want to help, because of “MQTT related”.

More info:

  • firmware 3.9.5
  • mosquitto broker 6.4.1 in HA
1 Like

Same thing happening here also, Nuki pro 3 getting disconnected from MQTT server (provided through home assistant)

Door cannot be opened, people are calling me, and need every time to perform a reconnect of the MQTT from the Nuki app re-adding the password (such a bad UX)

I am dealing with such issue for almost a year and no fixes came so far

I am thinking on switching over the new Swithbot door opener, they know how to design APIs and support works

This is not necessary.
If you do not change any other parameters (hostname, username) you do not need to provide the password. The Smart Lock will remember it.

Thanks Marc; from a user standpoint, that was unclear but certainly worth knowing and highly welcome!

1 Like

Is getting worse week after week, now it disconnects from 3 to 4 times a week with firmware 3.9.5. It was disconnecting once every two months before and the even worse thing is that it is incapable of reconnecting automatically: it appears as connected but not responsive to commands! You need to enter the app and reconnect again. Every time.

Is there a fix planned? Next time I am going to smash it with an hammer.

1 Like

Hello,

i recently bought a Nuki Lock Pro 4.0 with Firmware 4.2.8 and have the same issue. If I reboot my HA Server which is hosting the MQTT server, the Nuke Lock Pro never reconnects until I open the App and hit “Save” in the MQTT Settings.

1 Like

I have the same problem also with my Nuki Lock 3 Pro and it seems easy to reproduce. Simple turn off the MQTT server for more than 5 minutes and then the Nuki Lock is not able to reconnect to the MQTT server.

1 Like