Thread support

Tagging @Automated_House

same here, it’s even worse … I can see a Nest network on my Android device and a HomePod network on my iOs device.

Smartthings support for new Nanoleaf devices has not been announced. There is still a little hope for Matter. .

While I was expecting Thread will be a new WiFi for IoT (open for eveyone) , now it’s just another proprietary protocol and requires a special partnership to get it working.

1 Like

Looks like that’s the case.

The issue is Nanoleaf Essentials only support Thread 1.0 version and Hub supports Thread 1.3 version. I thought that the 1.3 version is backwords compatible with 1.0.

Hopefully things will get better with Matter and Thread 1.3 version with the new Nanoleaf Essentials matter and thread. I think the new Nanoleaf Essentials and an existing Nanoleaf Essentials are same product just a software difference, Nanoleaf Essentials needs to rollout to the existing product. Hopefully, Nanoleaf stay away from the Marketing gimmicks and create confident in exsiting customers.

1 Like

yeah, Thread is a bit of a mess right now. I currently have 5 separate Thread networks in my home: 2 from SmartThings, 1 from Amazon, 1 from Apple and 1 from Home Assistant.

There’s a variety of issues to why they are currently separate:

  1. A lot of vendors haven’t updated to Thread 1.3 yet which will enable Matter controllers to combine their Thread networks (as i understand it)
  2. Nobody has come out with the UI in their apps to combine the networks

You would assume when I added my SmartThings Station to my network that has a V3 hub on it they would automatically combine to the same Thread network, but nope!

I did previously have My ST V3 and Home Assistant Yellow sharing the same Thread network. I did this 2 or 3 versions ago on HA when they exposed the SI Labs Thread management web portal. But they’ve since removed that and I had to reset my HA Yellow to resolve a zigbee/thread Multi PAN channel conflict.

1 Like

unlikely they told the old Essential will not get an update as the hardware is (not powerful enough ) not made for Matter. This creates a huge confusion in the market, several months ago local shops had discounts of up to 50% to sell off non-Matter Essebtiol stocks.
The second-hand market is going to be a total mess.


This has been discussed before back in February, but the discussion tends to get super technical.

Basically, you can’t think of thread the way you think of Wi-Fi or Zigbee when it comes to the names of networks. It’s just a different architecture. Thread does a lot of stuff at a layer above Where Zigbee and Wi-Fi do it.

I have a friend who calls thread a “mosaic of tiny mesh networks that share a security key” and I think that’s a pretty good way to think about it visually.

Each thread “partition“ can be on a different frequency. Then a thread border router will pass messages between the different partitions by going over the Wi-Fi and back again. Which sounds ugly but actually works pretty well.

And thread is great at frequency agility, much better than Zigbee in most implementations. It can change the thread frequency on the fly very quickly, if needed. But that’s usually done to avoid Wi-Fi interference, not for normal routing.

But mostly once you get to Thread 1.3 the message hits a thread border router, that TBR uses Wi-Fi to get to a TBR on a different partition, and then that second TBR reaches the next set of thread devices.

Also, the partitions get reformed fairly often. You might see one set of “networks” listed on Monday and a different set listed on Tuesday, and it wouldn’t mean anything good or bad. Just that partitions had been re-formed due to local traffic. (a lot of app UIs don’t know how to handle reporting the thread partition stuff.)

It’s part of the “hubless“ concept. There’s no single primary coordinator, so it doesn’t matter if they show up as different “networks.“ They should all still be able to talk to each other. Remember that each end device has its own unique IP address, so the coordinator doesn’t have to keep all of that straight.

All of which is to say, I don’t think it should matter if the app says you have a bunch of different thread networks As long as there are thread border routers to connect them.

But all of that only becomes true with thread 1.3. The older Thread generations aren’t as good at passing stuff between TBRs, if they even do it at all. So that’s a whole separate issue than the fact that you’re seeing multiple “network” entries. :thinking:

(Having said all of that, that’s what’s actually happening at the transport level. But the Thread group has decided to use the term “one thread network” in a way which sort of ignores the fact that the partitions exist. I think that’s a marketing decision, to be honest. They don’t want thread to seem too complicated. The problem is that a lot of the UI’s haven’t kept up. They see different frequencies and assume it’s different networks, which it is from one perspective but not for the way the thread group wants us to look at it. The thread group is basing “Network“ on a shared security key, so the fact that parts of it are on different frequencies, or changing frequencies, doesn’t matter.)

Here’s my previous post on the topic. It includes a bunch of links to technical references if anybody’s interested in a deeper dive.


It sounds fascinating from an engineering point of view. But also as a total disaster from the user’s perspective.

I felt a normal person should know even thinking that there two bulbs have a different version of the protocol and one will work only with HomePod, another will work with Nest as well.

With Zigbee it’s more straightforward, buy our hub and our lightbulbs and they will work. Just follow the brand and “friends” and you’ll be fine

Thread brings another unknowing into this equation, and doesn’t simplify product choice.
I can’t tell my mother just buy something with this logo on the box and it will work.

I still have hopes for Matter.


Right now pretty much anything matter is still in beta. We will have to wait and see what happens once it’s widely deployed. I feel pretty confident, although I may be wrong, that Amazon is not going to turn on thread matter support until it’s both easy and mostly invisible to the typical customer.


The Alexa iOS app needs updating too. Amazon is being very slow with Matter adoption. But the Thread radio in the Echo 4th gen was recently activated. It’s on firmware 1.1 and you can’t do anything with it yet, but progress!

1 Like

Don’t know about the iOS app, but the Android app already has Matter support (for Wi-FI at least). I’ve got a Matter plug set up with an Echo Dot Gen 4 running routines to turn it on/off at specific times.

1 Like

Thank you @JDRoberts for a really good post on Thread that starts to look into the implications of what its widespread adoption still entails.

And as you are almost certainly correct here, meanwhile (maybe 2024!) the typical customer has the choice, as far as the much announced Matter is concerned, of buying Matter over WiFi, Matter over Thread or continue with Zigbee, but relying on the implementation of Matter on the various hubs as the safest bet.
Not an easy choice marketing wise for any manufacturer to decide on the right course.

1 Like

A friend of mine says I need to say something about “fabrics,“ so here goes. (This is one reason I don’t like to get into super technical discussions outside of engineering forums: you’re jumping down the rabbit hole, for sure. :wink:)

I posted this on another site in response to a power user author, who had talked about joining another thread network, which is not actually what happens in matter.

The following is supertechnical, but I do think the definition of “fabric” is a little different than what you have described. It’s a term that the Thread group has used for a long time to deal with the fact that the same security key is shared among devices on completely different networks, like a Wi-Fi device and a thread device. Or even just between two thread partitions that happen to be on different frequencies. They called it “fabric“ because devices on different networks could be woven together using the same security key.

(note that it’s not the networks themselves being woven together, it’s in the application layer above that. You could have two Wi-Fi smart plugs on the same Wi-Fi network, but only one of them is matter-compatible, and only that one would participate in the “fabric“ established by the Matter Controller acting as admin.)

Here’s the official thread border router white paper, which explains:

In matter, devices are paired to a controller known as an admin. Devices become interoperable when they are paired with the same admin. {this is when the security key is exchanged.} examples of Admins are popular smart home platforms and apps that are interested in configuring, controlling, and listening to smart home devices. Groups of such devices are known as a “fabric“ of devices, since the IPv6 messages can be woven across many different physical networks, like Wi-Fi, thread, and ethernet.
This woven nature of matter fabrics is why thread border routers are so crucial to the success of matter with Thread devices, in particular. In principle, a thread mesh without a border router can use matter if configured properly; however, in practice, a border router is required to enable the majority of use cases. This is especially true today, since the vast majority of smart speakers, smartphones, and computers do not have direct Thread capabilities, so they must communicate with Matter over thread devices through a thread border router.”

So a Matter “fabric” is all the devices that are allowed to send messages to each other, regardless of their specific network, because they have all been enrolled to the same admin, and are using the same security key.

the “multi admin” feature in matter means that one device can be enrolled to multiple fabrics at the same time. Note that it might be on the same WiFi or Thread network the whole time, but it’s enrolling individually with different admins, like once with Apple home, and once with home assistant. Again, that’s because matter is in a layer above the transport network.

So it’s not that the thread with matter smart plug is joining a new network when you enroll it with a new controller. It’s joining a new fabric. It’s on the same physical network it was before, but now it has permission to exchange messages with all of the Matter devices that have been enrolled with that new admin, regardless of their individual networks. So that’s why we needed a new term, in this case “fabric,“ because we are talking about a Message exchange method which operates above the level of the physical Networks.

I hope that’s not too technical. Again, all of this will be invisible to most people once matter is fully deployed. But some people may find the engineering details Interesting.



Matter will make the smart home easy! :sweat_smile:

For my understanding, let me pose a Matter over Thread question this way: If I decide to move my Eve motion sensor from one end of house where my ST V3 TBR is (it’s own Thread network), to the other end of the house (out of range of the V3 TBR) where my ST Station TBR is (it’s own Thread network), will the sensor stay online?

1 Like

The TBR doesn’t necessarily make a difference, the question is, who is the admin for the fabric that the Eve motion sensor originally joined.

If the sensor is able to join to the station and keep the same matter identity (same fabric), everything should be fine. You may need to reset it so it can join to the physical thread Network being supported by the station. But as far as the app is concerned, it should have the same address and be the same device.

However, if smartthings has implemented matter so that the fabric isn’t at the account or location level, it’s at the hub level, then I don’t know what’s going to happen to it as far as routines and stuff. It might need to be added as a whole new device. :thinking:

If you find out, let us know!

1 Like

Two more links for those who like to get REALLY deep into the technical details…

Nordic Semiconductor uses the term “operational network” synonymously with “fabric” and Cisco Networks sometimes uses “virtual network” and both mean the same thing: the set of devices which are allowed to exchange messages based on their IP addresses, even if they are on different physical networks.

When you add a new Matter device to your account, you are “commissioning it“ to the specific matter fabric controlled by that Administrator. But in order to simplify adding new devices, the matter specification also allows that administrator to add the device to the appropriate physical Network (WiFi or Thread at this time) so that the end-user doesn’t have to first add it to the Thread/WiFi network and then add it to the matter fabric. It’s two separate steps, one at the physical layer, and one at the application layer, but the end user only has to make one request, and the administrator takes care of everything.

The following article from Nordic semiconductor details how this two-step process works behind the scenes:

So the device gets added to a physical Network, and then gets added to the virtual fabric, but this might all look like one request to the end-user.

And then the following article from the same source explains what happens behind the scenes if you want to add one device to two different fabrics, for example, to google home and to home assistant.

Again, these are highly technical articles, and most people won’t be interested in this level of detail, but it does explain why it’s so easy to get confused.

Your new Thread with Matter device will be added to a physical thread Network (which might have multiple thread border routers) and it will be added to a virtual Matter fabric.

Then, when you go to add it to a second platform, it will be added to a different virtual fabric, but it stays on the same physical Thread Network.

From a network engineering standpoint, the interesting thing is that the two fabrics don’t have to use the same security codes. It’s just that the end device becomes a trusted member of each of the fabrics.

I’d say another way to think about it is that there are multiple overlay networks running on the same physical network. And each overlay has its own administrative orchestrator/controller. And any given device can be a participant in one or more of the overlays.

Except that I think the main point is that a single “fabric” (virtual network) can include devices from multiple physical networks, even networks of different protocols, such as some Wi-Fi devices and some Thread devices.

Then to your point, an individual device can be attached to multiple fabrics.

But there’s no constraint to a single physical network, and that’s really what’s big here.

What you’re describing is how “partitions” work on a single physical thread network. Which is important, but it’s the ability to include select individual devices from multiple networks without having to bind the entire physical network which is what will lead to the hoped for full interoperability for Matter. :thinking:

Right, an overlay that exists independent of the underlying transport. Think of a VXLAN implementation where devices that are attached to physical ethernet ports, VMs that live on a hypervisor, and Wi-Fi devices can all participate in the same overlay.

1 Like

Good morning @JDRoberts @veonua . Speaking of Thread protocol, I wanted to know if the Qingping Thread temperature and humidity sensor will support the Smartthings hub in the future? Will there be a Thread driver for the Smartthings hub in the future? Here is the link for the sensor model:!BRL!250.09!157.58!!!!!%402102172f16821726650543247d06fd!12000031721777452!sea!BR!2106986981&curPageLogUid=tlRHcf1y8TzZ

1 Like

I may be wrong, but my understanding was that smartthings will only support thread devices that use Matter, which the device you linked to does not.

Otherwise, it’s like the WeMo 3 button scene controller or the Netatmo models that do use thread, but don’t support matter. There’s no way to add them to a SmartThings account. :thinking:

But @Automated_House might know more.

1 Like