feature: DPL: allow overscaling to compensate for shading

[AndreasBoehm]

Fixes #917 based on the discussion #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

[schlimmchen]

Quite clean. Thanks for printing an informative message in case this new overscaling method does change the limit. I did not check the algorithm itself, since I don't care. Others will let us know if this works as expected or not.

[schlimmchen]

@AndreasBoehm I allowed myself to rebase this onto the current development branch before asking users to review your work.

[schlimmchen]

@greymda @spcqike @hex2647 Please test this feature by flashing the firmware built in this PR's build-run.

[greymda]

i don't have access any more to the partially shaded setup :(

[spcqike]

Kann es sein dass es ein Problem mit HMS wechselrichter und neuer Firmware gab? Oder liegt es am PR? Ich bekomme seit dem Update keine Verbindung mehr zum HMS.

[schlimmchen]

Benutzt du einen Reverse Proxy oder hast sonst irgendein Setup, das verhindert, dass die Websocket-Verbindung zustande kommt? Oder geht es nicht um das LiveView, sondern dass der Inverter nicht gepollt werden kann? Was steht in der Konsole?

[spcqike]

Kein peoxy. Direkt die IP der openDTU. Er empfängt gar nichts vom wechselrichter

Naja. Da steht nicht viel.

All missing
17:03:43.240 > Nothing received, resend whole request
17:03:43.738 > Websocket: [/livedata][6] disconnect
17:03:44.048 > All missing
17:03:44.058 > Nothing received, resend whole request
17:03:44.864 > All missing
17:03:44.907 > Nothing received, resend whole request
17:03:45.566 > All missing
17:03:45.576 > Nothing received, resend count exeeded
17:03:45.888 > All missing
17:03:45.896 > Nothing received, resend whole request
17:03:46.195 > All missing
17:03:46.240 > Nothing received, resend whole request
17:03:46.502 > All missing
17:03:46.544 > Nothing received, resend whole request
17:03:46.714 > All missing
17:03:46.748 > Nothing received, resend whole request
17:03:46.912 > All missing
17:03:46.951 > Nothing received, resend count exeeded
17:03:46.958 > Fetch inverter: 116492305207
17:03:46.965 > Request SystemConfigPara
17:03:46.972 > All missing
17:03:46.980 > Nothing received, resend whole request
17:03:46.988 > All missing
17:03:46.997 > Nothing received, resend whole request
17:03:47.033 > All missing
17:03:47.041 > Nothing received, resend whole request
17:03:47.085 > All missing
17:03:47.093 > Nothing received, resend whole request
17:03:47.101 > All missing
17:03:47.109 > Nothing received, resend count exeeded
17:03:47.707 > All missing
17:03:47.717 > Nothing received, resend whole request

[schlimmchen]

Begreif ich nicht. Hat sich an den Einstellungen des CMT etwas verändert? Ich hab ja ein HMT und keine Probleme...

[spcqike]

Nein. Daran hat sich nichts geändert.

Ich weiß allerdings nicht, wie lange ich kein Update gemacht habe. Wenn irgendwas die Kommunikation zerschossen hat, könnte das auch schon länger her sein. Wobei es dann wohl mehr issues geben würde. Und das letzte war ja wegen dem Proxy, oder?

[spcqike]

Ich weiß nicht hat genau warum, aber es scheint an den DTU Einstellungen zu liegen.

Ich habe in der Vergangenheit, da ich Signal Probleme hatte, die Frequenz und die sendeleistung leicht erhöht.

Damit der DTU den wechselrichter nach einem Update wieder findet oder anspricht, reicht es, in den DtU Einstellungen bspw verbose logging zu aktivieren und zu speichern. Den Rest kann ich so lassen wie es ist. Logging kann danach auch wieder aus gemacht werden. Hauptsache das speichern wird einmal ausgeführt.

Das konnte ich jetzt sowohl mit der Firmware aus dem PR als auch mit dem latest release und einem Release aus dem Februar reproduzieren.

So, es läuft also. Und irgendwie lag es (halb?) an mir. Aber dennoch komisch. Leider ist jetzt die Sonne weg um die Anpassung zu testen :)

Nachtrag;
Es reicht einfach so auf speichern zu drücken. Ohne Änderungen. Und auch ein reiner Neustart der DTU genüg für das Problem. Scheinbar.

[schlimmchen]

Und auch ein reiner Neustart der DTU genüg für das Problem. Scheinbar.

Sicher?

Es gab da jedenfalls Probleme mit den Einstellungen. Die hatten mit der Frequenzauswahl zu tun. Da musste man dann den Schieber einmal bewegen und speichern, sodass ein gültiger Wert abgespeichert wurde.

[spcqike]

Sicher?

grad nochmal getestet. Ja. Neustart, 30 Sekunden kein Empfang. Einstellungen ->DTU -> Speicher , 3 sek später die live Daten.

[hex2647]

@greymda @spcqike @hex2647 Please test this feature by flashing the firmware built in this PR's build-run.

Ist installiert und aktiviert... morgen ist bei mir keine Verschattung zu erwarten aber das lässt sich ja simulieren :) bin gespannt.

[AndreasBoehm]

Es sieht so aus als ob ich die Logik nochmal überarbeiten muss, habe zwei Eingänge mit 50W und zwei die bis zu 100w bekommen. Netzbezug ist auf -100W gestellt, trotzdem regelt die Überskalierung effektiv auf -200W.

Konnte jemand von euch ein ähnliches Problem feststellen?

[hex2647]

Das bisher noch nicht. Was mir vorhin aufgefallen war ist das er total instabil war, also das die Regelung extrem geschwankt hat… ich Versuch das nachher mal festzuhalten und besser darzustellen…

[spcqike]

Hab es auch grad getestet. Schwankt stark. Entweder voll offen (2.000W) oder das normale Limit, welches nicht ausreicht

hab zum testen 1 Paneel abgesteckt und das Target grad auf 800W gestellt.

[AndreasBoehm]

Danke fürs testen @spcqike und @hex2647.
Ich habe den Fehler für die instabile und schwankende Regelung und auch den Fehler in der Berechnung für das Limit behoben. Vorerst zähle ich einen Eingang der 95% des Limits liefert als nicht limitiert um bei minimalen Schwankungen nicht zu viel zu skalieren, was haltet ihr davon?

@schlimmchen Könntest du den workflow erneut freigeben um neue test builds bereitzustellen? Danke.

[schlimmchen]

Neue Firmware: https://github.com/helgeerbe/OpenDTU-OnBattery/actions/runs/9054654684

[spcqike]

Vorerst zähle ich einen Eingang der 95% des Limits liefert als nicht limitiert um bei minimalen Schwankungen nicht zu viel zu skalieren, was haltet ihr davon?

ich weiß nicht, ob das so hinkommt.

auto expectedPowerPerChannel = (newLimit / dcTotalChnls) * 0.95;

        size_t dcLimitedChnls = 0;
        auto limitedChannelPowerSum = 0.0;

        for (auto& c : dcChnls) {
            auto channelPower = inverter->Statistics()->getChannelFieldValue(TYPE_DC, c, FLD_PDC);

            if (channelPower < expectedPowerPerChannel) {
                dcLimitedChnls++;
                limitedChannelPowerSum += channelPower;
            }
        }

vielleicht verstehe ich auch nur die Variablen falsch, aber sollte man nicht die nicht begrenzten Eingänge zählen? und sollte man nicht gegen das alte Limit vergleichen? Sollte es nicht eher so werden?

auto expectedPowerPerChannel = (currentLimitWatts/ dcTotalChnls) / 0.95;

        size_t dcNotLimitedChnls = 0;
        auto notLimitedChannelPowerSum = 0.0;

        for (auto& c : dcChnls) {
            auto channelPower = inverter->Statistics()->getChannelFieldValue(TYPE_DC, c, FLD_PDC);

            if (channelPower < expectedPowerPerChannel) {
                dcNotLimitedChnls ++;
                notLimitedChannelPowerSum += channelPower;
            }
        }

        if (dcNotLimitedChnls == 0 || dcNotLimitedChnls == dcTotalChnls) { return newLimit; }

        auto overScaled = static_cast<int32_t>((newLimit - notLimitedChannelPowerSum ) /(dcTotalChnls-dcNotLimitedChnls) * dcTotalChnls);

        MessageOutput.printf("[DPL::scalePowerLimit] %d/%d channels are producing less than expected, "
                "scaling from %d to %d W\r\n", dcNotLimitedChnls , dcTotalChnls, newLimit, overScaled);
        return overScaled;

Wie oben geschrieben, müsste 1. anhand des aktuell gültigen Limits verglichen werden. (Wenn das Limit bspw. von 1000W auf 300W fällt, und man die aktuelle DC Leistung gegen das neue Limit vergleicht, liefern alle DC Eingänge zu viel)
Dann müsste 2. herausgefunden werden, welche Eingänge NICHT durch das Software-Limit begrenzt sind (sondern durch Verschattung). die Summe der "unter performenden" Eingänge und deren Leistung ist wichtig.

Ob man nun fixe 95% annimmt, oder die aktuelle Effizienz, oder den Wert einfach bei 1 belässt (immerhin wird die erwartete DC Leistung dadurch nur erhöht. DC-seitig liefern die Eingänge immer mehr, als man AC-seitig haben will.), kann man ja einfach ausprobieren.

Was man vielleicht noch einbauen sollte

 if (newLimit < currentLimitWatts) { return newLimit; }

Die Skalierung braucht nicht gemacht zu werden, wenn das Limit sich verkleinert. Die Berechnung

auto overScaled = static_cast<int32_t>((newLimit - limitedChannelPowerSum) / dcNonLimitedChnls * dcTotalChnls);

wird nicht sinnvoll klappen, wenn das neue Limit, durch Verbrauchsreduzierung, wesentlich kleiner wird. im Gegenteil, extrem Beispiel: das alte LImit war 800W, das neue ist 50W. Was passiert da?

[AndreasBoehm]

vielleicht verstehe ich auch nur die Variablen falsch, aber sollte man nicht die nicht begrenzten Eingänge zählen? und sollte man nicht gegen das alte Limit vergleichen? Sollte es nicht eher so werden?
Ich hab die Variablen umbenannt um deutlich zu machen das in meinem Fall "limited" ein "limited by shading" war und nicht "limited by inverter limit". Eventuell kannst du mit dieser Info meine Berechnungen nachvollziehen.

auto expectedPowerPerChannel = (currentLimitWatts/ dcTotalChnls) / 0.95;

Hast du hier eine Effizienz von 95% angenommen um den AC wert von 'currentLimitWatts' in DC zu wandeln?

    size_t dcNotLimitedChnls = 0;
    auto notLimitedChannelPowerSum = 0.0;

    for (auto& c : dcChnls) {
        auto channelPower = inverter->Statistics()->getChannelFieldValue(TYPE_DC, c, FLD_PDC);

        if (channelPower < expectedPowerPerChannel) {
            dcNotLimitedChnls ++;
            notLimitedChannelPowerSum += channelPower;
        }
    }

    if (dcNotLimitedChnls == 0 || dcNotLimitedChnls == dcTotalChnls) { return newLimit; }

    auto overScaled = static_cast<int32_t>((newLimit - notLimitedChannelPowerSum ) /(dcTotalChnls-dcNotLimitedChnls) * dcTotalChnls);

    MessageOutput.printf("[DPL::scalePowerLimit] %d/%d channels are producing less than expected, "
            "scaling from %d to %d W\r\n", dcNotLimitedChnls , dcTotalChnls, newLimit, overScaled);
    return overScaled;

Wie oben geschrieben, müsste 1. anhand des aktuell gültigen Limits verglichen werden. (Wenn das Limit bspw. von 1000W auf 300W fällt, und man die aktuelle DC Leistung gegen das neue Limit vergleicht, liefern alle DC Eingänge zu viel) Dann müsste 2. herausgefunden werden, welche Eingänge NICHT durch das Software-Limit begrenzt sind (sondern durch Verschattung). die Summe der "unter performenden" Eingänge und deren Leistung ist wichtig.

Du hast recht, da hatte ich einen Fehler in meiner Logik, ich werde den Code anpassen und das aktuelle Limit verwenden um zu ermitteln ob ein Eingang verschattet ist.

Ob man nun fixe 95% annimmt, oder die aktuelle Effizienz, oder den Wert einfach bei 1 belässt (immerhin wird die erwartete DC Leistung dadurch nur erhöht. DC-seitig liefern die Eingänge immer mehr, als man AC-seitig haben will.), kann man ja einfach ausprobieren.

Ich denke du vermischt hier zwei Dinge a) AC <-> DC Umwandlung und die Effizienz davon und b) Threshold der z.b. auch bei 61 Watt bei geforderten 64 Watt den Eingang als non shaded wertet.

a) werde ich sobald die Regelung klappt noch mit einbauen, denn nur dann entspricht das Limit auch wirklich dem was man erwartet.
b) sollten wir diskutieren, aktuell nutze ich hier 95%

Was man vielleicht noch einbauen sollte

 if (newLimit < currentLimitWatts) { return newLimit; }

Das kann man pauschal so nicht machen, denn newLimit wird immer kleiner sein als currentLimitWatts wenn wir aktuell im 'Overscaling' sind, auch kann das neue Limit kleiner sein aber es trotzdem bedarf geben eine Verschattung auszugleichen.

Die Skalierung braucht nicht gemacht zu werden, wenn das Limit sich verkleinert. Die Berechnung

auto overScaled = static_cast<int32_t>((newLimit - limitedChannelPowerSum) / dcNonLimitedChnls * dcTotalChnls);

wird nicht sinnvoll klappen, wenn das neue Limit, durch Verbrauchsreduzierung, wesentlich kleiner wird. im Gegenteil, extrem Beispiel: das alte LImit war 800W, das neue ist 50W. Was passiert da?

Dafür gibt es eine extra Abfrage die einfach newLimit zurück gibt wenn alle Eingänge die Erwartungen erfüllen. Gibt dann ja keinen 'shaded channel'.

[AndreasBoehm]

Was man vielleicht noch einbauen sollte

 if (newLimit < currentLimitWatts) { return newLimit; }

Die Skalierung braucht nicht gemacht zu werden, wenn das Limit sich verkleinert.

Da wir nun 'currentLimitWatts' zur Berechnung nutzen habe ich verstanden warum du diesen Vorschlag bringst.
Ich würde vorschlagen das wir in dem fall aber dann einfach mit 'newLimit' prüfen ob wir einen verschatteten Eingang haben um gleich korrekt zu skalieren. Was denkst du?

[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: #1025

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

[schlimmchen]

Beautiful ❤️

[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 #1025 (comment)

Thanks a lot for your support on this

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

[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 (#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