ThingsBoard vs. Grafana: Was passt besser für IoT?
Timo WevelsiepWenn IoT-Daten in der Praxis ankommen, stehen Teams fast immer vor derselben Frage: Brauchen wir „nur" Dashboards und Alerting (Grafana) – oder eine IoT-Plattform mit Device-Modell, Rule Engine und Workflows (ThingsBoard)?
Die kurze Wahrheit: Grafana und ThingsBoard sind selten echte Alternativen. Sie lösen unterschiedliche Teile des IoT-Stacks – und funktionieren in vielen Setups gemeinsam am besten.
Im Folgenden bekommst du einen klaren Vergleich, typische Einsatzszenarien und eine Entscheidungshilfe für produktive IoT-Deployments.
Inhaltsverzeichnis
- 1) Was ist Grafana?
- 2) Was ist ThingsBoard?
- 3) Der Kernunterschied in einem Satz
- 4) Vergleich nach Praxis-Kriterien
- 5) Entscheidungshilfe: Was passt wann?
- 6) Typische Architekturbeispiele
- 7) Häufige Fehler bei der Tool-Entscheidung
- 8) Fazit
- Ihr IoT-Projekt umsetzen
- Quellenverzeichnis
1) Was ist Grafana?
Grafana ist primär eine Visualisierungs- und Observability-Plattform: Dashboards, Abfragen über Datenquellen, Transformationen und Alerting. Grafana kann Daten aus vielen Quellen in einem Dashboard zusammenführen (über Data-Source-Plugins) und bietet Alerting über mehrere Datenquellen inklusive Notification Routing.
Grafana ist stark, wenn du:
- Telemetrie/Metriken visualisieren willst (z. B. Temperatur, CO₂, Spannung, Gateway-Health)
- zuverlässiges Alerting (Schwellwerte, Zustandsänderungen) brauchst
- Observability für Plattformbetrieb (SLO/SLA-Monitoring) willst
2) Was ist ThingsBoard?
ThingsBoard ist eine IoT-Plattform mit Fokus auf Device/Asset-Modelle, Datenverarbeitung und IoT-Workflows. Zentral ist dabei die Rule Engine: Sie empfängt Telemetrie und Events, transformiert/routet sie und reagiert darauf (z. B. Alarme auslösen, Daten an externe Systeme pushen, Workflows starten).
ThingsBoard ist stark, wenn du:
- Geräte/Assets und deren Zustände als Plattform-Objekte modellieren willst
- Regeln/Workflows serverseitig brauchst (Rule Chains, Enrichment, Routing)
- ein IoT-Application-Layer mit Nutzer/Rollen/Entitäten aufbauen willst
3) Der Kernunterschied in einem Satz
- Grafana = „Wie sehen die Daten aus, wie monitoren wir Zustände, wie alarmieren wir?"
- ThingsBoard = „Wie modellieren wir Geräte/Assets, verarbeiten Events, steuern Workflows und bauen eine IoT-Anwendung?"
4) Vergleich nach Praxis-Kriterien
A) Device Management & IoT-Entitäten
- ThingsBoard: Device/Asset-Modell ist Kern der Plattform; eignet sich für Multi-Device- und Multi-Tenant-Setups und „IoT-App-Strukturen".
- Grafana: Kein natives Device-Management; Grafana „kennt" Datenquellen und Visualisierungen, aber keine IoT-Entitäten als Plattformobjekte.
Daumenregel: Wenn du Geräte als „First-Class Citizens" brauchst, ist ThingsBoard näher dran.
B) Dashboards & Visualisierung
- Grafana: Sehr stark in Dashboards, Visualisierung, Datenquellen-Anbindung und Transformationen.
- ThingsBoard: Bietet ebenfalls Dashboards, aber typischerweise als Teil einer IoT-App (mit Device/Asset-Kontext und Workflows).
Daumenregel: Für klassische Ops-Dashboards (SRE/Operations) gewinnt oft Grafana; für „App-Dashboards" pro Kunde/Device ist ThingsBoard häufig passender.
C) Alerting & Benachrichtigungen
- Grafana Alerting: Alert Rules über mehrere Datenquellen, flexible Notification Policies und Routing; basiert auf dem Prometheus-Alerting-Modell.
- ThingsBoard: Kann auf Events/Telemetrie reagieren – häufig über Rule Engine/Alarme/Workflows, also stärker „IoT-Anwendungslogik" als reine Observability.
Daumenregel: Grafana ist sehr stark für Operations-Alerting; ThingsBoard eignet sich, wenn Alerts Teil eines IoT-Workflows sind (z. B. Ticketing, Device-State, Eskalationslogik pro Tenant).
D) Datenverarbeitung / Rules / Workflows
- ThingsBoard: Rule Engine ist das Herzstück (Transformieren, Routen, Reagieren auf Events/Telemetrie).
- Grafana: Keine Rule-Engine-Plattform. Grafana ist „Auswertung/Visualisierung/Alerting", nicht primär Event-Processing.
Daumenregel: Wenn „Business-Logik auf Events" wichtig ist, führt ThingsBoard.
E) Betrieb in Produktion (Ops-Aufwand)
Beide Systeme sind gut, aber: Sie werden oft unterschätzt, sobald es um Upgrades, Backups, Mandanten, Monitoring, Skalierung und Ownership geht.
- Grafana (prod): Datenquellen, Alerting, Provisioning/Config-as-Code, RBAC/Users, Backup-Strategien.
- ThingsBoard (prod): Plattform-Betrieb inkl. Datenverarbeitungspipeline, Rule Chains, Device/Entity-Modelle, Permissions/Tenants, Integrationen.
Daumenregel: ThingsBoard ist eher „Platform-Ops", Grafana eher „Observability-Ops".
5) Entscheidungshilfe: Was passt wann?
Du brauchst Grafana, wenn …
- ihr schnell IoT-Dashboards und Ops-Monitoring braucht
- die Daten sauber in einer TSDB/Monitoring-Pipeline liegen (z. B. Prometheus/Influx)
- Alerting über mehrere Datenquellen und sauberes Routing zentral sein soll
Du brauchst ThingsBoard, wenn …
- ihr Geräte/Assets modellieren wollt (Kunden/Tenants, Rollen, Entitäten)
- ihr Rule Engine / Workflows im IoT-Backend braucht
- ihr eine IoT-Anwendungsschicht aufbauen wollt (nicht nur Monitoring)
Du brauchst beides, wenn …
- ThingsBoard die IoT-Applikationslogik liefert (Rules, Device Model)
- Grafana das Operations-Monitoring und ggf. SRE-Alerting übernimmt
6) Typische Architekturbeispiele
Beispiel A: LoRaWAN (ChirpStack) → Grafana (Ops-Dashboard)
Sensors/Gateways → ChirpStack → Datenpipeline/TSDB → Grafana Dashboards & Alerting
Eignet sich für:
- Kühlhaus-/Temperaturüberwachung
- Umweltmonitoring
- Infrastruktur-Monitoring
Beispiel B: LoRaWAN (ChirpStack) → ThingsBoard (IoT App)
Sensors/Gateways → ChirpStack → MQTT/Integration → ThingsBoard (Rule Engine, Entities, Workflows)
Eignet sich für:
- Multi-Tenant Lösungen
- Customer Portals / Device-Portale
- komplexere Business-Workflows
Beispiel C: Kombi: ThingsBoard (App) + Grafana (Ops)
ThingsBoard für Device-/Tenant-Logik, Grafana für Plattform-Monitoring, SLOs, Alerting, Betrieb.
Eignet sich für:
- größere Rollouts
- Teams mit klarer Trennung „Produkt" vs „Betrieb"
7) Häufige Fehler bei der Tool-Entscheidung
-
Grafana als „IoT-Plattform" behandeln – Grafana ist hervorragend für Dashboards/Alerting, aber kein Device-Management-Backend.
-
ThingsBoard nur als Dashboard-Tool verwenden – Dann bleibt der größte Mehrwert (Rule Engine/IoT-Workflows) ungenutzt.
-
Betrieb unterschätzen – Die ersten Dashboards gehen schnell. Skalierung, Updates, Backups, Monitoring und Ownership sind der eigentliche Kostentreiber.
8) Fazit
Grafana ist deine beste Wahl, wenn du IoT-Daten zuverlässig visualisieren und alerten willst.
ThingsBoard ist deine beste Wahl, wenn du eine IoT-Applikationsschicht mit Device-Modell und Rule Engine brauchst.
In vielen produktiven Umgebungen ergänzen sie sich: ThingsBoard für IoT-Logik, Grafana für Ops-Observability.
Ihr IoT-Projekt umsetzen
Sie haben eine Idee für vernetzte Sensorik? merkaio begleitet Sie von der Anforderungsanalyse bis zum laufenden Betrieb – Technologieauswahl, Architektur, Implementierung und Operations.
Quellenverzeichnis
IoT-Projekt umsetzen?
Von der Idee bis zum laufenden Betrieb – wir begleiten Ihr IoT-Vorhaben.