ThingsBoard vs ChirpStack: Unterschied und Zusammenspiel

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.18.0 (Mai 2026), 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 in der Professional Edition).

Aktuell ist ThingsBoard 4.3 (Januar 2026) mit Alarm Rules 2.0 und neuen Calculated Fields. Die Community Edition steht unter Apache 2.0 und ist kostenlos, auch kommerziell. 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

So spielen beide zusammen: ChirpStack -> MQTT -> ThingsBoard

Der Standardweg in einer self-hosted LoRaWAN-Lösung sieht so aus:

1. Sensor -> Gateway: Der LoRaWAN-Sensor funkt seine Bytes an ein Gateway in Reichweite.
2. Gateway -> ChirpStack: Das Gateway leitet die Pakete an ChirpStack weiter. ChirpStack entschlüsselt, dedupliziert und ordnet sie dem Gerät zu.
3. ChirpStack -> MQTT: ChirpStack veröffentlicht den Uplink als JSON auf einem MQTT-Topic (Schema application/<id>/device/<devEUI>/event/up).
4. 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.
5. 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 ist Teil der ThingsBoard Professional Edition und Cloud (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

Beide Kernkomponenten sind quelloffen und lizenzkostenfrei. ChirpStack ist MIT-lizenziert und kennt keine Editionen oder Per-Device-Gebühren. ThingsBoard Community Edition ist Apache 2.0 und ebenfalls kostenlos, auch kommerziell. Für Funktionen wie White-Labeling, erweitertes RBAC, Scheduler und die fertigen Platform-Integrationen gibt es die Professional Edition: als Perpetual License ab 4.999 USD einmalig oder als Cloud-/Managed-Modell mit Per-Device-Komponente (Cloud-Mehrgeräte ab 0,30 USD/Gerät, Managed Private Cloud ab 1.499 USD/Monat; Stand thingsboard.io/pricing, Juni 2026). 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.