-
Notifications
You must be signed in to change notification settings - Fork 66
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
feature: DPL: allow overscaling to compensate for shading #956
feature: DPL: allow overscaling to compensate for shading #956
Conversation
ddec3cf
to
3d235d8
Compare
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
3d235d8
to
c1e6989
Compare
@AndreasBoehm I allowed myself to rebase this onto the current development branch before asking users to review your work. |
@greymda @spcqike @hex2647 Please test this feature by flashing the firmware built in this PR's build-run. |
i don't have access any more to the partially shaded setup :( |
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. |
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? |
Kein peoxy. Direkt die IP der openDTU. Er empfängt gar nichts vom wechselrichter Naja. Da steht nicht viel.
|
Begreif ich nicht. Hat sich an den Einstellungen des CMT etwas verändert? Ich hab ja ein HMT und keine Probleme... |
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? |
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; |
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. |
grad nochmal getestet. Ja. Neustart, 30 Sekunden kein Empfang. Einstellungen ->DTU -> Speicher , 3 sek später die live Daten. |
Ist installiert und aktiviert... morgen ist bei mir keine Verschattung zu erwarten aber das lässt sich ja simulieren :) bin gespannt. |
c51453c
to
7b675cb
Compare
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? |
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… |
Danke fürs testen @spcqike und @hex2647. @schlimmchen Könntest du den workflow erneut freigeben um neue test builds bereitzustellen? Danke. |
ich weiß nicht, ob das so hinkommt.
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?
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) 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
Die Skalierung braucht nicht gemacht zu werden, wenn das Limit sich verkleinert. Die Berechnung
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? |
Hast du hier eine Effizienz von 95% angenommen um den AC wert von 'currentLimitWatts' in DC zu wandeln?
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.
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 a) werde ich sobald die Regelung klappt noch mit einbauen, denn nur dann entspricht das Limit auch wirklich dem was man erwartet.
Das kann man pauschal so nicht machen, denn
Dafür gibt es eine extra Abfrage die einfach |
Da wir nun 'currentLimitWatts' zur Berechnung nutzen habe ich verstanden warum du diesen Vorschlag bringst. |
@AndreasBoehm Hast du einen ESP32 mit mind. 8MB Flash und kannst das Feature auch ab dem nächsten Release begleiten? |
@schlimmchen Fusion Board mit 8MB liegt schon bereit 👍 |
@AndreasBoehm Also wird das aufgeräumte / zusammengeführte Release dann schon nicht mehr auf den 4MB ESPs funktionieren? |
@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? |
560b519
to
e5038d4
Compare
@hex2647
@schlimmchen Ich hab aufgeräumt und der PR wäre von meiner Seite aus jetzt fertig. |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Beautiful ❤️
Thanks a lot for your support on this @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)
@AndreasBoehm You are very welcome. Let me know if you are interested in tackling another feature 😉 |
@schlimmchen Jetzt habe ich mir gestern frisch ne Fusion DTU bestellt, um up-to-date zu bleiben… 🤪🫣 |
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. |
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? |
@hex2647 |
Ah ok da wird mir nichts angezeigt dann hab ich wohl keine passende Version installiert :) |
@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. |
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 :)
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 :) 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. |
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. 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. |
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. 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. |
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. |
@AndreasBoehm Im Falle der Scrennshots waren es 2.000 W Limit bei aktiviertem DPL. 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. 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. |
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. |
Okay, werde ich mal genauer dokumentieren. Also nicht hier fortführen? |
Hey! |
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. |
@schlimmchen Kannst du hier zu machen? Danke |
Fixes #917 based on the discussion #819
Notes
Console