diff --git a/pr-preview/pr-4/404.html b/pr-preview/pr-4/404.html deleted file mode 100644 index 114164f..0000000 --- a/pr-preview/pr-4/404.html +++ /dev/null @@ -1 +0,0 @@ -
The Alliance has a number of Working Groups responsible for each of the different standards that we manage.
Matter is one such Working Group, the WG is governed by a Steering Committee. The SC manages overall activities, priorities, scope & budget of the Working Group.
Beneath the Matter Working Group are 3 Sub Groups:
The Marketing and Product Sub Group (MPSG) is responsible for capturing use cases, identifying functional/non-functional requirements, and producing marketing requirements documents (MRDs) for hand-over to the Technical Sub Group. -They also develop branding, positioning and external communications materials relating to Matter.
The Technical Sub Group (TSG) develops the technical aspects of the Matter from the requirements given to them and takes this through specification release. -The Matter TSG also has an active Software Development Tiger Team who maintain and develop the open source Matter SDK.
The Certification Sub Group (CSG) develops methods to test for specification conformance, from test cases & scripts, to test events leading up to specification release.
Additionally each Sub Group forms a number of Tiger Teams to focus on a specific topic or item and feed this work up into the sub group. Some teams are ongoing, others are formed for the purpose of a specific deliverable and then dissolved.
Membership of each working group is open to a member company holding participant or promoter level membership. Once a member company has formally joined a WG then employees of that company can participate in the sub groups and tiger teams.
Our wide-ranging global membership is on a mission. That mission is to ignite creativity and collaboration in the Internet of Things, by developing, evolving, and promoting universal open standards that enable all objects to securely connect and interact. We believe all objects can work together to enhance the way we live, work, and play. Learn more
The Alliance is the owner of the Matter specification and its associated marks. We are responsible for the continued development of the specification, the certification of products, and the promotion of Matter.
The Alliance is a member driven organization. The majority of the work on Matter is done by members with the support of their companies, and the Alliance employs a relatively small full time staff to facilitate, co-ordinate and support this work.
Work with the world’s most innovative companies to create, evolve, and promote universal open standards that connect all IoT devices – regardless of country, network, brand, or function – for a unifying wireless experience that inspires new possibilities for people everywhere.
Curious about which level is right for your company? Below is an overview of the four types of membership available:
Associate Members use standards-based IoT products but do not directly build or manufacture them. To join at the Associate level and certify white-label products, a company must partner with an Alliance Participant or Promoter member through our Certification Transfer Program.
Adopter Members use existing, approved specifications to build products. Adopters can access completed, approved standards documents, certify products through Alliance certification programs, and use Alliance technology logos and trademarks for certified products.
Participant Members contribute to and develop standards they will later adopt and use. Participants can access Alliance Working Groups, are hands-on in developing specifications, and gain early access to draft specifications and testing, with the opportunity to develop and get to market faster.
Promoter Members contribute to, develop, and adopt Alliance standards and enjoy all other member-level benefits. Promoters help lead the Alliance with final approval on all standards, hold a seat on the Alliance Board of Directors, and may lead and participate in Board Committees.
If you are already a member of the Alliance, here are some helpful links found in Causeway (you’ll need to log in with your member credentials).
We create, evolve, and manage IoT technology standards through a well-established, collaborative process. We empower companies with practical, usable assets and tools to ease and accelerate development, freeing them to focus on new areas of IoT innovation.
Our strong certification programs help Members avoid unnecessary development cycles, ensure compliance, and validate interoperability. Certification and our stamp of approval tell the world they can buy and use Alliance-certified products and platforms with confidence.
We are allies for a connected future. Our membership, spanning the globe and the IoT value chain, actively seeks to promote the benefits of global, open standards, the value of the IoT to customers and consumers, and to break down the barriers to broad access and adoption of IoT technologies and solutions.
Certified Devices are Devices that have gone through the Connectivity Standards Alliance (Alliance) Matter Certification Process.
During the commissioning process, a device cryptographically proves (attests) to the commissioner that:
In order to accomplish those goals, the device carries:
During the development phase, the manufacturer is able test their Devices without the full Attestation process. Testers should be explicitly informed that the Device is under testing, and it hasn’t yet been certified and launched. Once a manufacturer enters a production phase, the ecosystem of the provisioner should enforce all Attestation requirements.
Attestation uses a Public Key Infrastructure (PKI) that leverages Root Certificate Authorities and Intermediate Certificates, in a similar way to the widely adopted server authentication certificates used for SSL/TLS. This process is called the Device Attestation Certificate Chain.
The DAC is a X.509 v3 certificate. The first version of X.509 was published in 1988 by ITU-T. The X.509 v3 with Public Key Infrastructure Certificate and Certificate Revocation List (CRL) used by Matter is specified by RFC5280. It contains:
The DAC is unique per device and associated with the unique attestation key pair within the product. It is issued by a CA associated with the Device manufacturer.
The DAC’s signature is validated against the Product Attestation Intermediate Certificate (PAI), which is also issued by a PAA. However, a vendor might choose to create one PAI per product (PID-specific), group of products, or for all its products.
At the root of the chain of trust, the Product Attestation Authority (PAA) Certificate Authority (CA) public key validates signatures from the PAI. Note that the Matter trust store is federated and the set of PAA certificates trusted by commissioners is maintained in a central trusted database (the Distributed Compliance Ledger). Entry of a PAA within the trusted set requires meeting a certificate policy managed by the Alliance.
The PAI is also a X.509 v3 certificate that includes:
Lastly, the PAA is the root certificate in the chain and it is self-signed. It includes:
The attestation process has several documents and messages. The following items are a brief overview of their function and composition. The image below aids in the understanding of their hierarchy.
The CD allows the Matter product to prove its compliance with the Matter protocol. When a product has been certified by the CSA, the product maker can request a CD from the Alliance which can then be included in the product firmware. The CD includes among other information:
The Firmware Information contains the CD Version Number and one or more digests of components in the firmware, such as the OS, filesystem, bootloader. The digests may be either a hash of the software components or a hash of the signed manifests of the software components.
The vendor might as well choose to include in Firmware Information only the “hash-of-hashes” of its components, instead of an array of individual hashes.
Firmware Information is an optional element in the Attestation Process and applicable when a vendor has a secure boot environment which handles the Attestation key pair.
Message sent from the Commissionee to the Commissioner. The Attestation Information combines a TLV containing the Attestation Elements and a Attestation Signature. -Attestation Elements
Out-of-band challenge derived during Passcode Authenticated Session Establishment (PASE)/ Certificate Authenticated Session Establishment (CASE) session establishment and used to further secure the procedure and avoid replayed signatures. Comes from either CASE session, PASE session or a resumed CASE session.
Message containing the Attestation Elements and Attestation Challenge.
Signature of the Attestation TBS, signed using the Device Attestation Private Key.
The Commissioner is responsible for validating attestation information from the Commissionee. It executes the following steps:
This content was originally published on the Google Developer Site
Commissioning in Matter refers to the process of assigning Fabric credentials to a new device or app. The Commissioner is the device or app that does the Commissioning process. The Commissionee is the new device or app that needs to be provisioned into the Fabric.
At a high-level, the commissioning flow can be broken down into multiple stages:
Prior to start of the Commissioning flow, the Commissionee must start advertising itself. The Commissionee may advertise itself using any of the three Commissionable Discovery methods. The Commissionee must also provide the onboarding payload.
Once the Commissioner has seen the advertisement and matches up the Discriminator, the Commissioner uses the passcode from the onboarding payload to do Passcode Authenticated Session Establishment (PASE) to connect to the device. This is the method to securely establish keys that both devices will be able to use to establish communication. At this step, the Commissioner also arms a fail-safe. A fail-safe provides a way to roll back the device to its original state if commissioning doesn’t complete successfully.
The Commissioner reads all the descriptors from the Commissionee. The DescriptorCluster
is on endpoint 0 of the device and describes all the other endpoints. Commissioner also reads the Basic Information Cluster which includes information like the Vendor ID, Product ID, Product Name and the Serial Number. At this step, the Commissioner also reads the device type of the Commissionee which helps drive the UX on the Commissioner side.
The Commissioner configures regulatory information on the Commissionee using the SetRegulatoryConfig
command. Regulatory information includes information like configuring the location (indoor/outdoor/both) of the device or setting up the country code.
The goal of the Commissionee attestation procedure is to determine whether a device has been certified and is a genuine Matter device. Commissioner extracts the Device Attestation Certificate (DAC) and the Product Attestation Intermediate (PAI) certificate from the Commissionee. These certificates contain the Vendor ID, Product ID and Attestation Public Key. Once the certificates are received, the Commissioner does a challenge request that should be signed by the Attestation Private Key and uses that to establish the authenticity of the Commissionee.
The Commissioner sends a Certificate Signing Request (CSR) to the Commissionee. The Commissionee creates a unique operational key pair that will be used in a Certificate Authenticated Session Establishment (CASE) later. The Commissionee returns the resulting CSR information back to the Commissioner.
The Commissioner uses the CSR information received from the Commissionee and passes it to the Administrative Domain Manager (ADM) to generate a trusted Node Operational Certificate (NOC). The Commissioner installs the Root Certificate on the Commissionee using the AddTrustedRootCertReq
command and then installs the Node Operational Certificate using the AddNOC
command.
The Commissioner configures the operational network on the Commissionee. This step is needed for Thread or Wi-Fi devices. This step is not needed for Ethernet Devices where the device is already connected to the network. It uses ScanNetworks
, AddOrUpdateWifiNetwork
and ConnectNetwork
commands.
Once the newly commissioned node is connected to the network, the Commissioner uses Operational Discovery to find the node on the operational network. Operational discovery is the process by which commissioned nodes are found on the operational network using DNS-SD. If the Commissionee is a Wi-Fi device, it will use mDNS to discover the device.
Operational discovery helps the Commissioner and other Nodes in the network know which IP address and port the Commissionee is using.
Once the newly commissioned node has been discovered, a CASE session is established between the Commissioner and the device. This session is initiated by the Commissioner and is responded to by the device. In this step, operational certificates are exchanged and a shared trust is established by validating they’re in the same logical fabric.
The Commissioner uses CASE to send the CommissioningComplete
command to the newly commissioned device. This is the last step in the commissioning process. CommissioningComplete
also automatically disarms the fail-safe timer. Once commissioning is successfully completed, the device operates like any other Node on the operational network.
This content was originally published on the Google Developer Site
In principle, any IPv6-bearing network is suitable for Matter deployment, subject to supporting a few core IPv6 standards. In the current version of the specification, we focus on three link layer technologies: Ethernet, Wi-Fi and Thread. We restrict the specification to the above so that the specification can suitably cover provisioning of these link layers, and so that the amount of testing in certification is suitably bounded.
Matter treats networks as shared resources: it makes no stipulation of exclusive network ownership or access. As a result, it is possible to overlay multiple Matter networks over the same set of constituent IP networks. -This protocol may operate in the absence of globally routable IPv6 infrastructure. This requirement enables operation in a network disconnected or firewalled from the global Internet. It also enables deployment in situations where the Internet Service Provider either does not support IPv6 on consumer premises or where the support proves otherwise limiting, for example, if the delegated prefix cannot accommodate all the networks and devices on premises. -This protocol supports local communications spanning one or more IPv6 subnets. Canonical networks supporting a fabric may include a Wi-Fi/Ethernet subnet, or one or more low power and lossy networks (LLN) subnets. In this version of the specification, Thread is the supported LLN standard. -Matter uses IPv6 for its operational communications, and leverages both IPv6 Unicast and Multicast addressing for accessing its Nodes and Groups, respectively.
This is the simplest transport for Matter, as there is no need to communicate any network credentials to the device; it is simply connected to the Ethernet network. -Commissioning of devices should use the on-network bitmask in the Discovery Capabilities of the Onboarding Payload and the device will be discovered via DNS-SD.
Matter devices may use the 802.11 (Wi-Fi) standard for connectivity, any of the approved versions of this spec are compatible with Matter and all the approved frequency bands may be used (subject to local regulatory limits). -In order for a Matter device that uses Wi-Fi to be certified the manufacturer must first obtain Wi-Fi certification for the device from the Wi-Fi Alliance. -This can often be obtained via the Wi-Fi chipset vendors existing certification. -For commissioning, Wi-Fi devices may use the BLE method of discovery and conveying of network credentials or the device may already be connected to the IP network via an existing proprietary method.
Thread is a low power 802.15.4 mesh-based radio protocol designed for IP transport. There are a number of additional considerations when using Thread for a Matter device which are explained on the dedicated Thread page of this site. -In order for a device that uses Thread to be Matter certified, the manufacturer must first obtain Thread certification for the device from the Thread Group. -When a device uses Thread, it must also use BLE for Discovery and Commissioning in order to provision the Thread network credentials to the device.
Bluetooth Low Energy (BLE) is used in Matter as part of the discovery and commissioning stage as a method for passing the credentials of the Wi-Fi or Thread network that the device will use for operational communication. BLE is required where a device uses Thread and optional for Wi-Fi. -BLE cannot be used as the sole transport technology for a Matter Device.
Devices in Matter have a well-defined data model (DM), which is a hierarchical modeling of a Device’s features. At the top level of this hierarchy there is a Device.
All Devices, including smartphones and home assistants, are composed of Nodes. A Node is a unique identifiable and addressable resource in a network that a user can perceive as functionally whole. Network communication in Matter originates and terminates at a Node.
Nodes are a collection of Endpoints. Each Endpoint encloses a feature set. For instance, an Endpoint might relate to a lighting functionality, while another relates to motion detection, and another deals with utilities such as Device OTA.
A Node role is a set of related behaviors. Each Node may have one or more roles. Node roles include:
Within an Endpoint a Node has one or more Clusters. These are another step in the Device hierarchy, as they group specific functionality such as a on/off cluster on a smart plug, or a level control cluster on a dimmable light Endpoint.
A Node may also have several Endpoints, each creating an instance of the same functionality. For example, a light fixture may expose independent control of individual lights or a power strip may expose control of individual sockets.
### Attributes -At the last level we’ll find Attributes, which are states held by the node, such as the current level attribute of a level control cluster. Attributes may be defined as different data types such as uint8, strings or arrays.
Besides Attributes, Clusters also have Commands, which are actions that may be performed. They are the equivalent in Matter’s data model of a remote procedure call. Commands are verb-like, such as lock door on a Door Lock cluster. Commands may generate responses and results; in Matter, such responses are also defined as Commands, going in the reverse direction.
### Events -Lastly, Clusters may also have Events, which can be thought of as a record of past state transitions. While Attributes represent the current states, events are a journal of the past, and include a monotonically increasing counter, a timestamp and a priority. They enable capturing state transitions, as well as data modeling that is not readily achieved with attributes.
The Endpoint 0 is reserved for the Utility Clusters. Utility Clusters are specific Clusters that enclose servicing functionality on an Endpoint, such as discovery, addressing, diagnostics and software update. On the other hand, the Application Clusters support primary actions such as on/off or temperature measurement.
Altogether, which Cluster combinations should be included as a device manufacturer plans a new Device?
The Matter specification requires that the device implement or extend one or more Device Types. A Device Type is a collection of mandatory and optional Clusters that define the top-level attributes of a physical Device, such as Dimmable Light, Door Lock, or Video Player.
The Device Types are not specified by the Matter specification main document, but by an accompanying document: the Device Library. Similarly, all Application Clusters are defined in the Application Cluster Library. These three documents can be found on the Connectivity Standards Alliance (Alliance) website.
Each Endpoint implementing a Device Type must implement the mandatory Clusters that define that Device Type. In addition to the mandatory Clusters, the Endpoint may implement additional Clusters, including one or more of the Device Type’s optional Clusters, or even Clusters that aren’t part of the Device Type.
Clusters might be either a Client Cluster or a Server Cluster. While a Server is stateful and holds Attributes, Events and Commands, a Client is stateless and its responsibility is to initiate Interactions with a remote Server Cluster, thus performing:
While the DM is hierarchical within a Node, the relationship between Nodes is not. Nodes in Matter do not have vertical controller/peripheral or leader/follower relationships. On the contrary, the relationship is horizontal: Any Cluster may be either Server or Client. Thus a Node may be both Server and Client with regards to different Clusters and functionalities.
For instance, we may have two table lamps: Node A and Node B. Both nodes implement an On/Off Light Device Type. This Device Type includes an On/Off Server Cluster that controls their respective physical light outputs.
But, as typical table lamps do, our physical devices will also include an On/Off Light Switch Device Type for their local on/off switches. This Device Type must implement an On/Off Client Cluster so it may control the Server Clusters.
In this sample, the On/Off Client Cluster on Node A is changing the attributes of the On/Off Server Cluster on Node A and Node B, while the Node B’s Client Cluster is only changing the Server Cluster on Node B itself.
In the next section we’ll detail how Client and Server Clusters interact: the Interaction Model.
As the name implies, the Descriptor Cluster Server provides introspection information. It describes the Endpoint enumerating its:
The Commissioner or Controlling device such as a phone or hub can use the information found on the Descriptor Cluster to model the Device (light, switch, pump, thermostat), and specific features implemented by that particular instance of the Device, showing the correct UI to the user.
The ServerList
Attribute lists the Cluster Servers in the Endpoint.
The ClientList
Attribute lists the Cluster Clients in the Endpoint.
The DeviceTypeList
Attribute is a list of Device Types supported by the Endpoint, along with its respective revisions. It must contain at least one Device Type.
The PartsList
contains the list of Endpoints used for implementing this Device Type.
The PartsList
of Endpoint 0 (Root Node) contains all the Endpoints of the device apart from itself (Endpoint 0).
The PartsList
of other Endpoints will usually be empty. For example, a Temperature Sensor mandates a Temperature Measurement Server Cluster and nothing else.
Other device types might be composed in a tree structure of more than one Device Type instance. For example, a Video Player Device type can be composed of TV, Video Player, Speaker and different Content App Device Types, each on a different Endpoint.
This content was originally published on the Google Developer Site
In order to be certified a Matter device must conform to one of the approved device types.
As of Matter 1.2 the following types are certifiable.
The On/Off Light is a lighting device that is capable of being switched on or off by means of a bound controller device such as an On/Off Light Switch or a Dimmer Switch. In addition, an on/off light is also capable of being switched by means of a bound occupancy sensor.
A Dimmable Light is a lighting device that is capable of being switched on or off and the intensity of its light adjusted by means of a bound controller device such as a Dimmer Switch or a Color Dim mer Switch. In addition, a Dimmable Light device is also capable of being switched by means of a bound occupancy sensor or other device(s).
A Color Temperature Light is a lighting device that is capable of being switched on or off, the inten sity of its light adjusted, and its color temperature adjusted by means of a bound controller device such as a Color Dimmer Switch.
An Extended Color Light is a lighting device that is capable of being switched on or off, the intensity of its light adjusted, and its color adjusted by means of a bound controller device such as a Color Dimmer Switch or Control Bridge. The device supports adjustment of color by means of hue/satura tion, enhanced hue, color looping, XY coordinates, and color temperature. In addition, the extended color light is also capable of being switched by means of a bound occupancy sensor.
An On/Off Plug-in Unit is a device that is capable of being switched on or off by means of a bound controller device such as an On/Off Light Switch or a Dimmer Switch. The On/Off Plug-in Unit is typ ically used to control a conventional non-communicating light by switching its mains connection. Other appliances can be controlled this way as well.
A Dimmable Plug-In Unit is a device that is capable of being switched on or off and have its level adjusted by means of a bound controller device such as a Dimmer Switch or a Color Dimmer Switch. The Dimmable Plug-in Unit is typically used to control a conventional non-communicating light through its mains connection using phase cutting.
A Pump device is a pump that may have variable speed. It may have optional built-in sensors and a regulation mechanism. It is typically used for pumping fluids like water.
An On/Off Light Switch is a controller device that, when bound to a lighting device such as an On/Off Light, is capable of being used to switch the device on or off.
A Dimmer Switch is a controller device that, when bound to a lighting device such as a Dimmable Light, is capable of being used to switch the device on or off and adjust the intensity of the light being emitted.
A Color Dimmer Switch is a controller device that, when bound to a lighting device such as an Extended Color Light, is capable of being used to adjust the color of the light being emitted.
A Control Bridge is a controller device that, when bound to a lighting device such as an Extended Color Light, is capable of being used to switch the device on or off, adjust the intensity of the light being emitted and adjust the color of the light being emitted. In addition, a Control Bridge device is capable of being used for setting scenes.
A Pump Controller device is capable of configuring and controlling a Pump device.
A generic switch can be either momentary or latching in state, with multiple positions.
The Generic Switch device type and the On/Off Light Switch device type both convey information about interactions with a switch to another device.
This allows a more comprehensive controller to combine the information from the switch with other inputs or information sources (e.g. time of day, user presence) to determine which control commands (e.g. on/off, scene recall, attribute change) are sent to other devices in the network.
The Contact Sensor is a device that reports a boolean state, typically open/closed.
A Light Sensor device is a measurement and sensing device that is capable of measuring and reporting the intensity of light (illuminance) to which the sensor is being subjected.
An Occupancy Sensor is a measurement and sensing device that is capable of measuring and reporting the occupancy state in a designated area.
A Temperature Sensor device reports measurements of temperature.
A Pressure Sensor device measures and reports the pressure of a fluid.
A Flow Sensor device measures and reports the flow rate of a fluid.
A humidity sensor (in most cases a Relative humidity sensor) reports humidity measurements.
An On/Off Sensor is a measurement and sensing device that, when bound to a lighting device such as a Dimmable Light, is capable of being used to switch the device on or off.
A Smoke CO Alarm device is capable of sensing smoke, carbon monoxide or both. It is capable of issuing a visual and audible alert to indicate elevated concentration of smoke or carbon monoxide. -Smoke CO Alarms are capable of monitoring themselves and issuing visual and audible alerts for hardware faults, critical low battery conditions, and end of service. Optionally, some of the audible alerts can be temporarily silenced. Smoke CO Alarms are capable of performing a self-test which performs a diagnostic of the primary sensor and issuing a cycle of the audible and visual life safety alarm indications. -Some smoke alarms MAY be capable of adjusting sensitivity. Smoke CO Alarm MAY have the ability to detect and report humidity levels, temperature levels, and contamination levels.
A Door Lock is a device used to secure a door. It is possible to actuate a door lock either by means of a manual or a remote method.
A Door Lock Controller is a device capable of controlling a door lock.
A window covering is a device that actuates a cover for a window, typically a blind. The covering can be vertical or horizontal and optionally the tilt of the sections in the covering can be changed.
A Window Covering Controller is a device that controls a window covering device.
A Heating/Cooling Unit is a device capable of heating or cooling a space in a house. It is not manda tory to provide both functionalities (for example, the device may just heat but not cool). It may be an indoor air handler.
A Thermostat device is capable of having either built-in or separate sensors for temperature, humidity or occupancy. It allows the desired temperature to be set either remotely or locally. The thermostat is capable of sending heating and/or cooling requirement notifications to a heating/cool ing unit (for example, an indoor air handler) or is capable of including a mechanism to control a heating or cooling unit directly.
An Air Purifier is a standalone device that is designed to clean the air in a room. -It is a device that has a fan to control the air speed while it is operating. Optionally, it can report on the condition of its filters.
This defines conformance for the Air Quality Sensor device type. -An air quality sensor is a device designed to monitor and measure various parameters related to the quality of ambient air in indoor or outdoor environments.
A Basic Video Player represents a device that is able to play media to a physical output or to a display screen which is part of the device. -A Basic Video Player has playback controls (play, pause, etc.) and keypad remote controls (up, down, number input), but is not able to launch content and is not a content app platform -For example, a Basic Video Player can be a traditional TV device a physical media playback device such as a DVD Player, or a device that provides input to another device like a TV or computer monitor.
A Casting Video Player represents a device that is able to play media to a physical output or to a display screen which is part of the device. -A Casting Video Player has basic controls for playback (play, pause, etc.) and keypad input (up, down, number input), and is able to launch content. -For example, a Casting Video Player can be a smart TV device, a TV Set Top Box, or a content streaming device that provides input to another device like a TV or computer monitor.
This feature controls the speaker volume of the device. -To control unmute/mute, the On/Off cluster SHALL be used. A value of TRUE for the OnOff attribute SHALL represent the volume on (not muted) state, while a value of FALSE SHALL represent the volume off (muted) state. For volume level control, the Level cluster SHALL be used. -A dedicated endpoint is needed because the On/Off cluster can also be used for other purposes, such as for power control.
A Content App is usually an application built by a Content Provider. A Casting Video Player with a Content App Platform is able to launch Content Apps and represent these apps as separate end points.
A Casting Video Client is a client that can launch content on a Casting Video Player, for example, a Smart Speaker or a Content Provider phone app.
A Video Remote Control is a client that can control a Video Player, for example, a traditional universal remote control.
A robotic vacuum cleaner is a device capable of autononomous cleaning, the cleaning mode may be selected from a number of predefined options and the device should report back any error states.
A refrigerator represents a device that contains one or more cabinets that are capable of chilling or freezing food. Examples of consumer products that MAY make use of this device type include refrigerators, freezers, and wine coolers.
A Temperature Controlled Cabinet only exists composed as part of another device type. It represents a single cabinet chilling or freezing food in a refrigerator, freezer, wine chiller or other similar device.
A Room Air Conditioner is a device with the primary function of controlling the air temperature in a single room.
A Laundry Washer represents a device that is capable of laundering consumer items. Any laundry washer product may utilize this device type.
A dishwasher is a device that is generally installed in residential homes and is capable of washing dishes, cutlery, and other items associate with food preparation and consumption. The device can be permanently installed or portable and can have variety of filling and draining methods.
Commissionable discovery happens before Commissioning and refers to the process of discovering and identifying a commissionable Node. There are two methods through which a commissionable Node may advertise itself:
In either method, the commissionable node advertises information as shown in the table below.
Field | Length | Required |
---|---|---|
Discriminator | 12 bit | Yes |
Vendor ID | 16 bit | No |
Product ID | 16 bit | No |
Extended data | variable | No |
As per the Matter specification, Vendor ID and Product ID are not required but can be included. The Discriminator is mandatory and is crucial during the commissioning process to provision the correct device, in case multiple identical devices are connected at the same time. Extended data may be used to encode custom vendor-specific information.
Many devices will advertise for a short period of time (~3-15 mins) after power-up. Other devices must not start advertising either because their primary control does not originate from the fabric or because automatic unprovisioned advertising of devices such as locks isn’t safe. This table summarizes the behavior.
Primary Device Function | Automatic Announcement |
---|---|
Locks and barriers access devices | No |
Most control originates from fabric. For example, switch or light bulb. | Yes |
Most control does not originate from fabric. For example, dishwasher or refrigerator. | No |
In this mode of advertisement, the Commissioner will see BLE advertisements. The Commissionee must implement a Generic access profile (GAP) peripheral interface and advertise its uncommissioned state periodically. For the first 30 seconds after a device is turned on the advertisement frequency must be high, at 20 to 60 milliseconds intervals.
After 30 seconds, the device must advertise at a low frequency, at 150 to 1500 millisecond intervals. When commissioned to its first fabric, the device must stop its BLE advertisement.
The Commissioner does not need to issue scan requests. It should do a passive scan on the three BLE advertising channels: 37 (2402 MHz), 38 (2426 MHz) and 39 (2480 MHz). These channels are picked from regions in the spectrum with minimal overlap with Wi-Fi Channels, minimizing interference cross-radio interference.
BLE is not used for operational discovery.
In this case the Commissionee will be discovered by its domain name service - service discovery (DNS-SD) advertisements that contain information on services rendered by the nodes. See RFC 6762 for more information about DNS-SD. This is a common method of device discovery when:
The Commissionee is connected to Ethernet and thus has physical access to an unencrypted network medium. -The Commissionee has joined the Wi-Fi or Thread network by any out-of-band means. -The Commissionee was already commissioned to another fabric and has joined the Wi-Fi/Thread network. In this case the Commissionee can’t use BLE advertisements. Thus all secondary fabrics are provisioned through this method. -Thread devices don’t directly use DNS-SD, but instead use a proxied method provided by the Thread Border Router. This method is defined by the DNS-SD Service Registration Protocol and its Advertising Proxy. Thread devices register themselves in the SRP service typically provided by a Thread Border Router. This service handles mDNS traffic on behalf of each registered Thread node without burdening the Thread network with additional traffic generated by these protocols.
The DNS-SD instance name for device discovery is _matterc._udp and the host names are built by either a 48-bit MAC address or a 64-bit MAC Extended Address, expressed as a hex string such as A5F15790B0D15F32.local.. Generally this record is only advertised when the Commissionee may be commissioned. However, it may also continue advertising when not in commissioning mode. That behavior is named extended discovery.
After discovery, IPv6 addresses are returned in the AAAA records and key/value pairs are returned in the DNS‑SD TXT record. The key/value pair contains information such as the Discriminator, Vendor ID, and Product ID. The node also advertises commissioning subtypes, which enables filtering of results to find only Commissionees that match a particular attribute.
Operational discovery is the process of discovering and identifying a commissioned node. Operational discovery only happens through the IP-based DNS-SD method. The node instance name will be composed of the 64 bit compressed Fabric ID and 64 bit Node ID. These IDs in hexadecimal are then concatenated with a hyphen, such as in 2906C908D115D362-8FC7772401CD0696.local.. Operational discovery shares the same target host name as DNS-SD Device Discovery.
The DNS-SD service type is _matter._tcp.
Although _tcp
naming is used, the device might use other transports such as UDP.
Commissioner discovery is the process used by Commissionee’s to discover Commissioners on the network. Commissioner discovery only happens through the IP-based DNS-SD method.
With Commissioner Discovery, a Commissionee, upon user interaction, can discover Commissioners on the network and obtain a list of information for each which may include Vendor ID, Product ID and friendly name. A Commissionee with a user interface, such as a Television, Thermostat or Video Player device, can then display the list of discovered commissioners to the user for selection. Once selected, the Commissionee can use the User Directed Commissioning protocol with the Commissioner to indicate that the user has selected it for commissioning of the Commissionee. The Commissioner Discovery service records thus enable a form of “door bell” protocol to allow a Commissionee to request Commissioning.
The DNS-SD instance name for commissioner discovery is _matterd._udp and the host names are built by either a 48-bit MAC address or a 64-bit MAC Extended Address, expressed as a hex string such as A5F15790B0D15F32.local. similar to commissionable node discovery.
After discovery, IPv6 addresses are returned in the AAAA records and key/value pairs are returned in the DNS‑SD TXT record. The key/value pair contains information such as the Discriminator, Vendor ID, and Product ID. The node also advertises commissioning subtypes, which enables filtering of results to find only Commissioners that match a particular attribute.
This content was originally published on the Google Developer Site
The Matter spec uses sophisticated methods for encrypting and decrypting information, as well as safe mechanisms for assuring a Node’s identity and sharing cryptographic credentials.
Whenever a set of Devices in a network shares the same security domain, and thus allows secure communication between Nodes, this set is called a Fabric. Devices within a fabric share the same Certificate Authority (CA) top-level certificate (Root of Trust) and a 64-bit identifier named Fabric ID, unique within the context of that CA.
Thus the commissioning process is the assignment of the Fabric credentials to a new Node so it may communicate with other Nodes in the same Fabric.
The Root of Trust is set on a Node under commissioning by the Commissioner, typically a device with some type of GUI, such as a smartphone, hub or computer, after receiving it from an Administrative Domain Manager (ADM), which will often be an ecosystem that acts as a Trusted Root Certificate Authority (CA).
The Commissioner has access to the CA. Thus it requests the Node Operational Credentials from the CA on behalf of the node being commissioned or Commissionee. The credentials are made of two parts:
Node Operational Identifier (or Operational Node ID) is a 64-bit number that uniquely identifies every Node in the Fabric.
Node Operational Certificate (NOC) is the set of credentials that Nodes use to communicate and identify themselves within a Fabric. They are generated by the Node Operational Certificate Signing Request (NOCSR) process.
NOCSR is a procedure that runs on Node being commissioned. It binds several cryptographical elements, then sends them to the Commissioner, who requests the CA ecosystem for its corresponding NOC. This diagram depicts this dependency tree and the order by which some operations occur.
While understanding each cryptographic element is important for SDK development, it is outside of this document’s scope to fully analyze their role and implications. What’s important to note is that:
The Attestation procedure is a process used by the Commissioner to certify that:
Nodes may also be commissioned on more than one Fabric. This property is often referred to as multi-admin. For instance, we may have a Device commissioned to both the manufacturer’s Fabric and a cloud ecosystem’s Fabric, with each Fabric handling a different set of encrypted communications and operating independently.
As several Fabrics may coexist, a Device might have several sets of Node operational credentials. However, the Node’s Data Model is shared: the Cluster Attributes, Events, and Actions are common between Fabrics. Thus, although Thread and/or Wi-Fi credentials are set during the commissioning process, they are part of the Networking Operational Cluster, being shared between all the Fabrics and part of the node’s DM, not the Fabric credentials.
This content was originally published on the Google Developer Site
This section goes into detail about how Matter works. Click through the links in the sidebar to learn more about Matter roles, device types, connectivity transports, and more. You can download the Matter specification directly from the Connectivity Standards Alliance’s website for the most detail.
The Data Model (DM) of a Node isn’t relevant if we can’t perform operations on them. The Interaction Model (IM), defines a Node’s DM relationship with the DM of other Nodes: a common language for communication between DMs.
Nodes interact with each other by:
Whenever a Node establishes an encrypted communication sequence with another Node, they constitute an Interaction relationship. Interactions may be composed of one or more Transactions, and Transactions are composed of one or more of Actions which can be understood as IM-level messages between Nodes.
Several Actions are supported on Transactions, such as a Read Request Action that requests an Attribute or Event from another Node, or its response, the Report Data Action, which carries the information back from the server to the client.
The Node that initiates a Transaction is the Initiator, while the Node that responds is the Target. Typically the Initiator is a Client Cluster and the Target is a Server Cluster. However, there are exceptions to this pattern, such as in the Subscription Interactions analyzed further down in this section.
Nodes and Endpoints in Matter may belong to a Group. A Group is a mechanism for addressing and sending messages to several Nodes in the same Action simultaneously. All Nodes in a Group share the same Group ID, a 16-bit integer.
To accomplish group-level communication (Groupcast), Matter leverages IPv6 Multicast messages, and all Group members have the same Multicast address.
Whenever we want to interact with an Attribute, Event, or Command, we must specify the Path for this interaction: the location of an Attribute, Event or Command in the Data Model hierarchy of a Node. The caveat is that paths may also use Groups or Wildcard Operators to address several Nodes or Clusters simultaneously, aggregating these Interactions and thus decreasing the number of actions.
This mechanism is important to enhance the responsiveness of communications. For example, when a user wants to shut down all lights, a voice assistant can establish a single interaction with several lights within a Group instead of a sequence of individual Interactions. If the Initiator creates individual Interactions with each light, it can generate human-perceptible latency in Device responsiveness. This effect causes the multiple Devices to react to a command with visible delays between them. This is often referred to as “popcorn effect”.
A Path in Matter can be assembled using one of the options below:
<path> = <node> <endpoint> <cluster> <attribute | event | command>
-<path> = <group ID> <cluster> <attribute | event | command>
-
And within these Path building blocks, endpoint
and cluster
may also include Wildcards Operators for selecting more than one Node instance.
### Timed and Untimed
There are two ways of performing a Write or Invoke Transaction: Timed and Untimed. Timed Transactions establish a maximum timeout for the Write/Invoke Action to be sent. The purpose of this timeout is to prevent an Intercept Attack on the Transaction. It is especially valid for Devices that gate access to assets, such as garage openers and locks.
To understand Timed Transactions it’s useful to understand how Intercept Attacks can happen and why Timed Transactions are important.
The Intercept Attack -An Intercept Attack has the following pattern:
Alice sends Bob an initial message, such as a Write Request Action. -Eve, a man-in-the-middle, intercepts the message and prevents Bob from receiving it, for example through some type of radio jamming. -Alice, not receiving a response from Bob, sends a second message. -Eve intercepts again and prevents Bob from receiving it. -Eve sends the first intercepted message to Bob, as if it were coming from Alice. -Bob sends the response to Alice (and Eve). -Eve holds the second intercepted message for a later replay. Since Bob never received the original second intercepted message from Alice, it will accept it. This message represent a security breach when the message encodes a command such as “open lock”. -To prevent these types of attacks, Timed Actions set a maximum Transaction timeout at the start of the Transaction. Even if Eve manages to execute the first six steps of the attack vector, it will not be able to replay the message on step 7 due to an expired timeout on the Transaction.
Timed Transactions increase the complexity and number of Actions. Thus they are not recommended for every Transaction, but only the critical operations on Devices that have control over physical or virtual security and privacy assets.
The sections Read Transactions, Write Transactions, and Invoke Transactions provide a high-level overview of the Interaction Model Actions performed by the SDK.
The developer creating a product that uses the Matter SDK typically does not perform calls to execute Actions directly; the Actions are abstracted by SDK functions that will encapsulate them into an Interaction. However, understanding IM Actions is important to provide the engineer a good proficiency on the capabilities of Matter, as well as fine control over the SDK implementation.
One of the first use cases when interacting with Nodes in Matter is the reading of an Attribute from another Node, such as a temperature value from a sensor. In such Interactions, the first Action that must be performed is the Read Request Action.
Direction: Initiator -> Target
In this Action the Initiator queries a Target providing:
After the Read Request Action is received by the Target it will assemble a Report Data Action with the requested information.
Direction: Target -> Initiator
In this Action the Target responds with:
Direction: either Target -> Initiator or Initiator -> Target
Once the Initiator receives the requested data, by default it must generate a Status Response Action. This action is sent from the Initiator, acknowledging the receipt of the reported data. If the flag Suppress Status Response is set, the Initiator must not send the Status Response Action.
Once the Status Response Action is sent by the Initiator, or a Report Data Action is received by the Initiator with the Suppress Response flag enabled, the read/report query is finished.
The Status Response Action simply contains a status field that will either acknowledge operation success or present a failure code.
The Read Request Action and Report Data Action are Unicast-only. Moreover, the Paths of these requests may not target a Group of Nodes.
The Status Response Action is Unicast-only and can’t be generated as a response to a groupcast.
Direction: Initiator -> Target
In addition to a singular Read Request Action, an Initiator may also subscribe to periodic updates of an Attribute or Event. Thus the same Report Data Action can be generated as a result of periodic data updates that follow a Subscription Transaction.
A Subscription Interaction creates a relationship between two Nodes, in which the Target periodically generates Report Data Actions to the Initiator. The Initiator is the Subscriber and the Target is the Publisher.
A Subscribe Request Action contains:
After the Subscribe Request, the Target responds to the Initiator with a Report Data Action containing the first batch of reported data: the Primed Published Data.
The Initiator then acknowledges the Report Data Action with a Status Response Action sent to the Target. Once the Target receives a Status Response Action reporting no errors, it sends a Subscribe Response Action.
The Target will subsequently send Report Data Action periodically at the negotiated interval and the Initiator will respond to those Actions until the subscription is lost or cancelled.
Direction: Target -> Initiator
This is the last Action on the Subscription Transaction and concludes the process. It includes:
In the last section we discussed the reading interactions of Attributes and Events. In this section we’ll discuss the writing of Attributes, which is the change of an Attribute value on a Cluster such as Level.
Direction: Initiator -> Target
Similar to the Read Request Action, in this Action the Initiator provides the Target with:
Direction: Target -> Initiator
After the Target receives the Write Request Action it will finalize the transaction with a Write Response Action that carries:
The Write Request Action may be a groupcast, but in this case the Suppress Response flag must be set. The rationale is that otherwise the network might be flooded by simultaneous responses from every member of a group.
To enable this behavior, the Path used in the Write Requests list may contain Groups and alternatively they may contain wildcards, but only on the Endpoint field.
Timed write transactions add a few steps to untimed write transactions.
Direction: Initiator -> Target
A Initiator starts the Transaction sending this Action that contains:
Once the Timed Request Action is received, the Target must acknowledge the Timed Request Action with a Status Response Action. Once the Initiator receives a Status Response Action reporting no errors, it will send a Write Request Action.
Same as the previously described Write Request Action.
Same as the previously described Write Response Action.
The Timed Request Action, the Write Request Action and the Write Response Action are unicast-only.
Invoke Transactions are used for invoking one or more Cluster Commands on a Target Node. It is similar to remote procedures calls made to a command defined in the Cluster.
In a similar way of Write Transactions, Invoke Transactions support Timed and Untimed Transactions. Please refer to the Timed and Untimed Actions section for further information on Timed Transactions.
Direction: Initiator -> Target
Similar to the Read Request Action and Write Request Action, in this Action the Initiator provides the Target with:
Direction: Target -> Initiator
After the Target receives the Invoke Request Action it will finalize the transaction with an Invoke Response Action that carries:
The Invoke Request Action may be a groupcast, but in this case the Suppress Response flag must be set. The rationale is that otherwise the network might be flooded by simultaneous responses from every member of a group.
To enable this behavior the Path used in the Invoke Requests list may contain Groups and alternatively they may contain wildcards, but only on the Endpoint field. Moreover, if the Action is groupcast, this transaction terminates with no response.
Similar to Timed Write Transactions, Timed Invoke Transactions also start with the Timed Request Action.
Direction: Initiator -> Target
A Initiator starts the Transaction sending this Action that contains:
Once the Timed Request Action is received, the Target must acknowledge the Timed Request Action with a Status Response Action. Once the Initiator receives a Status Response Action reporting no errors, it will send a Invoke Request Action.
Same as the previously described Invoke Request Action.
Same as the previously described Invoke Response Action
All invoke commands may be called on a Timed Interaction. The Timed Request Action, the Invoke Request Action and the Invoke Response Action are Unicast-only and thus can’t be used as groupcast on Timed Invoke Transactions.
The Invoke Request Action supports the usage of paths with Groups, as well as wildcards, but the Invoke Response Action does not support wildcard usage.
This content was originally published on the Google Developer Site
An important note is that while these definitions explain the distinct roles as defined in the Matter specification, in many cases, the products in users’ homes have the ability to take on different roles or serve in multiple roles at once.
A smart home hardware product that supports Matter, so that it can be connected to and controlled by a Matter Controller. Examples: light bulbs, switches, sensors, thermostats, blinds, door locks, bridges, and media devices.
Matter Devices are connected together on a virtual network within the home called a Matter Fabric, a private virtual network over which Matter Devices, Admins, and Controllers communicate with each other. Matter Fabrics can span across the Wi-Fi, Thread, and Ethernet physical networks within the home. Matter Devices can be connected to one or more Fabrics at a time, each managed by a Matter Administrator. Sometimes Matter Fabrics are referred to as “services” by smart home apps and platforms.
A device or application that is used as a tool to set up a Matter Device, in other words bring it into a Matter Fabric. Commissioners first verify the device’s authenticity and then assign network credentials as needed. A platform, device vendor, or other Matter-enabled app, mobile OS, smart speaker, or display may all provide a Matter Commissioner. A Commissioner can be an independent tool or part of a device or system that includes other roles such as Administrator or Controller.
A device or application that creates, maintains, and manages security and privileges for all devices on the Fabric it administers. Administrators can be a physical device like a hub or software like an app. Matter’s Multi-Admin feature which allows Devices to connect to multiple smart home platforms simultaneously, is a reference to connecting Devices to multiple Matter Administrators, and thus to multiple Fabrics.
As the name suggests, a Matter Controller is an entity that can control Matter devices the user has connected to it. Matter Controller functionality can be built into many types of hardware devices like phones, always-powered smart home hubs that provide local and remote control, smart switches and buttons, or even mobile apps. There can be multiple Matter Controllers on a Fabric to provide redundancy and/or convenient controls for users.
It’s important to note that in most cases, a Matter Controller is exclusive to the company that provides it. For instance, a smart speaker with a Matter Controller from Smart Home Platform A can be used to control Matter devices through the Platform A app, voice control, or other interfaces. But if you want to use Platform B to control Matter devices, you’ll need to have one of Platform B’s Controllers. An exception to this is devices such as switches, buttons, sensors, etc that can be commissioned as third-party Controllers onto a Fabric.
With Matter’s Multi-Admin features, you can connect Matter devices to multiple platforms if you have a Matter Controller for each platform in your home.
Matter Controller is the technical term for this role, though note that many smart home platforms colloquially refer to their devices that contain Matter Controllers as “hubs” (see below).
A Matter Bridge translates from one protocol to another, allowing non-Matter smart home devices (such as those using Zigbee or Z-Wave) to connect to a Matter Fabric via the Bridge. This allows consumers to use their non-Matter smart home devices along with their new Matter devices to continue growing their unified smart home.
A Matter Bridge is a different role than a Controller. A bridge serves as an intermediary for Matter and non-Matter devices. However, Bridges may be built into a number of devices like smart home “hubs” that also serve as Matter Controllers. For a deeper dive read Why Bridging Matters.
This content was first published on the Alliance website as a blog
Matter was created with security and privacy as key design tenets and provides -a baseline for building secure IoT devices. The following are key principles of Matter security.
Data privacy aims to protect consumers whose personal information is consumed and transacted -Matter embeds data privacy principles for all interactions between devices and software agents -that handle personal information. For complete protection, additional support from the environment -and infrastructure that Matter devices operate in is needed
Matter uses the highest possible level of civilian cryptographic standards for network communications to ensure that unauthorized entities cannot easily access or tamper with data communicated between Matter devices
Required for Matter devices with cryptographic certificates so data is shared only between known Matter entities
Enables anyone to inspect the template for Matter interactions between legitimate Matter nodes
Data shared within Matter interactions is minimized, thereby reducing the potential for inadvertent leakage -of information
Data shared between Matter nodes is strictly for a defined purpose, namely, for the specific operations -of devices as required by the Matter protocol
### Privacy preserving mechanisms -Encryption to ensure that messages or identities of communicating parties are not in cleartext on the network
Some Matter Nodes are wired and have energy budgets that allow them to keep their radios continuously on. Other types of Nodes such as sensors have requirements to run for years on a battery, operating their radios on low-power networks such as Thread. The proxy architecture, along with Thread Sleepy End Devices, allows full-powered Nodes to provide both network-level and application-level functionality that insulates their child Nodes from energy-intensive transactions.
A fundamental aspect of Matter is that it works both on high-throughput network mediums such as Wi-Fi and Ethernet, but also on low-latency, low-bandwidth, such as Thread. If all Multicast packets from Wi-Fi were bridged into Thread, we’d overburden the network, and potentially flood it. Thread’s goal is to enable IPv6 in low-power, low-latency mesh networking, not high-bandwidth data transfer. While Thread’s ICMPv6 pings in a local network are typically under few tens of milliseconds RTT, its total bandwidth is limited to 250 kbps at the IEEE 802.15.4 PHY. With packet retransmissions and overhead, the typical max bandwidth is around 125 kbps. In other words, orders of magnitude less than Wi-Fi.
Frames on the IEEE 802.15.4 PHY are 127 bytes, but the largest (and typical) maximum transmission unit (MTU) of IPv6 packets in Thread is 1280 bytes. Thus IPv6 packets often need to be split into several PHY frames. This process is defined by RFC 4944.
To learn more, refer to IPv6 Addressing in the Thread Primer on openthread.io.
So how can Nodes coexist on both transport mediums while in the same fabric? Although both networks share application-level Matter credentials, they don’t share the same link technology. In this scenario, the network needs a Thread Border Router (BR) to enable connectivity. BRs are Stub IPv6 Routers.
Stub Routers enable connectivity between stub networks and regular networks. A Stub Network is a “last-mile” network that provides outer connectivity to its members, but doesn’t serve as a transit network path between other networks. Typically, Matter Stub Networks are Thread-based. Refer to RFC draft for further information on stub networks.
BRs therefore have the responsibility of being the link between the Stub Network and the Adjacent Infrastructure Network, which is the local Wi-Fi or Ethernet network. They forward only the packets that are relevant to the Thread network.
This process is accomplished by assigning different IPv6 prefixes to Thread and Adjacent Infrastructure Networks. Thus the BR only forwards unicasts to or from the Thread IPv6 prefix.
Border Routers are also responsible for:
To learn more, refer to the Border Router guide on openthread.io.
Group messages are also important as they allow simultaneous control of several Matter Nodes through Multicast. In order to route this traffic into the Thread network, both Matter and Thread implement the Unicast Prefix-based IPv6 Multicast Addressing Scheme defined by RFC 3306.
This method allows the selection of the destination Nodes of a Multicast packet based on their shared IPv6 Unicast prefix.
For example, a Matter Multicast address might look like this:
-FF35:0040:FD<Fabric ID>00:<Group ID>
This Table details how this address is constructed:
Bits | Description |
---|---|
12 bits | 0xFF3 |
4 bits | 0x05 Scope: site-local |
8 bits | 0x00 reserved |
8 bits | 0x40 Indicates a 64-bit long prefix |
8 bits | 0xFD Designates a ULA prefix |
56 bits | Fabric ID |
8 bits | 0x00 |
16 bits | Group ID |
More information can be found in the Multicast section of the Thread Primer and on the RFC itself.
When IPv6 Multicast Addresses are formed, they also include the upper 56-bits of the Fabric ID. The important implication is that the scope of Multicast is within a Fabric, while Unicast addresses are shared between Fabrics. Nodes with many fabrics can potentially have several Multicast addresses defining overlapping Node Groups scoped at each fabric.
Matter has the goal of being an interoperable standard that fosters technology adoption and innovation, gradually replacing proprietary protocols for smart home ecosystems.
Matter is implemented by an open source SDK that contains not only the implementation of the specification but also a rich set of examples and interoperable code. The core Matter protocol fits on the top three layers in the context of OSI, meaning it can run over any type of IPv6 transport and network. While control and other operational communication are performed over IPv6, Bluetooth Low Energy (BLE) may be employed to commission new devices.
Matter is flexible and interoperable. It builds upon years of challenges and successes of low power 802.15.4 networks as well as Wi-Fi smart home devices. Like Thread, Matter builds atop IPv6. It includes strong cryptography, a well-defined modeling of Device Types and their data, and the support for multiple ecosystem administrators.
Matter also supports bridging of other Smart Home technologies such as Zigbee, Bluetooth Mesh and Z-Wave. This means that devices based on these protocols may be operated as if they were Matter devices through a Bridge, which is a member device of both a Matter network and the other, bridged, IoT technologies.
There is a dual advantage to Bridges. The devices that use other protocols gain access to technologies and ecosystems that target native Matter devices. Meanwhile Matter will leverage mature technologies with large installed user bases to create a true web of connected things.
This content was originally published on the Google Developer Site
Welcome to the Matter Handbook. This handbook is here to help make building and shipping devices with Matter easier by providing answers to common questions. Inside, you’ll find information on everything from getting started with the Working Groups, the basics of Matter, navigating the SDK, and more.
In the spirit of openness, we’ve tried to capture as much information here as possible. That includes links to resources that are only available to members of the Connectivity Standards Alliance. If you’re not a member and you find yourself clicking through to many of those password-protected areas, we encourage you to consider joining the Alliance to work with us there. If you’re a member of the media and have more questions, we encourage you to take a look at our Newsroom or reach out to press@csa-iot.org.
This handbook is compiled from contributions from our member volunteers. If you have suggestions, edits, or comments, either raise an issue or submit a PR on the GitHub Repository.
The Matter Software Development Kit is a collection of tools to facilitate building Matter devices and control applications. -The SDK comprises of several different components to guide the development process.
The ZAP tool is a GUI tool that is used to generate a .zap file which describes the endpoint composition of your device, and the clusters that are on it along with their attributes, commands, features, etc. -This .zap file is used by the ZAP compiler along with the cluster definitions from the SDK to generate an Ember layer. This happens automatically as part of the build process, and the Ember layer is compiled into the firmware.
The tool produces .matter files which are a human-readable version of the .zap that can be used for review.
The Ember layer is a generated layer that implements the composition of ONE SPECIFIC device. It looks at each message and determines if the device has implemented the selected attribute or command on the cluster on the selected endpoint, and then blocks or routes accordingly, based on the implementation and the access control. Valid requests are forwarded on to the cluster implementations to handle and invalid requests get sent back with an error. Ember layer is the piece that makes your device your device. Most are generated statically using zap.
Chef is a tool to help generate sample device type zap configuration files which can be further customised with the ZAP tool.
The Core src folder contains the underlying Matter interoperability layers that provide essential functionality. These are used by the build process.
CHIP Tool is our example controller app, used for development and testing of your Matter device.
GN is part of the build system which was originally developed for the Chromium browser project, it is used to configure the build of a Matter device. -Ninja is the component which builds the device image.
The platform layer contains device specific delegate implementations for most of the common architectures on which Matter is deployed.
The SDK contains absctraction layters for Python, Java and Kotlin controllers.
The SDK is publically avalible on GitHub