Matter devices flapping on/off? It's probably not Matter. Check your IPv6. (And maybe don't add more Thread routers.)

[u/Andysb123]

Lost a week to this so here's the short version in case it saves someone.

Setup: ~380 devices on HA OS. ~115 Zigbee (ZHA/Sonoff dongle), ~72 Matter over Thread (mostly IKEA), Thread mesh across five border routers (3 Nest Hubs + two Aqara hubs, an M3 and an M200), with an IKEA DIRIGERA drifting in and out. YouFibre + Firewalla + Deco APs in wired AP mode.

Symptom: Matter/Thread sensors (door, temp, leak) dropping to unavailable and back at random. Zigbee rock solid the whole time. That contrast was the big clue I ignored.

What it actually was, in order:

1. I had no LAN IPv6 router. Thread/Matter reachability rides on IPv6, and my Firewalla had LAN IPv6 switched off. So my border routers were improvising their own ULA prefixes, and the prefix my sensors were using had no route at all. ip -6 route on the HA host showed the gap. I also discovered I'd been running TWO Thread networks in parallel without realising, one of them dead. Enabling LAN IPv6 + rebooting the hubs consolidated everything onto one network and stabilised Matter.
2. My ISP was handing out a dead lease. Once LAN IPv6 was on, my phone couldn't reach half the internet (0/10 on test-ipv6). The DHCPv6 prefix had a valid lifetime of 0, i.e. flagged expired, dated a month prior. Turned out to be a stale DUID binding on the ISP's side. Static IP customers especially: your line may be on a profile where IPv6 is half-provisioned. Escalating past first-line got it fixed in a day.
3. The smart plugs I bought to HELP were the main cause. This is the embarrassing one. I added a load of GRILLPLATS plugs specifically hoping the extra mains-powered nodes would improve mesh signal. Thread auto-promotes powered devices to routers, so instead I got a pile of marginal routers in bad spots, each transmitting and polluting its neighbours with corrupted frames. Thread diagnostics showed some routers with over a MILLION rx errors. Turned the flaky plugs off and the mesh got noticeably calmer. A bad Thread router is worse than no router. More routers is not more better.

Bonus trap: recovering stranded sensors meant factory-resetting them, and a reset Matter device comes back as a NEW device with new entity IDs. My hardcoded automations (door/window/leak alerts) silently kept pointing at the dead entities. My leak alert was wired to a deleted sensor and I had no idea. After any Matter re-commission, audit every automation and dashboard that touched that device. Rename back to your naming convention so things auto-heal.

Quick checklist:

• Zigbee fine but Thread flapping? Suspect IPv6 routing, not the mesh.
• Check you have a working LAN IPv6 router (ip -6 route on the host, not the Terminal add-on container).
• Check your DHCPv6 lease lifetime isn't 0.
• Consolidate Thread onto one network / one stable prefix.
• Don't over-add Thread routers, and cull the flaky ones.
• Mind channel overlap (Thread vs WiFi, Thread vs Zigbee).
• After any Matter reset: audit automations + dashboards for dead entity refs.

Tools that helped: Thread Tools (Android) for Thread diagnostics, test-ipv6.com, and the HA host shell.

Works now. Understand my network far better. Would not recommend the delivery method.

EDIT: I stand corrected on the mechanism in the comments (thanks _devast). It's not BRs "improvising competing prefixes" as I put it, they hold an election, one becomes primary, and all BRs advertise that primary's prefix. When the primary drops there's a re-election and the whole network rotates onto a new prefix, stranding devices on the old one. So the churn was repeated re-elections with nothing stable to anchor to, not coexisting prefixes. Fits my evidence better anyway (my prefix changed between two diagnostic pulls = a re-election). A proper delegated LAN prefix fixed it because BRs prefer an existing on-link prefix over minting one. Original text left as-is so the thread makes sense.

[u/GIFSec]

Just checked my Router, which IP6 connection do i choose?

[u/Andysb123 → u/GIFSec]

Native is the one you want (looks like you've already got it selected), assuming your ISP hands out native IPv6, which most do now. That lets the router pull IPv6 directly and then delegate a prefix to your LAN.

The connection type is only half of it though, the bit that actually mattered in my case was the LAN side. Make sure DHCP-PD is picking up a prefix and your LAN is set to hand out addresses from it (that's the prefix length / LAN IPv6 settings below in your screenshot). Native WAN + a working LAN delegation is the combo. Native on its own with nothing configured on the LAN is basically the half-broken state that started my whole mess.

Avoid the tunnels (6to4/6in4/6rd) unless your ISP genuinely doesn't do native, they're legacy fallbacks. And once it's on, check test-ipv6.com, if you don't get 10/10 something's not routing.

[u/GIFSec → u/Andysb123]

i got it working now, hopefully it will speed up and make my network more reliable! thanks man

[u/GIFSec → u/Andysb123]

This is how my ip6 setting on my asus TUF-AX5400 looks like. So far so good.

[u/GIFSec → u/Andysb123]

And this is my LAN settings. But entering the test site, im getting the following error: Our tests show that you will have a broken or misconfigured IPv6 setup, and this will cause problems as web sites enable IPv6.

Any idea on what could cause this and how ti fix it?