From 836e8fad653a7364c99d90deb13932f132331820 Mon Sep 17 00:00:00 2001 From: ipadurean-bd Date: Fri, 23 Feb 2024 10:46:37 +0200 Subject: [PATCH] Correct grammar and formatting Correct acronym defined first for each document Use Alliance instead of CSA (two terms: Alliance and CSA were used for the Connectivity Standard Alliance) Correct grammar mistakes Correct formatting Apply uniform formatting of lists with dot at the end --- content/Alliance/_index.md | 4 +- content/Alliance/howwework.md | 7 +- content/Alliance/membership.md | 1 + content/Alliance/resources.md | 6 +- content/Alliance/whatwedo.md | 5 +- content/HowItWorks/Attestation.md | 42 +++--- content/HowItWorks/Commisioning.md | 16 +- content/HowItWorks/ConnectivityTransports.md | 6 +- content/HowItWorks/DataModel.md | 28 +++- content/HowItWorks/DeviceTypes.md | 146 ++++++++++++------- content/HowItWorks/Discovery.md | 23 +-- content/HowItWorks/Fabric.md | 5 +- content/HowItWorks/InteractionModel.md | 46 ++++-- content/HowItWorks/Roles.md | 14 +- content/HowItWorks/Security.md | 48 +++--- content/HowItWorks/Thread.md | 6 +- content/HowItWorks/WhatIsMatter.md | 2 +- content/HowItWorks/_index.md | 4 +- content/SDK/_index.md | 14 +- content/Specification/_index.md | 8 +- content/_index.md | 5 +- 21 files changed, 276 insertions(+), 160 deletions(-) diff --git a/content/Alliance/_index.md b/content/Alliance/_index.md index e87b883..c17ab6d 100644 --- a/content/Alliance/_index.md +++ b/content/Alliance/_index.md @@ -5,12 +5,10 @@ weight = 2 pre = "2. " +++ - -# The Connectivity Standards Alliance +# The Connectivity Standards Alliance (The Alliance) 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](https://csa-iot.org/about/) 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. - diff --git a/content/Alliance/howwework.md b/content/Alliance/howwework.md index 4ecd6d6..fc366ec 100644 --- a/content/Alliance/howwework.md +++ b/content/Alliance/howwework.md @@ -5,6 +5,7 @@ weight = 15 +++ ### Working Groups + 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. @@ -17,14 +18,18 @@ The Marketing and Product Sub Group (MPSG) is responsible for capturing use case They also develop branding, positioning and external communications materials relating to Matter. ### Technical Sub Group + 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. ### Certification Sub Group + The Certification Sub Group (CSG) develops methods to test for specification conformance, from test cases & scripts, to test events leading up to specification release. ### Tiger Teams + 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. ### Joining -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. \ No newline at end of file + +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. diff --git a/content/Alliance/membership.md b/content/Alliance/membership.md index ca83124..59aff9e 100644 --- a/content/Alliance/membership.md +++ b/content/Alliance/membership.md @@ -9,6 +9,7 @@ weight = 20 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. ### Membership at a Glance + 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. diff --git a/content/Alliance/resources.md b/content/Alliance/resources.md index f25c2b4..db12062 100644 --- a/content/Alliance/resources.md +++ b/content/Alliance/resources.md @@ -9,19 +9,21 @@ weight = 30 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). ### New Member Orientation + - [Slides](https://groups.csa-iot.org/wg/members-all/document/30359) ### Group Links + - [Matter Working Group](https://groups.csa-iot.org/wg/matter-wg/dashboard) - [How to Join the Matter Working Group and Subgroups (pg. 32-35)](https://groups.csa-iot.org/wg/members-all/document/folder/2817) - [Meeting Calendar for Matter Working Groups and Subroups](https://groups.csa-iot.org/wg/matter-wg/calendar) _Not seeing a calendar for a specific group? Make sure you’re a member of that group for visibility_ ### Subgroups + - [Matter CSG](https://groups.csa-iot.org/wg/matter-csg/dashboard) - [Matter MPSG](https://groups.csa-iot.org/wg/matter-mpsg/workgroup) - [Matter TSG](https://groups.csa-iot.org/wg/matter-tsg/dashboard) ### Tools -- [Collaboration Tools (pg. 43-48)](https://groups.csa-iot.org/wg/members-all/document/folder/2817) - +- [Collaboration Tools (pg. 43-48)](https://groups.csa-iot.org/wg/members-all/document/folder/2817) diff --git a/content/Alliance/whatwedo.md b/content/Alliance/whatwedo.md index b341c17..b9b69c1 100644 --- a/content/Alliance/whatwedo.md +++ b/content/Alliance/whatwedo.md @@ -4,13 +4,14 @@ chapter = false weight = 10 +++ - ### Develop + 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. ### Certify + 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. ### Promote -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. +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. diff --git a/content/HowItWorks/Attestation.md b/content/HowItWorks/Attestation.md index 1fcf9f2..a5b5b5a 100644 --- a/content/HowItWorks/Attestation.md +++ b/content/HowItWorks/Attestation.md @@ -6,14 +6,16 @@ weight = 45 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: +During the commissioning process, a device cryptographically proves (attests) to the Commissioner that: + - it is a genuine product -- it is a product that passed Matter compliance tests and has been thus certified by CSA. +- it is a product that passed Matter compliance tests and has been thus certified by the Alliance. In order to accomplish those goals, the device carries: -- A Device Attestation Certificate (DAC) that conveys device's manufacturer ID (VID) and product ID (PID). The DAC chains up to a set of trusted roots, approved by CSA members. + +- A Device Attestation Certificate (DAC) that conveys device's manufacturer ID (VID) and product ID (PID). The DAC chains up to a set of trusted roots, approved by the Alliance members. - A securely-stored, private key associated with the public key stored in the DAC that proves the device owns this unique certificate. -- Certificate declaration is a statement cryptographically signed by CSA that states that a tuple (VID,PID) has passed Matter compliance tests. +- Certificate declaration is a statement cryptographically signed by the Alliance that states that a tuple (VID,PID) has passed Matter compliance tests. 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. @@ -29,13 +31,13 @@ The DAC is a X.509 v3 certificate. The first version of X.509 was published in 1 - Certificate Serial Number - Validity, where expiration can be indeterminate - Signature -- Vendor ID and Product ID are attributes of the MatterDACName in the DAC subject. +- Vendor ID and Product ID, which are attributes of the MatterDACName in the DAC subject. -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 is unique per device and associated with the unique attestation key pair within the product. It is issued by a Certificate Authority (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. +The DAC's signature is validated against the Product Attestation Intermediate Certificate (PAI), which is also issued by a Product Attestation Authority (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. +At the root of the chain of trust stands the PAA CA's public key, which 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. ![Matter Attestation Public Key Infrastructure](../../primer-attestation-pki.png) @@ -47,7 +49,7 @@ The PAI is also a X.509 v3 certificate that includes: - Certificate Serial Number - Validity, where expiration can be indeterminate - Signature -- Vendor ID and Product ID (optionally) are attributes of the MatterDACName in the DAC subject. +- Vendor ID and Product ID (optionally), which are attributes of the MatterDACName in the DAC subject. Lastly, the PAA is the root certificate in the chain and it is self-signed. It includes: @@ -56,7 +58,7 @@ Lastly, the PAA is the root certificate in the chain and it is self-signed. It i - Issuer - Subject - Certificate Serial Number -- Validity +- Validity. ## Additional Attestation Documents & Messages @@ -65,7 +67,9 @@ The attestation process has several documents and messages. The following items ![Attestation Document Hierarchy](../../primer-attestation-document-hierarchy.png) ### Certification Declaration (CD) -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 CD allows the Matter product to prove its compliance with the Matter protocol. When a product has been certified by the Alliance, 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: + - VID - PID (one or more) - Server Category ID @@ -73,9 +77,10 @@ The CD allows the Matter product to prove its compliance with the Matter protoco - Security Level - Security Information - Certification Type (development, provisional, or official) -- Signature +- Signature. ### Firmware Information (optional) + 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. @@ -83,26 +88,29 @@ The vendor might as well choose to include in Firmware Information only the "has 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. ### Attestation Information -Message sent from the Commissionee to the Commissioner. The Attestation Information combines a TLV containing the Attestation Elements and a Attestation Signature. -Attestation Elements -### This is a TLV containing: +Message sent from the Commissionee to the Commissioner. The Attestation Information combines a Tag-Length-Value (TLV) containing the Attestation Elements and an Attestation Signature. The Attestation Elements contain the metadata related to attestation, encoded in Matter TLV, with the following fields: + - Certificate Declaration - Timestamp - Attestation Nonce - Firmware Information (optional) -- Vendor Specific information (optional) +- Vendor Specific information (optional). ### Attestation Challenge + 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. ### Attestation TBS (to be signed) + Message containing the Attestation Elements and Attestation Challenge. ### Attestation Signature + Signature of the Attestation TBS, signed using the Device Attestation Private Key. ## Attestation Procedure + The Commissioner is responsible for validating attestation information from the Commissionee. It executes the following steps: 1. Commissioner generates a random 32 byte attestation nonce. In cryptography jargon, a nonce (number used once) is a random number generated in the cryptographic procedure and meant to be used once. @@ -118,4 +126,4 @@ The Commissioner is responsible for validating attestation information from the - Firmware Information (if present and supported by Commissioner) matches an entry in the Distributed Compliance Ledger. - Additional VID/PID validations also take place between the Device Basic Information Cluster, Certification Declaration and the DAC. -_This content was originally published on the [Google Developer Site](https://developers.home.google.com/matter/primer)_ \ No newline at end of file +_This content was originally published on the [Google Developer Site](https://developers.home.google.com/matter/primer)_ diff --git a/content/HowItWorks/Commisioning.md b/content/HowItWorks/Commisioning.md index e55d4d3..43b2a55 100644 --- a/content/HowItWorks/Commisioning.md +++ b/content/HowItWorks/Commisioning.md @@ -14,36 +14,46 @@ 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](/howitworks/discovery/#commissionable-discovery) methods. The Commissionee must also provide the onboarding payload. -## 2 Connect to device (PASE) +## 2 Connect to device using PASE + 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. ## 3 Get Commissionee information + 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. ## 4 Regulatory config + 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. ## 5 Commissionee attestation + 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. ## 6 Certificate Signing Request (CSR) + 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. ## 7 Add Node Operational Certificate (NOC) -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 uses the CSR information received from the Commissionee and passes it to the Administrative Domain Manager (ADM) to generate a trusted 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. ## 8 Network provisioning + 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. ## 9 Operational discovery + Once the newly commissioned node is connected to the network, the Commissioner uses [Operational Discovery](/howitworks/discovery/#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. ## 10 CASE session establishment + 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. ## 11 Commissioning complete + 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](https://developers.home.google.com/matter/primer)_ \ No newline at end of file +_This content was originally published on the [Google Developer Site](https://developers.home.google.com/matter/primer)_ diff --git a/content/HowItWorks/ConnectivityTransports.md b/content/HowItWorks/ConnectivityTransports.md index 91cafc9..d09ba00 100644 --- a/content/HowItWorks/ConnectivityTransports.md +++ b/content/HowItWorks/ConnectivityTransports.md @@ -4,7 +4,7 @@ chapter = false weight = 30 +++ -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 certifica­tion is suitably bounded. +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 owner­ship 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 con­sumer premises or where the support proves otherwise limiting, for example, if the delegated pre­fix cannot accommodate all the networks and devices on premises. @@ -21,7 +21,7 @@ Commissioning of devices should use the on-network bitmask in the Discovery Capa 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](https://www.wi-fi.org/certification). 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. +For commissioning, Wi-Fi devices may use the Bluetooth Low Energy (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 @@ -31,5 +31,5 @@ When a device uses Thread, it must also use BLE for Discovery and Commissioning ## Bluetooth -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 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. diff --git a/content/HowItWorks/DataModel.md b/content/HowItWorks/DataModel.md index 3ddaf50..36809af 100644 --- a/content/HowItWorks/DataModel.md +++ b/content/HowItWorks/DataModel.md @@ -21,7 +21,7 @@ A Node role is a set of related behaviors. Each Node may have one or more roles. - Commissioner: A Node that performs Commissioning. - Controller: A Node that can control one or more Nodes. Examples include a phone app used for device setup, the Hub associated with the setup app which might be embedded in a Router, Smart Speaker, TV or Smart Panel. Some device types, such as the On/Off Light Switch, have the Controller role. -- Controlee: A Node that can be controlled by one or more Nodes. Most device types can be a - - Controlee, except for some device types which have the Controller role, such as the On/Off Light Switch. The On/Off Light Switch can only be a Controller. It cannot be a Controlee. +- Controlee: A Node that can be controlled by one or more Nodes. Most device types can be a Controlee, except for some device types which have the Controller role, such as the On/Off Light Switch. The On/Off Light Switch can only be a Controller. It cannot be a Controlee. - OTA Provider: A Node that can provide OTA software updates. - OTA Requestor: A Node that can request OTA software updates. @@ -32,14 +32,17 @@ Within an Endpoint a Node has one or more Clusters. These are another step in th 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. ![Nodes, Endpoints, Attributes and Commands](../../primer-node-endpoint-attribute.png) ### Commands + 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. ![A sample of the hierarchy of Matter Devices interaction model](../../primer-device-type.png) @@ -50,7 +53,7 @@ The Endpoint 0 is reserved for the Utility Clusters. Utility Clusters are specif 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 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](https://csa-iot.org/developer-resource/specifications-download-request/). @@ -60,8 +63,8 @@ Each Endpoint implementing a Device Type must implement the mandatory Clusters t 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: -- reads from and writes to its remote Attributes. -- reads of its remote Events. +- reads from and writes to its remote Attributes +- reads of its remote Events - invocation of its remote Commands. 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. @@ -77,23 +80,32 @@ In this sample, the On/Off Client Cluster on Node A is changing the attributes o In the next section we'll detail how Client and Server Clusters interact: the Interaction Model. ## Descriptor Cluster + As the name implies, the Descriptor Cluster Server provides introspection information. It describes the Endpoint enumerating its: -- Server Clusters. -- Client Clusters. -- Device Types. +- Server Clusters +- Client Clusters +- Device Types - Additional Endpoints, known as Parts. + Every Device Type requires the implementation of Descriptor Clusters. The Root Device Type is defined on Endpoint 0. Reading its Descriptor Cluster will provide the client the visibility to traverse the full tree of available Endpoints and perform applicable operations. 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. ### Server Clusters + The `ServerList` Attribute lists the Cluster Servers in the Endpoint. + ### Client Clusters + The `ClientList` Attribute lists the Cluster Clients in the Endpoint. + ### Device Type List + 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. + ### Parts List + 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). @@ -102,6 +114,6 @@ The `PartsList` of other Endpoints will usually be empty. For example, a Tempera 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. -[^1]: The Matter specification determines that a Device may have multiple Nodes. For example, smartphones may have multiple apps, each app being a different Node. For the purposes of this primer, all Devices will contain a single Node. It's expected that most physical devices will follow this pattern. +[^1]: The Matter specification determines that a Device may have multiple Nodes. For example, smartphones may have multiple apps, each app being a different Node. For the purposes of this primer, all Devices will contain a single Node. It's expected that most physical devices will follow this pattern. _This content was originally published on the [Google Developer Site](https://developers.home.google.com/matter/primer)_ diff --git a/content/HowItWorks/DeviceTypes.md b/content/HowItWorks/DeviceTypes.md index 082ed1e..1955659 100644 --- a/content/HowItWorks/DeviceTypes.md +++ b/content/HowItWorks/DeviceTypes.md @@ -8,166 +8,196 @@ In order to be certified a Matter device must conform to one of the approved dev As of Matter 1.2 the following types are certifiable. - - Lighting - - [On/Off Light](#onoff-light) - - [Dimmable Light](#dimmable-light) - - [Color Temperature Light](#color-temperature-light) - - [Extendded Color Light](#extendded-color-light) + - [On/Off Light](#onoff-light) + - [Dimmable Light](#dimmable-light) + - [Color Temperature Light](#color-temperature-light) + - [Extended Color Light](#extended-color-light) - Smart Plugs/Outlets and Other Actuators - - [On/Off Plug in Unit](#onoff-plug-in-unit) - - [Dimmable Plug in Unit](#dimmable-plug-in-unit) - - [Pump](#pump) + - [On/Off Plug in Unit](#onoff-plug-in-unit) + - [Dimmable Plug in Unit](#dimmable-plug-in-unit) + - [Pump](#pump) - Switches and Controls - - [On/Off Light Switch](#onoff-light-switch) - - [Dimmer Switch](#dimmer-switch) - - [Color Dimmer Switch](#color-dimmer-switch) - - [Control Bridge](#control-bridge) - - [Pump Controller](#pump-controller) - - [Generic Switch](#generic-switch) + - [On/Off Light Switch](#onoff-light-switch) + - [Dimmer Switch](#dimmer-switch) + - [Color Dimmer Switch](#color-dimmer-switch) + - [Control Bridge](#control-bridge) + - [Pump Controller](#pump-controller) + - [Generic Switch](#generic-switch) - Sensors - - [Contact Sensor](#contact-sensor) - - [Light Sensor](#light-sensor) - - [Occupancy Sensor](#occupancy-sensor) - - [Temperature Sensor](#temperature-sensor) - - [Pressure Sensor](#pressure-sensor) - - [Flow Sensor](#flow-sensor) - - [Humidity Sensor](#humidity-sensor) - - [On/Off Sensor](#onoff-sensor) - - [Smoke CO Alarm](#smoke-co-alarm) + - [Contact Sensor](#contact-sensor) + - [Light Sensor](#light-sensor) + - [Occupancy Sensor](#occupancy-sensor) + - [Temperature Sensor](#temperature-sensor) + - [Pressure Sensor](#pressure-sensor) + - [Flow Sensor](#flow-sensor) + - [Humidity Sensor](#humidity-sensor) + - [On/Off Sensor](#onoff-sensor) + - [Smoke CO Alarm](#smoke-co-alarm) - Closures - - [Door Lock](#door-lock) - - [Door Lock Controller](#door-lock-controller) - - [Window Covering](#window-covering) - - [Window Covering Controller](#window-covering-controller) + - [Door Lock](#door-lock) + - [Door Lock Controller](#door-lock-controller) + - [Window Covering](#window-covering) + - [Window Covering Controller](#window-covering-controller) - HVAC - - [Heating/Cooling Unit](#heatingcooling-unit) - - [Thermostat](#thermostat) - - [Fan](#fan) - - [Air Purifier](#air-purifier) - - [Air Quality Sensor](#air-quality-sensor) + - [Heating/Cooling Unit](#heatingcooling-unit) + - [Thermostat](#thermostat) + - [Fan](#fan) + - [Air Purifier](#air-purifier) + - [Air Quality Sensor](#air-quality-sensor) - Media - - [Basic Video Player](#basic-video-player) - - [Casting Video Player](#casting-video-player) - - [Speaker](#speaker) - - [Content App](#content-app) - - [Casting Video Client](#casting-video-client) - - [Video Remote Control](#video-remote-control) + - [Basic Video Player](#basic-video-player) + - [Casting Video Player](#casting-video-player) + - [Speaker](#speaker) + - [Content App](#content-app) + - [Casting Video Client](#casting-video-client) + - [Video Remote Control](#video-remote-control) - Robotic Devices - - [Robotic Vacuum Cleaner](#robotic-vacuum-cleaner) + - [Robotic Vacuum Cleaner](#robotic-vacuum-cleaner) - Appliances - - [Refrigerator](#refrigerator) - - [Temperature Controlled Cabinet](#temperature-controlled-cabinet) - - [Room Air Conditioner](#room-air-conditioner) - - [Laundry Washer](#laundry-washer) - - [Dishwasher](#dishwasher) + - [Refrigerator](#refrigerator) + - [Temperature Controlled Cabinet](#temperature-controlled-cabinet) + - [Room Air Conditioner](#room-air-conditioner) + - [Laundry Washer](#laundry-washer) + - [Dishwasher](#dishwasher) ### On/Off Light + 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. ### Dimmable Light -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 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 Dimmer Switch. In addition, a Dimmable Light device is also capable of being switched by means of a bound occupancy sensor or other device(s). ### Color Temperature Light -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. + +A Color Temperature Light is a lighting device that is capable of being switched on or off, the intensity of its light adjusted, and its color temperature adjusted by means of a bound controller device such as a Color Dimmer Switch. ### Extended Color Light -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 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/saturation, 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. ### On/Off Plug in Unit -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. + +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 typically used to control a conventional non-communicating light by switching its mains connection. Other appliances can be controlled this way as well. ### Dimmable Plug in Unit + 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. ### Pump + 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. ### On/Off Light Switch + 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. ### Dimmer Switch + 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. ### Color Dimmer Switch + 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. ### Control Bridge + 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. ### Pump Controller + A Pump Controller device is capable of configuring and controlling a Pump device. ### Generic Switch + 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. + - The On/Off Light Switch will send On/Off/Toggle commands from its On/Off (client) cluster to a device implementing the On/Off (server) cluster to control the on/off functionality of that device. An On/Off Light Switch device can also implement Groups and Scenes clusters and thus send group and scene commands. Basically, it is targeted at directly sending control commands to other devices. The binding table is used to tell the device where to send the commands. - The Generic Switch device type will send updates of attributes (for Latching Switch only) and events to subscribed parties which implement the Switch client cluster, as indications of inter­ action with the switch - leaving the interpretation (e.g. which device should be actuated because of the interaction) to the subscribed party. So it can be compared to a sensor-type 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. ### Contact Sensor + The Contact Sensor is a device that reports a boolean state, typically open/closed. ### Light Sensor + 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. ### Occupancy Sensor + An Occupancy Sensor is a measurement and sensing device that is capable of measuring and reporting the occupancy state in a designated area. ### Temperature Sensor + A Temperature Sensor device reports measurements of temperature. ### Pressure Sensor + A Pressure Sensor device measures and reports the pressure of a fluid. ### Flow Sensor + A Flow Sensor device measures and reports the flow rate of a fluid. ### Humidity Sensor + A humidity sensor (in most cases a Relative humidity sensor) reports humidity measurements. ### On/Off Sensor + 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. ### Smoke CO Alarm + 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. ### Door Lock + 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. ### Door Lock Controller + A Door Lock Controller is a device capable of controlling a door lock. ### Window Covering + 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. ### Window Covering Controller + A Window Covering Controller is a device that controls a window covering device. ### Heating/Cooling Unit -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 Heating/Cooling Unit is a device capable of heating or cooling a space in a house. It is not mandatory to provide both functionalities (for example, the device may just heat but not cool). It may be an indoor air handler. ### Thermostat -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. +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. ### Fan + ### Air Purifier + 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. ### Air Quality Sensor + 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. ### Basic Video Player 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 +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. ### Casting Video Player @@ -183,31 +213,37 @@ To control unmute/mute, the On/Off cluster SHALL be used. A value of TRUE for th A dedicated endpoint is needed because the On/Off cluster can also be used for other purposes, such as for power control. ### Content App + 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. ### Casting Video Client -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 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. ### Video Remote Control + A Video Remote Control is a client that can control a Video Player, for example, a traditional universal remote control. ### Robotic Vacuum Cleaner -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 robotic vacuum cleaner is a device capable of autonomous cleaning, the cleaning mode may be selected from a number of predefined options and the device should report back any error states. ### Refrigerator + 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. ### Temperature Controlled Cabinet -A Temperature Controlled Cabinet only exists composed as part of another device type. It repre­sents a single cabinet chilling or freezing food in a refrigerator, freezer, wine chiller or other simi­lar device. +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. ### Room Air Conditioner + A Room Air Conditioner is a device with the primary function of controlling the air temperature in a single room. ### Laundry Washer + A Laundry Washer represents a device that is capable of laundering consumer items. Any laundry washer product may utilize this device type. ### Dishwasher -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. \ No newline at end of file +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. diff --git a/content/HowItWorks/Discovery.md b/content/HowItWorks/Discovery.md index e934745..d5f38f9 100644 --- a/content/HowItWorks/Discovery.md +++ b/content/HowItWorks/Discovery.md @@ -9,7 +9,7 @@ weight = 41 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: - Bluetooth low energy (BLE) -- DNS-SD on an any IP network the Node is connected to +- Domain name service - service discovery (DNS-SD) on an any IP network the Node is connected to In either method, the commissionable node advertises information as shown in the table below. @@ -31,6 +31,7 @@ Many devices will advertise for a short period of time (~3-15 mins) after power- | Most control does not originate from fabric. For example, dishwasher or refrigerator. | No | ### Bluetooth Low Energy + 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. @@ -39,32 +40,34 @@ The Commissioner does not need to issue scan requests. It should do a passive sc BLE is not used for operational discovery. - ### DNS-SD -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: +In this case the Commissionee will be discovered by its 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. -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. +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 + 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 -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. + +Commissioner discovery is the process used by Commissionees 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. +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](https://developers.home.google.com/matter/primer)_ \ No newline at end of file +_This content was originally published on the [Google Developer Site](https://developers.home.google.com/matter/primer)_ diff --git a/content/HowItWorks/Fabric.md b/content/HowItWorks/Fabric.md index 8c4ab38..0c1a9f7 100644 --- a/content/HowItWorks/Fabric.md +++ b/content/HowItWorks/Fabric.md @@ -12,7 +12,7 @@ Thus the commissioning process is the assignment of the Fabric credentials to a ## Operational credentials -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 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 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: @@ -37,11 +37,10 @@ The Attestation procedure is a process used by the Commissioner to certify that: - The Device has gone through Matter certification. - The Device is indeed is what it claims to be: it cryptographically proves its Vendor, Product ID and other manufacturing information. - ## Multi-Admin 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](https://developers.home.google.com/matter/primer)_ \ No newline at end of file +_This content was originally published on the [Google Developer Site](https://developers.home.google.com/matter/primer)_ diff --git a/content/HowItWorks/InteractionModel.md b/content/HowItWorks/InteractionModel.md index b5bc431..8474030 100644 --- a/content/HowItWorks/InteractionModel.md +++ b/content/HowItWorks/InteractionModel.md @@ -12,7 +12,7 @@ Nodes interact with each other by: - Reading and Subscribing to Attributes and Events - Writing to Attributes -- Invoking Commands +- Invoking Commands. 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. @@ -21,14 +21,17 @@ Whenever a Node establishes an encrypted communication sequence with another Nod 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. ### Initiators and Targets + 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. ### Groups + 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. ### Paths + 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". @@ -47,16 +50,18 @@ There are two ways of performing a Write or Invoke Transaction: Timed and Untime To understand Timed Transactions it's useful to understand how Intercept Attacks can happen and why Timed Transactions are important. -The Intercept Attack +#### 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. +- 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". +- 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. @@ -70,6 +75,7 @@ The developer creating a product that uses the Matter SDK typically does not per ## Read Transactions ### Read Transaction + 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. ### Read Request Action @@ -87,6 +93,7 @@ After the Read Request Action is received by the Target it will assemble a Repor After the Read Request Action is received by the Target it will assemble a Report Data Action with the requested information. ### Report Data Action + Direction: Target -> Initiator In this Action the Target responds with: @@ -107,11 +114,13 @@ Once the Status Response Action is sent by the Initiator, or a Report Data Actio The Status Response Action simply contains a status field that will either acknowledge operation success or present a failure code. ### Read Restrictions + 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. ## Subscription Transaction + ### Subscribe Request Action Direction: Initiator -> Target @@ -154,11 +163,13 @@ This is the last Action on the Subscription Transaction and concludes the proces - The Subscriber may terminate the Subscription Interaction by responding to a Report Data Action with an INACTIVE_SUBSCRIPTION status code. ## Write Transactions + 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. ### Untimed Write Transaction #### Write Request Action + Direction: Initiator -> Target Similar to the Read Request Action, in this Action the Initiator provides the Target with: @@ -168,7 +179,9 @@ Similar to the Read Request Action, in this Action the Initiator provides the Ta - Suppress Response: a flag that indicates whether the Response Status Action should be suppressed. ![Untimed Write Transaction](../../primer-im-untimed-writing.png) + #### Write Response Action + Direction: Target -> Initiator After the Target receives the Write Request Action it will finalize the transaction with a Write Response Action that carries: @@ -182,9 +195,11 @@ The Write Request Action may be a groupcast, but in this case the Suppress Respo 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 Transaction + Timed write transactions add a few steps to untimed write transactions. #### Timed request action + Direction: Initiator -> Target A Initiator starts the Transaction sending this Action that contains: @@ -194,21 +209,25 @@ 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. #### Write Request Action + Same as the previously described Write Request Action. #### Write Response Action + Same as the previously described Write Response Action. #### Timed Write Restrictions + The Timed Request Action, the Write Request Action and the Write Response Action are unicast-only. ## Invoke Transactions + 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. - ### Untimed Invoke Transaction + #### Invoke Request Action Direction: Initiator -> Target @@ -231,16 +250,18 @@ After the Target receives the Invoke Request Action it will finalize the transac - Invoke Responses: a list of command responses or status for every invoke request sent. - Interaction ID: a integer used for matching the Invoke Response Action to the Invoke Request Action. - #### Untimed Invoke Restrictions +#### Untimed Invoke Restrictions 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. ### Timed Invoke Transactions + Similar to Timed Write Transactions, Timed Invoke Transactions also start with the Timed Request Action. #### Timed Request Action + Direction: Initiator -> Target A Initiator starts the Transaction sending this Action that contains: @@ -252,14 +273,17 @@ Once the Timed Request Action is received, the Target must acknowledge the Timed ![Timed Invoke Transaction](../../primer-im-timed-invoking.png) #### Invoke Request Action + Same as the previously described Invoke Request Action. #### Invoke Response Action + Same as the previously described Invoke Response Action #### Timed Invoke Restrictions + 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](https://developers.home.google.com/matter/primer)_ \ No newline at end of file +_This content was originally published on the [Google Developer Site](https://developers.home.google.com/matter/primer)_ diff --git a/content/HowItWorks/Roles.md b/content/HowItWorks/Roles.md index 1707252..148f34c 100644 --- a/content/HowItWorks/Roles.md +++ b/content/HowItWorks/Roles.md @@ -3,33 +3,39 @@ title = "Roles" chapter = false weight = 5 +++ + 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. ## Matter Device + 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 Fabric + 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. ## Matter Commissioner + 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. ## Matter Administrator + 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. ## Matter Controller -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. + +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. +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). ## Matter Bridge -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. +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_ diff --git a/content/HowItWorks/Security.md b/content/HowItWorks/Security.md index 3a1bce5..bd915dc 100644 --- a/content/HowItWorks/Security.md +++ b/content/HowItWorks/Security.md @@ -8,47 +8,55 @@ 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. ### Comprehensive -- Layered approach with authentication and attestation for commissioning -- Every message protected -- Secure over-the-air firmware updates -### Strong -- Single strong cryptographic suite based on well-established standards -- Passcodes and certificates used to setup secure sessions -- Device attestation to ensure authenticity +- Layered approach with authentication and attestation for commissioning. +- Every message protected. +- Secure over-the-air firmware updates. + +### Strong + +- Single strong cryptographic suite based on well-established standards. +- Passcodes and certificates used to setup secure sessions. +- Device attestation to ensure authenticity. ### Easy -- Designed to make smart devices easier to implement and use + +- Designed to make smart devices easier to implement and use. ### Resilient -- Designed to protect, detect and recover -- Distributed Compliance Ledger to enhance resiliency and scale + +- Designed to protect, detect and recover. +- Distributed Compliance Ledger to enhance resiliency and scale. ### Agile -- Crypto-flexibility to address new developments and threats + +- Crypto-flexibility to address new developments and threats. ## Matter Privacy Principles -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 + +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. ### Confidentiality & Integrity + 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 ### Proof of identity + Required for Matter devices with cryptographic certificates so data is shared only between known Matter entities ### Open standard + Enables anyone to inspect the template for Matter interactions between legitimate Matter nodes ### Minimizing data -Data shared within Matter interactions is minimized, thereby reducing the potential for inadvertent leakage -of information + +Data shared within Matter interactions is minimized, thereby reducing the potential for inadvertent leakage of information ### Defined purpose -Data shared between Matter nodes is strictly for a defined purpose, namely, for the specific operations -of devices as required by the Matter protocol + +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 \ No newline at end of file + +Encryption to ensure that messages or identities of communicating parties are not in cleartext on the network diff --git a/content/HowItWorks/Thread.md b/content/HowItWorks/Thread.md index d5c3764..02901b7 100644 --- a/content/HowItWorks/Thread.md +++ b/content/HowItWorks/Thread.md @@ -5,6 +5,7 @@ weight = 60 +++ ## Low Power + 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. @@ -14,6 +15,7 @@ Frames on the IEEE 802.15.4 PHY are 127 bytes, but the largest (and typical) max To learn more, refer to IPv6 Addressing in the [Thread Primer on openthread.io](https://openthread.io/guides/thread-primer). ## Border Routers + 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. @@ -30,6 +32,7 @@ Border Routers are also responsible for: To learn more, refer to the [Border Router guide on openthread.io](https://openthread.io/guides/border-router). ## IPv6 Multicast + 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. @@ -49,9 +52,6 @@ This Table details how this address is constructed: |8 bits|0x00| |16 bits|Group ID| - More information can be found in the [Multicast](https://openthread.io/guides/thread-primer/ipv6-addressing) 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. - - diff --git a/content/HowItWorks/WhatIsMatter.md b/content/HowItWorks/WhatIsMatter.md index d5fe6d7..e3563de 100644 --- a/content/HowItWorks/WhatIsMatter.md +++ b/content/HowItWorks/WhatIsMatter.md @@ -17,4 +17,4 @@ Matter also supports bridging of other Smart Home technologies such as Zigbee, B 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](https://developers.home.google.com/matter/primer)_ \ No newline at end of file +_This content was originally published on the [Google Developer Site](https://developers.home.google.com/matter/primer)_ diff --git a/content/HowItWorks/_index.md b/content/HowItWorks/_index.md index 4a12cb2..3ffcae7 100644 --- a/content/HowItWorks/_index.md +++ b/content/HowItWorks/_index.md @@ -4,7 +4,7 @@ chapter = true weight = 1 pre = "1. " +++ -# How It Works -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](https://csa-iot.org/developer-resource/specifications-download-request/) for the most detail. +# How It Works +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](https://csa-iot.org/developer-resource/specifications-download-request/) for the most detail. diff --git a/content/SDK/_index.md b/content/SDK/_index.md index dbe88c5..3937d31 100644 --- a/content/SDK/_index.md +++ b/content/SDK/_index.md @@ -5,39 +5,45 @@ weight = 4 pre = "4. " +++ - # The Matter SDK 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. ### ZAP + 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. +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. ### Ember + 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 +### Chef + Chef is a tool to help generate sample device type zap configuration files which can be further customized with the ZAP tool. ### Core + The Core src folder contains the underlying Matter interoperability layers that provide essential functionality. These are used by the build process. ### CHIP Tool + CHIP Tool is our example controller app, used for development and testing of your Matter device. ### GN/Ninja + 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. ### Platform Layer + The platform layer contains device specific delegate implementations for most of the common architectures on which Matter is deployed. ### Abstraction Layers -The SDK contains abstraction layers for Python, Java and Kotlin controllers. +The SDK contains abstraction layers for Python, Java and Kotlin controllers. The SDK is publically avalible on [GitHub](https://github.com/project-chip/connectedhomeip) diff --git a/content/Specification/_index.md b/content/Specification/_index.md index 3a69763..ad0949f 100644 --- a/content/Specification/_index.md +++ b/content/Specification/_index.md @@ -5,12 +5,11 @@ weight = 3 pre = "3. " +++ - # The Matter Specifications - The Matter Specification is updated twice a year in Spring and Fall. -- Version 1.0 was published in November 2022 + +- Version 1.0 was published in November 2022 - Version 1.1 was published in April 2023 - Version 1.2 was published in October 2023 @@ -21,5 +20,4 @@ The specification is made up of a number of documents: - The Device Library Specification sets out the types of End User device in Matter and which Application Clusters make up that device. - The Namespace Specification (introduced in 1.2) details common data formats and structures used across multiple clusters. - -All these documents can be downloaded from [The Alliance website](https://csa-iot.org/developer-resource/specifications-download-request/). \ No newline at end of file +All these documents can be downloaded from [The Alliance website](https://csa-iot.org/developer-resource/specifications-download-request/). diff --git a/content/_index.md b/content/_index.md index 37c2694..a31528f 100644 --- a/content/_index.md +++ b/content/_index.md @@ -5,11 +5,10 @@ weight = 5 pre = "1. " +++ - # Welcome -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. +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](https://csa-iot.org/become-member/) 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](https://csa-iot.org/newsroom/) or reach out to . -This handbook is compiled from contributions from our member volunteers as a guide and educational resource. In the case that there is a discrepancy between this handbook and the Matter specification, SDK, or Connectivity Standards Alliance policy, those formal documents are the source of truth. But please let us know! If you have suggestions, edits, or comments, either raise an issue or submit a PR on the [GitHub Repository](https://github.com/project-chip/matter-handbook). +This handbook is compiled from contributions from our member volunteers as a guide and educational resource. In the case that there is a discrepancy between this handbook and the Matter specification, SDK, or Connectivity Standards Alliance policy, those formal documents are the source of truth. But please let us know! If you have suggestions, edits, or comments, either raise an issue or submit a PR on the [GitHub Repository](https://github.com/project-chip/matter-handbook).