Matter: Template

This sample demonstrates a minimal implementation of the Matter (formerly Project Connected Home over IP, Project CHIP) application layer. This basic implementation enables the commissioning on the device, which allows it to join a Matter network.

Use this sample as a reference for developing your own application. See the Creating Matter device page for an overview of the process you need to follow.

Requirements

The sample supports the following development kits:

Hardware platforms

PCA

Board name

Build target

nRF52840 DK

PCA10056

nrf52840dk_nrf52840

nrf52840dk_nrf52840

nRF5340 DK

PCA10095

nrf5340dk_nrf5340

nrf5340dk_nrf5340_cpuapp

nRF21540 DK

PCA10112

nrf21540dk_nrf52840

nrf21540dk_nrf52840

For testing purposes, that is to commission the 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 starts the Bluetooth® LE advertising automatically and prepares the Matter device for commissioning into a Matter-enabled Thread network. The sample uses an LED to show the state of the connection. You can press a button to start the factory reset when needed.

Remote testing in a network

Testing in a Matter-enabled Thread network requires a Matter controller that you can configure either on a PC or a mobile device. By default, the Matter accessory device has Thread disabled. To use the device within a Thread network, you must pair it with the Matter controller over Bluetooth LE to get the configuration from the controller. You can enable the controller after building and running the sample.

To pair the device, the controller must get the commissioning information from the Matter accessory device and provision the device into the network.

Commissioning in Matter

In Matter, the commissioning procedure takes place over Bluetooth LE between a Matter accessory device and the Matter controller, where the controller has the commissioner role. When the procedure has completed, the device is equipped with all information needed to securely operate in the Matter network.

During the last part of the commissioning procedure (the provisioning operation), the Matter controller sends the Thread network credentials to the Matter accessory device. As a result, the device can join the Thread network and communicate with other Thread devices in the network.

To start the commissioning procedure, the controller must get the commissioning information from the Matter accessory device. The data payload includes the device discriminator and setup PIN code. The payload is encoded within a QR code, printed to the UART console.

Configuration

See Configuring your application for information about how to permanently or temporarily change the configuration.

Matter template build types

The sample uses different configuration files depending on the supported features. Configuration files are provided for different build types and they are located in the configuration/<board_name> directory.

The prj.conf file represents a debug build type. Other build types are covered by dedicated files with the build type added as a suffix to the prj part, as per the following list. For example, the release build type file name is prj_release.conf. If a board has other configuration files, for example associated with partition layout or child image configuration, these follow the same pattern.

Before you start testing the application, you can select one of the build types supported by the sample. This sample supports the following build types, depending on the selected board:

  • debug – Debug version of the application - can be used to enable additional features for verifying the application behavior, such as logs or command-line shell.

  • release – Release version of the application - can be used to enable only the necessary application functionalities to optimize its performance.

  • no_dfu – Debug version of the application without Device Firmware Upgrade feature support - can be used only for the nRF52840 DK and nRF5340 DK, as those platforms have DFU enabled by default.

Note

Selecting a build type is optional. The debug build type is used by default if no build type is explicitly selected.

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 and nRF5340 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. To configure the sample to support the DFU over Matter and SMP, use the -DOVERLAY_CONFIG=../../overlay-smp_dfu.conf build flag during the build process. To configure the sample to disable the DFU and the secure bootloader, use the -DCONF_FILE=prj_no_dfu.conf build flag during the build process.

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 build_target replaced with the build 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 build_target -- dfu_build_flag

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 FEM is connected to the nRF5 SoC in your device. See Set devicetree overlays 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. This variable instructs the build system to append the appropriate devicetree overlay file. For example, to build the sample from the command line for an nRF52833 DK with the nRF21540 EK attached, use the following command within the sample directory:

    west build -b nrf52833dk_nrf52833 -- -DSHIELD=nrf21540_ek

    This command builds the application firmware. See Programming nRF21540 EK for information about how to program when you are using a board with a network core, for example nRF5340 DK.

Each of these options adds the description of the nRF21540 FEM to the devicetree. See Working with RF 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.

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.

Button 1:

If pressed for six seconds, it initiates the factory reset of the device. Releasing the button within the six-second window cancels the factory reset procedure.

SEGGER J-Link USB port:

Used for getting logs from the device or for communicating with it through the command-line interface.

Building and running

This sample can be found under samples/matter/template in the nRF Connect SDK folder structure.

See Building and programming an application for information about how to build and program the application.

Selecting a build type

Before you start testing the application, you can select one of the Matter template build types, depending on your building method.

Selecting a build type in nRF Connect for Visual Studio Code

To select the build type in the nRF Connect for Visual Studio Code extension:

  1. When Building an application as described in the nRF Connect for Visual Studio Code extension documentation, follow the steps for setting up the build configuration.

  2. In the Add Build Configuration screen, select the desired .conf file from the Configuration drop-down menu.

  3. Fill in other configuration options, if applicable, and click Build Configuration.

Selecting a build type from command line

To select the build type when building the application from command line, specify the build type by adding the following parameter to the west build command:

-- -DCONF_FILE=prj_selected_build_type.conf

For example, you can replace the selected_build_type variable to build the release firmware for nrf52840dk_nrf52840 by running the following command in the project directory:

west build -b nrf52840dk_nrf52840 -d build_nrf52840dk_nrf52840 -- -DCONF_FILE=prj_release.conf

The build_nrf52840dk_nrf52840 parameter specifies the output directory for the build files.

Note

If the selected board does not support the selected build type, the build is interrupted. For example, if the shell build type is not supported by the selected board, the following notification appears:

File not found: ./ncs/nrf/samples/matter/template/configuration/nrf52840dk_nrf52840/prj_shell.conf

Testing

When you have built the sample and programmed it to your development kit, it automatically starts the Bluetooth LE advertising and the LED1 starts flashing (Short Flash On). At this point, you can press Button 1 for six seconds to initiate the factory reset of the device.

Note

If you are new to Matter, commission the Matter device using the Android Mobile Controller when setting up the Matter development environment.

Testing in a network

To test the sample in a Matter-enabled Thread network, complete the following steps:

  1. 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.

  2. Connect to the kit with a terminal emulator that supports VT100/ANSI escape characters (for example, PuTTY). See How to connect with PuTTY for the required settings.

  3. Commission the device into a Thread network by following the guides linked on the Configuring Matter page for the Matter controller you want to use. The guides walk you through the following steps:

    • Configure Thread Border Router.

    • Build and install the Matter controller.

    • Commission the device.

    • Send Matter commands.

    At the end of this procedure, LED 1 of the Matter device programmed with the sample starts flashing in the Short Flash Off state. This indicates that the device is fully provisioned, but does not yet have full Thread network connectivity.

  4. Press Button 1 for six seconds to initiate the factory reset of the device.

The device reboots after all its settings are erased.

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: