Marstek Venus A – Erfahrungen & Modbus-Tools

Warum uns das wichtig ist – eine kurze Geschichte: Der erste Akku wurde über die API gesteuert. Nach etwa drei Wochen mit ständigen Problemen ging er irgendwann gar nicht mehr an: Man konnte ihn einschalten, die grüne Power-LED leuchtete, aber die LEDs auf der Frontleiste blieben aus. Auch per App war er nicht mehr erreichbar. Erst nach langem Nachhaken und vielen Diskussionen mit dem Support wurde das Gerät getauscht. Auch hier vermuten wir im Nachhinein die API als Ursache – gesichert ist das nicht, aber es passt genau ins Bild der Aussetzer und Fehlfunktionen von oben.

Das Ersatzgerät wird von Anfang an ausschließlich per Modbus angesteuert (API deaktiviert) – und läuft seitdem problemlos.

Die Modbus-TCP-Implementierung des Akkus weicht vom Standard ab. Mit keinem der getesteten fertigen Modbus-Programme kam eine funktionierende Verbindung zustande. Erst eigene, minimalistische Python-Scripts (modbus.py/modbus_w.py) haben zuverlässig funktioniert.

Was den Unterschied macht, lässt sich direkt am Code der Scripts ablesen – sie sprechen bewusst „unsauberes" Modbus TCP:

• Es wird kein fertiges Modbus-Framework verwendet, sondern ein rohes TCP-Socket. Der 7-Byte-Header (Transaction ID, Protocol ID, Length, Unit ID) wird von Hand zusammengebaut.
• Die Antwort wird nicht anhand der Längenangabe im Header geparst, sondern anhand fester Byte-Positionen (Function-Code-Byte, Datenbytes) – die Length-Angabe im Header wird schlicht ignoriert, statt als Prüfkriterium zu dienen.
• Ein Code-Kommentar in modbus.py dokumentiert explizit einen Firmware-Bug: Bei Fehler-/Exception-Antworten schickt der Akku eine falsche Längenangabe im Header (4 statt der korrekten 3) – die Scripts werten die Antwort trotzdem aus, statt sie deswegen zu verwerfen.
• Die Registernummern (z. B. 42010, 30001) werden unverändert als Protokolladresse übertragen, ohne die in der Modbus-Welt verbreitete Offset-Konvention (z. B. „40001 abziehen") anzuwenden.

Genau das war der Punkt, an dem fertige Modbus-Programme gescheitert sind – sie halten sich strikt an die Spezifikation und geben bei diesen Abweichungen auf. Die eigenen Scripts sind bewusst genau an diesen Stellen toleranter gebaut, und funktionieren dadurch zuverlässig.

Work Mode kann Steuerbefehle stillschweigend blockieren. Steht Register 43000 nicht auf 0 (Manual) – z. B. auf 1 (Anti-Feed), Werkseinstellung bei neuen Geräten – werden Schreibbefehle auf 42010/42020/42021 vom Gerät ignoriert. Der Modbus-Write selbst meldet trotzdem Erfolg (Echo kommt zurück), nur der Akku reagiert nicht.

42000 und 43000 setzen sich beim Schreiben gegenseitig zurück (bestätigter, deterministischer Effekt, kein Timing-Problem). Schreiben von 43000 wirft 42000 zuverlässig wieder auf „aus“ (21947) zurück – und umgekehrt. Das zuletzt geschriebene Register „gewinnt“, das andere kippt garantiert um, ohne dass der Write das meldet.

Funktionierende Reihenfolge nach einem Neustart – 42000 muss der allerletzte Write sein:

43000 = 0       # Work Mode Manual (falls gewünscht)
42000 = 21930   # RS485-Kontrolle – MUSS zuletzt vor 42010/42020 stehen
42010 = 1/2     # Force Mode Laden/Entladen
42020/42021     # Leistung setzen

42010/42020/42021 setzen 42000 nicht zurück – sie können also gefahrlos danach folgen.

Diese Prozedur muss nach jedem Neustart des Akkus erneut durchlaufen werden. Ist das Gerät aber einmal im richtigen Modus (42000 aktiv), scheint es Schreibbefehle bis zum nächsten Neustart zuverlässig anzunehmen – ohne dass man die Register zwischendurch nochmal anfassen muss.

Nicht zu häufig abfragen. Wird der Akku zu dicht getaktet mit Modbus-Anfragen „bombardiert“, kommt es zu fehlerhaften bzw. unvollständigen Rückmeldungen. Ein Poll-Intervall von einigen Sekunden (z. B. alle 3–5 s ein Register) ist unproblematisch – mehr sollte man dem Gerät nicht zumuten. Zwischen mehreren Register-Reads hintereinander lohnt sich zusätzlich eine kurze Pause (in unserem Dauerbetrieb bewährt: 3 s).

Sich nicht darauf verlassen, dass jede einzelne Abfrage klappt. Auch bei moderater Abfragefrequenz schlägt gelegentlich ein Read oder Write fehl (Timeout, leere/unvollständige Antwort). Eigener Code sollte das einplanen – also Fehler abfangen, ggf. mit Retry, und nicht bei einem einzelnen Fehlschlag den letzten bekannten Wert verwerfen oder einen Steuerbefehl als endgültig gescheitert werten.

Nutzung auf eigene Verantwortung. Insbesondere modbus_w.py schreibt direkt in Steuerregister des Akkus (Force Mode, Lade-/Entladeleistung). Bei falscher Anwendung – z. B. Schreiben unerwarteter Werte in unbekannte Register – ist eine Fehlfunktion oder Beschädigung des Geräts nicht auszuschließen. Wir übernehmen keine Haftung für Schäden am Akku, angeschlossenen Geräten oder sonstige Folgeschäden durch die Nutzung dieser Scripts. Vor Schreibzugriffen immer erst mit Lesebefehlen (modbus.py) vertraut machen und Werte im Zweifel gegen die Register-Tabellen oben prüfen.