LoRaWAN ohne Cloud: Sensordaten lokal mit Edge Computing auswerten

"LoRaWAN without Cloud: Evaluating Sensory Data Locally with Edge Computing" challenges traditional assumptions about IoT architecture. The author questions the need to transmit temperature data halfway across the globe when a gateway is only three meters away. This highlights the underestimated computational requirements at the edge in LoRaWAN systems.

Many people mistakenly believe these tasks are offloaded to cloud services like The Things Network (TTN), but even simple applications require surprising computational power.

The author found a single Raspberry Pi 4 could decode data for over 50 nodes without issue, provided data streams are intelligently distributed. A practical example is a local TTN Standalone Server, running on a Docker stack that includes TTN Community Edition, PostgreSQL, and Redis. This setup performs all joins and data processing locally, with the option to block connections to public Join Servers via firewall rules.

Cost advantages include eliminating MQTT bandwidth fees and avoiding abrupt API limits. The recommended pipeline involves ChirpStack as a Network Server, Mosquitto MQTT Broker for device communication, Telegraf as a data collector using MQTT, and InfluxDB for Time-Series Storage. Performance testing shows a single InfluxDB instance on a NUC can handle over 10,000 samples per second, more than sufficient for most sensor systems.

For local device management, Node-RED is recommended instead of expensive cloud IoT platforms. An example alerting setup includes decoding moisture levels, checking ranges, and sending Telegram notifications when soil becomes too dry. This approach provides full control over alerting logic without external API dependencies.

Common pitfalls in implementing these solutions include time synchronization problems with Class-B LoRaWAN, which require a local NTP server with GPS reference. Join Server failures can be mitigated by configuring OTAA devices with ABP for critical applications. Gateway capacity should be managed carefully, with proper spread factor (SF7-SF12) selection.

The author concludes that edge computing in LoRaWAN is viable with a well-defined architecture. After a year of operating a cloud-independent LoRaWAN stack, the main challenge turns out to be consistent data flow architecture, not computational power. The recommendation is to start with a minimal test stack using ChirpStack and InfluxDB to uncover true architectural issues. The era of connecting every thermometer to the cloud is over, and this change is beneficial.