ThingsBoard und ChirpStack konkurrieren nicht miteinander, sie ergänzen sich. Das ist das häufigste Missverständnis bei der Planung einer LoRaWAN-Lösung. ChirpStack ist ein LoRaWAN Network Server: Es bringt die Funkdaten Ihrer Sensoren über die Gateways ins Netz und stellt sie als Nachrichten bereit. ThingsBoard ist eine IoT-Anwendungsplattform: Geräteverwaltung, Dashboards, Alarme, Regel-Engine, Mehrmandantenfähigkeit. Die beiden sitzen auf unterschiedlichen Schichten der IoT-Architektur. Die typische Kette lautet: ChirpStack -> MQTT -> ThingsBoard. Dieser Artikel erklärt den Unterschied, das Zusammenspiel und wann Sie nur eines von beiden brauchen.
Warum "ThingsBoard vs ChirpStack" die falsche Frage ist
Die Suche nach "ThingsBoard vs ChirpStack" unterstellt, beide würden dasselbe leisten. Tun sie nicht. Ein LoRaWAN-Sensor sendet ein paar Bytes per Funk an ein Gateway. Damit aus diesem Funksignal eine nutzbare, entschlüsselte und an das richtige Gerät zugeordnete Nachricht wird, braucht es einen Network Server. Genau das ist ChirpStack. Erst danach beginnt die Arbeit der Anwendungsplattform: Werte speichern, in Dashboards zeigen, Schwellwerte überwachen, Benachrichtigungen auslösen, Daten an andere Systeme weitergeben. Das ist die Domäne von ThingsBoard.
Mehr Hintergrund zu beiden Bausteinen finden Sie unter Was ist ChirpStack? und Was ist ThingsBoard?.
Was ChirpStack macht: der LoRaWAN Network Server
ChirpStack übernimmt die Netzwerk- und Konnektivitätsschicht für LoRaWAN. Seine Aufgaben:
- Gateways anbinden und verwalten (über die ChirpStack Gateway Bridge und einen MQTT-Broker).
- LoRaWAN-Sitzungen führen: Device Activation (OTAA/ABP), Deduplizierung mehrfach empfangener Pakete, Frame-Counter, Adaptive Data Rate.
- Payloads entschlüsseln und über Codecs vordecodieren.
- Daten ausliefern: ChirpStack veröffentlicht jeden Uplink als JSON oder Protobuf auf einem MQTT-Topic und bietet zusätzlich HTTP- und Cloud-Integrationen.
Seit Version 4 sind Network Server und Application Server zu einer einzigen Komponente verschmolzen, und mehrere Regionen werden ohne separate Instanzen bedient (chirpstack.io/docs/architecture). Aktuell ist ChirpStack v4.19.2 (September 2026) (GitHub Releases), lizenziert unter der MIT-Lizenz und damit kostenlos einsetzbar. Was ChirpStack bewusst nicht ist: eine Anwendungsplattform. Es bringt eine schlanke Web-Oberfläche für Gateways, Geräte und Mandanten mit, aber keine frei baubaren Dashboards, keine komplexe Regel-Engine und keine Reports.
Was ThingsBoard macht: die IoT-Anwendungsplattform
ThingsBoard sitzt eine Schicht höher, auf der Anwendungs- und Plattformebene. Seine Aufgaben:
- Geräteverwaltung über Device Profiles (Transport, Payload-Format, Alarmregeln, Provisionierung).
- Datenaufnahme über native Transporte: MQTT, HTTP, CoAP, LwM2M, SNMP.
- Visualisierung mit frei baubaren Dashboards und Widgets.
- Regel-Engine: Rule Chains verarbeiten eingehende Nachrichten, lösen Alarme aus, transformieren und leiten Daten weiter.
- Mehrmandantenfähigkeit, RBAC, White-Labeling (Letzteres bis 4.3 in der Professional Edition, ab 4.4 mit kommerzieller Lizenz).
Aktuell ist ThingsBoard 4.4 (September 2026) unter der Business Source License 1.1: kostenlos bis 100 Geräte auf einem Server bei kommerzieller Nutzung, darüber lizenzpflichtig. Die letzte Linie unter Apache 2.0 ist die Community Edition 4.3 (Januar 2026, mit Alarm Rules 2.0 und neuen Calculated Fields), die Sicherheitsupdates bis zum 20. Juli 2027 erhält (ThingsBoard, Ankündigung). Was ThingsBoard bewusst nicht ist: ein LoRaWAN Network Server. Es kann kein LoRa-Funksignal verarbeiten und kennt keine LoRaWAN-Sitzungen. Es erwartet Daten, die ihm jemand liefert, etwa ChirpStack.
Vergleichstabelle: ThingsBoard vs ChirpStack
| Kriterium | ChirpStack | ThingsBoard |
|---|---|---|
| Zweck | LoRaWAN Network Server (Daten hereinbringen) | IoT-Anwendungsplattform (Daten nutzen) |
| Architektur-Schicht | Netzwerk / Konnektivität | Anwendung / Plattform |
| Kernfunktion | Gateways, LoRaWAN-Sitzungen, Geräte-Activation | Dashboards, Regel-Engine, Geräteverwaltung |
| Protokolle | LoRaWAN (Funk), Ausgabe per MQTT/HTTP | MQTT, HTTP, CoAP, LwM2M, SNMP |
| Dashboards | Minimal (Geräte-/Gateway-Verwaltung) | Voll, frei baubar |
| Regel-Engine | Nein | Ja (Rule Chains) |
| Mandantenfähigkeit | Ja (Tenants) | Ja (Tenants, Customers, RBAC) |
| Lizenz | MIT (kostenlos) | bis 4.3 CE: Apache 2.0 (kostenlos); ab 4.4: BUSL 1.1, kostenlos bis 100 Geräte auf einem Server |
| Aktuelle Version | v4.19.2 (September 2026) | 4.4 (September 2026), LTS 4.3.1.6 |
| Konkurriert mit dem anderen? | Nein, liefert die Daten | Nein, verarbeitet die Daten |
So spielen beide zusammen: ChirpStack -> MQTT -> ThingsBoard
Der Standardweg in einer self-hosted LoRaWAN-Lösung sieht so aus:
- Sensor -> Gateway: Der LoRaWAN-Sensor funkt seine Bytes an ein Gateway in Reichweite.
- Gateway -> ChirpStack: Das Gateway leitet die Pakete an ChirpStack weiter. ChirpStack entschlüsselt, dedupliziert und ordnet sie dem Gerät zu.
- ChirpStack -> MQTT: ChirpStack veröffentlicht den Uplink als JSON auf einem MQTT-Topic (Schema
application/<id>/device/<devEUI>/event/up). - MQTT -> ThingsBoard: ThingsBoard nimmt die Nachricht über eine Integration entgegen. Ein Uplink-Converter dekodiert das Payload und schreibt die Werte als Telemetrie an das passende Gerät.
- In ThingsBoard: Dashboards zeigen die Werte, die Regel-Engine prüft Schwellwerte, Alarme und Weiterleitungen.
Zwei Wege der Anbindung sind üblich. Die komfortable native ChirpStack-Integration mit fertigen Uplink-Convertern war bis 4.3 der Professional Edition und der Cloud vorbehalten und ist seit 4.4 in allen Lizenzwegen enthalten, im Community Grant nur mit Professional Pack (thingsboard.io/docs). Mit der Community Edition funktioniert es ebenfalls: ChirpStack schreibt die Daten per MQTT oder HTTP direkt an die Geräte-API von ThingsBoard, authentifiziert über den Device Access Token (chirpstack.io/docs/guides/thingsboard). Praktisch hängen zwischen beiden Diensten ein MQTT-Broker (etwa Mosquitto) sowie je eine eigene Datenhaltung (ChirpStack nutzt PostgreSQL und Redis, ThingsBoard PostgreSQL und optional TimescaleDB/Cassandra).
Wann reicht eines, wann brauchen Sie beide?
Nur ChirpStack genügt selten allein. Sinnvoll ist das, wenn Sie ausschließlich einen LoRaWAN Network Server betreiben und die Daten an ein bereits vorhandenes Zielsystem (eigene Software, Datenbank, Cloud-Dienst) ausliefern. ChirpStacks eigene Oberfläche reicht zum Verwalten von Gateways und Geräten, nicht für Endanwender-Dashboards.
Nur ThingsBoard genügt, wenn Ihre Geräte kein LoRaWAN sprechen: MQTT-, HTTP-, CoAP-, LwM2M- oder über Adapter angebundene Modbus-/OPC-UA-Geräte gehen direkt in ThingsBoard, ganz ohne Network Server.
Beide zusammen sind die Regel, sobald Sie LoRaWAN-Sensoren anbinden und echte Dashboards, Alarme, Mandantentrennung und eine Regel-Engine brauchen. Das ist der klassische Aufbau einer souveränen, self-hosted IoT-Plattform: ChirpStack als Network Server, ThingsBoard als Anwendungsschicht, oft ergänzt um Grafana für Spezial-Dashboards. Eine breitere Einordnung der Bausteine gibt der Vergleich Open-Source-IoT-Plattformen.
Lizenz und Kosten kurz eingeordnet
ChirpStack ist MIT-lizenziert und kennt keine Editionen oder Per-Device-Gebühren. Bei ThingsBoard hängt es von der Version ab: Die Community Edition bis 4.3 ist Apache 2.0 und kostenlos, auch kommerziell, erhält aber nur bis zum 20. Juli 2027 Sicherheitsupdates. Ab Version 4.4 gilt die BUSL 1.1: Kommerzielle Produktion ist bis 100 Geräte auf einem Server kostenlos, darüber braucht es eine kommerzielle Lizenz ab 99 USD pro Monat oder eine Perpetual License ab 4.999 USD einmalig. Bestehende CE-Installationen können über den Community Grant in ihrer heutigen Größe kostenlos wechseln. ThingsBoard Cloud rechnet nach Geräten ab (Mehrgeräte 0,30 USD/Gerät, Managed Private Cloud ab 1.499 USD/Monat; Stand thingsboard.io/pricing, Oktober 2026). Die Einordnung des Lizenzwechsels steht im Beitrag ThingsBoard 4.4 unter BUSL 1.1. Eine vollständige Aufschlüsselung steht unter ThingsBoard Preise und Was kostet ChirpStack?.
Wichtig für die Gesamtrechnung: Der reale Kostentreiber einer self-hosted Lösung sind nicht Lizenzen, sondern Server, Betrieb und Wartung. Genau hier liegt der Vorteil gegenüber Managed-IoT-Clouds (AWS IoT, Azure IoT, Cumulocity), deren Per-Device- und Per-Message-Abrechnung mit der Gerätezahl explodiert. Mehr dazu im Vergleich IoT self-hosted vs. Cloud.
Betrieb und Unterstützung
Wir planen, bauen und betreiben souveräne, self-hosted IoT-Plattformen aus ChirpStack und ThingsBoard auf Ihrer Infrastruktur (Proxmox, Hetzner, on-prem), DSGVO-konform aus Deutschland und ohne Cloud-Lock-in. Mehr dazu auf unseren Seiten zu ThingsBoard und ChirpStack sowie im IoT-Hub und speziell zu LoRaWAN. Für ein unverbindliches Erstgespräch buchen Sie direkt einen Termin.
