[This is article #3 in the Espressif Matter Series of articles. You may read the second part here.]

In the previous article we looked at the data model of Matter. Today, let us talk about how Matter devices within a network can interact with each other leading to useful automations. For instance, you may want a light switch at your home to control one or more light bulbs. Or even a thermostat to turn on or off based on reports from the occupancy sensor.

This is a very interesting usecase that is not easily possible through the existing ecosystem protocols. Matter easily enables this. This doesn’t require intermediation from any cloud or phone apps to make it happen. Instead, it is all facilitated directly over the local network.

As mentioned in the data model article, every Matter cluster has a cluster server, and a cluster client counterpart. The communication happens between the client and server of the same cluster. As can be seen above, the OnOff cluster client on the switch can talk with the OnOff cluster server on the light to turn it on or off. And the end-user can configure which device can talk to which device(s) in their home.

For this interaction to happen, the switch should know the details about the light. This is achieved through device binding. A binding represents a persistent relationship that informs a client endpoint of one or more target endpoints for a potential interaction. A user (through the Matter phone app) can establish binding between devices, regardless of the vendors they are from.

There are two ways through which device-to-device interaction can be accomplished:

1. Synchronous Control

Let’s go back to our example of the switch controlling the light that is shown above. For this, the switch additionally needs to have a Binding cluster server that offers the binding service. After a user binds the light to the switch, an action (on or off) on the switch results into corresponding action on the light. This scenario is illustrated below:

Similarly, a Dimmer Switch needs to have an OnOff client, a Level Control client and a Binding server to control a dimmable light.

2. Asynchronous Notification (Subscribe-Report)

This method facilitates receiving data reports from a publisher to a subscriber. The subscriber can subscribe to attributes and/or events on the publisher.

The thermostat and occupancy sensor usecase mentioned above can be realised after the thermostat subscribes to attributes of the sensor. First the user binds the thermostat to the occupancy sensor. Once done, the thermostat can subscribe to the sensor attributes and receive data periodically as well as when there is an activity (change in sensor attributes). This scenario is illustrated below:

This was an example of subscribing to attributes. Devices could also subscribe to events. In the data model article, we talked about clusters having attributes and commands. Here, we introduce events which are also a part of clusters. Events capture every single change and convey it to the subscribed entity. A few examples of events include switch pressed, long press, and door opened.

This sums up the introduction to device-to-device communication in Matter along with the different ways in which it can be implemented.

This article is a part of a series of articles Espressif Matter Series. You may read the next article that talks about Matter: Bridge to non-Matter Devices.

Matter: Device-to-Device Automations was originally published in The ESP Journal on Medium, where people are continuing the conversation by highlighting and responding to this story.

Introduction

Matter, previously project CHIP, is the new foundation for connected things. Guided by the Connectivity Standards Alliance, and developed through collaboration amongst all the leaders of the IoT industry, Matter focuses on building connected devices that are secure, reliable, and importantly, seamless to use.

Espressif has been a part of the Matter initiative since early days, and we have been focusing on making it easy to develop and use Matter with Espressif’s line of SoCs. In this article, we will discuss the steps to get your first Matter application up and running on an ESP32. In upcoming articles, we will discuss various technical details of Matter and explore ways to quickly build Matter certified devices on Espressif platforms.

Architecture

As illustrated above, Matter defines the application layer that will be deployed on devices and controllers as well as supported IPv6-based networks to help achieve the interoperability goals. Matter will initially support Wi-Fi and Thread for core communications and Bluetooth Low Energy (BLE) to simplify device commissioning and setup.

Matter on ESP32

Matter SDK

The Matter SDK is an open source repository for the implementation of the specification and continues to be under active development. ESP32 has been a supported platform in the Matter SDK since the very beginning. At present, it is the only platform that offers support of both Wi-Fi as well as BLE. ESP32 supports commissioning (initial device configuration) over BLE as well as Wi-Fi SoftAP; and supports operational communication over Wi-Fi.

Sample Examples

You could try either of the following examples:

1. ESP32 all-clusters-app: This example allows you to try out all the Matter features using ESP32 based dev-kits (ESP32 WROVER Kit, ESP32 DevKit-C, M5Stack Core1). It allows you to perform device commissioning, and also control the device using a Matter controller. This is also the default application that is used by many of the Matter developers for development and testing.
2. Footprint optimised application: The ESP32 all-clusters-app above is like a kitchen sink application that incorporates all the clusters that are part of Matter. If you wish to get an idea about the footprint utilisation of Matter, you may try the ESP32 temperature-measurement-app. This app is specifically optimised, in order to facilitate footprint impact analysis.

Either of these examples can be tested against a Matter controller. The Matter SDK provides reference implementation of controllers:

1. Python based Device Controller
2. CHIPTool
3. Android CHIPTool
4. Darwin CHIPTool

Getting Started

Let’s look at the steps to try the above examples on ESP32.

We use Espressif IoT Development Framework (ESP-IDF) release v4.3 to try this out.

1. If you haven’t setup ESP-IDF already, please follow the steps here.
2. You may then follow the README files in the respective application directories (all-clusters app README, temperature-measurement-app README) for instructions on building and loading the examples on ESP32.
3. Once the ESP32 is up and running, we need to setup the controller. As a demonstration, we will be using the all-clusters-app with the Python based controller here. Please follow the steps below:

Build the Python Controller

$ cd /path/to/connectedhomeip

$ ./scripts/build_python.sh -m platform

• Execute the controller and establish a secure session over BLE. BLE is the default mode in the application and is configurable through menuconfig.

$ source ./out/python_env/bin/activate

$ chip-device-ctrl

chip-device-ctrl > ble-scan

chip-device-ctrl > connect -ble 3840 20202021 135246

Parameters:

1. Discriminator: 3840 (configurable through menuconfig)
2. Setup-pin-code: 20202021 (configurable through menuconfig)
3. Node ID: Optional. If not passed in this command, then it is auto-generated by the controller and displayed in the output of connect. The same value should be used in the next commands. We have chosen a random node ID which is 135246.

• Add credentials of the Wi-Fi network you want the ESP32 to connect to, using the AddWiFiNetwork command and then enable the ESP32 to connect to it using EnableWiFiNetwork command. In this example, we have used TESTSSID and TESTPASSWD as the SSID and passphrase respectively.

chip-device-ctrl > zcl NetworkCommissioning AddWiFiNetwork 135246 0 0 ssid=str:TESTSSID credentials=str:TESTPASSWD breadcrumb=0 timeoutMs=1000

chip-device-ctrl > zcl NetworkCommissioning EnableNetwork 135246 0 0 networkID=str:TESTSSID breadcrumb=0 timeoutMs=1000

• Close the BLE connection to ESP32, as it is not required hereafter.

chip-device-ctrl > close-ble

• Resolve DNS-SD name and update address of the node in the device controller.

chip-device-ctrl > resolve 135246

• Use the OnOff cluster command to control the OnOff attribute. This allows you to toggle a parameter implemented by the device to be On or Off.

chip-device-ctrl > zcl OnOff Off 135246 1 0

Note: All the above commands have help associated with them that can assist with the parameters.

The above commands help you try the common functionality that is exposed by Matter on the ESP32.

ESP32-C3 Support

ESP32-C3 support is integrated in Matter. Please follow the READMEs to run the examples on ESP32-C3

Stay tuned for more updates on Matter and ESP32. Happy hacking!

Announcing Matter (previously ‘CHIP’) on ESP32 was originally published in The ESP Journal on Medium, where people are continuing the conversation by highlighting and responding to this story.

The NimBLE preview release is made available on ESP-IDF Github: https://github.com/espressif/esp-idf/tree/feature/nimble-preview

A few examples, ported from the NimBLE repository, can be found here: https://github.com/espressif/esp-idf/tree/feature/nimble-preview/examples/bluetooth/nimble

The porting layer is kept cleaner by maintaining all the existing APIs of NimBLE along with a single ESP-NimBLE API for initialisation, making it simpler for the application developers. The documentation of NimBLE APIs can be found at: https://mynewt.apache.org/latest/network/docs/index.html#ble-user-guide

Preview Release: NimBLE support in ESP-IDF was originally published in The ESP Journal on Medium, where people are continuing the conversation by highlighting and responding to this story.

ESP32 now also supports Dialogflow, a voice-enabled conversational interface from Google. It enables IoT users to include a natural language user interface in their devices.

The differences of Dialogflow w.r.t. voice assistants are

• a reduced complexity,
• pay as you go pricing,
• custom wake words, instead of having to use ‘Okay Google’ or ‘Alexa’
• and no certification hassles, because hey, you aren’t integrating with Alexa or Google Assistant; you are building one of your own

Unlike voice-assistants, Dialogflow let’s you configure every step of the conversation, and it won’t answer other trivia/questions like voice-assistants typically do. For example, a Dialogflow agent for a Laundry project will provide information only about the configurable parameters of the laundry (like state, temperature, wash cycle etc.)

This is now a part of Espressif’s Voice Assistant SDK and is available on github here: https://github.com/espressif/esp-va-sdk. To get started, see this.

The underlying technologies used by the Dialogflow implementation for VA SDK includes:

• gRPC
• Google Protobufs
• HTTP 2.0

You can see a demo video of Dialogflow on ESP32 LyraT below:

Note that the current Dialogflow SDK does not yet include support for creating custom wake words. Conversations initiated with a tap-to-talk button are supported.

Embedding Voice into Devices with ESP32 was originally published in The ESP Journal on Medium, where people are continuing the conversation by highlighting and responding to this story.