Smart Lock (4th generation) Firmware Beta 4.3.x

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.

image

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

I can reproduce this process.

Same here. Issues started since yesterday. Is this cloud related or just coincidence?

I mentioned already some time ago, that we’re looking into it. There is no update as of now, mainly because we still could not reproduce it (both the forever unlatch and the drain).

And here we go again. Today, my lock has gone offline, i.e. no wifi connection, twice. It came back online 7 hours later, by itself the first time.

THIS PRODUCT IS COMPLETELY UNRELIABLE.

1 Like

to reproduce it, you’ll have to enable MQTT, AND use MQTT to control the lock from time to time!
If you still cannot reproduce it, make it 10 test scenarios with 10 different systems.

Wifi offline again. Does Nuki care about this?

This is plain ridiculous. It’s disconnected from my wifi again. I noticed, good beta tester that I am, that when I go to wifi settings, the loading icon spins a couple of times and then freezes. Of course it’s not connected and probably won’t reconnect unless I remove the battery.

Question:
Can I connect my Nuki pro to a Nuki bridge and control it in local polling with its API without MQTT ? Have you ever tried ?

Yes. https://support.nuki.io/hc/en-us/articles/4409021237777-Do-I-need-the-Nuki-Bridge-to-manage-my-Smart-Lock-online

Today, the “forever unlatched” situation happened again and this time I pressed the physical button to see if it would respond and it did. It locked.

Please send me a direct message with a screenshot of the activity log where both lock actions are on it. Thank you!

And it happened again just now

I’ve had the lock for almost two months and not a week has gone by without some problems, be it Wifi disconnections, MQTT disconnections or “forever unlatched”. If Nuki cannot fix their - expensive - product, I think they should find some other solution. Is the Nuki bridge compatible with the SL4 Pro?

Update:
And we’re disconnected from MQTT again…

I gave up hope. Months went by with no real solution. It is very frustrating buying the top of the line product only to realize that it will (probably) never work. Simply put, I am unable to use ANY of the “PRO” features of this lock.

The solution that finally worked for me reliably in home assistant for WEEKS (!!!) now is resetting the lock and not using ANY features of it and connect it to a bridge. In my case not even using the official bridge, but:

Lesson learned: This was my last lock from you guys.

Thank you @ChrisT for your insight.

@NUKI @Juergen I think it’s time for some official answer from Nuki.

I’m running the 4.3.4 beta version connected to Home Assistant via MQTT.

Since moving to the beta firmware, the lock is more stable, although there are still times when it reports an Unavailable status in HA, just for much less time than before:

Yesterday customer support told me to put my lock into maintenance mode and then reboot it to try to resolve issues I’m having with the keypad connecting to the lock. I did so at about 4pm then, at around midnight, I checked to see whether the lock was available in HA as I’ve previously had problems with it reconnecting to MQTT. Sure enough, it was marked as Unavailable since 4pm. All I had to do was go to the MQTT config screen and press Save without changing anything, and it worked. Why doesn’t this happen automatically?

But then during the night things went a bit crazy. It started auto-locking every 5 minutes and for about 3.5 hours, and at 2:20am it suddenly opened by itself:

Fortunately there was somebody awake who noticed and closed the door. But I don’t understand where that Open command came from.

Any ideas what is going on here?

thanks

Clint

Same as the others, Nuki 4 Pro, with 4.3.4 keeps switching to unavailable on HA with Mqtt.
However, it does seem to always work from Nuki Web. so I guess it’s not a Wifi issue.

Is it possible to connect HA to the lock via http API (as it is possible with the bridge) ?

Here’s a log from my MQTT showing how the Nuki lock disconnects

2024-06-05 21:31:42: Client 43Lkc9GFtSrnrcwXJJ3gY3 closed its connection.
2024-06-05 21:31:51: New connection from 172.30.32.1:47057 on port 1883.
2024-06-05 21:31:51: New client connected from 172.30.32.1:47057 as 5wsbOXVsI8m51biuEHNjpP (p2, c1, k60, u'homeassistant').
2024-06-05 21:32:16: New connection from 172.30.32.2:35984 on port 1883.
2024-06-05 21:32:16: Client <unknown> closed its connection.
2024-06-05 21:34:17: New connection from 172.30.32.2:58198 on port 1883.
2024-06-05 21:34:17: Client <unknown> closed its connection.
2024-06-05 21:36:17: New connection from 172.30.32.2:54402 on port 1883.
2024-06-05 21:36:17: Client <unknown> closed its connection.
2024-06-05 21:36:58: Client Nuki_3BCA456C closed its connection.
2024-06-05 21:37:04: New connection from 192.168.87.118:49838 on port 1883.
2024-06-05 21:37:04: New client connected from 192.168.87.118:49838 as Nuki_3BCA456C (p2, c1, k300, u'mqtt').
2024-06-05 21:38:17: New connection from 172.30.32.2:45376 on port 1883.
2024-06-05 21:38:17: Client <unknown> closed its connection.
2024-06-05 21:40:17: New connection from 172.30.32.2:37420 on port 1883.
2024-06-05 21:40:17: Client <unknown> closed its connection.
2024-06-05 21:42:17: New connection from 172.30.32.2:44110 on port 1883.
2024-06-05 21:42:17: Client <unknown> closed its connection.
2024-06-05 21:44:17: New connection from 172.30.32.2:60312 on port 1883.
2024-06-05 21:44:17: Client <unknown> closed its connection.
2024-06-05 21:44:42: Client Nuki_3BCA456C has exceeded timeout, disconnecting.
2024-06-05 21:46:17: New connection from 172.30.32.2:49102 on port 1883.
2024-06-05 21:46:17: Client <unknown> closed its connection.
2024-06-05 21:48:17: New connection from 172.30.32.2:37084 on port 1883.
2024-06-05 21:48:17: Client <unknown> closed its connection.
2024-06-05 21:49:58: New connection from 192.168.87.118:56757 on port 1883.
2024-06-05 21:49:59: New client connected from 192.168.87.118:56757 as Nuki_3BCA456C (p2, c1, k300, u'mqtt').
2024-06-05 21:50:17: New connection from 172.30.32.2:48378 on port 1883.
2024-06-05 21:50:17: Client <unknown> closed its connection.

So after all the trouble I had with WiFi, I decided to buy a SkyConnect and connect the lock through Thread and Matter. It was quite a hassle to setup, but since then it has been running incredibly well. I still use MQTT over Thread. The location of the antenna is right next to my WiFi access point, which is quite close to the lock. So I still doubt it has anything to do with the WiFi signal.

I have not had any (yes, none) disconnects from MQTT. I have not had the forever unlatched issue anymore.

The only issue I have noticed is when my Internet went down, the lock repeatedly reconnected with MQTT and eventually did not work anymore. I had to completely remove the battery to get it to connect again. This seems very strange to me, as the local network was still functioning correctly. Could this be a bug?

1 Like

Same here, but with the non pro version. It is very stable with thread a matter and MQTT.

I had only disconnections if remote access is activated, not tried with log disabled.