The Matter Smart Home Standard
The smart home community was stirred into a frenzy during January of 2020 when it was announced that all the big names in the industry had joined forces under a new initiate to ‘solve’ smart home fragmentation, called the Connected Home over IP initiative.
This initiative was formed under the umbrella of the ZigBee Alliance, probably because most of the players involved were already members. But that has now changed, with the group moving to a new phase as we get closer to what is hoped to be the holy grail of smart home integration, a unifying standard for all devices to communicate.
As a reflection of how significant this is, the ZigBee Alliance is no more, having rebranded to the Connectivity Standards Alliance in 2021. Along with that rebranding came the announcement of Matter, the name chosen for this new connectivity standard. After some delays due to ongoing negotiations on the technical details between members, the Matter Specification 1.0 was finally released in September of 2022 along with a raft of device announcements from dozens of brands.
Personally, I can see that name being a bit of an issue as it’s a common word that has nothing to do with the tech industry, so it’s not easy to find info on it. Nonetheless it shows a lot of promise in delivering on the stated goals.
What is Matter?
Matter is a new integration standard being built by a consortium of major tech brands, including Google, Amazon, Apple, Signify (Philips Hue), Tuya, LeGrand, SmartThings, Huawei, and many more. Importantly, it’s being developed as open source, and we can already dig into the code that has been submitted on GitHub.
“The Project’s design and technical processes are intended to be open and transparent to the general public, including to Work Group non-members wherever possible. The availability of this GitHub repository and its source code under an Apache v2 license is an important and demonstrable step to achieving this commitment.”
Matter provides for the creation of ‘Fabrics’ which are collections of devices that share a common trusted security root. You can have multiple fabrics on the same physical networks, including the same devices, but with difference administrators - administrator is the highest access level in a fabric. This allows for using multiple smart home platforms (essentially Fabrics) or apps to control the same set of devices without them needing to share security information.
The Matter specification is available for free download and provides all the required information to implement the standard and is intended for those creating devices or applications that use it. It’s pretty deep, so it won’t be for everyone, and it’s certainly a lot more than you need to understand as a smart home enthusiast.
I’ve distilled the important stuff that you need to understand in this article, and we’ll get into that in a moment.
Why Is Matter important?
Smart Home products need to communicate with each other in order to provide the benefits of automation in the home. Not that long ago every device had its own app, and nothing worked together very well. The big tech players have tried to improve this with their respective platforms by providing a consistent standard that device makers can use to integrate with them, but these are all different, and use different approaches.
Additionally, there are different communication protocols being used, also in an attempt to improve interoperability. These mean that some devices simply aren’t even on the same wavelength (so to speak) as others, so they can’t talk to each other at all.
Sticking to one platform can help to solve the mess of apps and provide a common integration experience, but that doesn’t solve the need for various hubs to enable communication in the first place, nor does it prevent you being shut out of certain products because they don’t support your platform of choice.
Matter aims to solve all these problems by defining a standard communication technology, and a standard application layer that all devices can use and understand consistently. This would eliminate the need for hubs or controllers and allow for devices to be controlled locally, improving reliability and security by negating the need for cloud servers.
Having this standard be based on open-source code, and supported by such a huge swath of the industry is a very good start. That ensures no one needs to be locked out by licensing fees, while still allowing for a widely accepted certification process to ensure standards compliance.
The state of play
Integration Types
Smart device makers and the platforms the integrate with take different approaches to how they, and we, control their devices. Many opt for maximum compatibility and go with the ubiquitous Wi-Fi protocol for communications. That’s fine, but it’s not suitable for smaller battery powered devices like sensors, it can be clunky to set up new devices, and there is no standard for how those devices should communicate with one another.
To solve this last problem, these devices tend to use cloud-based services to control them and provide an application layer interface (API) for others to use. These Web-based APIs are all different and require custom code to interface with them. Platforms like Amazon and Google have adopted this as the primary method of integrating with their platforms. Using a special software plugin built to their own standard, the platform can be told what functions it can use and how to connect to the API.
Of course, this requires every device brand to have a user account, which means more passwords and more risk of leaks and hacks by connecting to a plethora of cloud services with unknown security controls. Oh, and if your internet, or their servers, go down, you can’t use your device at all.
Other makers go with local control provided by specialist smart device protocols like ZigBee and Z-Wave. But these devices need a compatible hub to connect to, and even though these protocols are intended to provide interoperability, variations in implementation means bespoke handlers are still often required to make a device work correctly. This adds complexity and roadblocks for end users.
How Does Matter Work?
The Technology Stack
All modern data networks comprise a ‘stack’ of technologies, each adding functionality on top of one another in layers. Each layer abstracts the ones below and focuses on specific functionality that allows different aspect of the network to function without having to worry about the others. Matter is a stack as well that handles the definition of devices types, data structures, interactions between devices, encryption and authentication of messages, and the packaging of those messages for sending out on the network.
Matter Network Stack
Matter itself sits at the top of the network stack, forming the Application layer. This is where the user-facing logic takes place, in this case controlling our smart devices and getting data back from them. A unified application layer ensure that all devices can understand each other, can read the data they need (say a fan getting data from a temperature sensor), can send commands (a motion sensor telling a light to turn on), and can be accessed by any compatible app (Google Home for example).
This application layer is useless without consistent communication between devices, though. So the standard will specify the communication technologies to be used. Initially this will be Wi-Fi (for high bandwidth) and Thread (for low bandwidth/low power) for operational use, and Bluetooth for initial discovery and provisioning. This is a common use of Bluetooth in the smart device market now, and many device makers use this to simplify locating and pairing with a new device already.
All Matter devices will leverage IP addressing, specifically IPv6. IP is ubiquitous on the internet and throughout the world’s local networks and has proven itself scalable and versatile for all use cases. IPv6 in particular allows for a wide range of addressing and routing schemes that can be universally handled across different network types and has been specifically adopted in the Thread protocol for these reasons. By using IPv6 connected device networks will be able to scale freely and communicate without the risk of being segregated by different intermediate technologies.
As with other standards in the market, device makers will need to seek certification in order to be able to label their products as Matter compatible. We don’t know if any stricter enforcement will be applied yet at the network level. Certification will be performed by the Connectivity Standards Alliance in the same way that ZigBee implementation is certified today.
The Data Model
Devices in Matters consist of a hierarchy of data elements that define the capabilities of the device and allow it to be controlled. At the top of the hierarchy is the Node. Most smart devices will have one Node which contains the functionality of the device. Complex devices, like smart phones, can have many nodes covering their various distinct functions.
Within each Node are at least 2 Endpoints. The first Endpoint, known as Endpoint 0 or the Root Node, contains the device information pertaining to addressing, discovery, firmware versions and so forth. Other Endpoints are created to contain distinct functions depending on the type of device.
These functions are contained within another level called a Cluster. Each device type will have mandatory and option clusters defined by the Matter Device Library Specification document. These clusters contain Attributes and Commands which contain stateful information about the device and things it can do, respectively. These values are covered by the Matter Application Cluster Specification. These documents are available for free from the CSA Download page.
Additionally, each Cluster can be defined as a Server or Client. Server clusters are stateful and can be controlled while Client clusters are stateless and only initiate interactions with Server clusters. These interactions can be reading or writing attributes or invoking remote commands.
The diagram below shows how these various layers relate to one another in a (somewhat silly) example of a basic light bulb with a built-in temperature sensor. This is simply to show how different Endpoints can be used to encapsulate discrete functionality. The green nodes are Attributes while the red are Commands. Only the basic mandatory Clusters are shown, other clusters and attributes could also be included to represent additional functions or state data. For example, Endpoint 1 could also include the Level Control cluster if the light was dimmable, and the Color Control cluster if it had selectable color.
A basic representation of a light bulb with a built-in temperature sensor
Device Discovery
In order for a Controller (usually a smartphone app like Apple Home or Google Home) to find devices to add to a Matter Fabric a discovery process must be used. This can be done over normal Bluetooth discovery or Wi-Fi.
For Wi-Fi discovery, a yet to be commissioned device can create an ad-hoc Wi-Fi network using a pre-defined SSID based on its vendor (v) and product ID (p) numbers and a 12-bit discriminator (d) that allow a scanning commissioner to find it automatically. Once joined, the two devices will create a local IPv6 connection and then continue the provisioning process. This will be in the form of:
MATTER-ddd-vvvv-pppp
If the device has been joined to the network already, either via Ethernet or by another app, then DNS-SD (Service Discovery) will be used over mDNS. By using multicast DNS (mDNS) all parties have a known address to listen on for discovery requests and to advertise their service availability.
A device that is ready for initial setup will advertise the service _matterc._udp that provides the connection details a controller can use to initiate the provisioning process. Once the device has been joined to a Fabric it will advertise the service _matter._tcp with the addresses for communication. These ongoing advertisements are known as Operational Discovery and will always be done via DNS-SD over mDNS.
Limitations And Issues
Currently the biggest issue facing Matter today is a lack of communication between Fabric Controllers. While any Matter device can be added to multiple fabrics under multiple controllers (basically multiple Smart Home platforms and apps), once they are added there is no syncronization of the configuration between them.
As a basic example, if you were to add a device to Apple HomeKit and Google Home, changing the name of the device in one would not be reflected in the other. Obviously, this makes for potentially frustrating management of a smart home. When it comes to concepts like room and groups things get messy as the platforms handle these things quite differently.
The major platforms claim to be working on this, but there is yet to be any agreement on how this can be standardized.
In Summary
The Matter standard holds the promise is unifying the smart home space and enabling faster, more reliable, and more secure device integration that many devices offer today. More importantly, it will open up the market by enabling the use of any device with any app or platform.
Being open source will greatly help adoption and industry confidence as it ensures many eyes will be on the code base to drive improvements. Having a more open standard will also allow for greater expert knowledge to grow in the community as the technical details won’t be walled off by expensive fees or “black box” implementations.
I’ll be updating this article as we learn more about the standard and the implementation details.
