The Arm Mbed OS Lighting Example demonstrates how to remotely control a dimmable white light source. The example takes advantage of the IO available on board:
You can use this example as a reference for creating your own application.
The example is based on Matter and Arm Mbed OS, and supports remote access and control of lighting over a WiFi network.
The example behaves as a Matter accessory, in other words a device that can be paired into an existing Matter network and can be controlled by this network.
Pigweed functionalities are also integrated into this application. The Remote Procedure Call (RPC) server is created. It allows sending commands through the serial port to the device. The following RPC protocols services are available:
The Matter device that runs the lighting application is controlled by the Matter controller device over WiFi. By default, the Matter device is disconnected , and it should be paired with Matter controller and get configuration from it. Actions required before establishing full communication are described below.
To commission the device onto a Matter network, the device must be discoverable over BLE. The BLE advertising starts automatically after device boot-up.
In Matter, the commissioning procedure (called rendezvous) is done over BLE between a Matter device and the Matter controller, where the controller has the commissioner role.
To start the rendezvous, the controller must get the commissioning information from the Matter device. The data payload is encoded within a QR code, printed to the UART console.
The last part of the rendezvous procedure, provisioning involves sending the network credentials from the Matter controller to the Matter device. As a result, device is able to join the network and communicate with other devices in the network.
Before building the example, check out the Matter repository and sync submodules using the following command:
$ git submodule update --init
Building the example application requires the use of ARM Mbed-OS sources and the arm-none-gnu-eabi toolchain. The OpenOCD package is used for flashing purpose.
Some additional packages may be needed, depending on selected build target and its requirements.
The VSCode devcontainer has these components pre-installed. Using the VSCode devcontainer is the recommended way to interact with Arm Mbed-OS port of the Matter Project.
Please read this README.md for more information about using VSCode in container.
To initialize the development environment, download all registered sub-modules and activate the environment:
$ source ./scripts/bootstrap.sh $ source ./scripts/activate.sh
If packages are already installed then you just need to activate the development environment:
$ source ./scripts/activate.sh
The Lighting application can be built in the same way as any other Matter example ported to the mbed-os platform.
Command Palette (F1) => Run Task... => Run Mbed Application => build => lighting-app => (board name) => (build profile)
${MATTER_ROOT}/scripts/examples/mbed_example.sh -c=build -a=lighting-app -b=<board name> -p=<build profile>
Both approaches are limited to supported evaluation boards which are listed in Supported devices paragraph.
Mbed OS defines three building profiles: develop, debug and release. For more details please visit ARM Mbed OS build profiles.
When using the building script, it is possible expand the list of acceptable targets; this may be useful for rapid testing of a new mbed-targets.
The Lighting application can be flashed in the same way as any other Matter example ported to mbed-os platform.
The Open On-Chip Debugger is used to upload a binary image and reset the device.
Command Palette (F1) => Run Task... -> Run Mbed Application => flash => lighting-app => (board name) => (build profile)
${MATTER_ROOT}/scripts/examples/mbed_example.sh -c=flash -a=lighting-app -b=<board name> -p=<build profile>
Run and Debug (Ctrl+Shift+D) => Flash Mbed examples => Start Debugging (F5) => (board name) => lighting-app => (build profile)
The last option uses the Open On-Chip Debugger to open and manage the gdb-server session. Then gdb-client (arm-none-eabi-gdb) upload binary image and reset device.
It is possible to connect to an external gdb-server session by using specific ‘Flash Mbed examples [remote]’ task.
Debugging can be performed in the same was as with any other Matter example ported to mbed-os platform.
The Open On-Chip Debugger is used to to open and manage the gdb-server session. Then gdb-client (arm-none-eabi-gdb) connect the server to upload binary image and control debugging.
Run and Debug (Ctrl+Shift+D) => Debug Mbed examples => Start Debugging (F5) => (board name) => lighting-app => (build profile)
It is possible to connect to an external gdb-server session by using specific ‘Debug Mbed examples [remote]’ task.
The application traces are streaming to serial output. To start communication open a terminal session and connect to the serial port of the device. You can use mbed-tools for this purpose (mbed-tools):
mbed-tools sterm -p /dev/ttyACM0 -b 115200 -e off
After device reset these lines should be visible:
[INFO][CHIP]: [-]Mbed lighting-app example application start ... [INFO][CHIP]: [-]Mbed lighting-app example application run
The lighting-app application launched correctly and you can follow traces in the terminal.
Read the MbedCommissioning to see how to use different CHIP tools to commission and control the application within a WiFi network.
The RPC console is an interactive Python shell console, where the different RPC command can be invoked. It is a complete solution for interacting with hardware devices using pw_rpc over a pw_hdlc transport. For more details about Pigweed modules visit Pigweed modules.
Building and installing
To build and install the RPC console check the guide CHIP RPC console.
Run
To start the RPC console run the following command and provide device connection parameters as arguments:
Example:
python -m chip_rpc.console -d /dev/ttyUSB0 -b 115200 -o /tmp/pw_rpc.out
To control the lighting type the following command, where you define if ‘on’ state is true or false:
In [1]: rpcs.chip.rpc.Lighting.Set(on=True)
The response from the device should be:
Out[1]: (Status.OK, pw.protobuf.Empty())
To check the lighting state type the following command:
In [1]: rpcs.chip.rpc.Lighting.Get()
The response from the device should contain the current lighting state:
Out[1]: Status.OK, chip.rpc.LightingState(on=True))
For more details about RPC console and supported services visit CHIP RPC console.
The example supports building and running on the following mbed-enabled devices:
| Manufacturer | Hardware platform | Build target | Platform image | Status | Platform components |
|---|---|---|---|---|---|
| Cypress Semiconductor | CY8CPROTO-062-4343W | CY8CPROTO_062_4343W | CY8CPROTO-062-4343W | :heavy_check_mark: | LEDsBoard has only one usable LED (LED4) which corresponds to USER LED from UI.Lighting LED should be an external component connected to PB9_6 pin (active high). ButtonsSW2 push-button is not used in this example due to its interaction with WIFI module interrupt line.Button 0 corresponds to BTN0 capacitive button.Button 1 corresponds to BTN1 capacitive button. SliderThe board's touch slider corresponds to UI slider |
lighting-app/mbed/mbed_app.json.This section lists the User Interface elements that you can use to control and monitor the state of the device. These correspond to PCB components on the platform image.
USER LED shows the overall state of the device and its connectivity. The following states are possible:
Short Flash On (50 ms on/950 ms off) — The device is in the unprovisioned (unpaired) state and is waiting for a commissioning application to connect.
Rapid Even Flashing (100 ms on/100 ms off) — The device is in the unprovisioned state and a commissioning application is connected through Bluetooth LE.
Short Flash Off (950ms on/50ms off) — The device is fully provisioned, but does not yet have full network or service connectivity.
Solid On — The device is fully provisioned and has full network and service connectivity.
Lighting LED simulates the light bulb and shows the state of the lighting. The following states are possible:
Solid On — The light bulb is on.
Off — The light bulb is off.
PWM — The light bulb is dimmed according to PWM.
Button 0 can be used for the following purposes:
Pressed for 6 s — Initiates the factory reset of the device. Releasing the button within the 6-second window cancels the factory reset procedure. LEDs 1-4 blink in unison when the factory reset procedure is initiated.
Pressed for less than 3 s — Initiates the OTA software update process. This feature is not currently supported.
Button 1 — Pressing the button once changes the lighting state to the opposite one.
Slider — This touch control allows you to change PWM and therefore the dimming lighting state from the OFF state to maximum brightness corresponding to ON state. Currently the dimming resolution is set from 0-255 to satisfy ZCL 8 bit commands argument for lighting cluster.
Some of the supported boards may not have sufficient number PCB components to follow above description. In that case please refer to Supported devices section and check board's ‘Platform components’ column for additional information about the limitation.