Thread support

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

How can you tell if Thread Radio has been activated on you Echo 4th gen. and what the firmware version is?

I suspect that if Thread support is available, your device will list it in the Wireless section of the device details, as it does for Wi-Fi and Bluetooth.

1 Like

It shows up in both my Nanoleaf app and Home Assistant Thread settings. Home Assistant let’s me see the details like version.

1 Like

Thanks, I looked in the Alexa App and couldn’t find that information. Since Thread is not listed on the Device setup page I am assuming it is not active on my Echo 4th gen.

It’s not listed on mine either. They silently turned it on, but its not useable yet as far as I know.

1 Like