Battery Powered Multi-Purpose Matter Beacons

Smart Homes often require too many types of sensors from multiple manufacturers. The interoperability between the multiple vendors is not great, forcing the users to use multiple ecosystems in parallel. The battery life of devices is often to short, as they are often wasting battery life by too much wireless transmission activity.

With combing multiple sensors into a single beacon the number and type of sensors in a smart home can be significantly reduced. For ex we can have temperature sensor, an ambient light sensor and microphone in an single device.

By using Matter we can leverage the data from all these sensors to build smart solutions for different use cases, even if the sensors used share a common device.

In this project I will present a Multi-purpose Smart Sensor Beacon solutions, built over the Nordic Thingy:53 platform. Each sensor beacon will expose multiple sensors via Matter. Machine learning models powered by Edge Impulse will be used to enhance the devices with smart functionality.

The nRF5340 DK and nRF7002 DK development kits will be used to demonstrate Matter over Thread and WiFi 6. The Power Profiler Kit II will be used to measure power consumption of various power saving modes and mechanisms.

The Matter Standard

Matter is a fairly new IoT connectivity standard meant to improve the interoperability between smart home devices from different manufacturers. The standards also defines strict security requirements, and it enables things like local control and OTA firmware updates.

Matter as a standard does not defines a wireless protocol, but instead relies on IPv6 based networking and proven wireless standard such as Thread and Wi-Fi.

Thread is an IPv6 / IEEE 802.15.4 based low power wireless mesh technology. It is ideal for battery powered IoT devices, with fairly low power requirements. On the other hand Wi-Fi is proven wireless technology suitable for use cases with higher bandwidth requirements, such as cameras or microphones.

Battery Powered Matter Devices

Many of our IoT and Smart Home devices are battery powered, and for these efficient power usage is essential.

Thread is a low power wireless mesh protocol, which also comes with a couple of mechanisms that helps further increase battery life. With Thread, battery powered devices can use power optimized profiles such as Sleepy End Device (SED) and Synchronized Sleepy End Device (SSED).

Sleepy End Devices (SED) save power by staying most of the time in sleep modes, and waking up periodically only for short times. Their Thread parent is responsible for buffering pending messages until the SED wakes up. On a wake up the device queries its parent for pending messages. the In case a message was received, the device will receive it and it will stay active until it complete the action.

Synchronized Sleepy End Device (SSED) takes this concept one step further, and instead of actively queering the parent for pending messages, it wakes up periodically and activates only its receiver. Wakes up happen at predefined time slots, negotiated with the Thread parent. If there is a pending message the Thread parent will use this time slot to send pending messages. This way the SSED only transmits and send requests to the Thread parent when it is really needed, thus saving power. They wake up periodically and query their Thread parent for any message.

Wi-Fi is a wireless protocol which can offer higher bandwidth compared to Thread and similar low power protocols. It is traditionally has a much higher power consumption, but with Wi-Fi 6 a couple of power saving features were introduced. One of these is Target Wake Time (TWT), which is feature that allows clients to negotiate time slots with the router, in which they are active and can send / receive data. Thus TWT allows saving power similar to how Thread SSED does.

Fortunately, the Nordic development kits (nRF5340 dk, nRF7002 dk, Thingy:53) and software (nRF Connect) already support these features, and we will see later how they can be used.

Getting Started

To get started with Matter we need a couple of things:

• a Development Kit, which can be nRF7002 DK for Wi-Fi, and nRF5340 DK for Thread
• a Wi-Fi Router, a home network with IPv6 support
• a Thread Border Router (only for Thread), that does the routing between our Thread and our WiFi / home network
• a Matter Controller (smart hub, or preferably the CHIP Tool)
• a Laptop / PC / SBC with BLE support

For the Thread Border Router a decided to use the Open Thread Border Router (OTBR) running on a Raspberry Pi 4, with a nRF52840 Dongle acting as the radio co-processor. This guide can be used to set up OTBR on a Raspberry Pi.

For the Matter Controller I'm using the CHIP Tool running on my laptop. The CHIP tool can be downloaded from GitHub nrfconnect/sdk-connectedhomeip releases page.

As the development environment for the Nordic development kits and devices we can use Visual Studio Code, with the nRF Connect for VS Code extension.

With this setup we should be able to try out the examples from Nordic's Getting started with Matter guide.

Matter Concepts

The document describing the Matter standard is quite lengthy, but to be able to develop custom Matter applications we still need to know a couple of concepts:

• Devices - represent physical IoT / Smart Home devices, with one or more Matter nodes
• Nodes - are individually addressable network nodes in the Matter fabric. On Device can contain one or more nodes. For example a smart power outlet with two socket could represent two individual Matter nodes
• Endpoints - represent different sets of functionality in a single Matter nodes. Each node has a root endpoint (0), and a set of functional endpoints (1, 2, ..) such like Switch or Light
• Clusters - group attributes and events related to each other. For example the Switch cluster has attributes and events indicating the current position and change of the switch.

Matter also has the concept of Server and Client clusters. The clusters defined by the devices are usually Server clusters, while the callers consuming those clusters are must define Client clusters.

To develop custom Matter devices, we first need to define a data model with the concepts defined above. We can do this using the ZAP tool:

The ZAP tool can be used both to define the data model, usually located in a template.zap file, but it can also be used to generate source code that later can be used in our project.

Code

The recommended way to develop Matter applications on Nordic devices is to use the nRF Connect SDK together with the Zephyr RTOS. As an IDE we can use Visual Studio Code, with the nRF Connect for VS Code extension.

Fortunately, the nRF Connect SDK comes with a number of Matter sample applications. We can use to these to bootstrap or project the development kits.

In these project I used the following samples:

• Thingy:53: Matter Weather Station - provides Temperature, Air Pressure, Relative Humidity and Battery measurements. It implements Matter over Thread (and over WiFi with expansion board) with support for low power modes.
• Matter: Light Switch / Light Bulb - simple examples implementing Matter over Thread and WiFi with low power mode support.
• Edge Impulse: Wrapper - machine learning application with support Edge Impulse ML

The samples were slightly modified and combined, in order to demonstrate concepts such as low power operation and machine learning.

The code is available at GitHub under the bluetiger9 / matter-smart-sensor-beacons repository.

Measuring Power

To get an idea over the expected battery life our product, it's important to understand the power consumption characteristics of the device. This combined with the the capacity of our power source (usually a battery) determines the battery life of the product.

To measure the power consumption of a device we can take multiple approaches.

• Measuring Battery Voltage - a simple method for battery powered devices, used to measure the remaining capacity of the battery. It can be used to get a general estimate of battery consumption over long period of time
• Measuring Current Consumption - is useful for detailed analysis of short time power consumption behaviour. For wireless devices, an instrument with fast current measuring capability, such as the Power Profiler Kit II is needed.

To estimate the power consumption of Matter application with Nordic devices, I used the the Power Profiler Kit II in combination with the nRF5340-DK and nRF7200-DK.

There are multiple ways to measure the power consumption with the PPK II, with the main methods being the Ampere and Source Meter modes:

• in Ampere Meter mode we measure the current used in the different power domains of the devices, via measurement points exposed at the boards. Supported for the nRF5340-DK, nRF7200-DK and the Thingy:53
• in Source Meter mode we power the boards from the PPK II, and measure the power consumption from the source. Supported for the nRF5340-DK and nRF7200-DK.

A simple, but low power enabled Matter example such as the light_switch is a good start to measure current consumption. The bellow two screenshots show the nRF5340-DK in different scenarios:

• Matter over Thread (with SED) - Idle - current consumption ~10uA, with wake ups every ~1s

• Matter over Thread (with SED) - Receive + Transmit, responding to an attribute read

Testing the same on the nRF7200-DK with WiFi show significantly higher current consumption:

(note: this test was done with WiFi 5. Unfortunately, I didn't yet had the possibility to test low power modes with a WiFi 6 router)

With the Thingy:53, I tested power consumption using two methods:

• Current Consumption measurement with the PPK II - shows an average of ~300-450uA

• Battery Voltage Measurement over Matter - shows about ~10% capacity reduction over 7 days

The Thingy:53 has a 5.0Wh / 135mAh Li-Po battery, which with 300-450uA consumption would result in a 125 day runtime. This is more or less in the same ballpark as the 70 days estimate would get by estimating by real usage.

Adding Artificial Intelligence

Some sensors like accelerometers and microphones have a relatively high data production rate. However, the raw data produced by this sensors are not that useful, and needs to be pre-processed with digital signal processing or artificial intelligence.

In case of battery powered device, this pre-processing step ideally should be done locally, in order to avoid draining the battery with unnecessary data transmissions. Combining traditional methods with artificial intelligence can be used to achieve great results:

• using sensors with power saving modes, like accelerometers with "wake up on motion" functionality, can be used to sense the environment while keeping the main MCU in deep sleep modes
• when the sensor detects activity it wakes up the MCU, and we can start collecting data
• using DSP and AI / ML models we can process the sensor data to extract meaningful information
• based on the results we can trigger Events, or generate a data stream with much lower update frequency

A handy way to implement machine learning on edge devices such as MCU-s, is to use Edge Impulse to collect data and build ML models. The nRF Connect SDK already comes with Edge Impulse integration, which makes integrating machine learning into our applications relatively easy.

In order to demonstrate the use of Machine Learning model in combination with Matter we could implement something like:

• use the Thingy:53 to collect accelerometer or sound data, and feed it to an Edge Impulse inference model
• publish the inference results as a Matter attribute, or as a Matter event signalling an event we are interested in

Note: this part is still work in progress and I'm working to integrate ML functionality in the Matter examples...

Matter Clients & Visualization & Automation

Smart Home devices can be usually controlled via smartphone applications and virtual assistants like the Amazon Alexa. However, these are vendor specific solutions, and preferably we would like to be able to control Matter devices directly.

For certain use cases we would also like to have programmatic / API access to Matter devices, so that we can integrate them in various automation and monitoring systems.

To control Matter devices directly we have a couple of options:

• Implement a Matter Device / Node with the appropriate privilege (>= View for reads, >=Operate for control). Suitable for programmatic / API access.
• Interact with the Matter Controller directly. This usually implies using a vendor specific controller. Cloud provide programmatic / API access.
• Implement a Matter Controller with the desired functionality. The Matter devices can join the new Matter fabric. Could be used for programmatic / API access. May not be scalable as Matter only guarantees up to 5 fabrics per device.

To demonstrate programmatic access I decided to implement a Matter to Grafana / InfluxDB based integration, with visualization and control functionality.

For the sake of simplicity I decided to interact directly with the CHIP tool acting as the Matter controller. CHIP tool has an interactive server mode that starts a WebSocket server, which can be use to used to send and receive data from Matter devices.

The interactive server mode can be started the command:

./chip-tool-release interactive

and a WebSocket server starts on the port 9002.

After this, we can use the WebSocket servers to send the same commands we would normally use with the CHIP tool. The commands are sent in plain text, while the responses are send in a JSON format.

To implement Grafana / InfluxDB integration I created a simple Python script that does the following:

• create a local WebSocket connection to the CHIP tool
• sends a `read-attribute` command and wait for the response
• reads the measured values from the JSON response
• publishes a data point to InfluxDB
• from InfluxDB we can simply load the values in Grafana

The script can we started with a command like:

$ python3 chip-tool-ws-client.py --node-id 55 --endpoint-id 1 --cluster-name temperaturemeasurement --divide 100.0

The collected data is saved in InfluxDB and can be displayed in Grafana in various dashboards. The bellow screenshots shows Temperature, Relative Humidity and Air Pressure Data collected from the Matter Weather Station app running on the Thingy:53:

Conclusions

Matter brings significant quality of life improvements in smart homes, by improving interoperability and device security. Wireless protocols such as Thread and WiFi 6 enable the development of devices with great battery life.

Using solutions like the Multi-purpose Smart Sensor Beacon presented here can improve our homes, by reducing the number of sensors we have, by providing great battery life and machine learning powered smart functionality.

(Note: some of the parts of this project are still in progress and will be completed later)

Resources

Getting started with Matter (Nordic)

Reducing power consumption in Matter (Nordic)

Matter: Light switch (Nordic)

Thingy:53: Matter weather station (Nordic)

ZAP Tool (Project CHIP)