Matter: Light bulb

This light bulb sample demonstrates the usage of the Matter application layer to build a white dimmable light bulb device. This device works as a Matter accessory device, meaning it can be paired and controlled remotely over a Matter network built on top of a low-power, 802.15.4 Thread network or on top of a Wi-Fi network. Support for both Thread and Wi-Fi is mutually exclusive and depends on the hardware platform, so only one protocol can be supported for a specific light bulb device. You can use this sample as a reference for creating your own application.

Note

This sample is self-contained and can be tested on its own. However, it is required when testing the Matter light switch sample.

The sample can also communicate with AWS IoT Core over a Wi-Fi network using the nRF7002 DK. For more details, see the AWS IoT integration section.

Requirements

The sample supports the following development kits:

Hardware platforms

PCA

Board name

Build target

Shields

nRF7002 DK

PCA10143

nrf7002dk_nrf5340

nrf7002dk_nrf5340_cpuapp

nRF54L15 PDK

PCA10156

nrf54l15pdk_nrf54l15

nrf54l15pdk_nrf54l15_cpuapp

nRF5340 DK

PCA10095

nrf5340dk_nrf5340

nrf5340dk_nrf5340_cpuapp

nrf21540ek_fwd nrf21540ek

nRF52840 DK

PCA10056

nrf52840dk_nrf52840

nrf52840dk_nrf52840

nrf21540ek

If you want to commission the light bulb device and control it remotely, you also need a Matter controller device configured on PC or mobile. This requires additional hardware depending on the setup you choose.

Note

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

IPv6 network support

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

  • Matter over Thread is supported for nrf52840dk_nrf52840, nrf5340dk_nrf5340_cpuapp, nrf21540dk_nrf52840, and nrf54l15pdk_nrf54l15.

  • Matter over Wi-Fi is supported for nrf5340dk_nrf5340_cpuapp with the nrf7002ek shield attached or for nrf7002dk_nrf5340_cpuapp.

Overview

The sample uses buttons to test changing the light bulb and device states, and LEDs to show the state of these changes. You can test it in the following ways:

  • Standalone, by using a single DK that runs the light bulb application.

  • Remotely over the Thread or Wi-Fi, which requires more devices.

The remote control testing requires a Matter controller that you can configure either on a PC or a mobile device (for remote testing in a network). You can enable both methods after building and running the sample.

Remote testing in a network

By default, the Matter accessory device has no IPv6 network configured. You must pair it with the Matter controller over Bluetooth® LE to get the configuration from the controller to use the device within a Thread or Wi-Fi network. The controller must get the Onboarding information from the Matter accessory device and provision the device into the network. For details, see the Commissioning the device section.

Configuration

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

Matter light bulb build types

The sample does not use a single prj.conf file. Configuration files are provided for different build types, and they are located in the sample root directory. Before you start testing the application, you can select one of the build types supported by the application.

See Custom build types and Configuring build types for more information about this feature of the nRF Connect SDK.

The sample supports the following build types:

Sample build types

Build type

File name

Supported board

Description

Debug (default)

prj.conf

All from Requirements

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

prj_release.conf

All from Requirements

Release version of the application; can be used to enable only the necessary application functionalities to optimize its performance.

Device Firmware Upgrade support

Note

You can enable over-the-air Device Firmware Upgrade only on hardware platforms that have external flash memory. Currently only nRF52840 DK, nRF5340 DK and nRF7002 DK support Device Firmware Upgrade feature.

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

  • Matter OTA update protocol that uses the Matter operational network for querying and downloading a new firmware image.

  • Simple Management Protocol (SMP) over Bluetooth® LE. In this case, the DFU can be done either using a smartphone application or a PC command line tool. Note that this protocol is not part of the Matter specification.

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

The DFU over Matter is enabled by default. The following configuration arguments are available during the build process for configuring DFU:

  • To configure the sample to support the DFU over Matter and SMP, use the -DCONFIG_CHIP_DFU_OVER_BT_SMP=y build flag.

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

For example:

west build -b nrf52840dk_nrf52840 -- -DCONFIG_CHIP_DFU_OVER_BT_SMP=y

FEM support

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

  • Build the sample for one board that contains the nRF21540 FEM, such as nrf21540dk_nrf52840.

  • Manually create a devicetree overlay file that describes how FEM is connected to the nRF5 SoC in your device. See Set devicetree overlays for different ways of adding the overlay file.

  • Provide nRF21540 FEM capabilities by using a shield, for example the nRF21540 EK shield that is available in the nRF Connect SDK. In this case, build the project for a board connected to the shield you are using with an appropriate variable included in the build command, for example SHIELD=nrf21540ek. This variable instructs the build system to append the appropriate devicetree overlay file.

    To build the sample in the nRF Connect for VS Code IDE for an nRF52840 DK with the nRF21540 EK attached, add the shield variable in the build configuration’s Extra CMake arguments and rebuild the build configuration. For example: -DSHIELD=nrf21540ek.

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

    See Programming nRF21540 EK for information about how to program when you are using a board with a network core, for example nRF5340 DK.

Each of these options adds the description of the nRF21540 FEM to the devicetree. See 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.

Factory data support

In this sample, the factory data support is enabled by default for all build types except for the target board nRF21540 DK. This means that a new factory data set will be automatically generated when building for the target board.

To disable factory data support, set the following Kconfig options to n:

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

AWS IoT integration

The sample can be configured to communicate with AWS IoT Core to control attributes in supported clusters on the device. After a connection has been established, the sample will mirror these attributes in the AWS IoT shadow document. This makes it possible to remotely control the device using the AWS IoT Device Shadow Service. The supported attributes are OnOff from the OnOff cluster and CurrentLevel from the LevelControl cluster.

The following figure illustrates the relationship between the AWS IoT integration layer and the light bulb sample:

Sample implementation of the AWS IoT integration layer

AWS IoT integration layer implementation diagram

The following figure illustrates the interaction with the AWS IoT shadow Service:

Interaction with the AWS IoT shadow service

AWS IoT Shadow and Matter interaction diagram

AWS IoT setup and configuration

To set up an AWS IoT instance and configure the sample, complete the following steps:

  1. Complete the setup and configuration described in the AWS IoT documentation to get the host name, device ID, and certificates used in the connection.

  2. Set the CONFIG_AWS_IOT_BROKER_HOST_NAME and CONFIG_AWS_IOT_CLIENT_ID_STATIC Kconfig options in the overlay-aws-iot-integration.conf file.

  3. Import the certificates to the light_bulb/src/aws_iot_integration/certs folder.

    The certificates will vary in size depending on the method you chose when generating the certificates. Due to this, you might need to increase the value of the CONFIG_MBEDTLS_SSL_OUT_CONTENT_LEN option to be able to establish a connection.

  4. Build the sample using the following command:

    west build -p -b nrf7002dk_nrf5340_cpuapp -- -DEXTRA_CONF_FILE="overlay-aws-iot-integration.conf"
    
  5. Flash the firmware and boot the sample.

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

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

  8. Commission the device to the Matter network. See Commissioning the device for more information.

  9. Observe that the device automatically connects to AWS IoT when an IP is obtained and the device is able to maintain the connection.

  10. Use the following bash function to populate the desired section of the shadow:

    function aws-update-desired() {
          aws iot-data update-thing-shadow --cli-binary-format raw-in-base64-out --thing-name my-thing --payload "{\"state\":{\"desired\":{\"onoff\":$1,\"level_control\":$2}}}" "output.txt"
    }
    

    You can also use aws-update-desired 0 0, or aws-update-desired 1 128 (onoff, levelcontrol). Alternatively, you can alter the device shadow directly through the AWS IoT console.

  11. Observe that the light bulb changes state. The local changes to the attributes always take precedence over what is set in the shadow’s desired state.

Note

The integration layer has built-in reconnection logic and tries to maintain the connection as long as the device is connected to the internet. The reconnection interval can be configured using the CONFIG_AWS_IOT_RECONNECTION_INTERVAL_SECONDS option.

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 light bulb. The following states are possible:

  • Solid On - The light bulb is on.

  • Off - The light bulb is off.

Additionally, the LED starts blinking evenly (500 ms on/500 ms off) when the Identify command of the Identify cluster is received on the endpoint 1. The command’s argument can be used to specify the duration of the effect.

Button 1:

Depending on how long you press the button:

  • If pressed for less than three seconds:

    • If the device is not provisioned to the Matter network, it initiates the SMP server (Simple Management Protocol) and Bluetooth LE advertising for Matter commissioning. After that, the Device Firmware Update (DFU) over Bluetooth Low Energy can be started. (See Upgrading the device firmware.) Bluetooth LE advertising makes the device discoverable over Bluetooth LE for the predefined period of time (15 minutes by default).

    • If the device is already provisioned to the Matter network it re-enables the SMP server. After that, the DFU over Bluetooth Low Energy can be started. (See Upgrading the device firmware.)

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

Button 2:
  • Changes the light bulb state to the opposite one.

SEGGER J-Link USB port:

Used for getting logs from the device or for communicating with it through the command-line interface.

NFC port with antenna attached:

Optionally used for obtaining the Onboarding information from the Matter accessory device to start the commissioning procedure.

Building and running

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

To build the sample with Visual Studio Code, follow the steps listed on the How to build an application page in the nRF Connect for VS Code extension documentation. See Configuring and building an application for other building scenarios, Programming an application for programming steps, and Testing and optimization for general information about testing and debugging in the nRF Connect SDK.

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 bulb build types. See Configuring build types for detailed steps how to select a build type.

Testing

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

You can either test the sample’s basic features or use the light switch sample to test the light bulb’s communication with another device.

Testing basic features

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

  1. Connect the kit to the computer using a USB cable. The kit is assigned a COM port (Windows) or ttyACM device (Linux), which is visible in the Device Manager.

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

  3. Observe that LED 2 is off.

  4. Press Button 2 on the light bulb device. The LED 2 turns on and the following messages appear on the console:

    I: Turn On Action has been initiated
    I: Turn On Action has been completed
    
  5. Press Button 2 again. The LED 2 turns off and the following messages appear on the console:

    I: Turn Off Action has been initiated
    I: Turn Off Action has been completed
    
  6. Keep the Button 1 pressed for more than six seconds to initiate factory reset of the device.

Testing communication with another device

After building this sample and the Matter light switch sample and programming them to the development kits, complete the steps in the following sections to test communication between both devices.

Bind both devices

Complete the following steps to bind both devices:

  1. Connect the kit to the computer using a USB cable. The kit is assigned a COM port (Windows) or ttyACM device (Linux), which is visible in the Device Manager.

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

  3. If devices were not erased during the programming, press and hold Button 1 on each device until the factory reset takes place.

  4. On each device, press Button 1 to start the Bluetooth LE advertising.

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

  6. Use the CHIP Tool (“Writing ACL to the accesscontrol cluster” section) to add proper ACL for the light bulb device. Depending on the number of the light bulb devices you are using, use one of the following commands, with <light_switch_node_ID> and <light_bulb_node_ID> values from the previous step about commissioning:

    • If you are using only one light bulb device, run the following command for the light bulb device:

      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.

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

After preparing devices for testing, you can test the communication either of a single light bulb or of 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:

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

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

Enabling remote control

Remote control allows you to control the Matter light bulb device from an IPv6 network.

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

Commissioning the device

To commission the device, go to the Testing Matter in the nRF Connect SDK page and complete the steps for the Matter over Thread or Matter over Wi-Fi development environment and the Matter controller you want to use. After choosing the environment configuration, the guide walks you through the following steps:

  • Configure the Thread Border Router (only for Matter over Thread communication).

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

Before starting the commissioning procedure, the device must be made discoverable over Bluetooth LE. The device becomes discoverable automatically upon the device startup, but only for a predefined period of time (15 minutes by default). If the Bluetooth LE advertising times out, press Button 1 to enable it again.

Onboarding information

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

For this sample, you can use one of the following onboarding information formats to provide the commissioner with the data payload that includes the device discriminator and the setup PIN code:

Light bulb sample onboarding information

QR Code

QR Code Payload

Manual pairing code

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

QR code for commissioning the light bulb device

MT:6FCJ142C00KA0648G00

34970112332

When the factory data support is enabled, the onboarding information will be stored in the build directory in the following files:

  • The factory_data.png file includes the generated QR code.

  • The factory_data.txt file includes the QR Code Payload and the manual pairing code.

This data payload also includes test Device Attestation, with test Certification Declaration, Product ID, and Vendor ID. These are used for Device Attestation within commissioning, and you can generate your own test Certification Declaration when you work on Matter end product.

Upgrading the device firmware

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

Dependencies

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

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

The sample depends on the following Zephyr libraries: