As a ‘Matter’ of Fact

Inside Latest Home Control Consolidation Attempt via Google Home and Matter-over-Thread

In last month’s column, Jeff showed us how to build a smart thermostat, using Silicon Labs MGM240 module and a Sparkfun Thing module. This month, he examines the intricacies of melding this hardware and Matter software into a device that can replace an existing thermostat. Access is controlled by Google Home via the Matter-over-Thread network supported by the MGM240.

In the ‘80s, the American Association of Home Builders first used a term to describe an automated home system that would become commonplace in future homes. Here we are in 2024 and “Home Control” or “Home Automation” (HC or HA) is far from common. Even with many companies manufacturing HA devices, very few households have currently implemented them in any serious way.

With the change of the century, some high-level HA software for Windows, Apple, and Linux machines began to surface. Home Assistant and OpenHAB have been some of the more successful open-source favorites. While these attempt to support the plethora of devices and protocols presently being manufactured, they continue to require a mishmash of support, because there are no standards.

If you have some semblance of an HA system in your home, you know that adding a new device is not a simple task. Each device has its own application that must be used to add it to your system. Unless you are going to use that app every time you want to control that device, adding it to your system can be another level of frustration.

PROPRIETY

Several different wired and wireless protocols are now used by devices in an HA environment, Wired devices may use power-line transmissions (like X-10 or Universal Powerline) Bus, Ethernet, or may be directly connected to your system I/O. Wireless devices may use Wi-Fi, Bluetooth, Zigbee, and Z-Wave.

Protocols thus abound, and many are proprietary. Some companies feel they must tightly control a protocol, so it can’t be abused or even used by others without the proper compensation. This makes it more difficult for one company’s device to control or be controlled by another company’s device. To bridge two devices, a request might have to be transmitted to the company’s cloud site to control a device locally. Should your Internet go down, that device can no longer be controlled.

There have been attempts to create some kind of universal interface, such as USNAP. In 2011 (Circuit Cellar #246, January, 2011) [1] I did a project with that device. I recently tried to look up that protocol again, and it is literally gone. Most Google references will bring you to a “403 Forbidden” webpage or a “We’re having trouble finding that site” message. Crushed or absorbed, I’m not sure. It was backed by a number of big companies, including Google, GE, Carrier, Insteon, and Microchip.

In 2014 the Thread Group was established to bring security and mesh networking to Wi-Fi (IEEE 802.11), with the help of the Zigbee Alliance. The Zigbee Alliance is IEEE 802.15.4, and is known for its self-organizing, self-healing mesh topology, based on 915MHz and 2GHz.

• IEEE 802.11 is commonly known as Wi-Fi and uses high-data-rate wireless access technology for devices. This outlines the architecture and defines the MAC and physical layer specifications for wireless LANs (WLANs).
• IEEE 802.15.4 is a low-cost, low-data-rate wireless access technology for devices that are operated by or work on batteries. This describes how low-rate wireless personal area networks (LR-WPANs) function.

Thread: Thread is an IPv6-based networking protocol designed for low-power Internet of Things (IoT) devices in a wireless mesh network, known as a Wireless Personal Area Network (WPAN). Thread is a pipe or connection much like Zigbee, Z-Wave, and Bluetooth LE. Each thread device or node is a mini-router that forms a mesh network with other devices. This network is entirely separate from your LAN and does not require Wi-Fi, LAN or Internet access.

There are products on the market right now that support Thread. Many of these are Wi-Fi-based and act as a Thread edge router or link between a Thread network and your Wi-Fi, LAN, and the Internet. Every Thread device is a router, but not all are edge routers. You only need an edge router to make that Wi-Fi connection, though multiple edge routers will supposedly increase reliability.

Google has released OpenThread, an open-source implementation of Thread, to make the networking technology they used in Google Nest products more broadly available to developers, to accelerate the development of products for the connected home and commercial buildings.

Matter: Isn’t there something that combines Thread devices and your local LAN devices under one roof? That would be the ultimate unifier. What started out as Project CHIP (Project Connected Home over IP) has been repackaged as “Matter.” Matter is an open-source implementation of a new, unified connectivity protocol.

Matter makes it easier for device manufacturers to build products that are compatible with smart home and voice services, such as Amazon’s Alexa, Apple’s Siri, Google’s Assistant, and others. The first specification release of the Matter protocol will run on Wi-Fi and Thread network layers, and will use Bluetooth Low Energy for commissioning. Ah, commissioning. If you’ve ever added HA devices in your home, commissioning is the hoop you must jump through to get your device recognized by an app that will allow you to control/monitor the device. It’s a pain, and requires a different app for each device.

A Matter-enabled device will use Bluetooth to connect to the device and register it with your HA system. Matter is supported by four of the biggest names in HA: Google Home, Apple Home, Samsung SmartThings, and Amazon Alexa. If you are using one of the open-source apps like Home Assistant, there is preliminary support for Matter. Matter commissioning looks somewhat different, depending on which HA application you will be using, but they are all consistent. Commissioning is a four- step process. The prerequisites are: power on a Thread Edge Router (such as Google Nest Hub); power on your device; and open your HA application (such as Google Home).

The prerequisite commissioning steps are:

• Choose to add a Matter device.
• Type in your device’s Matter pairing code (use your camera to scan its QR code).
• Bluetooth will make a connection and pass some credentials.
• The device will be recognized by your Thread Edge Router and will be installed.

ARDUINO MATTER SUPPORT

At the start of last month’s project (Circuit Cellar #411, October, 2024) [2], Arduino was supporting two devices—Nano Matter and Sparkfun’s Thing Plus Matter. While both use the same Silicon Labs MGM240 modules and were about the same price, only the Sparkfun DIP was available. So last month’s project was based on the Sparkfun device. Not only was I going to delve into unexplored territory using a newly supported device, but also, my end goal was to have some hardware that had a Matter interface. Which brings you all up to speed.

Silicon Labs has really put together some extensive examples using this device. For this month’s project, let’s look at the simplest example, before working on the thermostat interface. You will need to go to GitHub’s Silicon Labs/Arduino webpage [3] to download the required library file for the Matter-supported MGM240. Click on “CODE” and download the .zip file. Install this into your Arduino IDE under the sketch tab, choose “include library” and “add ZIP library.” Pick the downloaded arduino-main.zip file, and you will have a new entry under the tools tab for Board: ->Silicon Labs. Silabs is supporting Sparkfun, Nano and a number of their own Matter dev boards.

With one of Silab’s Matter boards selected, you will find over a dozen examples of Matter devices to choose from. Let’s first look at the light bulb device—one of the simplest applications.

Two library files are used for this application (see Listing 1). The general Matter.h file is used for all Matter applications, and a device-specific file MatterLightbulb.h is for this demo using an LED to simulate a light bulb. There is a lot going on in the setup() function. If the device has never before been added to a Thread network, then it must be commissioned or given permission to join. It uses Bluetooth to do this. I am using a Google Nest Hub (7” display) as Thread edge router, and the Google Home application as my HA interface. When I add a device with Google Home on my Android phone, the app will offer to scan a QR code or allow a PIN to be manually entered.

Listing 1
Note here that the setup() function handles all the commissioning, if this has never been done before. Otherwise, it waits for the Thread network to find the device, and then it waits for Matter to discover it on the network.

#include <Matter.h>#include <MatterLightbulb.h>MatterLightbulb matter_bulb;void setup(){  Serial.begin(115200);  Matter.begin();  matter_bulb.begin();  pinMode(LED_BUILTIN, OUTPUT);  digitalWrite(LED_BUILTIN, LED_BUILTIN_INACTIVE);  Serial.println(“Matter lightbulb”);  if (!Matter.isDeviceCommissioned())   {    Serial.println(“Matter device is not commissioned”);    Serial.println(“Commission it to your Matter hub with the manual pairing code or QR code”);    Serial.printf(“Manual pairing code: %s\n”, Matter.getManualPairingCode().c_str());    Serial.printf(“QR code URL: %s\n”, Matter.getOnboardingQRCodeUrl().c_str());  }  while (!Matter.isDeviceCommissioned())   {    delay(200);  }  Serial.println(“Waiting for Thread network...”);  while (!Matter.isDeviceThreadConnected())   {    delay(200);  }  Serial.println(“Connected to Thread network”);  Serial.println(“Waiting for Matter device discovery...”);  while (!matter_bulb.is_online())   {    delay(200);  }  Serial.println(“Matter device is now online”);}

Listing 2
In the loop() function we can use the function matter_bulb.get_onoff() to determine if the state has changed. We are simulating a light bulb with the built-in LED, via the digitalWrite() function. The state is also sent as a serial print statement to the serial port for debugging purposes.

void loop(){  static bool matter_lightbulb_last_state = false;  bool matter_lightbulb_current_state = matter_bulb.get_onoff();  // If the current state is ON and the previous was OFF - turn on the LED  if (matter_lightbulb_current_state && !matter_lightbulb_last_state) {    matter_lightbulb_last_state = matter_lightbulb_current_state;    digitalWrite(LED_BUILTIN, LED_BUILTIN_ACTIVE);    Serial.println(“Bulb ON”);  }  // If the current state is OFF and the previous was ON - turn off the LED  if (!matter_lightbulb_current_state && matter_lightbulb_last_state) {    matter_lightbulb_last_state = matter_lightbulb_current_state;    digitalWrite(LED_BUILTIN, LED_BUILTIN_INACTIVE);    Serial.println(“Bulb OFF”);  }}

Listing 3 
Special functions available for our thermostat can be found in the MatterThermostat.h file.

int16_t get_local_temperature_raw();
void set_local_temperature_raw(int16_t local_temp);float get_local_temperature();
void set_local_temperature(float local_temp);
int16_t get_heating_setpoint_raw();
void set_heating_setpoint_raw(int16_t heating_setpoint);
float get_heating_setpoint();
void set_heating_setpoint(float heating_setpoint);

void set_absolute_minimum_heating_setpoint(float abs_min_heating_setpoint);
void set_minimum_heating_setpoint(float min_heating_setpoint);
void set_absolute_maximum_heating_setpoint(float abs_max_heating_setpoint);
void set_maximum_heating_setpoint(float max_heating_setpoint);
float get_absolute_minimum_heating_setpoint();
float get_minimum_heating_setpoint();
float get_absolute_maximum_heating_setpoint();
float get_maximum_heating_setpoint();

thermostat_mode_t get_system_mode();
void set_system_mode(thermostat_mode_t system_mode);

Listing 4
 The first two functions start the Matter.h and the MatterThermostat.h libraries. I have combined the commissioning into a function to simplify the setup() function. This initializeMatterThermostat() function will handle an initial sync with the external Matter thermostat control.

 //----------------   // start setup Matter  Matter.begin();  matter_thermostat.begin();  matterCommission();  initializeMatterThermostat();  // end setup Matter  //----------------  

Note in Listing 1 that when this application is executed, it will check to see if it has ever been commissioned. If not, it will display an 11-character PIN that can be entered directly into the commissioning application and a web address that will generates a QR code. You can scan this code instead of entering the PIN. Remember to print the QR code; it is unique to your MGM240 device and can be used in the future to identify it.

The Google Home app will scan the QR code or accept the PIN, make a Bluetooth connection to the device, and transfer Thread information, so that the device can log onto the Thread network. Once the device is found by the edge router and allowed on the network, the device then waits for Matter to discover the device. Once discovered, the device will become part of the Matter fabric consisting of devices that trust and communicate with each other.

You’ll note that the light bulb is now accessible from the Google Nest Hub or the Google Home app. Although a command can be sent to turn the light bulb (LED) on or off, the command doesn’t actually turn ON or OFF the light; it only keeps track of the requested state. It is our application’s job to handle the heavy lifting by constantly checking for the state using the routine matter_bulb.get_onoff(). We can use a few Boolean variables to determine if the state has changed, and if so, execute a routine to handle that change of state. In this case, we will turn the LED ON or OFF (Listing 2).

As you can see in Listing 2, this application uses a single matter_bulb function. Are there others? If you look at the MatterLightbulb.h file, you will find a section “class MatterLightbulb,” and it will list the available routines for the class device. In this case it’s:

void set_onoff(bool value);
bool get_onoff();
void toggle();

You can see that there are two additional functions besides get_onoff(), set_onoff(bool value) and toggle(). We could add an external push button like the one on our prototype, and use it to locally turn the LED ON or OFF or toggle it. If we then use the available routines to update the Matter state, it will handle sending a command back to reflect the local change. We could substitute a relay on our prototype for the LED, and we have then allowed the Matter_Lightbulb class to turn ON and OFF the relay, If we used the relay to control a floor lamp, we’ve just made a useful device.

You might want to look at other similar examples: matter_lightbulb_with_button, and matter_on_off_outlet. Okay, we’ve covered the two areas we need to deal with when creating a Matter-enabled device, commissioning and how we use a Matter library’s functions to pass info between our application and the Matter interface. So let’s take our prototype thermostat, developed last month, and add the necessary hooks to allow it to be controlled by Google Home through Matter over Thread.

THERMOSTAT

When I chose Sparkfun’s MGM240P DIP module as the basis for last month’s thermostat project [2], it was the only Matter-compatible product available at the time that had such a large set of example applications. Not having used a Silicon Labs processor in the past, it was a good opportunity to try out something new. So I slowly developed the thermostat project by introducing one function at a time—adding some digital I/O, then analog temperature measurement, and finally adding an SPI display and touchscreen.

Having looked briefly at the Matter-enabled thermostat example, I tried to keep in mind what would be necessary to make this hardware compatible with the example given, without giving my ultimate goal away until this month. Hopefully, I can meld this hardware and the Matter software into a usable device and then replicate it to replace the three thermostats in my house. Then I’ll have access to each thermostat through Google Home via the Matter over Thread network supported by the MGM240.

As seen in the first Matter application, Matter Lightbulb, there are basically two processes that we need to add to our existing thermostat project—commissioning and data exchange. The first will be the same for every Matter device, and the second will be customized to the type of device we are developing. For this project we will be adding the general Matter.h library that covers commissioning, and also the specialized library, MatterThermostat.h, which will cover the specific operations of our thermostat project.

If you refer the MatterThermostat.h file, you can find the special functions available for our thermostat (see Listing 3).

Five parameters are being handled here in these functions. The local_temperature is the actual room temperature that the TMP36 is measuring. This could be a separate MatterTemperature device mounted in the room, but I have integrated a device locally. The heating_setpoint is the requested temperature normally set by the user. I have enabled this as a local user function for this project.

The next two functions have to do with the allowable upper and lower limits to which the user can set the heating_setpoint. The user’s available range will be limited to the minimum and maximum setpoints. The absolute limits are the practical limits of the system. A facility’s administrator may want to set the minimum and maximum user-adjustable range to a somewhat limited range between the absolute max and min. Finally, thermostat_mode is essentially an ON/OFF switch to the system in this version; the only choices are Off and Heat. This is where other modes could be established. Note the value of mode 0=OFF and 4=Heat. These values suggest that other modes might be available, such as Cool or Fan. In fact, if you look at the Matter Application Cluster Specification under SystemMode Attribute, it specifies the current operating modes of the thermostat (see Table 1).

Table 1– It looks like Silabs chose to limit its thermostat demo to Off and Heat only, thus, the logic explanation of its mode values.

• Table 1
• Table 2

Now let’s look at how the Matter libraries are integrated into our thermostat project. I defined all the local variables we need in my column last month [2], when the Analog Temperature Sensor was added. So we only need to add the Matter.h and the MatterThermostat.h libraries and a bit of code to the setup() function (Listing 4).

If the thermostat has not previously been commissioned, then it will be handled in the matterCommission() routine. The commissioning function was discussed earlier. Once a device has been commissioned, its certificates to verify that the authenticity of the device have been saved in NV RAM. Note that if you wish to reuse the node as a different device type, the stored data can be erased by re-burning the bootloader. If our node has been Commissioned, it will wait for the Thread network to add it to the group. Once in the Thread group, Matter will discover and enable it, and the project becomes part of the Matter fabric.

Now we must make a connection between our local variables and Matter Client Thermostat Cluster interface. This is handled by each local function that affects a local variable. These include the mode, centigradeAverage, heatingSetpoint, maximumHeatingSetpoint, and the minimumHeatingSetpoint. For instance, with the displayMode() function, we were already checking for a change of state in the local mode. In that routine, we update the Matter interface when the local mode is changed. When it changes to OFF, the Matter interface is updated using the following command:

matter_thermostat.set_system_mode(MatterThermostat:: thermostat_mode_t::OFF);

In addition to the local mode test in the displayMode() function, a second test now tests for a change in the Matter interface using the command:

if(lastM != matter_thermostat.get_system_mode())

{

displayModeMatter();

}

The displayModeMatter() function will then change local mode. These routines will keep both our local display and the Matter interface in sync as far as the mode goes. All of the other variables are treated in a similar fashion, except for the actual temperature, centigradeAverage, which cannot be altered by the Matter interface. In fact, if we used an external Matter temp_sensor, it could be used as an input to a thermostat that did not have an internal sensor. Also, an external Matter on_off_outlet, which controls a relay, could take the place of the local relay on our thermostat. Matter seems to be very flexible. With the use of an external Matter on_off_outlet (relay), which could connect directly to your furnace thermostat inputs, you could eliminate the thermostat wiring normally run from the furnace to the thermostat!

INSTALLATION

After my thermostat project’s PCB was programmed, I fired it up, and the sign on screen (TFT) displayed the sketch name and date. I had to start adding this, so I could easily find the sketch from among more than 400 sketches I now have on my PC. After this brief screen I got the following:

Waiting for Commissioning

Use this code 34970112332

This was my cue to open the Google Home app on my phone. Under “Devices” I hit the “+ add” button, and was presented with the choices shown in Figure 1. I selected “Matter choice” and now had the opportunity to scan a QR code or set up without QR code (manually enter the code), as shown in Figure 2. Now my phone attempted to connect to the thermostat over Bluetooth, made contact, and gave me a warning message about uncertified devices (Figure 3). After clicking on “install anyway,” the app completed the install with a “Device connected” message (Figure 4). Since the Silicon Labs examples are intended for experimentation only, no certification is available. You may join the Connectivity Standards Alliance (CSA) to become a member and certify a product [3].

• Figure 1
• Figure 2
• Figure 3
• Figure 4

While the app is negotiating with the node, the thermostat displays this message:

Waiting for Thread Network

Then, once its becomes part of a Thread by the Google Nest Hub edge router:

Connected to Thread network

Waiting for Matter device discovery…

Finally, once the node is discovered by the app via Thread-over-Wi-Fi:

Matter On Line

After the commissioning was finished, the thermostat began displaying its normal display as shown in Figure 5.

On my phone, the Google Home app had the thermostat installed and displayed the thermostat as shown in Figure 6. The number in the center is the setpoint. The user can change this by dragging the small circle along the large arc. The actual temperature is displayed below the word “indoor” and also as the small dot on the large arc. The mode is displayed below the temperature as a button with an icon. You can change the mode with this button, and the mode is displayed as a flame or Off switch icon. On the Google Nest Hub, the thermostat is displayed as shown in Figure 7. The same user adjustments are available on this hub display.

• Figure 6
• Figure 7

CONCLUSION

I was able to alter a Matter demo example written by Tamas Jozsi (Silicon Labs) [4] to construct a useful thermostat for my home. Silicon Labs has really put some effort into supporting the Sparkfun and Arduino Nano Matter boards. I hope they will continue adding examples for some of the newer devices that the latest revision (1.3) of the Matter specification supports.

Although Thread and Matter are supposed to bring all Home Automation equipment into one happy family, there are still some hurdles to get over. I see two particularly large obstacles. First, each of the “Big 4” currently creates its own Thread network. These networks should be able to work together under Matter; however, a universal method of sharing credentials has not been agreed upon. The Thread Group is attempting to solve this issue.

Second, devices can have mandatory, optional, and undocumented commands. Not every manufacturer is willing to turn over complete control of all its devices. That’s not how the railroad is run. There will continue to be glitches until all are willing to work together on an equal footing. Put your egos aside, use consensus to define the specifications, and then abide by the rules. Until then, we will remain fragmented into different camps.

I am pleased with the speed with which the Connectivity Standards Alliance (CSA) has released new standard specifications (Table 2). With an open source and no license fees on sold devices, this could lead to a boom in new HA devices and widespread use. Certification testing costs, registration fees, and CSA membership are the only external costs for a developer.

For someone who has followed the HA trends for more than 40 years, the ultimate answer seems to continuously fall somewhere on the horizon. Like the carrot on the stick, those who are seeking some sort of HA nirvana are constantly willing to accept the next big thing. Let’s hope that Thread and Matter are the final steps to reach that pot of gold. Too much to learn, too little time. 

RESOURCES
Silicon Labs | www.silabs.com
Google | www.google.com
Thread Group | www.threadgroup.org
Connectivity Standards Alliance | www.csa-iot.org

REFERENCES
[1] Circuit Cellar #246, January, 2011. FROM THE BENCH—Smart Network Access Point by Jeff Bachiochi
[2] Jeff Bachiochi, “Turning Up the Heat: Building A Smart Thermostat.” Circuit Cellar #411, October, 2024.
[3] Download the required library file for the Matter-supported MGM240 at GitHub’s Silicon Labs/Arduino webpage: https://github.com/SiliconLabs/arduino
[3] Join the Connectivity Standards Alliance to certify a product: https://csa-iot.org/become-member/
[4] Matter demo example written by Tamas Jozsi (Silicon Labs):
https://github.com/SiliconLabs/arduino/blob/main/libraries/Matter/examples/matter_fan/matter_fan.ino
[5] Matter 1.3 Specifications: https://csa-iot.org/developer-resource/specifications-download-request/

SOURCES
csa-iot.org/resources/developer-resources/ Matter standards, Connectivity Standards Alliance
www.threadgroup.org/support#Resources Thread standards, Thread Group
matter-smarthome.de/en/homepage/  Independent information on Matter
home.google.com/welcome/ Google Home
www.apple.com/home-app/ Apple Home
www.samsung.com/us/smartthings/ Samsung Smarthings
www.amazon.com/b?&node=17386948011&ref=MARS_NAV_desktop_plswitcher Amazon Smart Home
www.home-assistant.io Home Assistant

Code and Supporting Files

PUBLISHED IN CIRCUIT CELLAR MAGAZINE • NOVEMBER 2024 #412 – Get a PDF of the issue

Jeff Bachiochi

Website |  + postsBio

Jeff Bachiochi (pronounced BAH-key-AH-key) has been writing for Circuit Cellar since 1988. His background includes product design and manufacturing. You can reach him at: jeff.bachiochi@imaginethatnow.com or at: www.imaginethatnow.com.

• Jeff Bachiochi

  https://circuitcellar.com/author/jeff-bachiochi/

  Wireless Music
• Jeff Bachiochi

  https://circuitcellar.com/author/jeff-bachiochi/

  3-Axis Digital Compass IC Modules
• Jeff Bachiochi

  https://circuitcellar.com/author/jeff-bachiochi/

  Printed Circuit Boards (PCBs)
• Jeff Bachiochi

  https://circuitcellar.com/author/jeff-bachiochi/

  Lighting a Miniature Holiday Village