Is that because both the v3 and the station are both border routers? I thought you could have multiple Matter controllers in a network, but I’m not sure that you can have multiple border routers. @JDRoberts?
Thread spec 1.3 enabled you to have multiple border routers from multiple manufacturers to share the same Thread network. I think I have it working with my SmartThings V3 and my Home Assistant Yellow, but it’s hard to tell.
I don’t normally go too deep into the super technical networking stuff, but I will just mention this briefly.
Thread network integration is done at the application layer level.
Thread radios are frequency agile.
Thread border routers can form separate “partitions” (remember, this is done at the application layer level)
The thread partitions can be reformed as needed
The “leader” border router will look for the least busy channel when forming a new partition
Cross partition communication uses mDNS
I was wrong before when I said that thread and Zigbee in ST hubs would need to be on the same channel when they are using the same radio: the radio ‘just” needs to be frequency agile. (Since ST Zigbee radios have not been frequency Agile in the past, I initially assumed that was still true, but it probably isn’t.)
So… although thread has channels, they aren’t going to be significant to the end-user and you aren’t going to manually switch them.
And I suspect we are going to lose our ability to manually switch the Zigbee channel in the new architecture: it will likely be a frequency agile design, which is something control 4 has used for a long time.
more than one leader means more than one thread mesh. This is fine for thread as long as each mesh has at least one border router….It’s reasonable for two meshes to route over wifi between two border leaders.
My knowledge of Thread is somewhat superficial. My understanding is that a Thread network could be thought of as a single mesh. It uses a single channel at a time. It can change to a different channel in the same way Zigbee supposedly should be able to but doesn’t in practice, but it is not something it does without good reason.
I am also aware that a Thread network with multiple border routers can respond to communication difficulties within the mesh by splitting into partitions, so basically multiple meshes, each of which has a border router. It will return to a single partition when it can.
I am also aware that there is a higher level concept called a Thread domain that combines multiple Thread networks. I don’t know anything more about that.
What I don’t know is what is required, recommended or optional.
It has been reported by members of the community that if they change the Zigbee channel their ST hub is using the Thread channel also changes to the same channel. Perhaps that is a feature of the approach ST have used to implement Zigbee and Thread using the same chip, perhaps it isn’t. So what are the implications of this? Does it suggest Thread networks can be forced to a single channel by a Thread Border Router?
I suspect, but do not know for sure, that thread is frequency agile even in smartthings, meaning it can change between channels on its own as needed.
So it might simply be a reporting artifact: they may be reporting the thread channel as whatever the Zigbee channel is currently set to.
(BTW, there are lots of real world Zigbee implementations which are frequency agile, it’s just that smartthings never has been.
It’s been particularly used by smart meters, tv cable boxes, and some metered appliances, typically mains power devices that are professionally installed in residential environments. It’s mostly used there to avoid Wi-Fi interference.
What tends to Trip it up is sensornets or other deployments with large numbers of battery powered sleepy devices, as they may miss the message about the channel change.
But that’s actually one of the reasons why Zigbee uses the secure rejoin: many battery powered devices are engineered so that if they can’t find the hub, they will try another channel in case they just missed the channel change while they were sleeping.
If it has a Bluetooth radio, that can be re-purposed for thread. That’s how eve did their in place updates, for example. There isn’t really such a thing as a “thread radio.“ There’s a 2.4 GHz radio. the same radio could be used for Wi-Fi, Bluetooth, Zigbee, or thread. But the firmware has to be updated to manage it.
That said, that’s a technical answer. Just because the radio can be updated to thread, doesn’t mean the device can be updated to matter (as some manufacturers have discovered). There are some security and always listening requirements for matter that older hardware may not be able to support even if they have a thread radio.
Well, my fridge is currently acting as a Hub running 42.7. I can even add devices to it (LAN only at this point since no dongle yet) and install Edge drivers. I’m hoping that once they add Matter support to the dongle, they’ll also update the fridge Hub firmware to support Matter as well. If that all happens, then I’ll have a Matter Thread Border Router and Matter Controller all in one.