#So, and again this is at the 1st grade
1 messages · Page 1 of 1 (latest)
As other members here already stated: yes, they do work together, as much as matter can work with anything that is essentially IPv6 based. And yes, Matter has some tweaks to handle some of Thread's intricacies. This decoupling is an intentional design choice.
In terms of the OSI model Thread, like Ethernet or WiFi serves as the physical transport layer foundation operating on Layers 1-4 while Matter sits on top (Layers 4-7). This is fundamentally different to the ZigBee design, e.g.
The current matter server implementation uses information that it gets from "connected" devices. And "connected" here means that a device has been commisioned to the matter network (we use the term fabric to make a destiction to the actual "physical" network, i.e. Thread, WiFi, Ethernet). This connection is authenticated and encrypted. So, on a matter protocol level the server can only directly see peers/nodes that are part of it's fabric. Oftentimes though, Matter devices reveal some information about their immediate environment in either their WiFiNetworkDiagnostics or ThreadNetworkDiagnostics. That is how the matter server in it's current implementation state can draw its conclusions and know about the existence of border routers or WiFi access points.
See here for the Matter/Thread OSI layer reference: https://developers.home.google.com/matter/primer?hl=en
Now, I have a couple of Matter over Thread devices that just don't expose such information. These appear completely isolated in my matter server thread mesh graph. Probably your single MoT device behaves the same.
Yes, everybody wants better integration. For vendors who bundle their version of a matter controller with their version of a border router it is easy to provide this kind of a more seamless integration. A border router should at all times know the full topology of its current thread mesh partition (including nodes that are not part of the current matter fabric). At the same time Matter was designed to work with any border router, and most consumer grade products don't expose such information. The only openly documented border router implementation that I know of is the OpenThread border router. And it also offers a well defined and documented API.
Now, while most border routers on the market are derivates of that implementation vendors tend to close the API. So you basically depend on a running "vanilla" OpenThread border router in your thread mesh for the matter server to make use of it. Now, while you can use the Home Assistant OTBR Add-on/App, the current matter server implementation (remember 0.5.x beta) doesn't make use of its API. At the same time, this would be an optional fetaure, because not everybody wants to run the HA OTBR (and potentially buy extra hardware to do so) but use what they already have in their pre-existing eco system.
Ultimately, this would be a product decision to be made once the new matter server App and the new OTBR App get ready to be officially released.