Bridge/ WiFi repeated WLAN-Error/ WiFiRestart + UartCRCError

Nuki APIs Bridge
1

Hi,

I am currently troubleshooting a persistent connection issue with a Nuki Bridge and would like to know whether anyone has seen the same log pattern or knows what the internal error codes mean.

The issue has now occurred with three different Nuki Bridges , including a newly purchased one.

The current setup is:

  • Bridge firmware: 2.18.0
  • WiFi firmware: 2.4.0
  • Smart Lock firmware: 4.10.5
  • Opener firmware: 1.12.4

The Bridge is connected to a dedicated 2.4 GHz WiFi network and normally works for some time.

However, the Bridge repeatedly logs the following sequence:

WLAN-Error
unconnCnt: 0
unansMsg: 33
lastMsg: 0 or 1
pings: 0

WLAN-WiFiRestart
UartCRCError len1:1810 len2:7
WLAN-Init
WLAN-Connect
SSE-Disconnected
WLAN-Disconnected
WLAN-Connected
SSE-Connected

There are also many additional entries like:

UartCRCError len1:18 len2:0

Reproduced on a completely separate mobile hotspot

The important point is that I also reproduced the exact same behavior during a test requested by Nuki support using a completely separate 2.4 GHz mobile phone hotspot .

The same restart sequence occurred, for example:

WLAN-Error unconnCnt:0 unansMsg:33 lastMsg:1 pings:0
WLAN-WiFiRestart
UartCRCError len1:1810 len2:7
WLAN-Init
WLAN-Connect
SSE-Disconnected
WLAN-Disconnected
WLAN-Connected 10.51.162.189
SSE-Connected

And again:

2026-09-28 03:44:16 UTC
WLAN-Error unconnCnt:0 unansMsg:33 lastMsg:1 pings:0
WLAN-WiFiRestart
UartCRCError len1:1810 len2:7
WLAN-Init
WLAN-Connect
SSE-Disconnected
WLAN-Disconnected
WLAN-Connected 10.51.162.189
SSE-Connected

So the problem does not appear to be limited to my home WiFi, router or access point configuration.

Separate remote-access issue

There was also another incident where:

  • the Bridge was still locally reachable
  • both paired devices were reachable through the local Bridge API
  • I could trigger a physical lock action through the local API
  • the Bridge reported serverConnected:true

At the same time, the Nuki app reported that remote access was unavailable / the Bridge was not connected.

So there may be more than one issue involved.

BLE issues with the Opener

In addition, I see frequent BLE-related entries, especially for the Opener:

BLE-EarlyDisconnect
BLE-Retry
BLE-ConnectionTimeout
BLE-ConnectError

Some BLE commands still complete successfully afterwards, so I am not sure whether this is expected retry behavior or another separate problem.

Questions

  1. What does unansMsg:33 mean internally?
  2. What does UartCRCError len1:1810 len2:7 indicate?
  3. Is the sequence WLAN-Error -> WLAN-WiFiRestart -> UartCRCError -> WLAN-Disconnected a known Bridge or WiFi firmware issue?
  4. Has anyone seen this behavior with Bridge firmware 2.18.0 and WiFi firmware 2.4.0 ?
  5. Are frequent BLE-EarlyDisconnect , BLE-Retry and BLE-ConnectionTimeout entries for the Opener considered normal, or do they indicate an unstable BLE connection?

Any technical insight would be appreciated, especially from anyone familiar with the Bridge log internals.
I’m already in contact with support since a few weeks, but there is no progress except that they told me that I have to purchase a new bridge, which I did already…

thanks in advance
Martin

2

Hi @Martin_K1 ,

I can’t tell if the problems I had/have with my bridge is the same, but my bridge used (use?) to lost connection with lock/internet and the way I solved the problem was using brute force: weekly reboot of it. Problem solved!

Since I use a Hubitat hub, I was able to do it effortlessly.

After more than 45 years “scrubbing bits”, I’ve been resorting to “brute force” solutions whenever I can. :rofl:

3

Have you tried to plug the bridge into a different power outlet (or move it to a different place in your room/appartment/house)?

4

Hi Jürgen,
yes, the first Bridge was already installed at a different location and on a different power outlet. The Wi-Fi signal there was actually worse than at the current location, but the same general problem occurred.
In addition, with the current Bridge we reproduced the characteristic sequence
WLAN-Error → WLAN-WiFiRestart → UartCRCError → WLAN-Disconnected
while the Bridge was connected to an independent 2.4 GHz mobile hotspot.
So far we have therefore tested different Bridges, different physical locations / outlets and a completely different Wi-Fi infrastructure.
I can still move the current Bridge to another outlet once more as an additional exclusion test, but the previous tests suggest that the current outlet or location alone is unlikely to explain the issue.
Best regards,
Martin

5

Hi Marco,

thanks for the tip. A scheduled reboot could be a useful workaround, although I’d still like to understand the underlying cause first.

Best regards,
Martin

6

Do you use the http-bridge API?
Do you use the Nuki Web API?
Is Nuki Web active?

Or is only the Nuki App used to access the lock?

7

Hi Jürgen,
I mainly use the Nuki App to access the lock and opener.
The HTTP Bridge API is enabled and I have used it for troubleshooting, for example to check /info, /lockState and to verify that local commands still work when remote access via the app fails.
I do not actively use the Nuki Web API for automation.
Nuki Web is not part of my normal workflow either.
So under normal conditions, access is mainly through the Nuki App. The HTTP Bridge API has only been used to diagnose the issue.
Best regards,
Martin