Matter: Door lock

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 depends on the hardware platform. The door lock sample can be built with support for one transport protocol, either Thread or Wi-Fi, or with support for switching between Matter over Wi-Fi and Matter over Thread, where the application activates either Thread or Wi-Fi on boot, depending on the runtime configuration.

Depending on the network you choose:

  • In case of Thread, this device works as a Thread Sleepy End Device.

  • 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.

The same distinction applies in the Thread and Wi-Fi switching scenario, depending on the active transport protocol.

Requirements

The sample supports the following development kits:

Hardware platforms

PCA

Board name

Board target

Shields

nRF7002 DK (emulating nRF7001)

PCA10143

nrf7002dk

nrf7002dk/nrf5340/cpuapp/nrf7001

nRF7002 DK

PCA10143

nrf7002dk

nrf7002dk/nrf5340/cpuapp

nRF54L15 PDK

PCA10156

nrf54l15pdk

nrf54l15pdk/nrf54l15/cpuapp

nRF54H20 DK

PCA10175

nrf54h20dk

nrf54h20dk/nrf54h20/cpuapp

nRF5340 DK

PCA10095

nrf5340dk

nrf5340dk/nrf5340/cpuapp

nrf7002ek_coex nrf7002ek

nRF52840 DK

PCA10056

nrf52840dk

nrf52840dk/nrf52840

nRF21540 DK

PCA10112

nrf21540dk

nrf21540dk/nrf52840

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.

If you want to enable and test Matter Bluetooth LE with Nordic UART Service, you also need a smartphone with either Android (Android 11 or newer) or iOS (iOS 16.1 or newer).

IPv6 network support

The development kits for this sample offer the following IPv6 network support for Matter:

  • Matter over Thread is supported for nrf52840dk/nrf52840, nrf5340dk/nrf5340/cpuapp, nrf21540dk/nrf52840, and nrf54h20dk/nrf54h20/cpuapp.

  • Matter over Wi-Fi is supported for nrf5340dk/nrf5340/cpuapp or nrf54h20dk/nrf54h20/cpuapp with the nrf7002ek shield attached, for nrf7002dk/nrf5340/cpuapp (2.4 GHz and 5 GHz), or for nrf7002dk/nrf5340/cpuapp/nrf7001 (2.4 GHz only).

  • Switching between Matter over Thread and Matter over Wi-Fi is supported for nrf5340dk/nrf5340/cpuapp with the nrf7002ek shield attached, using the switched Thread and Wi-Fi configuration.

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 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.

You can enable both methods after building and running the sample.

Remote testing in a network

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.

Door lock credentials

By default, the application supports only PIN code credentials, but it is possible to implement support for other door lock credential types by using the AccessManager module. The credentials can be used to control remote access to the bolt lock. The PIN code assigned by the Matter controller is stored persistently, which means that it can survive a device reboot. Depending on the IPv6 network technology in use, the following storage backends are supported by default to store the PIN code credential:

  • Matter over Thread - secure storage backend (CONFIG_NCS_SAMPLE_MATTER_SECURE_STORAGE_BACKEND Kconfig option enabled by default).

  • Matter over Wi-Fi - non-secure storage backend (CONFIG_NCS_SAMPLE_MATTER_SETTINGS_STORAGE_BACKEND Kconfig option enabled by default).

You can learn more about the nRF Connect SDK Matter persistent storage module and its configuration in the Persistent storage section of the Advanced Matter Kconfig options documentation.

The application supports multiple door lock users and PIN code credentials. The following Kconfig options control the limits of the users and credentials that can be added to the door lock:

  • CONFIG_LOCK_MAX_NUM_USERS - Maximum number of users supported by the door lock.

  • CONFIG_LOCK_MAX_NUM_CREDENTIALS_PER_USER - Maximum number of credentials that can be assigned to one user.

  • CONFIG_LOCK_MAX_NUM_CREDENTIALS_PER_TYPE - Maximum number of credentials in total.

  • CONFIG_LOCK_MAX_CREDENTIAL_LENGTH - Maximum length of a single credential in bytes.

Thread and Wi-Fi switching

When built using the switched Thread and Wi-Fi configuration and programmed to the nRF5340 DK with the nRF7002 EK shield attached, the door lock sample supports a feature that allows you to switch between Matter over Thread and Matter over Wi-Fi at runtime. Due to Matter protocol limitations, a single Matter node can only use one transport protocol at a time.

The application is built with support for both Matter over Thread and Matter over Wi-Fi. The device activates either Thread or Wi-Fi transport protocol on boot, based on a flag stored in the non-volatile memory on the device. By default, Matter over Wi-Fi is activated.

You can trigger the switch from one transport protocol to the other using Button 3 on the nRF5340 DK. This toggles the flag stored in the non-volatile memory, and then the device is factory reset and rebooted. Because the flag is toggled, the factory reset does not switch the device back to the default transport protocol (Wi-Fi). Instead, the factory reset and recommissioning to a Matter fabric allows the device to be provisioned with network credentials for the transport protocol that it was switched to, and to start operating in the selected network.

See Matter door lock custom configurations and Testing switching between Thread and Wi-Fi for more information about how to configure and test this feature with this sample.

Wi-Fi firmware on external memory

You can program a portion of the application code related to the nRF70 Series’ Wi-Fi firmware onto an external memory to free up space in the on-chip memory. This option is available only when building for the nRF5340 DK with the nRF7002 EK shield attached. To prepare an application to use this feature, you need to create additional MCUboot partitions. To learn how to configure MCUboot partitions, see the Adding nRF70 Series firmware patch partitions guide. To enable this feature for Matter, set the SB_CONFIG_WIFI_PATCHES_EXT_FLASH_STORE, SB_CONFIG_DFU_MULTI_IMAGE_PACKAGE_WIFI_FW_PATCH Kconfig options to y, and set the SB_CONFIG_MCUBOOT_UPDATEABLE_IMAGES Kconfig option to 3.

For example:

west build -b nrf5340dk/nrf5340/cpuapp -p -- -Dlock_SHIELD=nrf7002ek -Dipc_radio_SHIELD=nrf7002ek_coex -DFILE_SUFFIX=thread_wifi_switched -DSB_CONFIG_WIFI_PATCHES_EXT_FLASH_STORE=y -DSB_CONFIG_MCUBOOT_UPDATEABLE_IMAGES=3 -DCONFIG_CHIP_DFU_OVER_BT_SMP=y -DSB_CONFIG_WIFI_NRF700X=y -DSB_CONFIG_DFU_MULTI_IMAGE_PACKAGE_WIFI_FW_PATCH=y

Matter Bluetooth LE with Nordic UART Service

The Matter implementation in the nRF Connect SDK lets you extend Bluetooth LE an additional Bluetooth LE service and use it in any Matter application, even when the device is not connected to a Matter network. The Matter door lock sample provides a basic implementation of this feature, which integrates Bluetooth LE with the Nordic UART Service (NUS). Using NUS, you can declare commands specific to a Matter sample and use them to control the device remotely through Bluetooth LE. The connection between the device and the Bluetooth controller is secured and requires providing a passcode to pair the devices.

In the door lock sample, you can use the following commands with the Bluetooth LE with NUS:

  • Lock - To lock the door of the connected device.

  • Unlock - To unlock the door of the connected device.

If the device is already connected to the Matter network, the notification about changing the lock state will be send to the Bluetooth controller.

Currently, the door lock’s Bluetooth LE service extension with NUS is only available for the nRF52840 and the nRF5340 DKs in the Matter over Thread network variant. However, you can use the Bluetooth LE service extension regardless of whether the device is connected to a Matter over Thread network or not.

See Enabling Matter Bluetooth LE with Nordic UART Service and Testing door lock using Bluetooth LE with Nordic UART Service for more information about how to configure and test this feature with this sample.

Scheduled timed access

The scheduled timed access feature is an optional Matter lock feature that can be applicable to all available lock users. You can use the scheduled timed access feature to allow guest users of the home to access the lock at the specific scheduled times. To use this feature, you need to create at least one user on the lock device, and assign credentials. For more information about setting user credentials, see the Saving users and credentials on door lock devices section of the Working with the CHIP Tool page in the Matter documentation set, and the Testing remote access with PIN code credential section of this sample.

You can schedule the following types of timed access:

  • Week-day - Restricts access to a specified time window on certain days of the week for a specific user. This schedule grants repeated access each week. When the schedule is cleared, the user is granted unrestricted access.

  • Year-day - Restricts access to a specified time window on a specific date window. This schedule grants access only once, and does not repeat. When the schedule is cleared, the user is granted unrestricted access.

  • Holiday - Sets up a holiday operating mode in the lock device. You can choose one of the following operating modes:

    • Normal - The lock operates normally.

    • Vacation - Only remote operations are enabled.

    • Privacy - All external interactions with the lock are disabled. Can only be used if the lock is in the locked state. Manually unlocking the lock changes the mode to Normal.

    • NoRemoteLockUnlock - All remote operations with the lock are disabled.

    • Passage - The lock can be operated without providing a PIN. This option can be used, for example, for employees during working hours.

See the Enabling scheduled timed access and Testing scheduled timed access sections of this sample for more information.

Configuration

See Configuring and building an application for information about how to permanently or temporarily change the configuration.

Matter door lock custom configurations

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.

The sample supports the following configurations:

Sample configurations

Configuration

File name

FILE_SUFFIX

Supported board

Description

Debug (default)

prj.conf

No suffix

All from Requirements

Debug version of the application.

Enables additional features for verifying the application behavior, such as logs.

Release

prj_release.conf

release

All from Requirements

Release version of the application.

Enables only the necessary application functionalities to optimize its performance.

Switched Thread and Wi-Fi

prj_thread_wifi_switched.conf

thread_wifi_switched

nRF5340 DK with the nRF7002 EK shield attached

Debug version of the application with the ability to switch between Thread and Wi-Fi network support in the field.

Device Firmware Upgrade support

Note

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 PDK 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.

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 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

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 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.

    See nRF Connect for VS Code extension pack documentation for more information.

    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.

Enabling Matter Bluetooth LE with Nordic UART Service

You can enable the Matter Bluetooth LE with Nordic UART Service feature by setting the CONFIG_CHIP_NUS Kconfig option to y.

Note

This sample supports one Bluetooth LE connection at a time. Matter commissioning, DFU, and NUS over Bluetooth LE must be run separately.

The door lock’s Bluetooth LE service extension with NUS requires a secure connection with a smartphone, which is established using a security PIN code. The PIN code is different depending on the configuration the sample was built with:

  • In the debug configuration, the secure PIN code is generated randomly and printed in the log console in the following way:

    PROVIDE THE FOLLOWING CODE IN YOUR MOBILE APP: 165768
    
  • In the release configuration, the secure PIN is set to 123456 due to lack of a different way of showing it on nRF boards other than in the log console.

See Testing door lock using Bluetooth LE with Nordic UART Service for more information about how to test this feature.

Factory data support

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:

To learn more about factory data, read the Configuring factory data for the nRF Connect examples page in the Matter documentation.

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.

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:

    • 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:
  • Changes the lock state to the opposite one.

Button 3:
  • On the nRF5340 DK when using the switched Thread and Wi-Fi configuration: If pressed for more than ten seconds, it switches the Matter transport protocol from Thread or Wi-Fi to the other and factory resets the device.

  • On other platform or configuration: Not available.

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 procedure.

Building and running

This sample can be found under samples/matter/lock in the nRF Connect SDK folder structure.

To build the sample, follow the instructions in Configuring and 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.

See Configuration for information about building the sample with the DFU support.

To use nrf54H20 DK with the nrf7002ek shield attached (2.4 GHz or 5 GHz), follow the Developing with nRF7002 EB user guide to connect all required pins and then use the following command to build the sample:

west build -b nrf54h20dk/nrf54h20/cpuapp -p -- -DSB_CONFIG_WIFI_NRF700X=y -DCONFIG_CHIP_WIFI=y -Dlock_SHIELD=nrf700x_nrf54h20dk

Selecting a configuration

Before you start testing the application, you can select one of the Matter door lock custom configurations. See Custom configurations and Providing CMake options for more information how to select a configuration.

Testing

After building the sample and programming it to your development kit, complete the following steps to test its basic features:

  1. 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.

  2. 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.

  3. Observe that LED 2 is lit, which means that the door lock is closed.

  4. 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
    
  5. 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
    
  6. 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.

Enabling remote control

Remote control allows you to control the Matter door lock device from a Thread or a Wi-Fi network.

Commissioning the device allows you to set up a testing environment and remotely control the sample over a Matter-enabled Thread or Wi-Fi network.

Commissioning the device

Note

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.

If you are new to Matter, the recommended approach is to use CHIP Tool for Linux or macOS.

Onboarding information

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:

Door lock sample onboarding information

QR Code

QR Code Payload

Manual pairing code

Scan the following QR code with the app for your ecosystem:

QR code for commissioning the light bulb device

MT:8IXS142C00KA0648G00

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.

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.

Enabling scheduled timed access

To enable the scheduled timed access feature, complete the following steps:

  1. Enable all needed scheduled timed access types in the ZAP file:

    1. Open the lock.zap file using the following west command:

      west zap-gui
      
    2. Select the endpoint that contains the Matter Door Lock cluster. By default, this is Endpoint-1.

    3. Click the Configure symbol for the Door Lock cluster entry.

    4. In the Door Lock context window, go to the Attributes tab and enable all required attributes:

      • NumberOfWeekDaySchedulesSupportedPerUser for the Week-day schedule support.

      • NumberOfYearDaySchedulesSupportedPerUser for the Year-day schedule support.

      • NumberOfHolidaySchedulesSupported for the Holiday schedule support.

    5. In the Door Lock context window, go to the Attribute Reporting page and enable all required attribute reporting entries:

      • NumberOfWeekDaySchedulesSupportedPerUser for the Week-day schedule support.

      • NumberOfYearDaySchedulesSupportedPerUser for the Year-day schedule support.

      • NumberOfHolidaySchedulesSupported for the Holiday schedule support.

    6. In the Door Lock context window, go to the Commands page and enable all required command entries:

      • For the Week-day schedule support:

        • SetWeekDaySchedule

        • GetWeekDaySchedule

        • GetWeekDayScheduleResponse

        • ClearWeekDaySchedule

      • For the Year-day schedule support:

        • SetYearDaySchedule

        • GetYearDaySchedule

        • GetYearDayScheduleResponse

        • ClearYearDaySchedule

      • For the Holiday schedule support:

        • SetHolidaySchedule

        • GetHolidaySchedule

        • GetHolidayScheduleResponse

        • ClearHolidaySchedule

  2. In the Door Lock context window, go to the Attributes tab and set the proper bits for the FeatureMap attribute:

    • For the Week-day schedule support set the 5th bit of the feature map bit map.

    • For the Year-day schedule support set the 11th bit of the feature map bit map.

    • For the Holiday schedule support set the 12th bit of the feature map bit map.

  3. Enable Time Synchronization cluster with all needed types in the ZAP file:

    1. In ZAP Tool GUI, select the endpoint 0 and enable the Time Synchronization cluster, with both server and client roles, for that endpoint.

    2. Click the Configure symbol for the Time Synchronization cluster entry.

    3. In the Time Synchronization context window, go to the Attributes tab and enable all required attributes:

      • UTCTime.

      • Granularity.

      • TimeZone.

      • DSTOffset.

      • LocalTime.

      • TimeZoneDatabase.

      • TimeZoneListMaxSize.

      • DSTOffsetListMaxSize.

      • TrustedTimeSource.

    4. In the Time Synchronization context window, go to the Attribute Reporting page and enable all available attribute reporting entries.

    5. In the Time Synchronization context window, go to the Commands page and enable all required command entries:

      • SetUTCTime.

      • SetTimeZone.

      • SetTimeZoneResponse.

      • SetDSTOffset.

      • SetTrustedTimeSource.

  4. In the Time Synchronization context window, go to the Attributes tab and set the proper bits for the FeatureMap attribute:

    • For the TimeZone support, set the 0th bit of the feature map bit map.

    • For the TimeSyncClient support, set the 3rd bit of the feature map bit map.

    As a result, the default decimal value of the FeatureMap should be 9.

  5. Save the lock.zap file, and close ZAP-tool.

  6. Generate new ZAP files with the changes in the Door Lock cluster using the following west command:

    west zap-generate
    
  7. Enable the Lock Schedules feature in the nRF Connect SDK Matter Lock sample by setting the CONFIG_LOCK_SCHEDULES Kconfig option to y.

  8. Enable the Read Client support in the nRF Connect SDK Matter Lock sample by setting the CONFIG_CHIP_ENABLE_READ_CLIENT Kconfig option to y.

  9. Use the following Kconfig options to modify the maximum number of specific schedule types:

    • CONFIG_LOCK_MAX_WEEKDAY_SCHEDULES_PER_USER to define the maximum number of Week-day schedules for one user.

    • CONFIG_LOCK_MAX_YEARDAY_SCHEDULES_PER_USER to define the maximum number of Year-day schedules for one user.

    • CONFIG_LOCK_MAX_HOLIDAY_SCHEDULES to define the maximum number of Holiday schedules.

To learn more about configuring the Matter clusters, see the Adding clusters to Matter application user guide.

All scheduled timed access entries are saved to non-volatile memory and loaded automatically after device reboot. To disable the feature, you need to revert all changes in the lock.zap file, re-generate the ZAP files and set the CONFIG_LOCK_SCHEDULES Kconfig option to n.

Note

Adding a single schedule for a user contributes to the settings partition memory occupancy increase.

Testing remote access with PIN code credential

Note

You can test the PIN code credential support with any Matter compatible controller. The following steps use the CHIP Tool controller as an example. For more information about setting user credentials, see the Saving users and credentials on door lock devices section of the Working with the CHIP Tool page in the Matter documentation set.

After building the sample and programming it to your development kit, complete the following steps to test remote access with PIN code credential:

  1. 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.

  2. 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.

  3. Wait until the device boots.

  4. Commission an accessory with node ID equal to 10 to the Matter network by following the steps described in the Commissioning the device section.

  5. Make the door lock require a PIN code for remote operations:

    ./chip-tool doorlock write require-pinfor-remote-operation 1 10 1 --timedInteractionTimeoutMs 5000
    
  6. Add the example Home door lock user:

    ./chip-tool doorlock set-user 0 2 Home 123 1 0 0 10 1 --timedInteractionTimeoutMs 5000
    

    This command creates a Home user with a unique ID of 123 and an index of 2. The new user’s status is set to 1, and both its type and credential rule to 0. The user is assigned to the door lock cluster residing on endpoint 1 of the node with ID 10.

  7. Add the example 12345678 PIN code credential to the Home user:

    ./chip-tool doorlock set-credential 0 '{"credentialType": 1, "credentialIndex": 1}' 12345678 2 null null 10 1 --timedInteractionTimeoutMs 5000
    
  8. Unlock the door lock with the given PIN code:

    ./chip-tool doorlock unlock-door 10 1 --PINCode 12345678 --timedInteractionTimeoutMs 5000
    
  9. Reboot the device.

  10. Wait until the device it rebooted and attached back to the Matter network.

  11. Unlock the door lock with the PIN code provided before the reboot:

    ./chip-tool doorlock unlock-door 10 1 --PINCode 12345678 --timedInteractionTimeoutMs 5000
    

Note

Accessing the door lock remotely without a valid PIN code credential will fail.

Testing scheduled timed access

Note

You can test Scheduled timed access using any Matter compatible controller. The following steps use the CHIP Tool controller as an example.

After building the sample with the feature enabled and programming it to your development kit, complete the following steps to test scheduled timed access:

  1. 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.

  2. 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.

  3. Wait until the device boots.

  4. Commission an accessory with node ID equal to 10 to the Matter network by following the steps described in the Commissioning the device section.

  5. Add the example Home door lock user:

    ./chip-tool doorlock set-user 0 2 Home 123 1 0 0 10 1 --timedInteractionTimeoutMs 5000
    

    This command creates a Home user with a unique ID of 123 and an index of 2. The new user’s status is set to 1, and both its type and credential rule to 0. The user is assigned to the door lock cluster residing on endpoint 1 of the node with ID 10.

  6. Set the example Week-day schedule using the following command:

    ./chip-tool doorlock set-week-day-schedule weekday-index user-index days-mask start-hour start-minute end-hour end-minute destination-id endpoint-id
    • weekday-index is the index of the new schedule, starting from 1. The maximum value is defined by the CONFIG_LOCK_MAX_WEEKDAY_SCHEDULES_PER_USER Kconfig option.

    • user-index is the user index defined for the user created in the previous step.

    • days-mask is a bitmap of numbers of the week days starting from 0 as a Sunday and finishing at 6 as a Saturday. For example, to assign this schedule to Tuesday, Thursday and Saturday you need to provide 84 because it is equivalent to the 01010100 bitmap.

    • start-hour is the starting hour for the week day schedule.

    • start-minute is the starting minute for the week day schedule.

    • end-hour is the ending hour for the week day schedule.

    • end-minute is the ending hour for the week day schedule.

    • destination-id is the device node ID.

    • endpoint-id is the Matter door lock endpoint, in this sample assigned to 1.

    For example, use the following command to set a Week-day schedule with index 1 for Tuesday, Thursday and Saturday to start at 7:30 AM and finish at 10:30 AM, dedicated for user with ID 2:

    ./chip-tool doorlock set-week-day-schedule 1 2 84 7 30 10 30 1 1
    
  7. Set the example Year-day schedule using the following command:

    ./chip-tool doorlock set-year-day-schedule yearday-index user-index localtime-start localtime-end destination-id endpoint-id
    • yearday-index is the index of the new schedule, starting from 1. The maximum value is defined by the CONFIG_LOCK_MAX_YEARDAY_SCHEDULES_PER_USER Kconfig option.

    • user-index is the user index defined for the user created in the previous step.

    • localtime-start is the starting time in Epoch Time.

    • localtime-end is the ending time in Epoch Time.

    • destination-id is the device node ID.

    • endpoint-id is the Matter door lock endpoint, in this sample assigned to 1.

    Both localtime-start and localtime-end are in seconds with the local time offset based on the local timezone and DST offset on the day represented by the value.

    For example, use the following command to set a Year-day schedule with index 1 to start on Monday, May 27, 2024, at 7:00:00 AM GMT+02:00 DST and finish on Thursday, May 30, 2024, at 7:00:00 AM GMT+02:00 DST dedicated for user with ID 2:

    .. code-block:: console
    

    ./chip-tool doorlock set-year-day-schedule 1 2 1716786000 1717045200 1 1

  8. Set the example Holiday schedule using the following command:

    ./chip-tool doorlock set-holiday-schedule holiday-index localtime-start localtime-end operating-mode destination-id endpoint-id
    • holiday-index is the index of the new schedule, starting from 1.

    • localtime-start is the starting time in Epoch Time.

    • localtime-end is the ending time in Epoch Time.

    • operating-mode is the operating mode described in the Scheduled timed access section of this guide.

    • destination-id is the device node ID.

    • endpoint-id is the Matter door lock endpoint, in this sample assigned to 1.

    For example, use the following command to setup a Holiday schedule with the operating mode Vacation to start on Monday, May 27, 2024, at 7:00:00 AM GMT+02:00 DST and finish on Thursday, May 30, 2024, at 7:00:00 AM GMT+02:00 DST:

    ./chip-tool doorlock set-holiday-schedule 1 1716786000 1717045200 1 1 1
    
  9. Read saved schedules using the following commands and providing the same arguments you used in the earlier steps:

    ./chip-tool doorlock get-week-day-schedule weekday-index user-index destination-id endpoint-id
    ./chip-tool doorlock get-year-day-schedule yearday-index user-index destination-id endpoint-id
    ./chip-tool doorlock get-holiday-schedule holiday-index destination-id endpoint-id

Testing switching between Thread and Wi-Fi

Note

You can only test Thread and Wi-Fi switching on the nRF5340 DK with the nRF7002 EK shield attached, using the switched Thread and Wi-Fi configuration.

To test this feature, complete the following steps:

  1. Build the door lock application using the switched Thread and Wi-Fi configuration:

    west build -b nrf5340dk/nrf5340/cpuapp -- -DFILE_SUFFIX=thread_wifi_switched -Dlock_SHIELD=nrf7002ek -Dipc_radio_SHIELD=nrf7002ek_coex -DSB_CONFIG_WIFI_NRF700X=y
    
  2. 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.

  3. Program the application to the kit using the following command:

    west flash --erase
    
  4. Wait until the device boots.

  5. Find the following log message which indicates that Wi-Fi transport protocol is activated:

    D: 423 [DL]Starting Matter over Wi-Fi
    
  6. Press Button 3 for more than ten seconds to trigger switching from one transport protocol to the other.

  7. Wait until the operation is finished and the device boots again.

  8. Find the following log message which indicates that Thread transport protocol is activated:

    D: 423 [DL]Starting Matter over Thread
    

Testing door lock using Bluetooth LE with Nordic UART Service

To test the Matter Bluetooth LE with Nordic UART Service feature, complete the following steps:

Note

Some of the steps depend on which configuration the sample was built with.

  1. Install nRF Toolbox on your Android (Android 11 or newer) or iOS (iOS 16.1 or newer) smartphone.

  2. Build the door lock application for Matter over Thread with the CONFIG_CHIP_NUS set to y. For example, if you build from command line for the nrf52840dk/nrf52840, use the following command:

    west build -b nrf52840dk/nrf52840 -- -DCONFIG_CHIP_NUS=y
    
  3. Program the application to the kit using the following command:

    west flash --erase
    
  4. If you built the sample with the debug configuration, connect the board to an UART console to see the log entries from the device.

  5. Open the nRF Toolbox application on your smartphone.

  6. Select Universal Asynchronous Receiver/Transmitter UART from the list in the nRF Toolbox application.

  7. Tap on Connect. The application connects to the devices connected through UART.

  8. Select MatterLock_NUS from the list of available devices. The Bluetooth Pairing Request with an input field for passkey appears as a notification (Android) or on the screen (iOS).

  9. Depending on the configuration you are using:

    • For the release configuration: Enter the passkey 123456.

    • For the debug configuration, complete the following steps:

      1. Search the device’s logs to find PROVIDE THE FOLLOWING CODE IN YOUR MOBILE APP: phrase.

      2. Read the randomly generated passkey from the console logs.

      3. Enter the passcode on your smartphone.

  10. Wait for the Bluetooth LE connection to be established between the smartphone and the DK.

  11. In the nRF Toolbox application, add the following macros:

    • Lock as the Command value type Text and any image.

    • Unlock as the Command value type Text and any image.

  12. Tap on the generated macros and to change the lock state.

The Bluetooth LE connection between a phone and the DK will be suspended when the commissioning to the Matter network is in progress or there is an active session of SMP DFU.

To read the current door lock state from the device, read the Bluetooth LE RX characteristic. The new lock state is updated after changing the state from any of the following sources: NUS, buttons, Matter stack.

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: