InfluxDB und MQTT im Energiemonitoring: Was die Kombination in der Praxis leistet
MQTT transportiert deine Messwerte, InfluxDB speichert sie als Zeitreihe – zusammen ergeben sie das Rückgrat vieler Monitoring-Systeme. Hier liest du direkt, welche Rolle jede Komponente übernimmt und wo die Kombination an ihre Grenzen kommt.
MQTT ist ein schlankes Publish/Subscribe-Protokoll: Zähler, Wechselrichter oder Sensoren senden ihre Werte an einen Broker, dein System abonniert die Topics. InfluxDB ist eine Zeitreihen-Datenbank, die genau solche zeitgestempelten Messwerte effizient ablegt und abfragbar macht. MQTT ist also der Transport, InfluxDB der Speicher – das eine bewegt Daten, das andere hält sie vor. Beide zusammen ersetzen weder deine Auswertung noch dein Regelwerk, sie liefern die Datenbasis dafür.
In der Praxis läuft am Edge ein kleiner Rechner (z. B. ein Raspberry Pi), der die Anlage per Modbus TCP oder Herstellerschnittstelle ausliest und die Werte als MQTT-Nachricht – meist JSON – an einen Broker publiziert. Ein Bridge-Dienst abonniert diese Topics und schreibt die Punkte in InfluxDB. Bei uns läuft genau dieses Muster: ein MQTT-zu-Datenbank-Bridge-Service abonniert Topics wie `anlage/bhkw/*/json` oder `anlage/shelly/*/json` und legt sie strukturiert in der Zeitreihen-Datenbank ab. Als Ingest-Werkzeug für InfluxDB ist häufig Telegraf mit MQTT-Input im Einsatz.
Sie entkoppelt Erfassung und Auswertung: Fällt die Netzverbindung aus, puffert der Broker (oder die Edge-Logik) und liefert nach, ohne dass Werte verloren gehen. MQTT skaliert auf viele verteilte Standorte, weil jeder Sensor nur in sein Topic publiziert. InfluxDB wiederum ist auf hohe Schreibraten von Zeitstempel-Werten ausgelegt und beantwortet Zeitraum-Abfragen (Tageslast, Peak, Mittelwert) schnell. Für Lastgänge, Erzeugungskurven und Grenzwert-Überwachung ist das ein solides Fundament.
Ein bewährtes Muster ist die Doppelung: InfluxDB läuft lokal am Standort (rotierend, als Kurzzeit-Puffer), während die Werte parallel per MQTT an einen zentralen Server gehen. Am Edge hast du so auch bei Verbindungsabbruch noch ein Dashboard und Rohdaten; zentral entsteht die standortübergreifende Sicht. Für Steuerbefehle (z. B. Wechselrichter abregeln) empfiehlt sich ein Audit-Log lokal plus eine MQTT-Bestätigung (ACK) zurück – so bleibt nachvollziehbar, was wann geschaltet wurde.
MQTT selbst garantiert je nach QoS-Stufe nur „mindestens einmal“ oder „genau einmal“ – Topic-Struktur, QoS und Retain-Flag musst du bewusst festlegen, sonst bekommst du Duplikate oder Lücken. InfluxDB braucht eine durchdachte Retention Policy, sonst wächst der Speicher unkontrolliert. Sicherheit ist Pflicht: TLS auf dem Broker, eigene MQTT-Nutzer je Standort und getrennte Buckets. Und: Die Kombination liefert Daten, keine Bewertung – die Fachlogik (§51-Prüfung, Wirtschaftlichkeit) baust du darüber.
Wenn du mehrere verteilte Messpunkte oder Standorte hast und Live-Zeitreihen brauchst, ist MQTT + InfluxDB fast Standard. Für einen einzelnen Zähler ohne Fernabfrage reicht oft ein einfacherer Weg. Sobald du aber Wechselrichter, BHKW, Zähler und Shelly-Sensoren gemeinsam erfassen, Lastgänge auswerten oder Steuerbefehle rückmelden willst, spielt die Kombination ihre Stärke aus – als Datenschicht unter Dashboard, Alarmierung und Auswertung.