#How to troubleshoot issues with Matter/Thread pairing process?

1 messages · Page 1 of 1 (latest)

lone wing
#

I'm new to Matter and Thread and I can't get commissioning process to work no matter what I try. I've tried doing it through the Android app and using the bluetooth adapter on the HA server (through the Matter Server web ui).

On Android it always fails like this: Connecting ... Generating Credentials ... Checking connectivity to Thread network ha-thread-something ... and then it always fails with "Can't reach device. Make sure your phone is connected to Wi-Fi"

I want to try digging deeper to find the cause but I'm not familiar with Matter/Thread commissioning process. That error message doesn't give me much to go on, Is the Matter device failing to connect to OTBR? Is my phone trying and failing to connect to the Matter server? to OTBR?

I'd appreciate any tips or guidance.

My setup is like this:

  • HomeAssistant OS running in a Proxmox VM
  • SMLight SLZB-MR3U adapter connected over USB (just to rule out any networking issues between OTBR and the adapter)
  • Phone connected to wifi which is on the same subnet and VLAN as HAOS

So far I've:

  • performed the "Sync Thread credentials" in the HA app and get the expected message: "✅ Home assistant and this device use the same network"
  • tried disabling OTBR firewall in add-on settings
  • tried enabling "beta" mode in OTBR add-on settings
  • SSH'd into my HA server and successfully pinged my phone's link-local IPv6 address: ping fe80::aa:bbb:cccc:dddd%enp6s18 (I'm not sure how ipv6 connectivity plays into this with matter/thread)

Previous discussion: #1468620644936581273 message

lone wing
#

@plush vapor I got it working, it was a networking issue unrelated to the adapter (but I'll still have to see how well that works over ethernet, I'm using it over USB at the moment)

#

I thought I wasn't blocking anything but then to make triple sure I went into Proxmox Firewall settings and noticed that "Router advertisement" was set to "No" (blocked, I assume)

#

Once I changed it to "Yes" the commissioning worked

sterile ocean
#

Great find for Proxmox users

spare mantle
#

yep, checking whether the phone was receiving the router announcements from the TBR was the first thing i would have recommended checking from your original post. For anyone else hitting a similar issue, check to make sure the phone receives an ipv6 address that starts with fd

lone wing
#

For more technically inclined, you can also check whether you're receiving router advertisements using Wireshark
And making sure that everything is on the same broadcast domain (VLAN), at least for debugging

#

from your LAN (phone/PC) you should be able to ping Thread Border Router's IPv6 address

#

And I'd recommend using a known-good bluetooth adapter, connecting it to the HA host, and commissioning the device without using your smartphone at all:
https://www.matteralpha.com/how-to/how-to-use-home-assistant-to-add-matter-devices-without-phone

Matter Alpha

Skip phone pairing woes with Home Assistant's hidden Matter setup. This guide details using Bluetooth/Thread dongles to add devices directly, bypassing app bugs and platform limits.

#

Although as soon as I unblocked Router Advertisements, I successfully commissioned the device - but I still had to use an older non-grapheneos android smartphone, that's a whole another story

lone wing
#

Some notes on that:

Requirements:

# With the Matter device in pairing mode:

# 1. Pairing:
# Contacts the device over BLE, joins it to the Thread network, commissions it into a Matter fabric operated by `chip-tool`
# <NODE_ID> is an arbitrary integer
# expected output in logs: "Device commissioning completed with success"
# Bypasses attestation because we don't have a production CA database

chip-tool pairing code-thread <NODE_ID> hex:<THREAD_DATASET> <11_DIGIT_PAIRING_CODE> --bypass-attestation-verifier true

# 2. Transfer:
# Opens "commissioning window" on the device, using "Basic commissioning method" for 600 seconds to allow a different Matter commissioner (e.g. HomeAssistant Matter server) to commission it
# expected output in logs: "Successfully opened pairing window on the device"

chip-tool pairing open-commissioning-window <NODE_ID> 0 600 1000 0
#

Once the commissioning window reopens, go to Matter Server web UI, hit "commission existing device", and enter the pairing code. The device should be successfully added.
Here I'm using the "beta" version of Matter server but I think it should work in both, I'm using the beta version because it has a network map

#

The point of all this is to get the Matter device connected to the Thread network in step 1 which requires bluetooth, and once it's in the Thread network, HA Matter Server can talk to it via IPv6 and "adopt" it without using bluetooth

spare mantle
#

that's the exact same process as performed using the phone commissioning flow, fwiw, except there it is done using the matter stack provided by the phone os / google play services.

lone wing
#

interesting, thanks. Yeah I had no idea what's going on behind the scenes on android. If Google used its infinite wisdom to say "Timed out waiting for Router Advertisement" somewhere I wouldn't have wasted 2 days chasing that issue down :/

spare mantle
#

it really should be returning a "no route to device" error :/

#

(that error probably is happening internally, it's just not displaying it in the ui)

lone wing
#

I wish HA didn't rely on google play services for this. Do you know if Matter is difficult enough to implement that it's worth the trade-offs with Play services and google account requirements?

#

it seems like a reaaaally unfortunate dependency to have in a system lika HA

spare mantle
#

it's not impossible to do in an app, but this choice was made to significantly speed up development of matter support in HA by using the vendor-provided solution instead of needing to build something to do it themselves.

#

it's pretty much only folks using grapheneos who have a problem with it, since it requires doing ble discovery and communication plus some lower level network discovery; also access to things like wifi and thread credentials which are stored in os level keyrings.

#

a benefit of using the os stuff is that it will work with thread border routers from other vendors, assuming the vendor app has loaded the thread credentials into the os keyring

#

a HA-specific app would only work with home assistant's border router (or potentially other systems implementing the OTBR apis)

lone wing
#

Yeah I'm sure it generally works fine, but for me (and likely most people, I would assume) the point of using HomeAssistant is to have an independent system that isn't subject to whims and reliability issues of some external entity.
Now that I know how to commission devices without a smarphone I think it's good enough, but if the only way I could commission a Matter device was by using Google play services I would just avoid the ecosystem entirely

#

Most users probably don't even know they have a hidden dependency on Google when they use Matter through HA

#

If Google has some technical issues or your internet goes down, you lose the ability to commission Matter devices on your local network managed by your local HA instance... that would be a non-starter for me personally (if this alternative didn't exist)

#

interesting point about using TBR's from other vendors... don't all of them implement the same APIs?

#

if you purchased one from IKEA or Google or whomever, wouldn't you just add their integration in HA, it would show up here, and then the process should be the same from here onwards?

#

and whichever border router has the phone+key symbol is the one that's used by the mobile app when pairing new devices

spare mantle
#

no, that's not how it works. There is no integration for having HA talk to thread border routers from other vendors.

#

all thread border routers provide some standard apis used for certain things, but "retrieving the thread network credentials" isn't something that got standardized until thread 1.4 (which hasn't been widely adopted yet)

#

the thread 1.4 stuff requires user interaction to share the thread border router credentials in some cases, so it needs some work on the home assistant side too (will need to be a form in ha to enter a passcode provided by the thread border router or vendor app)

plush vapor
# lone wing I thought I wasn't blocking anything but then to make triple sure I went into Pr...

Dude!! Nice that you got it working just came to the discord to check issues I'm now running into with the MR5U and I probably have discovery stuff disabled on my unifi router. I'll have to check it tomorrow. So far I've tried using it via PoE as I would need to disassemble my main Home Assistant box to get to a usb port ... I designed it mainly for looks and not upgradeability ...

lone wing
#

FWIW both Zigbee and Matter have worked fine over ethernet for me so far

#

once I got it working over USB I switched to ethernet without issues, stable 1-2ms ping from HA server to MR3U adapter, but I only have a couple of Matter and Zigbee devices right now

plush vapor
#

Nice, I'll get to mine later. My current setup is roughly 45 Zigbee devices and one Matter device

#

And 12 Homematic I'm also going to try via the MR5U

plush vapor
#

Urgh, I don't know what happened but it seems my OTBR no longer works the app keeps stopping.

#

Huh, was there an OTBR update yesterday? I'm basically running into this which was just posted too ...

#
#

Did yours decide to crash out today too? @lone wing

lone wing
#

I'll try updating now

lone wing
#

seems to be working fine after updating as well

plush vapor
#

Hmm strange.

lone wing
#

I did see something vaguely similar with Zigbee at some point (software failed to "initialize" the adapter on startup, whilst I had it connected over USB too), but it myseriously went away after a few z2mqtt server restarts

plush vapor
#

Looking into it more I probably should have gotten a SMHUB instead that one is Linux base and runs Z2M an a OTBR on device.

#

Wouldn't even have cost more though seems a bit Alpha/Beta stage

lone wing
#

I didn't even know that existed... hmm

plush vapor
#

Yeah me neither

#

Not the pretties device to have somewhere openly but that's a general SLZB problem

#

That modular approach to radios would be a nice addition to the next nabu casa home assistant main device

lone wing
#

I think I'd go back to simpler USB adapters before I went with SMHUB though

#

SMHUB would probably add even more proprietary ... stuff that I'd rather not deal with. If it's proprietary it better work flawlessly and I'm sure that it doesn't

plush vapor
#

yeah also true ... just adds more things that could fail

#

two ZBT-2 might have been the better choice ... though then the Server has to be somewhere not the cellar

lone wing
#

Yeah mine is in the basement, though a few hardwired devices should theoretically bridge the gap across the house

lone wing
#

do your logs also mention "universal_silabs_flasher"?

#

half-guessing, but maybe OTBR add-on is trying to flash firmware which is not a supported operation on the SLZB (?)

#

actually no, that's not it

#

I see this instead, it sends the same data but mine receives a reply, yours doesn't.

2026-02-12 16:10:20 homeassistant serialx.descriptor_transport[253] DEBUG Immediately writing b'~\x80\x01\x02\xea\xf0~'
2026-02-12 16:10:20 homeassistant serialx.descriptor_transport[253] DEBUG Sent 7 of 7 bytes
2026-02-12 16:10:20 homeassistant serialx.descriptor_transport[253] DEBUG Event loop woke up reader
2026-02-12 16:10:20 homeassistant serialx.descriptor_transport[253] DEBUG Received b'~\x80\x06\x00p\xeet~'
#

i'm assuming you've tried restarting the SLZB

plush vapor
#

after reflashing and a bunch of other things just removing power completely has it back in the routers so app is running still need to figure out network settings though as that doesn't work yet.

plush vapor
#

Yeah this is no fun ... I have no idea where things are going wrong.

#
s6-rc: info: service otbr-agent-rest-discovery successfully started
s6-rc: info: service legacy-services: starting
s6-rc: info: service legacy-services successfully started
00:00:27.233 [N] Mle-----------: RLOC16 3000 -> fffe
00:00:27.777 [N] Mle-----------: Attach attempt 1, AnyPartition reattaching with Active Dataset
00:00:34.279 [N] RouterTable---: Allocate router id 12
00:00:34.279 [N] Mle-----------: RLOC16 fffe -> 3000
00:00:34.283 [N] Mle-----------: Role detached -> leader
00:00:34.286 [N] Mle-----------: Partition ID 0x67eeea41
[NOTE]-BBA-----: BackboneAgent: Backbone Router becomes Primary!
00:00:35.834 [W] DuaManager----: Failed to perform next registration: NotFound
Default: mDNSPlatformSendUDP got error 99 (Cannot assign requested address) sending packet to ff02::fb on interface fe80::.............. (this line keeps repeating)
plush vapor
#

Yeah now I get "Can't connect to thread network ..." "Check that your device can work with this network type and try again."

#

Alternatively I'll get "Can't reach device" "Make sure your phone is connected to Wi-Fi"

lone wing
#

...i think, I'll check tomorrow if they're the same exact messages...

plush vapor
#

It's probably something about my network setup but just having one matter device also has me doubting it though I did see a video of this specific device being used without issue so I'm fairly certain it should be fine.

#

I'll step back from this for a while there's so much else to do and I wasted too much time on this.

#

It's an IKEA ALPSTUGA in case it matters to anyone

plush vapor
#

huh ... I just noticed the name it's trying to connect to of the thread network shown while pairing and on the website are not the same ... I've synced the credentials repeatedly no idea why that would be different

#

I've cleared my app data reinstalled it on my phone still using some old thread network credentials it seems ... where is this store on the phone

plush vapor
#

OK it's finally connected ... Had to clear all Google Play Services Cache and Data since that kept the old information ... probably all the network things I did were pointless and connecting via USB is probably also not the problem.

plush vapor
#

I get that this is probably caused by some Google nonsense but it should be easy enough for the Home Assistant App to just also store the credentials locally and then compare with what is actually used during pairing to give a better error message.

#

Now to undo the network changes and try again and after that move to PoE again and try once more ... but maybe some sleep first.