Nuki Smart Lock and Matter (or mqtt)

I have a new Nuki 4 (no PRO and no bridge or anything else), which I added to Apple Home via Matter using a Homepod.

My HA instance is a docker container (no supervised install). I’ve created the matter server with docker (GitHub - home-assistant-libs/python-matter-server: Python server to interact with Matter) and connected with the integration in HA. So the HA or Matter instances has no own thread or bluetooth interface.

I’ve activated the pairing for the Nuki in the Apple Home App, opened the Home Assistant App and added a Matter device… After a few tries (read and follow the instructions on the matter server readme about ipv6), it was working.

6 Likes

Congratulations! Did you use the iPhone Home Assistant App, or the Android version?

iPhone, as I added the Nuki to Apple Home. But I think it schouldn‘t be to much different on Android.

The Nuki needs to be added to a thread/matter-compartible Apple, Google, Samsung or Alexa bridge. Than enable the pairing mode for Nuki in the corresponding app.

The sharing between matter bridges should work with all vendors. This isn’t a apple feature.

Adding in HA should be the same as on iPhone: Settings > Devices > Add Matter device… than scan QR code or enter paring code.

See https://m.youtube.com/watch?v=Fk0n0r0eKcE

Af far as I know, Alexa / Echo Devices are not supported yet.
This will follow later this year according to the NUKI support.

Hello,

I’m in the same situation as fago:

I bought a Nuki 4.0 Pro with Matter and without bridge.
I have Home Assistant with the usb sonoff zigbee dongle which I flashed to get the matter functionality and thought I could connect the Nuki directly to HA which this was. but for now it didn’t work.

Everything was ok fare, when I scan the QR code in the companion app it makes a few steps but the last step “checking network” of the device adding procedure fails. I have no other Matter device so I cannot check if my network is really not ok.

Now I read there is another way with MQTT. I’m fully new in MQTT as I use ZHA integration in HA.
I added the addon Mosquitto and the Integration MQTT. When I try to connect the Nuki via MQTT it says error (8D or 8A or 85). Which information do I have to fill out in “host name”, “username” and “passwort” to connect?

Would be great to find a way to integrate the nuki in Home assistant, that was the reason why I bought it :smiling_face:

For me it works perfectly with MQTT.

Did you configure your broker (mosquitto) already?.
The docs are pretty good:
MQTT - Home Assistant (home-assistant.io)

If that’s done connecting NUKI is easy.
The host (in the NUKI config) needs to be the HA compute IP Address and user / pwd as well (if you did the MQTT config properly).

I don’t know about your error messages, but I assume it’s from the APP?
So, I guess MQTT needs to be setup properly first.

Thank’s for the missing hint about IPv6… ;made my day! :slight_smile:
Now the lock is perfectly controlled by Matter, but they are a fiew more thing’s which i can control by the old Bridge. Not sure if you can see / control by MQTT?

I don’t even remember that o have mentioned ipv6 unless it was mentioned on the mqtt doc site :wink:
Most of the stuff I can also see using the pro without the hub via mqtt.
I think the only thing which is missing is the info about the keypad battery.

I just ordered my Nuki 4 pro, and trying to wrap my head around the safest way to hook things up. Maybe it deserves a separate topic, but for now this seems the best place.

My understanding is that matter support for opening a European style lock is hopefully coming through matter 1.2 support soon. (As in 2 levels to open a door: Lock/unlock and open door). Until then mqtt is the only way if I choose to allow it to unlock or open the door.

There’s also the choice wifi or thread. Thread is less power hungry. My understanding is mqtt could theoretically run over thread as it is tcp/ip6 based, but it is of course designed to be a transport layer matter in the first place. Is there any chance mqtt over thread might work, or is wifi the way to go for this?

I own Google Nest gen 2 which supports thread. I managed to join HA thread to the Nest tread network. I do not use a thread enables usb stick. Now my hope is I can use HA as a Matter controller over the Nest Hub thread border router. Is that possible, and am I right in hoping that Google cannot control my lock this way (even with Matter 1.2) because HA is in charge of matter?

And if I decide to use mqtt instead, what does that mean security wise? Because mqtt is now currently only protected by user/pwd, and to my knowledge not open to the outside (unless Nabu Casa does something I am not aware of). As I read it, Nuki is not doing much to protect the information going over mqtt. Is matter in the end the safest bet (knowing then that then HA is my weakest link)?

To reply to my own post: I managed to link the two Nest hub gen 2 to the Thread network from HA using the companion app on Android. I installed the Matter server addon, and connected the Nuki gen 4 to it.

The Matter integration is however often unavailable for an hour or so. The. it comes back. The Nest border routers are on the same floor, one about 3 or 4 meter away, one door between (albeit a fire rsisitant door). The other one has a wall between it, about three mtr. I do not think I’ll ever get a well connected border router closer to it.

The new firmware, which is supposed to provide remote access through Thread/matter does not seem to work for me to provice remote access.

For now I use MQTT (and Matter as a fallback), which provides more information and is more reliable. To give an example, I found no visible proof that I can see if any one unlocks the door outside HA using the Matter integration. MQTT will show me unlock events. Also, but this is known, the Matter 1.2 feature to unlatch as well as onlock is not there yet. MQTT will alow me to actually open the door (although I would like a feature to disable it from the lock side, I have no need for it yet so it is a security risk).

in my integration with matter over the apple tv i don‘t see all this entities? hoe did you integrate it?

best regards

philipp

Hello everyone,

I’m currently attempting to set up Matter with Thread, and I find myself encountering some challenges.

I seem to be at an impasse as the Nuki ( PRO 4 ) device fails to join the network. At this point, I’m unsure whether the issue lies with the Nuki device itself or with my setup. It’s worth noting that I only have one Nuki device to test.

My Thread router is a Sonoff Dongle E, as shown in the image below:
image

I’m exclusively utilizing Thread with this device, as I have another device dedicated to the Zigbee network. Initially, I attempted to use OpenThread RCP, but encountered difficulties running it on my Docker container. Specifically, I faced connectivity issues, which I suspect may be attributed to the network interface being labeled as eno1 instead of eth0.

Unfortunately, I couldn’t find any documentation on how to address this within the Docker-compose environment or command line ( to force to use eno1 instead of eth0 )

Below is the snippet of the attempted setup:

  # openthread:
  #     image: openthread/otbr
  #     tty: true
  #     stdin_open: true
  #     container_name: openthread
  #     privileged: true
  #     command: --radio-url spinel+hdlc+uart:///dev/ttyACM0
  #     sysctls:
  #       - net.ipv6.conf.all.disable_ipv6=0
  #       - net.ipv4.conf.all.forwarding=1
  #       - net.ipv6.conf.all.forwarding=1
  #     ports:
  #       - "8080:80"
  #     dns: 127.0.0.1
  #     volumes:
  #       - "/dev/ttyACM0:/dev/ttyACM0"

Following this setback, I attempted to change the firmware and employed MultiPan, despite my intention to solely utilize Thread routing.

Below is the Docker configuration for MultiPan:

  multipan:
    container_name: multipan
    image: b2un0/silabs-multipan-docker:latest
    restart: unless-stopped
    privileged: true # don't change this !
    network_mode: host # don't change this !
    cap_add:
      - SYS_ADMIN
      - NET_ADMIN
    volumes:
      - /home/pc/Documents/projects/multipan/data:/data
    environment:
      DEVICE: "/dev/ttyACM0" # only change if your have multiple devices
      BACKBONE_IF: "eno1" # change this to your network interface
      BAUDRATE: "460800"
      FLOW_CONTROL: "false" # change to false if you not using SkyConnect
      OTBR_REST_LISTEN_PORT: "8081" # use this within the HomeAssistant integration
      OTBR_WEB_PORT: "8086"

Although the setup appears functional, I’m uncertain about its adequacy.

I’ve found the following plugins to be promising:

This one also ( I don’t know the diff between Thread and OTBR so I installed both ) :

However, despite these seemingly positive indications, I’m unable to ascertain why my Nuki device refuses to join the network. I enable Matter, proceed to the HomeAssistant app, and attempt to add the Matter device. While the device is detected and an attempt to connect is made, it ultimately fails with an error message stating, “This device cannot join the Thread-HA network. Ensure it’s compatible with this network.”

Any insights into resolving this issue would be greatly appreciated.

Edit: OMG, after 3 hours of attempts, I succeeded by following the following tutorial

to record the device on Home Assistant without using Home Assistant App AND especially by reverting the server matter I had from version 5.6.0 to 5.0.3 AND revert HA to 2024.2.2.

I’m not exactly sure what was causing the issue, but there you go for those who have been going in circles like me for hours :slight_smile:

I will try to upgrade server-matter more later after some updated versions to see if it’s still working or not.
Same for Home Assistant

After many issues with disconnections and spending a lot of time, especially updating and downgrading Matter and OTBR addons, I believe I have detected my problem. I mention it in case it can be of help. I use the Sonoff dongle, which I had connected to a USB port on my NUC7. For some strange reason, that USB port conflicts with the internal Bluetooth & WiFi port of the NUC. Once changed to another port, the connection is now perfect.

Thank you for your feedback. I keep it on my side if the issue is still persisting. I think I did like you without know that.

I also encountered a problem few tomes after my message just before mentioned, when the device and Matter server were down. I received mDns timeout and BLE timeout errors.

I attempted to unpair the device, create a new thread protocol, set up a new Matter server, and reinstall firmware on the Sonoff Dongle, but the issue persisted.

Eventually, I unplugged and replugged the USB hub where the Sonoff Dongle was connected and upgraded and restarted the Bluetooth firmware on the NUC.
Additionally, I installed the latest version of Matter server (5.6.0) since I noticed it addressed issues with mDns timeout, which seemed to align with my errors.

Now everything is working fine again after to pair it the device.
Initially, it worked for only two hours yesterday before all my steps to fix it, but now it has been a day without any issues.

Hopefully, it will continue to function smoothly.

Can you please keep us updated on how this works? I’m also interested on buying the Nuki and I wanted to use thread with the Sonoff dongle, still deciding if to buy a separate one for thread or if to flash the one I currently use for Zigbee with the multipan firmware.

I managed to set the Nuki up with a Nest Hub 2 as a thread border router (supposed to be more stable) and the HA matter controller addon. It works most of the time, but the connection is unreliable (3 to 4 meters to the hub, one living room door inbetween). I’m using MQTT now which is more stable and also supports opening the door, not just operating the night lock. This will only be supported though Matter when Matter version 1.2 arrives.

On my side for the moment. 0 crash. It’s seems stable with Sonoff Dongle E + nuki 4.

Are you using the new Sonoff E and not P for zigbee ?

Not sûre it’s really stable for zigbee. But for thread it’s working well with multipan firmware. For zigbee I use an other one coordinator.

My smart lock is really close of the thread router so I dont know exactly the maximum range.

For now, I will just check the consumption of battery and still waiting matter 1.2 to have mqtt via thread and no via wifi which is really really bad. I don’t know why wifi of Nuki is always down ( always pending connections) . That’s why I decided to move to Matter.

Correct, I am using the E version for Zigbee and it is quite stable.
I had bought it because I had hoped that by the time Thread and Matter started getting traction the multipan firmware and integrations would be more stable but it’s not looking too good at the moment, at least from the reports I’ve found online.

Honestly, things have been going quite well for me over the past few weeks, especially with the positive feedback I’ve seen regarding Thread. Given the common issues reported with Sonoff E in Zigbee setups, it’s fantastic if everything is running smoothly for you. Typically, problems arise due to insufficient support from the end device. However, with proper implementation and using the latest versions of matter-server and multipan firmware, it’s been quite reliable for me.

I’ve come across occasional reports online of range issues with Thread, likely because we currently don’t have access to adjust transmit power on the Sonoff E. However, since I only have one device connected to matter (and it’s positioned very close, so it’s not an issue for me), I haven’t encountered any problems. Most of my other devices operate solely on Zigbee or WiFi. Additionally, I’ve read about some issues with WiFi routers related to poor management of IPv6 and, more rarely, some issues with BLE (which I experienced before updating my Bluetooth manager).

Furthermore, it’s worth mentioning that people often overlook the need to modify the default channel on OpenThread (channel 15), which can lead to network congestion. It’s crucial for individuals to analyze both their own WiFi channels and those of their neighbors to avoid interference