Interesting for the continued standardization of Matter. Not that we didn't know this kind of crap wasn't coming...
2 Likes
I'd argue that Matter via wifi/lan will be more impactful than Thread as wifi modules are fairly cheap compared to others. It will make it easier to bring to market since wifi is nearly everywhere and most homes have it. Just for Hubitat alone, Matter via wifi will allow for local push control rather than current polling for lan devices.
@JB10 Thread runs over Wi-Fi. It's the main binding protocol. Matter can work without thread but it's better with it
What about that many devices via wifi. Fine for a few smart devices but try to add 300 smart devices going through your wifi router?
1 Like
@rlithgow1, you have it backwards. Matter runs over thread or Wi-Fi. Thread is closer to Zigbee than anything else.
4 Likes
@kahn-hubitat no disagreement there on having that many Wi-Fi devices. I just look around the forum and the amount of folks with Kasa, LIFX, Wiz, and other assorted Wi-Fi type devices. Rather than have all these individual integrations, it will be much easier on the Hubitat staff to provide a Matter integration.
What Matter will ultimately do is just provide more flexibility for those of us with Hubitat Hubs. We will be able to utilize Zigbee, Zwave, Wi-Fi, and potentially Thread devices and pick the best tool for the job.
2 Likes
I doubt those knuckleheads even have anything Thread or Matter at home. Thread isn't a protocol like Zigbee, Zwave and Homekit, its a transport layer like wifi. You can have thread hubs that talk Homekit, Matter, and probably Google-Nests own development language.
Matter's problem isn't thread, Thread is it's own problem. Thread didn't put in a standard way to allow its hubs to talk to each other so we end up with multiple whacky thread networks in our homes.
Heres a glimpse of my own thread networks from my home assistant system. Not even Amazon's Eeros and Echos fully talk to each other I have one echo communicating with Eero's thread hub and others forming their own.
I think you may be seeing something known as "Thread-over-infrastructure" at work in your network.
As best I understand it from the openthread border router documents here: OpenThread Border Router, the forming of multiple thread sub-networks is what is supposed to happen (at least under certain network scenarios where a single mesh can't be formed). This may occur where, for example, you have groups of end-devices that are isolated from each other so as to be unable to interconnect into a single reliable IEEE 802.15.4 network. In that case, the devices can form isolated groups, each having their own border router to a local mesh. Thread border routers each implement a (mandatory) feature known as "Thread-over-infrastructure" (referenced here: https://openthread.io/codelabs/openthread-border-router#0 that then allows the border routers to communicate with each other over wifi or ethernet to form a merged network. This also provides bandwidth improvements as even in the case where a single border router is established (in that case, the other boarder routers act as "regular" routing nodes to communicate via 802.15.14), each border router capable node, even if demoted to act as a "regular" router, can still use their ethernet / wifi link to backhaul to the "main" border router so additional jumps over the 802.15.4 network can be reduced
Compare this to zigbee. In zigbee, if you had isolated groups, the mesh would not full form leaving some devices unreachable. To fix this, you'd have to start adding additional zigbee devices to get the mesh to stabilize adding potentially long routes over the relatively slow 802.15.14 links. With thread, the border routers can provide an alternate way of joining isolated groups into a single network with faster links for backhaul.
1 Like
Not to be pedantic, but Thread is a protocol.
1 Like
This topic was automatically closed 365 days after the last reply. New replies are no longer allowed.
