Wir haben gerade ein Forschungsprojekt mit einer Bäckerei in der Nachbarschaft begonnen. Der Bäckermeister erzählte uns, dass seine aktuelle Lösung täglich mehrere Alarme an sein Postfach schickt: Temperatur zu hoch, Akku zu schwach, Signal zu schwach, und so weiter. Irgendwann hat er einen Filter eingerichtet, damit er sich nicht mehr damit beschäftigen muss.
Ein Monitoring-System, das man sich antrainiert hat zu ignorieren, ist kein Monitoring-System mehr.
Vielleicht lässt sich der Alarm so gestalten, dass jeder Alarm auch tatsächlich Handlungsbedarf bedeutet. Der erste Schritt: genug Daten aus seiner Produktion sammeln.
In den letzten Jahren haben wir mit den Standardwerkzeugen der Branche gearbeitet: The Things Stack und The Things Industries als LoRaWAN Network Server, Datacake für Dashboards. Das sind ausgezeichnete Produkte, und wir empfehlen sie in vielen Kontexten. Aber sobald wir gegenüber dem Kunden für die gesamte Kette vom Sensor bis zum Alarm verantwortlich sind, sind wir auf einige Trade-offs gestoßen:
- Datensouveränität
- Pricing pro Gerät
- Eingeschränkte Kontrolle über die Alarmlogik
- Vendor-Lock-in
Irgendwann haben wir uns die interessantere Frage gestellt: Wie würde es aussehen, den gesamten Stack selbst zu betreiben?
Der Stack: ChirpStack, InfluxDB, Grafana und Node-RED
Das System besteht aus vier Open-Source-Komponenten plus der Hardware, die mit ihnen kommuniziert. Alles läuft auf einem einzigen virtuellen Server, gehostet in der EU.
ChirpStack ist der LoRaWAN Network Server. Er übernimmt die Geräteaktivierung, entschlüsselt die Sensor-Payloads, verwaltet Gateways und Mandanten und leitet die dekodierten Daten weiter. MIT-lizenziert. Das Open-Source-Äquivalent zu dem, was The Things Stack bietet, aber standardmäßig selbst gehostet.
InfluxDB v2 speichert die Zeitreihen-Sensordaten. Temperaturen, Luftfeuchtigkeit, Batteriespannungen, alles, was ankommt, wird hier zeitgestempelt und nach Gerät indiziert abgelegt.
Grafana macht aus dieser Datenbank Dashboards. Das ist die Ebene, die der Kunde tatsächlich sieht: aktuelle Temperaturen, Tagesverläufe, Vergleiche zwischen den Geräten. AGPLv3-lizenziert.
Node-RED sitzt zwischen den Daten und den Menschen. Hier werden die Alarme später konfiguriert. Hier entstehen auch die kundenspezifischen Exporte, etwa HACCP-Berichte und CSV-Dateien für Behörden.
Ein paar unterstützende Komponenten vervollständigen das Bild: Mosquitto als MQTT-Broker zwischen ChirpStack und den anderen Komponenten, PostgreSQL als Datenbank für ChirpStack, Nginx Proxy Manager für TLS-Zertifikate und das Routing des öffentlichen Datenverkehrs, und Docker Compose, um das Ganze aus einer einzigen Konfigurationsdatei reproduzierbar zu halten.
Jede Komponente ist Open Source. Keine Lizenzgebühren, keine Kosten pro Gerät, keine Nutzungslimits. Die Rechnung beschränkt sich im Wesentlichen auf die VPS-Miete, unabhängig davon, wie viele Sensoren angeschlossen sind.
Die Infrastruktur läuft auf einem VPS in Helsinki, innerhalb der EU. Aus Sicherheitsgründen sind nur zwei Dinge aus dem öffentlichen Internet erreichbar: Das Web-Dashboard (Port 443, TLS-terminiert) und der LoRaWAN-Gateway-Uplink-Port (UDP 1700, der nur verschlüsselte LoRaWAN-Payloads transportiert). Alles andere – das Admin-Interface des Network-Servers, die Datenbank, der MQTT-Broker und der Node-RED-Editor – ist ausschließlich über einen authentifizierten SSH-Tunnel erreichbar. Für die administrativen Komponenten gibt es keine öffentliche Angriffsfläche.
Gateway: RAKwireless WisGate Edge Lite 2
Als Gateway haben wir das RAKwireless WisGate Edge Lite 2 eingesetzt. Die Stärke liegt hier in WisGate OS, einem ausgereiften, auf OpenWrt basierenden Betriebssystem, das saubere Konfigurationsoptionen für beide Packet-Forwarder-Modi bietet, klares Netzwerkmanagement, Unterstützung für Ethernet- und WLAN-Backhaul, und ein Web-UI, das übersichtlich genug ist, um es bei Bedarf an den Kunden weiterzugeben. Den eingebauten Network-Server des Gateways haben wir bewusst nicht verwendet. Den LoRaWAN Network Server auf einem dedizierten VPS zu betreiben statt auf der kleinen ARM-CPU des Gateways verschafft dem System deutlich mehr Headroom und hält jede Schicht auf das fokussiert, was sie am besten kann. Aus unserer eigenen Erfahrung: einmal eingerichtet, läuft das Gateway stabil und unauffällig. Genau das, was man von einem Gateway erwartet.


|
Modell |
LTE |
Besonderheit |
Shop |
|
RAK7268V2 |
Nein |
Standardmodell |
|
|
RAK7268V2 9–24V DC |
Nein |
Flexibler Stromeingang |
|
|
RAK7268CV2 |
Ja |
Interne LTE-Antenne |
|
|
RAK7268CV2 |
Ja |
Externe LTE-Antenne |
|
|
RAK7268CV2 9–24V DC |
Ja |
LTE + flexibler Stromeingang |
Sensoren: Dragino LHT65N in der Praxis
Als LoRaWAN Temperatursensor haben wir den Dragino LHT65N eingesetzt, konkret die NE117-Variante mit externer TMP117-Hochpräzisions-Temperatursonde. Der LHT65N gehört zu den meistverbreiteten LoRaWAN Temperatursensoren am Markt.
|
Modell |
Besonderheit |
Shop |
|
LHT65N |
Interner Temperatur- & Feuchtesensor |
|
|
LHT65S |
Wie LHT65N, mit externer SMA-Antenne |
|
|
LHT65N-E3 |
Mit externem Temperatursensor |
|
|
LHT65N-NE117 |
Mit TMP117-Hochpräzisions-Temperatursensor |
|
|
LHT65N-E31F |
Mit Sensirion SHT31F (Temp. + Feuchte) |
|
|
LHT65S-NE117 |
LHT65S + TMP117 |
|
|
LHT65S-E3 |
LHT65S + externer Temperatursensor |
Die externen Fühler sind auch einzeln erhältlich und können nachträglich ergänzt oder ausgetauscht werden: Temperatursonde E3 · NE117 TMP117 · E31F SHT31F

Erste Ergebnisse aus der Bäckerei
Der gesamte Stack wurde auf einem Hetzner-VPS in Helsinki deployed. Die drei Sensoren und das eine Gateway wurden in ChirpStack registriert.
Innerhalb einer Stunde nach Ankunft in der Bäckerei erschienen die ersten Temperaturwerte aus der Produktion im Grafana-Dashboard.

Drei Dragino LHT65N sind in der Produktion verteilt: zwei in Kühlschränken, einer in einem großen Gefrierschrank. Ein RAKwireless WisGate Edge Lite 2 ist über Ethernet an das Internet der Bäckerei angeschlossen und leitet LoRaWAN-Pakete an den Server in Helsinki weiter.
Jedes Gerät hat bereits eine sichtbare Persönlichkeit entwickelt. Die beiden Kühlschränke pendeln um die 5°C mit eigenen Kompressor-Zyklen und Feuchtigkeitssignaturen. Der Gefrierschrank hält stabil rund -20°C.
Wir haben die Alarme bewusst noch nicht konfiguriert. Wir wollen jedes Gerät zuerst über mehrere Wochen beobachten, sein tatsächliches Betriebsfenster vermessen, und dann Alarme entwerfen, die nur dann auslösen, wenn wirklich etwas Bedeutsames passiert.
In Teil 2 dieser Serie werten wir die Daten aus, die wir während der Beobachtungsphase gesammelt haben.
EXP-Tech ist autorisierter Distributor von Dragino und Gold VAR Partner von RAKWireless in Deutschland.



