Matter: Light switch

This light switch sample demonstrates the usage of the Matter (formerly Project Connected Home over IP, Project CHIP) application layer to build a switch device that binds with lighting devices and changes the state of their LEDs. When configured together with the Matter light bulb sample (or other lighting sample) and when using a Matter controller, the light switch can control one light bulb directly or a group of light bulbs remotely over a Matter network built on top of a low-power, 802.15.4 Thread network. You can use this sample as a reference for creating your own application.

Requirements 

The sample supports the following development kits:

Hardware platforms	PCA	Board name	Build target
nRF52840 DK	PCA10056	nrf52840dk_nrf52840	`nrf52840dk_nrf52840`
nRF5340 DK	PCA10095	nrf5340dk_nrf5340	`nrf5340dk_nrf5340_cpuapp`
nRF21540 DK	PCA10112	nrf21540dk_nrf52840	`nrf21540dk_nrf52840`

For this sample to work, you also need at least one Matter light bulb sample programmed to another supported development kit.

To commission the device and run all required commands, you need also a Matter controller. By default, this sample is configured to use the CHIP Tool as Matter controller. See the Working with the CHIP Tool page in the Matter documentation for the CHIP Tool’s setup information.

If you decide to use Matter CLI support, you also need a USB cable for the serial connection.

Note

Matter requires the GN tool. If you are updating from the nRF Connect SDK version earlier than v1.5.0, see the GN installation instructions.

Overview 

The sample controls the state of the LED 2 on connected light bulbs devices. After configuring the light switch sample, the lighting devices get proper Access Control List from the Matter controller to start receiving commands sent from the light switch. Then, the light switch device prepares a new binding table to be able to discover light bulb devices and perform Binding.

After the binding is complete, the application can control the state of the connected lighting devices in one of the following ways:

With a single light bulb, it uses a Certificate-Authenticated Session Establishment session (CASE session) for direct communication with the single light bulb.
With a group of light bulbs, it uses multicast messages sent through the Thread network using Group communication with all light bulbs in the group.

Access Control List 

The Access Control List (ACL) is a list related to the Access Control cluster. The list contains rules for managing and enforcing access control for a node’s endpoints and their associated cluster instances. In this sample’s case, this allows the lighting devices to receive messages from the light switch and run them.

You can read more about ACLs on the Access Control Guide in the Matter documentation.

Group communication 

Group communication (groupcast or multicast) refers to messages and commands sent to the address of a group that includes multiple devices with the same Groups cluster. The cluster manages the content of a node-wide Group Table that is part of the underlying interaction layer. This is done on per endpoint basis. After creating the Group cluster with specific ID and Name, a device gets its own IPv6 multicast Thread address and is ready to receive groupcast commands.

In this sample, the light switch device is able to create a groupcast message and send it to the chosen IPv6 multicast Thread address. This allows the light switch more than one lighting devices at the same time.

Note

Writing the groupcast table on the devices blocks sending unicast commands. If you want to go back to the original state, perform factory reset of the device.

Binding 

Binding refers to establishing a relationship between endpoints on the local and remote nodes. With binding, local endpoints are pointed and bound to the corresponding remote endpoints. Both must belong to the same cluster type. Binding lets the local endpoint know which endpoints are going to be the target for the client-generated actions on one or more remote nodes.

In this sample, the light switch controls one or more lighting devices, but does not know the remote endpoints of the lights (on remote nodes). Using binding, the light switch device updates its Binding cluster with all relevant information about the lighting devices, such as their IPv6 Thread address, node ID, and the IDs of the remote endpoints that contains the On/Off cluster and the LevelControl cluster, respectively.

Configuration 

See Configuring your application for information about how to permanently or temporarily change the configuration.

Matter light switch build types 

The sample uses different configuration files depending on the supported features. Configuration files are provided for different build types and they are located in the configuration/<board_name> directory.

The prj.conf file represents a debug build type. Other build types are covered by dedicated files with the build type added as a suffix to the prj part, as per the following list. For example, the release build type file name is prj_release.conf. If a board has other configuration files, for example associated with partition layout or child image configuration, these follow the same pattern.

When the CONF_FILE variable contains a single file and this file follows the naming pattern prj_<buildtype>.conf, then the build type will be inferred to be <buildtype>. The build type cannot be set explicitly. The <buildtype> can be any string, but it is common to use release and debug.

For information about how to set variables, see Important Build System Variables in the Zephyr documentation.

The Partition Manager’s static configuration can also be made dependent on the build type. When the build type has been inferred, the file pm_static_<buildtype>.yml will have precedence over pm_static.yml.

The child image Kconfig configuration can also be made dependent on the build type. The child image Kconfig file is named <child_image>.conf instead of prj.conf, but otherwise follows the same pattern as the parent Kconfig.

Before you start testing the application, you can select one of the build types supported by the sample. This sample supports the following build types, depending on the selected board:

debug – Debug version of the application - can be used to enable additional features for verifying the application behavior, such as logs or command-line shell.
release – Release version of the application - can be used to enable only the necessary application functionalities to optimize its performance.
no_dfu – Debug version of the application without Device Firmware Upgrade feature support - can be used only for the nRF52840 DK and nRF5340 DK, as those platforms have DFU enabled by default.

Note

Selecting a build type is optional. The debug build type is used by default if no build type is explicitly selected.

FEM support 

You can add support for the nRF21540 front-end module to this sample by using one of the following options, depending on your hardware:

Build the sample for one board that contains the nRF21540 FEM, such as nrf21540dk_nrf52840.
Manually create a devicetree overlay file that describes how FEM is connected to the nRF5 SoC in your device. See Set devicetree overlays for different ways of adding the overlay file.
Provide nRF21540 FEM capabilities by using a shield, for example the nRF21540 EK shield that is available in the nRF Connect SDK. In this case, build the project for a board connected to the shield you are using with an appropriate variable included in the build command. This variable instructs the build system to append the appropriate devicetree overlay file. For example, to build the sample from the command line for an nRF52833 DK with the nRF21540 EK attached, use the following command within the sample directory:
```
west build -b nrf52833dk_nrf52833 -- -DSHIELD=nrf21540_ek
```
This command builds the application firmware. See Programming nRF21540 EK for information about how to program when you are using a board with a network core, for example nRF5340 DK.

Each of these options adds the description of the nRF21540 FEM to the devicetree. See Working with RF front-end modules for more information about FEM in the nRF Connect SDK.

To add support for other front-end modules, add the respective devicetree file entries to the board devicetree file or the devicetree overlay file.

Matter CLI support 

The Matter CLI allows to run commands through the serial interface using the USB cable connected to the USB port on Nordic Semiconductor’s development kit.

To enable the Matter CLI, you must build the light switch application with the additional option -DCONFIG_CHIP_LIB_SHELL=y. Use the following command pattern, with <build-target> replaced with the build target name of Nordic Semiconductor’s development kit you are using (see Requirements):

west build -b <build-target> -- -DCONFIG_CHIP_LIB_SHELL=y

For example:

west build -b nrf52840dk_nrf52840_cpuapp -- -DCONFIG_CHIP_LIB_SHELL=y

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 and nRF5340 DK support Device Firmware Upgrade feature.

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

Matter OTA update protocol that uses the Matter operational network for querying and downloading a new firmware image.
Simple Management Protocol (SMP) over Bluetooth® LE. In this case, the DFU can be done either using a smartphone application or a PC command line tool. Note that this protocol is not part of the Matter specification.

In both cases, MCUboot secure bootloader is used to apply the new firmware image.

The DFU over Matter is enabled by default. To configure the sample to support the DFU over Matter and SMP, use the -DOVERLAY_CONFIG=../../overlay-smp_dfu.conf build flag during the build process. To configure the sample to disable the DFU and the secure bootloader, use the -DCONF_FILE=prj_no_dfu.conf build flag during the build process.

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

When building on the command line, run the following command with build_target replaced with the build target name of the hardware platform you are using (see Requirements), and dfu_build_flag replaced with the desired DFU build flag:

west build -b build_target -- dfu_build_flag

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 Bluetooth LE Direct Firmware Update (DFU) process.

Off - Bluetooth LE is not advertising and DFU is not ready.
Rapid Even Flashing (30 ms off / 170 ms on) - Bluetooth LE is advertising and the DFU process can be started.

LED 3:

Identifies the device after sending the identify command to the endpoint 0 from the Matter controller device. The LED starts blinking evenly (500 ms on/500 ms off) when the Identify command of the Identify cluster is received. The command’s argument can be used to specify the duration of the effect.

LED 1-4:

Blink in unison when the factory reset procedure is initiated.

Button 1:

Depending on how long you press the button:

If pressed for less than three seconds, it initiates the SMP server (Security Manager Protocol). After that the Direct Firmware Update (DFU) over Bluetooth Low Energy can be started. (see Upgrading the device firmware).
If pressed for more than three seconds, it initiates the factory reset of the device. Releasing the button within the 3-second window cancels the factory reset procedure.

Button 2:

Controls the light on the bound lighting device. Depending on how long you press the button:

If pressed for less than 0.5 seconds, it changes the light state to the opposite one on the bound lighting device (light bulb).
If pressed for more than 0.5 seconds, it changes the brightness of the light on the bound lighting bulb device (light bulb). The brightness is changing from 0% to 100% with 1% increments every 300 milliseconds as long as Button 2 is pressed.

Button 4:

Starts the NFC tag emulation, enables Bluetooth LE advertising for the predefined period of time (15 minutes by default), and makes the device discoverable over Bluetooth LE. This button is used during the commissioning procedure.

SEGGER J-Link USB port:: Used for getting logs from the device or for communicating with it through the command-line interface.

NFC port with antenna attached:: Optionally used for obtaining the commissioning information from the Matter accessory device to start the commissioning procedure.

Matter CLI commands 

If you build the application with the Matter CLI support, you can use a series of commands to control the light switch device. These commands can be sent to one device (unicast) or a group of devices (groupcast).

Unicast commands

You can use the following commands for direct communication with the single lighting device:

switch onoff on

This command turns on LED 2 on the bound lighting device. For example:

uart:~$ matter switch onoff on

switch onoff off

This command turns off LED 2 on the bound lighting device. For example:

uart:~$ matter switch onoff off

switch onoff toggle

This command changes the LED 2 state to the opposite one on the bound lighting device. For example:

uart:~$ matter switch onoff toggle

Groupcast commands

You can use the following commands a group of devices that are programmed with the Light Switch Example application by using the Matter CLI:

switch groups onoff on

This command turns on LED 2 on each bound lighting device connected to the same group. For example:

uart:~$ matter switch groups onoff on

switch groups onoff off

This command turns off LED 2 on each bound lighting device connected to the same group. For example:

uart:~$ matter switch groups onoff off

switch groups onoff toggle

This command changes the LED 2 state to the opposite one on each bound lighting device connected to the same group. For example:

uart:~$ matter switch groups onoff toggle

Building and running 

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

See Building and programming an application for information about how to build and program the application.

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

Selecting a build type 

Before you start testing the application, you can select one of the Matter light switch build types, depending on your building method.

Selecting a build type in nRF Connect for Visual Studio Code

To select the build type in the nRF Connect for Visual Studio Code extension:

When Building an application as described in the nRF Connect for Visual Studio Code extension documentation, follow the steps for setting up the build configuration.
In the Add Build Configuration screen, select the desired .conf file from the Configuration drop-down menu.
Fill in other configuration options, if applicable, and click Build Configuration.

Selecting a build type from command line

To select the build type when building the application from command line, specify the build type by adding the following parameter to the west build command:

-- -DCONF_FILE=prj_selected_build_type.conf

For example, you can replace the selected_build_type variable to build the release firmware for nrf52840dk_nrf52840 by running the following command in the project directory:

west build -b nrf52840dk_nrf52840 -d build_nrf52840dk_nrf52840 -- -DCONF_FILE=prj_release.conf

The build_nrf52840dk_nrf52840 parameter specifies the output directory for the build files.

Note

If the selected board does not support the selected build type, the build is interrupted. For example, if the shell build type is not supported by the selected board, the following notification appears:

File not found: ./ncs/nrf/samples/matter/light_switch/configuration/nrf52840dk_nrf52840/prj_shell.conf

Testing 

After building the sample and programming it to your development kit, complete the steps in the following sections.

Prepare for testing 

After building this and the Matter Light Bulb samples, and programming them to the development kits, complete the following steps:

Note

In both samples (light switch and light bulb), a Bluetooth LE discriminator is set with the same value by default (hexidecimal: 0xF00; decimal: 3840). This means that only one uncommissioned device can be powered up before commissioning. If both are powered up at the same time, the CHIP Tool can commission a random device and the node ID assignment is also random. When one device is commissioned, power up the next device and perform the commissioning. To avoid this unclear situation, you can set up your unique discriminator in src/chip_project_config.h file by changing CHIP_DEVICE_CONFIG_USE_TEST_SETUP_DISCRIMINATOR value. Then build an example and commission with your unique discriminator.

Connect the kit to the computer using a USB cable. The kit is assigned a COM port (Windows) or ttyACM device (Linux), which is visible in the Device Manager.
Connect to the kit with a terminal emulator that supports VT100/ANSI escape characters (for example, PuTTY). See How to connect with PuTTY for the required settings.
If devices were not erased during the programming, press and hold Button 1 on each device until the factory reset takes place.
On each device, press Button 4 to start the Bluetooth LE advertising.
Commission devices to the Matter network. See Commissioning the device for more information. During the commissioning process, write down the values for the light switch node ID and the light bulb node ID (or IDs, if you are using more than one light bulb). These IDs are going to be used in the next steps (<light_switch_node_ID> and <light_bulb_node_ID>, respectively).

Use the CHIP Tool (“Writing ACL to the accesscontrol cluster” section) to add proper ACL for the light bulb device. Run the following command, with <light_switch_node_ID> and <light_bulb_node_ID> values from the previous step about commissioning:

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

If you are using more than one light bulb device, connect all devices to the multicast group by running the following command for each device, including the light switch:
```
chip-tool tests TestGroupDemoConfig --nodeId <node_ID>
```
Use the <node_ID> values from the commissioning step.

Write a binding table to the light switch to inform the device about all endpoints by running this command (only for light switch):

For unicast binding to bind the light switch with only one light Bulb:

chip-tool binding write binding '[{"fabricIndex": 1, "node": <light bulb node id>, "endpoint": 1, "cluster": 6}, {"fabricIndex": 1, "node": <light bulb node id>, "endpoint": 1, "cluster": 8}]' <light switch node id> 1

For groupcast binding to bind the light switch with multiple light bulbs:

chip-tool binding write binding '[{"fabricIndex": 1, "group": 257}]' <light_switch_node_ID> 1

All devices are now bound and ready for testing communication.

Note

In this sample, the ACL cluster is inserted into the light bulb’s endpoint 0, and the Binding cluster is inserted into the light switch’s endpoint 1.

Testing with bound light bulbs devices 

After preparing devices for testing, you can test the communication of a single light bulb or a group of light bulbs with the light switch, but not both a single device and a group at the same time.

Complete the following steps:

On the light switch device, use buttons to control the bound light bulbs:
1. On the light switch device, press Button 2 to turn off the LED 2 located on the bound light bulb device.
2. On the light switch device, press Button 2 to turn on the light again. LED 2 on the light bulb device turns back on.
3. Press Button 2 and hold it for more than 0.5 seconds to test the dimmer functionality. LED 2 on the bound light bulb device changes its brightness from 0% to 100% with 1% increments every 300 milliseconds as long as Button 2 is pressed.
Using the terminal emulator connected to the light switch, run the following Matter CLI commands:
1. Write the following command to turn on LED 2 located on the bound light bulb devices:
  - For a single bound light bulb:
    matter switch onoff on
  - For a group of light bulbs:
    matter switch groups onoff on
2. Write the following command to turn on LED 2 located on the bound light bulb device:
  - For a single bound light bulb:
    matter switch onoff off
  - For a group of light bulbs:
    matter switch groups onoff off

Commissioning the device 

To commission the device, go to the Configuring Matter development environment guide and complete the steps for the Matter controller you want to use. The guide walks you through the following steps:

Configure the Thread Border Router.
Build and install the Matter controller.
Commission the device.
Send Matter commands that cover scenarios described in the Testing section.

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

Before starting the commissioning procedure, the device must be made discoverable over Bluetooth LE. By default, the device is not discoverable automatically upon startup and Button 4 must be used to enable the Bluetooth LE advertising.

When you start the commissioning procedure, the controller must get the commissioning information from the Matter accessory device. The data payload includes the device discriminator and setup PIN code. It is encoded within a QR code printed to the UART console and can be shared using an NFC tag.

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 in the Matter documentation.

Dependencies 

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

Matter

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

DK Buttons and LEDs

The sample depends on the following Zephyr libraries: