Understanding Thread and Matter (from a power user’s perspective)

Questions & Help
1

Thread and Matter are often difficult to understand. I’ve personally run into problems due to misunderstandings and learned a lot through research and trial-and-error. This is not a post from a standards expert, and some wording may be imperfect. I’m simply sharing my current understanding in the hope that it helps others.

1. Zigbee / Z-Wave vs. Thread / Matter

Zigbee and Z-Wave are integrated standards: they define both

  • the radio/mesh layer and

  • the device model and capabilities.

With Thread and Matter, these responsibilities are split:

  • Thread defines the low-power IP mesh network

  • Matter defines the device and application layer

This separation is powerful, but it also makes the system harder to reason about.

2. What Thread actually is

Thread is a lightweight, low-power IPv6-based mesh network, specifically designed for IoT devices. It is optimized for:

  • short messages

  • low latency

  • resilience and self-healing

Thread operates in the 2.4 GHz band, but unlike Wi-Fi, it is designed for dense meshes and unattended operation. Devices can automatically reroute traffic and recover from node failures without user interaction.

A Thread network is the mesh itself.
A Thread Border Router connects this mesh to the regular IP network (Ethernet/Wi-Fi).

3. What Matter is (and what it is not)

Matter is not a radio protocol.
It is a strictly defined device and application standard that runs on top of IP transports such as:

  • Thread

  • Wi-Fi

  • (Bluetooth LE is typically used for commissioning)

Matter leaves very little room for interpretation. Certified devices expose exactly the data and commands defined by the specification, in the locations defined by the standard.

This strictness enables interoperability, but it also means that some device types expose only their core features.

Example:
For thermostats / TRVs, Matter typically exposes:

  • current temperature

  • target setpoint

  • heating/off modes

Additional features (offsets, boost modes, advanced scheduling) are often implemented by manufacturers via apps or device UIs, or recreated via automations.

4. Matter Bridges

A Matter controller can optionally act as a Matter bridge.
A bridge exposes non-Matter devices (for example Zigbee devices) as virtual Matter devices to a Matter ecosystem.

Bridges exist mainly to:

  • allow gradual migration to Matter

  • avoid forcing users to replace large existing Zigbee/Z-Wave installations all at once

5. Matter Multi-Admin (correct mental model)

Matter supports Multi-Admin, meaning a single device can belong to multiple Matter fabrics at the same time.

Important clarification:

  • A Matter fabric is a security and administration domain (keys, permissions)

  • It is not a network

With Multi-Admin:

  • a device stores multiple fabric credentials

  • each controller has full, native access to the device

  • the device is not “owned” by one controller and remotely controlled by others

This is the intended Matter model, even if some user interfaces make it look like “sharing” or “granting access”.

6. Thread networks vs. Matter fabrics (the crucial distinction)

This is where most confusion comes from.

  • Thread network
    → the physical mesh (routers, repeaters, border routers)

  • Matter fabric
    → a logical security domain on top of IP

Multiple Matter fabrics can coexist on a single Thread network without weakening it.

7. Where theory and practice diverge

In theory, this means:

  • one Thread network

  • multiple Matter fabrics

  • no fragmentation

  • maximum mesh strength

In practice, however:

  • many ecosystems are capable of creating their own Thread network

  • not all controllers reliably join an existing Thread network

  • some controllers always initialize their own Thread network when commissioning devices

As a result, multiple Thread networks often exist in parallel, leading to:

  • fragmented meshes

  • fewer routers per network

  • reduced resilience

This fragmentation is not caused by Matter Multi-Admin itself, but by how controllers handle Thread network creation and joining.

8. Why commissioning order matters

The first controller that commissions a device determines:

  • which Thread network the device joins

Multi-Admin:

  • adds additional Matter fabrics

  • does not change the Thread network

Therefore, pairing devices consistently to a single primary ecosystem and only then adding additional controllers via Multi-Admin can help avoid fragmentation.

9. Apple Home as an example of a resilient Thread foundation

One ecosystem that handles this particularly well (in my experience) is Apple Home:

  • multiple Apple TVs and HomePods act as Thread Border Routers

  • all devices under the same Apple ID form one coordinated Thread network

  • controller failover happens automatically without user interaction

This makes it a strong candidate for acting as the primary Thread network, while other controllers can be layered on top via Matter Multi-Admin for advanced automation features.

10. Final thoughts

  • Thread provides a robust, low-power IP mesh

  • Matter standardizes device behavior across ecosystems

  • Multi-Admin allows multiple controllers without duplicating networks

  • Fragmentation happens when multiple Thread networks are created

  • Avoiding fragmentation is largely about commissioning strategy and controller behavior

If you spot inaccuracies or have additional insights, I’m very happy to learn and refine this understanding further.

Edit - TREL:
One thing I learned today and is missing in my post is TREL (Thread Radio Encapsulation Link).

While we often discuss Thread as a mesh, TREL is the standard that turns our Wi-Fi and Ethernet into a “backbone” for that mesh. It is specifically what makes Multi-Admin setups across different controllers reliable.

How it works (The “Tunneling” Principle): TREL allows a Thread Border Router to take a Thread packet and encapsulate it within a standard IP packet to send it over the LAN. Crucially, the Border Router does not need to decrypt the packet. It simply “passes through” the encrypted payload, including the security keys (CASE/PASE), directly between the Matter Controller and the end device.

Key benefits for the infrastructure:

  • Virtual Proximity: A controller on the LAN (like Homey Pro) can reach a Thread device even if it’s out of radio range, as long as there is a Border Router (like an Apple TV) reachable via IP to act as the “entry point.”

  • Unified Backbone: TREL syncs different Thread partitions. It prevents “Thread Islands” by using the home’s high-speed network to bridge separate radio areas.

  • End-to-End Security: Since TREL only encapsulates the data, the secure session remains strictly between the controller and the device, maintaining the integrity of the Matter fabric.

Understanding TREL is essential for anyone building a multi-vendor Matter network, as it explains how devices can remain reachable across different physical locations and network segments.

4 Likes
Zwave vs. Matter/Thread
2

Bit of a bad example, because all of those features are specified by Matter (offset and weekly schedules since 1.0, boost (“emergency heat”) since at least 1.2).

But you’ll find that quite often, many such features just aren’t implemented in the Matter controller. So if Athom states that Homey supports “Matter thermostats”, it does so only partially. At least with Zigbee, apps are able to add support for such features, but not with Matter.

3

You’re right — those features are defined in the Matter specification.
What I was trying to express is something slightly different and probably didn’t phrase clearly enough.

In practice, many Matter devices end up exposing only the core functionality that is required to make the device usable across ecosystems. This can happen for two reasons:

  • either the device itself only exposes a subset of the standardized features, or

  • the controller only implements and surfaces a subset of what the device actually supports.

The Matter standard defines what is possible and how it must be exposed if implemented, but it doesn’t force devices or controllers to expose or make use of every optional feature. As a result, users often interact only with the core feature set, even though additional standardized capabilities may exist in the device.

So the limitation is usually not the Matter specification itself, but where — and by whom — functionality is actually exposed and made usable in practice.

2 Likes
4

Do you write all your responses with AI?

2 Likes
5

No and yes. My english is not really good (this is not handled by AI) I have a good understanding but a bad writing. So all the content is my own content that I write generally in German or French. I use AI to transform it in correct and fluent Englisch and to bring it in form (often complicated with * and so on). But AI is not allowed to change my content. One exception, it can tell my if I’m wrong, but that generally works not very well. AI is overestimated, we use Language Models, that arent really intelligent, nor do they have knowledge. They simply predict what most people would say and that leads to many many errors. I tried AI to write programs in python. It ended up with loops of errors and giving finally up.

1 Like
6

it can tell me😁

7

That happens without AI :grinning_face:

2 Likes
8

Edited my post (top post) to add TREL explication at the end. That makes Thread so strong compared to Zigbee and Z-Wave.

9

I don’t think using AI makes your text easier to understand. It just looks more to a political correct statement. To formulate your text more simple, I would say “you can have a multicolor bulb, but whith an on/off remote control you get only white light”. Or “the chain is as strong as the weakest link”.

I prefer clear text :grin:

10

That saying is largely true for Zigbee, but it doesn’t really apply to Thread in the same way. Thread doesn’t rely on fixed routing tables. Routing decisions are made hop by hop, so the network can automatically go around weak or unstable nodes instead of being limited by them. That’s one of the core strengths of Thread radios.

To make Thread and Matter easier to visualize (simplified and not technically exact): imagine two Zigbee networks where some devices belong to both networks, and traffic for one network can transparently pass through the other network for shared or not shared devices. In real terms, that’s ONE Thread network with multiple fabrics (even overlapping fabrics - shared devices) on top of it.

Combined with dynamic path selection, automatic avoidance of weak routers, and the ability to change channels when interference is detected — without losing devices because the fabric layer is independent — this is what makes Thread much more resilient than traditional mesh systems.

That’s the short version, focusing on the core concepts and leaving the deeper details aside.

11

I just think we are not discussing the same topic. But that is ok.

12

Matter and Thread – a common pitfall

I often see people blaming Matter when devices become unavailable because of “unstable radio”. Technically speaking, that’s not correct — although it’s a very natural assumption for users coming from Zigbee or Z-Wave.

With Zigbee and Z-Wave, the device model and the radio transport are bundled into one single standard. Matter is different: it is a very strict device and interoperability standard only. The actual transport is handled by Thread or Wi-Fi.

Matter devices can of course become unavailable for reasons like poor hardware design, bad Matter implementations, or a corrupted Matter fabric (as I described in earlier posts). But today this is relatively rare, aside from a few known exceptions.

In most real-world cases, the problem is the transport layer.

Wi-Fi is well known to be sensitive to interference and congestion. Without good access point coverage, reliability will always be limited.

Thread, on the other hand, is a very robust radio protocol when networks are designed properly. Most issues I see with Thread are not caused by the technology itself, but by incorrect network assumptions — especially from people coming from Zigbee.

One common misunderstanding:
A wired Matter device using Wi-Fi is still a Matter device, but it does not act as a Thread router or repeater. Mixing Matter over Thread and Matter over Wi-Fi does not strengthen your Thread network. Only Thread devices that support routing do that. Wi-Fi devices never repeat Thread, and they don’t even repeat Wi-Fi unless they are access points.

Another important point is network architecture. The ideal setup is a single Thread network with multiple fabrics on top of it (as explained in my previous posts). In this model, all Thread routers can be used by all fabrics.

If instead you build separate Thread networks — for example an Apple Thread network, a Google Thread network, and a Homey Thread network — they won’t see each other and won’t share routers. That severely weakens overall coverage. A better approach is to pair devices to one controller first and then share them via multi-admin.

And finally the pitfall I see most often:

With Zigbee, almost every mains-powered device acts as a repeater. With current Matter over Thread devices, this is absolutely not the case.

Some brands like Eve or Onvis clearly build their smart plugs as Thread routers, but many cheaper Matter plugs and bulbs do not support routing at all. Unfortunately this is often not clearly stated on the packaging. In some cases I only found it mentioned in online descriptions like “can extend your network”.

So assuming your network is strong just because you have many wired Matter devices can be completely wrong.

Example: The IKEA KAJPLATS Bulb is Matter over Thread, but it is an end device without router function. Edit: This bulb has routing, so it’s a bad example.

13

The KAJPLATS bulbs are REED devices (Router Eligible End Device). They can become routers when needed, and can downgrade back to a non-routing end device.

Here’s a screenshot from HA (not my own):

image
image522×548 47.4 KB

1 Like
14

Yes, your screenshot clearly shows that the IKEA bulb was a bad example in this case.

That said, the general point still stands: many mains-powered Matter over Thread devices do not act as routers.

It’s also possible that this specific bulb behaves differently depending on firmware version, network conditions, or that it can downgrade to a pure end device role when routing isn’t needed. That could explain why my information about this particular device was different.

In any case, the broader issue remains that — unlike Zigbee — routing is not guaranteed just because a device is hard-wired.

15

There are examples of mains-powered Zigbee end-devices that are not Zigbee repeaters. Sengled Zigbee bulbs and some Zigbee outlets are examples of this. Thus, it is never a guarantee that a mains-powered Zigbee device is a Zigbee repeater. Most are, but not all.

16

I agree. The important difference is that with Zigbee (especially Zigbee 3.0), mains-powered devices are generally expected by the standard to act as routers/repeaters, as long as they implement the router capability. While it’s not a strict 100% requirement, in practice most wired Zigbee devices do extend the mesh.

With Matter over Thread, this assumption no longer holds. Routing is optional in the Thread specification, even for mains-powered devices, so a much smaller and highly device-dependent share of devices actually strengthens the network.

17

FYI - Built-in wall switches/dimmers without a neutral wire are typically also not router devices. Because they are not continuously powered in the traditional sense. They are kept alive by keeping a minimal amount of power flowing by not fully switching off the connected light.

1 Like
18

I agree — but I wouldn’t really classify those devices as mains-powered in the usual sense.

At least for me, “mains-powered” implies having both a live (phase) and a neutral wire available. Switches or dimmers without a neutral are usually powered through leakage current, which is a very different situation and explains why they often don’t support routing.