Matter: Temperature Sensor
This sample demonstrates how to use the Matter application layer to build a device capable of measuring temperature.
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 and works as a Minimal Thread Device (MTD) in a Sleepy End Device (SED) variant. Additionally, it works as Matter Intermittently Connected Device (ICD) with a Short Idle Time (SIT) and Long Idle Time (LIT)
You can use this sample as a reference for creating 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 |
|
|---|---|---|---|
PCA10184 |
|
||
PCA20072 |
|
||
PCA10156 |
|
||
PCA10095 |
|
||
PCA10056 |
|
If you want to commission the Temperature Sensor device and control it remotely through a Thread network, you need to set-up the Thread Border Router and control it with the chip-tool, or use a commercial ecosystem controller. When this happens, you will also be able to control it through 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.
IPv6 network support
The following development kits for this sample offer IPv6 network support for Matter over Thread:
nrf52840dk/nrf52840,nrf5340dk/nrf5340/cpuapp,nrf54l15dk/nrf54l15/cpuapp,nrf54l15tag/nrf54l15/cpuapp,nrf54lm20dk/nrf54lm20b/cpuappandnrf54lm20dk/nrf54lm20a/cpuappboard targets.
Overview
The sample uses a real temperature measurement only on the nRF54L15 TAG due to hardware limitations. On other targets, it simulates temperature measurement following the linearly increasing values from –10 to +30 Celsius degrees. The measurement results are updated every 10 s and after reaching the maximum value, the temperature drops to the minimum and starts to increase from the beginning.
You can test the device remotely over a Thread network, which requires more devices.
The remote control testing requires a Matter controller that you can configure either on a PC or a mobile device.
Testing with the Matter Quick Start app
The Temperature Sensor sample is available in the Matter Quick Start app desktop application. Use this app to enable fast and easy evaluation of the sample without compiling it or setting the development environment thanks to the pre-compiled hex files. After flashing, follow the step-by-step instructions to commission the sample to the Matter network and interact with commercial ecosystems.
Download the Matter Quick Start app from the nRF Connect for Desktop application.
Temperature Sensor features
This sample implements the following features:
ICD LIT - The temperature sensor can be used as an Intermittently Connected Device (ICD) with a Long Idle Time (LIT).
Use the click to show toggle to expand the content.
ICD LIT device type
The device works as a Matter Intermittently Connected Device (ICD) with a Long Idle Time (LIT). The device starts operation in the Short Idle Time (SIT) mode and remains in it until it is commissioned to the Matter fabric and registers the first ICD client. It then switches the operation mode to LIT to reduce the power consumption.
In the LIT mode, the device is less responsive than in the SIT mode. However, you can request the device to become responsive, for example, to change its configuration. Press the Third Button to use the User Active Mode Trigger (UAT) feature.
See the User interface section for information on how to switch the operation modes.
Configuration
This section describes the configuration options for the sample.
See Configuring and building for information about how to permanently or temporarily change the configuration.
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.
Note
If you are working with multiple devices, set a unique discriminator for each one, or commission them one at a time. See Matter device identification for more information.
The sample supports the following build 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. |
Internal memory only |
— |
|
nRF54LM20 DK |
Debug version of the application with external flash disabled. Enables the Temperature Sensor to work using internal memory only. |
Advanced configuration options
This section describes advanced configuration options that you can apply in this sample.
Use the click to show toggle to expand the content.
Device firmware upgrade support
The sample supports device firmware upgrade (DFU) over-the-air (OTA) using the 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. This protocol is not part of the Matter specification.
In both cases, the MCUboot secure bootloader is used to apply the new firmware image.
The DFU over Matter is enabled by default.
Additionally, you can enable the DFU over SMP by using 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.
The following platforms require external flash memory to perform the DFU:
nRF52840 DK
nRF5340 DK
nRF54L10 DK
You can run DFU without external flash memory on the nRF54L15 and nRF54LM20 DKs using the MCUboot image compression feature.
To see if the sample supports this feature, check whether the internal build configuration is available in the build configuration table.
When building with nRF Connect for VS Code, add your desired dfu_build_flag to Extra CMake arguments.
For example add -DCONFIG_CHIP_DFU_OVER_BT_SMP=y to enable DFU over BT SMP.
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 nrf54l15dk/nrf54l15/cpuapp -- -DCONFIG_CHIP_DFU_OVER_BT_SMP=y
Factory data support
In this sample, factory data support specific to the nRF Connect SDK is enabled by default for all configurations. 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:
To learn more about factory data, read the Factory provisioning in Matter user guide.
Custom board with Nordic SoC
To prepare the sample to work with a custom board, complete the following steps:
Refer to the Create your board directory Zephyr guide and create your board directory.
Modify the contents of the
board.yamlfile according to the Write your board YAML user guide.Update the Write your devicetree (all .dts and .dtsi files) to match your board’s requirements.
Write Kconfig files to enable all required Kconfig options for your board.
If you want to build your custom board with nRF70 Wi-Fi support, set the
CONFIG_CHIP_WIFIandSB_CONFIG_WIFI_NRF70Kconfig options toy.If your device uses external flash, add its devicetree definition under the
board/<board_name>_<soc_name>.overlayfile, and setnordic,pm-ext-flashin the devicetree’schosenconfiguration.Refer to the Advanced Matter Kconfig options user guide, create your list of advanced configurations for your board, and apply the selected Kconfig options in the
prj.conffile.See the list of threads used in Matter application and adjust stack sizes according to your board and project requirements.
A custom board does not have support for LEDs and buttons by default. Therefore, you need to provide your own implementation of the
nrf/samples/matter/common/src/board/board.cppboard file.
For more information, see the following guides:
Board Porting Guide and Custom Board, Devicetree and SOC Definitions to learn how to create a custom board directory.
Optimizing memory usage in Matter applications to learn how to optimize memory on your board.
Advanced Matter Kconfig options to learn about Matter configuration.
Matter hardware and memory requirements to learn about hardware requirements for Nordic Development Kits and to use as a reference when planning your custom board.
Internal memory only
For the nRF54LM20 DK, you can configure the sample to use only the internal RRAM for storage. It applies to the DFU as well, which means that both the currently running firmware and the new firmware to be updated will be stored within the device’s internal RRAM memory.
The DFU image fits in the internal flash memory if you use MCUboot image compression.
This configuration is disabled by default for the Matter Temperature Sensor sample.
To enable it, set the FILE_SUFFIX CMake option to internal.
To build the sample for the nRF54LM20 DK with support for Matter OTA DFU and DFU over Bluetooth SMP, and using internal RRAM only:
Add -DCONFIG_CHIP_DFU_OVER_BT_SMP=y -DFILE_SUFFIX=internal to Extra CMake arguments in your build configuration.
west build -p -b nrf54lm20dk/nrf54lm20b/cpuapp -- -DCONFIG_CHIP_DFU_OVER_BT_SMP=y -DFILE_SUFFIX=internal
To build the sample for the same purpose in the release configuration:
Add -DCONFIG_CHIP_DFU_OVER_BT_SMP=y -DFILE_SUFFIX=internal -D<sample_name>_EXTRA_CONF_FILE=prj_release.conf to Extra CMake arguments in your build configuration, replacing <sample_name> with the actual sample name (for example light_bulb or matter_bridge).
Replace <sample_name> with the actual sample name and run:
west build -p -b nrf54lm20dk/nrf54lm20b/cpuapp -- -DCONFIG_CHIP_DFU_OVER_BT_SMP=y -DFILE_SUFFIX=internal -D<sample_name>_EXTRA_CONF_FILE=prj_release.conf
In this case, the size of the MCUboot secondary partition used for storing the new application image is approximately 30-40% smaller than it would be when using a configuration with external flash memory support.
User interface
This section describes the user interface available on the development kit in this sample.
Development kit interface
This sample implements the following interface available on a development kit. While reading the names, refer to the Buttons and LEDs map.
- First LED:
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.
- Second LED:
The LED starts blinking evenly (500 ms on/500 ms off) when the
Identifycommand of the Identify cluster is received on the endpoint1. You can use the command’s argument to specify the duration of the effect.
- First Button:
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 Simple Management Protocol (SMP) server and Bluetooth LE advertising for Matter commissioning. After that, the Device Firmware Update (DFU) over Bluetooth Low Energy can be started. 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.
If pressed for more than three seconds, it initiates the factory reset of the device. Releasing the button within three seconds of the initiation cancels the factory reset procedure.
- Third Button:
Functions as the User Active Mode Trigger (UAT) button. For more information about Intermittently Connected Devices (ICD) and User Active Mode Trigger, see the Enable Matter Intermittently Connected Devices support documentation section.
- 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 the device procedure while using a commercial ecosystem. See the Testing with commercial ecosystem section.
- First Button:
Depending on how long you press the button:
If pressed for less than 1.5 seconds:
If the device is not provisioned to the Matter network, it initiates the Simple Management Protocol (SMP) server and Bluetooth LE advertising for Matter commissioning. After that, the Device Firmware Update (DFU) over Bluetooth Low Energy can be started. 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.
If pressed for more than 1.5 seconds, but less than 3 seconds (indicated by rapidly blinking white LED), it functions as the User Active Mode Trigger (UAT) button. For more information about Intermittently Connected Devices (ICD) and User Active Mode Trigger, see the Enable Matter Intermittently Connected Devices support documentation section.
If pressed for more than three seconds, it initiates the factory reset of the device. Releasing the button within three seconds of the initiation cancels the factory reset procedure.
Building and running
This section describes how to build the sample and commission it to the Matter network.
This sample can be found under samples/matter/temperature_sensor 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.
When building this sample with Sysbuild for an SoC that has a network core, the IPC radio firmware is automatically applied to the build.
The IPC radio is one of the companion components in the nRF Connect SDK and allows to use the radio peripheral from another core in a multicore device.
If needed, you can modify the IPC radio configuration in the prj.conf source file in the sample’s sysbuild/ipc_radio directory.
Before starting the commissioning procedure, make sure that the device is discoverable over Bluetooth LE. The device becomes discoverable automatically upon the device startup, but only for a predefined period of time (one hour by default). If the Bluetooth LE advertising times out, enable it again.
Testing
This section shows how to test the sample. You can test it using your PC and the CHIP Tool for Linux or macOS or commercial ecosystem that supports Matter.
Testing with CHIP Tool
Complete the following steps to test the Temperature Sensor device using CHIP Tool:
Prepare Matter network
To set up the Matter over Thread, complete the following steps:
Configure the Thread Border Router. See the Running OTBR using Docker section on the Thread Border Router page.
Download the prebuilt CHIP tool package from the Matter nRF Connect releases GitHub page. Make sure that the package is compatible with your nRF Connect SDK version.
Prepare your DK
To flash your DK with the sample and prepare it for testing, complete the following steps:
Connect the kit to the computer using a USB cable. The kit is assigned a serial port. Serial ports are referred to as COM ports on Windows, /dev/ttyACM devices on Linux, and /dev/tty devices on macOS. To list Nordic Semiconductor devices connected to your computer together with their serial ports, open a terminal and run the
nrfutil device listcommand. Alternatively, check your operating system’s device manager or its equivalent.Open a serial port connection to the kit using a terminal emulator that supports VT100/ANSI escape characters (for example, the Serial Terminal app). See Testing and optimization for the required settings and steps.
If the device was not erased during the programming, perform the factory reset procedure.
To restore the device settings and state to its factory set press the First Button for six seconds to initiate the factory reset of the device.
Commission to Matter network
To commission the device to the Matter network complete the following steps:
Obtain a Thread active dataset from OTBR:
Connect to the Raspberry Pi through USB or SSH.
Run the following commands:
sudo ot-ctl > dataset active -x
Run the following command:
sudo docker exec -it otbr sh -c "ot-ctl dataset active -x"The output should look like:
080000000000000000000300001735060004001fffe00208deadbeefcafe12340708fd123456789abc00000510112233445566778899aabbccddeeff00030a54657374576f726b3031010211220410aabbccddeeff00112233445566778899aa0c0402a0f7f8 Done
Run the following command and fill the <thread dataset> argument obtain in the previous step:
chip-tool pairing ble-thread 1 hex:<thread dataset> 20202021 3840
Read the simulated temperature
To read the simulated temperature, run the following command:
chip-tool temperaturemeasurement read measured-value 1 1
The received output will look similar to the following:
[1755081048.320] [99348:99350] [TOO] Endpoint: 1 Cluster: 0x0000_0402 Attribute 0x0000_0000 DataVersion: 1994139940
[1755081048.320] [99348:99350] [TOO] MeasuredValue: 9
Read the temperature again
Wait some time, for example 30 s, and read the measured temperature again using the same command as before:
chip-tool temperaturemeasurement read measured-value 1 1
The received value will be different, for example:
[1755081048.320] [99348:99350] [TOO] Endpoint: 1 Cluster: 0x0000_0402 Attribute 0x0000_0000 DataVersion: 1994139940
[1755081048.320] [99348:99350] [TOO] MeasuredValue: 1200
Testing with commercial ecosystem
Before starting testing, ensure that the ecosystem supports the device types enabled in this sample. See the ecosystem manual page for instructions on how to use it.
When you start the commissioning procedure, the ecosystem 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:
Temperature Sensor sample onboarding information QR Code
QR Code Payload
Manual pairing code
Scan the following QR code with the app for your ecosystem:
MT:K.K9042C00KA0648G00
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.pngfile includes the generated QR code.The
factory_data.txtfile 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.
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: