Constant reconnect cycles causing HA to go unavailable

fabianwimberger · August 22, 2026, 8:10pm

Hello,

unfortunately over the last two releases a new issue seems to have crept in. The connection via MQTT seems to reinitialize every ~360s causing the device to become unavailable in Homeassistant and delaying or preventing the sending of commands. Furthermore it spams logs within the mqtt broker and homeassistant, causing unnecessary write cycles on top of not being able to lock/unlock or see the status of the lock.

The logs within mqtt5 look like following:

mqtt5  | 1787427912: New connection from 192.0.2.129:64179 on port 1883. 
mqtt5  | 1787427913: New client connected from 192.0.2.129:64179 as Nuki_XXXXXXXX (p4, c1, k300, u'nuki'). 
mqtt5  | 1787428269: Client Nuki_XXXXXXXX [192.0.2.129:64179] disconnected: connection closed by client. 
mqtt5  | 1787428274: New connection from 192.0.2.129:64893 on port 1883. 
mqtt5  | 1787428275: New client connected from 192.0.2.129:64893 as Nuki_XXXXXXXX (p4, c1, k300, u'nuki'). 
mqtt5  | 1787428469: Saving in-memory database to /mosquitto/data//mosquitto.db. 
mqtt5  | 1787428633: Client Nuki_XXXXXXXX [192.0.2.129:64893] disconnected: connection closed by client. 
mqtt5  | 1787428638: New connection from 192.0.2.129:60459 on port 1883. 
mqtt5  | 1787428639: New client connected from 192.0.2.129:60459 as Nuki_XXXXXXXX (p4, c1, k300, u'nuki').

I have checked the wifi logs and at least the wifi connection has been stable for more than 48h (no reauth, no reconn). Also my mqtt broker is not having any issues with more than 10 other devices. Additionally, the disconnect is a clean disconnect from mqtt, no network fluke or kick.

Device: Pro (5th Generation)
Firmware: 5.9.4
MQTT Broker: eclipse-mosquitto 2.1.2
Homeassistant: 2026.8.3

I would appreciate some assistance and would gladly join the Beta program in order to test a new version.

jasper · September 9, 2026, 8:04am

I’ve got the same problem since i updated to 5.9.4

itsthomas · September 9, 2026, 4:57pm

Same issue here.

Juergen · September 10, 2026, 3:53pm

We could not reproduce the problem you describe, therefore it does not seem to apply to everyone but require a specific setup.

Could you please describe a bit your system setup (esp. which MQTT broker you are using and your network topology, how the SL is connected to the WIFI & internet, do you use VLANs and is the internet access for the Smart Lock restricted)?

If you are running a beta firmware of the Smart Lock, please send me the Nuki ID of your Smart Lock in a direct message. Thank you!

jasper · September 11, 2026, 1:22pm

Thanks for looking into this. Happy to share my setup:

MQTT broker: the official Mosquitto broker add-on (7.1.1), running locally on my Home Assistant OS instance (not a cloud/external broker).
Network: UniFi (UDM/UniFi controller + UniFi APs), managed via the UniFi and UniFi Insights integrations in Home Assistant.
Smart Lock connectivity: no Bridge involved — this is a Smart Lock Ultra with built-in WiFi, connected directly to my 2.4GHz home network and talking straight to the local Mosquitto broker via the built-in MQTT feature. WiFi power mode is set to “Automatic” (unchanged from before the update).
VLANs: no VLAN segmentation, single flat LAN
Internet access restriction for the Smart Lock: no restriction, it has normal outbound internet access

One thing I can confirm precisely: the problem started exactly at the firmware update to 5.9.4 (06.08.2026 public release, not a beta). Before that (5.8.11) the lock only went unavailable sporadically (once every day or two). right after updating, it started flapping to unavailable roughly every ~360 seconds, matching what’s described above. I’m on the public release track, not the beta program, so no beta Nuki ID to share on that front.

Let me know if there’s specific diagnostic data (MQTT broker logs, HA logbook export, etc.) that would help narrow this down further.

fabianwimberger · September 11, 2026, 1:52pm

Same from my side. However I have in the meantime switched to a thread based setup. With thread, both the native matter “entities” AND also mqtt was working just fine. So i suspect it has to with the wifi stack.

My setup before change to thread:

MQTT broker: the official Eclipse-Mosquitto Docker Container
Network: OpenWRT APs
Smart Lock connectivity: no Bridge involved — this is a Smart Lock Ultra with built-in WiFi, connected directly to my 2.4GHz home network and talking straight to the local Mosquitto broker via the built-in MQTT feature. WiFi power mode is set to “Automatic” (unchanged from before the update). No DNS either, connected directly via IP, User and PW.
VLANs: no VLAN segmentation, single flat LAN
Internet access restriction for the Smart Lock: no restriction, it has normal outbound internet access. However restricting outbound connections was one of the things i tried, it changed nothing.

Since i switched to Thread in the meantime, this is no issue for me anymore. But i suspect Bugreports will be coming in once users upgrade to the latest nuki release. I tried different AP, different SSID, different Wifi-PW, readding mqtt connection in nuki several times. Nothing helped.

theorician · September 18, 2026, 3:39pm

I have the exact same problem. Smart Lock Pro 5 running 5.9.4. It started happening after a firmware update, but I don’t know which. I had auto update on, so it’s probably deducible from the timeline.

I’ve had the network setup written out and the timeline analysed by an AI - sorry for that, but it does make it a lot clearer to read. Here’s the AI speaking mostly:

Switching to Wi-Fi compatibility mode made it stable for several weeks. Then I switched compatibility mode off and back on, and it started dropping out again. It’s still set to compatibility mode now.

My setup is a MikroTik hAP ax³ running RouterOS 7.24.2, with the lock connected directly to its 2.4 GHz Wi-Fi. The AP uses 20/40 MHz and WPA2/WPA3 mixed mode. No Nuki Bridge or Thread involved.

The broker is the official Eclipse Mosquitto 2.0.22 container, running locally in a k3s cluster alongside Home Assistant 2026.9.1. The lock connects with username/password over TCP port 1883. Mosquitto logs show a 300-second keepalive.

The network path is basically:

Nuki → MikroTik Wi-Fi → wired LAN → MetalLB service → Mosquitto

Wi-Fi and Ethernet are on the same LAN bridge, with no VLAN segmentation. MetalLB exposes the broker directly on a LAN IP; there’s no reverse proxy in between. There aren’t any firewall or DNS rules restricting access to Nuki’s servers, or any Kubernetes network policy restricting the broker.

I went through the HA history and found almost exactly the six-minute cycle described here: during August 6–18, disconnects were a median of 360.7 seconds apart and lasted about 7.3 seconds. That worked out to roughly 200–240 dropouts a day.

After enabling compatibility mode, it settled down around August 21–22 and stayed about 99.94% available through September 15. The problems returned after I toggled the mode, and now some outages are much longer. On September 17 it was unavailable for nearly six hours in total, including one stretch of 3½ hours.

Other MQTT devices stayed available through almost all of those outages. About 11 hours of broker logs on September 18 showed 16 connections from the lock, seven connections closed by the client, and five keepalive timeouts. I haven’t yet checked whether the lock stays associated with the AP during those periods.

I’m happy to do any testing for you guys, just ping me.