Chip / Matter support (including Thread)

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).

https://buildwithmatter.comhttps://github.com/project-chip

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. :woozy_face:
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 :wink:

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)

1 Like

Matter/CHIP could be implemented as either native integration like ZHA (and Z-Wave JS) or external like Zigbee2MQTT.

I suggested the latter as Zigbee2MQTT expansion to its developers but not much interest today, see

https://github.com/Koenkk/zigbee2mqtt/discussions/7443

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.

https://www.threadgroup.org/news-events/blog/ID/229/Thread-Border-Router-The-simple-component-to-get-your-Thread-network-started

https://openthread.io/guides/border-router

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:

https://www.nordicsemi.com/Software-and-tools/Development-Kits/nRF52840-Dongle

2 Likes

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:

https://staceyoniot.com/thread-101-what-you-need-to-know-about-this-smart-home-protocol-in-2021/

https://github.com/project-chip/connectedhomeip/blob/805a4b3fcd753fdb75126d34bb41c7f6137da70f/docs/guides/nrfconnect_android_commissioning.md

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.

Yes. He may be silly, but that’s along the lines of what I’m imagining as a bad-case scenario.

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 …

Ok startpost edited…

1 Like

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 :roll_eyes:

1 Like

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.

My point being, it’s not a good solution for us end users.

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 :wink:). 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.

if only it was as simple as Australia being an outlier frequency.

What we need is countries to give up some frequencies for standards

@MoeJoe @HeyImAlex Neither statements are actually completely true nor completely false either.

Matter/CHIP is an “open standard”, meaning that the documentation should be publicly available and it does have an open source for a reference implementation, but the Matter/CHIP specifications itself is not “open source”.

The specification of the Matter/CHIP protocol itself and its technical documentation is proprietary and those are controlled by the technology consortium Connectivity Standards Alliance (CSA), meaning that unlike an open-source project you can not copy it (fork it) and make release your own specification under a different name.

As it is “open standard” you are allowed to make and publish your own Matter/CHIP implementation (like a new open-source integration for Home Assistant) based on the reference implementation royalty-free without having to pay anything to the owners of Matter/CHIP, however, if you later want to get a certification that implementation to get an official rubber stamp of compatibility approval by Connectivity Standards Alliance then you need to pay CSA for that certification process, and if you also join the CSA as a member then you get a say in the direction of Matter/CHIP as a standard and have the possibility to influence the specification.

PS: Suggest you see Wikipedia article on open standard → https://en.wikipedia.org/wiki/Open_standard

1 Like

You are mixing things up. An open standard is, as the name implies, open. Its specifications and technical details must be available for anyone to use and implement, without royalties, license fees, hidden patents or other legal constraints. A standard cannot be open source, as there is no source in a standard. A reference implementation of a standard may or may not be open source, but the lack of reference implementation or even a closed one does not make the standard closed as long as specifications are available. This also holds the other way round. An open reference implementation of a closed standard does not make the standard open. In fact, Matter does not meet the requirements for an open standard by either OASIS, OSI or the FSF (see here for more info). Until the specifications are made generally available without restrictions (which may or may not happen in the future), Matter is not an open standard.

1 Like

Those are not hard requirements for “open standard”. There is more definitions with other requirements.

Quote below from https://en.wikipedia.org/wiki/Open_standard

Many definitions of the term standard permit patent holders to impose “reasonable and non-discriminatory licensing” royalty fees and other licensing terms on implementers or users of the standard. For example, the rules for standards published by the major internationally recognized standards bodies such as the Internet Engineering Task Force (IETF), International Organization for Standardization (ISO), International Electrotechnical Commission (IEC), and ITU-T permit their standards to contain specifications whose implementation will require payment of patent licensing fees. Among these organizations, only the IETF and ITU-T explicitly refer to their standards as “open standards”, while the others refer only to producing “standards”. The IETF and ITU-T use definitions of “open standard” that allow “reasonable and non-discriminatory” patent licensing fee requirements.

There are those in the open-source software community who hold that an “open standard” is only open if it can be freely adopted, implemented and extended.[1] While open standards or architectures are considered non-proprietary in the sense that the standard is either unowned or owned by a collective body, it can still be publicly shared and not tightly guarded.[2]

1 Like

Oh please. If a standard specification is not open, then the standard is not open. Period. Companies will try to weasel around that all the time, because ‘open standard’ makes good a press and PR statement. Can I reimplement Matter without reverse engineering their chaotic code dump or without becoming a member for $7k and most likely signing an NDA ? No, I can’t. Is that an open standard ? No, it’s not. I don’t know what is so hard to understand about this, reading past all the Google/Amazon/Apple marketing BS.

2 Likes