Matter over thread stablebility and experiences

Configuration Matter/Thread
1

Hi everyone,

I’m a developer from Shenzhen Heiman. I’ve been developing Matter since 2022, at that time, The Alliance was conducting test events, The Alliance conducted nine test events and two final Specification Validation Event (SVE) prior to the launch of Matter. and two final Specification Validation Event (SVE) prior to the launch of Matter.

I am wondering how you have been feeling about the stability and overall experience of Matter over Thread. I’ve received feedback regarding several different issues; the major one being that users are often unable to commission, pair, or onboard their devices. Others are encountering “unresponsive” or “unavailable” status errors.

I’m not sure if most of you are facing these same hurdles. Have you run into any issues with Matter over Thread devices lately—for example, with the recent IKEA Matter series? How has your experience been with these brands? Let’s discuss it here."

I’ve been testing Matter over Thread devices for years, including our own Heiman Matter products. To start this topic, I’d like to share some of my experiences and test results below, I am also very curious to hear: what do your Matter setups look like?"

Test Setup 1: Apple Home Only.

  • Matter Hubs: Apple HomePod Mini, HomePod (2nd Gen), Apple TV 4K.
  • Matter Devices: Heiman Motion sensor(M1-M), Heiman Smoke Sensor(S1-M, HS1SA-M, S1-TM), Heiman Co Sensor(C1-M, HS720ES-M, HS725ES-M), Heiman temperature & humidity sensor(H1-M), Heiman Door Sensor(D1-M) and Heiman Water Leakage Sensor(L1-M).
  • Version: Hubs are running HomePod Software 26; iPhone 15 Pro Max is on iOS 18.5.
  • Result: We commissioned 25 battery-powered devices with no issues. However, when we increased the count to 50, devices began going offline due to high network traffic (congestion), especially during active commissioning.
  • Recommendation: For larger setups, adding Full Thread Device (FTD) routers (mains-powered Matter devices) is highly recommended to improve system robustness.
  • Known Issue: Apple Home currently does not support the Self-Test feature for Smoke and CO alarms.

Test Setup 2: Google Home Only.

  • Matter Hubs: Google Nest Hub (Gen 2), Google TV Streamer 4K.
  • Matter Devices: Heiman Motion sensor(M1-M), Heiman Smoke Sensor(S1-M, HS1SA-M, S1-TM), Heiman Co Sensor(C1-M, HS720ES-M, HS725ES-M), Heiman temperature & humidity sensor(H1-M), Heiman Door Sensor(D1-M) and Heiman Water Leakage Sensor(L1-M).
  • Result: 25 devices commissioned successfully with no issues. We did not add more “Sleepy End Devices” (SEDs) here, as we recommend adding FTD routers to the mesh first to ensure stability.
  • Known Issues (Pending Google Fix): 1. Battery status always shows as “Unavailable” for Smoke and CO alarms. 2. Hardware status always shows as “Unavailable” for Smoke and CO alarms.

Test Setups 3 & 4: SmartThings / Homey Pro Only.

  • Matter Hubs: SmartThings Hub v3 / Homey Pro.
  • Matter Devices: Full range including M1-M, S1-M, S1-TM, C1-M, HS1SA-M, HS720ES-M, HS725ES-M, H1-M, L1-M and D1-M.
  • Result: 25 devices commissioned with no issues. As with other platforms, we recommend adding FTD routers if you plan to expand the number of battery-powered sensors.

Test Setup 5: Home Assistant (HAOS) Only

  • Matter Hub: Home Assistant Green/ Heiman thread dongle.
  • Matter Devices: Full range including M1-M, S1-M, S1-TM, C1-M, HS1SA-M, HS720ES-M, HS725ES-M, H1-M, L1-M and D1-M.
  • Result: 48 devices commissioned (mixture of battery and AC-powered). We use this daily for automations with great success.
  • Observation: Without an FTD router in the system, we noticed very brief “drop-offs” or latency. Adding a Matter-compatible Thread router is highly recommended.

Test Setups 6–9: Multi-Admin (Mixed Ecosystems)

  • Setups: Apple + HA, Google + HA, Homey + HA, SmartThings + HA.
  • Matter Devices: Full range including M1-M, S1-M, S1-TM, C1-M, HS1SA-M, HS720ES-M, HS725ES-M, H1-M, L1-M and D1-M.
  • Result: We tested 15 to 20 devices in these multi-admin configurations. All worked without issue. We still suggest FTD routers for any network with many sleepy devices.

Developer Tips for Matter over Thread:

  1. OTA Updates: We found that SmartThings, Google Home, and Home Assistant currently handle OTA (Over-the-Air) firmware updates most easily.
  2. Firmware Version: For Heiman Matter devices, we highly recommend using Version 1.5.
  3. Mesh Robustness: Always include at least one or two Full Thread Devices (FTDs)—like a smart plug or light switch—to act as routers for your battery-powered sensors.
  4. Wireless Interference: Check your Wi-Fi channel against your Thread (802.15.4) channel. Ensure they do not overlap to prevent signal interference, Thread and Wi-Fi both use the 2.4 GHz frequency. For the most stable connection, manually set your Wi-Fi to Channel 1. This stays far away from Thread Channel 25, which many Matter hubs (like Apple’s) use by default and cannot change.
  5. Network Unity: When using multiple hubs, ensure they are all on the same Local Area Network (LAN).
  6. Border Router Support: Ensure your chosen hub officially supports OTBR (OpenThread Border Router) functionality.
  7. Troubleshooting Unavailable: If a device drops off, try moving it closer to the hub or a router to check for range issues.
  8. IPv6 Configuration: Double-check your router’s IPv6 configuration, as it is critical for Matter over Thread stability, Ensure your Wi-Fi router has mDNS or Multicast enabled. Matter uses these to “find” devices on your network. If your router blocks multicast, your devices will show as “Unavailable” even if the Thread signal is strong.

what do your Matter setups look like? please leave comments below.

2

First of all, I can’t say enough good stuff about Home Assistant and the developers and community that make it work.

And I appreciate your work on Matter - I like the idea of mesh networking and not needing a proprietary hub - but it’s been a terrible experience for me, and my light bulbs still aren’t set up. I learned a lot about IPv6 and mDNS to try to debug this, and it will help me share some extra info, but I don’t think most users will be willing to spend days writing scripts and debugging their Matter setup.

I use Home Assistant, the HA matter.js server app for a controller, and the OTBR app, connected to a SLZB-06 radio, which works well. dns-sd shows me what thread border router is available, what matter devices are available, and I can ping6 their IPv6 addresses.

I have an iPhone 16, which has the Apple Home app, but no Apple Home Hub.

I have a bunch of Matter over Thread devices, including a the new Ikea ones (bulbs, switches, and thermometers) and an Eve switch.

To start, I plug a Matter over Thread device in. It appears that the HA Companion app and the Apple Home app both use the Apple Matter SDK. It tells me to hold my phone near the device, which has never worked. The QR code that I need to scan is usually inaccessible when the device (e.g., a bulb) is plugged / screwed in to power.

Although they both seem to use the same SDK, I have never been able to commission any device when I initiated the process through the Home Assistant Companion App, no matter whether or not I sync the credentials before or after trying.

I am sometimes able to commission a device using the Apple Home app. When it fails, it fails at different stages (sometimes connecting, sometimes adding), and the error it gives usually gives no useful information. Pretty much just “error adding” or something.

When I can add a device like a light bulb, most often, that was a one time thing. Most often, I won’t be able to add a second light bulb today. Maybe the whole stack needs a reboot between each light bulb :man_shrugging:

Once the device is added, I can get a pairing code in Apple Home and provide it to Home Assistant. Sometimes it successfully adds to HA, sometimes it fails with no useful error message. If it is added to HA, it works well from HA.

Meanwhile, in Apple Home, the connection is utterly inconsistent and laggy. It’s pretty funny to toggle the lights in a chandelier, and have different ones turn on and off each time with up to several minutes of lag. But I think I’ve mostly been able to figure out why.

The Apple Home app can only connect to the devices via bluetooth. If bluetooth is off, then my phone could never connect to the Matter devices, even though I have a working HA “hub” - a matter.js server and OTBR, both advertising their services via mDNS and accessible via IPv6. (Take care when diagnosing: if you disable bluetooth via the iOS control panel, it actually remains on for using Matter devices. Also, Eve’s diagnostic app sometimes shows connected via Thread even when it’s connected via bluetooth.) The Apple & Matter marketing material say that you don’t need a proprietary hub, but this doesn’t appear to be the case. Sometimes, Apple Home would have a message saying that I need a border router. Maybe it’s the version of the matter server app or the OTBR app, but it’s pretty hard to determine why Apple devices don’t want to cooperate.

It appears Apple Home does work with third-party Matter over Thread services to some degree. With bluetooth off, and being unable to control the lights via Apple Home, I deleted the devices from Apple Home, so it would never try to connect to them again by bluetooth. In this case, Apple Home collaborated with my HA to nuke the whole setup, and now I can’t control my lights with HA either.

At one point I tried to use Thread’s tool called chip-tool for issuing a command to the devices. It isn’t available as a binary for Mac, it requires installation of a custom device profile, and requires 30 GB of repos to build - which seems like a lot of GB for a light protocol that controls light bulbs. The tool errored out.

Frankly, most of the Matter over Thread marketing isn’t making sense to me any more. It appears proprietary hubs are required, at least if you plan to use your phone. It doesn’t make much sense that it would scale better than wifi: (1) everything still goes through the Matter controller, even if you can ping the devices directly, and (2) mesh networking is cool, but having 4 Thread bulbs in my chandelier doesn’t increase the range and creates excessive mDNS traffic that battery powered switches and thermometers can’t handle. With Wifi bulbs, I could simply issue an on/off command directly from client to bulb.

So, this has been a frustrating experience for me! I’m not a Matter dev, so I’d be happy if you corrected any misconceptions I have or give any other suggestions.

Thanks!

3

I commissioned a bunch of Ikea products, via the HA companion app on iPhone and matter.js server.

I noticed that I had to cut the power to most of the mains-powered MoT devices to commission more MoT devices.

I cannot share the devices with Apple Home. IIRC, Apple Home would tell me to enable bluetooth when the pairing code was scanned. I confirmed that the pairing code indicated the device was already commissioned over wifi.

When I tried commissioning via Apple Home (since the python matter server was not working), I found that it generally could not share with HA, and it could never communicate with the devices with bluetooth disabled.

4

Great post — really appreciate the detailed test results. I’m running one of the larger Matter over Thread deployments on Home Assistant I’ve seen discussed publicly, so hopefully this adds useful data.

My setup:

  • HA Yellow (primary) + 2× HA Green, all running OTBR add-on v2.16.5 on ZBT-2 radios, HAOS 17.1
  • ~184 Matter over Thread devices — primarily Inovelli White Series 2-in-1 switches (mains-powered, acting as Thread routers), plus Eve door/window sensors, Eve outlets and MotionBlinds.
  • Parallel Zigbee and Z-Wave running alongside with few issues

What’s working well: Your point about Full Thread Devices is spot on - my Inovelli switches are mains-powered and form the mesh backbone. With ~32 Thread routers in the mesh it’s genuinely resilient and reforms quickly after disruptions as long as I am running multiple border router radios.

Challenges at scale:

The biggest issue I’m actively debugging is (I think) a file descriptor leak in the OTBR add-on (otbr-agent and mdnsd both affected) that causes frequent mesh crashes when either process hits the 1024 FD soft limit introduced in HAOS 16. This is a Home Assistant add-on bug, not an OpenThread or Matter protocol issue, but at 184 devices the impact is significant. I’ve filed it at home-assistant/addons and I believe the fix is a one-line ulimit change that other affected add-ons have already shipped.

Commissioning is unreliable when the mesh is unstable - nothing new will connect cleanly until the network settles first. Devices that drop offline for extended periods can get stuck and need physical interaction to rejoin. That’s annoying and hard to predict. There has to be a better way to reconnect a device that’s dropped offline without having to physically interact with it.

If I had to do it over again, I’d probably split my devices more evenly between Zigbee / Zwave / Thread, but I’m cautiously optimistic this is just growing pains. Assuming these nagging issues get resolved, I think Matter/Thread will be hard to beat.

1 Like