SL4P MQTT Problems since Nuki FW Update 4.1.8

[jeje (Jerome)]

still have MQTT trouble with 4.2.5

[SchmuFoo (Jan S.)]

@jeje

still have MQTT trouble with 4.2.5

What problem exactly?

→

SL4P MQTT Problems since Nuki FW Update 4.1.8

Can you explain this a bit more please? In this|my Thread various problems I had where discussed and also fixed all the time. (From my side there is, BTW, only one last minor problem existing: Sometimes there is a delay of handling MQTT LockActions, which a) can be seen in an traffic capture and seems to be related with the MQTT KeepAlive process and b) is also already under investigation by Nuki)

[jeje (Jerome)]

First problem, I have a raspberry PI 3B+ near to the nuki (~50cm) ; WiFi is perfect on my raspberry (RTT 5ms) but signal is medium/poor with my SL4 (RTT ~900ms).

I manage my SL4 via MQTT by sending the payload 1 or 2 to the topic nuki/XXXXXXXX/lockAction

Second problem, The SL4 randomly disconnects from the broker (mosquitto) and very often. Moreover, and there is a lag between the MQTT command and the lock action (sometimes my request is even lost).

[paolo1983]

After some days i can say that with 4.2.5 mqtt seems to work …

[Juergen (Jürgen Pansy)]

@jeje

WiFi is perfect on my raspberry (RTT 5ms) but signal is medium/poor with my SL4 (RTT ~900ms).

RTT of a ping is not a proper measure of WiFi quality. The Smart Lock runs on batteries and RTT times >1.000ms are normal. If you have problems with frequent reconnects follow the steps described here: Smart Lock WiFi/Thread/MQTT connection troubleshooting / FAQ

[Jacob]

Update from my side:
After the latest updates to 4.2.6 and the beta version 4.3.1 it is still not stable.
It is beter then before the update, but still not good enough.

Best regards,
Jacob

[SchmuFoo (Jan S.)]

@Jacob

After the latest updates to 4.2.6 and the beta version 4.3.1 it is still not stable.
It is beter then before the update, but still not good enough.

Give 4.3.2 a try:

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

Original post has been updated with release notes for the Smart Lock Beta 4.3.2 This Beta includes improvements on the MQTT connection stability (improved TCP-ACK handling) as well as a critical bugfix for the Bridge notification handling. Please install this build and provide feedback via this channel - thank you

[Jacob]

Done, Let’s hope it is the final fix, for this.

[SchmuFoo (Jan S.)]

@SchmuFoo

(From my side there is, BTW, only one last minor problem existing: Sometimes there is a delay of handling MQTT LockActions, which a) can be seen in an traffic capture and seems to be related with the MQTT KeepAlive process and b) is also already under investigation by Nuki)

Since three days not a single delay - Seems to be fixed with 4.3.2

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

Original post has been updated with release notes for the Smart Lock Beta 4.3.2 This Beta includes improvements on the MQTT connection stability (improved TCP-ACK handling) as well as a critical bugfix for the Bridge notification handling. Please install this build and provide feedback via this channel - thank you

[nothing-else (Pi)]

A possible new “type” of issue with 4.2.6 that I didn’t have with 4.1.8.
I can unlock via MQTT almost always, but locking almost never works. The lock blinks, indicating it’s unlocked, I issue the MQTT command to lock it and it flashes white once, but doesn’t lock. After this, it doesn’t blink anymore, possibly indicating it “thinks” it’s locked now?
If I rotate the lock manually (as to unlock it) it starts blinking again and I can then lock it with MQTT.

This doesn’t happen if I lock with the app, so pretty weird.

Looking forward to 4.3.2 (waiting for stable though). For me, 4.1.8 was better than 4.2.6.

Thanks everyone

[Juergen (Jürgen Pansy)]

@nothing-else

A possible new “type” of issue with 4.2.6

Then please open a new thread for it and do not write in the 4.1.8 thread.

@nothing-else

After this, it doesn’t blink anymore, possibly indicating it “thinks” it’s locked now?

You could check what the Activity log of the Smart Lock says to this lock commands.

[Jacob]

Update: Today, one of the locks was disconnected from the WIFI. After repower hem, it was back.

[jonathan_rigaud]

I have the same issue
The smart lock is not always online.
I connected it to a guest network 2.4 ghz and battery medium but it is still unstable.
I am using a mesh network in the house.
Any idea what else I can do to improve the connection stability ?
Thanks

[Jacob]

update:
On 18 april. One of the locks on my backdoor became unavailable in Home Assistant (MQTT), but the lock still works with the app and WIFI, (Disabled the Blue Tooth)

So it is more stable, but not 100% jet.

Best regards,
Jacob

[Jacob]

Update:
Today again, one of the locks is not availible in MQTT, the WIFI is still working and the lock is responding with the Nuki app.

Best regards,
Jacob

[Jacob]

Update:
The beta firmware 4.3.4 is looking good.

The firmware 4.2.8 is still giving MQTT unavailable issues.
It is less frequent as a few months ago.

Best regards,
Jacob

[DaveySwift]

Nuki pro 3.0 Firmware 4.2.8 - wifi very not stable. Also I noticed the Time Zone is defaulted to another region during updates which forces router to disallow connection (Starlink, Gen 2)

Major issue when not at property with potentially no way other way to gain entry.

[MihaiKrieger (Mihai Voicu)]

I am noticing a similar behavior with my Nuki 4.0 pro connected to home assistant via MQTT.
The connection is stable, as long as there is no interaction with the lock. As soon as somebody locks or unlocks the door, it is 50/50. Locking/unlocking using the app works fine. The problem is, when interacting with it using home assistant.

• Sometimes it works flawlessly and reacts correctly.
• Oftentimes, it hangs in either “locking” or “unlocking” state, and becomes unavailable for around 5 minutes. After that, it comes back online and displays the correct status.

Below there are the MQTT logs. What I am noticing is that Nuki_3A10B07C is closing its connection (this is how I am seeing the bluetooth ID of the lock, even though bluetooth pairing is disabled).
192.168.0.107 is the IP address of the lock on my network. I am spotting a conflict between Nuki_3A10B07C and 192.168.0.107. Could this be the problem?

I am using FW version 4.2.8

2024-06-13 07:47:47: Client Nuki_3A10B07C closed its connection.
2024-06-13 07:47:59: New connection from 192.168.0.107:53740 on port 1883.
2024-06-13 07:48:00: New client connected from 192.168.0.107:53740 as Nuki_3A10B07C (p2, c1, k300, u'mqtt_user').
2024-06-13 07:48:09: New connection from 172.30.32.2:53420 on port 1883.
2024-06-13 07:48:09: Client <unknown> closed its connection.
2024-06-13 07:48:38: Client Nuki_3A10B07C closed its connection.
2024-06-13 07:50:01: New connection from 192.168.0.107:64573 on port 1883.
2024-06-13 07:50:02: New client connected from 192.168.0.107:64573 as Nuki_3A10B07C (p2, c1, k300, u'mqtt_user').
2024-06-13 07:50:09: New connection from 172.30.32.2:46164 on port 1883.
2024-06-13 07:50:09: Client <unknown> closed its connection.
2024-06-13 07:52:09: New connection from 172.30.32.2:39692 on port 1883.
2024-06-13 07:52:09: Client <unknown> closed its connection.
2024-06-13 07:54:09: New connection from 172.30.32.2:35256 on port 1883.
2024-06-13 07:54:09: Client <unknown> closed its connection.
2024-06-13 07:56:09: New connection from 172.30.32.2:51240 on port 1883.
2024-06-13 07:56:09: Client <unknown> closed its connection.
2024-06-13 07:58:09: New connection from 172.30.32.2:45258 on port 1883.
2024-06-13 07:58:09: Client <unknown> closed its connection.
2024-06-13 08:00:09: New connection from 172.30.32.2:41364 on port 1883.
2024-06-13 08:00:09: Client <unknown> closed its connection.
2024-06-13 08:02:09: New connection from 172.30.32.2:57868 on port 1883.
2024-06-13 08:02:09: Client <unknown> closed its connection.
2024-06-13 08:04:09: New connection from 172.30.32.2:45140 on port 1883.
2024-06-13 08:04:09: Client <unknown> closed its connection.
2024-06-13 08:05:38: New connection from 192.168.0.107:52043 on port 1883.
2024-06-13 08:05:38: Client Nuki_3A10B07C already connected, closing old connection.
2024-06-13 08:05:38: New client connected from 192.168.0.107:52043 as Nuki_3A10B07C (p2, c1, k300, u'mqtt_user').
2024-06-13 08:06:09: New connection from 172.30.32.2:50748 on port 1883.
2024-06-13 08:06:09: Client <unknown> closed its connection.
2024-06-13 08:08:09: New connection from 172.30.32.2:43378 on port 1883.
2024-06-13 08:08:09: Client <unknown> closed its connection.
2024-06-13 08:10:09: New connection from 172.30.32.2:60670 on port 1883.
2024-06-13 08:10:09: Client <unknown> closed its connection.
2024-06-13 08:11:13: Saving in-memory database to /data//mosquitto.db.
2024-06-13 08:12:09: New connection from 172.30.32.2:42752 on port 1883.
2024-06-13 08:12:09: Client <unknown> closed its connection.

[dof250]

I think the problem is not only with MQTT. I’ve now turned off wifi on both my Nuki doorlocks and connected them with Matter to HomeAssistant. My backdoor is running 4.2.8 and hasn’t lost connection once. My front door is still on the latest beta and that one is stilling losing connection to Matter even with wifi and MQTT turned off.

[MihaiKrieger (Mihai Voicu)]

Thank you for the insights. This is interesting.
How did you manager to add it to HA via matter? I have matter enabled, already connected to google home.
Matter server running on HA and integration activated, however, when adding the device to HA from the google home app, it runs for one minute telling me that the device is being added, than it fails.
I am new to Matter, and it be that I am overseeing something. Do you have any advice?