Neuer Optimizer/Logik für mehrere Hybrid ESSes

1

Hallo zusammen,
hallo @stefan.feilmeier ,

wie würde ich vorgehen müssen, wenn ich einen neuen Optimizer für 3 ESS ezu erstellen? Aktuell erhalte ich da echt total komische Verhalten, manchmal entlädt er, manchmal belädt er, manchmal belädt er nicht, manchmal “vollgas” manchmal gar nicht.

Ich komme da echt nicht weiter..

Kann mir da jemand helfen bzw. will jemand eventuell zusammen an so einer Lösung arbeiten?

Grüße !

2

Hallo @Sn0w3y,

mit dem neuesten Backport gibt es eine neue Strategy:

Vielleicht kannst du dir da etwas abschauen. Für deine Anforderung, einen Hybrid-Wechselrichter optimal zu unterstützen, wirst du aber auch am internen Unterbau einiges ändern müssen, weil du irgendwo die DC-Erzeugungsleistung mit übergeben musst.

Gruß,
Stefan

1 Like
3

Hallo Stefan,

ich bin mittlerweile von den 3 ESS weggegangen und habe nun “nur” noch 2.

2x GoodWe:

1x GoodWe Ess
1x GoodWe BatteryInverter und Fenecon Home 10 (klassische Fenecon config)

Wie meinst du könnte ich das am besten Umsetzen? Auch trotzdem im Solver?

Grüße !

4

Ja, du müsstest das trotzdem im Solver machen. Dort findet die Leistungsverteilung statt, bevor applyPower() aufgerufen wird.

Du kannst aber natürlich mal mit etwas hard-gecodetem anfangen, wenn du deine Umgebung genau kennst. Das kann ich dann aber leider nicht in OpenEMS aufnehmen, weil es nicht generisch genug wäre.

5

Also ich würde mich da ggf. beteiligen. Ich bekommen meinen 2. Hybrid Wechselrichter in den kommenden Wochen. Die Implementierung für OpenEMS habe ich bereits abgeschlossen.

Sollte ich mit diesen Systemen ähnliche Probleme haben, würde ein DC-optimierter Optimizer Sinn machen und ich würde mich hier durchaus beteiligen wollen. Dazu müsste ich mich aber intensiver nochmal mit der Struktur von den Optimizern auseinandersetzen, da ich da noch nicht so ganz durchsteige, wie letztlich die gewünschte Leistung verteilt wird.

Bis dahin ist es ja relativ klar:

Bei Discharge: Schauen, wieviel AC-Leistung gewünscht wird, dann:

  1. Erstmal die Leistung aus allen vorhandenen PV-Strings auf die Hybrid WR verteilen
  2. Sollte das nicht reichen: Batterien entsprechend entladen, wobei hier auch aus Effizienzgründen versucht werden sollte, nur einen Hybrid WR (bzw. so wenig wie möglich) für die Entladung zu nutzen. Das ist ja in den bisherigen Implementierungen ja auch bereits vorhanden.

Bei Charge: Schauen, wieviel AC-Leistung gewünscht wird, dann:

  1. Erstmal versuchen die Ladung auf der DC-Seite aller Hybrid-WR zu verteilen, um unnötige Verluste durch AC/DC-Wandlung zu vermeiden
  2. Sollte das nicht reichen, zusätzlich AC Ladung vorgeben, wobei auch hier versucht werden sollte, nur einen Hybrid WR (bzw. so wenig wie möglich) für die Ladung zu nutzen.
6

Hallo Mr T,

genau das wäre mein Ansatz.. Da ich leider “zu dumm” bin, einen Optimizer zu schreiben, der das abdeckt, habe ich nun die “Keep All Near Equal” genommen und einen eigenen PID in den Controller Balancing eingebaut.. Eventuell kannst du da mal anfangen und wir arbeiten dann zusammen ? :slight_smile:

Wenn ich eine “Outline” des Codes sehe, dann verstehe ich es auch meistens besser :smiley:

Grüße !

7

Hab jetzt mal ne Zeit lang den “KEEP_ALL_NEAR_EQUAL” ausprobiert:

Screenshot_20250607_144313_Chrome
Screenshot_20250607_144313_Chrome1080×1210 71.2 KB

Screenshot_20250607_144317_Chrome
Screenshot_20250607_144317_Chrome1080×1360 88.6 KB

8

Hi ,
How is this Keep_all_nearly_strategy working,

The Keep All Near Equals strategy essentially tries to select all the inverters during distribution, with the main goal of gradually balancing the SoC across multiple ESS units. It’s essentially a SoC-optimized approach.

On the other hand, for DC-optimized operation, is the main strategy to minimize the number of active inverters to reduce unnecessary DC-AC conversion losses across all inverters — considering inverter efficiency?

If yes , what is the logic to get the best efficient inverter ?
or simple round robin strategy to select the inverter is it ?

thanks,
pooran

1 Like
9

For the DC optimized approach, you should minimize the number of used invertes for AC/DC conversion to get the best efficiency.

The pv power on the DC-side can be used to charge the battery, for this you can use multiple hybrid inverters in parallel which is good for efficency.

Therefore if we look into charge operation:

  • First try to use DC surplus power of each hybrid inverter to charge each dc connected battery
  • if there is not enough dc power to reach the target, we have to use ac power for charging. Try to minimize the number of used invertes (taking into account that each ess has constrains for maximum charge power. So if you need 8000W AC charge power and ess1 can only ac-charge with 4000W and ess2 can charge with 9000W you want to chooose ess2)

And if you look into discharge:

  • Try to minimize the number of used invertes like described above
  • But make sure to use all actual DC generated pv power of all inverters for „discharge“ before discharge from battery

For getting the best inverter selected first:
I would see this as prio 2, because if you have desgined the battery size to your needs, you will use all batteries anyway.
But to bring a priority, a selection based on alphabetic order could be the easiest approach. Then you can have the most efficient inverter as ess0, the second as ess1, and so on.
Or does anyone has a better idea?

10

Maybe we should consider charging based on capacity

11

I’ve now built a prototype for it, which works very well in my initial tests. I’ll incorporate the logic into a new optimizer and upload the code to my fork on GitHub.

Regarding the prioritization of the inverter, the optimizer will prioritize using the same logic as ReduceNumberOfInverters, which in my opinion makes the most sense:

Prefers high-weight inverters (e.g. high state-of-charge) on DISCHARGE and low-weight inverters (e.g. low state-of-charge) on CHARGE.

1 Like
12

I just uploaded the branch to my GitHub as feature/PreferDcPowerOptimizer.

Feel free to test it and provide feedback.

1 Like
13

@Sn0w3y are you still interested to contribute to this development?

The DC optimizer works as expected within my installation (SolarEdge and RctPower). I only have problems using the SolarEdge SmartMode, but this does not seem to be directly related to the DC Optimizer

The SolarEdge gear reports some pv production when there is no production (e.g. during night). This can also be seen within the official SolarEdge Monitoring Portal. And with Smart Mode, I’m having the problem that the SolarEdge implementation only switches from or to Smart Mode for one cycle. I’m not sure if this is related to this incorrect PV production report. But I do not have the time to investigate here. For me it works good enough without using SmartMode.

For the DC optimizer the main doing (except more testing) is code cleanup and creation of JUnit Tests.

14

Hi @MrT ,

sure! Is there already a PR or a Repo for this? If yes, could you add me as a Conteibutor then I will have a look at it and maybe test it locally - in the meantime i also worked on a “quick and dirty” Solution which works well on my Installation with 2 GoodWe’s and 2 different Batterys connected (1 of them on each GoodWe)

Greetings!

15

You can find the feature in my repo: GitHub - timo-schlegel/openems at feature/PreferDcPowerOptimizer

You are already added as contributor. Did you see my PN from 5th of August?

16

It is running on my local System and I will monitor and check it :slight_smile:

1 Like
17

Eine kleine Anmerkung habe ich schon mal :slight_smile:
Meinst du schaffen wir es, wie in der OPTIMIZE_BY_KEEPING_ALL_NEAR_EQUAL auch die Speicher auf einem gleichen SoC zu lassen? Das ist mir bisher schon ein bisschen gelungen, aber nur so, dass es ab und zu dazu kam, dass sich die Speicher gegenseitig aufgeschwungen haben (Ausregelungzeit)

Wie wird denn beim Entladen aktuell entschieden, welcher Speicher entladen soll?

18

Das ist berücksichtigt. Sollte keine PV-Leistung vorhanden sein, wird der ESS entladen der den höchsten SOC hat.

Siehe auch:

- Inverters are by default sorted by weight descending.
For DISCHARGE take list as it is; for CHARGE reverse it.
This prefers high-weight inverters (e.g. high state-of-charge) on DISCHARGE and low-weight inverters (e.g. low state-of-charge) on CHARGE.
→ Note: The list will be adjusted slightly (when weight changes), see openems/io.openems.edge.ess.core/src/io/openems/edge/ess/core/power/data/WeightsUtil.java at develop · OpenEMS/openems · GitHub

Wenn DC PV-Leistung vorhanden ist, wird erstmal versucht die Entladung mit vorhandener DC (PV) Leistung zu decken. Reicht diese nicht, wird Batterieleistung ergänzt. Hierbei werden erstmal nur ESS berücksichtigt die bereits DC-Energie in AC wandeln, die Reihenfolge wie oben beschrieben, d.h. ESS mit hohem SOC werden zuerst verwendet.

Beim Laden ist es genau andersrum (ESS mit geringstem SOC wird bevorzugt). Wobei auch hier erst alle aktuell vorhandene DC PV-Leistung genutzt wird.

19

Tatsächlich funktioniert das bis jetzt ziemlich gut - lass uns das bitte noch ein bisschen bei mir auch laufen lassen - zudem müssten wir dann dafür einen Test schreiben :roll_eyes: Aber das bekommen wir schon hin :stuck_out_tongue:

Ich muss allerdings dazu sagen, dass mir solche Hard-Coded Values wie “100W Discharge” nicht wirklich gefallen - aber ich habe aktuell auch nicht wirklich eine andere Lösung.

20

Heute ist er zum ersten mal “Stecken geblieben” hat 0W entladen - nur beladen - das lag denke ich an den 100W Threshold, da einer der WR round about 100W produziert hat und der andere unter 100W

Genaueres kann ich noch nicht dazu sagen, weil ich die Logs nicht beobachten konnte - werde es später aber mal nochmal anschauen und Posten, wenn nötig