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.
Some references:
-
Network formation: Descubrimiento y formación de redes | OpenThread
-
how thread partitions work:
https://openthread.io/guides/thread-primer/node-roles-and-types
-
official document on TBRs https://www.threadgroup.org/Portals/0/documents/support/ThreadBorderRouterWhitePaper_07192022_4001_1.pdf
-
From a Netatmo thread presentation:
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.
And resources:
A) bonjour!
Android utility: https://play.google.com/store/apps/details?id=com.druk.servicebrowser
iOS utility: Discovery - DNS-SD Browser on the App Store