Matter: Window covering
This sample demonstrates the usage of the Matter application layer to build a window covering device. This device works as a Matter accessory device, meaning it can be paired and controlled remotely over a Matter network built on top of a low-power 802.15.4 Thread network. Additionally, this device works as a Thread Synchronized Sleepy End Device (SSED).
Use this sample as a reference for developing your own application. See the Adding clusters to Matter application page for an overview of the process you need to follow.
Requirements
The sample supports the following development kits:
Hardware platforms |
PCA |
Board name |
Board target |
---|---|---|---|
PCA10156 |
|
||
PCA10095 |
|
||
PCA10056 |
|
If you want to commission the window covering device and control it remotely through a Thread network, you also need a Matter controller device configured on PC or smartphone. This requires additional hardware depending on the setup you choose.
Note
Matter requires the GN tool. If you are updating from the nRF Connect SDK version earlier than v1.5.0, see the GN installation instructions.
Overview
The sample uses buttons for gradually changing the position and movement mode of the window cover, and LEDs to show the state of these changes. The following movement modes are available:
Lift - In this movement mode, the window cover moves up and down.
Tilt - In this movement mode, the window cover slats are tilted forward or backward without the cover moving vertically.
See User interface for information about how to switch the movement modes.
SSED device type
The SSED device type was created for the window covering devices to optimize the power usage of the device and communication pattern with the parent.
A Thread Synchronized Sleepy End Device (SSED) is synchronized with its parent router and uses the radio only at scheduled intervals, by using the Coordinated Sampled Listening (CSL) feature introduced as one of the Thread 1.2 Base Features. During those intervals, the device waits for the router to send it any data related to the desired device activity. The SSED does require sending packets occasionally to keep synchronization with the router. However, unlike a regular SED, an SSED does not actively communicate with the router by polling and goes into the idle mode between the scheduled activity periods. If there is no application-related traffic for an extended period of time, the SSED sends a data poll request packet to synchronize with the parent. Compared to a standard SED, the SSED features can further reduce energy consumption of the device and generate less data traffic.
See the Sleepy End Device types in Thread page for more information.
Sample testing
You can test the sample in the following ways:
Standalone, using a single DK that runs the window covering application.
Remotely over the Thread protocol, which requires more devices.
The remote control testing requires a Matter controller that you can configure either on a PC or mobile device (for remote testing in a network). You can enable both methods after building and running the sample.
Remote testing in a network
By default, the Matter accessory device has no IPv6 network configured. You must pair it with the Matter controller over Bluetooth® LE to get the configuration from the controller to use the device within a Thread or Wi-Fi network. The controller must get the Onboarding information from the Matter accessory device and provision the device into the network. For details, see the Commissioning the device section.
Configuration
See Configuring and building for information about how to permanently or temporarily change the configuration.
Matter window covering custom configurations
The sample uses a prj.conf
configuration file located in the sample root directory for the default configuration.
It also provides additional files for different custom configurations.
When you build the sample, you can select one of these configurations using the FILE_SUFFIX variable.
See Custom configurations and Providing CMake options for more information.
The sample supports the following configurations:
Configuration |
File name |
FILE_SUFFIX |
Supported board |
Description |
---|---|---|---|---|
Debug (default) |
|
No suffix |
All from Requirements |
Debug version of the application. Enables additional features for verifying the application behavior, such as logs. |
Release |
|
|
All from Requirements |
Release version of the application. Enables only the necessary application functionalities to optimize its performance. |
Matter window covering with Trusted Firmware-M
The sample supports using Trusted Firmware-M on the nRF54L15 DK. The memory map of the sample has been aligned to meet the TF-M partition alignment requirements.
You can build the sample with Trusted Firmware-M support by adding the ns
suffix to the nrf54l15dk/nrf54l15/cpuapp
board target.
For example:
west build -p -b nrf54l15dk/nrf54l15/cpuapp/ns
Note
The firmware built for nrf54l15dk/nrf54l15/cpuapp/ns
will not work on the nRF54L15 PDK.
Device Firmware Upgrade support
Note
You can enable over-the-air Device Firmware Upgrade only on hardware platforms that have external flash memory. Currently only nRF52840 DK, nRF5340 DK, nRF7002 DK and nRF54L15 DK support Device Firmware Upgrade feature.
The sample supports over-the-air (OTA) device firmware upgrade (DFU) using one of the two following protocols:
Matter OTA update protocol that uses the Matter operational network for querying and downloading a new firmware image.
Simple Management Protocol (SMP) over Bluetooth® LE. In this case, the DFU can be done either using a smartphone application or a PC command line tool. Note that this protocol is not part of the Matter specification.
In both cases, MCUboot secure bootloader is used to apply the new firmware image.
The DFU over Matter is enabled by default. The following configuration arguments are available during the build process for configuring DFU:
To configure the sample to support the DFU over Matter and SMP, use the
-DCONFIG_CHIP_DFU_OVER_BT_SMP=y
build flag.
See Providing CMake options for instructions on how to add these options to your build.
When building on the command line, run the following command with board_target replaced with the board target name of the hardware platform you are using (see Requirements), and dfu_build_flag replaced with the desired DFU build flag:
west build -b board_target -- dfu_build_flag
For example:
west build -b nrf52840dk/nrf52840 -- -DCONFIG_CHIP_DFU_OVER_BT_SMP=y
FEM support
You can add support for the nRF21540 front-end module to this sample by using one of the following options, depending on your hardware:
Build the sample for one board that contains the nRF21540 FEM, such as nrf21540dk/nrf52840.
Manually create a devicetree overlay file that describes how the nRF21540 FEM is connected to the SoC. See Configuring devicetree for different ways of adding the overlay file.
Provide nRF21540 FEM capabilities by using a shield, for example the nRF21540 EK shield that is available in the nRF Connect SDK. In this case, build the project for a board connected to the shield you are using with an appropriate variable included in the build command, for example
-DSHIELD=nrf21540ek
. This variable instructs the build system to append the appropriate devicetree overlay file.To build the sample in the nRF Connect for VS Code extension for an nRF52840 DK with the nRF21540 EK attached, add the shield variable in the build configuration’s Extra CMake arguments and rebuild the build configuration. For example:
-DSHIELD=nrf21540ek
.See How to work with build configurations in the nRF Connect for VS Code extension documentation for more information.
To build the sample from the command line for an nRF52840 DK with the nRF21540 EK attached, use the following command within the sample directory:
west build -b nrf52840dk/nrf52840 -- -DSHIELD=nrf21540ek
See Programming nRF21540 EK for information about how to program when you are using a board with a network core, for example the nRF5340 DK.
Each of these options adds the description of the nRF21540 FEM to the devicetree. See Developing with Front-End Modules for more information about FEM in the nRF Connect SDK.
To add support for other front-end modules, add the respective devicetree file entries to the board devicetree file or the devicetree overlay file.
Factory data support
In this sample, the factory data support is enabled by default for all configurations except for the target board nRF21540 DK. This means that a new factory data set will be automatically generated when building for the target board.
To disable factory data support, set the following Kconfig options to n
:
SB_CONFIG_MATTER_FACTORY_DATA_GENERATE
To learn more about factory data, read the Configuring factory data for the nRF Connect examples page in the Matter documentation.
User interface
- LED 1:
Shows the overall state of the device and its connectivity. The following states are possible:
Short Flash On (50 ms on/950 ms off) - The device is in the unprovisioned (unpaired) state and is waiting for a commissioning application to connect.
Rapid Even Flashing (100 ms on/100 ms off) - The device is in the unprovisioned state and a commissioning application is connected over Bluetooth LE.
Solid On - The device is fully provisioned.
- LED 2:
Indicates the lift position of the window cover, which is represented by the brightness of the LED. The brightness level ranges from
0
to255
, where the brightness level set to0
(switched off LED) indicates a fully opened window cover (lifted) and the brightness level set to255
indicates a fully closed window cover (lowered).Additionally, the LED starts blinking evenly (500 ms on/500 ms off) when the Identify command of the Identify cluster is received on the endpoint
1
. The command’s argument can be used to specify the duration of the effect.- LED 3:
Indicates the tilt position of the window cover, which is represented by the brightness of the LED. The brightness level ranges from
0
to255
, where the brightness level set to0
(switched off LED) indicates a fully opened window cover (tilted to a horizontal position) and the brightness level set to255
indicates a fully closed window cover (tilted to a vertical position).- Button 1:
Depending on how long you press the button:
If pressed for less than three seconds:
If the device is not provisioned to the Matter network, it initiates the SMP server (Simple Management Protocol) and Bluetooth LE advertising for Matter commissioning. After that, the Device Firmware Update (DFU) over Bluetooth Low Energy can be started. (See Upgrading the device firmware.) Bluetooth LE advertising makes the device discoverable over Bluetooth LE for the predefined period of time (1 hour by default).
If the device is already provisioned to the Matter network, it re-enables the SMP server. After that, the DFU over Bluetooth Low Energy can be started. (See Upgrading the device firmware.)
If pressed for more than three seconds, it initiates the factory reset of the device. Releasing the button within a 3-second window of the initiation cancels the factory reset procedure.
- Button 2:
When pressed once and released, it moves the window cover towards the open position by one step. Depending on the movement mode of the cover (see Overview), the button decreases the brightness of either LED 2 for the lift mode or LED 3 for the tilt mode.
- Button 3:
When pressed once and released, it moves the cover towards the closed position by one step. Depending on the movement mode of the cover (see Overview), the button increases the brightness of either LED 2 for the lift mode or LED 3 for the tilt mode.
- Button 2 and Button 3:
When pressed at the same time, they toggle the cover movement mode between lift and tilt. After each device reset, the mode is set to lift by default.
- SEGGER J-Link USB Port:
Used for getting logs from the device or for communicating with it through the command-line interface.
- NFC port with antenna attached:
Optionally used for obtaining the Onboarding information from the Matter accessory device to start the commissioning procedure.
- LED 0:
Shows the overall state of the device and its connectivity. The following states are possible:
Short Flash On (50 ms on/950 ms off) - The device is in the unprovisioned (unpaired) state and is waiting for a commissioning application to connect.
Rapid Even Flashing (100 ms on/100 ms off) - The device is in the unprovisioned state and a commissioning application is connected over Bluetooth LE.
Solid On - The device is fully provisioned.
- LED 1:
Indicates the lift position of the window cover, which is represented by the brightness of the LED. The brightness level ranges from
0
to255
, where the brightness level set to0
(switched off LED) indicates a fully opened window cover (lifted) and the brightness level set to255
indicates a fully closed window cover (lowered).Additionally, the LED starts blinking evenly (500 ms on/500 ms off) when the Identify command of the Identify cluster is received on the endpoint
1
. The command’s argument can be used to specify the duration of the effect.- LED 3:
Indicates the tilt position of the window cover, which is represented by the brightness of the LED. The brightness level ranges from
0
to255
, where the brightness level set to0
(switched off LED) indicates a fully opened window cover (tilted to a horizontal position) and the brightness level set to255
indicates a fully closed window cover (tilted to a vertical position).- Button 0:
Depending on how long you press the button:
If pressed for less than three seconds:
If the device is not provisioned to the Matter network, it initiates the SMP server (Simple Management Protocol) and Bluetooth LE advertising for Matter commissioning. After that, the Device Firmware Update (DFU) over Bluetooth Low Energy can be started. (See Upgrading the device firmware.) Bluetooth LE advertising makes the device discoverable over Bluetooth LE for the predefined period of time (1 hour by default).
If the device is already provisioned to the Matter network, it re-enables the SMP server. After that, the DFU over Bluetooth Low Energy can be started. (See Upgrading the device firmware.)
If pressed for more than three seconds, it initiates the factory reset of the device. Releasing the button within a 3-second window of the initiation cancels the factory reset procedure.
- Button 1:
When pressed once and released, it moves the window cover towards the open position by one step. Depending on the movement mode of the cover (see Overview), the button decreases the brightness of either LED 1 for the lift mode or LED 3 for the tilt mode.
- Button 2:
When pressed once and released, it moves the cover towards the closed position by one step. Depending on the movement mode of the cover (see Overview), the button increases the brightness of either LED 1 for the lift mode or LED 3 for the tilt mode.
- Button 1 and Button 2:
When pressed at the same time, they toggle the cover movement mode between lift and tilt. After each device reset, the mode is set to lift by default.
- SEGGER J-Link USB Port:
Used for getting logs from the device or for communicating with it through the command-line interface.
- NFC port with antenna attached:
Optionally used for obtaining the Onboarding information from the Matter accessory device to start the commissioning procedure.
Note
Completely opening and closing the cover requires 20 button presses (steps). Each step takes approximately 200 ms to simulate the real window cover movement.
The cover position and the LED brightness values are stored in non-volatile memory and are restored after every device reset. After the firmware update or factory reset both LEDs are switched off by default, which corresponds to the cover being fully open, both lift-wise and tilt-wise.
Building and running
This sample can be found under samples/matter/window_covering
in the nRF Connect SDK folder structure.
To build the sample, follow the instructions in Building an application for your preferred building environment. See also Programming an application for programming steps and Testing and optimization for general information about testing and debugging in the nRF Connect SDK.
Note
When building repository applications in the SDK repositories, building with sysbuild is enabled by default.
If you work with out-of-tree freestanding applications, you need to manually pass the --sysbuild
parameter to every build command or configure west to always use it.
Selecting a configuration
Before you start testing the application, you can select one of the Matter window covering custom configurations. See Custom configurations and Providing CMake options for more information how to select a configuration.
Testing
After building the sample and programming it to your development kit, complete the following steps to test its basic features:
Connect the kit to the computer using a USB cable. The kit is assigned a COM port (Windows) or ttyACM device (Linux), which is visible in the Device Manager.
Open a serial port connection to the kit using a terminal emulator that supports VT100/ANSI escape characters (for example, nRF Connect Serial Terminal). See Testing and optimization for the required settings and steps.
Observe that LED 2 and LED 3 are turned off, which means that the window cover is fully open.
The device starts in the lift movement mode by default.
Press Button 3 20 times to fully close the cover in the lift movement mode.
LED 2 lights up and its brightness increases with each button press until it reaches full brightness.
Press Button 2 20 times to fully lift the cover up.
The brightness of LED 2 decreases with each button press until the LED turns off.
Press Button 2 and Button 3 together to switch into the tilt movement mode.
Press Button 3 20 times to fully tilt the cover into the closed position.
LED 3 light up and its brightness increases with each button press until it reaches full brightness.
Press Button 2 20 times to fully tilt the cover into the open position.
The brightness of LED 3 decreases with each button press until the LED turns off.
Keep Button 1 pressed for more than six seconds to initiate factory reset of the device.
The device reboots after all its settings are erased.
Connect the kit to the computer using a USB cable. The kit is assigned a COM port (Windows) or ttyACM device (Linux), which is visible in the Device Manager.
Open a serial port connection to the kit using a terminal emulator that supports VT100/ANSI escape characters (for example, nRF Connect Serial Terminal). See Testing and optimization for the required settings and steps.
Observe that LED 1 and LED 3 are turned off, which means that the window cover is fully open.
The device starts in the lift movement mode by default.
Press Button 2 20 times to fully close the cover in the lift movement mode.
LED 1 lights up and its brightness increases with each button press until it reaches full brightness.
Press Button 1 20 times to fully lift the cover up.
The brightness of LED 1 decreases with each button press until the LED turns off.
Press Button 1 and Button 2 together to switch into the tilt movement mode.
Press Button 2 20 times to fully tilt the cover into the closed position.
LED 3 light up and its brightness increases with each button press until it reaches full brightness.
Press Button 1 20 times to fully tilt the cover into the open position.
The brightness of LED 3 decreases with each button press until the LED turns off.
Keep Button 0 pressed for more than six seconds to initiate factory reset of the device.
The device reboots after all its settings are erased.
Enabling remote control
Remote control allows you to control the Matter window covering device from a Thread network.
Commissioning the device allows you to set up a testing environment and remotely control the sample over a Matter-enabled Thread network.
Commissioning the device
To commission the device, go to the Testing Matter in the nRF Connect SDK page and complete the steps for the Matter over Thread or Matter over Wi-Fi development environment and the Matter controller you want to use. After choosing the environment configuration, the guide walks you through the following steps:
Configure the Thread Border Router (only for Matter over Thread communication).
Build and install the Matter controller.
Commission the device.
Send Matter commands that cover scenarios described in the Testing section.
If you are new to Matter, the recommended approach is to use CHIP Tool for Linux or macOS.
Before starting the commissioning procedure, the device must be made discoverable over Bluetooth LE. The device becomes discoverable automatically upon the device startup, but only for a predefined period of time (1 hour by default). If the Bluetooth LE advertising times out, enable it again.
Onboarding information
When you start the commissioning procedure, the controller must get the onboarding information from the Matter accessory device. The onboarding information representation depends on your commissioner setup.
For this sample, you can use one of the following onboarding information formats to provide the commissioner with the data payload that includes the device discriminator and the setup PIN code:
QR Code
QR Code Payload
Manual pairing code
Scan the following QR code with the app for your ecosystem:
MT:SAGA442C00KA0648G00
34970112332
When the factory data support is enabled, the onboarding information will be stored in the build directory in the following files:
The
factory_data.png
file includes the generated QR code.The
factory_data.txt
file includes the QR Code Payload and the manual pairing code.
This data payload also includes test Device Attestation, with test Certification Declaration, Product ID, and Vendor ID. These are used for Device Attestation within commissioning, and you can generate your own test Certification Declaration when you work on Matter end product.
Upgrading the device firmware
To upgrade the device firmware, complete the steps listed for the selected method in the Performing Device Firmware Upgrade in the nRF Connect examples tutorial of the Matter documentation.
Dependencies
This sample uses the Matter library that includes the nRF Connect SDK platform integration layer:
In addition, the sample uses the following nRF Connect SDK components:
The sample depends on the following Zephyr libraries: