Matter / Thread pairing with Cisco LAN / Wifi

Hello everyone,

i need some help with understanding how Thread / Matter communication works.

From reading other posts here seems that if the setup is anything but a flat easy one device network you run into issues…

Now for the most anoying part i managed to add one device but i’m not able to add any more…

The device is a eve energy plug the exact same model that already is paired…

Some pitfalls i already have cleared:

  • HA / phone / M-T device all on the same VLAN
  • IPv6 enabled in HA
  • updated everything i possibly could
  • companion app credentials sync

Version:

Add-on: OpenThread Border Router
OpenThread Border Router add-on

Add-on version: 2.15.3
You are running the latest version of this add-on.
System: Home Assistant OS 16.3 (amd64 / generic-x86-64)
Home Assistant Core: 2025.12.4
Home Assistant Supervisor: 2025.12.3

Infastructure:

Homeassistant running on a dedicated server only one nic.

Core#sh ipv6 neighbors 
IPv6 Address                              Age Link-layer Addr State Interface
FC00:10:80:10::201                         39 9c6b.00a7.ea60  STALE Vl80        <-- HA ULA
FE80::6A25:DDFF:FE2E:92EF                   8 6825.dd2e.92ef  STALE Vl80        <-- SLZB-MR2
FE80::7459:F6FF:FEBC:8A5                    8 7659.f6bc.08a5  STALE Vl80        <-- Phone with APP
FE80::BCCB:5C6E:F0AB:FFCC                   0 9c6b.00a7.ea60  REACH Vl80        <-- HA LLA

So i assume it should not be an IPv6 issue.

So from my understanding:

  1. Phone connects with bluetooth to M-T device
  2. Thread border router commisions device via phone BT ?
  3. device should join thread network.

Since it is Matter over Thread and not over Wifi, the device should not connect to wifi at any point, correct?

If i go into OTBR debug i can see the device connected to that OTBR and i can use it so it is connected correctly and everything is working…

[D] RadioSelector-: RadioSelector: SelectRadio 15.4 - neighbor:[da67f7972fe1354e rloc16:0x4400 radio-pref:{15.4:255} state:Valid]

So at this point i’m assuming it is an mDNS issue that somehow was not present on the first device ?!

i can see the following services published:

Core#sh mdns service-types interface vlan 80

                                                    mDNS SERVICES 
==============================================================================================================================
[<NAME>]                                              [<TTL>/Remaining] [If-name]


_home-assistant._tcp.local                              4500/905        Vl80

_mass._tcp.local                                        4500/905        Vl80

_http._tcp.local                                        4500/905        Vl80

_trel._udp.local                                        4500/3898       Vl80

_meshcop._udp.local                                     4500/3901       Vl80

_matter._tcp.local                                      4500/3912       Vl80

_FC9F5ED42C8A._tcp.local                                4500/4087       Vl80

_sendspin-server._tcp.local                             4500/906        Vl80

If i look at what exactly was seen:
I can see services from my phone aswell as HA and the OTBR.

Core#show mdns cache 

                                                    mDNS CACHE 
=================================================================================================================================
[<NAME>]                                             [<TYPE>][<CLASS>] [<TTL>/Remaining] [Accessed] [If-name] [Mac Address] [<RR Record Data>]


_mass._tcp.local                                        PTR     IN      4500/3123       9       Vl80    9c6b.00a7.ea60  xxxxxxxxxxxxxxxxxxxxxxxxxxxx._mass._tcp.local           

xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx._mass._tcp.local      TXT     IN      4500/3123       10      Vl80    9c6b.00a7.ea60  (191)'server_id=xxxxxxxxxxxxxxxxxxxxxxxx''server_version=2.7.2''schem~'~

_home-assistant._tcp.local                              PTR     IN      4500/3154       18      Vl80    9c6b.00a7.ea60  Home._home-assistant._tcp.local                             

Home._home-assistant._tcp.local                         TXT     IN      4500/3154       10      Vl80    9c6b.00a7.ea60  (188)'location_name=Home''uuid=xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx''version=2025~'~
                           
_services._dns-sd._udp.local                            PTR     IN      4500/4274       1       Vl80    7659.f6bc.08a5  _FC9F5ED42C8A._tcp.local                                    

homeassistant.local                                     AAAA    IN       120/92         1       Vl80    9c6b.00a7.ea60  FC00:10:80:10::201

_services._dns-sd._udp.local                            PTR     IN      4500/3933       2       Vl80    9c6b.00a7.ea60  _trel._udp.local                                            

_trel._udp.local                                        PTR     IN      4500/3933       22      Vl80    9c6b.00a7.ea60  debd3b5d350eb3a7._trel._udp.local                           

_services._dns-sd._udp.local                            PTR     IN      4500/3941       2       Vl80    9c6b.00a7.ea60  _meshcop._udp.local                                         

_meshcop._udp.local                                     PTR     IN      4500/3977       10      Vl80    9c6b.00a7.ea60  Home Assistant OpenThread Border Router #B3A7._meshcop._udp.

debd3b5d350eb3a7._trel._udp.local                       TXT     IN      4500/3933       2       Vl80    9c6b.00a7.ea60  (24)'xa=^=;]5^N3'''xp=z&E^FLt3^R'

Home Assistant OpenThread Border Router #B3A7._mes    TXT     IN      4500/3929       12      Vl80    9c6b.00a7.ea60  (147)'rv=1''id=^]wW^K          ''vn=Home Assistant''mn=OpenThread Border Route~'~

Home Assistant OpenThread Border Router #B3A7._mes    TXT     IN      4500/3941       2       Vl80    9c6b.00a7.ea60  (192)'rv=1''id=^]wW^K          ''vn=Home Assistant''mn=OpenThread Border Route~'~

_services._dns-sd._udp.local                            PTR     IN      4500/3950       2       Vl80    9c6b.00a7.ea60  _matter._tcp.local                                          

_I05FB436DBADAB9E9._sub._matter._tcp.local              PTR     IN      4500/3950       2       Vl80    9c6b.00a7.ea60  05FB436DBADAB9E9-1BA7B12EC3C96121._matter._tcp.local        

_matter._tcp.local                                      PTR     IN      4500/3950       18      Vl80    9c6b.00a7.ea60  05FB436DBADAB9E9-1BA7B12EC3C96121._matter._tcp.local        

_I11F6143C71F51155._sub._matter._tcp.local              PTR     IN      4500/3950       2       Vl80    9c6b.00a7.ea60  11F6143C71F51155-0000000000000001._matter._tcp.local        

_matter._tcp.local                                      PTR     IN      4500/3950       18      Vl80    9c6b.00a7.ea60  11F6143C71F51155-0000000000000001._matter._tcp.local        

05FB436DBADAB9E9-1BA7B12EC3C96121._matter._tcp.loc      TXT     IN      4500/3950       2       Vl80    9c6b.00a7.ea60  (27)'SII=2000''SAI=2000''SAT=4000'
          
11F6143C71F51155-0000000000000001._matter._tcp.loc      TXT     IN      4500/3950       2       Vl80    9c6b.00a7.ea60  (27)'SII=2000''SAI=2000''SAT=4000'

11F6143C71F51155-000000000001B669._matter._tcp.loc      TXT     IN      4500/3950       2       Vl80    9c6b.00a7.ea60  (4)'T=2'

_services._dns-sd._udp.local                            PTR     IN      4500/4321       1       Vl80    9c6b.00a7.ea60  _home-assistant._tcp.local                                  

_services._dns-sd._udp.local                            PTR     IN      4500/4321       1       Vl80    9c6b.00a7.ea60  _sendspin-server._tcp.local                                 

_sendspin-server._tcp.local                             PTR     IN      4500/4321       5       Vl80    9c6b.00a7.ea60  0e7d0d4a576946bd92ea4124c5998fb4._sendspin-server._tcp.local

0e7d0d4a576946bd92ea4124c5998fb4._sendspin-server.      TXT     IN      4500/4321       1       Vl80    9c6b.00a7.ea60  (15)'path=/sendspin'

The message on the app gets stuck at the usual “connecting to thread network” the one after sending the credentials…

Question is there something missing that i should see ?
Or is someone else running a Cisco switch and can post me his output ?

Thanks

OTBR is a router, so it just routes IP packets, it doesn’t commission anything.

My understanding from the Matter spec is that it works like this:

  1. Phone uses Bluetooth to authenticate with the device (via the barcode or passcode)
  2. Phone sends the device credentials to join the network (WiFi or, in your case, Thread). NOTE: for WiFi, the phone must be on that WiFi SSID to provide credentials; for Thread the phone must have the credentials stored in its local password database (keychain/play services). There is no UI to select which Thread credentials to use if more than one dataset is stored on the phone.
  3. Device joins the network, and assigns itself an IP (per IPv6 spec). At a minimum it will have a fe80 LLA, but Thread devices must also have a fdxx ULA on the subnet announced by the border router. There is no need for WiFi devices to have a ULA or GUA.
  4. “Phase 2” commissioning begins between the device and the Matter server using IPv6 networking only. At this point the only difference between WiFi and Thread is the extra router hop of the Thread Border Router.
  5. Using mDNS, the device announces _matterc._udp.local (note the c for commissioning) service with its address information, and the server should see this and use it to start a secure session with the device. NOTE: If the TBR or WiFI device are separated from the Matter server by another router (i.e. vlan separation), the mDNS may not arrive.
  6. The Matter server (not the device, nor the phone) performs an attestation certification check to confirm the device is authentic and safe. At no point should the device (or the phone) require the Internet during commissioning.
  7. The device joins the Matter fabric and the server queries all the endpoints
  8. The Matter server sends the device/entity information to HA (Matter Integration) using a TCP websockets connection over IPv4 or IPv6 (usually localhost).

Some tips:

  • Home Assistant now has a built-in “Zeroconf Browser” (Settings → System → Network) to show you what mDNS announcements make it to the server; it also shows the IP addresses of the Thread device which you can verify its network connectivity via ping6 commands. If you never see the _matterc._udp.local service then the device is likely failing to join the Thread mesh.
  • If your phone has >1 Thread credentials dataset then you may need to delete one (or all) of them to commission successfully, or try a different phone. There is also an option of “direct commissioning” without a phone if the Matter server has its own dedicated bluetooth dongle (i.e. not shared with HA).
  • Your Matter server should have an IPv6 route to the Thread subnet; you can verify via ip -6 route command to find your Thread ULA subnet and verify the TBR is the “next-hop” address (or wpan0 for locally-hosted OTBR).
  • The commissioning window only says open a few minutes and if it fails, the device must be factory reset so you can start again from step 1 using the code. Matter doesn’t have a way to continue commissioning from Phase 2.
1 Like

Not a biggy, but AFAIK, the mobile device actually does go through a Thread commissioning process not only with the device but also with the BR in what Thread calls “External Thread Commissioning”. I think that is one of the reasons why a mobile device that has stored the Thread dataset also associates it with a BR.

1 Like

Thank you so much for that great write up… for some reason all the information on the internet goes into so many details and is not clearly structured…

There is no UI to select which Thread credentials to use if more than one dataset is stored on the phone.

_matterc._udp.local

I only saw announcements without “c” in my infrastructure… So that tip was gold, it had to be an issue with the credentials or something since i have a working device active in the thread fabric. Switched phones from a pixel to some older samsung and device seems to join the fabric now at least i can the the “c” announcements. Why the pixel did not work despite removing caches reinstalling apps no one knows.

_matterc._udp.local                                     PTR     IN      4500/3958       9       Vl80    9c6b.00a7.ea60  2C54A98B88B3699C._matterc._udp.local                        

2C54A98B88B3699C._matterc._udp.local                    TXT     IN      4500/4440       1       Vl80    9c6b.00a7.ea60  (121)'VP=4874+80''DT=266''DN=Eve Energy''SII=2000''SAI=2000''SAT=4000''D=1784''CM=~'~

This gets announced via mDNS from the OTBR.
Based on your explanation matter server should now see this and register the device.

That did not happen, as far as i can see and only one device (the old one) is active, so i’m now stuck at step 7. Probably just broke it trying to figure this out going to reinstall it and see if it works then.

The commissioning window only says open a few minutes and if it fails, the device must be factory reset so you can start again from step 1 using the code. Matter doesn’t have a way to continue commissioning from Phase 2.

Good to know so in my case this needs a reset on the next try !

Thanks again for taking the time appreciate it.

I reinstalled the matter server but yeah this is not working…


I can see the devices but seems that they can’t reach the matter server or something else is broken… I’m really not sure if this shouldn’t be beta software comparing to zigbee or similar…

Now i’m back to 0 working devices…

Home Assistant Supervisor is running!
System information:
  IPv4 addresses for enp1s0: 10.80.10.201/24
  IPv6 addresses for enp1s0: fc00:10:80:10:9c64:6b28:4112:270c/64, fe80::bccb:5c6e:f0ab:ffcc/64

  OS Version:               Home Assistant OS 16.3
  Home Assistant Core:      2025.12.4

  Home Assistant URL:       http://homeassistant.local:8123
  Observer URL:             http://homeassistant.local:4357

System is ready! Use browser or app to configure.
2026-01-03 12:10:24.921 (MainThread) INFO [matter_server.server.server] Using 'enp1s0' as primary interface (for link-local addresses)
fc00:10:80:10::/64 dev enp1s0  metric 100 
fd37:27c2:ab61:7086::/64 dev wpan0  metric 64 
fd3a:c99e:82ff:1::/64 dev wpan0  metric 64 

routes are there as well.

2026-01-03 13:16:16.081 (MainThread) DEBUG [matter_server.server.device_controller.mdns] Discovered commissionable Matter node: AsyncServiceInfo(type='_matterc._udp.local.', name='1625DDE57DB28F1B._matterc._udp.local.', addresses=[], port=5540, weight=0, priority=0, server='664647DA9DCA145F.local.', properties={b'VP': b'4874+80', b'DT': b'266', b'DN': b'Eve Energy', b'SII': b'2000', b'SAI': b'2000', b'SAT': b'4000', b'D': b'3293', b'CM': b'1', b'RI': b'0200B93F47CC0DA68B091789F9ABD22B1A3E', b'PH': b'36', b'PI': None}, interface_index=None)
2026-01-03 13:17:59.672 (ThreadPoolExecutor-0_0) DEBUG [matter_server.server.storage] Saved data to persistent storage

then just nothing happens…
was looking forward to the new ikea stuff but maybe i should cut my losses and go back to zigbee…

During commissioning using Companion App, do you see anything in the Matter Server Logs that say something like “Commission on network” or possibly “Commission with code”?

Since the _matterc._udp advertisements are showing up, it should mean that the device has successfully connected to its network and is available for commissioning. There are however two phases to the commissioning:

  1. The mobile device does the QR code based commissioning with itself. AFAIK, the mobile device is also looking for _matterc._udp
  2. After #1, the mobile device does a “Share” to the HA Matter server which should trigger HA’s Matter Server to start a commissioning session, and it then looks for _matterc._udp
1 Like

Thanks good to know !
So the phone needs to see the mDNS announcements.
I assume it does not see them that would explain why nothing is happening, when the app should share details with the matter server. I mean get an error in the app as well but it always the same.

I don’t see anything in the matter server logs that would hint on it doing a “Commission”.

Only couple of things I can think of is to check the IPv6 of the mobile device to see if it is on the IPv6 network as HA, and check to see if the mobile device is getting these mDNS advertisements which may require another App on the mobile device.

1 Like

Phone was on the same network.
But i have found the issue thanks to your tip that the phone need the mDNS announcements as well.

So for everyone who will be reading this in the future:
The issue was with Cisco WLC 9800 using the mDNS gateway feature on the WLC only predifined mDNS services gets forwarded. Matter stuff is not included in there, thats why it does not show up anywhere in the wifi infrastructure, it probably is possible to add everything but there is another way. To have that function with Cisco WLC, APs need to be placed in flex connect mode with local switching. Create a SSID in the same VLAN where you have your homeassistant.

In the SSID settings check mDNS Mode : Bridging
image
In global setting mDNS gateway needs to be disabled


flex connect settings:
image
this does not need to be set.

Thanks to everyone for the support :slight_smile:

1 Like