Smart Lock 3.10.x Beta

MQTT completly broken with 3.9.5

I received the 3.10.1 today incl. Wifi & MQTT improvements. As I don‘t have issue with Wifi and don‘t using MQTT, I can‘t comment on this fix.

1 Like

Everyone with problems with MQTT and 3.9.5/3.10.0, please report back if 3.10.1 fixes your problems.

If not, please provide are short description about your system architecture and the problems you have rather than just writing “it’s broken” (which is not very helpful especially when trying to find the cause of a problem which does not affect everyone but only a subset of users).

1 Like

First at all, my apoligies. You’re right, just complaining doesn’t help to anyone.

Anyway, last night I installed 3.10.1 and, don’t want to say it too loud but seems this is working much better.

Attaching a history of the lock in HA where you can see clearly when the new firmware was installed.

I will keep an eye and revert back


1 Like

I just installed the 3.10.1 on my two devices and hope the WiFi and MQTT problems are finally fixed. The 3.10.0 was as terrible as the 3.9.5.

I have a setup with two Nuki 3.0 Pro, WiFi roaming and home automation using Home Assistant. I hope I can report it as fixed…

—- Kevin

Problem with WiFi disconnects still not solved. :slightly_frowning_face:

Hello Jurgen and thank you for your answer.
It is difficult to partecipate in a beta program without knowing in detail what changes in every beta release, without any possibilities of rolling back in case of problems and without a well structured way to diagnose problems and send you the details you need.

I think that nobody here buys smartlock only for testing so our evidence should be of some help for you to get the app and the software better and better.

I will try 3.10.1 asap and let you know if MQTT is resolved. Anyway, what kind of details do you need to diagnose? Logs? Timing? MQTT broker extractions?
About calibration problems that I do not had in previous versions, what kind of information can I give you to help diagnose the problem?

Help us to help you :slight_smile:
Thank you very much

Same anoyning issue here !

It seems better for now with 3.10.1, i will observe the connection:

After almost a day with the new firmware, on HA indeed looks better regarding availability but it’s not working fine.

When I issue commands via MQTT, 90% of them just never happen and the rest, they may do with random delay from couple of seconds up to minutes.

Imaging arriving at home, try to open with nuki, doesn’t work so you use your key. After couple of minutes when you’re in the bathroom, nuki opens the door letting the cats out. :face_with_symbols_over_mouth: (true story, waf is about to end on divorce. Pablo, you can ping me when read this)

Complaining doesn’t help, but what else I can do?
I do not have any access to see what’s going on, and it happens to a subset of user, widely and variant subset, not just one with a crappy conection. It’s not me, my device or my setup.

Is there any template to fill with useful info to help development to fix this?

Is there any way to downgrade to old firmware? It was working flawless until firmware upgrade.

To be honest, I bought a product, not a position as nuki beta tester :man_shrugging:

I think I recognize Home Assistant.
Do you track your phone with Companion ?

I am currently on 3.10.0 and want to update to 3.10.1. But always when I try to update I get the message, that I need to be within bluetooth range. I am only 1 meter next to the lock but it does not connect via bluetooth. Also the connection view shows no direct connection between my phone and my smartlock.

Try the steps mentioned in the FAQ if you have not done that yet:

For me it does not matter which battery preference I use. With FAST I have the identical outages. Before 3.9.5 I had no WiFi connection errors and also no MQTT problems.

Yeah, I did follow all those steps, plus some more provided by customer service such us use another access point or even my phone etc, etc…
That was months ago already.
I even tested to have nuki wall powered all time, didn’t work.

To be honest, I’m pretty sure that there is some casuistic between nuki and particular wifi/network flag. But when all my other devices, ranging from crappy chiniese stuffs to firs class brands, work totally fine, I cannot look to another direction but the lock.
Even more, when it worked fine until firmware upgrade

And I also think it is more a WiFi connection problem then a MQTT problem.

Few seconds ago both of my locks had a WiFi connection. Now one of my locks is gone…

On my router device I can see several disconnection log’s like [MAC]@WiFi-SSID disconnected, connection lost, signal strength -57

I do not check anymore, but I saw that when nuki was unavailable on HA, it was too via NukiWeb.
I will try to setup a kurma monitor, just to have that info

Try to use the IP-Adress of your mqtt and not the DNS-name to minimize dns-routing delays or failures. Since 3.9.5 it works pretty stable and commands are always within 1 Second executed. The only thing is the long delay for mqtt-reconnection after a wlan-reconnect .

Good point, but I was always using local IP as MQTT address.

Now, after some time monitoring the nukilock ping responses, I can see it is still disconnecting randomly.
Something I noticed is that the shorter is the cycle (now on every 20s) the less times it fails. Keeping pinging the lock every 20s makes it almost usable.
So as we all suspected, must be something with the wifi energy savings.

Could be posible to release a beta with the option to totally disable energy savings? for testing purposes.

Good evening everybody,

today was a very rainy sunday and because the WiFi/MQTT problem really annoys me, I set-up a clean and tiny test environment:

  • 2x NUKI Pro 3.0 locks with battery option FAST
  • 1x clean Home Assistant instance for testing the MQTT connection (NUKI connected via IP) and also observing the availability of the two locks. I also setup the Nuki Lock integration for connecting to the devices via NUKI WEB API.
  • 1x clean network with direct internet connection. In this network we only have the Access Point, the two NUKI locks and the Home Assistant instance as physical device.

What I got:
The same annoying WiFI and MQTT non-availability as in my normal network. Everytime the device were shown as not available in Home Assistant, no communication was possible (not via MQTT and not via NUKI WEB API). Via iPhone App it was possible to see the connection status: Bluetooth. That means that all your energy saving functions or improvements are useless and causes all the problems we have since software version 3.9.5. With my test environment of today, I also can’t trust all the statements here in the forum that speak of a flawless uptime since software version 3.10.1 - either these statements are not true, or they use some kind of magic, which I as a software developer do not believe in.

So dear NUKI developer team: what specific information do you need for bug-fixing these issues. Is a rollback to the old software functionality imaginable? With this, we could test all your “energy saving functions and improvements” step by step?

Otherwise I’ll have to start believing in magic and contact Nuki support. Apparently both of my locks are broken, since there are devices that work flawless with 3.10.1.


PS: Using the Home Assistant NUKI Lock integration for using the NUKI WEB API is totally useless. Since there is always the last status shown - with this you never can see when the device was not available. :wink: