I have got a Thread-enabled led strip from Nanoleaf for Black Friday.
The Hub shows some information on the Thread, but the Nanoleaf app doesn’t see any thread routers nearby (<1 m).
Is it something to be done to activate Thread support on the ST? At this moment my hub is connected via LAN and doesn’t have WiFi credentials.
Which model hub do you have? The v3 is a thread border router, the V2 and the WiFi mesh models are not.
Wow! Are you in the beta for hub updates?
Guessing you’ve got a V3 or Aeotec hub.
The latest version of Nanoleaf app showing the thread network however the thread network in the Aeotec Hub has a different thread network name. The hub is connected via LAN cable however it configured to wifi if I remove the cable.
I am currently, have Nanoleaf essentials E27 Smart Bulb (no matter) that is connected to the thread network. In both cases LAN and wifi cases the Thread network in Nanoleaf and Aeotec Hub does not matches. In past I have connected Nanolead to Google Nest Hub v2 thread network.
See the attached screenshots.
Nanoleaf App thread Screenshot
Hub Thread screenshot
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.
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.
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:
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.
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. 
(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!
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.
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.
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. 
)
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! 
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?
