Ein Batteriespeicher kann in der Hersteller-App völlig normal aussehen und trotzdem deutlich weniger nutzbare Energie liefern als erwartet. Genau das zeigte sich bei meinem Marstek Venus E: keine Warnung, kein Fehlercode und unauffällige Temperaturen – aber zwei reproduzierbare Entladetests ergaben nur rund 3,84 kWh auf der Batterieseite und knapp 74 Ah zwischen 100 und 12 Prozent SOC.
Damit sich solche Messreihen ohne direkten Zugriff auf InfluxDB auswerten lassen, habe ich ein PowerShell-Skript erstellt. Es fragt die historischen Werte über die offizielle openHAB-Persistence-REST-API ab, erkennt die Entladephase und erstellt daraus einen Bericht, eine CSV-Datei und strukturierte JSON-Daten. Das mitgelieferte Mapping enthält direkt die Item-Namen meiner Marstek-Installation.
Der konkrete Anlass, die beiden kontrollierten Messläufe und die Reaktion des Herstellers sind im Beitrag Marstek Venus E im Langzeittest: Wie viel Kapazität bleibt nach rund 317 Zyklen? dokumentiert.
Was das openHAB-Skript auswertet
- AC-Energie: die am Wechselstromausgang abgegebene Energie, aus der Leistung über die Zeit integriert.
- DC-Energie: die auf der Batterieseite entnommene Energie vor den Verlusten des Wechselrichters.
- Amperestunden: die entnommene elektrische Ladung als zweite, von der Energieintegration unabhängige Plausibilitätsprüfung.
- SOC-Fenster: der tatsächlich durchlaufene Bereich des angezeigten Ladezustands.
- Zellspannungen: Minimum, Maximum, größte Differenz und 95-Prozent-Perzentil der Zellspreizung.
- Temperaturen: höchste Zell-, Innen- und MOS-Temperatur im gewählten Zeitraum.
- Diagnosewörter: Prüfung aller eingebundenen Alarm- und Fehlerregister auf Werte ungleich null.
Zusätzlich vergleicht das Skript die gemessene DC-Energie und die entnommenen Ah mit der Nennkapazität für das genutzte SOC-Fenster. Daraus entsteht eine grobe Hochrechnung auf 100 Prozent. Diese Hochrechnung ist kein Ersatz für eine kalibrierte Labormessung, macht wiederholbare Abweichungen aber sichtbar.
Warum die openHAB-Persistenz statt eines direkten InfluxDB-Zugriffs?
openHAB kapselt die jeweils verwendete Datenbank hinter seiner Persistence-API. Dadurch muss das Skript weder InfluxDB-Organisation, Bucket und Token noch Details einer anderen Persistence-Lösung kennen. Entscheidend ist nur, dass die benötigten Items im gewählten Dienst gespeichert wurden.
Das macht die Auswertung portabler und reduziert die Zahl der Zugangsdaten. Das Skript arbeitet ausschließlich lesend. Es sendet keine Befehle an den Speicher und verändert keine openHAB-Konfiguration.
Voraussetzungen
- PowerShell 7 auf Windows, Linux oder macOS
- openHAB mit einer eingerichteten Persistence, in meinem Beispiel InfluxDB
- persistierte Items für SOC, AC-Leistung, DC-Leistung und Batteriestrom
- ein openHAB-API-Token mit Lesezugriff
- ein Zeitraum, der möglichst genau einen kontrollierten Entladevorgang enthält
Die Zellspannungen, Temperaturen, der interne Entladezähler sowie Alarm- und Fehlerwörter sind optional, erhöhen aber die Aussagekraft deutlich. Wie die Modbus-Werte grundsätzlich in openHAB landen, zeige ich in meiner Anleitung zur Modbus-TCP-Anbindung des Marstek Venus.
Messlauf mit openHAB automatisch erzeugen
Das PowerShell-Skript wertet vorhandene Messreihen aus, erzeugt den benötigten Lade- und Entladeverlauf aber nicht selbst. Deshalb enthält das Downloadpaket zusätzlich die vollständige Beispiel-Rule Marstek_Kapazitaetstest_Beispiel.rules. Sie bildet den Ablauf meines ersten kontrollierten Tests nach.
- mit 1.500 W bis zum gemeldeten SOC von 100 Prozent laden
- 120 Minuten bei 100 Prozent halten, damit das BMS Zeit zum Balancieren erhält
- den Zwangsmodus beenden und zehn Sekunden vor dem Richtungswechsel warten
- mit 1.200 W bis 12 Prozent SOC entladen
- den Speicher stoppen und 60 Minuten in Ruhe beobachten
Die Rule arbeitet als Zustandsautomat und prüft alle fünf Sekunden die Modbus-Verbindung, minimale und maximale Zellspannung, Zellspreizung, Zell-, Innen- und MOS-Temperaturen sowie sämtliche eingebundenen Alarm- und Fehlerwörter. Sie bricht außerdem nach einem openHAB-Neustart, beim Neuladen der Rule, bei manueller Abschaltung und außerhalb des Zeitfensters von 07:00 bis 20:00 Uhr ab. Neue Läufe dürfen nur zwischen 07:00 und 12:00 Uhr gestartet werden.
Wichtig: Das ist eine Beispielkonfiguration aus meiner Installation und keine Herstellerfreigabe. Item-Namen, Zwangsmodi, Leistungsgrenzen, SOC-Grenzen und Sicherheitswerte müssen vor der Verwendung zum eigenen Gerät, zur Firmware und zur Modbus-Anbindung passen. Ein solcher tiefer Ladezyklus sollte nicht unbeaufsichtigt laufen.
Welche Steuer-Items die Rule erwartet
venus_modbus_zwangsmodus:0für Stopp,1für Laden und2für Entladenvenus_modbus_ladeleistung_sollundvenus_modbus_entladeleistung_soll: Sollleistung in Wattvenus_modbus_laden_bis_soc: oberes Ladeziel, hier 100 Prozentvenus_modbus_steuerung_aktiv: Freigabe der vorhandenen Modbus-Steuerungvenus_battery_test_activeundvenus_battery_test_status: Startschalter und lesbarer Phasenstatus
Zusätzlich verwendet die Rule dieselben SOC-, Zellspannungs-, Temperatur-, Verbindungs-, Alarm- und Fehler-Items wie das Analyse-Mapping. Die Datei Marstek_Kapazitaetstest_Beispiel.items enthält nur die beiden zusätzlichen Test-Items. Bereits vorhandene Items dürfen nicht doppelt angelegt werden.
Die Rule schreibt nicht selbst rohe Modbus-Register. Sie setzt die Steuer-Items der vorhandenen Marstek-RS485-/Modbus-Steuerung. Wer andere Item-Namen oder eine andere Schreiblogik verwendet, muss diese Befehle anpassen.
Andere Speicherregeln während des Tests sperren
PV-Überschussregeln, Akkupflege, Lade-Boost und andere Automationen dürfen während des Tests keine konkurrierenden Befehle senden. In meiner Installation prüfen diese Regeln deshalb vor ihrer Steuerlogik den Testschalter:
if (venus_battery_test_active.state == ON) {
return;
}Erst wenn diese Verriegelung eingerichtet und die Sicherheitsabschaltung geprüft ist, gehört die angepasste Beispiel-Rule nach conf/rules. Im Download liegt sie absichtlich nur als Vorlage und wird dadurch nicht automatisch von openHAB geladen.
Skript, Test-Rule und Marstek-Mapping herunterladen
PowerShell-Skript, Test-Rule, Mapping, README und MIT-Lizenz als ZIP herunterladen
Das ZIP enthält Analyze-OpenHABBattery.ps1, mapping.marstek-venus-example.json, die vollständige Marstek_Kapazitaetstest_Beispiel.rules, die beiden optionalen Test-Items, eine ausführliche README und die MIT-Lizenz. Im Mapping und in der Rule stehen die Item-Namen, mit denen die beschriebenen Messläufe durchgeführt und ausgewertet wurden. Zugangsdaten oder API-Token sind nicht enthalten.
Mapping an die eigene Installation anpassen
| Rolle | Beispiel-Item | Bedeutung |
|---|---|---|
soc | venus_battery_soc | Ladezustand in Prozent |
acPower | venus_battery_ac_power | AC-Leistung in Watt |
dcPower | venus_battey_dc_power | DC-Leistung in Watt |
batteryCurrent | venus_battery_current | Batteriestrom in Ampere |
cellVoltageMin/Max | venus_cell_voltage_min/max | kleinste und größte Zellspannung |
cellDeltaMv | venus_cell_voltage_delta | Zellspreizung in Millivolt |
alarms/faults | venus_*_status_word_* | Alarm- und Fehlerregister |
Die vier Rollen soc, acPower, dcPower und batteryCurrent sind erforderlich. Stimmen die Namen in der eigenen Installation nicht überein, werden nur die Werte rechts im JSON-Mapping ersetzt. Bei meinem Gerät sind Laden und Ladestrom positiv, Entladen negativ. Deshalb stehen dischargePowerMultiplier und dischargeCurrentMultiplier auf -1.
Analyse starten
Der API-Token wird nur für die aktuelle PowerShell-Sitzung als Umgebungsvariable gesetzt. Er gehört nicht in das Mapping und sollte auch nicht in gemeinsam genutzten Skripten stehen.
$env:OPENHAB_TOKEN = "mein-openhab-api-token"
.\Analyze-OpenHABBattery.ps1 `
-BaseUrl "http://openhab:8080" `
-MappingPath ".\mapping.marstek-venus-example.json" `
-Start "2026-10-13T07:20:00+02:00" `
-End "2026-10-13T15:15:00+02:00" `
-ServiceId "influxdb" `
-OutputDirectory ".\result-test-1" `
-ExportRawDataStart und Ende sind ISO-8601-Zeitstempel. Der UTC-Offset +02:00 gehört im Beispiel zur mitteleuropäischen Sommerzeit. Wer einen anderen Persistence-Dienst verwendet, ersetzt influxdb durch dessen Service-ID. Bei einer unverschlüsselten HTTP-Verbindung sollte sich openHAB ausschließlich in einem vertrauenswürdigen lokalen Netz befinden; extern ist HTTPS erforderlich.
Welche Dateien entstehen?
analysis-report.md: kompakter, direkt lesbarer Berichtanalysis-summary.csv: Kennzahlen für Tabellenkalkulation oder Supportanfrageanalysis.json: vollständiges Ergebnis für weitere automatische Verarbeitungraw/*.csv: optionale Rohdaten pro Messgröße bei gesetztem-ExportRawData
Ergebnis meines ersten Marstek-Testlaufs
| Kennzahl | Auswertung |
|---|---|
| SOC-Fenster | 100 bis 12 % |
| aktive Entladedauer | 165,81 Minuten |
| integrierte AC-Energie | 3,305 kWh |
| interner AC-Entladezähler | 3,330 kWh |
| integrierte DC-Energie | 3,829 kWh |
| entnommene Ladung | 73,80 Ah |
| hochgerechnete Vollkapazität | 4,352 kWh / 83,87 Ah |
| AC/DC-Wirkungsgrad | 86,3 % |
| maximale Zellspreizung | 211 mV |
| 95-Prozent-Perzentil der Zellspreizung | 82 mV |
| Zellspannungsbereich | 3,161 bis 3,605 V |
| höchste Zelltemperatur | 33,0 °C |
| höchste Innentemperatur | 45,9 °C |
| Alarm- oder Fehlerwort gesetzt | nein |
Die integrierten 3,305 kWh AC und die 3,330 kWh des internen Zählers liegen eng beieinander. Das ist eine gute Plausibilitätskontrolle. Die 3,829 kWh DC und 73,80 Ah zeigen dagegen unabhängig voneinander, dass im gemessenen SOC-Fenster weniger Ladung und Energie zur Verfügung standen als rechnerisch erwartet.
Die maximale Zellspreizung von 211 mV trat direkt am oberen Ladeende auf und sank nach der Ruhephase auf 67 mV. Ein solcher Spitzenwert ist daher für sich kein verlässlicher Defektnachweis. Am unteren Ende brach ebenfalls keine einzelne Zelle ein: Kurz vor dem Stopp bei 13 Prozent SOC und rund 1.200 W Entladeleistung lag die niedrigste Zellspannung bei etwa 3,164 V, die höchste bei rund 3,20 V und die Spreizung bei ungefähr 35 mV. Hauptbefund bleiben damit die reproduzierbar geringere DC-Energie und Ladungsmenge sowie der schnelle SOC-Anstieg. Marstek hat nach Prüfung der Daten einen Austausch des Speichers zugesagt.
So sollten die Zahlen bewertet werden
- Ein einzelner Test ist nur ein Hinweis. Ein zweiter Lauf unter möglichst gleichen Bedingungen prüft die Wiederholbarkeit.
- AC- und DC-Energie dürfen nicht verwechselt werden. Wechselrichterverluste erklären die Differenz zwischen beiden Seiten, aber keine zu geringe DC-Kapazität.
- Eine große Zellspreizung ist besonders am Lade- und Entladeende interessant. Der Verlauf ist aussagekräftiger als ein isolierter Messpunkt.
- Keine gesetzten Fehlerwörter bedeuten nicht automatisch, dass Kapazität und Zellbalance in Ordnung sind.
- Herstellergrenzen, Reserven und Messfehler müssen berücksichtigt werden. Die Daten sollten als dokumentierte Supportgrundlage dienen, nicht als eigenständige Sicherheitsfreigabe.
Fazit
Die openHAB-Persistence-API reicht aus, um einen Batteriespeicher reproduzierbar zu analysieren, ohne direkt auf InfluxDB zugreifen zu müssen. Entscheidend ist nicht ein einzelner Prozentwert in der App, sondern das gemeinsame Bild aus Energie, Ah, SOC-Verlauf, Zellspannungen, Temperaturen und Diagnosewörtern.
In meinem Fall zeigte die App keinen Fehler. Erst die historische Auswertung machte die Abweichung belastbar sichtbar und lieferte die Datengrundlage für die Supportanfrage. Das Skript soll genau diese Lücke schließen und die Prüfung mit eigenen openHAB-Items nachvollziehbar machen.
Eine Antwort auf „Marstek-Speicher mit openHAB prüfen: Kapazität und Zellwerte automatisch auswerten“