Matter‑over‑Thread commissioning stalls after successful Thread attach for Eve Thermo gen5(ULA routing and mDNS verified)

fazkoenig · April 18, 2026, 4:13pm

Summary

Matter‑over‑Thread commissioning does not progress beyond discovery when using Home Assistant as the first Matter commissioner, even though:

Thread attach is successful
ULA (fdxx::/64) routing is correct end‑to‑end
OTBR advertises the Thread prefix correctly
Matter Server binds IPv6 and mDNS correctly
_matter._tcp services are advertised and visible

This issue report documents a fully verified IPv6/Thread/Matter setup where commissioning still does not proceed, to help clarify whether this is an expected device limitation, a documentation gap, or a controller limitation.

Environment

Home Assistant

Home Assistant OS: 17.2 (amd64 / qemux86‑64)
Home Assistant Core: 2026.4.3
Home Assistant Supervisor: 2026.04.0

Matter / Thread

Matter Server add‑on: 8.4.0
- JavaScript Matter Server (beta)
OpenThread Border Router add‑on: enabled
Thread radio: Home Assistant Connect ZBT‑2
Primary network interface: enp0s3
Thread interface: wpan0

Device

Matter‑over‑Thread device (thermostat class)
No Wi‑Fi
Thread‑only
Commissioned attempts via:
- Home Assistant (manual Matter code)
- Android phone
- iPhone (no Apple Thread Border Router present)

What works (verified)

1. Thread attach and operation

From OTBR logs:

Device sends Discovery Request
Parent Request / Parent Response
Child ID assigned
Device becomes Thread child
Stable RSSI and polling
IPv6 addresses assigned
Child supervision active

2. Thread ULA prefix is advertised

OTBR repeatedly advertises a ULA prefix, e.g.:

fdc7:8758:d54e:1::/64

Prefix is inside fc00::/7
Advertised via Router Advertisements
Seen on both wpan0 and infrastructure interface

3. HA host IPv6 routing is correct

ip -6 route on the HA host shows:

Thread ULA routed via wpan0
Same ULA reachable via infrastructure (enp0s3) through OTBR
Default IPv6 route present
No missing or black‑holed fc00::/7 routing

4. Matter Server networking is correct

From Matter Server startup logs:

Binds IPv4 and IPv6 mDNS sockets
Multicast bound on correct interface (enp0s3)
Thread dataset successfully injected into Matter Server
Controller starts successfully
Fabric loads correctly
_matter._tcp operational service is advertised

5. `_matter._tcp` advertised by device

On the Thread side, the device:

Registers via SRP
Advertises _matter._tcp.default.service.arpa

This confirms the device is commissionable and reachable on Thread.

What does NOT work

Matter commissioning does not progress

When starting commissioning via Add device → Add using Matter code:

Matter Server logs show:

Initiating discovery of node with discriminator XX

but never show:

commission_with_code
Opening PASE session
CASE exchange
Operational credentials installed

The Home Assistant UI remains stuck at:

“Checking Thread connection”

even though Thread attach is already complete.

Expected behavior

After successful Thread attach and discovery:

Matter Server should initiate a PASE session
Proceed with commissioning
Or clearly fail with a descriptive error if the device rejects HA as first commissioner

Actual behavior

Discovery starts
Device is visible and reachable on Thread
Commissioning does not start
No error is surfaced
Process stalls indefinitely

Additional notes / hypothesis

All networking layers have been verified as working:

Thread
IPv6 ULA routing
OTBR border routing
mDNS (IPv4 + IPv6)
Matter Server binding and controller startup

This suggests the remaining cause is not networking, but one of:

A device‑side restriction (device does not allow Home Assistant to be the first Matter commissioner)
A Matter Server / controller limitation in Thread‑only first‑commissioner scenarios
A documentation gap where certain devices require an external ecosystem (e.g. Apple Thread Border Router) for initial commissioning

If this behavior is expected, clarification in documentation would be very helpful, as the current UX suggests the setup should work.

Logs

Relevant logs available on request:

OTBR logs showing Thread attach + RA
ip -6 route output from HA host
Matter Server startup logs (IPv6/mDNS binding, controller start)
Matter commissioning attempt logs

Question to maintainers

Is Home Assistant expected to be able to commission Thread‑only Matter devices as the first controller?
If not, should this be documented more explicitly (and surfaced in the UI)?
If yes, is there a known limitation or missing step in the Matter Server / controller flow?

DocMarc73 · April 18, 2026, 4:28pm

What does it say, when you put in “ha docker info” in the Terminal?

fazkoenig · April 18, 2026, 4:43pm

enable_ipv6: null
logging: journalid
mtu: null
registrries: {}
storage: overlay2
version: 29.3.1

does that say anything its not docker its a VM on an Ugreen nas?

DocMarc73 · April 18, 2026, 10:13pm

Okay, so you have to enable ipv6 forwarding manually in the terminal:

ha docker options --enable-ipv6=true

restart HA.

Has got nothing to do with HA not running in a docker. IPv6 forwarding was disabled in one of the latest updates.

fazkoenig · April 19, 2026, 7:16am

did unfortunately not help . i checked “sysctl net.ipv6.conf.all.forwarding” as well and ipv6 forwarding is enabled.
To me this seems like a software error.
Thread is working, polling and even registering the matter.tcp.

But the handover to matter seems silent. Not a single log to be found in matter server logs… Matter is not even trying to add anything at all it seems…

00:05:05.990 [I] SrpServer-----: Received DNS update from fd72:4834:3272:dfe5:4a12:ebf0:451c:72b1
00:05:05.996 [I] SrpServer-----: Processed SRP update info
00:05:05.996 [I] SrpServer-----: Host:7E471208FAB211A3.default.service.arpa.
00:05:05.996 [I] SrpServer-----: Lease:7200, key-lease:1209600, ttl:7200
00:05:05.996 [I] SrpServer-----: 1 host address(es):
00:05:05.996 [I] SrpServer-----: fdc7:8758:d54e:1:745e:3a0:3b5:73ba
00:05:05.996 [I] SrpServer-----: Adding service ‘F0723F28DE470581-1B0D4FCB509FAA07._matter._tcp.default.service.arpa.’
00:05:05.996 [I] SrpServer-----: sub-type: _IF0723F28DE470581
00:05:05.996 [I] SrpAdvProxy—: Adv update for ‘7E471208FAB211A3.default.service.arpa.’
00:05:05.996 [I] SrpAdvProxy—: Registering host ‘7E471208FAB211A3’, id:2
00:05:05.996 [I] SrpAdvProxy—: Registering key for service ‘F0723F28DE470581-1B0D4FCB509FAA07’ ‘_matter._tcp’, id:3
00:05:05.996 [I] SrpAdvProxy—: Registering service ‘F0723F28DE470581-1B0D4FCB509FAA07’ ‘_matter._tcp’ on ‘7E471208FAB211A3’, id:4
00:05:05.996 [I] SrpAdvProxy—: Register callback, id:2, error:OK
00:05:06.149 [D] P-SpinelDrive-: Received spinel frame, flg:0x2, iid:0, tid:0, cmd:PROP_VALUE_IS, key:STREAM_RAW, len:22, rssi:-53 …
00:05:06.149 [D] P-SpinelDrive-: … noise:-128, flags:0x0000, channel:15, lqi:255, timestamp:60175673973, rxerr:0
00:05:06.149 [D] RadioSelector-: RadioSelector: UpdateOnRx 15.4 - neighbor:[7e471208fab211a3 rloc16:0x5801 radio-pref:{15.4:255} state:Valid]

DocMarc73 · April 19, 2026, 11:34am

What exactly happens when you try to add a MOT device? How exactly do you try to achieve this? Are you using a phone (Android/Iphone) when connecting a device or do you use the direct “phoneless” method using a bluetooth dongle connected to HA?

fazkoenig · April 19, 2026, 11:40am

I add it with my android using the companion app.
It starts contacting the Thermostat. The thermostat is added to the thread mesh and start communicating but its not handed over to matter. It is stuck at the "checking thread network “ha-thread-XXXX”.

→ no bluetooth dongle on the NAS where HA runs in the VM available. (Hence direct comissioning with code from the HA server does not work)

DocMarc73 · April 19, 2026, 11:46am

So you made sure the thread credentials were synchronized in the companion app?

fazkoenig · April 19, 2026, 11:51am

yes several times even tho its a nightmare tbh… deleting google data losing all wallet data sucks… what a bad implementation…

reset thread router, get new id/ credentials on the server
make router preferred and set it to use this border router for credentials
delete play service data on android
use troublehsooting setting n android to force it to refresh (twice)
did i miss something? not sure how i can make sure its the right dataset on the phone

if this would not be correct (which it was before) then its not even getting added to thread. but thread seems to work

DocMarc73 · April 19, 2026, 12:01pm

Yeah, i had the same problem !-).
I dont know how to make a hundred percent sure the credentials in the phone are right. But i think you can rely on the message “phone an HA are in the same network” or something similar.
For me the CLI command: ha docker options --enable-ipv6=true did the trick.
I have no knowledge or experience with HA running on a VM, maybe something is blocking the IPv6 forwarding.
Before knowing about the “ipv6 command” i was so desperate that i bought a ASUS BT500 bluetooth dongle and added some devices directly, which is a sort of workaround for the IPv6 problem.
After activating IPv6 manually everthing works fine even with the phone.
Is it the first device that you are trying to commision, or did it work before?

fazkoenig · April 19, 2026, 12:08pm

its the first Thread device. Shelly (matter over wifi) worked easily. what matter over thread device did you use? a thermostat?

DocMarc73 · April 19, 2026, 12:22pm

No, i have 37 MOT devices, mostly Eve Energys, Bosch M+, some Ikea devices like Grillplats, Kajplats and Bilresas.
So a thermostat sounds battery driven, right?
Is it close enough to the Border Routers radio?
Sometimes one or two walls in between can be too much to get a sufficient radio signal to the end device. You also might choose a thread channel that doesn’t interfere with the wifi 2,4 ghz band. If your wifi router uses the US scheme (channels 1, 6, 11) bandwith 20 Mhz, then Thread channel 25 should be safe.
What WiFi Router do you have?

fazkoenig · April 19, 2026, 12:31pm

signal is good. its 2m apart.
Router is a Fritzbox 5690Pro.
I still think its something about that Eve device… not sure

maybe i just give Aqara a shot…

DocMarc73 · April 19, 2026, 12:43pm

I have the same router. Make sure “Wlan Koexistenz” is activated. I must admit that i’m a big fan of the eve devices as they are pretty solid and i made bad experiences with aqara stuff.
Whatever, i think something in your setup VM/NAS HA is not working correctly (IPv6 wise) , so chosing another brand wont help. Do the phone and ha have the same ipv6 prefix apart from fe80:: ?

fazkoenig · April 19, 2026, 1:07pm

yes phone has same (fd79:XXXXXXX) as HA

thread as another ip6 but that seems normal.
Struggle is real

will try some more and then try another matter over thread device (need to buy one…), lets see.

DocMarc73 · April 19, 2026, 1:55pm

Good luck! Would be nice to hear from you once you’ve found a solution!

fazkoenig · April 19, 2026, 2:02pm

thanks for the help so far!!! will do!

mloquai · April 19, 2026, 5:13pm

Did you make any progress with your problem? I’m stuck with the same issue involving two Heiman smoke detectors. I’m also running HA in a VM under Proxmox—otherwise, my setup is the same as yours.

DocMarc73 · April 19, 2026, 5:27pm

I dont have any experiences with proxmox oder VMs but it seems to be a bit tricky to get IPv6 and USB passthrough working to get HA and Thread running.
Maybe this german site could help a bit (seeing your hardware i guess you speak german?):

Otherwise the direct method using a cheap but solid BT-Dongle like the ASUS BT500 (about 7-8€ on Amazon) is worth a try?

mloquai · April 20, 2026, 6:54am

wohoooo. Nice Link. Danke schön. I will check it.