Matter: Door lock
This door lock sample demonstrates the usage of the Matter (formerly Project Connected Home over IP, Project CHIP) application layer to build a door lock device with one basic bolt. 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 application.
Requirements
The sample supports the following development kits:
Hardware platforms |
PCA |
Board name |
Build target |
|---|---|---|---|
PCA10056 |
|
||
PCA10095 |
|
||
nRF21540 DK |
PCA10112 |
|
If you want to commission the lock 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 changing the lock and device states, and LEDs to show the state of these changes. You can test it in the following ways:
Standalone, using a single DK that runs the door lock 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 Thread disabled. 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 network. You have to make the device discoverable manually (for security reasons). The controller must get the commissioning information from the Matter accessory device and provision the device into the network. For details, see the Commissioning the device section.
Remote testing using test mode
Alternatively to the commissioning procedure, you can use the test mode that allows joining the Thread network with default static parameters and static cryptographic keys. Use Button 3 to enable this mode after building and running the sample.
Note
The test mode is not compliant with Matter and it only works together with the Matter controller and other devices that use the same default configuration.
Configuration
See Configuring your application for information about how to permanently or temporarily change the configuration.
The sample uses different configuration files depending on the supported features.
The configuration files are automatically attached to the build based on the build type suffix of the file name, such as _single_image_smp_dfu in the prj_single_image_smp_dfu.conf file.
To modify the configuration options, apply the modifications to the files with the appropriate suffix.
See the table for information about available configuration types:
Config suffix |
Enabled feature |
Enabling build option |
Supported boards |
|---|---|---|---|
none |
none (basic build) |
|
|
|
Single-image Device Firmware Upgrade over Matter |
|
|
|
Multi-image Device Firmware Upgrade over Matter |
|
|
|
Single-image Device Firmware Upgrade over Matter and SMP |
|
|
|
Multi-image Device Firmware Upgrade over Matter and SMP |
|
|
Device Firmware Upgrade support
Note
You can enable over-the-air Device Firmware Upgrade only on hardware platforms that have external flash memory.
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 -DBUILD_WITH_DFU=BLE build flag during the build process.
To configure the sample to disable the DFU and the secure bootloader, use the -DBUILD_WITH_DFU=OFF 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_method replaced with the desired DFU method:
west build -b build_target -- -DBUILD_WITH_DFU=dfu_method
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_ekThis 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.
Low-power build
To configure the sample to consume less power, use the low-power build. It enables Thread’s Sleepy End Device mode and disables debug features, such as the UART console or the LED 1 usage.
To trigger the low-power build, use the -DOVERLAY_CONFIG="overlay-low_power.conf" option when building the sample.
See Providing CMake options for instructions on how to add this option 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):
west build -b build_target -- -DOVERLAY_CONFIG="overlay-low_power.conf"
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:
Shows the state of the lock. The following states are possible:
Solid On - The bolt is extended and the door is locked.
Off - The bolt is retracted and the door is unlocked.
Rapid Even Flashing (50 ms on/50 ms off during 2 s) - The simulated bolt is in motion from one position to another.
- Button 1:
Depending on how long you press the button:
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.
If pressed for less than three seconds, it initiates the OTA software update process. The OTA process is disabled by default, but you can enable it when you build the sample with the DFU support (see Configuration).
- Button 2:
Changes the lock state to the opposite one.
- Button 3:
Starts the Thread networking in the test mode using the default configuration.
- Button 4:
Starts the NFC tag emulation, enables Bluetooth LE advertising for the predefined period of time (15 minutes by default), and makes the device discoverable over Bluetooth LE. This button is used during the commissioning procedure.
- 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 commissioning information from the Matter accessory device to start the commissioning procedure.
Building and running
This sample can be found under samples/matter/lock in the nRF Connect SDK folder structure.
See Building and programming an application for information about how to build and program the application.
See Configuration for information about building the sample with the DFU support.
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.
Connect to the kit with a terminal emulator (for example, PuTTY). See How to connect with PuTTY for the required settings.
Observe that LED 2 is lit, which means that the door lock is closed.
Press Button 2 to unlock the door. LED 2 is blinking while the lock is opening. After approximately two seconds, LED 2 turns off permanently. The following messages appear on the console:
I: Unlock Action has been initiated I: Unlock Action has been completed
Press Button 2 one more time to lock the door again. LED 2 starts blinking and remains turned on. The following messages appear on the console:
I: Lock Action has been initiated I: Lock Action has been completed
Press Button 1 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 door lock device from a Thread network.
Use one of the following to enable remote control:
Commissioning the device allows you to set up a testing environment and remotely control the sample over a Matter-enabled Thread network.
Remote testing using test mode allows you to test the sample functionalities in a Thread network with default parameters, without commissioning. Use Button 3 to enable this mode after building and running the sample.
Commissioning the device
To commission the device, go to the Configuring Matter development environment guide and complete the steps for the Matter controller you want to use. The guide walks you through the following steps:
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.
If you are new to Matter, the recommended approach is Configuring Thread Border Router and mobile Matter Controller using an Android smartphone.
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: