Why is thread/matter an absolute dumpster fire

Configuration Matter/Thread
1

I've been sat here for 2 days trying to pair/commission a Ikea Kajplats bulb to my home assistant.
I have an IOT vlan with Home Assistant, OTBR, Matter sever docker containers with a SLZB-MR3.

I had to remove my google home devices from my google account as the NEST-PAN one was not working, now I've managed to connect a Bilresa and it works but for the life of me i cannot pair the bulb.

Between Claude code telling me to get a USB Bluetooth Dongle for pairing, setting "local" ipv6 addresses and clearing my Google Play Services App storage (logging me out of my google account)

I've tried again on iOS and that gives little feed back so back to android that now connects to the device, generates the credentials and ends with the pairing process checking connectivity to the thread network and erroring with "Can't reach device"

Anyone got any suggestions before I bin off this "Amazing new smart home standard" in favor of the battle tested zigbee?

2

You can force the Kajplat bulb to use Zigbee by power-cycling it 11 times. I wrote a script that does just that with a smart plug.I recently bought a single Kajplat bulb to try this out and it worked.

Having said that I would not give up on Matter /Thread just yet. It’s easy to get tunnel vision with thread. For commissioning, Matter devices need both Bluetooth and IPV6. I think the recommended approach is the Home Assistant companion app.

1 Like
3

Two days on this is brutal, but your error ("credentials generate, then the Thread connectivity check fails with can't reach device") is almost always IPv6 routing between the commissioner and the Thread network, not Matter being broken. Two things about your setup make that the prime suspect.

1. Docker IPv6 (most likely here). You're running HA + OTBR + Matter server as docker containers, and Docker disables IPv6 by default. Thread is IPv6-only, so the device gets provisioned over BLE fine, then the commissioner can't reach it over Thread to finish, exactly your error. Enable IPv6 in the Docker daemon (daemon.json with "ipv6": true plus an IPv6 subnet), make sure the Matter-server and OTBR containers have it, and restart. This is the single most common fix for "stuck at checking Thread connectivity" on a container setup.

2. The IOT VLAN. The phone you commission with must be on the same VLAN/subnet as HA/OTBR and reach it over IPv6. Thread leans on link-local IPv6 and multicast, which generally don't cross VLANs even with mDNS reflection. Easiest test: put your phone on the IOT VLAN temporarily and commission there. Once paired the device works fine; commissioning is the fussy part.

3. Re-sync Thread credentials (Android). Removing the Nest border router scrambles Android's stored Thread creds, so the phone may be handing the bulb an empty/wrong network. HA Android app → Settings → Companion app → Troubleshooting → Sync Thread credentials, keep the Google Home app installed, and commission through the HA companion app (not Google Home) so it uses your OTBR.

4. Factory-reset the KAJPLATS between attempts. Two days of half-finished commissioning can leave the bulb stuck. Do IKEA's power-cycle reset before each fresh try.

5. Undo the "local IPv6" change. If Claude Code had you force link-local/ULA addresses, revert it. OTBR needs proper routable IPv6 (it advertises an off-mesh-routable prefix); forcing local addresses breaks reachability.

The encouraging bit: you already got the BILRESA onto Thread, so the stack fundamentally works. That points squarely at per-attempt IPv6 reachability (Docker IPv6 + the VLAN), not Matter being hopeless. Fix those two and the bulb should go through. For a VLAN'd, container-based setup, commissioning is the painful part, once devices are on, they're stable.

Refs:

btw; Docker disables IPv6 by default, plus Thread's link-local IPv6 doesn't like crossing VLANs...

3 Likes
4

Oh that's smart, I didn't realise the Kajplats could fall back to Zigbee with the 11 power-cycles.

And you're spot on about the tunnel vision. The Bluetooth + IPv6 point is exactly where I think the issue lies

5

Thanks guys,

Docker IPv6

I wasnt aware of this, this will be my first call

IOT VLAN

Yeah that caught my out a few times haha, my phone switching back to the main SSID not my hidden IOT one

Re-sync Thread credentials

This takes some doing, thats why i had to remove both of my Nest Displays and factory reset them

Factory-reset

These poor bulbs have been reset that much i'd be supprised if they even know they are a bulb still :wink:

"local IPv6"

Oh god, that took forever to do and after the Ikea remote was working I was scared to make those changes in case it disconnected its self, i had to half pair it with the HA app and then finish off by entering the code in to the Matter Options page

I'll update this after i've checked docker and again if i dare touch the link-local/ULA addresses

6

Matter is a dumpster fire if you run VLAns or have broken ipv6...
I stick with Zigbee, WIFI, and ZWave, thank-you.

Matter & Thread Deep Dive

On the right path with the bin idea, IMHO.

Don't forget that the manufacturer can pull the credentials on your device if they go out of business, or decide your device is dangerous, or whatever if they decide to do so. The often debated 'kill switch'.
Of course they will never do that. But if that's true, do you actually own the thing or have you signed up for a long term lease?

I just stay away. Just got a couple of Gen4 Shelly's. One is WIFI and the other is now zigbee. First thing I did was push the button 5 times and get the heck out of that matter mode.

5 Likes
7

I never managed to commission any node through my phone myself.

I'm using the "bluetooth" way, i.e. having bluetooth enabled on the HA matter service host, and commission directly from the matter addon/container, and it works pretty smoothly.

Actually I've put in place a system to commission nodes through bluetooth on a RPI which is not the HA matter server, but that's really too convoluted to share :smiley:

8

Would be ideal if i could use an ESP32 for the commission haha

9

This is pretty much BS and a sign of complete misunderstanding of the way how Matter over Thread works. The Thread credentials of your local Thread Mesh are primarly stored in HA/ Open Thread Border Router App (TLV string). No manufacturer can pull it from there and "killswitch" your Mesh.
You only have to send and store these credentials to your phone for the initial pairing process of new devices. It is indeed true that these credentials are stored in the Google Cloud on Android phones (dont know about IPhones).
Technically Google could delete that data in the cloud and maybe even your phone.
But that doesn't mean your Thread Mesh will crash, because the already added devices will keep on running absolutly locally in your network.

Second: you don't even need any phone to add new Thread devices! The pairing process works even more reliable without a phone:

What you need indeed for onboarding is a Bluetooth device, that sends the TLV-String (Thread credentials) to the new device, so that it get's paired with YOUR OWN LOCAL Thread Mesh.

For this purpose you might want to get yourself a cheap BT-Dongle and connect it to HA.
From then on HA can send the credentials directly to the new MoT Device, without needing to use a phones BT.
After the onboarding is done, Bluetooth is no longer needed.
Here's a good guide to do so:

Even though there are some obstacles in Home Assistant in regards to adding new Matter-over-Thread devices (e.g. IPv6 forwarding, mDNS, Thread credentials and phones) at first glance, i do believe it's superior to Zigbee.
It has so many advantages in different aspects and is quickly evolving.
The Border-Router App and the Matter Server App are getting constantly updated and become better and better with every update, eliminating comissioning problems and possible instabilities more and more.

Once you got into it, you won't want to return to ZiggysackBee ...

:wink:

10

Wellll... let me just say firstly that was adventure, but i think I’ve managed to get pairing wokring after

  1. Setting up IPv6 Vlan wide via HE Tunnel Broker
  2. Adding a static IPv6 route for the fc00::/7 range to point at both of my border routers
  3. Resetting my google play services app data (so i could sync my HA matter/thread creds)
  4. Making sure my phone was on the IOT vlan/ssid when pairing

I only have 1 Ikea bulb and the Ikea Bilresa scroll wheel. Feels like a lot of work troubleshooting and tinkering when i could have just stuck with zigbee, i do like the remote and the bulbs seem to fix the annoying issue where if it was switched off at 100% white and you want to turn it back on to say 5% it had to start at 100% and work down

As i said previously it would be nice to skip the phone pairing if i could have used an ESP32 as my HA server is a Proxmox VM in my garage so no chance of a USB dongle working

11

I'm happy for you. I truly am.

For me, I am glad that bluetooth is never needed.

You have heard the woes of the first gen Tesla powerwall users that woke up one day with their batteries disabled because they were deemed dangerous.
I just don't want anything like that and Matter strongly smells like it's similar.

The entry level users, as you can search here, are having a wonderful time with:

12

This is true but for the wrong reason. The Matter data is stored in something called the “DLC” or Distributed Compliance Ledger (DCL). This is a blockchain-based database run by the Connectivity Standards Alliance (CSA). Google is only a member of CSA; there are dozens of other members.

If Google kept the data on a normal cloud server, then yes, Google could shut down the server, and you would not be able to recommission a device after a factory reset. Or more importantly, you could not sell a used device on eBay.

The data there can never be retroactively changed by anyone, and even if one company drops out or goes bankrupt, the DCL is a distributed database with Apple, Google, Samsung, and over a dozen more jointly running this.

The purpose of DCL is only one thing: It is used to verify that your device is real. How else would you know that the IKEA light bulb you ordered was not secretly swapped by the FedEx delivery man for an evil spy device that only looks like a light bulb?

IKEA, when it makes the lightbulb, writes a certificate to the ledger; later, you read the certificate and compute if it is a match to the physical device you hold in your hand. This only needs to be done once. Certainly not every time you turn on the lightbulb.

Because the blockchain is immutable, we know that no evil hacker, even if they work at Google, can change the ledger. It is actually impossible to change, well, only until we have really big quantum computers. But fusion energy and flying cars will come before that.

1 Like
13

Blockchain, you say? Well, I'll be hornswoggled! DCL is built using the Cosmos SDK. It's looking like Cosmos ATOM will be my next crypto investment, lol. Thanks for the knowledge!

14

I guess we are talking about different things here. What i meant, was not the devices certificates like Device Attestation Certificate (DAC) from CSA and so on , (which also get checked during the pairing process), but the Thread Network Credentials, which are generated locally by HA/OTBR when you first setup your Thread Network and which need to be sent over BT to the device you want to add.
If you are using a phone, these credentials need to be sent from the companion app to your phone (Companion App/Troubleshooting/synchronize Thread credentials) and, in case of an Android phone, are stored in Google Play Services Data (wallet) and in the Google Cloud as well (if you don't untick that option in your phone).
If you dont want Google or Apple to store or even know about these Thread Credentials, you could exclude them by using a BT-Dongle connected to your HA-Server, so that the "onboarding" to your Thread Mesh happens locally without a phone.

And i still don't understand how a manufacturer should be able to "killswitch" your Thread Network or particular devices, that are already within that Mesh?

P.S.: i'm using a Zigbee Network as well with roughly 20+ devices which are connected directly to my Fritzbox (WiFi Router with built-in Zigbee Chip and upcoming Matter Bridge funtion), but i found my HA/OTBR/ZBT-2 Thread Mesh gave me more options and control over my Matter devices.

15

These devices can be connected to matter and wifi. Case in point, a zwave device was recently killed by the manufacturer that had the same ability. The user unknowingly left wifi enabled, an auto firmware update occurred and removed the zwave functionality, killing it in the mesh network. In matter devices, typically you cannot turn off wifi. So this is a real problem with matter devices that support both wifi/thread. You can block them from your firewall as well, but does that affect other features like recommissioning? (rhetorical question)

Anyways, the point @Sir_Goodenough is making is a very valid point. Matter was made by companies that have showed time and time again that they cannot be trusted. Everyone should keep their guard up when using their devices.

3 Likes
16

And that cannot happen to Zigbee devices as well? - real question -

Edit: now that i wrote that, i found an example in my own home:
i remember that lately i had a Zigbee/Bluetooth Ceiling Lamp that got its Zigbee functionality removed by an uncautios update that i made.

17

It can happen to any that have wifi + another protocol. The thing about zwave and zigbee is, you don't need wifi to commission the device so you can completely block it. That's not the case for matter, you need bluetooth and/or wifi.

TLDR: It's much more likely to happen with a matter device than it is with zigbee or zwave.

19

Right, but you're missing the point. It's much more likely to happen with something that requires a connection to your wifi network. That's why I did not mention bluetooth. I understand you're a matter fanboy, but this is a real problem and these big box companies will do things like this. It's a real issue and it should not be swept under the rug. Most matter devices are wifi or wifi+thread, not bluetooth+thread.

1 Like
20

Not really a thing…

1 Like