forked from project-chip/connectedhomeip
-
Notifications
You must be signed in to change notification settings - Fork 0
Commit
This commit does not belong to any branch on this repository, and may belong to a fork outside of the repository.
Pull request #243: Cherry-Pick "Doc updates v1.0.0" from silabs to si…
…labs_1.0 Merge in WMN_TOOLS/matter from cherry-pick/doc_updates_v1.0.0 to silabs_1.0 Squashed commit of the following: commit 78067c25ba6423ccc81b612b3aa0b49755039bf7 Author: Ezra Hale <[email protected]> Date: Fri Oct 28 20:01:49 2022 +0000 Pull request #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 <[email protected]> Date: Fri Oct 28 14:10:14 2022 -0400 fixed typos on board names commit 55c9e89b5f006bab627120b2e5b466ba06e9792f Author: Ezra Hale <[email protected]> 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 <[email protected]> Date: Fri Oct 28 12:13:03 2022 -0400 review of silabs_examples documentation ... and 14 more commits Conflicts: .vscode/tasks.json (resolved by overwriting with our changes as we maintain this file now)
- Loading branch information
Showing
29 changed files
with
695 additions
and
179 deletions.
There are no files selected for viewing
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -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. | ||
|
|
||
|  | ||
|
|
||
| ### 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) |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -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. | ||
|
|
||
|  | ||
|
|
||
| ## Example Commissioning Flow | ||
|
|
||
|  | ||
|
|
||
| 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. | ||
|
|
||
|  | ||
|
|
||
| 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. | ||
|
|
||
|  | ||
|
|
||
| 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) |
This file contains bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -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 | ||
| ``` |
Oops, something went wrong.