Constant reconnect cycles causing HA to go unavailable

Nuki APIs MQTT
1

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.

1 Like
2

Iā€™ve got the same problem since i updated to 5.9.4

3

Same issue here.

4

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!

5

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.

6

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.

7

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.

8

Hi everyone,

I am experiencing a similar problem with a Nuki Smart Lock Pro running firmware 5.9.4.

This setup worked very well for months, but it has now become unreliable enough that we have had to use a physical key or the Nuki app to enter the house. I cannot yet tie the start of the problem to a particular firmware update.

Setup

  • Nuki Smart Lock Pro, firmware 5.9.4, using built-in Wi-Fi and native MQTT, without a Nuki Bridge.
  • Home Assistant Core 2026.7.4 / HA OS 18.1, running in a Proxmox VM.
  • Official Mosquitto broker add-on 7.1.1, running locally.
  • UniFi Wi-Fi network with a dedicated IoT VLAN and 2.4 GHz / WPA2 SSID.
  • Local MQTT over TCP port 1883, using username/password authentication and a 300-second keepalive.
  • HA publishes lock commands with QoS 2 and retain=false.

Comparison with my Nuki Go

I also have a Nuki Smart Lock Go, running the same firmware 5.9.4, using the same Wi-Fi network and MQTT broker.

The Go is not showing the same prolonged unavailability and responded while the Pro was failing. I temporarily switched it off during some tests to isolate the Pro; those deliberate disconnections should not be counted as faults.

What we have tried

  1. Removed/re-added the locks and reconfigured MQTT access. Authentication succeeds; the recurring failure happens after connection.
  2. Changed the Proā€™s Wi-Fi Power Mode from Automatic to Compatibility. It initially responded quickly, but an idle-period test still failed.
  3. Enabled Force WiFi 4 Mode on the UniFi IoT SSID, with BSS Transition disabled. Channel Lock and DTIM Interval Lock were left disabled.
  4. Compared network and HA availability before and after the changes.
  5. Correlated HA script traces, MQTT transmit/receive diagnostics, broker logs and the Nuki activity log, rather than assuming that a completed HA script meant the lock had operated.

After the Wi-Fi change, the Pro initially looked much better. One arrival-script unlock completed in approximately 1.42 seconds, after more than 16 minutes without a recorded MQTT command. Unfortunately, the problem returned that evening.

Failure timeline ā€” 3ā€“4 October

Times below UTC+1.

  • 21:15: unlocking worked.
  • 21:18: locking through HA/MQTT worked.
  • 21:25ā€“21:33: further HA commands were recorded, but the Pro did not report corresponding state changes.
  • Someone tried to enter and had to use the mechanical key. Subsequent inside-button operations at 21:34ā€“21:35 appear in the Nuki activity log but were not reflected in HA.
  • 21:35: Mosquitto expired the connection with exceeded timeout, and HA showed the lock as unavailable.
  • 23:42: I also could not unlock through HA and used the Nuki app. The MQTT connection recovered around the same time.
  • The Nuki activity log shows both an app/user unlock and an MQTT unlock at 23:42. This is consistent with a previous attempt taking effect after connectivity recovered, but we cannot identify the exact command or prove where it waited.
  • Overnight, there were further reconnects and timeouts. Some broker connections were accepted without HA availability recovering.

Examples from the actual broker log, with identifiers anonymized:

2026-10-03 21:35:37: Client Nuki_<LOCK_ID> [<LOCK_IP>:53706] disconnected: exceeded timeout.
2026-10-03 23:42:48: New client connected from <LOCK_IP>:52365 as Nuki_<LOCK_ID> (p4, c1, k300, uā€™<MQTT_USER>ā€˜).
2026-10-04 02:00:22: Client Nuki_<LOCK_ID> [<LOCK_IP>:52365] disconnected: exceeded timeout.
2026-10-04 06:06:16: New client connected from <LOCK_IP>:53014 as Nuki_<LOCK_ID> (p4, c1, k300, uā€™<MQTT_USER>').
2026-10-04 06:12:37: Client Nuki_<LOCK_ID> [<LOCK_IP>:53014] disconnected: connection closed by client.
2026-10-04 06:20:21: Client Nuki_<LOCK_ID> [<LOCK_IP>:50454] disconnected: exceeded timeout.

There are also session taken over messages, with connections coming from the same lock IP.

An apparent ā€œlockedā€ event around 06:12 initially concerned me, but it coincided with reconnection/state republication. The Nuki activity log shows no operation then; its last overnight operation was a manual button lock at 01:48. A passive MQTT subscription also found no retained lockAction message.

Questions

Has anyone found a reproducible fix for this on 5.9.4, or a firmware version specifically addressing it?

I would particularly appreciate guidance on:

  • Distinguishing a Wi-Fi/power-saving issue from a stalled MQTT client.
  • Whether a command that appears to have failed can still execute when connectivity returns.
  • Which diagnostics would be most useful to Nuki support before making further changes.

I can provide additional anonymized broker logs, HA traces and the Nuki activity timeline if useful.

1 Like
9

@Juergen Hi - this is obviously a real problem which affects a subset of your user base and has done for months. A status updates would be appreciated.

10

We tried to reproduce the issue, but we havenā€™t been able to replicate it in our testing.

It would be really helpful if a few of you could join our firmware beta program. That build has additional logging enabled, which should help us figure out whatā€™s going on. If youā€™re affected and want to give it a try, please send me your Nuki ID in a DM.

11

Hi everyone,

Iā€™m experiencing a connectivity issue with a new Smart Lock Pro 5 running firmware 5.9.4, and Iā€™m wondering whether it could be related to the problems discussed here.

In my case, the WiFi connection itself works correctly. The lock associates with the access point, gets an IP address via DHCP and shows good signal quality, but the server connection remains indefinitely at ā€œSSE Connectingā€.

Iā€™ve done quite a lot of troubleshooting and have been able to reproduce the following consistently:

Pro 5 + home Internet (Telekom) ā†’ WiFi connected, SSE Connecting ā†’ Disconnects and retries indefinitely.

Pro 5 + iPhone/Android mobile hotspot ā†’ WiFi connected, SSE Connected ā†’ Connection remains estable and remote actions work.

Pro 4 + exact same home Internet ā†’ WiFi connected, server connection works ā†’ Connection remains estable and remote actions work.

I normally use a Linksys mesh system, but I have completely bypassed it and connected the Pro 5 directly to the WiFi of my Telekom Speedport 7 with its default configuration. The result is exactly the same.

I also tried a dedicated 2.4 GHz WPA2 network, Compatibility Mode, different DNS servers, DTIM Skip disabled and Broadcast Filter disabled. None of these changed the behavior.

One particularly interesting test was using an Android phone as the access point. When the Android phone uses mobile data as its upstream connection, the Pro 5 reaches SSE Connected. When the same phone and hotspot use my home WiFi as the upstream Internet connection, the Pro 5 remains at SSE Connecting.

My previous Smart Lock Pro 4 became defective recently after around two years, which is why I bought the Pro 5. To exclude my home network as much as possible, I even factory reset the old Pro 4 and configured its WiFi again from scratch. Despite its other hardware problem, it can still establish the Nuki server connection through exactly the same Telekom Internet connection where the Pro 5 fails.

I already opened a support case through the Nuki app and provided the internal diagnostic logs. The case was escalated to the appropriate technical team, but I have now been waiting for an update for around two weeks, so I thought I would also post the findings here.

I saw that connectivity issues with 5.9.4 are being investigated and that additional logging is available in the beta firmware. Iā€™m not sure whether my issue has the same underlying cause, since in my case the failure seems specifically related to establishing the SSE/server connection over my fixed Internet connection.

If this could be useful for the ongoing investigation, I would be happy to provide additional diagnostics or perform specific network tests. I would also be interested to know the hostname/endpoint that the Pro 5 attempts to reach when establishing the SSE connection, as I could test DNS, TCP and TLS connectivity to that endpoint directly from the same Telekom connection.

Thanks!

12

The Pro 5 and Pro 4 connect to different backend systems. See. Looks like your home Internet (Telekom) blocks connects or has communication problems to the new infrastructure.

The new infrastructure is based on MQTT. So you could try to connect to the following IPs on ports 8883 or 443 with an MQTT client: 135.125.168.126, 135.125.168.154, 51.89.116.104
(Note: Without certificate/Authentication you canā€™t to anything on the server, but you can at least check if it is reachable)

Frequent reconnects can also happen if the connection is terminated within the keep-alive period. In such a case the SL would connect right after a reboot but run into reconnect problems afterwards. You could test that as well by forcing a reboot via button press.

13

Thanks for the explanation and for providing the backend IP addresses!

I performed the connectivity tests from my Telekom home Internet connection.

All three IPs (135.125.168.126, 135.125.168.154 and 51.89.116.104) are reachable on both ports 8883 and 443.

I also tested the same six combinations through an iPhone cellular hotspot. All of them are reachable there as well.

As an additional test, I used openssl s_client against all six combinations. TLS 1.3 negotiation succeeds through both Telekom and the cellular connection, in both cases using TLS_AES_128_GCM_SHA256.

So at least at the TCP and TLS negotiation level, I cannot see a difference between the Telekom and cellular connections. Of course, this does not reproduce the authenticated MQTT session established by the Smart Lock itself.

I then performed the reboot test you suggested.

Unfortunately, the Pro 5 never reaches ā€œSSE Connectedā€, even immediately after restarting.

The observed sequence is:

  1. WiFi connects successfully.
  2. The lock receives an IP address via DHCP.
  3. Server status remains at ā€œSSE Connectingā€.
  4. After approximately 10 seconds, WiFi disconnects and the IP address disappears.
  5. The lock attempts to reconnect and the same cycle repeats.

After a forced reboot, the initial WiFi connection lasted slightly longer, but the server status never changed to ā€œSSE Connectedā€.

I have also already tried the WiFi troubleshooting suggested by Nuki Support, including Compatibility Mode and changes in Expert Settings such as disabling DTIM Skip and Broadcast Filter. I also tested a dedicated 2.4 GHz network, separated the 2.4 GHz and 5 GHz bands, and forced WPA2. Unfortunately, the behavior remains exactly the same.

I have additionally bypassed my Linksys mesh entirely and connected the lock directly to the Telekom Speedport 7 WiFi, with the same result.

What makes this particularly strange is that the same Pro 5 connects successfully when the Internet connection is provided through a cellular hotspot. I even tested an Android phone as the hotspot: when the phone uses mobile data as its upstream connection, the Pro 5 connects to the Nuki server; when the same phone and hotspot use my home Internet as the upstream connection, the Pro 5 fails to connect.

Since TCP and TLS connectivity to the new backend infrastructure work from another device on the same Telekom connection, and the lock successfully associates with WiFi and obtains an IP address, it seems that the failure happens at a later stage of the connection establishment.

Is there any additional diagnostic test I could perform to determine exactly where the connection fails? I would be happy to provide further logs or test specific MQTT behavior if that would help.

Thanks again for your help!

14

Really interesting findings. Weā€™ll reach out via DM since we need to ask for some private details that shouldnā€™t be shared publicly.

1 Like
15

Update: I found the cause and a workaround.

The issue is caused by the Internet Security / Protect Home feature of my Telekom Speedport 7 (Germany).

In the MeinMagenta app under Internet ā†’ Internet Security, Protect Home is enabled by default and includes protection against harmful websites, harmful IP addresses, phishing and compromised IoT devices.

As soon as I disabled Internet Security, the Pro 5 connected to the Nuki servers immediately and remote access started working normally. Re enabling it reproduces the connection problem.

Unfortunately, Telekom doesnā€™t seem to allow exceptions for individual devices, so for now this is only a workaround, as I would prefer not to disable the additional security permanently.

Iā€™ll report the issue to Telekom as well, so hopefully the false positive / compatibility issue can be resolved properly.

Thanks again JĆ¼rgen for your help investigating this!

1 Like
16

Unlikely to be related, but to eliminate variables: does anyone else in this thread have a Telekom Speedport 7?

17

@Juergen

Iā€™m on the 5.10.1 beta now and still seeing the six-minute reconnect cycle.

In the 24 hours ending 14 October at 23:24:

  • 188 outages recorded by HA.
  • Median interval between outage starts: 360.8 seconds.
  • Median outage duration: 7.2 seconds.

All times below are 14 October, Berlin time, CEST (UTC+2).

Three consecutive outage starts:

  • 15:28:44.851
  • 15:34:46.591
  • 15:40:48.207

Broker details for the middle one:

  • 15:34:45 ā€” received PINGREQ and sent PINGRESP.
  • 15:34:46 ā€” logged that the client closed its connection.
  • 15:34:52 ā€” lock reconnected.
  • 15:34:53.724 ā€” HA became available again.

The AP logged no Wi-Fi disconnects around these cycles. Of the 88 outage starts covered by the retained broker logs, 82 show the client closing its connection.

There was also a longer MQTT outage without a Wi-Fi disconnect recorded by the AP:

  • 17:22:56 ā€” last MQTT ping received.
  • 17:30:26 ā€” broker timed out the connection; HA became unavailable.
  • 19:34:19 ā€” HA recovered.

And no, I donā€™t have a Speedport, and am not on Telekom.

Is there anything specific you need me to check?

18

The keep-alive timeout for the local MQTT client is set to 300 seconds (5 minutes), so PINGREQ/PINGRESP packets should be sent every 5 minutes after the last message, rather than 6. This aligns with what we observe in our own setups.

A tcpdump of what the lock sends out would be helpful. With an openwrt router this is relatively easy. Donā€™t know about others. If you have a dump, please do not post it here, but DM it to me.

You might also try to set the wifi to ā€œcompatibility modeā€ in the Nuki App. Maybe that makes a difference.

And finally, if you have a Matter / Thread hub at home (e.g. Apple HomePod), it would be interesting if the problem also exists if the connection runs over Thread and not WiFi.

19

Hi,

You can cross check these timestamps with your logs, they are perhaps also useful.

The six-minute pattern hasnā€™t returned, but longer MQTT failures are still happening.

Since compatibility mode was enabled: 10 outages, totalling 34m 52s.
Last 24 hours: 7 outages, totalling 27m 15s.
All times are Berlin time, CEST (UTC+2):
17 October, 16:55:49ā€“16:58:54: 3m 05s, with no Wi-Fi disconnect logged.
17 October, 19:37:47ā€“19:48:15: 10m 28s, with no Wi-Fi disconnect logged.
17 October, 23:37:40ā€“23:39:05: 1m 26s, with no Wi-Fi disconnect logged.
18 October, 06:29:01ā€“06:40:42: 11m 41s. The last MQTT ping arrived at 06:21:31; the first Wi-Fi disconnect wasnā€™t logged until 06:32:42.