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:
- Payload-Decoding: Die Nutzdaten kommen oft als Hex-Strings oder Base64-codiert aus dem Gateway
- Join-Server-Kommunikation: OTAA-Devices brauchen regelmäßigen Crypto-Austausch
- 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:
- ChirpStack als Network Server (Alternative zu TTN)
- Mosquitto MQTT Broker für Device-Communication
- Telegraf als Datenkollektor mit diesem Input-Plugin:
[[inputs.mqtt_consumer]]
servers = ["tcp://localhost:1883"]
topics = ["gateway/+/event/#"]
data_format = "json"
- 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
Time Sync Probleme: Ohne NTP läuft Class-B in die Hose
→ Lokaler NTP-Server mit GPS-Referenz empfohlenJoin-Server Ausfallsicherheit: Bei OTAA wird jedes Device bei jedem Join internetabhängig
→ ABP als Fallback für kritische Devices konfigurierenGateway-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.
Top comments (0)