This door lock sample demonstrates the usage of the Matter application layer to build a door lock device with one basic bolt.
You can use this sample as a reference for creating your application.
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 or Wi-Fi network.
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 lock device.
Depending on the network you choose:
In case of Wi-Fi, this device works in the Legacy Power Save mode.
This means that the device sleeps most of the time and wakes up on each Delivery Traffic Indication Message (DTIM) interval to poll for pending messages.
If you want to commission the lock device and control it remotely through an IPv6 network, 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 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 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.
By default, the Matter accessory device has IPv6 networking 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 or Wi-Fi network.
You have to make the device discoverable manually (for security reasons).
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 different configuration files depending on the supported features.
Configuration files are provided for different build types and they are located in the application root 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.
When the CONF_FILE variable contains a single file and this file follows the naming pattern prj_<buildtype>.conf, then the build type will be inferred to be <buildtype>.
The build type cannot be set explicitly.
The <buildtype> can be any string, but it is common to use release and debug.
The Partition Manager’s static configuration can also be made dependent on the build type.
When the build type has been inferred, the file pm_static_<buildtype>.yml will have precedence over pm_static.yml.
The child image Kconfig configuration can also be made dependent on the build type.
The child image Kconfig file is named <child_image>.conf instead of prj.conf, but otherwise follows the same pattern as the parent Kconfig.
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.
thread_wifi_switched – Debug version of the application with the ability to switch between Thread and Wi-Fi network support in the field - can be used for the nRF5340 DK with the nRF7002 EK shield attached.
no_dfu – Debug version of the application without Device Firmware Upgrade feature support - can be used for the nRF52840 DK, nRF5340 DK, nRF7002 DK, and nRF21540 DK.
Note
Selecting a build type is optional.
The debug build type is used by default if no build type is explicitly selected.
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.
To configure the sample to disable the DFU and the secure bootloader, use the -DCONF_FILE=prj_no_dfu.conf 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
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, for example SHIELD=nrf21540_ek.
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=nrf21540_ek.
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=nrf21540_ek
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.
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.
Additionally, the LED starts blinking evenly (500 ms on/500 ms off) when 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.
Button 1:
Depending on how long you press the button:
If pressed for less than three seconds, it initiates the SMP server (Security Manager Protocol).
After that, the Direct Firmware Update (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 the 3-second window cancels the factory reset procedure.
Button 2:
On nRF52840 DK, nRF5340 DK, and nRF21540 DK: Changes the lock state to the opposite one.
On nRF7002 DK:
If pressed for less than three seconds, it changes the lock state to the opposite one.
If pressed for more than three seconds, it 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.
Button 3:
On the nRF5340 DK when using the thread_wifi_switched build type: If pressed for more than ten seconds, it switches the running application from Thread or Wi-Fi to the other and factory resets the device.
On other platform or build type: Not available.
Button 4:
On nRF52840 DK, nRF5340 DK, and nRF21540 DK: 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.
On nRF7002 DK: Not available.
SEGGER J-Link USB port:
Used for getting logs from the device or for communicating with it through the command-line interface.
To select the build type in the nRF Connect for VS Code extension:
When building an application as described in the nRF Connect for VS Code extension documentation, follow the steps for setting up the build configuration.
In the Add Build Configuration screen, select the desired .conf file from the Configuration drop-down menu.
Fill in other configuration options, if applicable, and click Build Configuration.
To select the build type when building the application from command line, specify the build type by adding the following parameter to the westbuild 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:
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/lock/configuration/nrf52840dk_nrf52840/prj_shell.conf
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 that supports VT100/ANSI escape characters (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 initiatedI: 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 initiatedI: Lock Action has been completed
Press Button 1 to initiate factory reset of the device.
The device reboots after all its settings are erased.
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:
The thread_wifi_switched build type allows you to build the door lock application that supports dynamic switching between Matter over Thread and Matter over Wi-Fi.
This feature requires that both variants of the application are built and placed in appropriate partitions of the external flash.
After that, when a user triggers the switch, the device is rebooted into the MCUboot bootloader, which swaps the current variant.
To test switching between Thread and Wi-Fi, complete the following steps:
Build the door lock application for Matter over Thread:
west build -b nrf5340dk_nrf5340_cpuapp -- -DCONF_FILE=prj_thread_wifi_switched.conf -DSHIELD=nrf7002_ek -DCONFIG_CHIP_WIFI=n
Program the application to the kit using the following command:
west flash --erase
Erase the entire content of the external flash using the following command:
nrfjprog --qspieraseall
Program the application to a partition of the external flash using the following command:
west build -t flash-external
Build the door lock application for Matter over Wi-Fi:
west build -b nrf5340dk_nrf5340_cpuapp -p always -- -DCONF_FILE=prj_thread_wifi_switched.conf -DSHIELD=nrf7002_ek
Program the application to another partition of the external flash using the following command:
west build -t flash-external
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.
Press Button 3 for more than ten seconds to trigger switching to the Matter over Wi-Fi variant of the application.
Observe logs showing the progress of the operation until the device shuts down.
Wait until the device boots again.
Find the following log message which indicates that the expected variant of the application is running:
D: 823 [DL]WiFiManager has been initialized
Device Firmware Upgrade over Matter for Thread/Wi-Fi switchable application
To upgrade the device firmware when using the thread_wifi_switched build type, complete the steps from the Device Firmware Upgrade over Matter section in the Performing Device Firmware Upgrade in the nRF Connect examples tutorial of the Matter documentation.
Because the application supports switching between Thread and Wi-Fi, you need to make sure that the Matter OTA image file served by the OTA Provider includes two application variants: for Matter over Thread and for Matter over Wi-Fi, respectively.
To make sure that both application variants are included in the OTA image file, use the dedicated the combine_ota_images.py script.
The script takes the Matter OTA image files generated for both variants and combines them in one file.
It also assumes that both input images were created with the same vendor_id, product_id, version, version_string, min_version, max_version, and release_notes.
Complete the following steps to generate the Matter OTA combined image file:
Build the door lock application for Matter over Thread by running the following command:
west build -b nrf5340dk_nrf5340_cpuapp -d build_thread -- -DCONF_FILE=prj_thread_wifi_switched.conf -DSHIELD=nrf7002_ek -DCONFIG_CHIP_WIFI=n
This command creates the build_thread directory, where the Matter over Thread application is stored.
Build the door lock application for Matter over Wi-Fi by running the following command:
west build -b nrf5340dk_nrf5340_cpuapp -d build_wifi -- -DCONF_FILE=prj_thread_wifi_switched.conf -DSHIELD=nrf7002_ek
This command creates the build_wifi directory, where the Matter over Wi-Fi application is stored.
Combine Matter OTA image files generated for both variants by running the combine_ota_images.py script in the sample directory by running the following command (with <output_directory> changed to the directory name of your choice):
Keep the order in which the files are passed to the script, given that the Thread variant image file must be passed in front of the Wi-Fi variant image.
