MQTT over Thread

Discussion
1

Hi everyone,

I’m trying to enable MQTT on my Nuki Smart Lock 4.0 (non-Pro) and I’m running into persistent connection issues. I’d appreciate help from anyone who has MQTT working in a similar setup.

Setup
• Device: Nuki Smart Lock 4.0 (non-Pro, Matter over Thread)
• Thread Border Router: Apple TV 4K (Thread enabled)
• Integration: Nuki paired successfully via Matter with Apple Home
• MQTT Broker: Mosquitto
• Standard port (1883)
• Username/password authentication
• No TLS

What works
• The MQTT broker is stable and reachable.
• Using the same credentials, I can successfully connect from another device (macOS) using mosquitto_sub / mosquitto_pub.
• The broker hostname resolves correctly via mDNS to both IPv4 and IPv6 and is reachable from other devices in the same network.

Problem
When I enter the same MQTT credentials into the Nuki app, the connection fails immediately with a “Action could not be executed. Please try again” (loosely translated from german) error.

Things I already tried

  • Configuring MQTT immediately after Matter pairing
  • Disabling remote access in the “Smart-Home → Matter” menu, leaving only the Matter connection active
  • Using the mDNS hostname of the broker as MQTT host or ipv4 directly (ipv6 does not fit in the “host name” field - too long)
  • Verifying credentials (confirmed externally)

Of note:

  • using ipv4 in host name field results in a different error message (“MQTT activation failed. Activating MQTT resulted in an error. Please check user name and password.”). Credentials are double checked.
  • dns-sd -G v4v6 only lists the link-local ipv6 (and of course, the correct ipv4) for my server → reason why ipv6 connections might fail?

Thanks a lot for any help.

Best regards
Fabian

2

Update / Root Cause Analysis

I was able to resolve the initial connectivity issue.

The problem turned out to be incorrect IPv6 routing configuration on the OS, which prevented proper Thread ↔ LAN communication.

Required IPv6 RA/RIO state on the host

For Thread Border Router route announcements to be accepted, the following settings are required on the relevant interface:

  • accept_ra = 2
  • forwarding = 0 (or 1, both are fine as long as accept_ra = 2)
  • accept_ra_rt_info_max_plen = 64 (must be ≥ the Thread prefix length)

Once this was set, the Thread ULA route appeared correctly as a proto ra route and IPv6 connectivity started working as expected.

↓

Remaining Issue: MQTT Authentication

The next problem appears to be MQTT username/password authentication with the Nuki Lock.

Observed behavior:

  • Mosquitto is configured with allow_anonymous false
  • A valid username/password is configured in the Nuki Lock
  • Despite this, the broker denies the connection with not authorised
  • Debug logs show that the client is treated as anonymous
  • If allow_anonymous true is set, the connection succeeds — but still as anonymous, not as the configured user

This suggests that the Nuki Lock does not correctly send MQTT username/password in the CONNECT packet, even though the UI allows configuring them.

↓

Concern

If this interpretation is correct, this represents a security concern, especially for a door lock:

  • The device appears unable to authenticate using MQTT credentials
  • Broker-side authentication cannot be enforced
  • Access control is effectively limited to topic-based ACLs or network trust

I’d be interested to hear whether others can reproduce this behavior. While the official API documentation states that TLS is not supported, basic user/pass authentication should probably be implementable.

For transparency, much of this debugging was done with AI assistance. I don’t have any formal education on networking or MQTT internals, so feedback or corrections are very welcome.

EDIT: still had inconsistent behaviour. With empty pass it started autheticating as the supplied with mosquitto. So I tried it with user + pass again, failing. Changing the password to only [a-zA-Z0-9] worked. Former password had special characters (but was only 24 chars long).
I could not find any information on character restraints in mqtt passwords in the lock though. Would have saved me quite some time…

Apparently, the 32char limit was discussed here (MQTT only accepts passwords up to 32 chars) , but it would be useful to mention password restrictions in places more accessible to the user (preferably the UI).

Thanks for reading, if you have made it this far. And happy holidays.