Connected electricity meter with Matter over Thread

Connect your electricity meter to your futuristic smart home ecosystem, thanks to the new Matter over Thread protocol !
Dev kit running app
Dev kit running the Linky-Matter application

The electric meter that Matters !

In every building, there is an electric meter installed by the electricity company. In some countries such as France, these meters can communicate real-time data about your power consumption and total count. The total consumed energy appears on your bill at the end of the month. With my system, you can check it (and more!) at real-time, on your phone, thanks to the Matter over Thread wireless protocol !

This project was initially published on Elektor Labs for the STM32 Wireless design contest proposed by Elektor Magazine and STMicroelecronics in February 2024.

Note 07/03/2024: My project is part of the five which have been selected among 26 projects for the win. The winner will be announced at Embedded World 2024. I’ll be there for sure !

Note 15/04/2024: During the award ceremony at Embedded World exhibition in Nüremberg on April.10th, I’ve been awarded the 3rd place ! That’s a very high honor I received here for my work. You can see more about this in the dedicated article I wrote.

Bill of Materials:

  • STM32WB5MM-DK
  • Custom PCB
    • MB1S diode bridge rectifier
    • ISP814X AC Opto-isolator
    • AMS117 LDO regulator
    • BS170 MOS
    • Resistors & Capacitors
  • A building with a Linky electricity meter

Context

A few years ago, all the French electricity counters have been replaced by the grid manager company (Enedis). They’re named “Linky” and they communicate from your house to your supplier thanks to a line carrying current. Not many people know that they can communicate to a consumer device inside the building.

Linky
The Linky power meter

The data is transmitted from the meter through three plugs, named L1 L2 and A. The data is available between the L1 and L2 while we can get a power output between L2 and A. The signal is an UART at 9600 baud, with one start bit, 7 data bits and an even parity bit, carried on a signal at 50kHz. This data is named “TIC”, which stands for “Télé-Information Client” that we could translate to remote customer information. The power signal on its side has an RMS voltage of 6V and can supply up to 130mW. The RMS stands for Root Mean Square, which is the effective voltage equals to

V_{RMS} = \frac{V_{pp}}{\sqrt{2}}

If we convert it to 5V, it means that we can supply a microcontroller easily with a current of

P = U.I \rightarrow I = \frac{P}{U} = \frac{0.13}{5} = 26mA

More than enough for a MCU! The kind of information that can be retrieved is very wide (around 70 fields), I’ll summarize here the most interesting ones:

  •  Current apparent power consumption, in VA
  • Current RMS current consumption, in Amps
  • Average RMS voltage, in Volts
  • Total consumed power since the counter installation, in kWh My goal will be to retrieve this data and stream wirelessly to my Smart Home ecosystem. Below is the high-level architecture of my system. 
Flowchart high-level architecture
High-level architecture

Convert data for the MCU

The first step in the loop is to convert the data outputted from the Linky to a clean UART link that can be interpreted directly by the STM32. To do so, I designed a custom electronic circuit, inspired by some other people on the internet who tried this before.

Schematic
Schematic of the PCB

Above is my schematic. The signals from the electric meter enter the circuit on the connector J1. Then, I1 and A are routed to a bridge rectifier D1 and finally to a low-dropout voltage regulator UR1. Some (big) capacitors are around to make a clean signal that can resist to current consumption peaks.

On the lower side, I1 and I2 are taken to an AC opto-isolator U1 to get rid of the carrier signal. At the output of the isolator, the UART signal as we’re used to see it is there! As it’s not properly referenced to the ground, the MOS Q1 is added before the actual UART output (and it also inverts back the signal).

Finally, all of these signals are routed to a 100mil pin header that will be connected to the CN5 connector on the STM32 Dev Kit. Note that the 5V from the LDO can be separated from the 5V sent to the dev kit (and same for the GND) with jumpers. This is to be able to power the circuit from the dev kit, instead of providing power to it. I did this because the dev board consumes more energy than what can flow out of the Linky, as the display and sensors around the MCU requires to be powered. Another configuration that works is to put a 3.3V regulator on the PCB, not a 5V. Feeding the MCU power directly is possible; it can be made through the JP1 jumper to bypass all the power lines.

Dev kit schematic
Power lines schematic of the dev kit

The PCB I designed has been made with a CNC mill. You’ll see below the expectation and the reality.

PCB 3D
3D view of the designed PCB
Soldered PCB
Resulting PCB

Below are some scopes to visualize the binary signal at each step of its transformation.

LDO output
Output of the LDO
Input signal
Input signal between I1 and I2
Output of opto-isolator
Output signal of the opto-isolator
UART signal
The final UART signal

The software concept

Now that we have a physical signal available on the pins of the microcontroller, it’s time to think about the software that will make it alive, smart and useful. What I would like is that once the signal is acquired and parsed, it’s transmitted to a smart home ecosystem, without wires.

Many wireless physical and application protocols exist, such as Zigbee, Z-Wave, proprietary RF, LoRa WiFi and many more. My electricity meter is in my house, which is not so big so I can exclude the long-range protocols: bye LoRa! Then I want something standard: bye proprietary RF! In general, I don’t want my smart objects to be on the WiFi network: bye WiFi! Finally, I was recently curious about the Matter over Thread protocol: we have a match!

First, Thread. It’s our RF protocol here. Wikipedia describes it well “Thread is an IPv6-based, low-power mesh networking technology for Internet of things (IoT) products.” It’s IP based so it can be connected to the internet and the other devices on the network (WiFi and Ethernet) by routing the traffic through a Border Router. It’s using the 2.4GHz frequencies range.

Thread logo
Thread’s logo

On top of this, the Matter application protocol is used. It was previously called Connectedhomeip. Wikipedia, again: “Matter is an open-source connectivity standard for smart home and IoT (Internet of Things) devices. It aims to improve interoperability and compatibility between different manufacturer and security, and always allowing local control as an option.” It’s a very recent protocol standardized by the CSA (Connectivity Standards Alliance) and pushed by major companies such as Apple, Amazon and Google.

Matter logo
Matter’s logo

To make it easy, it means that thanks to Matter, you can connect a smart device from any manufacturer to any home hub and ecosystem. It’s not mandatory anymore to have the home hub from the same brand as your device. In addition, commissioning devices in a Matter network needs a manager (such as a home hub) but this is not mandatory after this. The devices in the fabric can communicate point-to-point. You already may have read articles about this recently in Elektor.

Thread topology
Topology of a Thread network

Matter relies on the IP network for communication, so it can be run on devices with WiFi, Ethernet and Thread connectivity. For the commissioning process (joining a new device to the fabric), the BLE or NFC link is used. Then, our STM32WB5MM-DK is perfect, because it has the 2.4GHz capabilities for Thread and BLE.

Demo kit
STM32WB5MM Dev kit

The Matter stack is available publicly on its GitHub repo. It relies on the “Zigbee Cluster Library” to describe its clusters and attributes. The latest version of the Matter standard features some standard and well recognized clusters, but it’s completely possible with some development efforts to handle proprietary custom clusters. This feature is important for me as the Linky meter shows non-standard attributes.

The software in itself

The software for the MCU has been written in C and C++, while Python was used for retrieving and visualizing the data. It can be cut in four big parts: 

  1. The Matter stack and business logic
  2. The UART acquisition and processing
  3. The Matter clusters update
  4. The hub side 

The Matter stack and business logic

The Matter stack available on the Connectedhomeip’s repo is generic and has to be fitted to the specific device it will be ran on. In our case, it has already been adapted to the STM32WB55 by ST and they provided this adaptation as sample projects on their public GitHub. For the STM32WB5MM-DK, we have the choice between two projects, which are a “lighting app”, simulating a light bulb, and a “window app” acting as a window opener.

This code is a very good base for my project as ST took care of making run the Matter stack on their MCU and interacting with the Thread radio. The user “just” has to write the application software, the business logic behind and update the clusters.

I forked the repo and modified the lighting app to create an “electrical measurement” app from this. The project runs on FreeRTOS to handle multiple threads and dynamic memory allocation. The hardware layers have been generated with the STM32Cube suite.

The Matter stack runs in a thread of the main MCU core in parallel of the main application, while the Thread RF stack runs in the network core.

As a Matter application is about clusters and attributes, the first thing to do is to declare them to your application. To do so, the stack provides a “ZAP tool” to graphically manage the clusters and attributes then to create the corresponding C++ source files.

ZAP
ZAP tool’s interface

In my case, I declared the “Electrical measurement” cluster and a few of its attributes. As it was lacking some of the attributes that I was retrieving from the Linky, I created a custom cluster that I named the “Enedis-TIC”. I’ll detail this one a bit later! I won’t explain how to use the ZAP tool and the clusters of Matter because it would take hundreds of pages, It’s a very deep subject.

The UART acquisition and processing

As mentioned earlier, the decoder board streams the binary data to the MCU on an UART link, at 9600 baud with one stop bit and one even parity bit. I connected this binary stream to the pin PC0, configured as alternate function to be connected to the LPUART1 peripheral.

The UART stream starts with an ASCII STX byte and ends by an ETX byte. In between, each line starts with an LF and ends with a CR. In between, each line contains a label, may contain a timestamp then the data and finally a CRC. A schematic is worth a thousand words:

TIC frames
TIC frame data structure

I created a specific “AppLinky” class to handle the received bytes. The bytes are received in the LPUART1 Interrupt Service Routine (ISR) and stored directly in a queue only after the STX has been detected. When the frame is finished (i.e. the ETX arrived) it’s processed in a thread.

In the processing thread, it waits for the frame to be fully received. Once it is, each line is processed to interpret the kind of data that is in it. The data is stored in a big array, depending on its label. Here are (most of) the available fields:

  •  Meter’s address
  • Consumed energy distributor index 1-4
  • Current apparent power
  • Data (TIC) version
  • Total injected energy
  • Current apparent power lines 1-3
  • Date and time
  •  Total reactive energy Q1 to Q4
  • Average voltage lines 1-3
  • Supplier’s calendar name
  • RMS current line 1-3
  • Status register
  • Current supplier’s price tag
  • RMS voltage line 1-3
  • Start/end of peak 1-3
  • Total consumed energy
  • Apparent reference power
  • Info messages
  • Consumed energy supplier index 1-10
  • Apparent cutting power
  • Delivery location code 
UART ISR
Flowchart of the UART ISR

Each data line is parsed and its data is stored in a specific object of indexed in the list of all available fields. I wrote a custom storage class to handle the different sizes of the received data fields.
It’s interesting to mention that each time a field is updated in the storage, an event is sent to notify the main thread and update the Matter cluster with the new value.

Linky Thread
Flowchart of the Linky thread

The Matter clusters update

However, if you’re using a standard or a custom Matter cluster, you have to set its attributes when the corresponding value changes. The Matter stack provides the setters for all these attributes so you just have to call them with the new values.

The “Electrical Measurement” cluster is not an official one yet, but it’s in the “drafts” and may be integrated in the specification in the future. It means that for now it’s not recognized by the standard smart-home hubs. In this cluster, I keep track of the current apparent power drawn, the RMS current and the RMS voltage.

In my “Enedis TIC” cluster, I keep all the fields sent by the Linky, except the date and time as my device is not supposed to be a real-time clock source.

That’s the only steps that have to be done on the device side. Once the device will be commissioned in a network, the other devices will have the possibility to subscribe to all the attributes changed it wants. But that’s for the next paragraph!

It’s also interesting to mention that when the power lines are not bypassed, the onboard OLED display is used to show the current power drawn through the electricity meter and the current RMS current.

The hub side

On this side, I could simply use an Apple HomePod/TV, Amazon Echo 4 or Nest Hub. Two things: that would be too simple for the maker I am, and also that I don’t have such. Second thing, I won a Raspberry Pi 5 from Elektor a few weeks ago.

RPI border router
Raspberry Pi 5 as border router and Matter commissioner


On this Raspberry, I’ve setup an “OpenThread Border Router” which uses a Thread dongle to extend the IP network over thread. It’s the reference implementation of the border-router concept I mentioned previously; it will handle the nodes connectivity. The installation is well-described in the wiki.

Now that the border-router is ready, I need a Matter fabric manager. I could use the official “CHIP tool” but it’s a command-line tool so it’s not very handy to use to retrieve real-time data. I found on GitHub (again) the “Python Matter Server” from HomeAssistant which can be the Matter fabric manager and can also interview and stream the nodes updates through Websockets.

My smart home ecosystem runs on OpenHab, which has no websockets native compatibility. To counter this problem, I wrote a small Python script that listens to the websocket from the server then stores the latest data and provides it through an HTTP API running with FLASK. This way, I can use the OpenHab HTTP binding to poll the API and retrieve the data to show the current and history data of my Linky in my interface.

Matter data flow
The Matter data flow
Openhab summary
Summary of the retrieved values
Graphs
Power consumption over time

As you can see on the screenshots, the Linky data goes up to my OpenHab instance. I displayed some basic information, which is now shown live or on graphs, over time. That will help me to follow my power consumption and figure out whether a device is still powered on when it’s not supposed to be.

Conclusion

To conclude, I reached my objective. My power consumption data is now available in real-time in my smarthome ecosystem, without need of a proprietary cloud or application.

Designing a circuit suiting my needs make it very qualitative, even if on the power supply-side it’s not ideal as a dev kit consumes much energy. Although, I’m convinced that a standalone MCU can run completely headless and powered by the electricity meter.

Exploring the Matter standard has been a very enriching experience, even if its youth makes it a bit hard to learn at the beginning. The lack of standardized clusters for my need, and data visualization tools forced me to adapt the data flow for my system, but anyway, it works!

I would like to thank Elektor and STMicroelectronics for this contest initiative.

Thanks to my fiancée for the proof-reading and tolerating my long evenings (and so short nights) in front of the computer.

I hope you, reader, have found this project interesting and/or useful!

References

  • GitHub repository of the project – https://github.com/BDeliers/stm32wb-matter-device-over-thread
  • My Website – https://www.bdeliers.com
  • An inspiring schematic – https://github.com/papsdroidfr/Linky/blob/main/_docs/schemaLinky.png 
  • Matter’s website – https://csa-iot.org/all-solutions/matter/
  • Thread’s Wikipedia page – https://en.wikipedia.org/wiki/Thread_(network_protocol)
  • Matter standard’s Wikipedia page – https://en.wikipedia.org/wiki/Matter_(standard)
  • Enedis TIC datasheet – https://www.enedis.fr/media/2035/download
  • Python-matter-server library – https://github.com/home-assistant-libs/python-matter-server
  • OpenThread border router – https://openthread.io/guides/border-router
  • Connectedhomeip repository – https://github.com/project-chip/connectedhomeip
  • STM32WB5MM-DK product page – https://www.st.com/en/evaluation-tools/stm32wb5mmdk.html 
  • STM32WB5MM-DK schematics – https://www.st.com/content/ccc/resource/technical/layouts_and_diagrams/schematic_pack/gr oup1/0a/d5/78/b6/d7/bd/45/de/mb1292_shematics/files/MB1292-WB5MMB01_Schematic.PDF/jcr:content/translations/en.MB1292-WB5MM-B01_Schematic.PDF
  • OpenHab – https://www.openhab.org/ 

Loading

Tags