Matter Protocol Integration Using Espressif’s Solutions to Achieve Smart Home Interoperability

Abstract

Smart home devices are becoming more popular over the years. A diverse range of appliances is being created, and Ambient Intelligence is growing in homes. However, there are various producers of these gadgets, different kinds of protocols, and diverse environments. The lack of interoperability reduces comfort of the user and turns into a barrier to smart home adoption. Matter is growing by constructing an open-source application layer protocol that can be compatible with all smart home ecosystems. In this article, a Matter overview is provided (namely, of the Commissioning stage), and a Matter Accessory using ESP32-S3 is developed referring to the manufacturer’s SDKs and is inserted into an existent household ecosystem. Its behavior on the network is briefly analyzed, and interactions with the device are carried out. The simplicity of these tasks demonstrates accessibility for developers to create products, especially when it comes to firmware. Additionally, device commissioning and control are straightforward for the consumer. This capacity of gadget incorporation into diverse ecosystems using Matter is already on the market and might result in higher device production and enhanced smart home adoption.

1. Introduction

Humans have a natural course of action within the environment where they are located. By having sensing capabilities, the conditions can be comprehended, and reactions are made accordingly. With the evolution of technology, some of these tasks have become automated ubiquitously by the users, especially in smart homes, where the mentioned to conditions are perceived by devices providing Ambient Intelligence [1,2,3].

In this scenario, smart homes are an emerging technology that allows end users to achieve comfort within the household environment remotely and automatically [4]. This can have several benefits for different fields (such as health-related, environmental, and financial fields) because, by applying the several services provided by the smart home environment, users can benefit from immediate and long-term advantages. For example, the enhancement of entertainment and virtual interaction can overpower the feeling of isolation [5]. Environmentally and economically, power monitoring systems can reduce energy consumption by providing the user with feedback and suggestions on how to use energy more efficiently [6,7].

However, in addition to all these advantages and conveniences, there are still major barriers. Because the data collection of the given Ambient Intelligence is massive, users tend to associate it with risk. Because this type of information is personal and is given to companies, it can implicate consumer privacy [7,8]. Another technological barrier is the complexity of the systems, which affects the ease of usability for the end user [9]. Financially, the cost of the devices and installation is a major concern. Psychologically, there might be resistance to or fear about these kinds of technologies, along with a lack of experience, which can also be obstacles to adopting the smart home concept. For the ones that are starting to become familiar with these tools, the fact that not all devices operate in consonance due to the diversity of suppliers and protocols forms a barrier to the acquisition of more devices by end users [7]. This example can be easily observed nowadays, as customers can have a mobile application for each smart device, making it impractical to control the home if there are multiple appliances because it leads to uncertainty and inaccessibility [10].

1.1. Review on Smart Home Protocols

As time passed, home technology has been able to evolve on account of several entities that have been developing state-of-the-art protocols that are adequate for each need inside the domain. There were times when wired protocols were the most welcome mechanisms to automate places, but wireless technologies have become more popular and diverse in the market [11,12]. Consumers can now purchase a smart plug, connect it to the cloud via Wi-Fi, and control appliances remotely, without the need to expend or automate much equipment, which could lead to additional installation costs. Therefore, the smart home market is becoming more accessible over the years [13].

Different kinds of devices such as door and window sensors (which have a low data throughput) and smart vacuum cleaners (which need to send and receive more information) are endowed with contrasting types of technologies that are specific for their demands. In this instance, the window sensor might work with ZigBee, allowing it to be battery powered and last for years without being recharged or replaced, and the smart vacuum cleaner might work with Wi-Fi, requiring it to be periodically charged. All the previously mentioned technologies require gateway implementation, which has been a key factor over the years for managing the connections with several devices inside a network. This gadget allows communication between different technologies used in the home environment and can provide access to and from other external types of services [12].

With this, here we present some of the most used IoT (Internet of Things) data link protocols in smart homes, along with some product examples specifically in relation to wireless communications.

Table 1. Comparison of communication protocols.

Protocol	Network Topology	Range	Autonomy	IPv6 Capabilities
Wi-Fi	P2P/Star	Moderate/High	Low	Yes
ZigBee	P2P/Star/Mesh	Moderate	High	No
Bluetooth Classic	P2P/Star/Mesh	Short	Moderate	No
BLE	P2P/Star/Mesh	Short	High	No
Thread	P2P/Star/Mesh	Moderate	High	Yes

shows the most important parameters when deciding what protocol to choose when developing a product.

• Wi-Fi: Devices utilize 802.11 radios due to their widespread availability, high bandwidth, and, more importantly, their compatibility with household networks. Devices such as smart speakers/voice assistants and security cameras employ this type of communication protocol due to the higher energy consumption rates derived from their higher data throughputs to the network. Some devices are now compatible with Wi-Fi HaLow (IEEE 802.11ah [14]), which improves range connectivity and reduces power consumption [15];
• ZigBee: It is a widely accepted communication protocol used in smart homes that provides advantages such as low power consumption, mesh networking, and robustness. Normally, this technology is used in battery-powered devices such as window and door sensors, buttons, and door locks. However, these kinds of products normally require an additional hub which can bridge ZigBee communications to Wi-Fi or the Ethernet to establish a smart home ecosystem by providing interoperability between devices that use other protocols [16];
• Bluetooth Classic: A protocol that works in the unlicensed frequency band (ISM—Industrial, Scientific, and Medical) by operating at 2.4 GHz. It can be used to connect mobile phones to wireless speakers or phones and transmit bursts of constant data, for example, sending a piece of music to be played from one device to another using P2P (Peer-to-Peer) communications. Its major disadvantage is its short-range distance coverage, which, in the context of a home, might imply that the communication can only work in a single room [17];
• BLE (Bluetooth Low Energy): Similar to Bluetooth Classic, a new standard designed to enhance low-power applications using frequency hopping while having a slower rate. This technology has high potential for smart homes when it comes to becoming a key protocol for the IoT because of its low cost and low power consumption, although it has small-sized devices [18]. This protocol is commonly used on door locks and different types of sensors, namely, when configuring these devices to attach them to a specific Wi-Fi network;
• Thread: A wireless networking protocol designed for short-range, low-powered, and low-bandwidth applications leveraging standards such as IEEE 802.15.4 radios, 6LoWPAN, and IPv6. This means that this technology enables the usage of IP addressing on resource-constrained devices that might work using batteries for some time. With this, in the smart home context, it eliminates the need for extra translation or adaptation layers when designing hubs/Bridges, making communication between devices with different connectivity technologies much simpler and guaranteeing interoperability within the IP network [19].

Relative to the TCP/IP (Transmission Control Protocol/Internet Protocol) stack, on top of these described physical and link layer technologies, several application layer protocols fit each protocol’s demands. Some protocols that are utilized in the industry that suit IPv6 in the network layer and TCP/UDP (Transmission Control Protocol/User Datagram Protocol) in the transport layer are HTTP (Hypertext Transfer Protocol), MQTT (Message Queuing Telemetry Transport), and CoAP (Constrained Application Protocol); however, it is hard to understand which protocol is being utilized in each product because this information may not always be disclosed by manufacturers [20]. A more recent application layer protocol that is being widely approached in industry, but not so much in the academic literature, is Matter [21,22,23,24,25].

Over time, the industry has become increasingly divided due to product manufacturing having fragmented standards, which creates problems in terms of the interoperability of devices from different companies. Devices require multiple types of data link and application protocols to work seamlessly, which, in device fabrication, presents higher costs and complexity of implementation. To companies, maintaining their proprietary standards is the most cost-efficient approach. However, as previously mentioned, to the end user, this becomes a major barrier because the consumer is forced to utilize different mobile applications to control several types of appliances or give in and use the ecosystem of one single fabricant [7,10,26].

1.2. Matter—Connected Home over Internet Protocol

This aforementioned protocol, Matter, once known as Project CHIP (Connected Home over IP), is remodeling the smart home industry by promoting interoperability among different manufacturers’ products, namely, devices (such as sensors, actuators, or hubs) and mobile applications [27]. This application layer protocol is being invested in by the most impactful smart home corporations like Google and Amazon and is led by the CSA (Connectivity Standards Alliance), which was formerly known as the ZigBee Alliance [28]. This free and open-source connectivity standard aims to establish a universal communication standard for smart home products, facilitating interoperability across different ecosystems. In sum, with this technology, the consumers can purchase any type of device from any producer and can control or manage it by referring to any mobile application, whatever the provider. For the purchaser, it breaks down barriers by enabling users to stop worrying about compatibility issues and having to utilize different mobile applications for distinct devices within the house and makes it easier to manage the network of gadgets, making this type of machinery and ecosystem more user friendly. The major development goal of this protocol implementation is ecosystem unification while being secure, robust, flexible, open, and easy to use [29].

This protocol architecture in the TCP/IP stack is well defined, as can be observed in Figure 1. In the link layer, Matter can utilize different types of technologies such as Ethernet, Wi-Fi, and Thread, depending on the device’s requirements. For instance, a low-power application such as a door sensor running on batteries can work with Thread, while a more powerful device that requires high data throughput and is connected to an outlet can work on Wi-Fi. However, in the network layer, to handle routing and addressing within the network, Matter-enabled devices require IPv6. In 802.11 and 802.3 data link protocols, this is already being seamlessly implemented in day-to-day applications by referring to DHCPv6 (Dynamic Host Configuration Protocol version 6) servers; however, in 802.15.4, the Thread Group implemented a layer on top of the MAC (Media Access Control) layer called 6LoWPAN (IPv6 over Low-Power Wireless Personal Area Networks) which handles limitations when sending and receiving IPv6 packets over 802.15.4 links, such as packet encapsulation, packet fragmentation and reassembly, header compression, and packet forwarding [30].

With the created network of devices, despite the type of application and link layer protocol utilized, TCP and UDP framing is enabled in the transport layer of the TCP/IP stack, which ensures reliable transmission of packets. On top of this, Matter is presented as a standard application layer protocol to be used with this set of wireless technologies, representing a set of commands and topologies that devices need to communicate. This means that devices must submit to some identifiers in the network to be able to interact with each other, such as a 16-bit Vendor ID (VID), which is a unique value that identifies a specific product manufacturer (allocated by the CSA), and a 16-bit Product Identifier (PID), which identifies the product of a specific fabricant. The combination of these values uniquely identifies a Matter product, and a Device Attestation Certificate (DAC) proves the authenticity of the device hardware and software. DACs are X.509 certificates hard coded in the device that ensure the device is registered within the CSA and is trustworthy [31,32].

Different arrangements of devices can be established in a home network, allowing distinct topologies to communicate with each other using central hubs. For instance, to attach Thread and Wi-Fi networks, Edge Routers are utilized to ensure the interoperability between different IPv6 networks that support Matter. In this case, it can be carried out by Thread Border Routers and Wi-Fi Access Points [33]. However, within the smart home ecosystem, there can also be devices that do not support the Matter protocol. To fit the need for compatibility between architectures, Bridges can be implemented to ensure that non-Matter devices can communicate securely with the established Matter network. For example, the adoption of a ZigBee or a Z-Wave infrastructure into a Matter network implements a Matter Bridge which allows communication between devices using distinct application layer protocols.

To interact with Matter devices, Controllers are used. Normally, the aforementioned central hubs assume this role, which enables setting adjustment, information gathering, and control of Matter accessories. Matter packets are exchanged within the LAN (Local Area Network), and the usage of central hubs is leveraged due to their cloud communications. Therefore, users can remotely control and monitor Matter-enabled devices using the Internet [34].

However, when first initializing Matter-enabled gadgets, they need to be adopted into the Matter network using a process called Commissioning. This requires a Commissioner, which is normally a mobile phone running a mobile application that facilitates the communication of the device with Controllers. A Commissioner discovers devices in the surroundings, authenticates them into the IPv6 network, and configures its parameters with simplicity and minimal effort of the end user. Usually, the Commissioning process is performed over BLE (Bluetooth Low Energy). The Commissioner and Controller roles can sometimes be assumed by one entity. The Commissioning process is divided into the following steps [35,36]:

• The Matter Accessory must enter Commissioning mode, whether automatically or forced to by the user. This device starts the Advertising process using BLE or Wi-Fi Soft AP;
• A mobile phone running a Commissioner application scans the QR code attached to the device or enters the Matter passcode manually. This ensures that the mobile phone sets up a BLE-secured connection with the Matter-enabled device by using the obtained passcode (PASE—Password-Authenticated Session Establishment) by referring to BLE beaconing. This process is called Validating;
• The following step is Device Attestation, which is when the Commissioner checks the manufacturer certificate and compliance of the device by communicating with a remote database for validation (DCL—Distributed Compliance Ledger). If the device is not certified, users are prompted with this information and are asked whether they still want to continue the Commissioning process;
• If the process continues, the Commissioner locally generates or obtains for a remote server an operational certificate to be installed within the device together with a generated ACL (Access Control List) containing the list of administrators;
• The Commissioner supplies the device with credentials from the network to join. If it is a Wi-Fi-compatible device, the SSID and password are configured. If it is a Thread-compatible device, the PAN ID, network key, and other parameters are delivered. This process is called Provisioning;
• The device joins the operational network (Joining). However, in the case of a Thread-compatible device, before joining, network scanning, discovery, and selection are performed, as well as parent selection to organize the node in the best possible position within the network [37];
• Once the device is authenticated in the network, it will advertise itself using mDNS (Multicast Domain Name Service) so the Commissioner and other nodes can know its IP address and associated port (Advertising). From now on, nodes utilize CASE (Certificate-Authenticated Session Establishment) to achieve secure session establishment using their certificates, proving the legitimacy of their entities within the network. This completes the Commissioning process.

Following the Commissioning process, devices can be controlled using clusters, which are a set of attributes and commands grouped by specific functionalities. For example, to turn on/off a device, the “On/Off” cluster has an attribute called “OnOff” with a Boolean type. This attribute can be toggled by sending “On” to set it to “1” and sending “Off” to set it to “0”. ZCL is a complex library that will not be approached in depth in this work.

1.3. Problem Structuring

In sum, to implement the Matter protocol, a smart home needs a Matter Accessory, a Matter Commissioner, and a Matter Controller. In this work, to demonstrate the proof of concept, a Matter network is implemented. The main research objective is to investigate the performance and interoperability of Matter-enabled devices in existent smart home ecosystems that support this protocol. Furthermore, it aims to provide additional insights into how to develop and use these kinds of devices by referring to fabricant SDKs (Software Development Kits) and to show how effortlessly devices can be commissioned, controlled, and adjusted to these kinds of environments.

2. Methodology

Within this research, the main objective was to implement a sample of a Matter Accessory and insert it into a Matter-enabled smart home ecosystem. To achieve this, the environment was first set up—this involved setting up a Matter Controller and a Matter Commissioner.

2.1. Matter Controller and Matter Commissioner—Xiaomi Smart Home Hub 2 and Xiaomi Home

The Xiaomi Smart Home Hub 2 is a smart home central Controller that allows Wi-Fi (dual-band: 2.4 GHz and 5 GHz), ZigBee 3.0, Bluetooth, and, lately, Matter devices to interoperate within the ecosystem. By combining all these kinds of supported devices with the cloud infrastructure provided by Xiaomi, users can control and monitor their gadgets locally and remotely, as well as set up automation and scenes to achieve more pervasive and personalized control of the smart home. All of this can be performed by using the home Wi-Fi (LAN) or over the Internet (WAN) using the mobile application. The beauty of Matter is that, when all the devices are in the same LAN, the communications stay within the LAN, ensuring fast and efficient data exchange. However, when remote connections are needed, a mobile application communicates with the cloud infrastructure, which, in turn, will transmit the information to the central hub, which will relay controls to the devices. The opposite scenario is also verified. Namely, when it comes to sensors, the device sends data to the central hub, which will feed the cloud infrastructure, and, from there, the mobile application can access those data and display them.

To achieve this control and monitoring, the Xiaomi Home mobile application is utilized. It allows users to add new devices with ease and control them from anywhere in the world as long as there is Internet access and the hub is present in the same LAN as the devices. This mobile application was recently certified as a Matter-enabled product (1 February 2024) by the CSA, as well as the referred hub. In this specific case, the app was downloaded from the Google Play Store.

2.2. Matter Accessory—Espressif Solutions

Espressif Matter Solutions present a diversified range of devices with an appropriate, robust SDK for deploying firmware for each specific application. To build a Matter device, a Wi-Fi-enabled development kit was chosen (ESP32-S3), and the required frameworks were set up.

2.2.1. ESP-IDF

The ESP-IDF (Espressif IoT Development Framework) is a Software Development Kit (SDK) provided by Espressif Systems to program and develop applications for ESP32 microcontrollers effectively and efficiently. It provides extensive libraries that support different peripherals available in ESP32 chips, such as I2C, SPI, and GPIOs, among others. It provides a well-defined networking stack and communication protocols in the link layer such as Wi-Fi or Thread all the way up to application layer protocols such as MQTT and HTTP. The framework, by presenting a modular architecture with all these libraries and even being able to integrate an RTOS (Real-Time Operating System), it is shown to demonstrate efficient resource allocation and multitasking in a lightweight manner. In sum, the ESP-IDF provides the full development environment for Internet of Things applications. To configure the SDK, build firmware, or even interact directly with the ESP32 board, the framework provides tools that are sets of Python scripts, such as idf.py, which is a front-end command that allows more complicated instructions provided by ESP-IDF to be seamlessly achieved. Basically, within a known compatible IDE (Integrated Development Environment), engineers/developers can work on their project using the toolchain, then build the application for the specific ESP32 microcontroller model, upload the firmware, and monitor its behavior [38].

2.2.2. ESP-Matter-SDK

To design Matter-compatible devices using ESP32 chips without extensive library integration from the main open-source Matter SDK (provided by connectedhomeip), Espressif’s SDK for Matter was developed by Espressif on top of the existent Matter SDK. It has become the official Matter development framework for ESP32-series SoCs and was designed to accelerate the development of Matter devices using these kinds of chips. It provides a set of APIs that allow engineers to integrate different peripherals in their applications. To date, it supports device types such as some lighting applications (on/off lights, dimmable lights, etc.), utility device types, sensors, and even HVAC applications (air purifiers, for example). Extensive documentation is provided for engineers, which, alongside the thorough libraries and example applications, helps manufacturers to reduce their product time to market by expediting code development. To utilize this SDK, the ESP-IDF toolchain is required to build and flash the firmware. This is built on top of the open-source Matter SDK, as seen in Figure 2 [39].

2.2.3. Device Development

The ESP-IDF toolchain can be run from most known operating systems such as Windows, Linux, and MacOS. In our specific case, a Virtual Machine running Ubuntu 23.04 Lunar Lobster (64 bit) was deployed with the required packages to run the ESP-IDF and ESP-Matter-SDK. The SDKs were configured as recommended by the manufacturer; repositories were cloned, environment variables (seen in Listing 1) were set, and instructions to build and flash firmware were followed. With this, the Matter-compatible light sample provided in the ESP-Matter-SDK was built (application was compiled; bootloader, partitions table, and application binaries were generated) appropriately for an ESP32-S3 microcontroller, as illustrated in Figure 2. The provided samples can work with any ESP32 model/generation, although the bootloader and application binaries need to be built for the specific variant of microcontroller family.

Listing 1. Configuring environment.

cd  esp-idf;  source  ./export.sh;  cd  ..

cd  esp-matter;  source  ./export.sh;  cd  ..

Ccache usage is recommended by Espressif to enable faster IDF builds. In addition, Matter samples are code extensive, and, therefore, builds take a lot of time. Ccache caches previous compilations and accelerates recompilation in subsequent builds. The command can be observed in Listing 2.

Listing 2. Enabling Ccache.

export  IDF_CCACHE_ENABLE=1

To access the light (on/off) sample of the previously cloned ESP-Matter-SDK repository, build, and flash it to the board,  the steps in Listing 3 were taken.

Listing 3. Flashing firmware.

cd  esp-matter/examples/light

idf.py  set-target  esp32s3

idf.py  build  flash  monitor  --port  /dev/ttyUSB0

The fact that this SDK includes pre-configured examples, comprehensive documentation, and several tools to commission, test, and certificate supports the reduction of setup time and simplifies the device development process [29]. In this case, using the ready-to-use Matter light sample allows developers to quickly adapt their devices to ecosystems and further customize devices without starting from scratch. In comparison with work presented in [41,42,43,44,45], integration of this device is more straightforward because no additional mobile applications or cloud providers are required to harmonize the device with the presented ecosystem within the household.

2.2.4. Commissioning Device

In this sample, the Matter Accessory enables Commissioning mode on the first boot and starts Advertising its presence via BLE. Once the Xiaomi App (Commissioning device) is opened by the user, the device is automatically discovered (auto-detection) and ready to be set up, as can be seen in Figure 3.

When pressing “Matter device”, the application requires the user to scan the QR code attached to the device to ensure that a BLE-secured connection is established between the Commissioner and the commissionee (Figure 4). In this case, the scanned QR code was the one provided by Espressif when flashing a sample of a proof-of-concept Matter Accessory. Once this happens, the user is prompted with the actual name of the device and is asked to confirm whether it is the device to connect to. This standardized Commissioning process enables developers to rapidly set up devices using these QR codes, reducing the complexity of onboarding devices for smart home ecosystems.

After Validation is completed, the Xiaomi App asks the user what network credentials are configured for the device during the Provisioning process. However, before transmitting that information to the Accessory, Device Attestation takes place. As this gadget has not been certified by the CSA because it is only a sample, the user is prompted with an Unverified Device confirmation dialog box, advising that the device might work improperly (and might not be secure). In this case, the device was added anyway because it is trustworthy. Then, as expected, the Commissioner supplies the Matter Accessory with network credentials, and the device authenticates itself within the network. The process can be observed in Figure 5.

After the Commissioning process is complete, and similar to for major smart home devices, a room and a name for the Matter Accessory are configured. A sample of a Matter light is now fully arranged into the Xiaomi Home App, and parameters such as state (on/off), brightness, and color temperature are available to be controlled, as shown in Figure 6.

3. Results and Discussion

Once the device is completely commissioned into the network and controls are available, it was time to investigate the logs and understand its behavior. This was performed to understand the rapidness of device adaptation to the ecosystem, the control interaction between the device and the network, and the challenges encountered while using these technologies. With this, performance and interoperability can be assessed.

The Commissioning process is carried out with the Xiaomi ecosystem. However, if the user operates other kinds of Matter-compatible platforms within their household, this device can be attached to that ecosystem by simply factory resetting the board and repeating the Commissioning process (with the tools of the specific ecosystem). In this example, ESP32-C3’s BOOT button can be pressed for 5 s to achieve this purpose. With this, interoperability across different platforms can be guaranteed, unlike with other devices that work with the most well-known smart home environments [41,42,43,44,45].

3.1. Initial Behavior

In Listing 4, the ESP32-S3 logs obtained via the UART after the Commissioning process are presented. In lines 1–10, the BLE can be seen shutting down and the Wi-Fi station changing state to connected. Lines 15–18 demonstrate the IPv4 network configuration obtained, such as the local IP address, gateway, and mask. Similarly, in lines 25–27, it can be noticed that the device also obtains an IPv6 address. In lines 21–24 and 28–31, the process of Multicast DNS Advertising into the network (_matter._tcp) and the announcement of “Operational Device” can be perceived. This completes the configuration process of the Matter device, and it becomes ready to be controlled.

	Listing 4. Initialization of commissioned device.
1	esp_matter_core: BLE deinit successful and memory reclaimed
2	chip[DL]: WIFI_EVENT_STA_START
3	chip[DL]: Done driving station state, nothing else to do...
4	app_main: BLE deinitialized and memory reclaimed
5	chip[DL]: WIFI_EVENT_STA_CONNECTED
6	chip[DL]: WiFi station state change: Connecting ->    Connecting_Succeeded
7	wifi:<ba-add>idx:0 (ifx:0, b4:b0:24:c3:eb:b7), tid:0, ssn:3,    winSize:64
8	chip[DL]: WiFi station state change: Connecting_Succeeded ->    Connected
9	chip[DL]: WiFi station interface connected
10	chip[ZCL]: WiFiDiagnosticsDelegate: OnConnectionStatusChanged
11	chip[DL]: Done driving station state, nothing else to do...
12	chip[DL]: Updating advertising data
13	app_driver: Color mode not supported
14	main_task: Returned from app_main()
15	esp_netif_handlers: sta ip: 192.168.0.140, mask: 255.255.255.0, gw:    192.168.0.1
16	chip[DL]: IP_EVENT_STA_GOT_IP
17	chip[DL]: IPv4 address changed on WiFi station interface:    192.168.0.140/255.255.255.0 gateway 192.168.0.1
18	chip[DL]: IPv4 Internet connectivity ESTABLISHED
19	app_main: Interface IP Address changed
20	chip[DIS]: Updating services using commissioning mode 0
21	chip[DIS]: CHIP minimal mDNS started advertising.
22	chip[DIS]: Advertise operational node    676126B8A0315EF2-280BB2D72A5D0003
23	chip[DIS]: CHIP minimal mDNS configured as ’Operational device’;    instance name: 676126B8A0315EF2-280BB2D72A5D0003.
24	chip[DIS]: mDNS service published: _matter._tcp
25	chip[DL]: IP_EVENT_GOT_IP6
26	chip[DL]: IPv6 addr available. Ready on WIFI_STA_DEF interface:    fe80:0000:0000:0000:f612:faff:fefa:1ba4
27	app_main: Interface IP Address changed
28	chip[DIS]: Updating services using commissioning mode 0
29	chip[DIS]: CHIP minimal mDNS started advertising.
30	chip[DIS]: Advertise operational node    676126B8A0315EF2-280BB2D72A5D0003
31	chip[DIS]: CHIP minimal mDNS configured as ’Operational device’;    instance name: 676126B8A0315EF2-280BB2D72A5D0003.

To confirm the Advertising process, Wireshark network analyzer software is utilized. In Figure 7, IGMPv2 packets can be observed, highlighted in yellow, and mDNS packets originating from the Matter Accessory, highlighted in blue. In the context of Matter, the IGMP packets are utilized to announce that the device is joining a multicast group, which allows them to receive multicast traffic associated with Matter services. The mDNS service enables devices to announce their presence in the network and advertise the available services, permitting other devices on the network to use mDNS to resolve the hostnames and IP addresses of this commissioned Matter device. This allows them to dynamically discover and communicate with each other in the local network, which facilitates interoperability and efficiency among Matter-enabled devices. The fact that this gadget uses mDNS reduces complexity by requiring minimal configuration to set up and operate independently of the infrastructure [46].

This process is called Operational Discovery. The node instance name is crafted with a 64-bit compressed Fabric ID and 64-bit Node ID and then concatenated with a hyphen [47]. The node instance name can be observed in the red rectangle in Figure 7.

3.2. Device Control and Monitoring

To be able to interact with Matter-enabled devices, Controllers can use cluster control commands inherited from ZCL (ZigBee Cluster Library). In this case, when using a LAN, the Matter Controller is the mobile phone app. However, in the case of remote interaction with the device, the Internet (WAN) is utilized; therefore, the mobile phone app uses the cloud infrastructure to relay the control message to the local Matter Controller. With this, it is understandable that the Matter protocol only works in a LAN. In this case, the Xiaomi Home App changes the cluster’s attributes directly when the mobile phone is using the Wi-Fi from the smart home; however, when the LAN is not in range and mobile data are utilized, the Xiaomi Home App communicates via the cloud with the Xiaomi Smart Home Hub 2, which acts as a Matter Controller within the local network.

The implemented device is a Matter node, a unique, identifiable, and addressable resource within the network. Matter communications start and terminate at nodes. Each node has endpoints which can be thought of as virtual devices that provide services that are logically grouped. For instance, our endpoint is 0x0001. Each endpoint has clusters that represent specific functionalities that can be controlled. In our case, this “virtual device” within our device (endpoint 0x0001) has multiple application clusters, those being OnOff (Cluster ID 0x0006) and Level Control (Cluster ID 0x0008). Within the Level Control cluster, the associated stored attributes are Brightness, Color, and Color Temperature. To change each attribute state, specific commands are available. This allows us to control the state of the light, brightness, color temperature, and color of the onboard RGB on the ESP32-S3 via Matter. The real experiment can be observed in Figure 8.

By analyzing ESP32-S3 logs via the UART, as seen in Listing 5, when turning off the LED via the app, an instruction can be observed. This process, which is described in lines 1–6, is called an Invoke Transaction within the Matter Interaction Model. An Invoke Command Request is issued by the initiator (the Xiaomi Hub, which is the Matter Controller), diverse attributes from the specific cluster are read (which, in line 5, is represented by […] because it is extensive), and an Invoke Command Response is provided by the target (the ESP32-S3, which is the Matter Accessory). In line 8, a Report Data Action takes place, where the target sends back to the initiator the requested list of attributes. In lines 14–20, the device acting on the command by shutting the LED off can be observed. Then, in lines 21–25, data are again reported to the Matter Controller, updating the device’s state. With this, the initiator can control the target and remain updated on its attribute values.

	Listing 5. Device receiving OFF command.
1	chip[EM]: >>> [E:55603r S:65268 M:241839266] (S) Msg RX from    1:000000000000A8EA [5EF2] --- Type 0001:08    (IM:InvokeCommandRequest)
2	esp_matter_command: Received command 0x00000000 for endpoint    0x0001’s cluster 0x00000006
3	esp_matter_attribute: ********** R : Endpoint 0x0001’s Cluster    0x00000006’s Attribute 0x00000000 is 1 **********
4	chip[ZCL]: Toggle ep1 on/off from state 1 to 0
5	[...] (Reading attributes)
6	chip[EM]: <<< [E:55603r S:65268 M:15545545 (Ack:241839266)] (S) Msg    TX to 1:000000000000A8EA [5EF2]    [UDP:[FE80::56EF:44FF:FE49:BA64%st1]:5540] --- Type 0001:09    (IM:InvokeCommandResponse)
7	esp_matter_attribute: ********** R : Endpoint    0x0001’s Cluster 0x00000062’s Attribute 0x00000001 is 16 **********
8	chip[EM]: <<< [E:33244i S:65268 M:15545546] (S) Msg TX to    1:000000000000A8EA [5EF2]    [UDP:[FE80::56EF:44FF:FE49:BA64%st1]:5540] --- Type 0001:05    (IM:ReportData)
9	chip[EM]: >>> [E:55603r S:65268 M:241839267 (Ack:15545545)] (S) Msg    RX from 1:000000000000A8EA [5EF2] --- Type 0000:10    (SecureChannel:StandaloneAck)
10	chip[EM]: >>> [E:33244i S:65268 M:241839268 (Ack:15545546)] (S) Msg    RX from 1:000000000000A8EA [5EF2] --- Type 0001:01    (IM:StatusResponse)
11	chip[IM]: Received status response, status is 0x00
12	chip[EM]: <<< [E:33244i S:65268 M:15545547 (Ack:241839268)] (S) Msg    TX to 1:000000000000A8EA [5EF2]    [UDP:[FE80::56EF:44FF:FE49:BA64%st1]:5540] --- Type 0000:10    (SecureChannel:StandaloneAck)
13	[...] (Reading and writing attributes)
14	chip[ZCL]: Setting on/off to OFF due to level change
15	esp_matter_attribute: ********** R : Endpoint 0x0001’s Cluster    0x00000006’s Attribute 0x00000000 is 1 **********
16	chip[ZCL]: Toggle ep1 on/off from state 1 to 0
17	esp_matter_attribute: ********** W : Endpoint 0x0001’s Cluster    0x00000006’s Attribute 0x00000000 is 0 **********
18	[...] (Reading and writing attributes)
19	chip[ZCL]: Off completed. reset OnTime to  0
20	[...] (Reading and writing attributes)
21	chip[EM]: <<< [E:33245i S:65268 M:15545548] (S) Msg TX to    1:000000000000A8EA [5EF2]    [UDP:[FE80::56EF:44FF:FE49:BA64%st1]:5540] --- Type 0001:05    (IM:ReportData)
22	chip[EM]: >>> [E:33245i S:65268 M:241839269 (Ack:15545548)] (S) Msg    RX from 1:000000000000A8EA [5EF2] --- Type 0001:01    (IM:StatusResponse)
23	chip[IM]: Received status response, status is 0x00
24	chip[EM]: <<< [E:33245i S:65268 M:15545549 (Ack:241839269)] (S) Msg    TX to 1:000000000000A8EA [5EF2]    [UDP:[FE80::56EF:44FF:FE49:BA64%st1]:5540] --- Type 0000:10    (SecureChannel:StandaloneAck)
25	esp_matter_core: Store the deferred attribute 0x0 of cluster 0x8 on    endpoint 0x1

3.3. Security Risks

Integrating a Matter ecosystem into an existing home network enhances significantly the universality of the device and smart home ecosystems. However, it might introduce new security challenges, which should be addressed in protocol development and integration to ensure overall system reliability.

Recent studies on Wi-Fi-based behavior recognition (WBR) techniques present vulnerabilities to signal manipulation attacks, such as jamming. By exploiting physical signal manipulation, in [48], the authors performed untargeted and targeted attacks with high success rates (80% and 60%) when analyzing four real-world WBR systems. Due to the fact that several smart home devices, including this sample, utilize Wi-Fi, untargeted attacks could disrupt device functionality by causing intermittent failures and/or erratic performance. On the other hand, targeted attacks might gain unauthorized control of the device or access sensitive data. These kinds of attacks might compromise the reliability and integrity of these new devices.

Some of these smart devices might leverage the usage of deep learning techniques that enhance the performance and accuracy of their specific tasks. The authors in [49] developed a specific type of adversarial perturbation attack that is broadly applicable, robust, and stealthy. Data from sensors can be corrupted or manipulated, leading to unwanted device behavior. For example, if a Matter-compatible door lock is compromised, unauthorized individuals can obtain access to the household, therefore posing a significant security risk and potentially leading to severe consequences.

To mitigate these threats when developing Matter devices, strengthening the encryption to prevent unwanted signal manipulation, and improving authentication to achieve integrity in device control, is eminent. Furthermore, developing Machine Learning (ML) techniques to recognize normal operational patterns and detect deviations that suggest that attacks are in process is also important. A security-by-design approach when implementing this protocol is important, as well as frequent security audits and updates to ensure Matter devices’ software is patched against known vulnerabilities, therefore reducing the probability of attack occurrence and erratic device behavior. These and other features should be constantly updated by Over-The-Air (OTA) updates.

4. Conclusions

Several IoT protocols were studied, as well as some smart home products on the market. It can be perceived that the adoption of smart home gadgets presents some barriers, namely, the lack of interoperability between systems and devices. Users tend to have the issue of having multiple applications to control different appliances.

However, the usage of different link local protocols is here to stay. Some devices require higher data throughput to the network due to their applications, while others can work easily on batteries. On top of this, devices can be provisioned using P2P communications, increasing the ease of setup for the end user. These types of gadgets should be developed according to their requirements but also leverage simplicity of configuration for the end user.

In this scenario, the Matter application protocol is well designed and can stack on top of the required technology, whether it be a low-power sensor running on batteries or even an air purifier that needs a constant electrical supply. Data link technologies such as Thread, Wi-Fi, and BLE are utilized, and devices can communicate with each other despite their architecture and manufacturer as long as they can run Matter applications over IPv6. This will certainly allow users to improve their ecosystems by reducing the complexity of their smart home and enhancing interoperability between contrasting kinds of devices from different manufacturers.

Espressif is one of many manufacturers that are boosting smart home devices development. In this work, a sample of firmware from a Matter light was flashed to an off-the-shelf development kit using the SDKs provided by the fabricant. A proof-of-concept uncertified device was implemented with ease. To scale this to a real product, companies have to design the specific hardware, make some minor firmware changes, and obtain certification from the CSA. Therefore, it is understandable how enhanced device development is, namely, because software development is what takes the most time.

In sum, a Matter ecosystem was created with Xiaomi products, and an Espressif board served as Matter Accessory. It is proved that a manufactured device, independently of its fabricant, can be integrated into any type of smart home that leverages Matter with ease. However, a hub for the ecosystem is still required so it can act as a Matter Controller within the LAN, and a cloud connection can be made to enable remote control and monitoring. However, hardware complexity is still reduced due to common layers above the data link, specifically, IPv6 on the network, TCP and UDP on transport, and Matter on application.

In future work, different types of clusters should be studied and other proof-of-concept devices implemented, particularly gadgets that are not available on the market, such as air quality sensors and automated windows. This protocol might be combined with other types of cutting-edge secure cloud infrastructures that provide device management, data collection, storage, processing, and analytics. With this, the ecosystem can be perceived, predicted, and proactive.