Marstek Modbus Suite 3.0.1 und 3.1-Beta: Ladeprognose und Registerprüfung

Nach 3.0.0 ging es bei der Marstek Modbus Suite in drei Richtungen weiter: eine Korrektur für Neustarts, eine neue Prognose für „Zeit bis voll“ und eine Prüfung der Registerkarten von Venus D, A und E v3 gegen die jeweilige Firmware. Das Letzte ist als 3.1.0-beta.3 erschienen und umfangreich genug, dass es hier einen eigenen Überblick bekommt. Stabil ist weiterhin 3.0.1; die 3.1.0-Betas sind Vorabversionen, die man in HACS ausdrücklich aktivieren muss.

3.0.1: Wenn der Speicher beim Start nicht erreichbar war

Die Venus ist beim Laden der Integration nicht immer erreichbar, zum Beispiel beim Neustart nach einem Firmware-Update der Steuerung. Dann konnte das Setup von Home Assistants eigenem Timeout auf halbem Weg abgebrochen werden. Die Plattformen, die sich schon registriert hatten, wurden dabei nicht wieder entladen. Jeder weitere Versuch scheiterte dann auf allen Plattformen mit ... has already been setup!. Der Eintrag blieb geladen, aber ohne je abzufragen: Der Verbindungssensor stand auf aus, null Leseversuche, alle Entitäten unknown, obwohl der Speicher längst wieder antwortete. Nur ein manuelles Neuladen half. Fehlgeschlagene Setups werden jetzt vollständig aufgeräumt, auch Abbrüche, und der nächste Versuch beginnt sauber.

Zeit bis voll in der Reihenfolge des BMS

Bis 3.0.1 teilte runtime_to_full die fehlende Energie durch die aktuelle Leistung. Auf einer Venus A oder D schwankt das über die ganze Ladung zwischen viel zu kurz und viel zu lang, weil der Speicher seine Packs nicht gemeinsam lädt. So geht das BMS vor:

• Es lädt immer ein Pack zur Zeit, das leerste zuerst, bis zur nächsten vollen Zehnerstufe, und wechselt dann zum nächstleeren.
• Oberhalb von 90 Prozent regelt es die Leistung pro Pack zweimal herunter. Auf einer Venus D mit sieben Packs nahm der Speicher von 90 bis 95 Prozent etwa 1250 W und von 95 bis 100 Prozent etwa 490 W auf, Pack für Pack.
• Die oberste Stufe braucht viel weniger Energie, als ihre fünf Prozent vermuten lassen, denn das BMS erklärt ein Pack früh für voll.

Der Sensor spielt diese Reihenfolge jetzt durch. Für jeden Schritt gilt der kleinere von zwei Werten: die verfügbare Leistung oder die Grenze, die das BMS erlaubt. Bei einer erzwungenen Ladung zählt der Sollwert als verfügbare Leistung, sonst die gemessene Leistung. Die Grenzen und die tatsächliche Energie der beiden obersten Stufen werden je BMS-Firmwareversion gelernt und beim Wechsel der Steuerungsfirmware verworfen. Solange der Speicher jede Stufe noch nicht erlebt hat, rechnet die Prognose mit den Werten, die an der Venus D gemessen wurden. Sie wird also nach einigen Ladungen auf 100 Prozent genauer.

Neu sind dafür bms_charge_current_limit (Register 32106, der Ladestrom, den das BMS gerade annimmt; er liest 0, sobald das aktive Pack voll ist) und bms_charge_power_limit (BMS-Spannung mal dieser Strom), beide auf A und D. An runtime_to_full hängen die Attribute hours_to_90 und hours_to_95, die das Panel als zwei Marken unter dem Countdown zeigt. Gemessen und getestet ist das an einer Venus D mit sieben Packs. Die Venus A hat dieselbe Firmware-Basis und sollte sich genauso verhalten, ist aber nicht an einer A verifiziert; hier sind Rückmeldungen besonders willkommen. Bei Venus E v3 und E v1/v2 gibt es ein einziges Pack und damit keine Reihenfolge, es ändert sich wenig.

3.1.0-beta.3: Drei Registerkarten gegen die Firmware

Die Registerkarte der Venus D wurde gegen die Firmware der Steuerung (147 bis 151), des Wechselrichters (115, 116) und des BMS (117.7, 118) geprüft; die Venus A gegen Steuerung 1509, Wechselrichter/MPPT 1211 und BMS 1105; die Venus E v3 gegen Steuerung 151, Wechselrichter 119 und BMS 115. Wie schon bei 3.0 gilt: Wo Karte und Firmware sich widersprechen, gewinnt die Firmware.

Umbenennungen ohne Verlust

Fünf Messwerte der Venus D trugen einen Namen, der etwas anderes beschrieb, ebenso auf der Venus A; bei der Venus E v3 sind es vier. Schlüssel und Name ändern sich, aber die Registry-Einträge werden beim Start auf den neuen Schlüssel verschoben. Entität, Entity-ID, Verlauf und Anpassungen bleiben, nur der angezeigte Name ändert sich.

• device_name heißt device_model (fester Modelltext wie VNSD-0, kein Name).
• vms_version heißt vns_version, „VMS“ war ein Tippfehler für VNS (Wechselrichter-Firmware).
• battery_total_energy heißt battery_rated_capacity: die Nennkapazität (Packs × 2560 Wh bei der D, × 2080 Wh bei der A, konstant 5,12 kWh bei der E v3), nicht gespeicherte Energie.
• min_cell_temperature heißt battery_1_min_cell_temperature, weil es nur das Minimum von Pack 1 ist. Auf der E v3 behalten Minimum und Maximum ihre Namen, dort sind sie bei einem Pack ein stimmiges Paar.
• schedule_N_mode heißt schedule_N_power: die Leistung des Slots in Watt (plus entladen, minus laden, −1 Eigenverbrauch), kein Modus.

Eine Änderung greift in Automationen ein: Die Option trade_mode von user_work_mode heißt jetzt ai, nach der Bezeichnung der Firmware („AI-Modus“). Wer auf Venus D, A oder E v3 trade_mode auswählt, muss das anpassen.

Korrigiert und entfernt

Die 42 Pack-Temperaturen (Umgebung, MOSFET und Zell-NTC 1 bis 4 jedes Packs) wurden vorzeichenlos gelesen, ein Wert unter 0 °C erschien als etwa 6553 °C. Sie sind jetzt vorzeichenbehaftet. Schutzwörter werden als Bitmaske gelesen und in Attribute dekodiert, battery_N_mos_status zeigt, welche MOSFETs leiten, und mehrere Zustandssensoren zeigen Text und behalten die Zahl als Attribut raw_value.

Entfernt sind alarm_status, alarm_status_low und fault_status_2 samt Beschreibung auf der Venus D, weil die Firmware diese Wörter dort nie schreibt, sie lesen immer 0. Der alte factory_reset-Knopf schrieb nach 41001, was die Venus D gar nicht implementiert; er tat nichts. Die Entitäten bestehender Installationen bleiben als „nicht mehr bereitgestellt“ zurück und können gelöscht werden.

Für die Grenzwerte gibt es neue Untergrenzen: charge_to_soc ab 13 Prozent (die Firmware lehnt 10 bis 12 ab), max_charge_power und max_discharge_power ab 50 W, nie 0. Der Wechselrichter speichert den Wert im EEPROM und lädt ihn nach jedem Neustart ohne Bereichsprüfung, eine 0 blockiert Laden oder Entladen also dauerhaft, auch über einen Neustart. Das Register selbst liest nach jedem Neustart 0, bis es neu geschrieben wird, daher kann eine Entität „blockiert“ nicht von „unbekannt“ unterscheiden, und eine vergessene 0 sieht wie ein defekter Speicher aus. Jedes Schreiben belastet außerdem das EEPROM zweier Controller. Zum Stoppen eignen sich force_mode auf Standby (im RS485-Steuermodus) oder ein Sollwert beziehungsweise Zeitplan-Slot mit 0, denn diese sind flüchtig.

Knöpfe, ein WLAN-Dienst und Register, die man nicht im Block liest

Neue Tasten, alle standardmäßig deaktiviert: der echte Werksreset (41000 = 0xAA11, setzt Steuerung, Wechselrichter und alle Packs zurück, löscht WLAN- und Cloud-Einstellungen und startet neu), led_test, inverter_eeprom_test, read_inverter_input_pb1 und pack_coding (die „Battery Pack Recovery“ der App, die nur mit genau zwei Packs gelingt). Werksreset und Pack-Coding brauchen einen zweiten Druck innerhalb von 15 Sekunden; der erste zeigt nur die Warnung.

Der Dienst marstek_modbus.set_wifi(ssid, password) ist optional und aus, solange DEV-Register anzeigen nicht eingeschaltet ist. Er schreibt die WLAN-Zugangsdaten des Kommunikationsmoduls über 41500–41631 und prüft vorher alles (SSID 1 bis 31 Zeichen, Passwort leer oder 8 bis 31 Zeichen, druckbares ASCII ohne , und "). Das Passwort wird weder zurückgelesen noch von der Integration geloggt. Das Panel sendet über einen eigenen Websocket-Befehl, den Home Assistant nicht aufzeichnet; ein Aufruf des Dienstes selbst landet dagegen als call_service-Ereignis samt Passwort in der Recorder-Datenbank. Die Warnung dazu ist ernst: Die Firmware speichert die Zugangsdaten in einem EEPROM-Bereich (0x420–0x45F), der sich mit der Adresse 0x441 überschneidet, ein Firmware-Fehler. Ein falscher oder abgebrochener Schreibvorgang kann das Modul mit falschen Zugangsdaten zurücklassen, der Dienst taugt also nur, wenn der Speicher noch auf anderem Weg erreichbar ist. Einzelheiten stehen in docs/set-wifi.md.

Manche Register der Venus D tun etwas, wenn man sie liest. Ein Lesezugriff irgendwo in 38000–39014 lässt die Steuerung bis zum nächsten Neustart vier CAN-Frames pro Sekunde senden, ein Lesezugriff auf 45603–45605 blockiert ihre Modbus-Task für bis zu 200 Ticks. Diese Bereiche und einige weitere (in d.yaml aufgelistet) werden nie in einen Blockzugriff aufgenommen und nie überbrückt: Ein Register dort wird nur einzeln gelesen, und nur, wenn seine Entität eingeschaltet ist. Was bewusst gar nicht angeboten wird, steht jetzt auf einer eigenen Seite, docs/not-offered-registers.md: Werks- und Testmodi, der OTA/Shell-Schalter, Aliase und der Wert 0 für die maximale Lade- und Entladeleistung.

Modellspezifisches

Auf der Venus A zeigen mppt_warning (37024) und mppt_error (37023) jetzt, was der Code bedeutet, gelesen aus der Firmware des Wechselrichter-Mikrocontrollers, in dem die MPPT-Stufe der A sitzt. 1367 ist „MPPT-Chip über 85 °C“, 1363 bedeutet, dass die Leistungsreduzierung zwischen 73 und 90 °C aktiv ist, 1126 ist ein Überstromauslöser an PV1. Die Venus E v3 hat ein festes Pack und keine PV-Stufe: Das BMS sendet nur Pack 1 mit 16 Zellen, deshalb gibt es keine Entitäten für Packs 2 bis 7. Sie bekommt dafür die Reiter „Zellen“ und „Packs“ für dieses eine Pack, die in der Standardeinstellung deaktivierten Entitäten sind im Reiter vermerkt, statt leere Kästen zu zeigen.

Start und Lesen

Das Setup wartet nicht mehr auf den ersten Abfragezyklus. Home Assistant hielt beim Start bisher an, bis die Integration jeden Wert einmal gelesen hatte: bei einem langsamen Speicher oder hinter einem Proxy Dutzende Sekunden, im Feld wurden etwa 90 gesehen, und das hielt den gesamten Start und jede Automation auf. Der Eintrag lädt jetzt in deutlich unter einer Sekunde; Verbinden und der erste Zyklus laufen im Hintergrund, die schnelle Gruppe (Ladezustand, Leistung, Netz) zuerst. Ein beim Start nicht erreichbarer Speicher versetzt den Eintrag nicht mehr in einen Setup-Retry: Er lädt, die Entitäten bleiben nicht verfügbar, und die Verbindung wird beim nächsten Zyklus und dann jede Minute neu versucht.

Beim Lesen gilt: Ein einzelnes mit Ausnahme 2 (ungültige Datenadresse) abgelehntes Register wird nicht erneut angefragt, vorher kostete das drei Anfragen und zwei Reconnects. Lücken zwischen Registern lernt der Blockleser nur noch aus dieser Ausnahme; „busy“ (6) oder „device failure“ (4) sagen etwas über den Moment, nicht über die Register. Die Verbindung wird nach einem sauber abgelehnten Block nicht mehr neu aufgebaut.

Panel

Fehler- und Warncodes erscheinen nicht mehr mit Tausenderpunkt: 1367 las sich als „1.367“, ein Fehlerwort 1024 als „1.024“. Das Panel spricht jetzt auch Niederländisch. Der Wartungsbereich ganz unten im Reiter System ist eingeklappt und als Gefahrenzone gezeichnet. Er listet jede eingeschaltete Befehlstaste, und eine Taste mit Zwei-Schritt-Bestätigung zeigt die Warnung in einem Dialog mit Countdown und wird nur gesendet, wenn man innerhalb der 15 Sekunden bestätigt. Das Panel drückt über einen eigenen Websocket-Befehl (marstek_modbus/press_button), der nur Administratoren offensteht; das schließt eine Lücke, denn bisher stand button.press jedem Benutzer offen. Ein Nutzer ohne Administratorrechte sieht Panel und Reiter weiterhin, aber Befehlstasten und das WLAN-Formular sind deaktiviert, mit einem Hinweis darauf. Der Banner im System-Reiter nennt einen gesetzten Fehler im Klartext. Ist das BMS gesperrt oder der BMS-Werksmodus aktiv, erscheint eine Warnung, und bei der Venus E v3, die auf die Netzfreigabe wartet, ein Hinweis statt eines roten Fehlers.

Zum Ausprobieren

Die 3.1.0-Betas erscheinen in HACS nur, wenn Beta-Versionen für das Repository aktiviert sind. Nach dem Update gilt wie sonst: Home Assistant komplett neu starten und offene Panel-Tabs neu laden. Wer den Stand von 3.0.1 behalten will, bleibt einfach auf der stabilen Version. Für die Ladeprognose helfen Rückmeldungen mit Modell, Packzahl, BMS-Version und dem Verlauf von runtime_to_full einschließlich hours_to_90 und hours_to_95.