Hands-on Matter - The Matter Light Switch (Part 3)

Tim Conrad – Senior Security Consultant

15 February 2023

In Part 1 and Part 2 we took a look at the basic concepts and walked through the all-cluster app for an example matter device and turned a light on and off using our CLI. Now we will implement a matter light switch that will do this for us to complete our setup.

Note:
This blog post is written for developers and other people with a technical background and interest in a security focused overview of Matter.

Attention:
Please note, that the Matter code open source, so a lot and examples and tools might change through out the process. We will do everything on Ubuntu 20.04. For other systems, we will provide the link to the original document in the Matter repository.

To set up the light switch, first pull the newest changes from the matter repository and set up the light switch example as follows:

# Only perform this if you do not have the esp idf tool setup already.
mkdir ${HOME}/tools
cd ${HOME}/tools
git clone https://github.com/espressif/esp-idf.git
cd esp-idf
git checkout v4.4
git submodule update --init
./install.sh
. ./export.sh

# Move to your matter repo
cd ~/connectedhomeip
git pull

# This will remove your environmental settings just in case you have errors during the activate.
rm -r .environment 

# Bootstrap and activate Matter repo
source ./scripts/bootstrap.sh
source ./scripts/activate.sh

# Move to example
cd examples/light-switch-app/esp32

# Set the target
idf.py set-target esp32

# Build the app
idf.py build

# Flash it to your device
idf.py -p /dev/ttyUSB0 flash monitor

Now we have the light switch flashed with the firmware, to continue we need to add the device as an existing node to our fabric like we have done in Part 2 with the chip-tool.

./chip-tool pairing ble-wifi 12344320 "IoT Testing" NotTheRealPassword 20202021 3840

Note:
You might notice that the pin and discriminator are the same as the one from the all-cluster app. This is just for simplicity here because these are the values pre-configured in the repository. In a real world scenario, the both would be different to avoid commissioning conflicts. Here, you need to commission the two devices after one another to avoid that.

Note:
If you have trouble to write the ACL to the light (all-cluster-app) this might be because you rebooted at some point and the chip-tool has lost its certificates. The certificates are stored in /tmp/chip* and are not persistent after reboot. If you wish to continue make a copy of them to restore them to any given point.

The light switch will have the Node ID 12344320 (and the all-cluster-app had the Node ID 12344321).

Now we need to provide the all-cluster-app [12344321] with an access control list (ACL) that allows the light-switch _[12344320] to access the on-off-cluster (Endpoint 1, Cluster 6). Then we will take a closer look at the following command:

./chip-tool accesscontrol write acl '[{"fabricIndex": 1, "privilege": 5, "authMode": 2, "subjects": [112233], "targets": null },{"fabricIndex": 1, "privilege": 3, "authMode": 2, "subjects": [12344320], "targets": null }]' 12344321 0

The comments explain the used ACL a bit closer:

[{
    "fabricIndex": 1, // Symbolizes the fabric to which the ACL belongs (important for multi-fabric usage)
    "privilege": 5, // 5 refers to highest privilege (Administer)
    "authMode": 2, // CASE authentication (1 - PASE authentication)
    "subjects": [112233], // Refers to the chip-tool node id
    "targets": null // null means wildcard therefore all endpoints are targets
}, {
    "fabricIndex": 1,
    "privilege": 3, // 3 - Operate
    "authMode": 2, // CASE authentication
    "subjects": [12344320], // Node ID of the light switch
    "targets": null // wildcard, operate all endpoints
}]

The Node Id 12344321 (all-cluster-app) and the endpoint 0 are reserved for matter protocol-specific clusters, e.g., binding, pairing, etc.

Basically, the first ACL was provided by the commissioning process and allows our CLI tool (chip-tool) to access and administer the two devices. The second ACL gives the light-switch the access to operate the on-off cluster (or in this case all clusters). (These are too many rights and should be limited in production use, but for an example, it is okay.)

./chip-tool binding write binding '[{"fabricIndex": 1, "node":12344321, "endpoint":1, "cluster":6}]' 12344320 1

The binding will tell the light switch where it can operate:

[{
    "fabricIndex": 1, // Symbolizes the fabric to which the ACL belongs
    "node": 12344321, // Node of the light (all-cluster-app)
    "endpoint": 1, // Endpoint of the on-off-cluster
    "cluster": 6 // on-off-cluster
}]

Now you can press the boot button on the light ESP (close to the USB-Port) and you will see the light turn on.

This concludes our series, we have now a fully working example end to end. Our two Matter devices communicate with each other and we learned about all basic concepts to start working on our own ideas.

In Part 4 we will take a step further and look at Matter Bridges, this will be especially interesting for all that already own or maintain an existing smart home system.

Do you have any questions or would you like to realise a Matter project?

Patrick Sernetz – Head of Solution Architecture

Hi, I'm Patrick. Do you have any questions about Matter? Feel free to contact me by e-mail.

contact expert