Hat jemand Erfahrung mit der Modbus-Ansteuerung eines Fronius Symo Gen 24 Hybridwechselrichters?
Ich habe in OpenEMS einen Controller geschrieben, der die Lade-/Entladeleistung via Modbus/Sunspec Model 124 erfolgreich vorgibt und der Wechselrichter stellt diese Leistung auch tatsächlich ein. Das Problem scheint allerdings zu sein, dass der im WR eingebaute Standard-Regelmechanismus zur Optimierung des Eigenverbrauchs sich nicht abschalten lässt, damit parallel weiterläuft und gegen meine Modbus-Werte arbeitet. Das führt im Verhalten dazu, dass der WR oft hin und herschwingt zwischen meinen Werten, die über Modbus vorgegeben werden und jenen Werten, die der WR intern bestimmt.
Hat jemand dieses Verhalten schon beobachtet und gibt es dafür eine Lösung oder ein Register über das ich den Standard-Regler deaktivieren kann?
Hallo Thomas,
wir haben uns vor einigen Monaten mit dem Fronius Symo GEN 24 beschäftigt, die Arbeit dann aber frustriert zur Seite gelegt. Meiner Meinung nach und soweit ich mich erinnere hat die Fronius interne Implementierung einen Bug beim Null-Durchgang. Also in dem Moment wo ich von Laden- auf Entladen umschalte (oder umgekehrt). In diesem Moment hat der Fronius keine Vorgaben mehr akzeptiert. Ich könnte mir vorstellen, dass du auf das gleiche Problem gestossen bist (und dein Wechselrichter dann in die Eigenregelung übergegangen ist. Ich habe unseren Treiber gerade als PullRequest gestellt → Feature/fronius.gen24 by clehne · Pull Request #2150 · OpenEMS/openems · GitHub
Der Fronius GEN24 benötigt das Sunspec S160 Modell. Dieses wird derzeit nicht von OpenEMS zur Verfügung gestellt. Im PullRequest Feature/default sunspec update and enhancement by clehne · Pull Request #2149 · OpenEMS/openems · GitHub findest du das S160 Modell.
Neben dem Bug in der Ansteuerung (weitere Hinweise dazu findest du in der Implementierung) werden auch die PV-Werte durch teilweise systematische Messartefakte überlagert . Auch glaube ich, dass der Entwickler des GEN24 unerfahren im Umgang mitt dem Sunspec-Protokoll ist. Hier werden einige Register wahllos zweckentfremdet. Meiner Meinung nach ist der Fronius Symo GEN24 mit dem aktuellen Softwarestand nicht für eine Regelung mit OpenEMS benutzbar.
So ein System lässt sich leider nachträglich nicht so einfach austauschen. Wenn du einen speziellen Controller schreiben würde, der bei jedem Nulldurchgang (Änderung von Laden auf Entladen und umgekehrt) 10-20s wartet bevor der Controller den nächsten Regelvorgang einleitet, dann kann es funktionieren. Für die private Nutzung und für die Eigenverbrauchsoptimierung in Kombination mit dem Laden eines Autos oder eine Wärmepumpe kann man sich so sicher eine einigermaßen Regelung aufbauen.
Allen anderen möchte ich davon abraten derzeit OpenEMS in Kombination mit Fronius Symo GEN24 zu nutzen. Vielleicht kannst du auch den Fronius Support auf das Problem aufmerksam machen.
Hallo Christian,
danke für die PRs. Warst du dazu mit Fronius in Kontakt? Es könnte durchaus sein, dass die da aktiv eine Sperre beim Wechsel zwischen Be- und Entladung eingebaut haben. Besser als Reverse Engineering wäre aber eine konkrete Aussage dazu.
Für OpenEMS (bzw. den “Ess.Power”-Solver) ist es immer wichtig, dass das Gerät richtig modelliert ist, d.h., dass der Solver weiß, was zum entsprechenden Zeitpunkt gerade möglich ist. Damit kann man auch so eine 10-sekündige Sperre modellieren. Ein Beispiel für was ähnliches: openems/BpEssImpl.java at develop · OpenEMS/openems · GitHub
Noch eleganter, aber auch aufwendiger zu entwickeln, wäre ein “SMART-Mode”, wie wir das beim GoodWe für den FENECON Home umgesetzt haben (openems/ControlMode.java at develop · OpenEMS/openems · GitHub). Der SMART-Mode nutzt in den meisten Fällen den internen Regelmodus (der vermutlich schneller ist als über Modbus und kein Problem mit Be-/Entladewechseln hat) und nur bei einer externen Übersteuerung greift OpenEMS ein. Das klappt sehr gut z. B. für einen Netzdienliche-Beladung-Controller etc. weil die ja nicht so häufig die Leistungsvorgabe ändern.
Gruß,
Stefan
Hallo Stefan,
es ging um eine zeitkritische Umsetzung und das Fronius Gerät wurde daher damals zeitnah durch ein anderes Gerät ausgetauscht. Wir haben daher auch keinen Kontakt mehr zu Fronius aufgenommen.
Die Fronius Modbus-Tabelle war nur bedingt hiflreich. Die Implementierung beruht daher tatsächlich vorwiegend auf Reverse-Engineering.
Danke für den Hinweis auf die Constraints. PowerRamp-Constraints, das ist bisher wieder mal völlig an mir vorbeigegangen. Das werden wir uns genauer anschauen. Erwähnte ich schon einmal wie großartig ich OpenEMS finde ;-).
Den SMART-Mode kannte ich auch noch nicht. Eine gute Idee und eine elegante Möglichkeit um das Einschwingverhalten zu minimieren. Etwas das uns leider auch täglich begegnet.
VG, Christian
Vielen Dank für Eure Rückmeldungen! Ich habe etwas herumgefragt. Es scheint wohl feste Strategie von Fronius zu sein, die Algorithmik in Richtung Eigenbedarfsoptimierung auszulegen und nichts Anderes zuzulassen. Schade, dass man hier offenbar das Sunspec-Interface so einseitig auslegt.
LG Thomas