This blog post is part of a series of posts:

• Part 1 : Introduction
• Part 2 : From prototypes to V1.0
• Part 3 : Hardware design
• Part 4 : Software
• Part 5 : Integration with TTN, Node-RED and Home-Assistant

Introduction

My water consumption increased by a lot (+20%) in 2020-2021. Even if water isn’t the most expensive of my utility bills, I was still a bit concerned : maybe there’s leak in my water installation. This would be not good for my home and for the planet.

Most people I know would have simply checked their water meter regularly to see if the meter reading was rising overnight or while they were at work, for example.

But… I’m not one of these people, and I want to automate this manual operation. Plus, my water meter is installed in a small shed in the garden, away from the house, which makes this operation even more annoying.

Then, some of the people I know might have tried to find off-the-shelf components to do the job : it’s probably possible to find ‘something’ that plugs on the water meter and that sends the water consumption to some proprietary cloud service or even Home-Assistant.

But… my case is a bit more difficult : the shed where my water meter is installed is away from the house, which means my WiFi network doesn’t go that far and there’s no power available near that shed.

So yeah, yeah, I could have installed a WiFi extender and extended my electrical installation, but that’s not the goal : I’m a software engineer and I like to thinker with cheap MCU so… I’ll just build my own water meter that works in my use-cases.

What do I need, then ? It’s simple : I need a low power battery operated pulse counter (my water meter supports an add-on module that generates one pulse for each liter that flows through it) that does not rely on WiFi or wired communication to send the results.

This serie of articles is about this amazing (to me, at least) project I started 2 years ago which allowed me to learn about LoRa, the nRF52840 MCU and its low-power modes, electronics, PCB design and manufacturing,…

Oh! By the way… there was no leak in my water installation. The increased water usage was probably caused by the fact that my wife and myself were stuck at home for more than a year because of the pandemic!

General overview

As I said in the introduction, I want to be able to monitor my water usage. My water meter provides a pulse output : a pulse is generated each time a liter flowed trough the meter. To get this data into Home-Assistant (my home automation platform), I need something that sits in between the water meter and my Home-Assistant instance running on my local network.

This something will need to be able to do 3 things:

• Count the pulses on a GPIO
• Send them over a low power wireless communication
• Run on a battery, which means that it must use as little power as possible

To achieve this goal, I have to choose an MCU that will run the whole process, and a low power wireless communication protocol.

I decided to use the SeeedStudio XIAO NRF52840 MCU board. It’s cheap, it contains the bare minimum needed to run the MCU (which means that it’ll use less power than more crowded boards) and I’m already familiar with the NRF52 MCU family.

For the wireless communication protocol, I decided to use LoRaWAN since I’m really interested in this technology and I already own a few LoRa modules. For this project, I’ll use a LoRa module from Pine64 . I don’t think it’s available in the store right now, but it’s very similar to the well known RFM90 module.

LoRaWAN also needs a LoRaWAN gateway to connect the end device (this project) to the network. I already own the Pine64 LoRaWAN gateway , so I’ll use it for this project.

I’ll connect this gateway to The Things Network (TTN) . It’s a global collaborative LoRaWAN network. Anyone is free to use the network and to add their own gateway to extend its range.

And here is the high level view of the project:

• Pulses are generated by the watermeter
• They are counted by the MCU
• Results are sent over LoRaWAN via the LoRa module
• The LoRaWAN gateway forwards the data to The Things Network
• TTN processes the data and publishes them on a MQTT endpoint
• Home-Assistant receives the data from MQTT

In the next part of this series, I’ll give more details on the history of the project, how I went from prototype to V1.0 .