I think Thread and Matter a two different problems to solve.
Thread as a network needs a Thread Border Gateway, which is basically an IP router that routes IPv6 packets between the Thread network an the LAN (and helps a little bit with service discovery and commissioning). There’s Google’s reference implementation called OpenThread that can be run with a 802.15.4 compatible USB microcontroller like a nRF52840 dongle with an RCP OpenThread firmware on it and a RasPi or docker container (here’s a guide). The cheap ebyte nRF52840 dongles from AliExpress work, the official Dongle from Nordic also isn’t expensive. (Might change, seems the nRF52840 is hit by the semiconductor crisis, individual chips are out of stock everywhere.) Other chips might be used too with an OpenThread RCP firmware, but nRF528xx is used in all examples. But I guess every new released talking home cylinder will include a thread border gateway.
Matter meanwhile is a protocol on top of IP and designed to be used with Thread, but can be used with other IP transport layers too, mostly WiFi. Matter should be an ordinary IP based integration in Home Assistant, so no thread2mqtt needed. There’s an open source reference implementation in the Project CHIP github repo, but the specification seems only to be available for ZigbeeConnectivity Standards Alliance members (at least yet). Interesting definition of an “open standard“. I’m not sure how usable the reference implementation is at the moment, the repo is very confusing and the documentation is distributed all over the place or does not exist. Without the spec the protocol would have to be reverse engineered first.
Watch his recent video where he claims that Phillips Hue will still require you to have their proprietary hub. If you don’t want to watch the whole thing, it’s at about 8:35.
FYI, it is not the Thread network protocol that will be “THE” new open standard for this, instead, it is Matter/CHIP that will be “THE” new open standard. Thread is just one of the network layers supported by Matter/CHIP, while other supported network layers will initially also be; WiFi, Ethernet, and BLE (Bluetooth Low Entergy), while support for possibly even more types of network layers could maybe be added in the future, (though they may perhaps not do so as TCP/IP support as then there less of a need to add bridges/gateways).
The whole Matter/CHIP stack is also not really based fully on all Zigbee specifications, however one specific select part of it is the re-use of the ZCL (Zigbee Cluster Library) specification as an device abstraction in the protocol stack which allows implementing both global artifacts + unique attributes and commands functionality for many different devices types. But since ZCL is an important part of the existing ZHA integration if might be possible to look at using its code as a base for a new Matter/CHIP integration?
So there should not be any need to specifically add an integration with support for Thread. Instead there is need for an integration for “Matter” (formally CHIP) application layer thast communicate over TCP/IP.
I posted some news about this new open standard here:
Youtubers like him are so annoying with their „i make everything ridicolous“-videos.
back to topic:
Philips already announced in january, to only update the firmware of the HUE-bridge and not for every single light(product) they have.
But i think thats no issue, its more an opportunity for customers to upgrade their allready existing Hue-infrastructure to Matter.
The solution for us customers is quite simple. There will be (and allready are) other manufacturers with native Matter support in their lights. Just buy them
In the video(at 5:00), he also tells that the main problem for companies was the expensive certification for existing solutions like Zigbee,Homekit etc.
This problem doesnt exist anymore. Now even small companies can make products based on Matter, what leads to more products/companies that will support the new standard.
Im pretty sure, that Philips will change their strategy in the future, because there are much more competitors now they have to withstand. Why should someone buy a proprietary Hue lamp, when other lamps from a chinese manufacturer are cheaper and fully standalone compatibel?
@Hedda
we already mentioned that above(more or less)
Guess that general interest in the community will change when native Matter low-energy devices arrive.
Yes any Matter/CHIP devices that are based on Thread hardware will need an dedicated type of “Thread Border Router” RF-adapter (normally a Thread USB dongle/stick or a in a Thread to WiFi/Ethernet format) similarly to the hardware requirements for “Zigbee coordinator” or “Z-Wave controller”.
As both Thread and Matter/CHIP is IP-based the main difference between Zigbee coordinators and Z-Wave controllers and a Thread Border Router is that Thread Border Router for Matter/CHIP will connect WiFi/Ethernet LAN network to a Thread RF network while continuing to use TCP/IP instead of converting to a completely different transport layer like Zigbee and Z-Wave does. As such, a Thread Border Router acts almost exactly to a WiFi Access Point.
Nice is the MCU chips used in most Zigbee 3.0 coordinator hardware (and Zigbee 3.0 device hardware) does also support Thread as an alternative application firmware. So if you already have or buy a newer Zigbee 3.0 coordinator hardware then the good news is that you will likely be able to convert it into a Matter/CHIP compatible Thread Border Router in the future by simply flashing it with other firmware. The somewhat bad news is that you will probably still need a separate USB stick/dongle for Zigbee 3.0 and Matter/CHIP as the same MCU is unlikely to support run both as a Zigbee coorinator and a Thread Border Router at the same time.
PS: Recommended reference hardwarer for developer is the Nordic Semiconductor nRF52840 dongle:
IMHO a better is be to have subject topic “Matter/CHIP over Thread support” as that is the request.
This as any new Matter/CHIP integration will automatically get support for Matter/CHIP over Ethernet and WiFi, while much more work would be required to add native support for Matter/CHIP over Thread.
In order for integration to natively support for Matter/CHIP over Thread (to communicate with local Thread devices) the new Matter/CHIP integration also needs to integrate a Thread Border Router. See:
Why? We dont want Matter support over Thread only. Like you said yourself, Matter also supports WiFi, BL-Low energy, Ethernet…
If HA supports Matter natively, for example you could add Wifi-Matter devices over a normal router/wifi accesspoint. Or am i wrong?
Maybe i misunderstand you. English is not my native language …
Well, I guess that an integration that supports “Matter/CHIP over Thread support” is what you are actually requesting here. That is, an integration that can not only support “Matter/CHIP over Ethernet/WiFi” but one that also has native support which has a built-in functionality with config flow for setting up a Thread Border Router using a direct-attached Thread USB dongle/stick and via it create a local a Thread network which communicates via RF directly with low-power Matter/CHIP devices. As I assume that you do not just want an integration that only supports “Matter/CHIP over Ethernet/WiFi” as that would mean it has a prerequisite that the user first need to set up a third-party and create plus maintain the network via that as the controller. So more how the native ZHA integration functions than how Zigbee2MQTT working with HA via MQTT. Otherwise, as Thread can also be used stand-alone without Matter/CHIP, you could have a separate Thread integration that a “Matter/CHIP” integration could depend on.
Regardless the current title “Thread / Matter support” is misleading or simply wrong because Thread is not Matter/CHIP, and Matter/CHIP is not Thread. Matter is CHIP, and CHIP is Matter, and Matter/CHIP is an IP-based application protocol that can be used over Thread or over Ethernet/WiFi as its network layer. I think that you should really not write “Thread / Matter” as that is not what you are asking for so it is confusing.
Therefore I suggest change title to “Matter/CHIP over Thread support”, or “Matter/CHIP support and Thread support” or just “Matter/CHIP support”. As long as you seperate “Thread” from “Matter/CHIP” with more than a slash (“/”) sign.
That is true, i will edit the headline and the post to avoid a misunderstanding and to provide more informations.
When i started this thread, i had some educational gaps to the topic …
As far as I understand, this is not true. Developing a Matter based device specifically requires certification from the CSA to make sure it follows the interoperability standards. To get certified, you need an Adopter membership with the CSA ($7k / year) plus at least $1k per certified product. That might not be much for a larger company, but it will most definitely be a roadblock for small or independent developers.
So basically Matter is a semi-proprietary thing (the specifications are not open !), IP routed, that is pretty much entirely controlled by Amazon, Google and Apple. Yay. Exactly what the world needed …
Before you needed a certificate for Apple, for Zigbee, for Google, for Microsoft… to make it compatible to every platform.
And most companys only bought one or two certificates, like nanoleaf had only support for apple.
Now they can buy only one certificate and they have full compatibility to all platforms.
As far as i know, thats not true. Matter (formerly Chip) is open source and available on Github.
And the compatibility doesnt only rely on the IP interface. Every company can join the alliance and most will. Because of the fact that all the big players joined, it makes matter mostly universal.
You don’t have to watch his video for that. It was in the Signify statement about Matter support : the lights remain Zigbee, the Hue hub will make the translation between Matter and Zigbee.
We have had that for more than 20 years now. It’s called Zwave. Of course, the three big letter companies don’t have their claws benevolent hands on that one…
And of course the price tag on (mandatory) Matter certification will weed out all independent one-man shops and small businesses right away.
That is only the reference implementation. It does not include the specifications. You can’t do much with a code dump of an implementation, you need the specs to design a reliable product. And that does also include implementations as the one you’re asking for in HA. So either you have to shell out the cash for a CSA membership and get the official specs (probably under NDA) or someone will have to reverse engineer the reference implementation. Which gives us yet another half-reliable thing that could break on any new spec. At this point (we’ll see in the future), Matter is definitely not open.
Yeah the big players who’s primary business model is massive data collection. Great. I’ll pass on Matter.
Thats not strictly true either
Zwave has different frequency requirements per country. In Australia we cannot use Zwave product from say US or EU due to different frequencies.
Well, that situation is a little different. Even though you can not mix EU/US/AUS zwave devices, they do still talk the same language across manufacturers and they’re all certified to work together. It’s more like you buy a 120V device in the US and try to run it in a 240V country. There are physical differences that make them incompatible.
So this unfortunate situation comes down to a business decision by the device manufacturer, that is beyond any technical compatibility considerations. The fact that Australia uses a weird outlier frequency for that band doesn’t help. But you could easily get similar situations with Matter (or Zigbee or whatever) devices where manufacturers just don’t want to pay for electrical code certification in certain countries they deem unprofitable. The frequency problem just makes it a bit worse for zwave than for 2.4 or 5Ghz band devices (it does have other physical advantages though in terms of penetration and interference). Technically, Matter could actually work on the ISM band used by zwave too, as it doesn’t define the physical layer.
Edit: oh and I’m not trying to push zwave against Matter or anything (although I like zwave ). It was just an example of how a supposedly great innovative feature of Matter (certified vendor interoperability) isn’t actually new or innovative at all.
…