InfluxDB und Telegraf: Langzeit-Datenerfassung für PV-Anlagen
Dein Balkonkraftwerk liefert jede Sekunde Messwerte: Leistung, Spannung, Strom, Energie. Die Hersteller-App zeigt dir die letzten Tage, vielleicht Wochen. Aber was ist mit dem Vergleich zum Vorjahr? Mit der Frage, ob deine Module über die Jahre degradieren? Dafür brauchst du eine Langzeit-Datenbank, und genau dafür ist InfluxDB gemacht.
TL;DR
- InfluxDB ist eine Zeitreihendatenbank, die Messwerte effizient über Jahre speichert, ohne die Festplatte zu sprengen
- Telegraf ist der Datensammler, der Messwerte aus MQTT (OpenDTU, Shelly) entgegennimmt und in InfluxDB schreibt
- Installation auf Raspberry Pi, NAS oder Mini-PC per Docker in 10 Minuten
- Retention Policies bestimmen, wie lange Daten in welcher Auflösung gespeichert werden (z.B. 30 Tage sekündlich, 2 Jahre in 5-Minuten-Intervallen, unbegrenzt als Tagessummen)
- Der gesamte Stack (InfluxDB + Telegraf) braucht auf einem Raspberry Pi weniger als 500 MB RAM und wenige GB Speicherplatz
Warum eine Zeitreihendatenbank?
Du könntest deine Ertragsdaten auch in eine Excel-Tabelle eintragen. Jeden Tag eine Zeile, den Tagesertrag daneben. Das funktioniert, wird aber schnell unhandlich und gibt dir keine Detailauflösung. Wann genau hat die Leistung heute Mittag gepeakt? Wie sah die Kurve an dem Regentag letzte Woche aus? Solche Fragen kann Excel nicht beantworten, wenn du nur Tagessummen hast.
InfluxDB ist eine Datenbank, die für genau solche Messwerte optimiert ist. Sie speichert Datenpunkte mit Zeitstempel und macht Abfragen wie "Zeig mir die durchschnittliche Leistung pro Stunde im Juni 2025" in Millisekunden. Normale SQL-Datenbanken können das auch, aber bei Millionen von Datenpunkten werden sie langsam. InfluxDB bleibt schnell, weil sie intern anders organisiert ist.
Der Clou: Du speicherst nicht nur Tagessummen, sondern Messwerte alle 5-30 Sekunden. Damit hast du Leistungskurven in hoher Auflösung und kannst präzise analysieren, wann genau ein Problem aufgetreten ist, ob Verschattung die Ursache war und wie sich Wetterwechsel auf den Ertrag auswirken.
Die Architektur: Wer macht was?
Das Setup besteht aus drei Teilen, die zusammenspielen:
OpenDTU (oder Shelly) liest die Messwerte vom Wechselrichter und veröffentlicht sie per MQTT. Das ist die Datenquelle.
Telegraf ist der Datensammler. Er abonniert die MQTT-Topics von OpenDTU, nimmt die Messwerte entgegen und schreibt sie in InfluxDB. Telegraf ist dabei extrem flexibel: Er kann Daten aus hunderten verschiedenen Quellen lesen und transformieren.
InfluxDB ist die Datenbank. Hier landen die Messwerte und werden dauerhaft gespeichert. InfluxDB organisiert sie so, dass zeitbasierte Abfragen effizient sind.
Und dann kommt Grafana dazu (optional, aber empfohlen), das die Daten aus InfluxDB liest und als Dashboards visualisiert. Aber Grafana ist ein eigenes Thema, hier konzentrieren wir uns auf die Datenhaltung.
Installation: InfluxDB und Telegraf mit Docker
Docker ist der einfachste Weg, weil du keine Abhängigkeiten installieren und keine Systemkonfiguration anpassen musst. Ein Docker Compose File und ein Befehl, und alles läuft.
Voraussetzung: Docker auf dem Raspberry Pi
Falls Docker noch nicht installiert ist:
curl -fsSL https://get.docker.com | sh
sudo usermod -aG docker $USER
Abmelden, wieder anmelden. Docker ist bereit.
Docker Compose für InfluxDB und Telegraf
Erstelle einen Ordner für dein Monitoring-Setup und darin eine docker-compose.yml:
version: "3"
services:
influxdb:
image: influxdb:2.7
ports:
- "8086:8086"
volumes:
- ./influxdb-data:/var/lib/influxdb2
- ./influxdb-config:/etc/influxdb2
environment:
- DOCKER_INFLUXDB_INIT_MODE=setup
- DOCKER_INFLUXDB_INIT_USERNAME=admin
- DOCKER_INFLUXDB_INIT_PASSWORD=sicheres-passwort
- DOCKER_INFLUXDB_INIT_ORG=home
- DOCKER_INFLUXDB_INIT_BUCKET=solar
- DOCKER_INFLUXDB_INIT_RETENTION=30d
- DOCKER_INFLUXDB_INIT_ADMIN_TOKEN=dein-api-token
restart: unless-stopped
telegraf:
image: telegraf:latest
volumes:
- ./telegraf.conf:/etc/telegraf/telegraf.conf:ro
depends_on:
- influxdb
restart: unless-stopped
Die Umgebungsvariablen konfigurieren InfluxDB beim ersten Start: Ein Admin-Benutzer wird angelegt, eine Organisation ("home"), ein Bucket ("solar") und ein API-Token erstellt. Die Retention von 30 Tagen ist nur der Standard für den initialen Bucket, wir passen das gleich noch an.
Telegraf konfigurieren
Telegraf braucht eine Konfigurationsdatei telegraf.conf, die ihm sagt, woher er Daten holen und wohin er sie schreiben soll. Erstelle die Datei im gleichen Ordner:
[agent]
interval = "10s"
round_interval = true
flush_interval = "10s"
[[outputs.influxdb_v2]]
urls = ["http://influxdb:8086"]
token = "dein-api-token"
organization = "home"
bucket = "solar"
[[inputs.mqtt_consumer]]
servers = ["tcp://dein-mqtt-broker:1883"]
topics = [
"solar/+/+/+",
"solar/+/status/+"
]
topic_tag = "topic"
data_format = "value"
data_type = "float"
Die topics musst du an dein MQTT-Setup anpassen. OpenDTU veröffentlicht standardmäßig unter solar/<serial>/0/power, solar/<serial>/0/voltage etc. Die Wildcard + steht für beliebige Ebenen.
Wenn du einen Shelly Plug S per MQTT eingebunden hast, fügst du die entsprechenden Shelly-Topics hinzu:
[[inputs.mqtt_consumer]]
servers = ["tcp://dein-mqtt-broker:1883"]
topics = [
"shellies/shellyplug-s-XXXXXX/relay/0/power",
"shellies/shellyplug-s-XXXXXX/relay/0/energy"
]
topic_tag = "topic"
data_format = "value"
data_type = "float"
Alles starten
docker compose up -d
Nach 30 Sekunden ist alles am Laufen. Prüfe mit docker compose logs -f, ob Fehlermeldungen auftauchen. Wenn Telegraf sich erfolgreich mit dem MQTT-Broker und InfluxDB verbindet, siehst du keine Fehler.
InfluxDB kennenlernen: Buckets, Measurements und Fields
InfluxDB organisiert Daten anders als klassische Datenbanken. Statt Tabellen mit Spalten gibt es drei Konzepte:
Bucket: Ein Container für zusammengehörige Daten, vergleichbar mit einer Datenbank. Du hast einen Bucket "solar" für PV-Daten, eventuell einen zweiten "weather" für Wetterdaten.
Measurement: Eine Gruppe von Messwerten, vergleichbar mit einer Tabelle. In deinem "solar"-Bucket gibt es das Measurement "inverter" mit den Messwerten deines Wechselrichters.
Field: Ein einzelner Messwert mit Zeitstempel, z.B. "power = 423.5 W" um 12:34:56 Uhr.
Tag: Ein Label zur Kategorisierung, z.B. "channel = 0" oder "inverter = HM-800". Tags werden indexiert und machen Abfragen schnell.
Wenn du Telegraf die MQTT-Daten schreiben lässt, erzeugt er automatisch Measurements und Fields basierend auf den MQTT-Topic-Namen. Du musst nichts manuell anlegen.
Retention Policies: Daten schlau aufbewahren
Hier wird es spannend, denn die Frage "Wie lange speichere ich welche Daten?" ist entscheidend für den Speicherverbrauch und die Nützlichkeit deiner Langzeitdaten.
Ein Balkonkraftwerk mit 2 Modulen und OpenDTU erzeugt bei 10-Sekunden-Intervallen etwa 20-30 Datenpunkte pro Messzyklus (Leistung, Spannung, Strom, Energie, Temperatur, Status für beide Kanäle plus Gesamt). Das sind rund 250.000 Datenpunkte pro Tag. Über ein Jahr summiert sich das auf 90 Millionen Datenpunkte. Klingt nach viel, ist für InfluxDB aber kein Problem, solange du den Speicherplatz hast.
In der Praxis brauchst du aber nicht jede Sekunde der letzten fünf Jahre in voller Auflösung. Eine sinnvolle Strategie:
Stufe 1: Hochauflösend (letzte 30 Tage)
Die letzten 30 Tage speicherst du in voller Auflösung (alle 10 Sekunden). Das erlaubt dir, Leistungskurven im Detail zu analysieren, Verschattungsmuster zu erkennen und sporadische Fehler aufzuspüren.
Stufe 2: Mittlere Auflösung (letzte 2 Jahre)
Ältere Daten werden auf 5-Minuten-Durchschnitte komprimiert. Damit kannst du immer noch Tagesverläufe und Wochen-Muster erkennen, sparst aber 97 % Speicherplatz gegenüber der vollen Auflösung.
Stufe 3: Tagessummen (unbegrenzt)
Ab zwei Jahren behältst du nur noch die Tagessummen: Tagesertrag in kWh, Maximum-Leistung, Durchschnittstemperatur. Das sind wenige Kilobyte pro Tag und erlaubt Langzeitvergleiche über die gesamte Lebensdauer deiner Anlage.
In InfluxDB umsetzen
InfluxDB 2.x nutzt "Tasks" und "Downsampling Buckets" für diese Strategie:
- Erstelle einen Bucket "solar_5m" mit 730 Tagen Retention
- Erstelle einen Bucket "solar_daily" ohne Retention-Limit
- Erstelle Tasks, die regelmäßig die Daten aggregieren und in die entsprechenden Buckets schreiben
Ein Task für die 5-Minuten-Aggregation sieht so aus:
option task = {name: "downsample_5m", every: 5m}
from(bucket: "solar")
|> range(start: -10m)
|> filter(fn: (r) => r._measurement == "mqtt_consumer")
|> aggregateWindow(every: 5m, fn: mean)
|> to(bucket: "solar_5m", org: "home")
Und ein täglicher Task für die Tagessummen:
option task = {name: "downsample_daily", every: 1d}
from(bucket: "solar_5m")
|> range(start: -2d)
|> filter(fn: (r) => r._field == "daily_yield")
|> aggregateWindow(every: 1d, fn: max)
|> to(bucket: "solar_daily", org: "home")
Speicherverbrauch: Was du einplanen solltest
Auf einem Raspberry Pi mit SD-Karte oder einem kleinen SSD-Speicher ist der Platz begrenzt. Hier eine realistische Kalkulation:
- 30 Tage hochauflösend (10 Sekunden, 1 Wechselrichter): ca. 200-500 MB
- 2 Jahre in 5-Minuten-Auflösung: ca. 50-100 MB
- 10 Jahre Tagessummen: ca. 5-10 MB
- InfluxDB Overhead (Index, WAL): ca. 200-500 MB
Insgesamt brauchst du also 500 MB bis 1,5 GB für eine umfassende Langzeitdatenbank eines einzelnen Balkonkraftwerks. Auf einer 32-GB-SD-Karte ist das kein Problem. Allerdings: SD-Karten mögen keine dauerhaften Schreibzugriffe. Wenn du einen Raspberry Pi nutzt, solltest du entweder eine USB-SSD anschließen (20-30 Euro für 120 GB) oder zumindest eine hochwertige SD-Karte (Samsung EVO, SanDisk Extreme) verwenden.
OpenDTU-Daten optimal in InfluxDB bringen
Das GitHub-Projekt "OpenDTU-MQTT-Telegraf-influxdb-integration" (von smainz) bietet eine fertige Telegraf-Konfiguration, die speziell für OpenDTU-MQTT-Topics optimiert ist. Statt generisch alle MQTT-Nachrichten zu schlucken, parst sie die Topic-Struktur intelligent und erzeugt saubere Measurements und Tags.
Die Vorteile dieser optimierten Konfiguration:
- Jeder Wechselrichter wird als eigenes Measurement gespeichert
- Die Modulkanäle (DC-Eingang 0, 1, 2, 3) sind als Tags angelegt, was effiziente Abfragen ermöglicht
- Status-Messages werden als Strings gespeichert, nicht als Floats (verhindert Datenfehler)
- Die Konfiguration kommt mit einem passenden Grafana-Dashboard
Wenn du OpenDTU nutzt, ist diese fertige Integration der schnellste Weg zu sauberen Langzeitdaten.
Daten abfragen: Flux-Grundlagen
Flux ist die Abfragesprache von InfluxDB 2.x. Sie sieht auf den ersten Blick ungewohnt aus, ist aber logisch aufgebaut: Daten fließen durch eine Pipeline von Filtern und Transformationen.
Beispiel: Tagesertrag der letzten Woche
from(bucket: "solar")
|> range(start: -7d)
|> filter(fn: (r) => r._field == "daily_yield")
|> aggregateWindow(every: 1d, fn: max)
Lies das so: "Nimm Daten aus dem Bucket 'solar', der letzten 7 Tage, filtere auf das Feld 'daily_yield' und berechne für jeden Tag den Maximalwert." Der Maximalwert des Tagesertrags ist der Gesamtertrag dieses Tages, weil der Zähler über den Tag ansteigt.
Beispiel: Durchschnittliche Leistung pro Stunde
from(bucket: "solar")
|> range(start: -24h)
|> filter(fn: (r) => r._field == "ac_power")
|> aggregateWindow(every: 1h, fn: mean)
Beispiel: Vergleich zweier Module
from(bucket: "solar")
|> range(start: -24h)
|> filter(fn: (r) => r._field == "dc_power")
|> filter(fn: (r) => r.channel == "0" or r.channel == "1")
|> aggregateWindow(every: 5m, fn: mean)
Du musst kein Flux-Experte werden. Für die meisten Dashboards reichen diese Grundmuster, und du passt nur Zeiträume, Felder und Aggregationen an.
Backup: Daten sichern
Jahre von PV-Daten sind wertvoll, und eine kaputte SD-Karte kann sie in Sekunden vernichten. Ein regelmäßiges Backup ist Pflicht.
InfluxDB bietet eingebaute Backup-Funktionen:
docker exec influxdb influx backup /tmp/backup --org home --token dein-api-token
docker cp influxdb:/tmp/backup ./backup-$(date +%Y%m%d)
Diesen Befehl kannst du per Cron-Job wöchentlich oder monatlich ausführen und die Backup-Dateien auf ein NAS, eine externe Festplatte oder in die Cloud kopieren.
Alternativ, wenn du nur die Tagessummen sichern willst (die wichtigsten Langzeitdaten), exportiere sie als CSV:
from(bucket: "solar_daily")
|> range(start: 2024-01-01)
|> filter(fn: (r) => r._field == "daily_yield")
Diesen Export kannst du über das InfluxDB-Webinterface als CSV herunterladen und archivieren.
Troubleshooting
Telegraf schreibt keine Daten
Prüfe mit docker compose logs telegraf die Fehlermeldungen. Die häufigsten Ursachen: falsche MQTT-Broker-Adresse, falsches API-Token für InfluxDB, oder die MQTT-Topics in der Konfiguration passen nicht zu dem, was OpenDTU tatsächlich sendet. Nutze ein MQTT-Tool wie MQTT Explorer, um zu sehen, welche Topics auf dem Broker ankommen.
InfluxDB wird langsam
Wenn Abfragen über große Zeiträume langsam werden, fehlt vermutlich das Downsampling. Ohne Aggregation versucht InfluxDB, Millionen von Datenpunkten zu verarbeiten. Nutze aggregateWindow() in deinen Abfragen und richte die Downsampling-Tasks ein.
Speicherplatz wird knapp
Prüfe, ob die Retention Policies greifen. In InfluxDB unter Data > Buckets siehst du den Speicherverbrauch pro Bucket. Wenn der hochauflösende Bucket zu groß wird, verkürze die Retention auf 14 oder 7 Tage.
Datenqualität sicherstellen
Rohe Messdaten aus MQTT sind nicht immer sauber. Telegraf bietet Möglichkeiten, die Datenqualität zu verbessern, bevor die Werte in InfluxDB landen.
Ausreißer filtern
Gelegentlich sendet OpenDTU Messwerte, die offensichtlich falsch sind: negative Leistungswerte, Spannungsspitzen von 1.000 Volt oder Temperaturangaben von -50 Grad. Solche Ausreißer verfälschen deine Statistiken und erzeugen hässliche Spikes in Grafana.
Telegraf hat Processor-Plugins, die solche Werte filtern können. Mit dem processors.starlark-Plugin kannst du individuelle Filterregeln definieren, zum Beispiel: "Verwerfe alle Leistungswerte über 1.000 Watt oder unter -5 Watt" und "Verwerfe alle Temperaturwerte unter -20 oder über 100 Grad."
Lücken erkennen
Wenn die Verbindung zwischen OpenDTU und dem Wechselrichter unterbrochen ist, kommen keine Daten an. InfluxDB speichert einfach nichts, und in Grafana entsteht eine Lücke in der Kurve. Das ist korrekt, kann aber bei Berechnungen (z.B. Tagessumme) zu Ungenauigkeiten führen, weil die fehlenden Zeiträume als Null gewertet werden.
In der Praxis sind kurze Lücken von 1-2 Minuten irrelevant. Wenn aber stundenlange Ausfälle auftreten, solltest du in Grafana die Verbindungsoption "Connect null values" deaktivieren, damit die Lücken sichtbar bleiben und nicht als durchgehende Linie dargestellt werden.
Zeitstempel beachten
Telegraf schreibt die Daten mit dem Zeitstempel des Empfangs, nicht mit dem Zeitstempel der Messung. Bei einer stabilen Verbindung ist der Unterschied minimal (wenige Sekunden). Bei Verbindungsabbrüchen können Daten aber gepuffert und verzögert gesendet werden. In den meisten Fällen ist das für PV-Monitoring unkritisch, bei der Korrelation mit Wetterdaten solltest du es im Hinterkopf behalten.
Erweiterte Architektur: Node-RED als Datenvermittler
Für fortgeschrittene Setups kann Node-RED als Datenvermittler zwischen MQTT und InfluxDB dienen. Node-RED ist ein visuelles Programmier-Tool, das Datenflüsse als Diagramme darstellt und beliebig komplexe Transformationen erlaubt.
Typische Anwendungen:
Daten anreichern: Node-RED kann Wetterdaten von einer API abrufen und zusammen mit den PV-Daten in InfluxDB schreiben. So hast du Einstrahlung, Temperatur und Bewölkung direkt neben deinen Ertragsdaten.
Berechnungen: Node-RED kann aus den Rohdaten abgeleitete Werte berechnen, zum Beispiel den Eigenverbrauchsanteil (wenn du einen Shelly Pro 3EM am Zähler hast) oder die aktuelle Ersparnis in Euro (Leistung x Strompreis / 1.000).
Routing: Node-RED kann Daten an mehrere Ziele gleichzeitig senden: an InfluxDB für die Langzeitspeicherung, an Grafana für die Visualisierung, an Home Assistant für Automationen und an pvoutput.org für den Community-Vergleich.
Die Installation von Node-RED als Docker-Container ist unkompliziert und ergänzt den bestehenden Stack ohne Konflikte.
Migration und Datenkontinuität
Was passiert, wenn du deinen Raspberry Pi ersetzen, auf ein NAS umziehen oder von InfluxDB 1.x auf 2.x migrieren willst? Datenkontinuität ist bei einem Langzeitarchiv kritisch.
Hardware-Wechsel
Wenn du auf neue Hardware umziehst (neuer Pi, NAS, Mini-PC), kopierst du die Docker-Volumes (influxdb-data, grafana-data) auf das neue System und startest die Container dort. Solange die Pfade stimmen, laufen InfluxDB und Grafana mit allen Daten weiter, als wäre nichts passiert.
InfluxDB Versionswechsel
Der Wechsel von InfluxDB 1.x auf 2.x erfordert eine Datenmigration, weil sich das Datenformat geändert hat. InfluxDB bietet ein eingebautes Migrationstool (influxd upgrade), das den Prozess automatisiert. Trotzdem: Mach vorher ein Backup.
Langfristige Strategie
Plane von Anfang an so, dass deine Daten portabel sind. Nutze Docker-Volumes statt Daten direkt ins Container-Dateisystem zu schreiben. Mache regelmäßige Backups. Und dokumentiere deine Konfiguration (docker-compose.yml, telegraf.conf), sodass du das Setup jederzeit auf neuer Hardware reproduzieren kannst.
Eine gut dokumentierte Docker-Compose-Datei und eine Telegraf-Konfiguration sind zusammen weniger als 100 Zeilen Text. Speichere sie zusammen mit den Backups, und du bist gegen Hardwareausfälle gewappnet.
Der Langzeitnutzen
InfluxDB und Telegraf sind nicht die einfachste Monitoring-Lösung, dafür sind sie die gründlichste. Nach zwei oder drei Jahren hast du einen Datenschatz, der dir Fragen beantwortet, die du heute noch gar nicht stellst: Wie stark haben meine Module degradiert? War der Sommer 2025 wirklich besser als 2026? Lohnt sich das zweite Balkonkraftwerk auf der Westseite? Die Antworten stecken in den Daten, du musst sie nur speichern. Genau das tut dieser Stack, zuverlässig und effizient.
Und es gibt einen Bonus, der nicht in der technischen Beschreibung steht: Das Wissen, dass du einen lückenlosen Datensatz deiner Solaranlage hast, gibt dir Sicherheit. Wenn in fünf Jahren ein Modul auffällig degradiert, hast du die Daten, um gegenüber dem Hersteller einen Garantieanspruch zu belegen. Wenn du dein Haus verkaufst und das Balkonkraftwerk übergibst, hast du eine dokumentierte Geschichte der Anlage. Und wenn du in zehn Jahren zurückschaust und siehst, wie viel Sonnenstrom du über die Jahre geerntet hast, wirst du froh sein, dass du dir die Mühe gemacht hast.