Optimierung der DPL-Powermeter Regelgeschwindigkeit[Request] about opendtu-onbattery HOT 25 CLOSED

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)?

from opendtu-onbattery.

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

Siehe #899 (und andere).

from opendtu-onbattery.

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

Grüsse

from opendtu-onbattery.

@SW-Niko what if to go a step further and implement as a combination with #899 ?

anyhow, if you need tests I can participate.

p.s. great idea!

from opendtu-onbattery.

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

from opendtu-onbattery.

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 =)

from opendtu-onbattery.

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

from opendtu-onbattery.

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.

from opendtu-onbattery.

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

from opendtu-onbattery.

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?

from opendtu-onbattery.

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.

from opendtu-onbattery.

@schlimmchen - wie siehst du das?

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

from opendtu-onbattery.

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

from opendtu-onbattery.

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.

from opendtu-onbattery.

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

from opendtu-onbattery.

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?

from opendtu-onbattery.

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

from opendtu-onbattery.

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.

from opendtu-onbattery.

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

from opendtu-onbattery.

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.

from opendtu-onbattery.

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?

from opendtu-onbattery.

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.

from opendtu-onbattery.

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

from opendtu-onbattery.

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

from opendtu-onbattery.

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.

from opendtu-onbattery.