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
Hallo zusammen,
habt Ihr schonmal in den Einstellungen folgendes gechekt?
Hab ich gerade gefunden !
Die Register sind doch auch öffentlich?
Hi @Sn0w3y @ThomasBerndorfer ,
gibt es hier ein Update? Sind die Schnittstellen mittlerweile verbessert worden? Ich habe ebenfalls den Gen24 10 und will diesen mit der BYD HVM ins OpenEMS einbinden.
Danke und Grüße
Raphael
Hallo Christian, ich habe mir Deinen Code für den Gen24 mal aus dem PR geholt und bei mir eingepflegt, da ich derzeit testweise openEMS gegen eine Anlage mit Fronius Gen25 und BYD-Speicher laufen lasse. Das von dir beschriebene Verhalten sehe ich auch mit der aktuellen Fronius Firmware, was für mich derzeit aber nicht Priorität hat. Vielmehr beobachte ich, dass die Lade- bzw. Entladeleistungen nicht aufsummiert werden. Aufladen des Speichers wird als Verbrauch gewertet. Fehlt in der Umsetzung für den Gen24 noch etwas oder mache ich was falsch?
Danke im Voraus
Hans
Hallo Hans,
der Fronius GEN24 ist leider in einem nicht fertigen Zustand. Das Gerät wurde damals abgebaut, so dass wir den Treiber nicht fertigstellen konnten.
Lade- bzw. Entladeleistungen nicht aufsummiert werden
Du redest von den Energiewerten? Im Code kann ich gerade kein Mapping der Energiewerte finden. Ich erinnere mich, dass der Fronius eine eigene Interpretation von Sunspec gemacht hat. Es ist also möglich, dass die Werte nicht stimmen.
Aufladen des Speichers wird als Verbrauch gewertet.
Da denke ich eher an ein falsch konfiguriertes System bei dir (MeterType vom Gridzähler korrekt auf MeterType.GRID eingestellt?). Es mag aber auch sein, dass der Treiber falsch implementiert ist.
Generell glaube ich, dass jemand mit etwas Erfahrung den Treiber heute zu einem guten Treiber für ein Home EMS machen könnte (TODOs: Einführung SMART-Mode, Power Constraints, Sunspec aufräumen). Vermutlich Anfang September wird es einen OpenEMS Hackathon geben. Vielleicht könnte man das Event nutzen um den Treiber für den privaten Bereich stabil zum laufen zu bekommen.
Hallo Christian,
wäre eine super Idee, den Treiber beim Hackathon ans Rennen zu bekommen. 
Mein Meter ist auf GRID eingestellt. Aber der Meter-Treiber für das Fronius Smart Meter ist auch von mir geschrieben und derzeit noch im Testbetrieb. Dem traue ich auch noch nicht so ganz. Ich hänge mal einen Screenshot vom heutigen Tag an, was hoffentlich verdeutlicht, was ich meine:
Hier zum Vergleich ein Screenshot vom openWB, was ich derzeit parallel laufen lasse:
Der Screenshot zeigt realistisch den Verbrauch. Um 17:30 und um 19:30 herum hatten wir etwas größere Verbraucher laufen. Ansonsten ist das Haus derzeit noch nicht bezogen, die Grundlast eher minimal. Das kommt bei dem openWB deutlich besser heraus als bei openEMS. openWB greift die Daten des SmartMeters per json-API ab, mein TS63A-Treiber per SunSpec. Sry, wenn ich etwas abschweife.
Mir geht es darum, dass in der openEMS-History Anzeige bei Beladung und Entladung nicht die aufsummierten kWh des Tages angezeigt werden.
vielleicht könnte man ja aus deinem und meinem Projekt eins machen.
Mein Fronius läuft größten teil auf Basis von Json Daten die Abgefragt werden. da mir das mit den Modusregistern stellenweise einfach zu verpfuscht war seitens Fronius.
Speichersteuerung wäre dabei auch am Start und die läuft für mich zufriedenstellend. nur bin ich halt nicht der der “sauber” programmiert.
mfg Daniel
Hallo Daniel. Klingt vielversprechend und würde eines meiner Hauptprobleme lösen - openEMS setzt im Gen24 float für Fließkommazahlen voraus. Meine Wärmepumpe natürlich int+sf. Da ich eher openEMS ändern kann als die Firmware der WP, könnte die JSON-Api eine Lösung sein.
Mein aktueller Stand ist, dass ich den SunSpec-Ansatz von Christian weiter vervollständigt habe. Zwei Stellen habe ich korrigiert, wo zur Laufzeit noch Exceptions geworfen wurden - vermutlich, weil Christians Code schon etwas älter ist. Auch das Problem, dass die Summen der Batterie-Ladung und -Entladung in der History nicht angezeigt werden, habe ich gelöst.
Bei der Speichersteuerung habe ich derzeit nur ein paar Basics getestet. Derzeit steht die Hütte, wo die Anlage steht, noch leer (Was sich hoffentlich bald ändern wird 
). Mehr als Grundlast von 40-80w war da nicht. Ob es mit der Implementierung noch die oben beschriebenen Probleme gibt, dass die Gen24-Steuerung immer mal in die von openEMS reingrätscht, konnte ich bisher nicht testen. Beobachtest du das bei deiner Speichersteuerung nicht?
An anderer Aspekt - derzeit ist ja schon eine Fronius Wechselrichter-Implementierung im Feld, die SunSpec benutzt. Ich nhabe mir auch Fronius SmartMeter Treiber auf Sunspec-Basis gebaut. All das müsste man irgendwie zusammenfassen.