This sample demonstrates the usage of the Matter application layer to build a device capable of sensing smoke and carbon monoxide, and issuing an alarm if the their concentration is too high.
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.
You can use this sample as a reference for creating your own application.
If you want to commission the device and control it remotely, you also need a Matter controller device configured on PC or mobile.
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.
The sample does not use real hardware smoke or CO sensors due to hardware limitations.
Instead, it uses test event triggers to test issuing the device alarms, and LEDs to show the current device state.
The smoke CO alarm detects the alarm conditions and issues the appropriate alarm using different LED patterns.
Note
According to the Matter specification requirements, the smoke CO alarm device shall express alarms using both audible and visual indications.
This sample does not use audible indications because of the lack of suitable hardware on supported development kits.
In case multiple alarm conditions are met, the device expresses only the alarm with the highest priority.
After the alarm with the highest priority is stopped, the device starts expressing the next alarm in the priority order until all alarm conditions have ceased.
The implementation demonstrated in this sample supports issuing the following alarms, listed from the highest priority to the lowest:
Smoke alarm - Issued if allowed smoke concentration level is exceeded.
CO alarm - Issued if allowed carbon monoxide concentration level is exceeded.
Hardware fault alert - Issued if the device hardware is not operating properly.
Device self-test alert - Issued if the device self-test was started by the user.
End of service alert - Issued if the device service was ended either by the expiration date or other physical conditions, and it needs to be replaced.
Battery level alert - Issued if the device battery level is too low.
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.
You can enable both methods after building and running the sample.
The smoke CO alarm 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 responsiveness is much lower than in the SIT mode.
However, you can request the device to become responsive to, for example, change its configuration.
To do that, you need to use the User Active Mode Trigger (UAT) feature by pressing the appropriate button.
See User interface for information about how to switch the operation modes.
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.
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.
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.
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
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 Developing with 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 SHIELD=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 IDE 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.
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 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.
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:
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:
Shows the state of the alarm.
The following states are possible:
Even Flashing (300 ms on/300 ms off) - The smoke alarm is expressed.
Even Flashing (500 ms on/500 ms off) - 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.
Flashing in combination with LED3 and LED4 when other alarms are triggered.
LED 3:
Shows the state of the alarm.
The following states are possible:
Even Flashing (300 ms on/300 ms off) - The CO alarm is expressed.
Flashing in combination with LED2 and LED4 when other alarms are triggered.
LED 4:
Shows the state of the alarm.
The following states are possible:
Even Flashing (300 ms on/300 ms off) - The battery level low alarm is expressed.
Flashing in combination with LED2 and LED3 when other alarms are triggered.
LED 2, LED 3 and LED 4 combined:
Shows the state of the alarm.
The following states are possible:
All three LEDs, Short Flash On (300 ms on/700 ms off) - The hardware fault alarm is expressed.
All three LEDs, Long Flash On (700 ms on/300 ms off) - The end of service alarm is expressed.
Flashing In Sequence from LED2, through LED3 to LED4 (200 ms interval) - The self-test is triggered.
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 3:
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.
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:
Shows the state of the alarm.
The following states are possible:
Even Flashing (300 ms on/300 ms off) - The smoke alarm is expressed.
Even Flashing (500 ms on/500 ms off) - 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.
Flashing in combination with LED2 and LED3 when other alarms are triggered.
LED 2:
Shows the state of the alarm.
The following states are possible:
Even Flashing (300 ms on/300 ms off) - The CO alarm is expressed.
Flashing in combination with LED1 and LED3 when other alarms are triggered.
LED 3:
Shows the state of the alarm.
The following states are possible:
Even Flashing (300 ms on/300 ms off) - The battery level low alarm is expressed.
Flashing in combination with LED1 and LED2 when other alarms are triggered.
LED 1, LED 2 and LED 3 combined:
Shows the state of the alarm.
The following states are possible:
All three LEDs, Short Flash On (300 ms on/700 ms off) - The hardware fault alarm is expressed.
All three LEDs, Long Flash On (700 ms on/300 ms off) - The end of service alarm is expressed.
Flashing In Sequence from LED1, through LED2 to LED3 (200 ms interval) - The self-test is triggered.
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 2:
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.
After building the sample and programming it to your development kit, complete the following steps to test its basic features.
Note
The following steps use the CHIP Tool controller as an example.
Visit the test event triggers page to see the code values used for triggering specific alarms.
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.
If the device was not erased during the programming, press and hold Button 1 until the factory reset takes place.
Observe that LED 2, LED 3 and LED 4 are turned off, which means that the device does not express any alarm.
Trigger the device self-test by invoking the following command with the <node_id> and <endpoint_id> replaced with values selected by you (for example, 1 and 1):
The LED2, LED3 and LED4 will sequentially flash for 5 seconds.
Test the Smoke alarm by invoking triggers from the General Diagnostics cluster.
Replace the <test_event_enable_key> and <node_id> arguments in the presented commands with values selected by you (for example, 00112233445566778899AABBCCDDEEFF and 1):
Trigger the Smoke alarm by invoking the following command:
The LED2 will start blinking evenly with 300 ms interval.
Trigger the CO alarm by invoking the following command with the <test_event_enable_key> and <node_id> replaced with the values you selected in the previous steps:
Nothing will change, because the CO alarm has lower priority than smoke alarm, so it will not be expressed.
Stop the Smoke alarm by invoking the following command with the <test_event_enable_key> and <node_id> replaced with the values you selected in the previous steps:
The LED2 will be turned off and the LED3 will start blinking evenly with 300 ms interval, to express the CO alarm, as the next one in the order.
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.
If the device was not erased during the programming, press and hold Button 0 until the factory reset takes place.
Observe that LED 1, LED 2 and LED 3 are turned off, which means that the device does not express any alarm.
Trigger the device self-test by invoking the following command with the <node_id> and <endpoint_id> replaced with values selected by you (for example, 1 and 1):
The LED1, LED2 and LED3 will sequentially flash for 5 seconds.
Test the Smoke alarm by invoking triggers from the General Diagnostics cluster.
Replace the <test_event_enable_key> and <node_id> arguments in the presented commands with values selected by you (for example, 00112233445566778899AABBCCDDEEFF and 1):
Trigger the Smoke alarm by invoking the following command:
The LED1 will start blinking evenly with 300 ms interval.
Trigger the CO alarm by invoking the following command with the <test_event_enable_key> and <node_id> replaced with the values you selected in the previous steps:
Nothing will change, because the CO alarm has lower priority than smoke alarm, so it will not be expressed.
Stop the Smoke alarm by invoking the following command with the <test_event_enable_key> and <node_id> replaced with the values you selected in the previous steps:
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.
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.
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:
Scan the following QR code with the app for your ecosystem:
MT:6FCJ142C00KA0648G00
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.
