ThingsBoard vs. Grafana: Was passt besser für IoT?

Wenn 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
  • A) Device Management & IoT-Entitäten
  • B) Dashboards & Visualisierung
  • C) Alerting & Benachrichtigungen
  • D) Datenverarbeitung / Rules / Workflows
  • E) Betrieb in Produktion (Ops-Aufwand)
• 5) Entscheidungshilfe: Was passt wann?
  • Du brauchst Grafana, wenn …
  • Du brauchst ThingsBoard, wenn …
  • Du brauchst beides, wenn …
• 6) Typische Architekturbeispiele
  • Beispiel A: LoRaWAN (ChirpStack) → Grafana (Ops-Dashboard)
  • Beispiel B: LoRaWAN (ChirpStack) → ThingsBoard (IoT App)
  • Beispiel C: Kombi: ThingsBoard (App) + Grafana (Ops)
• 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

1. Grafana als „IoT-Plattform" behandeln – Grafana ist hervorragend für Dashboards/Alerting, aber kein Device-Management-Backend.

2. ThingsBoard nur als Dashboard-Tool verwenden – Dann bleibt der größte Mehrwert (Rule Engine/IoT-Workflows) ungenutzt.

3. 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.

Projekt besprechen →

---

Quellenverzeichnis

• Grafana Dashboards Documentation
• ThingsBoard Rule Engine Overview
• ThingsBoard GitHub Repository
• Grafana Data Sources
• Grafana Alerting Fundamentals