Application guide

The Matter bridge application demonstrates how to use the Matter application layer to build a bridge device. You can use this application as a reference for creating your own application.

See the Matter Bridge page for more information about the Matter bridge specification and architecture.

Requirements

The application supports the following development kits:

Hardware platforms

PCA

Board name

Board target

Shields

nRF54LM20 DK

PCA10184

nrf54lm20dk

nrf54lm20dk/nrf54lm20b/cpuapp nrf54lm20dk/nrf54lm20a/cpuapp

nrf7002eb2

nRF5340 DK

PCA10095

nrf5340dk

nrf5340dk/nrf5340/cpuapp

To test the Matter bridge application with the Bluetooth® LE bridged device, you also need the following:

To commission the Matter bridge device and control it remotely through a Wi-Fi® network, you also need a Matter controller device configured on PC or smartphone. This requires additional hardware depending on your setup.

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 application uses buttons to control the device state and a single LED to show the state of a device. The Matter bridge has capability of representing non-Matter bridged devices as dynamic endpoints. The application supports bridging the following Matter device types:

  • On/Off Light

  • On/Off Light Switch

  • Generic Switch

  • Temperature Sensor

  • Humidity Sensor

If the Matter device type required by your use case is not supported, you can extend the application. For information about how to add a new bridged Matter device type to the application, see the Extending the application section.

Except for the On/Off Light Switch, all of the listed device types are enabled by default. To disable one of them, set any of the following configuration options:

Additionally, you can choose to use the On/Off Light Switch implementation instead of the Generic Switch implementation for a switch device. To enable the On/Off Light Switch implementation, set the following configuration options:

See Providing CMake options for instructions on how to add these options to your build.

The Matter bridge device has an additional functionality, enabling it to work as a smart plug. This feature provides an additional endpoint with an ID equal to 2, which represents Matter on/off smart plug device type functionality. This means that you can integrate the Matter bridge functionality into your end product, such as a smart plug, and avoid having to use a standalone bridge device. This is an optional feature and can be enabled by Configuring the smart plug functionality.

Bridged device support

The application supports two bridged device configurations that are mutually exclusive:

  • Simulated bridged device - This configuration simulates the functionality of bridged devices by generating pseudorandom measurement results and changing the light state in fixed-time intervals.

  • Bluetooth LE bridged device - This configuration allows to connect a real peripheral Bluetooth LE device to the Matter bridge and represent its functionalities using Matter Data Model. The application supports the following Bluetooth LE services:

    • Nordic Semiconductor’s LED Button Service - represented by the Matter On/Off Light and Generic Switch device types. The service can be configured to use the On/Off Light Switch instead of the Generic Switch device type.

    • Zephyr’s ESP Peripheral - represented by the Matter Temperature Sensor and Humidity Sensor device types.

If the Bluetooth LE service required by your use case is not supported, you can extend the application. For information about how to add a new Bluetooth LE service support to the application, see the Adding support for a new Bluetooth LE service section.

Depending on the bridged device you want to support in your application, enable it using the appropriate Kconfig option. The Matter bridge supports adding and removing bridged devices dynamically at application runtime using Matter CLI commands from a dedicated Matter bridge shell module.

User interface

This section describes the user interface available on the development kit in this application.

Buttons and LEDs map

This section explains the names of Buttons and LEDs visible on a board depending on the development kits that are used in this application user guide.

Buttons and LEDs map

DK family

First LED

Second LED

Third LED

Fourth LED

First Button

Second Button

Third Button

Fourth Button

nRF52 and nRF53 DKs

LED 1

LED 2

LED 3

LED 4

Button 1

Button 2

Button 3

Button 4

nRF54 DKs

LED 0

LED 1

LED 2

LED 3

Button 0

Button 1

Button 2

Button 3

nRF70 DKs

LED 1

LED 2

Not available

Not available

Button 1

Button 2

Not available

Not available

Development kit interface

This application implements the following interface available on a development kit. While reading the names, refer to the Buttons and LEDs map.

First Button:

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 Simple Management Protocol (SMP) server and Bluetooth LE advertising for Matter commissioning. After that, the Device Firmware Update (DFU) over Bluetooth Low Energy can be started. 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.

    • If pressed for more than three seconds, it initiates the factory reset of the device. Releasing the button within three seconds of the initiation cancels the factory reset procedure.

Second Button:

If pressed while the Matter smart plug functionality is enabled, the button changes the state of the smart plug device.

First LED:

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.

Second LED:

If the CONFIG_BRIDGED_DEVICE_BT Kconfig option is set to y, shows the current state of Bridge’s Bluetooth LE connectivity. The following states are possible:

  • Turned Off - The Bridge device is in the idle state and has no Bluetooth LE devices paired.

  • Solid On - The Bridge device is in the idle state and all connections to the Bluetooth LE bridged devices are stable.

  • Slow Even Flashing (1000 ms on / 1000 ms off) - The Bridge device lost connection to at least one Bluetooth LE bridged device.

  • Even Flashing (300 ms on / 300 ms off) - The scan for Bluetooth LE devices is in progress.

  • Fast Even Flashing (100 ms on / 100 ms off) - The Bridge device is connecting to the Bluetooth LE device and waiting for the Bluetooth LE authentication PIN code.

If used with the Matter smart plug functionality enabled, it shows the state of the smart plug device.

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 the device procedure while using a commercial ecosystem. See the Testing with commercial ecosystem section.

Matter CLI commands

Use the following commands to control the Matter bridge device:

To see all available subcommands via the CLI, use the following command:

matter_bridge help

Use the click to show on each command below to see the details.

matter_bridge add

Adding a simulated bridged device to the Matter bridge

Use the following command:

matter_bridge add <device_type> ["node_label"]

In this command:

  • <device_type> is the Matter device type to use for the bridged device. The argument is mandatory and accepts the following values:

    • 15 - Generic Switch.

    • 256 - On/Off Light.

    • 259 - On/Off Light Switch.

    • 770 - Temperature Sensor.

    • 775 - Humidity Sensor.

  • [“node label”] is the node label for the bridged device. The argument is optional and you can use it to better personalize the device in your application.

Example command:

uart:~$ matter_bridge add 256 "Kitchen Light"
matter_bridge remove

Removing a bridged device from the Matter bridge

Use the following command:

matter_bridge remove <bridged_device_endpoint_id>

In this command, <bridged_device_endpoint_id> is the endpoint ID of the bridged device to be removed.

Example command:

uart:~$ matter_bridge remove 3
matter_bridge list

Showing a list of all bridged devices and their endpoints

Use the following command:

matter_bridge list

The terminal output is similar to the following one:

Bridged devices list:
---------------------------------------------------------------------
| Endpoint ID |        Name        |           Type
---------------------------------------------------------------------
| 3           | My Light           | OnOffLight (0x0100)
| 4           | My Temperature     | TemperatureSensor (0x0302)
| 5           | My Humidity        | HumiditySensor (0x0307)
| 6           | My Light Switch    | OnOffLightSwitch (0x0103)
---------------------------------------------------------------------
Total: 4 device(s)
matter_bridge onoff

Controlling a simulated On/Off Light bridged device

Use the following command:

matter_bridge onoff <new_state> <endpoint>

In this command:

  • <new_state> is the new state (0 - off and 1 - on) that will be set on the simulated On/Off Light device.

  • <endpoint> is the endpoint on which the bridged On/Off Light device is implemented

Example command:

uart:~$ matter_bridge onoff 1 3

Note that the above command will only work if the CONFIG_BRIDGED_DEVICE_SIMULATED_ONOFF_SHELL option is selected in the build configuration. If the Kconfig option is not selected, the simulated device changes its state periodically in autonomous manner and cannot be controlled by using shell commands.

matter_bridge onoff_switch

Controlling a simulated On/Off Light Switch bridged device

Use the following command:

matter_bridge onoff_switch <new_state> <endpoint>

In this command:

  • <new_state> is the new state (0 - off and 1 - on) that will be set on the simulated On/Off Light Switch device.

  • <endpoint> is the endpoint on which the bridged On/Off Light Switch device is implemented

Example command:

uart:~$ matter_bridge onoff_switch 1 3
matter_bridge scan

Getting a list of Bluetooth LE devices available to be added

Use the following command:

matter_bridge scan

The terminal output is similar to the following one:

Scan result:
---------------------------------------------------------------------
| Index |      Address      |                   UUID
---------------------------------------------------------------------
| 0     | e6:11:40:96:a0:18 | 0x181a (Environmental Sensing Service)
| 1     | c7:44:0f:3e:bb:f0 | 0xbcd1 (Led Button Service)
matter_bridge add <bluetooth>

Adding a Bluetooth LE bridged device to the Matter bridge

Use the following command:

matter_bridge add <ble_device_index> ["node label"]

In this command:

  • <ble_device_index> is the Bluetooth LE device index on the list returned by the scan command. The argument is mandatory and accepts only the values returned by the scan command.

  • [“node label”] is the node label for the bridged device. The argument is optional and you can use it to better personalize the device in your application.

Example command:

uart:~$ matter_bridge add 0 "Kitchen Light"

The terminal output is similar to the following one:

----------------------------------------------------------------------------------------
| Bridged Bluetooth LE device authentication                                           |
|                                                                                      |
| Insert pin code displayed by the Bluetooth LE peripheral device                      |
| to authenticate the pairing operation.                                               |
|                                                                                      |
| To do that, use matter_bridge pincode <ble_device_index> <pincode> shell command.    |
----------------------------------------------------------------------------------------

To complete the adding process, you must use the pincode command to insert the authentication pincode displayed by the bridged device.

matter_bridge pincode

Inserting a Bluetooth LE authentication pincode

Use the following command:

matter_bridge pincode <ble_device_index> <ble_pincode>

In this command:

  • <ble_device_index> is the Bluetooth LE device index on the list returned by the scan command.

  • <ble_pincode> is the Bluetooth LE authentication pincode of the bridged device to be paired.

Example command:

uart:~$ matter_bridge pincode 0 305051

The terminal output is similar to the following one:

I: Pairing completed: E3:9D:5E:51:AD:14 (random), bonded: 1

I: Security changed: level 4
I: The GATT discovery completed
I: Added device to dynamic endpoint 3 (index=0)
I: Added device to dynamic endpoint 4 (index=1)
I: Created 0x100 device type on the endpoint 3
I: Created 0xf device type on the endpoint 4

Configuration

This section describes the configuration options for the application.

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

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.

Note

If you are working with multiple devices, set a unique discriminator for each one, or commission them one at a time. See Matter device identification for more information.

The application supports the following build configurations:

Matter bridge build 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.

Internal memory only

—

internal

nRF54LM20 DK

Debug version of the application with external flash disabled.

Enables the Matter bridge to work using internal memory only.

Bridged device configuration

You can enable the Bridged device support by using the following Kconfig options:

The simulated On/Off Light bridged device can operate in the following modes:

  • Autonomous - The simulated device periodically changes its state. To build the simulated On/Off Light data provider in this mode, select the CONFIG_BRIDGED_DEVICE_SIMULATED_ONOFF_AUTOMATIC Kconfig option.

  • Controllable - The user can explicitly control the On/Off state by using shell commands. To build the simulated On/Off Light data provider in this mode, select the CONFIG_BRIDGED_DEVICE_SIMULATED_ONOFF_SHELL Kconfig option. This is enabled by default.

Additionally, you can decide how many bridged devices the bridge application will support. The decision will make an impact on the flash and RAM memory usage, and is verified in the compilation stage. The application uses dynamic memory allocation and stores bridged device objects on the heap, so it may be necessary to increase the heap size using the CONFIG_CHIP_MALLOC_SYS_HEAP_SIZE Kconfig option. Use the following configuration options to customize the number of supported bridged devices:

The following configuration options are available, click on the toggle to see the details:

Configuring the number of Bluetooth LE bridged devices

You have to consider several factors to decide how many Bluetooth LE bridged devices to support. Every Bluetooth LE bridged device uses a separate Bluetooth LE connection, so you need to consider the number of supported Bluetooth LE connections (selected using the CONFIG_BT_MAX_CONN Kconfig option) when you configure the number of devices. Since the Matter stack uses one Bluetooth LE connection for commissioning, the maximum number of connections you can use for bridged devices is one less than is configured using the CONFIG_BT_MAX_CONN Kconfig option.

Increasing the number of Bluetooth LE connections affects the RAM usage on both the application and network cores.

You can configure the number of Bluetooth LE bridged devices depending on your device and configuration:

The nRF53 Series supports the Matter bridge over Wi-Fi and Matter bridge over Thread configurations.

You cannot increase the default number of Bluetooth LE connections in this configuration using overlays. This is because the configuration uses both Thread and Bluetooth LE protocols, and limited RAM memory. You can still increase the number of connections by modifying the board files and decreasing the buffer sizes. The default number of connections is 8, which effectively means 7 bridged devices.

Configuring Bluetooth LE connection and scan parameters

You can set your own Bluetooth LE connection parameters instead of accepting the default ones requested by the peripheral device. You can disable configuring the parameters by setting the CONFIG_BRIDGE_FORCE_BT_CONNECTION_PARAMS Kconfig option to n.

Use the following Kconfig options to set the desired parameters:

The parameters in this application have been selected based on the Bluetooth LE and Thread coexistence information in the Multiprotocol support section.

Configuring the Bluetooth LE security

The application uses Bluetooth LE Security Manager Protocol (SMP) to provide secure connection between the Matter bridge and Bluetooth LE bridged devices.

Note

Do not confuse the Bluetooth LE Security Manager Protocol (SMP) abbreviation with the Bluetooth LE Simple Management Protocol that has the same abbreviation and is used for the Device Firmware Upgrade process.

The following security levels are defined by the Bluetooth LE specification:

  • Security Level 1 - supports communication without security.

  • Security Level 2 - supports AES-CMAC communication encryption, but does not require device authentication.

  • Security Level 3 - supports AES-CMAC communication encryption, requires device authentication and pairing.

  • Security Level 4 - supports ECDHE communication encryption, requires authentication and pairing.

To read more about the Bluetooth LE security implementation in Zephyr, see the Security section of the Stack Architecture page. By default, the Matter bridge application has SMP enabled and supports security levels 2, 3 and 4.

You can disable the Bluetooth LE security mechanisms by setting the CONFIG_BT_SMP Kconfig option to n. This is strongly not recommended, as it leads to unencrypted communication with bridged devices, which makes them vulnerable to the security attacks.

You can select the minimum security level required by the application. When selected, the Matter bridge will require setting the selected minimum level from the connected Bluetooth LE bridged device. If the bridged device supports also levels higher than the selected minimum, the devices may negotiate using the highest shared security level. In case the bridged device does not support the minimum required level, the connection will be terminated. To select the minimum security level, set the CONFIG_BRIDGE_BT_MINIMUM_SECURITY_LEVEL Kconfig option to 2, 3 or 4.

Building and running

This section describes how to build the application and commission it to the Matter network.

This sample can be found under applications/matter_bridge in the nRF Connect SDK folder structure.

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

When building this application with Sysbuild for an SoC that has a network core, the IPC radio firmware is automatically applied to the build. The IPC radio is one of the companion components in the nRF Connect SDK and allows to use the radio peripheral from another core in a multicore device. If needed, you can modify the IPC radio configuration in the prj.conf source file in the application’s sysbuild/ipc_radio directory.

Before starting the commissioning procedure, make sure that the device is discoverable over Bluetooth LE. The device becomes discoverable automatically upon the device startup, but only for a predefined period of time (one hour by default). If the Bluetooth LE advertising times out, enable it again.

Advanced building options

This section describes advanced building options that you can use with this application. Use the click to show toggle to expand the content.

Building the Matter over Wi-Fi variant on nRF54LM20 DK with nRF7002-EB II shield

To build the Matter over Wi-Fi application variant on nRF54LM20 DK with nRF7002-EB II attached, perform the following actions depending on the build tool:

  1. When building an application as described in the nRF Connect for VS Code documentation, follow the steps for setting up the build configuration.

  2. In the Add Build Configuration screen, click the Add argument button under the Extra CMake argument section.

  3. Add the following Kconfig options:

    -DSHIELD=nrf7002eb2 -DSB_CONFIG_WIFI_NRF70=y -DCONFIG_CHIP_WIFI=y

Flashing the Matter over Wi-Fi sample variant

In the Matter over Wi-Fi variant of this sample, the portion of the application code related to the nRF70 Series Wi-Fi firmware is stored in the external memory. When you program the sample onto your development kit, the build process automatically includes the Wi-Fi firmware patch and programs it into the external memory.

By default, using the west flash command erases the entire external flash memory before writing the new Wi-Fi firmware patch. This full-chip erase ensures that the patch is written to a clean memory area, but it can significantly increase the programming time - sometimes taking several minutes, especially if the external flash is large.

To optimize the programming process and reduce the time required, you can instruct west flash to erase only the specific memory ranges that will be overwritten by the Wi-Fi firmware patch. This is done by adding the --ext-erase-mode=ranges argument to the command. With this option, only the necessary sections of external memory are erased, making the programming process faster.

To speed up programming, use the Flash button instead of Erase and Flash to Board in the Actions View. Using Erase and Flash to Board erases the entire external flash and can take several minutes.

To disable storing the Wi-Fi firmware patch in the external memory, complete the following steps:

  1. Remove the Wi-Fi firmware patch partition from the partition list.

  2. Set the SB_CONFIG_WIFI_PATCHES_EXT_FLASH_STORE Kconfig option to n.

  3. Set the SB_CONFIG_DFU_MULTI_IMAGE_PACKAGE_WIFI_FW_PATCH Kconfig option to n.

  4. Set the SB_CONFIG_MCUBOOT_UPDATEABLE_IMAGES Kconfig option to 2.

To learn more about the Wi-Fi firmware patch, see the Adding nRF70 Series firmware patch partitions user guide.

Matter smart plug functionality

To enable the Matter smart plug functionality:

Add -DEXTRA_CONF_FILE=onoff_plug.conf to Extra CMake arguments in your build configuration.

Testing

This section shows how to test the application. You can test it using your PC and the CHIP Tool for Linux or macOS or commercial ecosystem that supports Matter.

Testing with CHIP Tool

Complete the following steps to test the Matter bridge device using CHIP Tool.

Prepare Matter network

To set up the Matter network, configure your environment according to the protocol you are using. Choose the appropriate tab below and follow the corresponding steps to prepare your Matter network.

  1. Configure the Thread Border Router. See the Running OTBR using Docker section on the Thread Border Router page.

  2. Download the prebuilt CHIP tool package from the Matter nRF Connect releases GitHub page. Make sure that the package is compatible with your nRF Connect SDK version.

Prepare your DK

To flash your DK with the application and prepare it for testing, complete the following steps:

  1. Connect the kit to the computer using a USB cable. The kit is assigned a serial port. Serial ports are referred to as COM ports on Windows, /dev/ttyACM devices on Linux, and /dev/tty devices on macOS. To list Nordic Semiconductor devices connected to your computer together with their serial ports, open a terminal and run the nrfutil device list command. Alternatively, check your operating system’s device manager or its equivalent.

  2. Open a serial port connection to the kit using a terminal emulator that supports VT100/ANSI escape characters (for example, the Serial Terminal app). See Testing and optimization for the required settings and steps.

  3. If the device was not erased during the programming, perform the factory reset procedure.

    To restore the device settings and state to its factory set press the First Button for six seconds to initiate the factory reset of the device.

Commission to Matter network

To commission the device to the Matter network complete the following steps:

  1. Obtain a Thread active dataset from OTBR:

    1. Connect to the Raspberry Pi through USB or SSH.

    2. Run the following commands:

    sudo ot-ctl
> dataset active -x

    The output should look like:

    080000000000000000000300001735060004001fffe00208deadbeefcafe12340708fd123456789abc00000510112233445566778899aabbccddeeff00030a54657374576f726b3031010211220410aabbccddeeff00112233445566778899aa0c0402a0f7f8
Done

  2. Run the following command and fill the <thread dataset> argument obtain in the previous step:

    chip-tool pairing ble-thread 1 hex:<thread dataset> 20202021 3840

Communicate with bridged devices

Depending on the chosen bridged devices configuration, complete the steps in one of the following tabs:

  1. Using the terminal emulator connected to the bridge, run the following Matter CLI command to add a new bridged device:

    uart:~$ matter_bridge add <device_type>

    The <device_type> is the value of the Matter device type that will be used to represent a new bridged device in the Matter Data Model. See the description in Matter CLI commands for the list of supported values. For example, if you want to add a new bridged device that will be exposed as an On/Off Light endpoint, use the following command:

    uart:~$ matter_bridge add 256

    The terminal output is similar to the following one:

    I: Adding OnOff Light bridged device
I: Added device to dynamic endpoint 3 (index=0)

  2. Write down the value for the bridged device dynamic endpoint ID. This is going to be used in the next steps (<bridged_device_endpoint_ID>).

  3. Use the CHIP Tool to read the value of an attribute from the bridged device endpoint. For example, read the value of the on-off attribute from the onoff cluster using the following command:

    ./chip-tool onoff read on-off 1 <bridged_device_endpoint_ID>

Testing with bridged device working as a client

To test the bridged device working as a client, you need to enable On/Off Light Switch device support (see matter_bridge_app_overview). The On/Off Light Switch device is capable of controlling the On/Off Light state of another device, such as the Matter Light Bulb sample working on an additional development kit. After building this application and the Matter Light Bulb sample, and programming them to the development kits, complete the following steps to test the bridged device working as a client:

Commission the devices to the Matter network

Complete the first three steps from the Prepare Matter network section.

Use two different node ID values for the bridge and the light bulb device. Write down the values for the bridge and the light bulb device node IDs. These values are going to be used in the next steps (<bridge_node_ID> and <light_bulb_node_ID>).

Add a bridged light switch device

Complete the following steps to add a bridged light switch device using either a simulated or a Bluetooth LE device.

  1. Using the terminal emulator connected to the bridge, run the following Matter CLI command to add a new bridged device:

    uart:~$ matter_bridge add 259

    The terminal output is similar to the following one:

    I: Adding OnOff Light Switch bridged device
I: Added device to dynamic endpoint 3 (index=0)

  2. Write down the value for the bridged device dynamic endpoint ID. This is going to be used in the next steps (<bridged_light_switch_endpoint_ID>).

Add proper ACL for the light bulb device

Use the following command, with the <bridge_node_ID> and <light_bulb_node_ID> values from the first step:

chip-tool accesscontrol write acl '[{"fabricIndex": 1, "privilege": 5, "authMode": 2, "subjects": [112233], "targets": null}, {"fabricIndex": 1, "privilege": 3, "authMode": 2, "subjects": [<bridge_node_ID>], "targets": [{"cluster": 6, "endpoint": 1, "deviceType": null}, {"cluster": 8, "endpoint": 1, "deviceType": null}]}]' <light_bulb_node_ID> 0

Write a binding table to the bridge to inform the device about all endpoints

Use the following command, with the <bridge_node_ID> and <light_bulb_node_ID> values from the first step:

chip-tool binding write binding '[{"fabricIndex": 1, "node": <light_bulb_node_ID>, "endpoint": 1, "cluster": 6}]' <bridge_node_ID> <bridged_light_switch_endpoint_ID>

Control the light bulb device

Complete the following steps depending on your configuration:

  1. Using the terminal emulator connected to the bridge, turn on the Second LED located on the bound light bulb device, by running the following Matter CLI command:

    uart:~$ matter_bridge onoff_switch 1 <bridged_light_switch_endpoint_ID>

  2. Using the terminal emulator connected to the bridge, turn off the Second LED located on the bound light bulb device, by running the following Matter CLI command:

    uart:~$ matter_bridge onoff_switch 0 <bridged_light_switch_endpoint_ID>

Testing with commercial ecosystem

Before starting testing, ensure that the ecosystem supports the device types enabled in this application. See the ecosystem manual page for instructions on how to use it.

When you start the commissioning procedure, the ecosystem controller must get the onboarding information from the Matter accessory device. The onboarding information representation depends on your commissioner setup.

For this application, 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:

Matter bridge application onboarding information

QR Code

QR Code Payload

Manual pairing code

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

matter_qr_code_image

MT:Y.K9042C00KA0648G00

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.

Dependencies

This application uses the Matter library that includes the nRF Connect SDK platform integration layer:

In addition, the application uses the following nRF Connect SDK components:

The application depends on the following Zephyr libraries:

Subpages