evcc Modbus-Ausfallsicherheit mit Huawei

[CiNcH83]

Ich habe mir mal die Mühe gemacht und die Ausfallsicherheit von evcc in Hinblick auf Modbus (vor allem die Batteriesteuerung) evaluiert und möchte die Ergebnisse mit euch teilen und ggfs. diskutieren.

Huawei-Anlagen sind bekannt dafür, dass Modbus nicht immer unter allen Gegebenheiten stabil funktioniert. Meine Anlage ist mit nur einem Wechselrichter (+Batterie und Smart Power Sensor) und ohne Parallelzugriffe (z.B. über Home Assistant) sehr einfach gestrickt. Ich werde auch keine Tests mit parallelen Instanzen machen, zumal ich es aus regulatorischer Sicht in Hinblick auf § 14a EnWG/§ 9 EEG schwierig sehe, wenn da ein Home Assistant auf die Anlage eindrischt (und u.U. sogar Register schreibt). Ich bin aber bereit, jeden zu unterstützen, der hier Probleme hat und konstruktiv mitarbeiten will.

Seit ich den schnelleren Dongle habe, sind die Antwortzeiten sehr gering und ich konnte keine Timeouts im Normalbetrieb mehr verzeichnen. Allerdings weiß ich um die Probleme sehr wohl Bescheid, zumal ich vor Jahren schon die gesamte Anlage in Solaranzeige mit dem langsamen Dongle mittels Einzelabfragen ausgelesen habe. Da konnte es zu Aussetzern von mehreren Sekunden (>10) kommen, mutmaßlich dann, wenn der Dongle parallel mit der Cloud (Daten-Upload in das FusionSolar-Portal) kommuniziert hat.

Periodisches Lesen von Registern - Ströme/Spannungen/SoC- und Energiewerte

Hier sehe ich keine großen Probleme. evcc verwendet einen Retry-Mechanismus mit exponentiellem Backoff. 10s lang wird mehrfach probiert, die entsprechenden Datenpunkte auszulesen. Und wenn mal ein Zyklus ausfällt, ist es auch nicht so schlimm.

Schreiben von Registern - Dim/Curtail/Battery Mode

Hier ist es natürlich deutlich ungünstiger, wenn man in einem restriktiven Batteriemodus oder der Leistungsreduzierung stecken bleibt. Es gibt zwar keinen direkten Retry, wenn allerdings ein Schreibvorgang fehlschlägt, verbleibt man erstmal im alten Zustand/Modus und es wird im nächsten Zyklus erneut versucht, den neuen Zustand/Modus herzustellen, indem die entsprechenden Register erneut geschrieben werden.

Natürlich kann es immer mal passieren, dass evcc Mist macht. Dem sollte man dann nachgehen und das entsprechende Verhalten korrigieren (siehe z.B. #25179). Erst wenn sich die Anlage intern verhaspelt und nach außen vorgibt, alles korrekt gemacht zu haben, hat man ein Problem. Auch das ist nicht auszuschließen. Das ist dann aber wahrscheinlich ein Zeichen dafür, dass man die Anlage außerhalb ihrer Wohlfühlzone betreibt, was mit Modbus-Proxy und parallelen Abfrage- und Steuerungsinstanzen evtl. der Fall sein kann. Aber auch hier habe ich bislang noch keine entsprechende Evidenz zu Gesicht bekommen.

Testen

Batterie-Modi kann man sehr einfach von außen über das evcc REST-API durchschalten. hold und charge müssen periodisch (z.B. alle 30s) neu gesetzt werden (Watchdog). Sonst fällt evcc in den normal zurück (die Register werden allerdings nur dann periodisch neu geschrieben, wenn die Modi auch "nach unten" in Richtung Hardware via Watchdog implementiert sind). Hier ein paar einfache Shell-Kommandos (via curl-Programm) zum Setzen der Modi...

normal:
curl -X 'POST' 'http://localhost:7070/api/batterymode/normal' -H 'accept: application/json' -d ''

hold:
while true; do curl -X 'POST' 'http://localhost:7070/api/batterymode/hold' -H 'accept: application/json' -d ''; sleep 30; done

charge:
while true; do curl -X 'POST' 'http://localhost:7070/api/batterymode/charge' -H 'accept: application/json' -d ''; sleep 30; done

ACHTUNG! Man kann die geänderten Einstellung zwar im FusionSolar-Portal prüfen (nur mit Installer-Rechten), jedoch werden diese dort u.U. nicht sofort reflektiert.

Optimierungsmöglichkeiten

Mit dem langsamen Dongle habe ich mit der Erhöhung der Baudrate von 9.600 auf 19.200 Baud gute Ergebnisse erzielen können (siehe #22708). Allerdings würde ich es da trotzdem tunlichst vermeiden, mit parallelen Instanzen auf den Dongle zuzugreifen.

@toeklk hat für das AA55-Plugin einen Block-Abfrage-Mechanismus entwickelt (siehe #29095). Diesen Mechanismus könnte man auch für Modbus übernehmen und so die Anzahl Abfragen reduzieren. Für das Auslesen der Ströme/Spannungen/SoC- und Energiewerte habe ich 5 sinnvolle Blöcke identifiziert und würde so von 12 auf 5 Abfragen kommen. Größere Blöcke machen IMHO keinen Sinn.

/cc @mucki12 @TRON4R

[CiNcH83]

Ich habe jetzt mal mit modbus-cli etwas die Response-Zeiten aller von evcc gelesenen Register gemessen. Ströme/Spannungen/Energie- und SOC Werte dauern ca. 5 ms. Einziger Ausreißer ist das neu eingeführte Register 47415 (Active Power Control Modus) für Curtailment/§ 9 EEG. Da dauert die Antwort mehrere Hundert Millisekunden. Wenn man etwas Verkehr auf den Modbus bringt (Wechselrichter-Konfiguration über die FusionSolar-Cloud), geht die Zeit dann auch gleich mal durch die Decke (=Timeout).

Dann habe ich von Modbus TCP auf Modbus RTU (Baudrate 19.200) umgestellt. Jetzt dauert jedes Register (inkl. 47415) ca. 30 ms. Über den Dongle gibt es also durchaus unterschiedliche Registerklassen mit unterschiedlichen Zykluszeiten. Da jetzt die Cloud abgehängt ist, bekommt man das auch nicht mehr gestört.

[CiNcH83]

Zum Rest sind wir unterschiedlicher Meinung. Hier muss dann wohl jemand einspringen, der die Probleme nachstellen kann, solange ich das nicht kann.

OK. Lass es mich anders ausdrücken... ich bin gerne bereit, da weiter zu unterstützen. Ich teste auch immer noch intensiv die Stabilität, bzw. ob ich mich auch in die Situation manövrieren kann. Ich weiß schon sehr gut, wo die Grenzen liegen. Ich kann auch den 004 recht leicht in den Timeout-Wahnsinn treiben. Mit Bauchgefühl kommen wir nicht weiter.

Um die ganze Sache näher zu betrachten, wäre halt ein Log schön gewesen. Schade, dass du nicht noch schnell über das evcc Log UI den Trace-Log exportiert hast. Noch schöner wäre natürlich ein Trace-Log (via File-Logging), wo man auch sieht, wo es bricht und nicht nur den verkürzten Trace-Ring aus dem UI heraus.

Ich habe jetzt nochmal etwas den Code von evcc mit modbusproxy (du verwendest doch den Proxy von evcc?) und huawei_solar bzw. der huawei-solar-lib analysiert. Im Grunde sind beide sehr vernünftig/konservativ. Die schicken nicht mehrere Requests auf die Reise sondern immer nur einen und warten erst auf die Antwort, bevor sie den nächsten Request absetzen. Man könnte für das Huawei-Template noch einen Delay (z.B. 50 ms) einfügen (mit dem neuen Block-Read-Mechanismus gibt es allerdings nicht mehr allzu viele Requests), um die Requests noch etwas zu entzerren. Dieser Delay gilt aber nicht für die Requests über Proxy. D.h. ein HA Request folgt sofort auf einen evcc-Request. Dafür könnte man den mbproxy nehmen.

Was man also noch probieren könnte:

• Modbus Register-Blöcke lesen (bereits im Master drin)
• Delay-Parameter in Huawei Template einführen
• Requests von evcc und HA weiter mit mbproxy entzerren (auch der arbeitet strikt synchron)
• Intervall in HA erhöhen
• Re-connect im Fehlerfall

In Zukunft kommen wir nicht drum herum, den neuen Mechanismus ab 0.306 zu verwenden. Hier sind bereits die Vorbereitungen zu holdcharge. Es wird dann also hold, holdcharge und holddischarge geben. Und die kann man eben über den Watchdog Ansatz nicht abbilden. Deshalb gibt es nur eine Richtung und die ist nach vorne...

[CiNcH83]

Ich habe jetzt insgesamt schon 160 Mal in den hold und zurück geschalten, siehe Test-Plan. Ist es u.U. möglich, dass das Schreiben dieser Register fehlschlägt, wenn der Speicher bzw. die Anlage im Standby ist? Und wenn evcc es dann permanent wieder versucht, der SUN2000 irgendwann die Latschen streckt?

Ich müsste das leer fahren des Speichers momentan erzwingen, um den Standby testen zu können...

[CiNcH83]

Macht aber auch keinen Sinn. Wenn der in den hold geht, fährt er ja nicht leer und geht daher nicht in den Standby!?

[CiNcH83]

Hier ein paar Worte zu mbproxy.

[TRON4R]

Meine LUNA war ganz sicher nicht im Standby. Und mein Master-WR, an dem die LUNA hängt und der SDongle hängt, geht eigentlich auch nie in den Standby. Nur der Slave macht das.