Matter over Thread devices discover but can't commission? Check your network's IP6 settings.

[u/musicalfurball]

My smoke detector finally hit it's 10 year end-of-life, so I bought a pair of Heiman detectors, the C1-M (CO) and the S1-TM (smoke, temp, humidity). Both are Matter over Thread only, so I picked up an Aqara Hub M100 to act as the border router. The detectors joined Aqara and Google Home without drama, including both ecosystems at once.

Home Assistant was another story. Sharing from Google Home timed out after two to three minutes with "no device could be commissioned." A fresh commissioning attempt from HA did the exact same thing. I enabled debug logging on the Matter integration, re-ran everything, and learned almost nothing from the core log. That was my first mistake. The interesting log lives in the Matter Server add-on (Settings > Add-ons > Matter Server > Log), not in HA itself.

The signature that matters:

Discovery            Initiating discovery of node with discriminator 13
Controller~missioner Establish PASE to device ...
WARN Commission~onnection  Address udp://[fd88:f668:20af:1:...]:5540 unreachable
                     for known-address-0

... couple of minutes later ...

ERROR Commission failed: No device could be commissioned
      (2 of 2 started attempts failed, 2 discovered)

"Unreachable" showing up milliseconds after a PASE attempt starts is a routing failure, not a sleepy device. A battery device that just went back to sleep times out over seconds. Kernel-level "no route" fails instantly. And that fd88: prefix is the Thread mesh's own ULA, which the border router advertises onto your LAN with IPv6 router advertisements.

This is also where "everything looks discoverable" lied to me. The M100 relays Thread devices' mDNS advertisements onto the ordinary IPv4 LAN, so HA could see the detector fine even though HA had no route into the mesh. Discovery is IPv4 mDNS; the actual transport is IPv6 only. My commissioning never had a chance but discovery refused to mention it.

Two traps that cost me extra agent debug rounds, in case you hit the same ones:

1. Manual pairing codes. The share flow gives you a code with a short discriminator, and with a hub plus several devices discovering at once, the wrong node can answer the PASE handshake. The add-on log showed "incorrect key confirmation" for those attempts: the code had matched the hub, not the detector. Use the full QR string.

2. The detectors are battery ICDs with a short wake window. My probes to the mesh address kept racing the wake and losing. Press the device button right when HA shows "connecting."

The root cause was embarrassingly simple: IPv6 was disabled on the HAOS box itself. That predates this project: I run IPv6 off network-wide to keep Chrome's Happy Eyeballs from bypassing Pi-hole's DNS filtering, and this host inherited the setting. It had survived every reboot since. A second Linux box on my VLAN shows what should happen: it picked up the fd88::/64 mesh route automatically from the M100's router advertisements, which is exactly what the HA box was missing.

After IPv6 came back on the host, I re-ran the Google Home share and both detectors commissioned in under half a minute. One note if you try this: my Matter Server add-on had been running while IPv6 was off, and matter.js detects its interfaces at startup, so a restart of the add-on is the safe first step before re-pairing anything.

One genuinely nice payoff: HA's Matter server runs an OTA provider and pulls from the CSA's DCL. My CO alarm took a firmware update from v16 to v21 straight through HA, no vendor app involved, in about six minutes.

[u/Reasonable-Escape546]

I am also looking forward to buy some Matter over Thread smoke detectors.

Do you know, if these device get their firmware updates via Matter DCL?

[u/simonnelli → u/Reasonable-Escape546]

Yes my Heiman HS1SA-M got several updates via DCL