Important: We're excited to introduce our new technical documentation platform docs.nordicsemi.com, currently in Beta version. We invite you to explore it and share your feedback. Read more on our DevZone blog.
This thermostat sample demonstrates the usage of the Matter application layer to build a thermostat device for monitoring temperature values and controlling the 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 or on top of a Wi-Fi network.
In case of Thread, this device works as a Thread Minimal End Device.
Support for both Thread and Wi-Fi is mutually exclusive and depends on the hardware platform, so only one protocol can be supported for a specific Matter device.
Additionally, this example allows you to connect to a temperature sensor device that can also be used for temperature measurement.
If you want to commission the device and control it remotely in 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.
Similarly, if you want to test the sample with External sensor integration, you need additional hardware that incorporates a temperature sensor.
For example, Nordic Thingy:53, used for the Matter weather station application.
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.
When programmed, 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.
The sample can operate in one of the following modes:
Simulated temperature sensor mode - In this mode, the thermostat sample generates simulated temperature measurements and prints it to the terminal.
This is the default mode, in which the sample provides simulated temperature values.
Real temperature sensor mode - In this mode, the thermostat sample is bound to a remote Matter temperature sensor, which provides real temperature measurements.
This mode requires External sensor integration.
The sample automatically logs the temperature measurements with a defined interval and it uses buttons for printing the measurement results to the terminal.
You can test the sample in the following ways:
Standalone, using a single DK that runs the thermostat application.
Remotely over the Thread or the Wi-Fi protocol, which in either case requires more devices, including a Matter controller that you can configure either on a PC or a mobile device.
The Access Control List (ACL) is a list related to the Access Control cluster.
The list contains rules for managing and enforcing access control for a node’s endpoints and their associated cluster instances.
In this sample’s case, this allows the temperature measurement devices to receive messages from the thermostat and provide the temperature data to the thermostat.
You can read more about ACLs on the Access Control Guide in the Matter documentation.
By default, the thermostat sample generates simulated temperature measurements that simulate local temperature changes.
Additionally, you can enable periodic outdoor temperature measurements by binding the thermostat with an external temperature sensor device.
To test this feature, follow the steps listed in the Testing with external sensor section.
Binding refers to establishing a relationship between endpoints on the local and remote nodes.
With binding, local endpoints are pointed and bound to the corresponding remote endpoints.
Both must belong to the same cluster type.
Binding lets the local endpoint know which endpoints are going to be the target for the client-generated actions on one or more remote nodes.
In this sample, the thermostat device prints simulated temperature data by default and it does not know the remote endpoints of the temperature sensors (on remote nodes).
Using binding, the thermostat device updates its Binding cluster with all relevant information about the temperature sensor devices, such as their IPv6 address, node ID, and the IDs of the remote endpoints that contain the temperature measurement cluster.
The sample does not use a single prj.conf file.
Configuration files are provided for different build types, and they are located in the sample root directory.
Before you start testing the application, you can select one of the build types supported by the application.
Debug version of the application; can be used to enable additional features for verifying the application behavior, such as logs or command-line shell.
You can enable over-the-air Device Firmware Upgrade only on hardware platforms that have external flash memory.
Currently only nRF52840 DK, nRF5340 DK and nRF7002 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.
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
For example:
west build -b nrf52840dk_nrf52840 -- -DCONFIG_CHIP_DFU_OVER_BT_SMP=y
The Device Firmware Upgrade (DFU) for the nRF54L15 PDK is exclusively available for the release build configuration and is limited to using the internal MRAM for storage.
This means that both the currently running firmware and the new firmware to be updated must be stored within the device’s internal flash memory.
Currently, there is no support for utilizing external flash memory for this purpose.
To build the sample with DFU support, use the -DCONF_FILE=prj_release.conf flag in your CMake build command.
The following is an example command to build the sample with support for OTA DFU only:
west build -b nrf54l15pdk_nrf54l15_cpuapp -- -DCONF_FILE=prj_release.conf
If you want to build the sample with support for both OTA DFU and SMP DFU, use the following command:
west build -b nrf54l15pdk_nrf54l15_cpuapp -- -DCONF_FILE=prj_release.conf -DCONFIG_CHIP_DFU_OVER_BT_SMP=y
You can disable DFU support for the release build configuration to double available application memory space.
Do this by setting the CONFIG_CHIP_DFU_OVER_BT_SMP and CONFIG_CHIP_OTA_REQUESTOR Kconfig options to n, and removing the pm_static_nrf54l15pdk_nrf54l15_cpuapp_release.yml file.
For example:
west build -b nrf54l15pdk_nrf54l15_cpuapp -- -DCONF_FILE=prj_release.conf -DCONFIG_CHIP_DFU_OVER_BT_SMP=n -DCONFIG_CHIP_OTA_REQUESTOR=n
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.
In this sample, the factory data support is enabled by default for all build types 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:
The nRF54L15 PDK revision v0.3.0 uses a different numbering system for buttons and LEDs compared to previous boards.
All numbers start from 0 instead of 1, as was the case previously.
This means that LED1 in this documentation refers to LED0 on the nRF54L15 PDK board, LED2 refers to LED1, Button 1 refers to Button 0, and so on.
For the nRF54L15 PDK revision v0.2.1, the numbering of buttons and LEDs is the same as on the nRF52840 DK and nRF5340 DK boards.
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:
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 (15 minutes 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:
Prints the most recent thermostat data to terminal.
SEGGER J-Link USB port:
Used for getting logs from the device or for communicating with it through the command-line interface.
Before you start testing the application, you can select one of the Matter thermostat build types, depending on your building method.
See Providing CMake options for information about how to select a build type.
After building the sample and programming it to your development kit, you can either test the sample’s basic features or use the Matter weather station application to test the thermostat with an external sensor.
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 the LED1 starts flashing (short flash on).
This means that the sample has automatically started the Bluetooth LE advertising.
Observe the UART terminal.
The sample starts automatically printing the simulated temperature data to the terminal with 30-second intervals.
Press Button 2 to print the most recent temperature data to the terminal.
Keep the Button 1 pressed for more than six seconds to initiate factory reset of the device.
The device reboots after all its settings are erased.
After building this sample and the Matter weather station application and programming each to the respective development kit and Nordic Thingy:53, complete the following steps to test communication between both devices:
Connect to both kits with a terminal emulator (for example, nRF Connect Serial Terminal).
See Testing and optimization for the required settings and steps.
Connect to both kits with 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.
If devices were not erased during the programming, press the button responsible for the factory reset on each device.
On each device, press the button that starts the Bluetooth LE advertising.
Commission devices to the Matter network.
See Commissioning the device for more information.
During the commissioning process, write down the values for the thermostat node ID, the temperature sensor node ID, and the temperature sensor endpoint ID.
These IDs are going to be used in the next steps (<thermostat_node_ID>, <temperature_sensor_node_ID>, and <temperature_sensor_endpoint_ID>, respectively).
Use the CHIP Tool (“Writing ACL to the accesscontrol cluster” section) to add proper ACL for the temperature sensor device.
Use the following command, with <thermostat_node_ID>, <temperature_sensor_node_ID>, and <temperature_sensor_endpoint_ID> values from the previous step about commissioning:
Write a binding table to the thermostat to inform the device about the temperature sensor endpoint.
Use the following command, with <thermostat_node_ID>, <temperature_sensor_node_ID>, and <temperature_sensor_endpoint_ID> values from the previous step about commissioning:
(You can read more about this step in the “Adding a binding table to the binding cluster” in the CHIP Tool guide.)
The thermostat is now able to read the real temperature data from the temperature sensor device.
The connection is ensured by Binding to Matter’s temperature measurement cluster.
Press Button 2 to print the most recent temperature data from the thermostat device to the UART terminal.
Before starting the commissioning to Matter procedure, ensure that there is no other Bluetooth LE connection established with the device.
To commission the device, go to the Testing Matter in the nRF Connect SDK page and complete the steps for the Matter network environment and the Matter controller you want to use.
After choosing the configuration, the guide walks you through the following steps:
Only if you are configuring Matter over Thread: Configure the Thread Border Router.
Build and install the Matter controller.
Commission the device.
Send Matter commands that cover scenarios described in the Testing section.
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:
