I’m trying (and failing) to get setup with Matter over Thread so I can use an Aqara U300 smart lock.
So I bought the Aqara lock and a SM Light SLZB-MR4 multi-radio since it would get me going with Matter over Thread… appraently.
The SLZB-MR4 is currently setup with one radio of it’s two set as Matter-over-Thread and the other ZigBee (not using yet since I already have a ZigBee setup separate to this) and is connected both via USB to my HA Server and Ethernet to my Ubiqiti Dream Machine Pro.
Initially I tried setting up the MR4 to connect to HA via USB but things werent’t working well so I swapped to Ethernet.
I’m running HAOS on a NUC, I have the Matter server add-on installed, the OpenThreadBoarderRouter add-on and integration, Thread and Matter Integrations, have done multiple synchronisations of the Thread credentials to my Android phone and still cannot get the Matter lock to connect. Needless to say, it’s driving me insane. I normally have everything under control with my smart home / HA but has cooked me.
In my UniFi setup, I’ve enabled IPv6, the HA server and my phone are on the same network and VLAN, as well as the SLZB-MR4 device.
Here are some screenshots of configs etc.
SLZB config:
I am at a total loss as to what to try next. When I try to add the U300 lock using Matter in the HA Companion app on my phone, it seems to detect the lock and creates Matter credentials, then goes to 'checking network connectivity or something…then times out saying to check the device is compatible.
Any tips on what to try next before giving up on Matter completely and sending this lock back? (a bit more of my chaos posted here)
I’m no longer using the USB connection for this device since I had no luck initially, now it’s connected via Ethernet and simply powered by USB (which is connected to the HA server for ease of swapping back if needed)
-----------------------------------------------------------
Add-on: Matter Server
Matter WebSocket Server for Home Assistant Matter support.
-----------------------------------------------------------
Add-on version: 8.1.1
You are running the latest version of this add-on.
System: Home Assistant OS 16.2 (amd64 / generic-x86-64)
Home Assistant Core: 2025.10.4
Home Assistant Supervisor: 2025.10.0
-----------------------------------------------------------
Please, share the above information when looking for help
or support in, e.g., GitHub, forums or the Discord chat.
-----------------------------------------------------------
s6-rc: info: service banner successfully started
s6-rc: info: service matter-server: starting
s6-rc: info: service matter-server successfully started
s6-rc: info: service legacy-services: starting
[09:49:10] INFO: Starting Matter Server...
s6-rc: info: service legacy-services successfully started
[09:49:11] INFO: Using 'eno1' as primary network interface.
[09:49:11] INFO: Successfully send discovery information to Home Assistant.
2025-10-28 09:49:14.776 (MainThread) INFO [matter_server.server.stack] Initializing CHIP/Matter Logging...
2025-10-28 09:49:14.776 (MainThread) INFO [matter_server.server.stack] Initializing CHIP/Matter Controller Stack...
[1761616154.803433][117:117] CHIP:CTL: Setting attestation nonce to random value
[1761616154.803856][117:117] CHIP:CTL: Setting CSR nonce to random value
[1761616154.804697][117:117] CHIP:DL: ChipLinuxStorage::Init: Using KVS config file: /tmp/chip_kvs
[1761616154.806022][117:117] CHIP:DL: Wrote settings to /tmp/chip_kvs
[1761616154.806238][117:117] CHIP:DL: ChipLinuxStorage::Init: Using KVS config file: /data/chip_factory.ini
[1761616154.806417][117:117] CHIP:DL: ChipLinuxStorage::Init: Using KVS config file: /data/chip_config.ini
[1761616154.806549][117:117] CHIP:DL: ChipLinuxStorage::Init: Using KVS config file: /data/chip_counters.ini
[1761616154.807695][117:117] CHIP:DL: Wrote settings to /data/chip_counters.ini
[1761616154.807706][117:117] CHIP:DL: NVS set: chip-counters/reboot-count = 6 (0x6)
[1761616154.808107][117:117] CHIP:DL: Got Ethernet interface: eno1
[1761616154.808355][117:117] CHIP:DL: Found the primary Ethernet interface:eno1
[1761616154.808599][117:117] CHIP:DL: Got WiFi interface: wlp0s20f3
[1761616154.808614][117:117] CHIP:DL: Failed to reset WiFi statistic counts
[1761616154.808619][117:117] CHIP:PAF: WiFiPAF: WiFiPAFLayer::Init()
2025-10-28 09:49:14.809 (MainThread) INFO [chip.storage] Initializing persistent storage from file: /data/chip.json
2025-10-28 09:49:14.809 (MainThread) INFO [chip.storage] Loading configuration from /data/chip.json...
2025-10-28 09:49:14.927 (MainThread) INFO [chip.CertificateAuthority] Loading certificate authorities from storage...
2025-10-28 09:49:14.927 (MainThread) INFO [chip.CertificateAuthority] New CertificateAuthority at index 1
2025-10-28 09:49:14.928 (MainThread) INFO [chip.CertificateAuthority] Loading fabric admins from storage...
2025-10-28 09:49:14.928 (MainThread) INFO [chip.FabricAdmin] New FabricAdmin: FabricId: 0x0000000000000002, VendorId = 0x134B
2025-10-28 09:49:14.928 (MainThread) INFO [matter_server.server.stack] CHIP Controller Stack initialized.
2025-10-28 09:49:14.928 (MainThread) INFO [matter_server.server.server] Matter Server initialized
2025-10-28 09:49:14.928 (MainThread) INFO [matter_server.server.server] Using 'eno1' as primary interface (for link-local addresses)
2025-10-28 09:49:14.929 (MainThread) INFO [matter_server.server.server] Starting the Matter Server...
2025-10-28 09:49:14.933 (MainThread) INFO [matter_server.server.helpers.paa_certificates] Skip fetching certificates (already fetched within the last 24h).
2025-10-28 09:49:14.933 (MainThread) INFO [chip.FabricAdmin] Allocating new controller with CaIndex: 1, FabricId: 0x0000000000000002, NodeId: 0x000000000001B669, CatTags: []
2025-10-28 09:49:15.011 (Dummy-2) CHIP_ERROR [chip.native.DIS] Failed to advertise records: src/inet/UDPEndPointImplSockets.cpp:417: OS Error 0x02000065: Network is unreachable
2025-10-28 09:49:15.033 (MainThread) INFO [matter_server.server.vendor_info] Loading vendor info from storage.
2025-10-28 09:49:15.044 (MainThread) INFO [matter_server.server.vendor_info] Loaded 361 vendors from storage.
2025-10-28 09:49:15.044 (MainThread) INFO [matter_server.server.vendor_info] Fetching the latest vendor info from DCL.
2025-10-28 09:49:16.726 (MainThread) INFO [matter_server.server.vendor_info] Fetched 360 vendors from DCL.
2025-10-28 09:49:16.727 (MainThread) INFO [matter_server.server.vendor_info] Saving vendor info to storage.
2025-10-28 09:49:16.736 (MainThread) INFO [matter_server.server.device_controller] Loaded 0 nodes from stored configuration
2025-10-28 09:49:16.752 (MainThread) INFO [matter_server.server.server] Matter Server successfully initialized.
My suspicion is that rather Thread than Matter is the problem, but if you want to make sure, it might be helpful to buy a cheap Matter-over-WiFi product (e.g., Nous oder Hama Smart Light Bulb, Sonoff MiniR4M, Meross MSS315) and check if that works.
You are using Android, right? I don’t know if there is an equivalent, but iOS has a - in my eyes - very simple “Home” App. I used this as a last resort for one or two devices (at least the Elko EP Thread Actor), which just did not want to connect to HA. If they were connected to the Home App (and the very same Thread network by the OTBR that HA uses), I could easily integrate them to HA (don’t select “new”, but “already in use” when adding the device).
I think the problem is the OTBR is repeatedly seeing RCP failures which suggests it is attempting to talk to the SLZB’s RCP and is unhappy with what it sees.
I don’t know much about this device, but I presume it has two paths for a protocol stack to talk to it since it is dual-protocol; Either two serial ports (via one USB) or two TCP/IP ports? Is it possible the OTBR is talking to the wrong port?
With the SLZB, I first tried to have it setup via USB to my HA server and it was/is detected etc, however the Thread network didn’t seem to connect so I changed the settings to use it via Network. The device still has the USB connected to the HA server. I used this guide.
Here’s the config I used for it in the OpenThread add-on:
Looking up that error the common issue is that when using a co-ordinator in multi-protocol its acting up. I would do a verification test to see if setting to Thread only mode will alleviate this issue. (this is one reason why I have dedicated co-ordinators in my setup instead of a multi setup just to prevent issues like this).
It looks like theres no option to disable a radio completely. I have the second radio (the one I’m not using for Matter over Thread) set to ZigBee coordinator but haven’t set it up in HA at all.
I have IPv6 somewhat sorted on my Unifi network, in that my HA server (and a number of other devices on my network) has been assigned an IPv6 address, but the SLZB-MR4 radio hasn’t even though IPv6 is enabled…
@sparkydave I am in the exact same situation as you, following this thread to see if you get it sorted. Just got my MR4U last night and haven’t made any real progress thus far.
I’m definitely close to having this working. Now that my IPv6 addresses are sorted, the Matter pairing progresses further. it was previously getting stuck at ‘checking network connectivity’, but noW it times out on ‘connecting device to home assistant’.
Matter addon log:
2025-11-07 11:23:01.376 (MainThread) INFO [matter_server.server.device_controller] Starting Matter commissioning using Node ID 1 and IP fdeREDACTED.
2025-11-07 11:23:03.804 (Dummy-2) INFO [chip.ChipDeviceCtrl] Established secure session with Device
2025-11-07 11:23:54.917 (Dummy-2) CHIP_ERROR [chip.native.EM] <<5 [E:40456i with Node: <0000000000000001, 1> S:5164 M:163573096] (S) Msg Retransmission to 1:0000000000000001 failure (max retries:4)
2025-11-07 11:24:04.253 (Dummy-2) CHIP_ERROR [chip.native.CTL] Error on commissioning step 'SendComplete': 'src/app/CommandSender.cpp:354: CHIP Error 0x00000032: Timeout'
2025-11-07 11:24:04.254 (Dummy-2) WARNING [chip.ChipDeviceCtrl] Failed to commission: src/app/CommandSender.cpp:354: CHIP Error 0x00000032: Timeout
2025-11-07 11:24:04.255 (MainThread) ERROR [matter_server.server.client_handler] [140714300690544] Error while handling: commission_on_network: Commissioning failed for node 1.
2025-11-07 11:26:29.926 (MainThread) INFO [matter_server.server.device_controller] Starting Matter commissioning using Node ID 2 and IP fdREDACTED.
2025-11-07 11:26:31.265 (Dummy-2) INFO [chip.ChipDeviceCtrl] Established secure session with Device
2025-11-07 11:27:09.394 (Dummy-2) CHIP_ERROR [chip.native.EM] <<5 [E:40462i with Node: <FFFFFFFB00000000, 0> S:5165 M:237109614] (S) Msg Retransmission to 0:FFFFFFFB00000000 failure (max retries:4)
2025-11-07 11:27:18.425 (Dummy-2) CHIP_ERROR [chip.native.CTL] Error on commissioning step 'SendPAICertificateRequest': 'src/app/CommandSender.cpp:354: CHIP Error 0x00000032: Timeout'
2025-11-07 11:27:52.368 (Dummy-2) CHIP_ERROR [chip.native.EM] <<5 [E:40463i with Node: <FFFFFFFB00000000, 0> S:5165 M:237109616] (S) Msg Retransmission to 0:FFFFFFFB00000000 failure (max retries:4)
2025-11-07 11:28:04.125 (Dummy-2) WARNING [chip.ChipDeviceCtrl] Failed to commission: src/app/CommandSender.cpp:354: CHIP Error 0x00000032: Timeout
2025-11-07 11:28:04.125 (MainThread) ERROR [matter_server.server.client_handler] [140714176215376] Error while handling: commission_on_network: Commissioning failed for node 2.
After hours of using ChatGPT to try and problem solve things, I’m STILL getting this error in the Matter addon log:
(Dummy-2) CHIP_ERROR [chip.native.DIS] Failed to advertise records: src/inet/UDPEndPointImplSockets.cpp:417: OS Error 0x02000065: Network is unreachable
Which basically means it wont work from what ChatGPT tells me, which seems fair.
Any ideas what I can look at next? (something to do with my UDM Pro firewall settings maybe?)
I was about ready to launch the Matter door lock into outer space after HOURS of ChatGPT and Googling to try and get things to work, but I finally had success.
As long as the IPv6 stuff is sorted, I found the below worked.
@sparkydave so I was able to get it working by flashing the CC2674P10 chip to be the Matter-over-Thread one, using the older 20240727 firmware. Now it all connects without issue. If yours is working using the other chip that’s great too!
