No, no wifi disconnection.
To the same network I have connected 56 other devices of which 17 are under MQTT network.
No other devices disconnected. Only NUKI ( and this thing repeats at least once a day).
I think at this point, after all these reports, it is time to stop blaming the WiFI connection.
The NUKI firmware has problems handling MQTT keep alive calls.
Damn it’s not complicated.
The firmware has to send a response to the server every few seconds, if it doesn’t the MQTT server flags you as offline and kills your session.
Another big problem is that after receiving any disconnection (it can happen, it causes problems with the WIFi or the MQTT server) , Nuki has to RESET the connection and send a new negotiation.
And this thing is NOT done.
P.S
Vittorio no problem with you…
And that here I see that for a simple matter instead of going forward we go backward.
Hey Elia, no problem! I agree with you on much of what you say. My network topology is very similar to yours (same number of devices, many of them connected to mosquitto). What I did, in my “debugging” phases, was to cross-reference the mqtt broker logs with those of the router, and I noticed that a few moments before the Nuki was disconnected from the MQTT broker, there was a disconnection from the WiFi network. And this really only happens with the Nuki. As I already said, using mqtt over thread, the problem does not occur. Let’s all hope that the issue will be resolved (it’s a bit embarrassing to buy a “PRO” product and be here discussing a bug like that…). For my part, unfortunately, I have no further tools to analyze and debug.
See you soon,
Vittorio.
And it happened again today, forever unlatched happened twice now when going from a locked state to unlatching. At the same time it seems to lose connection, might be related to the bug.
Next to that, I’m using the battery pack with the Smart Lock Pro and the percentage went down from 70 to 30 percent in 1 day. Or at least it reported 30 percent left. After charging for 10 minutes, the percentage was back to 80.
No, it is the WiFi connection. The MQTT client is the same whether it connects via WiFi or Thread does not make a difference in the way it handles the connection (or reconnection).
No. No and another time no.
There are about 12 different people in this discussion complaining about problems with MQTT and WIFI.
Do they all have probelms with the router?
In my case I have many devices connected in MQTT, but the only one that keeps getting unreachable is always just nuki.
In addition, I have connected the lock to the power (with cable) and set the power saving to FAST…
And it doesn’t change much, every once in a while the connection will drop and then NOT reconnect.
If I have problems with WIFI how come the only device to go unavailable is always only NUKI?
How come Nuki never tries to reconnect on its own?
How come Nuki when you enter MQTT settings then miraculously reconnects ?
Some background: my Wifi network is based on TP-Link Omada; last week I upgraded my 3 EAP225 access points with one EAP653 and two EAP613 access points. The network configuration itself has not changed (SSIDs, Authentication etc). I have a few SSIDs and my Nuki was always connected to my “main” SSID, which is a 2.4G+5G mixed network. I’ve had no problems with the Wifi connection itself so far.
Yesterday, Tuesday, morning my lock said it needed the battery recharged (after about 1.5 months)
I removed it and charged it for several hours
In the afternoon, I placed it back, only to find that the lock would not connect to the Wifi, no matter what I tried. I managed to connect it quite easily to a secondary SSID, which is 2.4G only, as opposed to my “main” network, which is mixed
Since then, I’m having constant MQTT disconnections and even a few Wifi disconnections (where the lock shows as connected only via bluetooth in the app)
Why on earth did the lock’s behavior change, just because the battery was recharged and it stayed offline for a few hours?
P.S. I have 52 Tasmota devices in my network, as well as several others, none of which have this kind of problems
Since i installed last Fw and resetted the lock, It works well. Any issue. Wifi+mqtt. It Is working from 10-15 days.
I set a static ip in my router and i set the battery savigny to auto
For the second time now I have seen my battery go from 80% to 25% in one day. The unit is pretty much new, have only charged the battery once. Last time I charged it for a few minutes and the battery was back to 100%. Could this be the beta firmware? Or maybe a defective battery pack?
Got this three times since I started using HomeAssistant this march even with the official 4.2.8 firmware. So this is not a beta problem. for me, it looks like a mqtt problem because this only started after I started using mqtt.
Here we go again. After some weeks of stability (no battery drain and no forever unlatched bug) suddenly these issues reappear. I had the forever unlatched issue three times in two days and the next day after that the battery started draining again. Nothing changed in my network or with the Nuki firmware which is still on Beta 4.3.4. I’m not experiencing other networking issues as described by other users in this thread. I have the device connected over MQTT which is working as expected.
A acknowledgement of Nuki regarding the forever unlatched and battery drain would be appreciated though.
And the same pattern repeats after this:
I pull the battery and insert it again
The battery level is much higher (now 47%)
The first unlock after having pulled the battery results in the motor blocking during unlatch, similar to the forever unlatched issue but now because the motor blocks
This block cant be resolved by re-opening the door which works as a work-around for the forever unlatched issue
I need to manually adjust the button and recalibrate the lock to get it working again
After this the percentage drops down to the value before I pulled the battery
happened twice now when going from a locked state to unlatching. At the same time it seems to lose connection, might be related to the bug.
