Hook – Warum das Wetter‑IoT nicht mehr in der Cloud wohnen darf

Stellen Sie sich vor, Sie betreiben ein Weingut in der Pfalz. Ihre Sensoren messen Bodenfeuchte, Temperatur und Blattklinik‑Druck – rund um die Uhr. Dann platzt plötzlich die Internetverbindung, das Weingut liegt im Nebel, und Sie haben keinen einzigen Wert mehr. Das ist kein Katastrophen‑Szenario, das ist die Realität in vielen ländlichen Betrieben. Edge Computing mit LoRaWAN ist die Antwort: Daten werden dort erfasst, wo sie entstehen, und bleiben lokal – nur das Wesentliche wird nach außen geschoben.

In diesem Artikel zeige ich Ihnen Schritt für Schritt, wie Sie ein komplett cloud‑freies LoRaWAN‑Edge‑Setup aufbauen. Ich verwende ausschließlich Open‑Source‑Tools, gebe drei echte Befehls‑Beispiele und bewerte jedes Modul kritisch. Am Ende stehen Sie mit einem funktionierenden System, das ohne teure Cloud‑Abonnements auskommt.

Was ist Edge Computing mit LoRaWAN?

Erklärung: Edge Computing bedeutet, dass die Datenverarbeitung so nah wie möglich an der Quelle stattfindet. Statt jeden Messwert in die Cloud zu schicken, bauen wir eine Mini‑Cloud im eigenen Netzwerk. LoRaWAN (Long Range Wide Area Network) liefert die Funk‑Schicht, die für kilometerweite, energieeffiziente Übertragungen optimiert ist – perfekt für Batteriebetriebene Sensoren.

Beispiel: Ein Feld‑Sensor (z. B. ein Arduino‑Board mit einem DHT22) sendet alle 15 Minuten einen Paket‑Payload von 12 Byte über LoRaWAN. Der lokale Gateway empfängt das Paket, dekodiert es und leitet den Messwert über MQTT an einen InfluxDB‑Server weiter. Dort werden die Daten sofort in einer Zeitreihendatenbank gespeichert – bereit für Grafana‑Dashboards, die Sie im Pausenraum anschauen können.

Einschätzung: Viele Unternehmen glauben, LoRaWAN sei ausschließlich für die Cloud gedacht. In Wahrheit ist das Protokoll völlig unabhängig von einem Cloud‑Provider. Die eigentliche Herausforderung liegt im Edge‑Orchestrator – die Logik, die die Daten lokal verarbeitet, filtert und speichert. Wenn Sie das richtig bauen, sparen Sie nicht nur Bandbreite, sondern erhalten auch volle Datenhoheit.

Hardware‑Setup: LoRaWAN‑Gateway und Sensoren

Erklärung

Ein funktionierendes LoRaWAN‑Netzwerk besteht aus mindestens einem Gateway (Empfänger) und einer oder mehreren Endgeräten (Sensoren). Für ein Hobby‑ bis Mittelstand‑Projekt reicht ein Raspberry Pi 4 kombiniert mit einem RAK2245‑LoRa‑Hat. Der Gateway‑Software‑Stack ist ChirpStack – ein komplett Open‑Source‑Server, der sowohl den Netzwerk‑Server (LoRaWAN‑Server) als auch den Application‑Server (JSON‑API) bereitstellt.

Beispiel 1 – Gateway‑Installation

# 1. Raspberry Pi OS aktualisieren
sudo apt update && sudo apt full-upgrade -y

# 2. git holen und ChirpStack klonen
git clone https://github.com/chirpstack/chirpstack-gateway-bridge.git
cd chirpstack-gateway-bridge

# 3. Go‑Toolchain installieren (ChirpStack ist in Go geschrieben)
sudo apt install -y golang

# 4. Builden und Service einrichten
make build
sudo cp chirpstack-gateway-bridge /usr/local/bin/
sudo cp systemd/chirpstack-gateway-bridge.service /etc/systemd/system/
sudo systemctl daemon-reload
sudo systemctl enable chirpstack-gateway-bridge
sudo systemctl start chirpstack-gateway-bridge

Die Konfiguration liegt in /etc/chirpstack-gateway-bridge/chirpstack-gateway-bridge.toml. Ein Minimal‑Eintrag für das RAK2245 sieht so aus:

[network_server]
  server_address = "127.0.0.1:8000"

[gateway]
  semtech_udp.bind = "0.0.0.0:1700"
  # Wenn Sie das RAK2245 im SPI‑Mode laufen haben
  concentrator.type = "rak2245"
  concentrator.spi_bus = 0
  concentrator.spi_cs = 0

Hinweis: Der semtech_udp.bind‑Port 1700 ist der Standard‑Port, den LoRa‑Node‑Boards zur Verfügung stellen. Der Gateway‑Bridge übersetzt das Semtech‑UDP‑Protokoll in MQTT‑Nachrichten für den ChirpStack‑Network‑Server.

Beispiel 2 – Sensor‑Firmware (Arduino + Dragino Lora Shield)

#include <Arduino.h>
#include <SPI.h>
#include <LoRa.h>
#include <DHT.h>

#define DHTPIN 2
#define DHTTYPE DHT22
DHT dht(DHTPIN, DHTTYPE);

void setup() {
  Serial.begin(9600);
  while (!Serial);
  dht.begin();

  if (!LoRa.begin(868E6)) {
    Serial.println("LoRa init failed");
    while (true);
  }
  Serial.println("LoRa init ok");
}

void loop() {
  float h = dht.readHumidity();
  float t = dht.readTemperature();
  if (isnan(h) || isnan(t)) return;

  String payload = String(t,1) + "," + String(h,1);
  LoRa.beginPacket();
  LoRa.print(payload);
  LoRa.endPacket();
  Serial.println("Sent: " + payload);
  delay(900000); // 15 min
}

Der Sketch sendet temperature,humidity als CSV‑Payload. Auf dem Gateway‑Bridge wird das als MQTT‑Message application/1/device/12345/rx bereitgestellt.

Einschätzung

Der größte Stolperstein ist das Timing zwischen LoRa‑Modul und Gateway. Viele Hobby‑Entwickler setzen auf den Semtech‑UDP‑Relay, vergessen aber, dass das UDP‑Packet nicht verschlüsselt ist. Für Produktionsumgebungen sollten Sie LoRaWAN‑v1.1‑Security (App‑Key / Nwk‑Key) aktivieren – ChirpStack macht das per Simple‑JSON-Konfiguration. In Testumgebungen reicht das hier gezeigte Minimal‑Setup völlig aus, um das Datenfluss‑Skelett zu verstehen.

Lokale Datenpipeline: MQTT → InfluxDB → Grafana

Erklärung

Sobald das Gateway die Pakete empfängt, leiten wir sie über Mosquitto (lokaler MQTT‑Broker) an InfluxDB (Zeitreihen‑DB) weiter. Grafana visualisiert die Daten. Diese Kette ist komplett offline, kann aber bei Bedarf über ein VPN mit dem Unternehmensnetz verbunden werden.

Beispiel 3 – Mosquitto Installation & Konfiguration

sudo apt install -y mosquitto mosquitto-clients
# Öffentliche Zugriffe deaktivieren (nur localhost)
sudo bash -c 'cat > /etc/mosquitto/conf.d/local.conf <<EOF
listener 1883 127.0.0.1
allow_anonymous false
password_file /etc/mosquitto/passwd
EOF'
# Benutzer anlegen
sudo mosquitto_passwd -b /etc/mosquitto/passwd edgeuser edgepassword
sudo systemctl restart mosquitto

ChirpStack wird nun so konfiguriert, dass er die MQTT‑Messages an localhost:1883 pushen kann. In der application_server.toml setzen Sie:

[application_server.integration.mqtt]
  server = "tcp://127.0.0.1:1883"
  username = "edgeuser"
  password = "edgepassword"

Beispiel 4 – InfluxDB + Python‑Writer

# InfluxDB 2.x installieren (Debian‑Paket)
wget -qO- https://repos.influxdata.com/influxdb.key | sudo apt-key add -
source /etc/os-release
printf "deb https://repos.influxdata.com/${ID} ${VERSION_CODENAME} stable" | sudo tee /etc/apt/sources.list.d/influxdb.list
sudo apt update && sudo apt install -y influxdb2
sudo systemctl enable --now influxdb

Jetzt schreiben wir ein kurzes Python‑Script, das die MQTT‑Messages abonniert und direkt in InfluxDB speichert:

import paho.mqtt.client as mqtt
from influxdb_client import InfluxDBClient, Point, WritePrecision

INFLUX_URL = "http://localhost:8086"
TOKEN = "my-token"
ORG = "my-org"
BUCKET = "edge"

client = InfluxDBClient(url=INFLUX_URL, token=TOKEN, org=ORG)
write_api = client.write_api(write_options="batch")

def on_message(client, userdata, msg):
    payload = msg.payload.decode()
    temp, hum = map(float, payload.split(','))
    p = Point("sensor")\
        .tag("location", "field1")\
        .field("temperature", temp)\
        .field("humidity", hum)\
        .time(datetime.utcnow(), WritePrecision.S)
    write_api.write(bucket=BUCKET, record=p)
    print(f"Stored {payload}")

mqttc = mqtt.Client()
mqttc.username_pw_set("edgeuser", "edgepassword")
mqttc.on_message = on_message
mqttc.connect("127.0.0.1", 1883, 60)
mqttc.subscribe("application/1/device/+/rx")
mqttc.loop_forever()

Beispiel 5 – Grafana Dashboard

sudo apt install -y grafana
sudo systemctl enable --now grafana-server

In Grafana fügen Sie einen InfluxDB‑Data‑Source hinzu (URL http://localhost:8086, Token aus vorherigem Schritt) und erstellen ein Dashboard mit zwei Panels:

• Temperatur – Query: from(bucket:"edge") |> range(start: -1h) |> filter(fn: (r) => r._field == "temperature")
• Luftfeuchte – gleiche Query, Feld humidity.

Einschätzung

Die Kombination aus Mosquitto + InfluxDB + Grafana lässt sich innerhalb von 2 Stunden auf einem einzelnen Raspberry Pi aufsetzen. Die häufigsten Fehler sind:

1. ACL‑Fehler im MQTT‑Broker – vergessen, allow_anonymous false zu setzen, führt zu unverschlüsseltem Datenfluss.
2. Token‑Verfall in InfluxDB 2.x – wenn Sie das Token einmal generieren und vergessen, das Ablaufdatum zu prüfen, bricht das Python‑Writer‑Script nach 30 Tagen ab.
3. Timestamp‑Mismatches – InfluxDB erwartet UTC‑Zeit; das Python‑Script muss datetime.utcnow() verwenden, sonst erscheinen die Werte „in der Zukunft“ und werden verworfen.

Sicherheit & Firmware‑Management

Erklärung

Edge‑Umgebungen dürfen nicht die vergessene „keine Sicherheit“‑Mentalität tragen. LoRaWAN selbst bietet AES‑128‑End‑to‑End‑Verschlüsselung. Zusätzlich sollten Sie MQTT über TLS (Port 8883) betreiben und OTA‑Updates für Arduino‑Boards planen.

Beispiel 6 – TLS für Mosquitto

sudo apt install -y openssl
# Zertifikat + Schlüssel generieren (self‑signed)
openssl req -new -x509 -days 365 -nodes -out /etc/mosquitto/certs/server.crt -keyout /etc/mosquitto/certs/server.key

# mosquitto.conf erweitern
sudo bash -c 'cat >> /etc/mosquitto/conf.d/tls.conf <<EOF
listener 8883
cafile /etc/mosquitto/certs/server.crt
certfile /etc/mosquitto/certs/server.crt
keyfile /etc/mosquitto/certs/server.key
require_certificate false
allow_anonymous false
password_file /etc/mosquitto/passwd
EOF'

sudo systemctl restart mosquitto

Beispiel 7 – OTA‑Update über LoRaWAN (ChirpStack)

1. Im ChirpStack‑UI aktivieren Sie das Device‑Profile „Enable OTA”.
2. Laden Sie das neue Firmware‑Image (firmware.bin) in das OTA‑Storage (z. B. ein lokaler MinIO‑Bucket).
3. Triggern Sie ein Downlink‑Job via API:

curl -X POST https://localhost:8080/api/device/12345/queue -H "Authorization: Bearer $TOKEN" -d '{"payload":"$(base64 -w 0 firmware.bin)"}'

Das Gerät erhält das Downlink‑Package, schreibt den Flash neu und startet automatisch neu – ohne menschliches Eingreifen.

Einschätzung

TLS für MQTT ist heute ein Muss, nicht optional. Der Aufwand für ein selbst‑signiertes Zertifikat ist minimal, aber er verhindert die üblichen Man‑in‑the‑Middle‑Gefahren. OTA‑Updates über LoRaWAN sind überraschend zuverlässig, solange Sie den LoRaWAN‑Data‑Rate (DR) passend wählen (z. B. DR 5 für 125 kHz‑Band). Ein zu hoher DR führt zu Paketverlusten, weil das Downlink‑Fenster zu kurz ist.

Häufige Fehler und wie man sie vermeidet

Schnell‑Check‑Liste

1. sudo lora-packet-log – sehen, ob Pakete ankommen.
2. mosquitto_sub -t "#" -v – prüfen, ob MQTT‑Messages erscheinen.
3. influx query "from(bucket:\"edge\") |> range(start: -1h)" – Daten in InfluxDB?
4. Grafana‑Dashboard öffnen – aktuelle Werte?

Fazit – Ihr erster Edge‑LoRaWAN‑Prototyp in 48 Stunden

Sie haben nun:

1. Einen lokalen LoRaWAN‑Gateway (Raspberry Pi + RAK2245) mit ChirpStack installiert.
2. Ein Arduino‑Node programmiert, das Temperatur‑ und Feuchtigkeitsdaten per LoRa sendet.
3. Eine vollständig automatisierte Datenpipeline (MQTT → InfluxDB → Grafana) aufgebaut.
4. Sicherheit über TLS und LoRaWAN‑Verschlüsselung implementiert sowie OTA‑Updates ermöglicht.
5. Die häufigsten Stolpersteine identifiziert und mit konkreten Konfigurations‑Snippets behoben.

Nächster Schritt: Skalieren Sie das Setup auf mehrere Felder, setzen Sie Node‑Red als lokales Orchestrierungs‑Tool ein und binden Sie optional Prometheus für Metriken ein. So erhalten Sie ein robustes Edge‑IoT‑Ökosystem, das komplett ohne Cloud‑Abhängigkeiten auskommt – und das alles unter Ihrer vollen Datenhoheit.

Viel Spaß beim Basteln, und denken Sie immer daran: Edge bedeutet Kontrolle, nicht Kompromiss.