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
nRF7002 DK	PCA10143	nrf7002dk	`nrf7002dk/nrf5340/cpuapp`
nRF54H20 DK	PCA10175	nrf54h20dk	`nrf54h20dk/nrf54h20/cpuapp`	`nrf700x_nrf54h20dk`
nRF5340 DK	PCA10095	nrf5340dk	`nrf5340dk/nrf5340/cpuapp`	`nrf7002ek`

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

An additional development kit compatible with one of the following Bluetooth LE samples:
- Bluetooth: Peripheral LBS
- Bluetooth: Peripheral ESP
A micro-USB cable for every development kit to connect it to the PC.

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:

CONFIG_BRIDGE_ONOFF_LIGHT_BRIDGED_DEVICE to n to disable On/Off Light.
CONFIG_BRIDGE_GENERIC_SWITCH_BRIDGED_DEVICE to n to disable Generic Switch
CONFIG_BRIDGE_TEMPERATURE_SENSOR_BRIDGED_DEVICE to n to disable Temperature Sensor.
CONFIG_BRIDGE_HUMIDITY_SENSOR_BRIDGED_DEVICE to n to disable Humidity Sensor.

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:

CONFIG_BRIDGE_GENERIC_SWITCH_BRIDGED_DEVICE to n to disable Generic Switch.
CONFIG_BRIDGE_ONOFF_LIGHT_SWITCH_BRIDGED_DEVICE to y to enable On/Off Light Switch.

The application supports over-the-air (OTA) device firmware upgrade (DFU) using either of the two following protocols:

Matter OTA update protocol. Querying and downloading a new firmware image is done using the Matter operational network.
Simple Management Protocol (SMP) over Bluetooth LE. The DFU is done using either 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.

Matter OTA update protocol is enabled by default. To configure the application to support the DFU over both 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:

west build -b board_target -- dfu_build_flag

Replace board_target with the board target name of the hardware platform you are using (see Requirements), and dfu_build_flag with the desired DFU build flag. For example:

west build -b nrf7002dk/nrf5340/cpuapp -- -DCONFIG_CHIP_DFU_OVER_BT_SMP=y

For information about how to upgrade the device firmware using a PC or a smartphone, see the Upgrading the device firmware section.

Note

Currently the DFU over Bluetooth LE SMP and Matter OTA are not available for the nrf54h20dk/nrf54h20/cpuapp board target.

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 Environmental Sensing Service - 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.

Remote testing in a network 

By default, the Matter accessory device has no IPv6 network configured. To use the device within a Wi-Fi network, you must pair it with the Matter controller over Bluetooth® LE to get the configuration from the controller.

The Bluetooth LE advertising starts automatically upon device startup, but only for a predefined period of time (1 hour by default). If the Bluetooth LE advertising times out, you can re-enable it manually (see the User interface section).

Additionally, the controller must get the Onboarding information from the Matter accessory device and provision the device into the network. For details, see the Testing section.

User interface 

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:

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

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:

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.

Button 0:

Depending on how long you press the button:

If pressed for less than three seconds:
- If the device is not provisioned to the Matter network, it initiates the SMP server (Simple Management Protocol) and Bluetooth LE advertising for Matter commissioning. After that, the Device Firmware Update (DFU) over Bluetooth Low Energy can be started. (See Upgrading the device firmware.) Bluetooth LE advertising makes the device discoverable over Bluetooth LE for the predefined period of time (1 hour by default).
- If the device is already provisioned to the Matter network, it re-enables the SMP server. After that, the DFU over Bluetooth Low Energy can be started. (See Upgrading the device firmware.)
If pressed for more than three seconds, it initiates the factory reset of the device. Releasing the button within a 3-second window of the initiation cancels the factory reset procedure.

Button 1:

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

LED 0:

Shows the overall state of the device and its connectivity. The following states are possible:

Short Flash On (50 ms on/950 ms off) - The device is in the unprovisioned (unpaired) state and is waiting for a commissioning application to connect.
Rapid Even Flashing (100 ms on/100 ms off) - The device is in the unprovisioned state and a commissioning application is connected over Bluetooth LE.
Solid On - The device is fully provisioned.

LED 1:

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.

Matter CLI commands 

You can use the following commands to control the Matter bridge device:

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)

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"

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.

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

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.

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

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

Configuration 

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

Configuration options 

Check and configure the following configuration options:

CONFIG_BRIDGED_DEVICE_IMPLEMENTATION

Select bridged device implementation. See the Bridged device configuration section for more information. Accepts the following values:

CONFIG_BRIDGED_DEVICE_SIMULATED: Implement a simulated bridged device. You must also configure CONFIG_BRIDGED_DEVICE_SIMULATED_ONOFF_IMPLEMENTATION

CONFIG_BRIDGED_DEVICE_BT: Implement a Bluetooth LE bridged device.

CONFIG_BRIDGE_HUMIDITY_SENSOR_BRIDGED_DEVICE: Enable support for Humidity Sensor bridged device.

CONFIG_BRIDGE_ONOFF_LIGHT_BRIDGED_DEVICE: Enable support for OnOff Light bridged device.

CONFIG_BRIDGE_SWITCH_BRIDGED_DEVICE

Enable support for a switch bridged device. Accepts the following values:

CONFIG_BRIDGE_GENERIC_SWITCH_BRIDGED_DEVICE: Enable support for Generic Switch bridged device.

CONFIG_BRIDGE_ONOFF_LIGHT_SWITCH_BRIDGED_DEVICE: Enable support for OnOff Light Switch bridged device.

CONFIG_BRIDGE_TEMPERATURE_SENSOR_BRIDGED_DEVICE: Enable support for Temperature Sensor bridged device.

If you selected the simulated device implementation using the CONFIG_BRIDGED_DEVICE_SIMULATED Kconfig option, also check and configure the following option:

CONFIG_BRIDGED_DEVICE_SIMULATED_ONOFF_IMPLEMENTATION

Select the simulated OnOff device implementation. Accepts the following values:

CONFIG_BRIDGED_DEVICE_SIMULATED_ONOFF_AUTOMATIC: Automatically simulated OnOff device. The simulated device automatically changes its state periodically.

CONFIG_BRIDGED_DEVICE_SIMULATED_ONOFF_SHELL: Shell-controlled simulated OnOff device. The state of the simulated device is changed using shell commands.

If you selected the Bluetooth LE device implementation using the CONFIG_BRIDGED_DEVICE_BT Kconfig option, also check and configure the following options:

CONFIG_BRIDGE_BT_MAX_SCANNED_DEVICES: Set the maximum number of scanned devices.

CONFIG_BRIDGE_BT_MINIMUM_SECURITY_LEVEL: Set the minimum Bluetooth security level of bridged devices that the bridge device will accept. Bridged devices using this or a higher level will be allowed to connect to the bridge. See the Configuring the Bluetooth LE security section for more information.

CONFIG_BRIDGE_BT_RECOVERY_MAX_INTERVAL: Set the maximum time (in seconds) between recovery attempts when the Bluetooth LE connection to the bridged device is lost.

CONFIG_BRIDGE_BT_RECOVERY_SCAN_TIMEOUT_MS: Set the time (in milliseconds) within which the Bridge will try to re-establish a connection to the lost Bluetooth LE device.

CONFIG_BRIDGE_BT_SCAN_TIMEOUT_MS: Set the Bluetooth LE scan timeout in milliseconds.

The following options affect how many bridged devices the application supports. See the Bridged device configuration section for more information.

CONFIG_BRIDGE_MAX_BRIDGED_DEVICES_NUMBER: Set the maximum number of physical non-Matter devices supported by the Bridge.

CONFIG_BRIDGE_MAX_DYNAMIC_ENDPOINTS_NUMBER: Set the maximum number of dynamic endpoints supported by the Bridge.

Bridged device configuration 

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

CONFIG_BRIDGED_DEVICE_SIMULATED - For the simulated bridged device.
CONFIG_BRIDGED_DEVICE_BT - For the Bluetooth LE bridged device.

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:

CONFIG_BRIDGE_MAX_BRIDGED_DEVICES_NUMBER - For changing the maximum number of non-Matter bridged devices supported by the bridge application
CONFIG_BRIDGE_MAX_DYNAMIC_ENDPOINTS_NUMBER - For changing the maximum number of Matter endpoints used for bridging devices by the bridge application. This option does not have to be equal to CONFIG_BRIDGE_MAX_BRIDGED_DEVICES_NUMBER, as it is possible to use non-Matter devices that are represented using more than one Matter endpoint.

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. The current maximum number of Bluetooth LE connections that can be selected using the default configuration is 10.

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 can increase the number of Bluetooth LE connections if you decrease the size of the Bluetooth LE TX/RX buffers used by the Bluetooth controller, but this will decrease the communication throughput.

Build the target using the following command in the project directory to enable a configuration that increases the number of Bluetooth LE connections to 20 by decreasing the size of Bluetooth LE TX/RX buffers:

west build -b nrf5340dk/nrf5340/cpuapp -p -- -Dmatter_bridge_SHIELD=nrf7002ek -DSB_CONFIG_WIFI_PATCHES_EXT_FLASH_STORE=y -DSB_CONFIG_DFU_MULTI_IMAGE_PACKAGE_WIFI_FW_PATCH=y -DSB_CONFIG_WIFI_NRF700X=y -Dmcuboot_CONFIG_UPDATEABLE_IMAGE_NUMBER=3 -DCONFIG_BRIDGED_DEVICE_BT=y -DEXTRA_CONF_FILE="overlay-bt_max_connections_app.conf" -Dipc_radio_EXTRA_CONF_FILE="overlay-bt_max_connections_net.conf" -DFILE_SUFFIX=nrf70ek

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

You can increase the number of Bluetooth LE connections if you decrease the size of the Bluetooth LE TX/RX buffers used by the Bluetooth controller, but this will decrease the communication throughput.

Build the target using the following command in the project directory to enable a configuration that increases the number of Bluetooth LE connections to 20 by decreasing the sizes of Bluetooth LE TX/RX buffers:

west build -b nrf54h20dk/nrf54h20/cpuapp -p -- -DSB_CONFIG_WIFI_NRF700X=y -DCONFIG_CHIP_WIFI=y -Dmatter_bridge_SHIELD=nrf700x_nrf54h20dk -DCONFIG_BRIDGED_DEVICE_BT=y -DEXTRA_CONF_FILE="overlay-bt_max_connections_app.conf" -Dipc_radio_EXTRA_CONF_FILE="overlay-bt_max_connections_net.conf"

You can increase the number of Bluetooth LE connections if you decrease the size of the Bluetooth LE TX/RX buffers used by the Bluetooth controller, but this will decrease the communication throughput.

Build the target using the following command in the project directory to enable a configuration that increases the number of Bluetooth LE connections to 20 by decreasing the sizes of Bluetooth LE TX/RX buffers:

west build -b nrf54h20dk/nrf54h20/cpuapp -p -- -DCONFIG_BRIDGED_DEVICE_BT=y -DEXTRA_CONF_FILE="overlay-bt_max_connections_app.conf" -Dipc_radio_EXTRA_CONF_FILE="overlay-bt_max_connections_net.conf"

The nRF70 Series supports the Matter bridge over Wi-Fi configuration.

You can increase the number of Bluetooth LE connections if you decrease the size of the Bluetooth LE TX/RX buffers used by the Bluetooth controller, but this will decrease the communication throughput.

Build the target using the following command in the project directory to enable a configuration that increases the number of Bluetooth LE connections to 20 by decreasing the sizes of Bluetooth LE TX/RX buffers:

west build -b nrf7002dk/nrf5340/cpuapp -- -DCONFIG_BRIDGED_DEVICE_BT=y -DEXTRA_CONF_FILE="overlay-bt_max_connections_app.conf" -Dipc_radio_EXTRA_CONF_FILE="overlay-bt_max_connections_net.conf"

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:

CONFIG_BRIDGE_BT_SCAN_WINDOW - The duration a central actively scans for devices within the scan interval.
CONFIG_BRIDGE_BT_SCAN_INTERVAL - Time between consecutive Bluetooth LE scan windows.
CONFIG_BRIDGE_BT_CONNECTION_INTERVAL_MIN - The minimum time requested by the central (the bridge) after which the peripheral device should wake up to communicate.
CONFIG_BRIDGE_BT_CONNECTION_INTERVAL_MAX - The maximum time requested by the central (the bridge) after which the peripheral device should wake up to communicate.
CONFIG_BRIDGE_BT_CONNECTION_TIMEOUT - The time since the last packet was successfully received until the devices consider the connection lost.
CONFIG_BRIDGE_BT_CONNECTION_LATENCY - Allows the peripheral to skip waking up for a certain number of connection events if it does not have any data to send.

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.

Matter bridge custom configurations 

The Matter bridge application uses a prj.conf configuration file located in the application root directory for the default configuration. It also provides additional files for different custom configurations. When you build the application, you can select one of these configurations using the FILE_SUFFIX variable.

See Custom configurations and Providing CMake options for more information.

The application supports the following configurations:

Matter bridge 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.
Matter bridge over Wi-Fi with nRF5340 DK and nRF7002 EK	—	`nrf70ek`	nRF5340 DK with the nRF7002 EK shield attached	Debug version of the application with Matter over Wi-Fi enabled. Enables the Matter Bridge to work with Wi-Fi on nRF5340 DK.

Building and running 

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.

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 -- -Dmatter_bridge_SHIELD=nrf7002ek -DSB_CONFIG_WIFI_PATCHES_EXT_FLASH_STORE=y -DSB_CONFIG_DFU_MULTI_IMAGE_PACKAGE_WIFI_FW_PATCH=y -DSB_CONFIG_WIFI_NRF700X=y -Dmcuboot_CONFIG_UPDATEABLE_IMAGE_NUMBER=3 -DFILE_SUFFIX=nrf70ek

To use the nRF54H20 DK with the nrf7002ek shield (2.4 GHz or 5 GHz), follow the Developing with nRF7002 EB user guide to connect all required pins. Once connected, run the following command to build the sample:

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

Selecting a configuration 

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

Configure the functionality of the Matter-Bridge device

To enable the Matter smart plugin functionality, run the following command with board_target replaced with the board target name:

west build -b board_target -p -- -Dmatter_bridge_SNIPPET=onoff_plug

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.

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.

Observe that the LED1 starts flashing (short flash on). This means that the sample has automatically started the Bluetooth LE advertising.

Commission the device to the Matter network. See Commissioning the device for more information. During the commissioning process, write down the value for the bridge node ID. This is going to be used in the next steps (<bridge_node_ID>).

Depending on the chosen bridged devices configuration, complete the steps in one of the following tabs:
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)
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>).
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 <bridge_node_ID> <bridged_device_endpoint_ID>
Build and program the one of the following Bluetooth LE samples to an additional development kit compatible with the sample:

Bluetooth: Peripheral LBS

Bluetooth: Peripheral ESP

Connect the development kit that is running the Bluetooth LE sample to the PC.

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.
Using the terminal emulator connected to the bridge, run the following Matter CLI command to scan for available Bluetooth LE devices:
uart:~$ matter_bridge scan
The terminal output is similar to the following one, with an entry for each connected Bluetooth LE device:
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)
Write down the value for the desired Bluetooth LE device index. This is going to be used in the next steps (<bluetooth_device_index>).
Using the terminal emulator connected to the bridge, run the following Matter CLI command to add a new bridged device:
uart:~$ matter_bridge add <bluetooth_device_index>
The <bluetooth_device_index> is a Bluetooth LE device index that was scanned in the previous step. For example, if you want to add a new Bluetooth LE bridged device with index 1, use the following command:
uart:~$ matter_bridge add 1
The terminal output is similar to the following one:
I: Connected: C7:44:0F:3E:BB:F0 (random)
----------------------------------------------------------------------------------------
| 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.    |
----------------------------------------------------------------------------------------
Write down the authentication pincode value from the Bluetooth LE bridged device terminal. The terminal output is similar to the following one:
Passkey for FD:D6:53:EB:92:3A (random): 350501
In the above example output, the displayed pincode value is 350501. It will be used in the next steps as <bluetooth_authentication_pincode>.
Insert the authentication pincode of the bridged device in the Matter bridge terminal. To insert the pincode, run the following Matter CLI command with <bluetooth_authentication_pincode> replaced by the value read in the previous step:
uart:~$ matter_bridge pincode <bluetooth_device_index> <bluetooth_authentication_pincode>
For example, if you want to add a new Bluetooth LE bridged device with index 1 and pincode 350501, use the following command:
uart:~$ matter_bridge pincode 1 350501
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
For the LED Button Service and the Environmental Sensor, two endpoints are created:

For the LED Button Service, one implements the On/Off Light device and the other implements the Generic Switch or On/Off Light Switch device.

For the Environmental Sensor, one implements the Temperature Sensor and the other implements the Humidity Sensor.
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>).
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 <bridge_node_ID> <bridged_device_endpoint_ID>
If you are using the Generic Switch implementation, read the value of the current-position attribute from the switch cluster using the following command:
./chip-tool switch read current-position <bridge_node_ID> <bridged_device_endpoint_ID>
Note that the Generic Switch is implemented as a momentary switch. This means that, in contrast to the latching switch, it remains switched on only as long as the physical button is pressed.

In case of the Environmental Sensor, the current temperature and humidity measurements forwarded by the Bluetooth LE Environmental Sensor can be read as follows:
temperature:
./chip-tool temperaturemeasurement read measured-value <bridge_node_ID> <bridged_device_endpoint_ID>
humidity:
./chip-tool relativehumiditymeasurement read measured-value <bridge_node_ID> <bridged_device_endpoint_ID>
Connect the kit to the computer using a USB cable. The kit is assigned a COM port (Windows) or ttyACM device (Linux), which is visible in the Device Manager.

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

Observe that the LED0 starts flashing (short flash on). This means that the sample has automatically started the Bluetooth LE advertising.

Commission the device to the Matter network. See Commissioning the device for more information. During the commissioning process, write down the value for the bridge node ID. This is going to be used in the next steps (<bridge_node_ID>).

Depending on the chosen bridged devices configuration, complete the steps in one of the following tabs:
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)
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>).
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 <bridge_node_ID> <bridged_device_endpoint_ID>
Build and program the one of the following Bluetooth LE samples to an additional development kit compatible with the sample:

Bluetooth: Peripheral LBS

Bluetooth: Peripheral ESP

Connect the development kit that is running the Bluetooth LE sample to the PC.

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.
Using the terminal emulator connected to the bridge, run the following Matter CLI command to scan for available Bluetooth LE devices:
uart:~$ matter_bridge scan
The terminal output is similar to the following one, with an entry for each connected Bluetooth LE device:
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)
Write down the value for the desired Bluetooth LE device index. This is going to be used in the next steps (<bluetooth_device_index>).
Using the terminal emulator connected to the bridge, run the following Matter CLI command to add a new bridged device:
uart:~$ matter_bridge add <bluetooth_device_index>
The <bluetooth_device_index> is a Bluetooth LE device index that was scanned in the previous step. For example, if you want to add a new Bluetooth LE bridged device with index 1, use the following command:
uart:~$ matter_bridge add 1
The terminal output is similar to the following one:
I: Connected: C7:44:0F:3E:BB:F0 (random)
----------------------------------------------------------------------------------------
| 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.    |
----------------------------------------------------------------------------------------
Write down the authentication pincode value from the Bluetooth LE bridged device terminal. The terminal output is similar to the following one:
Passkey for FD:D6:53:EB:92:3A (random): 350501
In the above example output, the displayed pincode value is 350501. It will be used in the next steps as <bluetooth_authentication_pincode>.
Insert the authentication pincode of the bridged device in the Matter bridge terminal. To insert the pincode, run the following Matter CLI command with <bluetooth_authentication_pincode> replaced by the value read in the previous step:
uart:~$ matter_bridge pincode <bluetooth_device_index> <bluetooth_authentication_pincode>
For example, if you want to add a new Bluetooth LE bridged device with index 1 and pincode 350501, use the following command:
uart:~$ matter_bridge pincode 1 350501
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
For the LED Button Service and the Environmental Sensor, two endpoints are created:

For the LED Button Service, one implements the On/Off Light device and the other implements the Generic Switch or On/Off Light Switch device.

For the Environmental Sensor, one implements the Temperature Sensor and the other implements the Humidity Sensor.
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>).
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 <bridge_node_ID> <bridged_device_endpoint_ID>
If you are using the Generic Switch implementation, read the value of the current-position attribute from the switch cluster using the following command:
./chip-tool switch read current-position <bridge_node_ID> <bridged_device_endpoint_ID>
Note that the Generic Switch is implemented as a momentary switch. This means that, in contrast to the latching switch, it remains switched on only as long as the physical button is pressed.

In case of the Environmental Sensor, the current temperature and humidity measurements forwarded by the Bluetooth LE Environmental Sensor can be read as follows:
temperature:
./chip-tool temperaturemeasurement read measured-value <bridge_node_ID> <bridged_device_endpoint_ID>
humidity:
./chip-tool relativehumiditymeasurement read measured-value <bridge_node_ID> <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:

Connect the kit to the computer using a USB cable. The kit is assigned a COM port (Windows) or ttyACM device (Linux), which is visible in the Device Manager.
Open a serial port connection to the kit using a terminal emulator that supports VT100/ANSI escape characters (for example, nRF Connect Serial Terminal). See Testing and optimization for the required settings and steps.
If the devices were not erased during the programming, press and hold Button 1 on each device until the factory reset takes place.
Commission the devices to the Matter network. See Commissioning the device for more information.

During the commissioning process, write down the values for the bridge node ID and the light bulb node ID. These IDs are going to be used in the next steps (<bridge_node_ID> and <light_bulb_node_ID>, respectively).
Add a bridged light switch device. Complete the following steps to use 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>).
1. Build and program the Peripheral LBS Bluetooth LE sample to an additional development kit.
2. Connect the development kit that is running the Bluetooth LE sample to the PC.
3. Using the terminal emulator connected to the bridge, run the following Matter CLI command to scan for available Bluetooth LE devices:
  uart:~$ matter_bridge scan
  The terminal output is similar to the following one, with an entry for each connected Bluetooth LE device:
  Scan result: --------------------------------------------------------------------- | Index | Address | UUID --------------------------------------------------------------------- | 0 | c7:44:0f:3e:bb:f0 | 0xbcd1 (Led Button Service)
4. Write down the value for the desired Bluetooth LE device index. This is going to be used in the next steps (<bluetooth_device_index>).
5. Using the terminal emulator connected to the bridge, run the following Matter CLI command to add a new bridged device:
```
uart:~$ matter_bridge add <bluetooth_device_index>
```
  The <bluetooth_device_index> is the Bluetooth LE device index that was scanned in the previous step. For example, if you want to add a new Bluetooth LE bridged device with index 0, use the following command:
  uart:~$ matter_bridge add 0
  The terminal output is similar to the following one:
  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 0x103 device type on the endpoint 4
6. Write down the value for the 0x103 bridged device dynamic endpoint ID. This is going to be used in the next steps (<bridged_light_switch_endpoint_ID>).

Use the CHIP Tool (“Writing ACL to the accesscontrol cluster” section) to 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 commissioning 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 by running the following command:

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

Complete the following steps depending on your configuration:
1. Using the terminal emulator connected to the bridge, turn on the LED 2 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 LED 2 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>
```
1. On the Peripheral LBS device, press Button 1 to turn on the LED 2 located on the bound light bulb device.
2. On the Peripheral LBS device, release Button 1 to turn off the light again.

Connect the kit to the computer using a USB cable. The kit is assigned a COM port (Windows) or ttyACM device (Linux), which is visible in the Device Manager.
Open a serial port connection to the kit using a terminal emulator that supports VT100/ANSI escape characters (for example, nRF Connect Serial Terminal). See Testing and optimization for the required settings and steps.
If the devices were not erased during the programming, press and hold Button 0 on each device until the factory reset takes place.
Commission the devices to the Matter network. See Commissioning the device for more information.

During the commissioning process, write down the values for the bridge node ID and the light bulb node ID. These IDs are going to be used in the next steps (<bridge_node_ID> and <light_bulb_node_ID>, respectively).
Add a bridged light switch device. Complete the following steps to use 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>).
1. Build and program the Peripheral LBS Bluetooth LE sample to an additional development kit.
2. Connect the development kit that is running the Bluetooth LE sample to the PC.
3. Using the terminal emulator connected to the bridge, run the following Matter CLI command to scan for available Bluetooth LE devices:
  uart:~$ matter_bridge scan
  The terminal output is similar to the following one, with an entry for each connected Bluetooth LE device:
  Scan result: --------------------------------------------------------------------- | Index | Address | UUID --------------------------------------------------------------------- | 0 | c7:44:0f:3e:bb:f0 | 0xbcd1 (Led Button Service)
4. Write down the value for the desired Bluetooth LE device index. This is going to be used in the next steps (<bluetooth_device_index>).
5. Using the terminal emulator connected to the bridge, run the following Matter CLI command to add a new bridged device:
```
uart:~$ matter_bridge add <bluetooth_device_index>
```
  The <bluetooth_device_index> is the Bluetooth LE device index that was scanned in the previous step. For example, if you want to add a new Bluetooth LE bridged device with index 0, use the following command:
  uart:~$ matter_bridge add 0
  The terminal output is similar to the following one:
  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 0x103 device type on the endpoint 4
6. Write down the value for the 0x103 bridged device dynamic endpoint ID. This is going to be used in the next steps (<bridged_light_switch_endpoint_ID>).

Use the CHIP Tool (“Writing ACL to the accesscontrol cluster” section) to 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 commissioning 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 by running the following command:

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

Complete the following steps depending on your configuration:
1. Using the terminal emulator connected to the bridge, turn on the LED 1 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 LED 1 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>
```
1. On the Peripheral LBS device, press Button 0 to turn on the LED 1 located on the bound light bulb device.
2. On the Peripheral LBS device, release Button 0 to turn off the light again.

Enabling remote control 

Remote control allows you to control the Matter bridge device from a Wi-Fi network.

Commissioning the device allows you to set up a testing environment and remotely control the sample over a Matter-enabled 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:

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

MT:06PS042C00KA0648G00

34970112332

Upgrading the device firmware 

To update the device firmware, complete the steps listed for the selected method in the Performing Device Firmware Upgrade in the nRF Connect examples tutorial in the Matter documentation.

Dependencies 

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

Matter

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

The application depends on the following Zephyr libraries: