Optimierung der DPL-Powermeter Regelgeschwindigkeit[Request]

SW-Niko commented 2 months ago

Is your feature request related to a problem? Please describe.

Das zeitverzögerte Anpassen des Inverter-Limits bei Lastsprünge wirkt sich negativ auf die Effektivität des Systems aus.

Describe the solution you'd like

Schnelleres optimiertes Anpassen des Inverter-Limits bei Lastsprüngen

Describe alternatives you've considered

Um die Effektivität der Regelung zu erhöhen habe ich den Inverter mit dem Powermeter synchronisiert und die Regelgeschwindigkeit erhöht. Aktuell laufen die beiden Prozesse „Regelung des Inverters“ und „Auslesen Powermeters“ nur bedingt synchronisiert.

grafik

Currently: Der Lastsprung wird zeitverzögert ausgeregelt New: Der Lastsprung wird schneller ausgeregelt.

Additional context

Vorteile:

Die höhere Auslesefrequenz verringert die Zeitverzögerung zwischen registrierter Laständerung und der Inverter stellt ein neues Limit ein.
Die Synchronisierung des Powermeters mit dem Inverter verringert die Zeitverzögerung nachdem der Inverter ein neues Limit eingestellt hat und bis ein neuer Powermeter Wert akzeptiert wird.
Die Synchronisierung des Powermeters mit dem Inverter verhindert ein asynchron bedingtes Schwingen der Regelung.
Das Lesen eines neuen Wertes vom Powermeter wird automatisch an die schwankende Einstellzeit des Inverters (Bei mir 2-3Sek) optimiert.

Auf meinem System läuft seit 26.04.24 die neue Regelung.

Probleme:

Diese Regelung ist für mein System mit einem Shelly 3EM (http+Json) optimiert. Bei anderen Powermetern (Z.B. Auslesen über Mqqt) ist der 2 Sekunden Zyklus vermutlich viel zu schnell.
Mir ist bis jetzt auch keine praktikable Lösung eingefallen, wie diese Zeitanpassung für alle Systeme automatisiert werden kann. Eine Konfiguration ist sicherlich möglich, birgt aber Risiken. Zum Beispiel wenn der Wert für das System zu niedrig eingestellt wird dann kommt es zu Regelschwingungen.
Ich kenne die anderen Powermeter zu wenig. Ich kann nicht beurteilen, ob die neue Methode auch ihnen funktionieren würde.

Ich wollte ersten Schritt diese Optimierung mal vorstellen und eine Diskussion über den Nutzen und die Risiken anstoßen.

DonJohnLong commented 2 months ago

Klingt sehr gut, habe auch eine 3em und würde mich allenfalls als tester melden.

Grüsse

greymda commented 2 months ago

@SW-Niko what if to go a step further and implement as a combination with https://github.com/helgeerbe/OpenDTU-OnBattery/issues/899 ?

anyhow, if you need tests I can participate.

p.s. great idea!

gitisgreat2023 commented 2 months ago

@SW-Niko Cool! Wäre das auch möglich für den Huawei charger?

poolcat4711 commented 2 months ago

Moin,

ich mische mich mal ein. Mein Setup - 3kwp an 15kwh, Shelly 3EM an der Hauptleitung und einen Hichi am Zähler.

Als DPL Steuerung benutze ich nicht ODTUoB, sondern habe es seit dem Start des Systems via NodeRed umgesetzt. Daher habe ich einige Fehler schon gesehen u kann berichten =)

Der Shelly hat mit den alten FWs gut funktioniert, bei den neueren ist er allerdings sowohl über MQTT als auch über webapi zu langsam. Man bekommt für ca. 3 Sekunden stets denselben Wert, obwohl bspw. das Web Frontend andere anzeigt. Egal ob man den Eco mode rein oder raus macht, ist es so. Bei älten FWs war das update intervall bei beiden zackiger.

Der Tasmota meldet nur im Telemetrie Intervall. Setzt man allerdings wie in der Anleitung beschrieben das letzte Byte anders (https://sites.google.com/view/hichi-lesekopf/faq#h.d0hovl5gmixp), sendet er mindestens einmal die Sekunde - meist sogar mehr.

Da ich via NodeRed keine Rückmeldung bekomme, ob ODTUoB den Wert am Hoymiles eingestellt hat, weiss ich auch wie @SW-Niko nicht, wann ich dem Wert vertrauen kann (Sprich, wann die eingestellte HM Leistung wirklich anliegt und der Hichi Wert das reflektiert).

Es läuft daher folgendermaßen:

der berechnete Wert wird eingestellt, wenn a) seit dem letzten senden 4 Sekunden vergangen sind (2 Sekunden Einstellzeit am HM via NRF + 1 Sekunde Hichi intervall + 1 Sekunde grace) und b) der Wert über meiner Hysterese von 10W liegt
nach 20 Sekunden seit dem letzten Senden, wird der aktuelle Wert eingestellt

Dadurch spricht das System sehr schnell auf grosse Veränderungen an und "übergeht" die Hysterese nach 20 Sekunden. Letzteres hat auch den Vorteil (da ich ja keine "Erfolgsmeldung" bekomme), dass das System nicht auf Maximum "hängen" bleibt - wenn genau dieser Max Wert nicht durchgegangen ist und dementsprechend der aktuelle Verbrauch immer über dem liegt was ich einspeisen kann.

Bei den Akku Lade-/Entladeregeln habe ich auch einige Feinheiten mehr als ODTUoB aktuell hat - bei Interesse, kann ich die auch mal ausführen oder meinen Flow zur Verfügung stellen =)

SW-Niko commented 2 months ago

Hallo @poolcat4711 ,

Der Shelly hat mit den alten FWs gut funktioniert, bei den neueren ist er allerdings sowohl über MQTT als auch über webapi zu langsam. Man bekommt für ca. 3 Sekunden stets denselben Wert, obwohl bspw. das Web Frontend andere anzeigt.

Das kann ich bei meinem Shelly nicht beobachten. Allerdings arbeite ich mit einem anderem Zeitschema.

Ich frage das Shelly 3EM immer in einem festen 2 Sekunden Rhythmus ab.
Mit Eco Mode dauert es im Schnitt 100ms bis ich Werte bekomme
Ohne Eco Mode dauert es im Schnitt 60ms bis ich Werte bekomme
Die Werte sind fast immer unterschiedlich, wenn auch nur in der letzten Kommastelle
Ungefähr 1mal in der Stunde kommt es zu einem Timeout und ich bekomme keine Werte. (Damit kann ich Leben)
Auf dem Shelly habe ich die FW "20230913-114244/v1.14.0-gcb84623"
Läuft jetzt seit über 2 Wochen auf meinem System mit einer Reaktionszeit von 0-2 Sekunden + Inverter-Einstell-Zeit

Jetzt stellt sich die Frage warum reagieren unsere Shelly's so unterschiedlich?

Wie ich sehe hast du die Zeiten bei dir optimal an dein System angepasst. Du hast das im Griff. 👍

Und genau hier habe ich ein Problem .... Ich suche nach einer Lösung, die bei jedem System automatisch das Optimum (Zeitliche Regelung) herausholt. Leider habe ich noch keine vernünftige Idee wie das funktionieren könnte. 😞

Matti07 commented 2 weeks ago

Moin @SW-Niko, PERFEKT! Ich verstehe nur leider nicht, warum Du das auf Teufel komm raus automatisieren willst. Mir gefällt der Vorschlag von @eu-gh sehr gut, das über das UI einzustellen. Ich denke, wer ODoB insgesamt zum fliegen bekommt, wird an einem einzelnen Parameter nicht scheitern. Dazu noch ein paar Sätze wie man das Ergebnis am besten kontrollieren kann sollten ausreichen. Das hätte auch den Vorteil, daß diese Optimierung schneller zur Verfügung stände für die Ungeduldigen - wie mich z.B. ... In ca. 2 Wochen kann ich auch gerne den Tester machen, dann sollte meine Anlage (Shelly 3EM, Pylontech, HM2000, OpenDTU Fusion mit CAN/Iso Shield) laufen.

Robert-Schimanek commented 2 weeks ago

@SW-Niko Cool! Wäre das auch möglich für den Huawei charger?

Das Huawei-Update-Intervall kann man verkleinern, was einen spürbaren Effekt hat. Ich habe es bei mir im fork, wie oben vorgeschlagen, in der Benutzeroberfläche einstellbar gemacht. Seit ein paar Wochen habe ich es auf 500 ms eingestellt. Das Netzteil reagiert laut meiner Shelly ultra schnell. Es hat bei mir definitiv den Vorteil, dass das huawei spürbar weniger aus dem Netz zieht bei wolkigem Wetter oder Lastwechsel.

poolcat4711 commented 2 weeks ago

Das Huawei-Update-Intervall kann man verkleinern, was einen spürbaren Effekt hat.

Vielleicht wäre das einen Change Request wert! Ich habe genau dasselbe Problem mit den Victron Werten. Das Minimum Intervall von 5 Sekunden ist viel zu lang. Ich weiss das der Vic nur jede Sekunde sendet - warum also eine "Limitierung" die komplett unnötig ist? Man kann das Standardintervall ja auf 5s belassen und dem der sich einliest ein wenig Spielraum lassen.

@schlimmchen - wie siehst du das?

SW-Niko commented 2 weeks ago

Hallo Zusammen, vielen Dank für das Interesse. Aber momentan bin ich noch an dem Battery-Limiter dran. Das dauert leider viel länger als geplant und ich will jetzt kein neues Fass aufmachen ....

Ich mit nicht so Multi-Tasking fähig wie @schlimmchen 😞

Ihr müsst euch noch etwas gedulden. Mist....Diesen Satz schreibe ich öfter in letzter Zeit.

schlimmchen commented 2 weeks ago

@schlimmchen - wie siehst du das?

Ich hab keine Ahnung, was du meinst... Wo ist ein Minimum-Intervall von 5s im Kontext der Victron-Laderegler?

poolcat4711 commented 2 weeks ago

Das MQTT Veröffentlichungsintervall - irgendwie war ich der Meinung, dass das früher mal unterhalb des Victrons war. Mit den 5 Sekunden die man leider nicht geringer machen kann, läuft meine eigene Steuerung etwas "versetzt". Ich wollte keinen eigenen Fork machen...

schlimmchen commented 2 weeks ago

Achso, das kann man in der UI nicht auf weniger als 5 Sekunden setzen... Verstanden. Da hatten wir in #1062 eine Diskussion zu. Meine Meinung dazu lautet, dass neue Messwerte genau veröffentlicht werden sollten beim Broker, wenn sie zur Verfügung stehen. Der Ansatz, das nur alle "MQTT publich interval" Sekunden zu machen, kommt von Thomas, und ich kenne den Grund nicht. Auch im Upstream könnte man genau dann etwas an den Broker schicken, wenn man eine neue Rückmeldung von einem Inverter hat.

Wie dem auch sei, ich schreib mir wieder die Finger wund.

Als Workaround versuch doch mal die config.json herunterzuladen, den Wert zu editieren, und die config.json wieder einzuspielen. Das sollte als Workaround für dich funktionieren.

poolcat4711 commented 2 weeks ago

Wow Knaller - 1000 Dank! Updates kommen jetzt im Sekundentakt rein - das reicht völlig für die Steuerung.

Und ja, ich teile deine Meinung. Gerade bei MQTT und wenn man eh Werteänderungen sendet, macht ein Sendeintervall recht wenig Sinn...

SW-Niko commented 7 hours ago

Hallo @schlimmchen , ich denke wir können diesen feature request ebenfalls schließen. Mit dem #1077 und einem Abfrageintervall von 1 Sekunde inclusive der 2 Sekunden Zusatzverzögerung nach einem Powermeter update ist nichts mehr offen.

Mir ist auch nichts vernünftiges eingefallen, wie man die Zusatzverzögerung (jetzt fest auf 2 Sekunden) automatisch vom System ermitteln und optimieren könnte. Thema: Schwingneigung.

Was meinst du?

helgeerbe / OpenDTU-OnBattery