LoRaWAN ohne Cloud: Sensordaten lokal mit Edge Computing auswerten

»Warum zur Hölle schicken wir Temperaturdaten erst um die halbe Welt, wenn der Auswerterechner 3 Meter neben dem Gateway steht?« – diese Frage hat mein gesamtes IoT-Architekturdenken auf den Kopf gestellt. Hier zeigen wir konkrete Lösungen jenseits von Cloud-Dashboards.

Der unterschätzte Rechenbedarf am Edge

LoRaWAN wirbt mit »Low Power« – aber vergisst zu erwähnen, dass die ganze Rechenarbeit einfach an Cloud-Dienste wie The Things Network (TTN) ausgelagert wird. Dabei fallen selbst bei einfachen Anwendungen überraschend rechenintensive Tasks an:

1. Payload-Decoding: Die Nutzdaten kommen oft als Hex-Strings oder Base64-codiert aus dem Gateway
2. Join-Server-Kommunikation: OTAA-Devices brauchen regelmäßigen Crypto-Austausch
3. Time Synchronization: LoRaWAN-Class-B benötigt präzise Zeitsynchronisation

Meine Erfahrung: Ein Raspberry Pi 4 schafft problemlos die Decodierung für 50+ Nodes – wenn man die Datenströme intelligent verteilt.

Praxisbeispiel: Lokaler TTN-Standalone-Server

# TTN Community Edition als Docker-Stack
version: '3.7'
services:
  ttn:
    image: thethingsnetwork/lorawan-stack:3.15
    command: ttn-lw-stack start
    environment:
      - TTN_LW_IS_DATABASE_URI=postgresql://ttn:ttn@db:5432/ttn
      - TTN_LW_REDIS_ADDRESS=redis:6379
    depends_on:
      - db
      - redis

Mit dieser Konfiguration laufen alle Joins und Datenverarbeitungen lokal. Die Verbindung zu öffentlichen Join-Servern kann über Firewall-Regeln blockiert werden – Ihr Netz, eure Regeln.

Kostenvorteil: Keine MQTT-Bandbreitenkosten bei Cloud-Anbietern, keine plötzlichen API-Limits.

Datenpipeline mit ChirpStack + InfluxDB

Für die Praxis empfiehlt sich folgender Stack:

1. ChirpStack als Network Server (Alternative zu TTN)
2. Mosquitto MQTT Broker für Device-Communication
3. Telegraf als Datenkollektor mit diesem Input-Plugin:

[[inputs.mqtt_consumer]]
  servers = ["tcp://localhost:1883"]
  topics = ["gateway/+/event/#"]
  data_format = "json"

1. InfluxDB für Time-Series Storage:

// Auswertung von Bodensensoren im 1h-Intervall
SELECT mean("moisture") FROM "soil" WHERE time > now() - 1h GROUP BY "device_id"

Performance-Tipp: Eine einzelne InfluxDB-Instanz auf einem NUC schafft 10.000+ Samples/sec – mehr als genug für typische Sensorsysteme.

Lokales Device Management mit Node-RED

Statt teurer Cloud-IoT-Plattformen lässt sich die gesamte Device-Logik in Node-RED abbilden:

// Automatische Alarmierung bei Feuchtigkeitsabfall
[{"id":"d1","type":"lorawan-decoder","device":"field-sensor-1"},
 {"id":"n1","type":"range","min":"30","max":"100"},
 {"id":"a1","type":"telegram","chatId":"12345","text":"⚠️ Feld 1 zu trocken: {{payload}}"}]

Vorteil: Volle Kontrolle über Alerting-Logik ohne externe API-Abhängigkeiten.

Typische Fallstricke in Eigenregie

1. Time Sync Probleme: Ohne NTP läuft Class-B in die Hose
   → Lokaler NTP-Server mit GPS-Referenz empfohlen

2. Join-Server Ausfallsicherheit: Bei OTAA wird jedes Device bei jedem Join internetabhängig
   → ABP als Fallback für kritische Devices konfigurieren

3. Gateway-Kapazitäten: Jedes Gateway kann max. 6-8 gleichzeitige Datenströme verarbeiten
   → Spread-Faktor (SF7-SF12) bewusst wählen

Fazit: Edge ist machbar – mit klarer Architektur

Nach 12 Monaten Betrieb unseres Cloud-unabhängigen LoRaWAN-Stacks zeigt sich: Die eigentliche Herausforderung ist nicht die Rechenleistung, sondern die konsistente Datenflussarchitektur. Mein Rat:

👉 Konkreter nächster Schritt: Bauen Sie mit ChirpStack + InfluxDB einen minimalen Teststack auf – schon 3-5 Sensoren offenbaren die wahren Architekturfragen.

Die glorreichen Zeiten, wo man jedes Thermometer an die Cloud angebunden hat, sind vorbei. Und das ist gut so.