LoRaWAN at home

There is a moment in every homelab journey where you run out of obvious things to build. The servers are running. The network is segmented. The backups are automated. The certificates are signed by your own CA. The VPN connects all three sites. You look at what you have and think: this is genuinely good. And then you start wondering what comes next.

For me, what came next was LoRaWAN.

I have written elsewhere about LoRa as a radio technology and LoRaWAN as the network protocol that runs on top of it. The short version: LoRa is a long-range, low-power radio modulation technique. LoRaWAN turns it into a network for small IoT sensors to transmit data over distances measured in kilometres without draining a battery for years. It is the technology behind soil moisture sensors on farms, flood warning systems on rivers, GPS trackers on shipping containers, and air quality monitors in city centres.

And I want it in my house.

The question I keep asking myself

My homelab exists because I believe that understanding the infrastructure your life runs on matters. Not in an abstract philosophical sense, though I believe that too. In a practical sense: the services you depend on, the data you generate, the systems that keep things running. Understanding them means being able to fix them, improve them, and extend them in directions that actually matter to you rather than directions that matter to a product team in San Francisco.

LoRaWAN extends that philosophy into the physical world.

Right now, I know a great deal about what is happening on my network. Which services are running, which ports are open, which devices are connected. I know almost nothing about what is happening in my house. Is the boiler room getting damp? Is the temperature in the loft creating a risk for the equipment up there? Is the front door being opened while I am away? Is the soil in the back garden dry enough to need watering, or not?

These are questions that sensors could answer. Small, cheap, battery-powered sensors that transmit a reading every few minutes and run for years without intervention. The data they produce is not interesting on its own. It becomes interesting when it accumulates over time into a picture of how the house behaves across seasons, across weather events, across years.

That picture does not exist anywhere right now. I want to build it.

Why not just use WiFi sensors

This is the obvious question and it deserves a direct answer.

WiFi sensors exist. They are cheap and widely supported. The problem is that they are power-hungry, which means they need to be plugged in or have batteries replaced frequently, and they are dependent on the WiFi network being available and the sensor being in range. More importantly, most of them connect to a cloud service. The data goes to someone else’s server. The sensor stops working if the cloud service changes its terms or shuts down.

LoRaWAN sensors can run for years on a single battery. They transmit through walls and at distances that make WiFi look myopic. And on a private LoRaWAN network, the data goes to my server and nowhere else.

The trade-off is that you cannot stream video over LoRaWAN, you cannot send large amounts of data, and the network requires a gateway. For sensors that need to transmit a temperature reading every five minutes, none of those trade-offs matter.

What I actually want to monitor

I have been making a list. It is longer than I expected.

The house itself:

Temperature and humidity in every room, the boiler room, the loft, and the garage. Flood detection in the boiler room and under the kitchen sink. Door and window sensors for the external doors. Smoke and CO2 levels, as a supplement to the existing detectors rather than a replacement. Energy monitoring on the main circuits.

The garden:

Soil moisture at various depths. Rainfall. Temperature at soil level versus air temperature. These readings would feed into an eventual irrigation automation.

The three sites:

Each of the three locations in this network has its own character. Burnage is the primary homelab site. Fallowfield and The Lighthouse are smaller. Having environmental monitoring at all three sites via a shared LoRaWAN network that feeds into the same central dashboard is a project that appeals significantly.

Asset tracking:

A GPS tracker on the car. Possibly on bicycles. Small devices that report location via LoRaWAN when in range of a gateway and store readings for upload when they next connect.

The architecture I am building toward

A private LoRaWAN network has three layers, and I want to own all three.

The gateway is the radio infrastructure. A single LoRaWAN gateway can cover a surprisingly large area: several kilometres in open terrain, several hundred metres in a dense urban environment. One gateway at Burnage would cover the house and a significant portion of the surrounding area. Three gateways, one per site, would create overlapping coverage across a meaningful chunk of Greater Manchester.

The network server is ChirpStack, running on the February homelab server once it is built. ChirpStack is the open source LoRaWAN network server: it handles device authentication, deduplication of packets received by multiple gateways, and routing data to the application layer. It is exactly the kind of infrastructure that belongs in the homelab rather than in someone else’s cloud.

The application layer is where the data becomes useful. ChirpStack delivers sensor readings via MQTT to whatever application is listening. In this case: InfluxDB for time-series storage, Grafana for visualisation, Node-RED for automation and alerting, and Home Assistant for integration with the rest of the house.

The MQTT article I wrote covers the glue between these layers. LoRaWAN is the source of the data that flows through that glue.

The thing that makes this different from a commercial solution

I could buy a commercial sensor system. Several of them are good. The problem is that they are walled gardens. The sensors talk to the vendor’s cloud. The dashboard is the vendor’s dashboard. The automation is whatever the vendor has decided to support. When the vendor changes the pricing, updates the terms, or discontinues the product line, the system either changes or breaks.

A private LoRaWAN network with ChirpStack and Grafana and MQTT breaks when I break it and for no other reason. The sensors I buy are standard LoRaWAN devices that work with any compliant network server. The data is in my InfluxDB database, in a schema I chose, queryable with tools I understand. The dashboard shows what I decide it should show.

This is the same argument that drives the rest of the homelab. The difference is that LoRaWAN extends it outside the server rack and into the physical environment. Sensors in the walls, sensors in the garden, sensors on the roof. The house becomes instrumented in the same way the network is instrumented. Not because it needs to be, but because understanding things is interesting, and the data that accumulates over time becomes genuinely useful.

Where I am with it

Planning stage, honestly. The network design is clear. The server to run ChirpStack on is being built. The list of sensors I want to deploy is drafted. The gateway hardware is shortlisted.

What I do not yet have is a working gateway transmitting packets to a working ChirpStack instance. That is the next step, and when it happens I will write about it in enough detail that someone reading this could follow the same path without having to figure everything out from scratch.

That is the point of writing any of this down. Not to document what I have already built, but to create the documentation I wished existed while I was building it.