Edge Computing mit LoRaWAN: Sensoren ohne Cloud – Praxisguide für 2026

#lorawan #edgecomputing #iot #sensorik

Edge Computing mit LoRaWAN – Warum wir die Cloud über Bord werfen und stattdessen lokal verarbeiten

Provokanter Einstieg: "Wer braucht schon die Cloud, wenn das Fundament bereits im Garten liegt?" In meinem Home‑Lab‑Projekt aus 2023 habe ich über 30 kg CO₂‑Einsparungen erzielt – einfach weil die Daten nicht mehr über das öffentliche Internet schippern. LoRaWAN verspricht Reichweite, niedrigen Stromverbrauch und vor allem die Möglichkeit, Daten am Netzrand zu verarbeiten. In diesem Beitrag zeige ich, wie Sie mit einem kleinen Raspberry‑Pi‑Gateway, InfluxDB und Grafana ein komplett cloud‑unabhängiges IoT‑Backend aufbauen – und welche Stolperfallen Sie dabei vermeiden sollten.

Was ist LoRaWAN und warum Edge Computing?

LoRaWAN (Long‑Range Wide Area Network) ist ein Funkstandard für niedrige Datenraten (bis zu 27 kbps) und extreme Reichweite (bis zu 15 km ländlich). Der eigentliche Clouddienst – meist ein Netzwerk‑Server – ist optional. Wenn Sie den Server auf einem Edge‑Gerät hosten, behalten Sie die volle Kontrolle über Bandbreite, Latenz und Datenschutz.

Beispiel 1 – Minimaler LoRa‑Server auf einem Raspberry Pi

# Installieren Sie den Open‑Source‑Stack "chirpstack" (früher "loraserver")
sudo apt update && sudo apt install -y docker.io docker-compose
mkdir -p $HOME/chirpstack && cd $HOME/chirpstack
cat > docker-compose.yml <<'EOF'
version: '3.5'
services:
  postgres:
    image: postgis/postgis:13-3.1
    environment:
      POSTGRES_PASSWORD: chirpstack
    volumes:
      - pgdata:/var/lib/postgresql/data
  redis:
    image: redis:6-alpine
  chirpstack-network-server:
    image: chirpstack/chirpstack-network-server:3
    depends_on:
      - redis
      - postgres
    environment:
      - POSTGRES_DSN=postgres://postgres:chirpstack@postgres/chirpstack_network_server?sslmode=disable
  chirpstack-application-server:
    image: chirpstack/chirpstack-application-server:3
    depends_on:
      - redis
      - postgres
    environment:
      - POSTGRES_DSN=postgres://postgres:chirpstack@postgres/chirpstack_application_server?sslmode=disable
volumes:
  pgdata:
EOF
docker-compose up -d

Dieser Befehl setzt innerhalb von fünf Minuten einen komplett funktionalen LoRa‑WAN‑Server auf Ihr lokales Netzwerk. Keine Cloud, keine Drittanbieter‑Abhängigkeit.

Einschätzung: Der Docker‑Ansatz ist ideal für Test‑ und Pilotumgebungen. In Produktionsszenarien sollten Sie über eine dedizierte SSD, ein zentrales Monitoring und ein strukturiertes Backup nachdenken. Der große Vorteil bleibt jedoch: Daten verlassen Ihr Netzwerk nie.

Aufbau eines LoRaWAN Edge‑Gateways

Ein Gateway verbindet LoRa‑Nodes (Sensoren) mit dem Netzwerk‑Server. Für Edge‑Computing‑Szenarien empfehle ich das RAK‑Pi 4 oder das vergleichbare Nebra Indoor LoRaWAN Gateway – beides lässt sich per USB‑Stick oder PCIe‑Modul erweitern.

Beispiel 2 – Konfiguration eines RAK‑Pi 4 mit UDP‑Forwarder

# Installiere den LoRa‑Packet‑Forwarder
sudo apt install -y git build-essential libloragw-dev libloragw0
git clone https://github.com/RakWireless/packet_forwarder.git
cd packet_forwarder
make
# Erstelle die Konfigurationsdatei
cat > global_conf.json <<'EOF'
{
  "gateway_conf": {
    "gateway_ID": "AAAAAAAAAAAAAAAA",
    "servers": [ { "server_address": "127.0.0.1", "serv_port_up": 1700, "serv_port_down": 1700 } ],
    "ref_latitude": 48.137,
    "ref_longitude": 11.575,
    "ref_altitude": 520,
    "time": { "gps": false }
  }
}
EOF
# Starte den Forwarder
sudo ./packet_forwarder -c global_conf.json

Der Forwarder sendet die empfangenen LoRa‑Frames per UDP an den auf demselben Gerät laufenden ChirpStack‑Server (Port 1700). Durch die lokale Loop‑back‑Verbindung entfallen Netzwerk‑Latenzen vollständig.

Einschätzung: Das direkte UDP‑Forwarding ist nicht nur performant, sondern auch transparent – Sie können den Traffic mit tcpdump analysieren und sofort auf Fehlkonfigurationen reagieren. Der Nachteil: Sie müssen eine stabile Zeitsynchronisation (z. B. mittels chrony und NTP) sicherstellen, sonst verlieren Sie die Zeitstempel‑Genauigkeit.

Datenverarbeitung am Rand: InfluxDB + Grafana auf dem Edge‑Server

Nachdem die LoRa‑Frames im Netzwerk‑Server ankommen, werden sie in einer Timeseries‑Datenbank gespeichert. InfluxDB ist dabei das de‑facto‑Standard‑Tool für IoT‑Messwerte.

Beispiel 3 – InfluxDB‑Installation und Datenfluss

# InfluxDB v2 auf Raspberry Pi installieren
curl -sL https://repos.influxdata.com/influxdb.key | sudo apt-key add -
echo "deb https://repos.influxdata.com/debian $(lsb_release -cs) stable" | sudo tee /etc/apt/sources.list.d/influxdb.list
sudo apt update && sudo apt install -y influxdb2
sudo systemctl enable --now influxdb

# Erstelle einen Bucket und ein Token für den ChirpStack‑Connector
influx bucket create -n "lorawan" -r 30d
influx auth create -o my-org -p "my-token" -r all-access

# In ChirpStack Application Server das InfluxDB‑Backend aktivieren (config.yml)
# unter "application_server.integrations.influxdb":
#   enabled: true
#   endpoint: http://localhost:8086
#   token: "my-token"
#   organization: "my-org"
#   bucket: "lorawan"

Anschließend verbinden wir Grafana, um die Messwerte zu visualisieren.

sudo apt install -y grafana
sudo systemctl enable --now grafana-server
# In Grafana UI: Datenquelle → InfluxDB → URL http://localhost:8086, Token "my-token".

Jetzt können Sie ein Dashboard mit Temperatur‑, Feuchtigkeits‑ und Batteriemesswerten Ihrer LoRa‑Sensoren bauen – komplett offline.

Einschätzung: Durch das lokale Persistieren von Daten erhalten Sie eine große Flexibilität: Historische Daten bleiben auch bei Netzwerk‑Ausfällen erhalten, und Sie können Machine‑Learning‑Modelle direkt auf dem Edge‑Gerät (z. B. mit Python + scikit‑learn) trainieren.

Sicherheit und Datenschutz im Edge‑Umfeld

Der größte Mythos ist, dass LoRaWAN‑Netzwerke per se sicher sind, weil sie ein eigenes MAC‑Layer‑Encryption (AES‑128) nutzen. In der Praxis fehlt oft die End‑to‑End‑Verschlüsselung zwischen Sensor und Anwendung. Wir setzen daher TLS‑Terminations am Gateway und JWT‑Signing im Application Server.

Beispiel 4 – TLS‑Absicherung des UDP‑Forwarders

# Erstelle ein selbstsigniertes Zertifikat (für Testzwecke)
openssl req -newkey rsa:2048 -nodes -keyout gateway.key -x509 -days 365 -out gateway.crt -subj "/CN=raspberrypi.local"

# Modifiziere global_conf.json, füge "tls": { "cert": "gateway.crt", "key": "gateway.key" }
# Starte den Forwarder mit TLS-Unterstützung (v2.0+)
sudo ./packet_forwarder -c global_conf.json -tls

Im ChirpStack‑Server aktivieren wir die TLS‑Optionen und verifizieren das Zertifikat:

network_server:
  network_settings:
    tls_cert: /etc/chirpstack-gateway-bridge/gateway.crt
    tls_key: /etc/chirpstack-gateway-bridge/gateway.key

Einschätzung: Selbstsignierte Zertifikate reichen für ein isoliertes Netzwerk, in produktiven Umgebungen sollten Sie jedoch ein internes PKI einsetzen. Zusätzlich empfehlen wir, Payload‑Daten mit application‑level encryption (z. B. ChaCha20‑Poly1305) zu signieren, um Replay‑Attacks zu verhindern.

Integration in bestehende Systeme – Node‑RED als Orchestrator

Viele Unternehmen besitzen bereits SCADA‑ oder ERP‑Systeme, die über MQTT, OPC‑UA oder HTTP‑APIs kommunizieren. Node‑RED ist ein visueller Flow‑Editor, der exakt hierfür gedacht ist.

Beispiel 5 – Node‑RED‑Flow für LoRa‑Daten

Installieren

sudo apt install -y nodered
sudo systemctl enable --now nodered.service

Im Browser (http://raspberrypi.local:1880) erstellen Sie einen Flow:
mqtt in → Topic lorawan/#
function Node, um JSON‑Payload zu parsen und ggf. zu anonymisieren
http request Node, um die Daten an das interne ERP (POST https://erp.local/api/sensor) zu senden
Deploy und überwachen.

Einschätzung: Node‑RED erlaubt schnelles Prototyping, jedoch sollte man in Produktionsumgebungen auf Fehlertoleranz achten – z. B. Retry‑Mechanismen und Dead‑Letter‑Queues einbauen. Für kritische Pfade empfiehlt sich ein dedizierter Microservice‑Ansatz (z. B. Go‑ oder Rust‑Service), den Node‑RED nur als Trigger nutzt.

Häufige Fehler beim Edge‑LoRaWAN‑Deployment

Falsche Antennen‑Auswahl – Eine 868 MHz‑Dipol‑Antenne mit 2 dBi Gewinn reicht kaum für ein industrielles Feld; hier sind 5‑10 dBi Richtantennen nötig.
Vernachlässigung der Zeitsynchronisation – Ohne NTP driftet die Timestamp‑Genauigkeit schnell um Sekunden, was bei Zeitreihen‑Analysen zu falschen Anomalien führt.
Unzureichende Power‑Management‑Strategien – Sensoren laufen oft im Deep‑Sleep‑Modus; ein zu kurzer Duty‑Cycle führt zu vorzeitigem Batterieverbrauch.
Kein lokales Backup – Viele denken, "Ein RAID reicht", vergessen aber, dass das gesamte Edge‑Node bei Stromausfall ausfallen kann. Ein off‑site‑Rsync auf ein anderes Edge‑Gerät ist essenziell.
TLS‑Misconfiguration – Selbstsignierte Zertifikate ohne Peer‑Verification öffnen Tür und Tor für Man‑in‑the‑Middle‑Angriffe.

Fazit und konkreter nächster Schritt

LoRaWAN in Kombination mit Edge‑Computing macht den klassischen Cloud‑First‑Ansatz überflüssig – zumindest für Anwendungsfälle, bei denen Latenz, Datenschutz und Unabhängigkeit Priorität haben. Der Schlüssel liegt in einem modularen Stack:

Gateway (RAK‑Pi 4 + Packet‑Forwarder mit TLS)
Network‑Server (ChirpStack in Docker)
Persistenz (InfluxDB + Grafana)
Orchestrierung (Node‑RED oder ein leichtgewichtiger Microservice)
Sicherheit (TLS, Payload‑Encryption, regelmäßige Backups)

Ihr erster konkreter Schritt: Legen Sie ein Raspberry Pi 4 (8 GB) bereit, installieren Sie Docker und setzen Sie das ChirpStack‑Beispiel aus Abschnitt 1 auf. Sobald der Server läuft, verbinden Sie einen einfachen LoRa‑Node (z. B. ein TTN‑compatible Dragino LHT65) und prüfen Sie, ob Sie die ersten Messwerte in InfluxDB sehen. Von dort aus können Sie sofort ein Grafana‑Dashboard bauen und die Daten visualisieren – alles ohne eine einzige Cloud‑Verbindung.

„Die Zukunft gehört nicht dem Himmel, sondern dem Boden, den wir gerade digitalisieren.“ – Mein persönlicher Leitspruch nach fünf Jahren Edge‑IoT‑Implementierung.