Was ist ChirpStack?

ChirpStack ist ein quelloffener LoRaWAN Network Server (LNS). Er bildet die Software-Schicht zwischen Ihren LoRaWAN-Gateways und Ihrer Anwendung: Er nimmt die Funkdaten der Sensoren entgegen, entschlüsselt sie, verwaltet Geräte und Gateways und stellt die Daten sauber strukturiert bereit, per MQTT, HTTP oder direkt an eine Datenbank.

Anders als die IoT-Dienste der großen Cloud-Anbieter gehört ChirpStack keinem Konzern. Es steht unter der MIT-Lizenz, wird maßgeblich von Orne Brocaar entwickelt (früher unter dem Namen LoRa Server bekannt, 2019 in ChirpStack umbenannt), läuft auf Ihrer eigenen Infrastruktur und bindet Sie an keinen Hersteller, weder bei der Hardware noch beim Betrieb. Das ist der entscheidende Unterschied zu proprietären Plattformen, deren Anbieter Preise ändern oder den Dienst einstellen können. Das Projekt ist dabei kein Neuling: Es ist seit 2016 in der Praxis erprobt (damals noch als LoRa Server) und wird von Tausenden Nutzern weltweit eingesetzt.

Wo ChirpStack im LoRaWAN-Stack sitzt

Ein LoRaWAN-System besteht aus vier Schichten:

1. End-Geräte sind die Sensoren, die per Funk senden (Temperatur, Füllstand, Tür-Status und vieles mehr).
2. Gateways empfangen die Funksignale und leiten sie per IP-Netz weiter. Ein Gateway ist ein reiner Vermittler, keine Intelligenz.
3. Der Network Server ist ChirpStack. Hier passiert die eigentliche Arbeit: Geräte-Authentifizierung, Entschlüsselung, Deduplizierung mehrfach empfangener Pakete, Routing und Geräteverwaltung.
4. Die Anwendung ist Ihr Dashboard, Ihre Datenbank oder Ihre Plattform, die die fertig aufbereiteten Daten bekommt.

ChirpStack ist Schicht 3, das Gehirn zwischen Funk und Anwendung. Ohne Network Server sind die Daten Ihrer Gateways nutzlos: verschlüsselte Bytes ohne Zuordnung.

Die Komponenten von ChirpStack v4

Mit Version 4 hat ChirpStack einen großen Schritt zur Vereinfachung gemacht. Wo in Version 3 noch mehrere getrennte Dienste betrieben werden mussten (ein eigener Network Server und ein separater Application Server), führt v4 diese in eine einzige Anwendung zusammen, neu geschrieben in Rust statt Go. Das reduziert den Installations- und Wartungsaufwand erheblich, und Multi-Region-Betrieb ist jetzt direkt eingebaut, statt pro Region einen eigenen Server zu brauchen.

Ein vollständiges ChirpStack-v4-Setup besteht aus wenigen Bausteinen:

• ChirpStack ist der vereinte Server inklusive Weboberfläche und gRPC-/REST-API. Das Herzstück.
• ChirpStack Gateway Bridge übersetzt zwischen dem Protokoll des Gateways und MQTT. Sie ist eine eigene Komponente und kann auf dem Server oder direkt auf dem Gateway laufen.
• PostgreSQL ist die Datenbank für Geräte, Anwendungen und Konfiguration. Für kleine oder Edge-Setups unterstützt ChirpStack v4 alternativ SQLite.
• Redis hält Sitzungs- und Gerätezustände schnell verfügbar.
• MQTT-Broker, meist Mosquitto, ist der zentrale Nachrichtenbus für den Datenaustausch.

Diese überschaubare Architektur ist einer der Gründe, warum ChirpStack zuverlässig läuft, von der einzelnen virtuellen Maschine bis hin zu ressourcenschwacher Edge-Hardware. Organisatorisch ordnet v4 alles unter dem Konzept des Tenants: Geräte gehören zu Anwendungen, Anwendungen zu einem Mandanten, was sauberes Multi-Tenant-Setup ermöglicht.

Was der Network Server konkret leistet

Über die reine Datenweiterleitung hinaus übernimmt ChirpStack die Aufgaben, die LoRaWAN erst praxistauglich machen:

• Deduplizierung: Empfangen mehrere Gateways dasselbe Paket, wird es nur einmal verarbeitet.
• Adaptive Data Rate (ADR): Bei aktiviertem ADR sorgt ChirpStack dafür, dass jedes Gerät mit der effizientesten Datenrate und Sendeleistung arbeitet. Das spart Batterie und entlastet das Funkspektrum.
• Geräteklassen A, B und C: Alle drei LoRaWAN-Klassen werden unterstützt, von der batteriesparenden Klasse A bis zur latenzarmen Klasse C (mehr dazu in unserem Beitrag zu den LoRaWAN-Geräteklassen A, B und C).
• Live Frame-Logging: ChirpStack zeigt pro Gateway und Gerät jedes Paket in Echtzeit an, mit allen RX-/TX-Metadaten und dem rohen LoRaWAN-PHYPayload in lesbarer Form. Faktisch ein Wireshark für LoRaWAN und unverzichtbar beim Debuggen.
• LoRaWAN 1.0 und 1.1: Beide MAC-Versionen werden gleichzeitig unterstützt, samt aller regionalen Frequenzbänder und Parameter-Spezifikationen.
• gRPC- und REST-API: Alles, was die Weboberfläche kann, ist auch per API steuerbar. Dazu kommen fertige Integrationen zu Cloud-Anbietern, Datenbanken und Visualisierungs-Plattformen. Das ist die Basis für Automatisierung und Anbindung an bestehende Systeme.

Diese Aufgaben sind der Grund, warum ein LoRaWAN-Netz überhaupt einen Network Server braucht: Erst sie machen aus empfangenen Funkpaketen ein verlässliches, betreibbares System.

ChirpStack vs. The Things Network vs. kommerzielle Server

LoRaWAN-Daten brauchen einen Network Server. Es gibt drei grundsätzliche Wege:

Ehrlich gesagt: Für ein schnelles Hobby-Projekt oder einen ersten Test ist TTN völlig ausreichend und in Minuten startklar. Sobald es aber produktiv wird, mit echten Kunden, Datenschutzanforderungen oder dem Wunsch nach Unabhängigkeit, führt für viele kein Weg an einem eigenen Network Server vorbei. ChirpStack ist hier der etablierte Open-Source-Standard.

Wann sich ChirpStack lohnt

ChirpStack ist die richtige Wahl, wenn Sie:

• Datenhoheit brauchen, etwa aus DSGVO-Gründen oder weil die Daten das Unternehmen nicht verlassen dürfen,
• unabhängig von Gateway-Herstellern bleiben wollen und Geräte verschiedener Anbieter mischen,
• mehrere Standorte oder Regionen zentral verwalten,
• keine laufenden Lizenzkosten pro Gerät zahlen möchten,
• oder die volle Kontrolle über Konfiguration, Integration und Betrieb behalten wollen.

Für wenige Sensoren in einem unkritischen Projekt reicht oft TTN. Ab dem produktiven Einsatz wird der eigene Network Server zur sinnvollen Grundlage, und ChirpStack ist dafür die ausgereifteste quelloffene Option.

Im nächsten Schritt zeigen wir, wie Sie ChirpStack v4 sauber einrichten, vom ersten Paket bis zum ersten Sensor, der Daten liefert.