ChirpStack & LoRaWAN: Self-Hosted Monitoring for a Bakery (Part 1)

We recently started a research project with a bakery in our neighborhood. The baker told us that his current solution sends several alerts to his inbox every day: temperature too high, battery too low, signal too weak, and so on. At some point, he set up a filter so he wouldn't have to deal with them anymore.

A monitoring system you've trained yourself to ignore is no longer a monitoring system.

Maybe it's possible to design the alerts so that every single one actually requires action. The first step: collect enough data from his production floor.

Over the past few years, we've worked with the industry's standard tools: The Things Stack and The Things Industries as the LoRaWAN Network Server, Datacake for dashboards. These are excellent products, and we recommend them in many contexts. But whenever we're responsible to the customer for the entire chain from sensor to alert, we've run into some trade-offs:

• Data sovereignty
• Per-device pricing
• Limited control over alert logic
• Vendor lock-in

At some point, we asked ourselves the more interesting question: What would it look like to run the entire stack ourselves?

The Stack: ChirpStack, InfluxDB, Grafana, and Node-RED

The system consists of four open-source components plus the hardware that communicates with them. Everything runs on a single virtual server, hosted in the EU.

ChirpStack is the LoRaWAN Network Server. It handles device activation, decrypts sensor payloads, manages gateways and tenants, and forwards the decoded data. MIT-licensed. The open-source equivalent of what The Things Stack offers, but self-hosted by default.

InfluxDB v2 stores the time-series sensor data. Temperatures, humidity readings, battery voltages — everything that comes in is stored here with a timestamp, indexed by device.

Grafana turns that database into dashboards. This is the layer the customer actually sees: current temperatures, daily trends, comparisons across devices. AGPLv3-licensed.

Node-RED sits between the data and the people. This is where the alerts will be configured later. It's also where customer-specific exports are generated — HACCP reports and CSV files for regulatory authorities, for example.

A few supporting components round out the picture: Mosquitto as the MQTT broker between ChirpStack and the other components, PostgreSQL as the database for ChirpStack, Nginx Proxy Manager for TLS certificates and public traffic routing, and Docker Compose to keep the whole setup reproducible from a single configuration file.

Every component is open source. No licensing fees, no per-device costs, no usage limits. The bill is essentially just the VPS rental, regardless of how many sensors are connected.

The infrastructure runs on a VPS in Helsinki, within the EU. For security reasons, only two things are reachable from the public internet: the web dashboard (port 443, TLS-terminated) and the LoRaWAN gateway uplink port (UDP 1700, which carries only encrypted LoRaWAN payloads). Everything else — the network server's admin interface, the database, the MQTT broker, and the Node-RED editor — is accessible exclusively via an authenticated SSH tunnel. There is no public attack surface for any of the administrative components.

Gateway: RAKwireless WisGate Edge Lite 2

For the gateway, we used the RAKwireless WisGate Edge Lite 2. Its strength lies in WisGate OS, a mature operating system based on OpenWrt that offers clean configuration options for both packet forwarder modes, straightforward network management, support for Ethernet and Wi-Fi backhaul, and a web UI tidy enough to hand off to a customer if needed. We deliberately chose not to use the gateway's built-in network server. Running the LoRaWAN Network Server on a dedicated VPS rather than on the gateway's small ARM CPU gives the system significantly more headroom and keeps each layer focused on what it does best. In our experience: once set up, the gateway runs reliably and stays out of the way. Exactly what you want from a gateway.

Sensors: Dragino LHT65N in Practice

As the LoRaWAN temperature sensor, we used the Dragino LHT65N — specifically the NE117 variant with an external TMP117 high-precision temperature probe. The LHT65N is one of the most widely deployed LoRaWAN temperature sensors on the market.

External probes are also available individually and can be added or swapped out at any time: Temperature probe E3 · NE117 TMP117 · E31F SHT31F

First Results from the Bakery

The entire stack was deployed on a Hetzner VPS in Helsinki. The three sensors and the gateway were registered in ChirpStack.

Within an hour of arriving at the bakery, the first temperature readings from the production floor appeared in the Grafana dashboard.

Three Dragino LHT65N units are distributed across the production area: two in refrigerators, one in a large freezer. A RAKwireless WisGate Edge Lite 2 is connected via Ethernet to the bakery's internet and forwards LoRaWAN packets to the server in Helsinki.

Each device has already developed a distinct character. The two refrigerators oscillate around 5°C with their own compressor cycles and humidity signatures. The freezer holds steady at around -20°C.

We deliberately haven't configured any alerts yet. We want to observe each device for several weeks first, measure its actual operating window, and then design alerts that only fire when something truly significant happens.

Part 2 of this series will analyze the data we've collected during the observation phase.

EXP-Tech is an authorized distributor of Dragino and a Gold VAR Partner of RAKWireless in Germany.