Optimierung der DPL-Powermeter Regelgeschwindigkeit[Request]

SW-Niko commented 6 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 6 months ago

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

Grüsse

greymda commented 6 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 6 months ago

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

poolcat4711 commented 6 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 6 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 4 months 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 4 months 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 4 months 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 4 months 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 4 months 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 4 months 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 4 months 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 4 months 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 3 months 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?

schlimmchen commented 3 months ago

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.

Das ist mir auch ein Dorn im Auge. Allerdings befürchte ich, dass wir das nicht rauskriegen können, weil wir weder (hinreichend gut) synchronisierte Uhren haben noch einen Zeitstempel, der am PowerMeter-Wert hängt. Bestenfalls könnte man eine Heuristik bauen: Wenn sich der PowerMeter-Wert ungefähr um den erwarteten Wert geändert hat, nehmen wir einfach an, dass es der neue Wert sein muss. Das lohnt sich aber vermutlich nicht.

Mehr Potential steckt darin, die Schleife um die Kommunikation mit den Inverter kürzer zu machen. Woanders habe ich es schonmal erwähnt: Im Discord habe ich mitbekommen, dass AhoyDTU inzwischen keine Pause mehr macht zwischen dem Abarbeiten der Nachrichten der Inverter, sondern nur noch am Ende der Schleife. Und auch am Ende der Schleifen kann man vermutlich auch einfach weniger lange warten (unter einer Sekunde, z.B. nur 250ms)?

gitisgreat2023 commented 3 months ago

@Robert-Schimanek Cool! Kommt dieses feature auch im offiziellen release? Einen schnelleren Huawei response würde ich gerne nutzen...

@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.

Robert-Schimanek commented 3 months ago

Mehr Potential steckt darin, die Schleife um die Kommunikation mit den Inverter kürzer zu machen. Woanders habe ich es schonmal erwähnt: Im Discord habe ich mitbekommen, dass AhoyDTU inzwischen keine Pause mehr macht zwischen dem Abarbeiten der Nachrichten der Inverter, sondern nur noch am Ende der Schleife. Und auch am Ende der Schleifen kann man vermutlich auch einfach weniger lange warten (unter einer Sekunde, z.B. nur 250ms)?

Die Reduktion der vielen Wartestadien im DPL habe ich seit ein paar Wochen implementiert, und es läuft soweit gut: siehe hier GitHub-Link.

Weiter beschleunigt habe ich es durch ein externes Shelly-Modul am Hoymiles, da so die Statistik dann nicht abgerufen werden muss. Ich habe auch am Ladegerät einen externen Leistungswert eingebunden (das hilft allerdings mehr zwecks Genauigkeit und weniger für die Geschwindigkeit).

Das größte Hindernis bei der Reduktion der Regelgeschwindigkeit des DPL ist meiner Meinung nach der MPPT des Hoymiles. Dieser braucht einfach 1 bis 2 Sekunden, um sich auf einen Leistungswert einzupendeln (teilweise überschwingt er auch, aber das ist eine andere Geschichte). Ich habe das Erreichen, das Berechnen, das Senden des Kommandos an der DTU und die erreichte Leistung am Hoymiles gemessen. Der MPPT reagiert meist erst nach 1 bis 2 Sekunden.

Robert-Schimanek commented 3 months ago

@Robert-Schimanek Cool! Kommt dieses feature auch im offiziellen release? Einen schnelleren Huawei response würde ich gerne nutzen...

Ich habe das für mein kleines Balkonkraftwerk gemacht, weil ich auf da auf die genaue Regelung der Leistung angewiesen bin. Für die meisten, die ordentlich viel Glas auf dem Dach haben, ist das alles nicht nötig. Falls es adaptiert wird, nur zu. Leider habe ich die Änderungen nicht so ordentlich committet und dokumentiert, aber die relevanten Dinge sind unter Github-Link zu finden.

schlimmchen commented 3 months ago

Weiter beschleunigen kann man es durch externe Shelly-Module am Hoymiles

Siehe #899 (und andere).

Robert-Schimanek commented 3 months ago

Weiter beschleunigen kann man es durch externe Shelly-Module am Hoymiles

Siehe #899 (und andere).

Genau, die Inspiration kam von dort! Ich habe den Shelly Dirty per MQTT über die PowerMeter-Klasse eingebunden.

poolcat4711 commented 3 months ago

noch einen Zeitstempel, der am PowerMeter-Wert hängt

Am MQTT vom Hichi hängt einer mit Sekundenauflösung ("Time": "2024-07-17T17:33:41") - am Shelly einer mit hundertsteln ( "ts": 1721234067.61). Von da ab könnte man den Zeitversatz ESP<->Shelly ermitteln und dadurch bei eingehenden Werten prüfen, ob das davor oder danach geschickt wurde. Das wäre aber auch echt aufwand, da das Script mehrere TS Codierungen verstehen muss.

Mal so aus Neugier - sind die 2 Sekunden Verzögerung bei den HMS/CMT2300A Modellen auch vorhanden?

schlimmchen commented 3 months ago

Das hilft alles nichts, weil der Offset nicht bekannt ist.

Mal so aus Neugier - sind die 2 Sekunden Verzögerung bei den HMS/CMT2300A Modellen auch vorhanden?

Die 2 Sekunden, die der PowerMeter Wert neuer sein muss als die Statistik des Inverters ist völlig unabhängig vom Modell oder RF Teil, also ja, die gibt es auch bei HMS-Invertern.

poolcat4711 commented 3 months ago

Das hilft alles nichts, weil der Offset nicht bekannt ist.

Der kann einfach angenähert werden sobald die MQTT Nachricht reinkommt bspw. mit einem 10er rolling average: offset += ((ESP_TS - MQTT_TS) - offset)/10

und dann wäre

MQTT_TS + offset > last_set_TS (+200ms grace oder so)

die bedingung ob der geänderte wert schon drin ist =) Aber ich sag ja, dass ist relativ viel kung fu....

Robert-Schimanek commented 3 months ago

Das hilft alles nichts, weil der Offset nicht bekannt ist.

Der kann einfach angenähert werden sobald die MQTT Nachricht reinkommt bspw. mit einem 10er rolling average: offset += ((ESP_TS - MQTT_TS) - offset)/10

und dann wäre

MQTT_TS + offset > last_set_TS (+200ms grace oder so)

die bedingung ob der geänderte wert schon drin ist =) Aber ich sag ja, dass ist relativ viel kung fu....

Genau! Bei mir erhält jeder empfangene Leistungswert im Powermeter einen Empfangsstempel, der der Messzeit an den Shellies entspricht, plus einem mehr oder weniger konstanten Offset. Meine Shellies senden im 750-ms-Intervall per MQTT und diesen Takt sieht man auch wunderbar im HA. Die Messstempel von Shelly sind meines Erachtens daher nicht nötig, da der Offset zwischen Messung und Empfang an der DTU fast konstant. Der Offset / die Laufzeit wird durch einen Parameter im Powerlimiter angepasst und abgefangen, und ggf auf Inverter Statisik umgeleitet. Setzt natürlich einen potenten MQTT Broker voraus...

schlimmchen commented 3 months ago

Aber ich sag ja, dass ist relativ viel kung fu....

Ich find das absolut überschaubar. Ich würds gerne benutzen. Aber leider begreife ich nicht, wie dein Vorschlag funktioniert... Ich glaube, du versuchst mir zu zeigen, wie man den Offset zwischen den Uhren der beiden Teilnehmer mittelt. Was aber gebraucht wird ist die Info, wie alt der Wert ist, wenn er am OpenDTU-OnBattery-ESP angekommen ist und ob der wohl schon den neuen Output des WR berücksichtigt.

github-actions[bot] commented 2 months ago

This issue has been automatically locked since there has not been any recent activity after it was closed. Please open a new discussion or issue for related concerns.

hoylabs / OpenDTU-OnBattery