feature: DPL: allow overscaling to compensate for shading

[AndreasBoehm]

Fixes https://github.com/helgeerbe/OpenDTU-OnBattery/issues/917 based on the discussion https://github.com/helgeerbe/OpenDTU-OnBattery/discussions/819

Notes

• Overscaling is only available when the inverter is solar powered
• I haven't touched C++ and HTML for a long time, please excuse me if i did something in a weird way
• I did not touch the french translations because the file is only partially translated, contains a lot of english strings and is missing a lot of strings

Config	Scaling result

Console

10:00:54.585 > [DPL::loop] ******************* ENTER **********************
10:00:54.597 > [DPL::calcPowerLimit] battery use prevented, solar power (DC): 10000 W
10:00:54.617 > [DPL::calcPowerLimit] target consumption: -150 W, base load: 100 W, power meter does include inverter output
10:00:54.628 > [DPL::calcPowerLimit] power meter value: -115 W, power meter valid: yes, inverter output: 235 W, solar power (AC): 9219 W
10:00:54.633 > [DPL::calcPowerLimit] limited to solar power: 270 W
10:00:54.640 > [DPL::setNewPowerLimit] input limit: 270 W, min limit: 40 W, max limit: 1600 W, hysteresis: 5 W
10:00:54.666 > [DPL::scalePowerLimit] 2/4 channels are producing less than expected, scaling from 270 to 324 W
10:00:54.671 > [DPL::setNewPowerLimit] inverter max: 1600 W, inverter is producing, requesting: 324 W, reported: 240 W, diff: 84 W
10:00:54.677 > [DPL::updateInverter] sending limit of 20.2 % (324 W respectively), max output is 1600 W

[greymda]

@AndreasBoehm you're right i opened this enhancement but I no longer have access to the partially shaded environment so, unfortunately, I cannot test. Still I believe that this functionality will bring value to the project, though.

[AndreasBoehm]

@hex2647 Konntest du nochmal prüfen warum bei dir so eine geringe Leistung anliegt? Und denkst du das die Skalierung nun korrekt funktioniert für dich?

[hex2647]

@hex2647 Konntest du nochmal prüfen warum bei dir so eine geringe Leistung anliegt? Und denkst du das die Skalierung nun korrekt funktioniert für dich?

Hi sorry bin gerade in Spanien unterwegs und hab daher leider keine Möglichkeit es zu testen… werd ich aber machen sobald ich zurück bin. Bezüglich der 1.9W hatte ich tatsächlich nen Verkabelungsfehler drin als ich den dann aber entdeckt hatte war die Sonne weg :(

[Dozer-hh]

Sehe ich es richtig, dass das hier angesprochene Schatten-Feature auch meine Anfrage von hier https://github.com/helgeerbe/OpenDTU-OnBattery/issues/1035 löst? Ich bleibe mal bei der deutschen Beschreibung meines Request:

Ich habe einen HMS-2000-4T mit 4 PV-Modulen á 435 W. Hiervon haben 2 Module eine Süd-Ost-Ausrichtung und 2 Module eine Süd-West-Ausrichtung, es liegt also nie an allen 4 Modulen die gleiche Leistung an. Derzeit habe ich keinen Speicher, so dass ich die volle Leistung bis zur erlaubten 800 W Grenze ins Haus einspeise.

Wenn ich das obere Leistungslimit auf 800W setze, wird der WR auf ein Limit von 40% gesetzt und somit jeder MPPT auf 200 W (der möglichen 500 W) begrenzt.

Wenn die 4 Module zu einem bestimmten Zeitpunkt insgesamt z.B. 1000 W produzieren können, davon Modul 1 und 2 (Süd-Ost) jeweils 400 W und die Module 3 und 4 (Süd-West) aber sonnenstandsbedingt nur jeweils 100 W, wird die reale Einspeisung durch das Limit von 40% pro MPPT auf zusammen 600 W (je 200 W von M1 und M2 und je 100 W von M3 und M4) begrenzt. Somit gehen zu dem Zeitpunkt 200 W verloren.

Wenn die OpenDTU-OnBattery nun erkennen würde, dass sie, um das gewünschte obere Leistungslimit von 800W zu erreichen, die "fehlenden" 200 W durch eine Angleichung des prozentualen Limits ausgleichen muss, würde man (beim Betrieb ohne Speicher) einiges weniger vom Netzbetreiber beziehen müssen, da die Anlage es selber hergeben würde.

[spcqike]

@Dozer-hh ja das siehst du richtig. dieser PR soll, bei Verwendung des DPL, genau das bewirken.

den letzten Build aus dem PR findest du, glaube ich, hier https://github.com/helgeerbe/OpenDTU-OnBattery/actions/runs/9087695629

[Dozer-hh]

@spcqike Perfekt, danke für die Bestätigung und den Link zum letzten PR Release!

EDIT: Ist der letzte Release nicht dieser hier: https://github.com/helgeerbe/OpenDTU-OnBattery/actions/runs/9170291945?

[AndreasBoehm]

@Dozer-hh Den letzten build findest du hier: https://github.com/helgeerbe/OpenDTU-OnBattery/actions/runs/9345299744 Bitte gib Bescheid ob alles klappt und wie erwartet funktioniert.

[Dozer-hh]

@AndreasBoehm vielen Dank für den Link. Ich habe Freitag die Version aus meinem vorangegangenen Link installiert und bisher keine Probleme festgestellt. Wetterbedingt konnte ich aber das von mir gewünschte Verhalten bzgl. Übersteuern noch nicht feststellen, da die Panel entweder gar nicht so viel Ertrag oder alle einen sehr ähnlichen Ertrag gebracht haben. Ich werde aber beobachten und berichten, falls es Probleme gibt bzw. sobald ich feststelle, dass die Steuerung klappt.

[AndreasBoehm]

@Dozer-hh Konntest du schon testen bzw feststellen ob alles funktioniert wie erwartet?

[Dozer-hh]

@AndreasBoehm Soweit ich es bisher sehen konnte, funktioniert die Übersteuerung / Regelung. Ich hatte bisher wetterbdingt leider nur zwei Situationen, die ich abpassen konnte und wo das Overscaling in jedem Fall höhere Werte der beiden nicht verschatteten Module bewirkte. Der Vergleich durch Ausschalten des DPL und einem "Dauerhaften Limit" von 100% brachte "identische" Ertragswerte der Module und das Ausschalten vom Overscaling bewirkte das gewohnt niedrigere Limit mit Beschneidung der beiden Module, die voll in der Sonne standen.

Ich meine, dass der angestrebte Netzbezug (bei mir auf -10W bei einer Hysterese von 5W) immer etwas lange über- bzw. unterschritten wurde (Bereich -30W bis +30W), das kann ich aber wetterbedingt nur eingeschränkt beurteilem, da ich WENN hier mal ausreichend Sonne ist, meist im Büro sitze und nicht allzu ausgiebig testen kann, bzw. sich Sonnenzustand zu Hause und im Büro nicht decken...

Aber auf den ersten Eindruck deckt das Feature genau meine Anforderungen und ist eine echte Verbesserung für meine Installationssituation mit unterschiedlich ausgerichteten Modulen.

[AndreasBoehm]

Danke für deine mühen @Dozer-hh ! Ich werde nachher noch etwas aufräumen, dann können wir das feature endlich mergen.

[schlimmchen]

@AndreasBoehm Hast du einen ESP32 mit mind. 8MB Flash und kannst das Feature auch ab dem nächsten Release begleiten?

[AndreasBoehm]

@schlimmchen Fusion Board mit 8MB liegt schon bereit 👍

[Dozer-hh]

@AndreasBoehm Also wird das aufgeräumte / zusammengeführte Release dann schon nicht mehr auf den 4MB ESPs funktionieren?

[schlimmchen]

@Dozer-hh Wenn das Feature "fertig" ist, gibt es im Rahmen dieses PR nochmal einen Build Run, der das Feature enthält und auf dem aktuellen Development-Branch beruht (Release 2024.06.03), welches das bisherige Partitionslayout für 4MB Flash noch benutzt. Das nächste Release allerdings wird das neue Partitionslayout verwenden.

[hex2647]

@Dozer-hh Wenn das Feature "fertig" ist, gibt es im Rahmen dieses PR nochmal einen Build Run, der das Feature enthält und auf dem aktuellen Development-Branch beruht (Release 2024.06.03), welches das bisherige Partitionslayout für 4MB Flash noch benutzt. Das nächste Release allerdings wird das neue Partitionslayout verwenden.

Ich bin zwar erst nächste Woche zurück zum weiter testen aber woran erkenne ich ob ich 4 oder 8mb zur Verfügung habe?

[AndreasBoehm]

@hex2647 Das kannst du in openDTU überprüfen wenn du das aktuelle Release build oder das aktuellste build von meinem PR installiert hast.

..navigate to the system's information page of the web UI. It lists the flash memory size in section "Hardware Information". This information is expected to be reliable. Quelle: https://github.com/helgeerbe/OpenDTU-OnBattery/issues/1025

@schlimmchen Ich hab aufgeräumt und der PR wäre von meiner Seite aus jetzt fertig.

[AndreasBoehm]

Beautiful ❤️

Thanks a lot for your support on this @schlimmchen !

[schlimmchen]

@Dozer-hh FYI: Ich rechne im Moment damit, dass ESP32 mit 4MB flash doch noch weiter unterstützt werden. Allerdings auf Kosten von Over-The-Air Updates. Siehe https://github.com/helgeerbe/OpenDTU-OnBattery/issues/1025#issuecomment-2179428297

Thanks a lot for your support on this

@AndreasBoehm You are very welcome. Let me know if you are interested in tackling another feature :wink:

[Dozer-hh]

@schlimmchen Jetzt habe ich mir gestern frisch ne Fusion DTU bestellt, um up-to-date zu bleiben… 🤪🫣

[schlimmchen]

Das wirst du auch nicht bereuen. Alleine schon um weiterhin OTA Updates machen zu können. Mit dem Kabel und dem PC für jedes Update an die OpenDTU-OnBattery zu gehen, oder schlimmer, diese an den PC zu bringen, ist schon lästig und würde eine Hürde darstellen, up-to-date zu bleiben, ggf. sogar obwohl du neue Features spannend findest.

[hex2647]

@hex2647 Das kannst du in openDTU überprüfen wenn du das aktuelle Release build oder das aktuellste build von meinem PR installiert hast.

..navigate to the system's information page of the web UI. It lists the flash memory size in section "Hardware Information". This information is expected to be reliable. Quelle: #1025

@schlimmchen Ich hab aufgeräumt und der PR wäre von meiner Seite aus jetzt fertig.

Kann das sein das ich nur 2mb hab? Da wurde ich ja dann ganz schön verarscht… welches ist denn das ideale Board vorallem wenn ich noch Batterie und Ladegeräte abklemmen will?

[AndreasBoehm]

@hex2647 Die Info gibts unter 'Hardwareinformationen'

[hex2647]

@hex2647 Die Info gibts unter 'Hardwareinformationen'

Ah ok da wird mir nichts angezeigt dann hab ich wohl keine passende Version installiert :)

[AndreasBoehm]

@hex2647 Das ist durchaus möglich, sonst versuch mal die Seite manuell neu zu laden, das ist nach einem Update immer erforderlich um die aktuelle Version der WebApp anzuzeigen.

[spcqike]

Mahlzeit,

ich hab jetzt den PR (https://github.com/helgeerbe/OpenDTU-OnBattery/pull/1077) auf dem neuen Board installiert, läuft soweit. Nun kann ich auch das Overscaling noch einmal auf Herz und Nieren testen. Dabei fällt mir auf, dass irgendwas nicht zu passen scheint :)

16:05:31.825 > [DPL::loop] ******************* ENTER **********************
16:05:31.909 > [DPL::calcPowerLimit] battery use prevented, solar power (DC): 10000 W
16:05:31.971 > [DPL::calcPowerLimit] target consumption: 0 W, base load: 250 W, power meter does include inverter output
16:05:32.115 > [DPL::calcPowerLimit] power meter value: 71 W, power meter valid: yes, inverter output: 213 W, solar power (AC): 9220 W
16:05:32.217 > [DPL::calcPowerLimit] limited to solar power: 284 W
16:05:32.321 > [DPL::setNewPowerLimit] input limit: 284 W, min limit: 200 W, max limit: 2000 W, hysteresis: 25 W
16:05:32.385 > [DPL::scalePowerLimit] all channels are shaded, keeping the current limit of 226 W
16:05:32.449 > [DPL::setNewPowerLimit] inverter max: 2000 W, inverter is producing, requesting: 226 W, reported: 226 W, diff: 0 W
16:05:32.527 > [PowerMeterHttpJson] New total: 63.49
16:05:32.850 > [DPL::loop] ******************* ENTER **********************
16:05:32.933 > [DPL::calcPowerLimit] battery use prevented, solar power (DC): 10000 W
16:05:32.994 > [DPL::calcPowerLimit] target consumption: 0 W, base load: 250 W, power meter does include inverter output
16:05:33.139 > [DPL::calcPowerLimit] power meter value: 63 W, power meter valid: yes, inverter output: 213 W, solar power (AC): 9220 W
16:05:33.241 > [DPL::calcPowerLimit] limited to solar power: 276 W
16:05:33.350 > [DPL::setNewPowerLimit] input limit: 276 W, min limit: 200 W, max limit: 2000 W, hysteresis: 25 W
16:05:33.417 > [DPL::scalePowerLimit] all channels are shaded, keeping the current limit of 226 W
16:05:33.550 > [DPL::setNewPowerLimit] inverter max: 2000 W, inverter is producing, requesting: 226 W, reported: 226 W, diff: 0 W
16:05:33.655 > Fetch inverter: 116492305207
16:05:33.758 > Success
16:05:33.854 > [PowerMeterHttpJson] New total: 64.87
16:05:33.956 > [DPL::loop] ******************* ENTER **********************
16:05:34.017 > [DPL::calcPowerLimit] battery use prevented, solar power (DC): 10000 W
16:05:34.161 > [DPL::calcPowerLimit] target consumption: 0 W, base load: 250 W, power meter does include inverter output
16:05:34.265 > [DPL::calcPowerLimit] power meter value: 64 W, power meter valid: yes, inverter output: 213 W, solar power (AC): 9224 W
16:05:34.335 > [DPL::calcPowerLimit] limited to solar power: 277 W
16:05:34.396 > [DPL::setNewPowerLimit] input limit: 277 W, min limit: 200 W, max limit: 2000 W, hysteresis: 25 W
16:05:34.469 > [DPL::scalePowerLimit] all channels are shaded, keeping the current limit of 226 W
16:05:34.572 > [DPL::setNewPowerLimit] inverter max: 2000 W, inverter is producing, requesting: 226 W, reported: 226 W, diff: 0 W
16:05:34.675 > [PowerMeterHttpJson] New total: 69.00

wie man sieht, gegen 15:50 hab ich das Target auf 0W gesetzt. das hält er auch. Kurz nach 16:00 gab es einen Anstieg im Verbrauch. Allerdings will er nicht hoch regeln. er sagt immer, alles sei verschattet, was so nicht ganz hinkommt. die 30W mehr wären sicherlich drin :) Daher hab ich das Skalieren aus gemacht und siehe da, er regelt hoch und macht auch mehr.

Leider sehe ich die Auswertung der Eingänge nicht mehr im Log, also wie viel leistung welcher Eingang tatsächlich liefert. und ich hab es mir nicht notiert :D

Hab also das Skalieren noch mal an gemacht und gucke, ob das Verhalten noch mal auftritt. Dann geb ich n Update dazu, welches Limit gesetzt ist, welche Leistung erzeugt und und welcher Eingang was dazu beisteuert.

[Dozer-hh]

Ich kann das Fehlverhalten bestätigen, allerdings aus dem Release #1310 von hier: https://github.com/helgeerbe/OpenDTU-OnBattery/actions/runs/9596676383.

Ich habe vor ein paar Tagen auf die Fusion openDTU von 3PrintD Solution gewechselt. Da für mich auf dem Fusion-Board die PIO Umgebung nicht eindeutig war (steht irgendwas mit Fusion in der Bezeichnung), habe ich wegen des ESP32-S3 Chips erst die falsche Firmware geflasht und die "opendtu-onbattery-generic_esp32s3" verwendet. Hier kam es dann aber bei aktiviertem DPL zu seltsamem Verhalten der openDTU.

Zum Glück bin ich dann unter: https://github.com/markusdd/OpenDTUFusionDocs/blob/main/BLANK_START.md auf den Hinweis gestoßen: For the Fusion board, you need the USB version.

Für Neulinge in dem Thema wäre hier ggf. (vor allem da demnächst vermutlich einige Leute auf andere Hardware umsteigen werden) ein kleiner Hinweis ganz gut, wann welche Firmware zu verwende ist. ;-)

Jedenfalls trat mit dem Release #1310 bei mir das Verhalten auf, dass bei Aktiviertem Ausgleich von Verschattung die Regelung total sprunghaft wurde und ganz oft trotz Sonne der WR so weit runter geregelt wurde, dass er Strom aus dem Netz zog, obwohl die Module ausreichend hätten liefern können:

Noch deutlicher hier:

Ich habe dann wieder den Release #1291 von hier: https://github.com/helgeerbe/OpenDTU-OnBattery/actions/runs/9345299744 installiert, da dieser vor dem Boardwechsel problemlos lief.

Leider scheint seitdem die letzten Tage die Sonne kaum bis gar nicht, so dass ich nicht sehe, ob der Wechsel etwas bewirkt hat oder ob das Problem mit am Fusion Board liegt.

Ich vermute aber, dass beim Aufräumen und Mergen von @AndreasBoehm irgendetwas schief gelaufen ist und ab des Releses #1310 irgendwas hakt.

[Dozer-hh]

Ich kann das Fehlverhalten bestätigen, allerdings aus dem Release #1310 von hier: https://github.com/helgeerbe/OpenDTU-OnBattery/actions/runs/9596676383.

Ich habe vor ein paar Tagen auf die Fusion openDTU von 3PrintD Solution gewechselt. Da für mich auf dem Fusion-Board die PIO Umgebung nicht eindeutig war (steht irgendwas mit Fusion in der Bezeichnung), habe ich wegen des ESP32-S3 Chips erst die falsche Firmware geflasht und die "opendtu-onbattery-generic_esp32s3" verwendet. Hier kam es dann aber bei aktiviertem DPL zu seltsamem Verhalten der openDTU.

Zum Glück bin ich dann unter: https://github.com/markusdd/OpenDTUFusionDocs/blob/main/BLANK_START.md auf den Hinweis gestoßen: For the Fusion board, you need the USB version.

Für Neulinge in dem Thema wäre hier ggf. (vor allem da demnächst vermutlich einige Leute auf andere Hardware umsteigen werden) ein kleiner Hinweis ganz gut, wann welche Firmware zu verwende ist. ;-)

Jedenfalls trat mit dem Release #1310 bei mir das Verhalten auf, dass bei Aktiviertem Ausgleich von Verschattung die Regelung total sprunghaft wurde und ganz oft trotz Sonne der WR so weit runter geregelt wurde, dass er Strom aus dem Netz zog, obwohl die Module ausreichend hätten liefern können:

Noch deutlicher hier:

Ich habe dann wieder den Release #1291 von hier: https://github.com/helgeerbe/OpenDTU-OnBattery/actions/runs/9345299744 installiert, da dieser vor dem Boardwechsel problemlos lief.

Leider scheint seitdem die letzten Tage die Sonne kaum bis gar nicht, so dass ich nicht sehe, ob der Wechsel etwas bewirkt hat oder ob das Problem mit am Fusion Board liegt.

Ich vermute aufgrund von @spcqike Rückmeldung aber eher, dass beim Aufräumen und Mergen von @AndreasBoehm irgendetwas schief gelaufen ist und ab dem Relese #1310 irgendwas hakt.

[AndreasBoehm]

Danke für deinen input @Dozer-hh, es wäre ganz wichtig neben dem aktuellen Limit auch das gewünschte Limit und vorallem auch die aktuelle Leistung pro Kanal zu sehen, denn diese ist entscheidend dafür ob skaliert wird oder nicht.

Ich konnte bisher mit meinem Setup kein Vergleichbares Problem feststellen.

[Dozer-hh]

@AndreasBoehm Im Falle der Scrennshots waren es 2.000 W Limit bei aktiviertem DPL. Da ich noch im Testmodus bin, ob und in welcher Dimension sich ein Speicher bei mir lohn, läuft das Limit bei aktiviertem DPL meist auf 2.000 W. Ich vergleiche diese Werte dann tageweise mit dem Ertrag ohne DPL und einem Limit von 2.000 W bzw. mit DPL und einem Limit von 800 W.

Ich habe 4 bifaziale Module á 435W Peak an nem Hoymiles HMS-2000-4T, die Module haben 2x SO-Ausrichtung und 2x SW-Ausrichtung.

Leider habe ich keine aussagekräftigen Scrennshots von der einzelnen Modulleistung. Was mit aber parallel aufgefallen ist, ist der Effekt, dass der angestrebte Netzbezug (habe -10W eingestellt) teilweise deutlich überschritten wurde und manchmal auf bis zu -350W ging.

Ich bin derzeit krank geschrieben und morgen soll es teils sonnig werden. Ich kann morgen gerne mal die beiden Releases gegeneinander testen und endsprechende Scrennshots der einzelnen Kanäle und Settings machen.

[AndreasBoehm]

Ich weiß das es schwer ist das so zu Beschreiben das alle wissen was passiert ist und was erwartet wurde, aber ich kann aktuell nicht nachvollziehen was du erwartest und was passiert ist, denn es ist auf den Screenshots auch nicht ersichtlich welche Einstellung gerade aktiv war (mit/ohne DPL, Modulleistung, Limits, etc).

Grundsätzlich muss man mit overscaling auch damit rechnen das Kurzzeitig sehr viel Strom eingespeist wird wenn wir von starker verschattung zu 100% Sonne wechseln.

Wäre super wenn du einen Issue öffnen könntest und dort versuchst exakt die verschiedenen Szenarien bzw übergange zwischen Szenarien zu beschrieben um es nachvollziehbar zu machen.

[Dozer-hh]

Okay, werde ich mal genauer dokumentieren. Also nicht hier fortführen?

[robbe1912]

Hey! Wenn ich das Overscaling anmache, dann schwankt der output extrem stark jedes update. Das kann sich irgendwie nicht an den richtigen wert annähern. Es geht von 300 zu viel zu 300 zu wenig, dann wieder 300 zu viel alle 5 sekunden. Kann man da eine Annäherungskurve einbauen um das zu reparieren?

[AndreasBoehm]

Hallo @robbe1912 ,

ich würde dich darum bitten wie in meinem früheren Kommentar beschrieben eine Ausführliche Beschreibung inklusive Logs und relevanten Daten bereit zu stellen, ohne diese Infos können wir nicht nachvollziehen ob ein Problem vorliegt und wo.

Bitte erstelle einen Issue mit den geforderten Infos dann können wir uns das anschauen.

[AndreasBoehm]

@schlimmchen Kannst du hier zu machen? Danke