InfluxDB und MQTT im Energiemonitoring: Was die Kombination in der Praxis leistet

TL;DR: InfluxDB speichert Messwerte zeitreihenoptimiert, MQTT liefert sie von IoT-Sensoren in Echtzeit. Zusammen mit Telegraf und Sparkplug-B entsteht eine flexible Dateninfrastruktur für gewerbliches Energiemonitoring – die Integration erfordert aber sorgfältige Konfiguration.

Warum eine Zeitreihendatenbank für Energiedaten sinnvoll ist

Energieverbrauchsdaten sind von Natur aus zeitgebunden: Jeder Messwert trägt einen Zeitstempel, und der Verlauf über Stunden, Tage oder Monate ist für Trendanalysen ebenso wichtig wie der aktuelle Momentanwert. Relationale Datenbanken sind für solche Abfrageprofile oft nicht optimal ausgelegt.

InfluxDB ist eine Zeitreihendatenbank, die genau für diesen Anwendungsfall entwickelt wurde. Sie speichert Messpunkte kompakt, erlaubt schnelle Aggregationsabfragen über beliebige Zeiträume und integriert sich direkt in Visualisierungstools wie Grafana. Für ein Energiemonitoring-Dashboard, das Lastgänge, Spannungswerte oder Zählerstände darstellen soll, ist das ein struktureller Vorteil gegenüber klassischen SQL-Lösungen.

MQTT als Übertragungsprotokoll für IoT-Sensoren

Sensoren im Gebäude oder auf dem Betriebsgelände – etwa Stromzähler vom Typ SDM630 oder Shelly-Energiemessgeräte – liefern ihre Werte in kurzen Intervallen. Das MQTT-Protokoll (Message Queuing Telemetry Transport) ist für genau diesen Einsatzzweck konzipiert: Es ist leichtgewichtig, verbindungsstabil auch bei instabilen Netzen und arbeitet nach dem Publish-Subscribe-Prinzip.

Ein zentraler MQTT-Broker nimmt die Nachrichten der Geräte entgegen und verteilt sie an alle Subscriber – in diesem Fall an die Datenerfassungsschicht. Geräte wie Loxone-Miniserver oder Emonio-Energiemessgeräte sprechen MQTT nativ oder über Adapter. Das reduziert den Integrationsaufwand erheblich gegenüber proprietären Schnittstellen.

Telegraf als Bindeglied zwischen Protokoll und Datenbank

Den Datentransfer zwischen dem MQTT-Broker und InfluxDB übernimmt Telegraf, ein Plugin-basierter Datensammler. Das Tool abonniert die relevanten MQTT-Topics, wandelt die Nachrichten in das InfluxDB-Zeilenformat um und schreibt sie in die Datenbank. Die Konfiguration erfolgt über eine einzige TOML-Datei, in der Eingabe- und Ausgabe-Plugins definiert werden.

Für industrielle Anwendungen kommt häufig Sparkplug-B hinzu – ein offenes Spezifikationsprotokoll, das auf MQTT aufsetzt und eine einheitliche Nachrichtenstruktur für Industriegeräte definiert. Es standardisiert Gerätestatus, Metadaten und Messwerttypen, was die Interoperabilität zwischen unterschiedlichen Herstellern verbessert.

Stolperfallen aus der Praxis

Die Kombination aus InfluxDB, MQTT und Telegraf klingt im Paket schlüssig – in der Umsetzung treten aber wiederkehrende Probleme auf:

• Topic-Struktur planen: MQTT-Topics wachsen schnell unübersichtlich. Eine klare Hierarchie (z.B. anlage/gebaeude/zaehler/messgröße) sollte vor der ersten Inbetriebnahme festgelegt werden, da nachträgliche Änderungen alle Subscriber betreffen.
• Datentypen konsequent deklarieren: InfluxDB unterscheidet Integer und Float strikt. Telegraf-Konfigurationen, die Typen nicht explizit setzen, können zu Schreibfehlern führen, wenn ein Gerät denselben Wert mal als Integer, mal als Float sendet.
• Broker-Sicherheit nicht vernachlässigen: Ein MQTT-Broker ohne Authentifizierung ist im lokalen Netz ein häufiges Muster – in produktiven Umgebungen mit Fernzugriff ist das ein Risiko. TLS und Passwortauthentifizierung sollten von Beginn an konfiguriert sein.
• Grafana-Verbindung testen: Die InfluxDB-Datenquelle in Grafana erfordert je nach Version (InfluxDB 1.x vs. 2.x) unterschiedliche Abfragesprachen (InfluxQL vs. Flux). Ein Versions-Mismatch führt zu leeren Dashboards ohne eindeutige Fehlermeldung.
• Schreibfrequenz und Retention abwägen: Sehr hohe Abtastraten erzeugen große Datenmengen. InfluxDB-Retention-Policies und Downsampling-Tasks sollten frühzeitig konfiguriert werden, um die Speichernutzung kontrollierbar zu halten.

Fazit

InfluxDB und MQTT sind bewährte Open-Source-Werkzeuge, die sich für das gewerbliche Energiemonitoring gut ergänzen. InfluxDB liefert die nötige Abfrageperformance für Zeitreihendaten, MQTT sorgt für eine standardisierte, gerätenahe Datenübertragung. Telegraf und optional Sparkplug-B schließen die Lücke dazwischen.

Die Technologieauswahl allein genügt nicht: Sorgfältige Planung der Topic-Struktur, explizite Datentypdeklaration und eine gesicherte Broker-Konfiguration sind Voraussetzungen dafür, dass das System im Betrieb stabil bleibt und auswertbare Daten liefert. Wer diese Grundlagen legt, erhält eine flexible Basis, die sich auf neue Messstellen und Gerätetypen erweitern lässt.

FAQ

Was ist der Unterschied zwischen MQTT und HTTP für IoT-Sensoren?

MQTT arbeitet nach dem Publish-Subscribe-Prinzip mit dauerhafter Verbindung zum Broker und ist deutlich ressourcenschonender als wiederholte HTTP-Requests. Es eignet sich besonders für Geräte mit begrenzter Rechenleistung und für Anwendungen, bei denen viele Messpunkte in kurzen Intervallen übertragen werden.

Kann ich bestehende Shelly-Geräte direkt mit InfluxDB verbinden?

Shelly-Geräte unterstützen MQTT nativ. Mit einem lokalen MQTT-Broker (z.B. Mosquitto) und Telegraf als Mittler lassen sich die Shelly-Messwerte ohne zusätzliche Software direkt in InfluxDB schreiben und in Grafana visualisieren.

Was ist Sparkplug-B und brauche ich es?

Sparkplug-B ist eine Spezifikation, die auf MQTT aufsetzt und eine einheitliche Nachrichtenstruktur für Industriegeräte definiert. Für einfache Installationen mit wenigen Geräten ist es nicht notwendig. Es wird relevant, wenn verschiedene Hersteller und Gerätetypen interoperabel kommunizieren sollen.

Wie lange sollte ich Energiedaten in InfluxDB aufbewahren?

Das hängt von den Analyse- und Dokumentationsanforderungen ab. InfluxDB erlaubt Retention Policies, die ältere Rohdaten automatisch löschen. Typisch ist eine Kombination aus hochaufgelösten Kurzzeit-Daten (Wochen bis Monate) und langfristig aggregierten Stundenwerten für Trendauswertungen und Vergleiche.