Pull request project-chip#215: Doc updates v1.0.0

Merge in WMN_TOOLS/matter from doc_updates_v1.0.0 to silabs

Squashed commit of the following:

commit 46f15d6f949cab44c10262869b2d94448d430f72
Author: Ezra Hale <ezra.hale@silabs.com>
Date:   Fri Oct 28 14:10:14 2022 -0400

    fixed typos on board names

commit 55c9e89b5f006bab627120b2e5b466ba06e9792f
Author: Ezra Hale <ezra.hale@silabs.com>
Date:   Fri Oct 28 13:58:31 2022 -0400

    updates to boards supported in script and vscode tasks, also few updates to matter bridge readmes

commit 49683bfb98730654f592187f373d1b20b6eada2a
Author: Ezra Hale <ezra.hale@silabs.com>
Date:   Fri Oct 28 12:13:03 2022 -0400

    review of silabs_examples documentation

... and 14 more commits

Author: Ezra Hale

.vscode/tasks.json

@@ -35,29 +35,34 @@
 
     1. [Setting up environment](dev/vscode/SETUP.md)
     2. [Running tasks](dev/vscode/TASKS.md)
-        1. [Build](dev/vscode/BUILD.md)
-        2. [Flash](dev/vscode/FLASH.md)
-        3. [Debug](dev/vscode/DEBUG.md) <br><br>
+        1. [Create](dev/vscode/CREATE.md)
+        2. [Build](dev/vscode/BUILD.md)
+        3. [Flash](dev/vscode/FLASH.md)
+        4. [Debug](dev/vscode/DEBUG.md) <br><br>
 
-7. Reference Guides
+7. Matter Overview Guides
+   1. [Commissioning Process Overview](general/COMMISSIONING.md)
+   2. [Security Overview](general/SECURITY.md)
+   5. [Matter Attestation Credentials for EFR32](../../silabs_examples/credentials/README.md)
+   3. [Matter Sleepy End Devices over Openthread](general/OT_SLEEPY_END_DEVICE.md)
+   4. [Matter OTA Software Update](general/OTA_SOFTWARE_UPDATE.md)
+   <br><br>
+8. Reference Guides
 
     1. [Matter Hardware Requirements](general/HARDWARE_REQUIREMENTS.md)
     2. [Matter Software Requirements](general/SOFTWARE_REQUIREMENTS.md)
     3. [Matter Artifacts Page](general/ARTIFACTS.md)
     4. [Matter Commit Hashes](general/COMMIT_HASHES.md)
     5. [How to Flash a Silicon Labs Device](general/FLASH_SILABS_DEVICE.md)
     6. [How to Find Your Raspberry Pi](general/FIND_RASPI.md)
-    7. [Silicon Labs Matter Commit Hashes](general/COMMIT_HASHES.md)
-    8. [Building a Custom Matter Device](general/CUSTOM_MATTER_DEVICE.md)
-    9. [Matter OTA Software Update](general/OTA_SOFTWARE_UPDATE.md)
-    10. [Matter Attestation Credentials for EFR32](../../silabs_examples/credentials/README.md)
-    11. [Using Simplicity Studio's Pin Tool and Project Configurator with Matter](./general/PINTOOL.md)
-    12. [Using Simplicity Studio's BLE GATT Configurator with Matter](./general/GATT.md)
-    13. [Using Simplicity Studio's Energy Profiler with Matter](./general/EP.md)
-    14. [Using Wireshark to Capture Network Traffic in Matter](./general/WIRESHARK.md)
-    15. [Matter EFR32 Flash Savings Guide](general/CODE_SIZE_SAVINGS.md)<br><br>
-
-8. Frequently Asked Questions (FAQ) / Troubleshooting
+    7. [Building a Custom Matter Device](general/CUSTOM_MATTER_DEVICE.md)
+    8.  [Using Simplicity Studio's Pin Tool and Project Configurator with Matter](./general/PINTOOL.md)
+    9.  [Using Simplicity Studio's BLE GATT Configurator with Matter](./general/GATT.md)
+    10. [Using Simplicity Studio's Energy Profiler with Matter](./general/EP.md)
+    11. [Using Wireshark to Capture Network Traffic in Matter](./general/WIRESHARK.md)
+    12. [Matter EFR32 Flash Savings Guide](general/CODE_SIZE_SAVINGS.md)<br><br>
+
+9.  Frequently Asked Questions (FAQ) / Troubleshooting
 
     - [Thread FAQ](thread/FAQ.md)
     - [Wi-Fi FAQ](wifi/FAQ.md)

docs/silabs/README.md

@@ -60,7 +60,8 @@ This step is identical to the steps for building on Linux/Mac, Refer to
 that [ section ](#linMac).
 
 ## ![](../../images/win_run_setup.gif)
-
+### Note for Windows Developers
+During bootstrap, an error might occur. Check if pip.exe is installed in ./environment/gn_out/python-venv/Scripts. If it does not exist, install pip.exe in that directory and rebuild the example.
 
 -----
 

docs/silabs/dev/vscode/BUILD.md

@@ -0,0 +1,43 @@
+# Building in VS Code
+
+This section covers creating a new sample application from an existing application, which is optional for [ Building ](BUILD.md), [ Flashing ](FLASH.md) and
+[ Debugging ](DEBUG.md) the target Matter Accessory Devices.
+
+<a name="linMac"></a>
+
+## Linux/Mac
+
+### Step 1:
+
+Use the shortcut (Ctrl + Shift + P) to trigger the command pallet.
+
+### Step 2:
+
+Search for "Run Task" and select the "Copy Sample Application" option.
+
+### Step 3:
+
+On the drop-down menu, select "Copy Sample Application".
+
+### Step 4:
+
+On the next menu select an EFR32 example to copy.
+
+### Step 5:
+
+Select the appropriate target board.
+
+![](../../images/build_efr32_example.gif)
+
+### Step 6:
+
+Provide a name for the sample application target directory in the Matter workspace.
+
+## Windows
+
+Copying a sample application is not supported for Windows at this time.
+
+
+-----
+
+[Table of Contents](../../README.md)

docs/silabs/dev/vscode/CREATE.md

@@ -4,9 +4,10 @@ VS Code offers a great way for developers to customize their development
 environment through the use of "tasks". The following key tasks have been
 provided to facilitate the development experience.
 
-1. [Build](BUILD.md)
-2. [Flash](FLASH.md)
-3. [Debug](DEBUG.md) <br><br>
+1. [Create](CREATE.md)
+2. [Build](BUILD.md)
+3. [Flash](FLASH.md)
+4. [Debug](DEBUG.md) <br><br>
 
 -----
 

docs/silabs/dev/vscode/TASKS.md

@@ -24,7 +24,7 @@ used with a Raspberry Pi to allow the Raspberry Pi's Open Thread Border Router
 to access the Thread network. Radio Co-Processor (RCP) images are available in
 the Assets section of this page:
 
-https://github.com/SiliconLabs/matter/releases/tag/v0.4.0
+https://github.com/SiliconLabs/matter/releases/tag/v1.0.0
 
 <br>
 
@@ -34,7 +34,7 @@ The Matter Accessory Device Images are used to turn an EFR into a Matter device.
 These are pre-built binary images for the Matter Demo. Matter Accessory Device
 Images are located in the Assets section of this page:
 
-https://github.com/SiliconLabs/matter/releases/tag/v0.4.0
+https://github.com/SiliconLabs/matter/releases/tag/v1.0.0
 
 For Matter over Thread, 3 different types of images are provided:
 
@@ -51,7 +51,7 @@ EFR32MG2x device, you will need to flash a bootloader binary on your device alon
 with the application image. Bootloader binaries for all of the Matter supported
 devices are available here:
 
-https://github.com/SiliconLabs/matter/releases/tag/v0.4.0
+https://github.com/SiliconLabs/matter/releases/tag/v1.0.0
 
 <br>
 
@@ -68,7 +68,7 @@ directory, `./third_party/silabs/wiseconnect-wifi-bt-sdk/firmware`
 SiWx917 Firmware(rps) images are available in
 the Assets section of this page:
 
-https://github.com/SiliconLabs/matter/releases/tag/v0.4.0
+https://github.com/SiliconLabs/matter/releases/tag/v1.0.0
 
 <br>
 ---

docs/silabs/general/ARTIFACTS.md

@@ -0,0 +1,56 @@
+# Commissioning
+
+## Overview
+
+The commissioning process supports two potential starting points:
+
+1. The device is already on the network
+2. The device needs network credentials for Wi-Fi or Thread (requires Bluetooth LE (BLE) support)
+
+The current Matter revision supports Ethernet, Wi-Fi, and Thread devices. 
+
+- Ethernet devices get into the operational network when their Ethernet cable is connected. Therefore the devices are normally already on the network before commissioning.
+- Wi-Fi and Thread devices must have credentials configured before the devices can be joined into the operational network. This is normally done over BLE. 
+
+The first step is for the device to enter commissioning mode, following one of two scenarios:  
+
+| Scenario Name | Description |
+| ------------------------- | ----------- |
+| Standard | Device automatically goes into the commissioning mode on power-up. Beneficial for limited UI devices (such as light bulbs) |
+| User-Directed | Device only enters commissioning mode when initiated by the user.  Helpful for devices that have user interfaces or for which commissioning should not be initiated without a user present. |
+
+The following figure provides an overview of the commissioning process and the actions each role performs. 
+
+![Commissioning Overview](./images/CommissioningOverview.png)
+
+## Example Commissioning Flow
+
+![Steps 1-4](./images/CommissioningSteps1-4.png)
+
+In step 1, the Matter device must enter commissioning mode in one of the two scenarios
+described above. 
+
+Usually, a mobile phone serves as the administrator. Step 2 is to use the mobile phone to scan the QR code of the Matter device. The QR code is used as a passcode to set up a secured BLE connection.
+
+Step 3 is to set up the BLE beaconing and connection between the mobile phone and the Matter device, so that the commissioning information can be exchanged through the BLE connection channel. 
+
+As the connection should be secure, step 4 is to secure the connection in a process known as password-authenticated session establishment (**PACE**). The passcode derived from the QR code is used as an input for this process. The output is the security key used by the connection.
+
+![Steps 5-7](./images/CommissioningSteps5-7.png)
+
+After the secured connection is established, step 5 is to verify the Matter device's manufacturer certificate and compliance status. Each Matter device must have a device certificate programmed before it is shipped. The mobile phone, acting as administrator, reads the device certificate through the commissioning channel, then communicates with a remote database to validate the certificate and the compliance status of the device. The remote database is called the Distributed Compliance Ledger (**DCL**).
+
+Step 6 is to install the operational certificate for the device. The administrator either obtains the certificate from the remote server or generates the certificate locally and then transfers the certificate to the device. The administrator also configures the Access Control List (**ACL**) with the list of administrators.
+
+After operational security is configured, step 7 is to configure the operational network for the device. For Wi-Fi devices, the SSID and the password are configured. For Thread devices, the PAN ID, network key, and other parameters are configured. 
+
+![Steps 8-10](./images/CommissioningSteps8-10.png)
+
+In step 8, the device starts to join the operational network with the configured parameters. 
+
+Once the device is attached to the network (step 9), it can be discovered through Service Registration Protocol (**SRP**). To control that device, you must establish a secured connection through the Certification Authorized Session Establishment (**CASE**) process. 
+
+After the CASE session is established, the Matter device is commissioned successfully and can communicate with other devices in the Matter network (step 10).
+
+----
+[Table of Contents](../README.md) | [Thread Demo](../thread/DEMO_OVERVIEW.md) | [Wi-Fi Demo](../wifi/DEMO_OVERVIEW.md)

docs/silabs/general/COMMISSIONING.md

@@ -0,0 +1,85 @@
+# Matter Sleepy End Devices over OpenThread
+
+This page explains how Matter OpenThread Sleepy End devices (SEDs) work and how to configure an SED example.
+
+## Overview
+
+Matter provides a Sleepy End Device operating mode to extend the battery life of a power limited devices. This operating mode leverages OpenThread functionalities to enhance the provided Matter features. Matter Sleepy functionalities currently focus on allowing an application to define the interval of time where a device is asleep.
+
+## Operating Modes
+
+SEDs have two operating modes, Idle and Active.
+
+- _Active Mode_ sets the SED into a fast-polling interval for maximum responsiveness when the Node is engaged in ongoing communication, such as an active exchange. The SLEEPY_ACTIVE_INTERVAL parameter communicates the maximum sleep interval of a node in active mode.
+
+- _Idle mode_, or slow-polling, sets the maximum time an SED will sleep before polling. This parameter affects both the minimum power consumption and maximum latency. The SLEEPY_IDLE_INTERVAL parameter communicates the maximum sleep interval of a node in idle mode.
+
+A device determines if it is in Active or Idle mode based on whether it has at least one open exchange in the message layer. As long as the device has one open exchanges, it will remain in Active mode and poll its associated OpenThread router at the fast-polling interval. Once all exchanges are closed, the device will switch operating modes to Idle Mode.
+
+When a device is in _Idle mode_, it will poll its associated router at its slow-polling interval to see if another device has tried to communicate with it while it was sleeping. If the OpenThread router has an outstanding message for the SED, the SED will enter its Active polling mode to process the message.
+
+## Thread Communication
+
+To receive message that were sent while the SED was sleeping, SED relies on its associated Thread router to buffer any incoming message. The Thread router will send all buffered message to the SED when the SED polls the router at the end of its slow-polling interval.
+
+## Configuration
+
+Matter exposes two defines that can be set to configure the SLEEPY_ACTIVE_INTERVAL and SLEEPY_IDLE_INTERVAL parameters. 
+
+| Parameter Name | Define | Description | Default Value | Maximum allowed Value |
+| - | - | - | - | - |
+| SLEEPY_IDLE_INTERVAL | CHIP_DEVICE_CONFIG_SED_IDLE_INTERVAL | Maximum node sleep interval when in idle mode. | 5000 ms | <= 1 hour|
+| SLEEPY_ACTIVE_INTERVAL | CHIP_DEVICE_CONFIG_SED_ACTIVE_INTERVAL | Maximum node sleep interval of when in active mode. | 200 ms | <= 1 hour|
+
+### Usage
+
+The default values for the these defines are located in `src/include/platform/CHIPDeviceConfig.h`
+
+```c++
+/**
+ * CHIP_DEVICE_CONFIG_SED_IDLE_INTERVAL
+ *
+ * The default amount of time in milliseconds that the sleepy end device will use as an idle interval.
+ * This interval is used by the device to periodically wake up and poll the data in the idle mode.
+ */
+#ifndef CHIP_DEVICE_CONFIG_SED_IDLE_INTERVAL
+#define CHIP_DEVICE_CONFIG_SED_IDLE_INTERVAL 5000_ms32
+#endif
+
+/**
+ * CHIP_DEVICE_CONFIG_SED_ACTIVE_INTERVAL
+ *
+ * The default amount of time in milliseconds that the sleepy end device will use as an active interval.
+ * This interval is used by the device to periodically wake up and poll the data in the active mode.
+ */
+#ifndef CHIP_DEVICE_CONFIG_SED_ACTIVE_INTERVAL
+#define CHIP_DEVICE_CONFIG_SED_ACTIVE_INTERVAL 200_ms32
+#endif
+```
+To change these default values, add `#define CHIP_DEVICE_CONFIG_SED_ACTIVE_INTERVAL <value>_ms32` to `src/platform/EFR32/CHIPDevicePlatformConfig.h`.
+
+## Building 
+
+### Enabling Sleepy Functionalities
+
+To build an OpenThread SED example, two conditions must be met: 1) The following macro must be defined : `CHIP_DEVICE_CONFIG_ENABLE_SED` and 2) the example must to use the MTD OpenThread libraries to be able to leverage OpenThread Sleepy functionalities.
+
+The `--sed` macro can be added to the build command to enable sleepy functionalities. Here is an example to build the light-switch-app as a SED for the EFR32MG24 BRD4186C.
+
+```bash
+./scripts/examples/gn_efr32_example.sh ./examples/light-switch-app/efr32/ ./out/light-switch-app_SED BRD4186C --sed
+```
+
+### Minimal Power Consumption
+
+Simply enabling Sleepy functionalities does not give the application the best power consumption. Be default several features, like the LCD, are enabled in example applications that increase the power consumption. The following set of features increase power consumption.
+
+- Matter Shell
+- OpenThread CLI
+- LCD and Qr Code
+
+To achieve the most power-efficient build, add these build arguments to the build command to disable all power-consuming features.
+
+```bash
+./scripts/examples/gn_efr32_example.sh ./examples/light-switch-app/efr32/ ./out/light-switch-app_SED BRD4186C --sed chip_build_libshell=false enable_openthread_cli=false show_qr_code=false disable_lcd=true
+```

docs/silabs/general/OT_SLEEPY_END_DEVICE.md

@@ -0,0 +1,70 @@
+# Security
+
+## General
+
+Each Matter device gets two certificates. The first, the **device certificate**, is programmed by the manufacturer before the device is shipped. This will be used later for device attestation when trying to join the network. The other, the **operational certificate**, is assigned by the commissioner in the commissioning stage. Certificates natively use a CHIP TLV format but can convert to/from X.509 format. All devices are given an operational certificate to prove their authorization on the Matter network (fabric) and securely identify them.
+
+Communication between Matter devices is protected with different keys in different stages. At the commissioning stage, the key is a result of the Password Authenticated Session Establishment (**PASE**) process over the commissioning channel using the passcode from the device's QR code as the input. During this initial setup, verification of possession of the passcode by both commissioner and joining device is confirmed. At the operational stage, the key is a result of the Certificate Authenticated Session Establishment (**CASE**) process over the operational channel using the operational certificate as the input. These sessions are used during normal operation between controller and device to validate that both are part of the Matter network.
+
+### Principles - 
+
+1. **No anonymous joining** - Always requires “proof of ownership” (that is, a device-specific passcode)
+
+2. **Device Attestation** - Every device has unique identity that is authenticated by the manufacturer and verified through the CSA as a certified device
+
+3. **Operational Credentials** - When commissioned onto a Matter network every device is given unique operational credentials after verifying their manufacturer credentials
+
+4. **Network credentials are given only *after* device authentication** - Wi-Fi network key or Thread Master Key are not given until device’s certificate is verified
+
+5. **Open standard and open-source software** - Open to third parties vetting the claims by examining the standard and auditing the source code
+
+## Message Protection
+
+Various cryptographic algorithms are used to ensure communication security and integrity. These include: 
+
+- **Hashing Algorithm** - SHA\-256
+
+- **Message Authentication** - HMAC-SHA\-256
+
+- **Public Key** - ECC Curve NIST P\-256
+
+- **Message Encryption** - AES\-CCM (128 bit keys)
+
+![Payload Encryption](./images/PayloadEncryption.png)
+
+**Confidentiality** - Message payload is encrypted by the encryption key (AES)
+
+![Address Encryption](./images/AddressEncryption.png)
+
+**Privacy** - Addresses are encrypted by the privacy key 
+
+## Device Attestation
+
+Every device has a unique certificate that is signed by the manufacturer. There is no single root CA across all devices. During commissioning the device is challenged to prove possession of the associated private key. The certificate can be validated against the Distributed Compliance Ledger (**DCL**) to verify device certification status
+
+![Certificate Authentication](./images/CertificateAuthentication.png)
+
+The hierarchy allows for a 3-level tier:
+
+- The first level is the Product Attestation Authority (**PAA**)
+- The PAA will be used to sign the Product Attestation Intermediate (**PAI**)
+- The PAI will be used to sign the Device Attestation Certificate (**DAC**). The DAC will be transferred to the commissioner and verified against the DCL.
+
+![Attestation Overview](./images/AttestationOverview.png)
+
+DAC is retrieved and verified before the device joins the Thread or Wi-Fi network. The Commissioner issues a challenge to the device to prove it possesses the associated Private Key.
+
+## Distributed Compliance Ledger
+
+![DCL Overview](./images/DCL_Overview.png)
+
+DCL is a database of all certified products which includes:
+
+- Certification status
+- Product name / description / firmware URL
+- Product certificates
+
+Reading from the DCL is open to public, but writing to the DCL is restricted to various parties/roles. These roles typically include CSA certification, test house, and vendor roles.
+
+----
+[Table of Contents](../README.md) | [Thread Demo](../thread/DEMO_OVERVIEW.md) | [Wi-Fi Demo](../wifi/DEMO_OVERVIEW.md)