Smart Lock Ultra (5.9.4): Matter stops responding while Thread, ICMP and MQTT all stay healthy — a device reboot does not recover it

Nuki APIs Matter
1

Setup

  • Nuki Smart Lock Ultra, firmware 5.9.4 (current release)
  • Matter over Thread, commissioned into Home Assistant (Matter Server 9.2.0, matter.js)
  • Thread border router: SMLIGHT SLZB-MR3U running OTBR on-device
  • The lock’s built-in Wi-Fi is also enabled, for the native MQTT interface

Symptom
The lock becomes unavailable in Home Assistant while remaining fully alive on every other layer. This is not a Thread dropout — I can show the radio is still attached:

  • It is still listed as a sleepy end device child in the border router’s Thread child table (RxOnWhenIdle: 0), continuously, throughout the outage.
  • It answers ICMPv6 pings on its Matter address the whole time (0.5–1.5 s RTT, as expected for a SED).
  • Its native MQTT interface keeps publishing throughout, including real door operations — during the outage the lock reported manual and keypad unlatches over MQTT, correctly, while Matter was dead.
  • Only the Matter/CASE session fails. matter.js reports the subscription timing out, then [peer-unreachable] Peer has been unreachable for …, and marks the node unavailable.

So the device, its radio and its IP stack are all working. The Matter application layer specifically stops answering on UDP 5540.

Two occurrences in one day

  1. ~08:47 → ~13:47 — recovered on its own after almost exactly 5 hours. Importantly, the lock’s own reboot count attribute was unchanged across the whole episode, so the device did not restart itself; the Matter session simply re-established.
  2. From ~20:32 — never recovered. Still down many hours later, at which point I moved control of the door to MQTT.

What did not fix occurrence 2

  • Reloading the Matter integration in Home Assistant — no effect (it does not reach the controller’s CHIP stack at all).
  • interview_node — aborts.
  • Restarting the Matter Server twice — the node re-pairs, reports its device data correctly (isThreadSleepyEndDevice: true, isIntermittentlyConnected: true, idleModeDuration: 900000), and then still cannot complete a CASE session.
  • A physical button restart (hold to the solid red ring, release). The device demonstrably rebooted — its Wi-Fi association uptime reset from ~12.6 hours to 101 seconds and its MQTT client reconnected — and Matter still did not come back.

The Ultra-specific problem
The usual advice for a wedged Matter stack is a full power cycle. The Ultra has no removable battery, so that is not possible. The button restart is the only reset available to an owner, and in my case it did not clear the fault. If the Matter stack requires a true power cycle to recover, then on this model there is no supported way to do it — which effectively means an unrecoverable device until it heals on its own, if it does.

Disclosures — two ways my setup is non-standard

  1. Wi-Fi and Thread are enabled at the same time. I understand the firmware normally disables Wi-Fi once Thread remote access is available; I deliberately keep Wi-Fi on for the MQTT interface. If this combination is unsupported or is itself the cause, please say so plainly — that would be a useful answer.
  2. My border router runs SMLIGHT’s on-device OTBR mode, which SMLIGHT labels experimental. Other Matter devices on the same fabric were unaffected throughout, but I can’t rule it out.

Questions

  1. Is this a known failure mode in 5.9.x?
  2. Is there any way to restart the Matter/CASE stack on an Ultra without a power cycle?
  3. Does a button restart fully reinitialise the Matter stack, or is it a soft restart that would leave a wedged CASE layer wedged?
  4. Would enabling extended logging or a beta firmware help you capture this? I still have the device in this state historically and can reproduce the diagnostics.

I have matter.js logs, Thread child-table output and MQTT traces for both occurrences and can supply any of it.