Fix: DPL: ensure inverter reaches requested state #708
Conversation
we previously only called commitPowerLimit() if the desired limit changed such that the change was bigger than the hysteresis. we found that if the limit update was not received and the desired limit would not change much, the limit of the inverter was wrong for a long time. to mitigate this, we introduced re-sending the limit update every 60 seconds, regardless of what the limit reported by the inverter was at that time. if the power-up command was not received, we also would repeat it only once every 60 seconds. this leads to a new kind of staleness and the actual inverter state was still not matching the desired state. this new approach effectively adds an additional control loop at the start of the DPL loop(). that new function compares the requested inverter state to the actual reported state. it sends updates (limit update or power on state) until the desired inverter state is reached, or until a (hard-coded) timeout occurs. this approach also allows us to send power-up, power-down, and limit update commands independent from one another and in a particular order. this should make sure that the inverter is in the desired state even if conditions change slowly and commands were not received as expected.
|
@chrisli01 Schau mal hier: https://github.com/helgeerbe/OpenDTU-OnBattery/actions/runs/8132571854?pr=708 Es wäre schön, wenn du das passende Artefakt dieses Pull-Request-Builds einmal auf deine Anlage spielen würdest und hoffentlich bestätigen kannst, dass du deinen Wechselrichter nun nicht mehr im Standby erwischst. Jedenfalls nicht für länger. Die Änderungen in diesem PR sollten sicherstellen, dass der Wechselrichter den gewünschten Zustand tatsächlich erreicht, egal wie oft ein Kommando an ihn verloren geht. Erst dann gibt es den nächsten DPL-Durchlauf. |
|
Gern. Mein wechselrichter sollte zwar nie stoppen, ich habe ja nur einen, aber schaden kann es ja auch nicht 😄 eine Frage: woran erkenne ich bei solchen PR-Versionen, ob ich tatsächlich die richtige installiert habe? |
Hi! Kann mich gerne beteiligen, wobei ich die Probleme nicht hatte bei mir. Von daher ist die Frage, ob das hilfreich ist. |
|
@dk7td Auch wenn du keine Probleme hattest, ist es sehr hilfreich zu wissen, dass du auch mit diesen Änderungen keine Probleme hast 😊 Dieser Pull-Request ist noch nicht im development branch enthalten und dementsprechend auch noch nicht released. Daher habe ich den Link https://github.com/helgeerbe/OpenDTU-OnBattery/actions/runs/8132571854?pr=708 oben eingefügt: Der führt zu den Artefakten, die aus dem Bau dieses PR entstehen, da sind diese Änderungen also drin. Überprüfen kannst du das nach einem Firmware-Update unter Info->System in der WebApp, da steht dann |
Ok, alles klar. Mach ich gerne. |
|
Alles richtig. Danke für eure Hilfe und schon jetzt für eure Rückmeldung 😉 [Ich musste gerade etwas dazulernen. Bei solch einem PR build run macht github einen merge, siehe https://github.com/helgeerbe/OpenDTU-OnBattery/commit/0a5073d. Daher kommt dieser Commit-Hash. Der ist kein Teil von irgendeinem Branch, jedenfalls nicht im öffentlichen Teil des Repos, sondern nur lokal auf dem Rechner, der die Firmware dann baut. Daher wird der Branch "master" angezeigt in der Web UI, obwohl das nicht stimmig ist. Vielleicht kann man da noch nachbessern, aber das ist echt nice-to-have und sonst nichts.] |
Siehe #709 😊 (gilt natürlich noch nicht, erst für jeden neuen PR, sobald @helgeerbe #709 ge-merge't hat). |
|
Guten Morgen, Welche muss ich einspielen? Die Factory? |
Hieß factory nicht Factory-Reset? Ich hab bisher immer die generic genommen. |
|
habs eingespielt! muss ich Einstellungen anpassen oder einfach mal so laufen lassen und schaun ob der WR immer „aufgeweckt“ wird!?? |
Einfach laufen lassen und melden, falls er sich doch wieder verklemmt oder melden, wenn er sich so lange nicht verklemmt hat dass du dir sicher bist, dass meine Änderung ein Fortschritt für dich ist. |
ist das korrekt so? bei mir steht bei der Versionsnummer komischerweise kein g davor …
|
|
Naja, nicht mehr jedenfalls, oben hast du ja einen Screenshot geteilt, bei dem auch du das "g" davor hast. Ich weiß leider nicht, wann es da steht und wann nicht. Jedenfalls ist das richtig so, der GIT Hash ist korrekt. |
|
Interrupt received |
|
Hat zugeschaltet ohne manuellen Neustart! |
Achje, schreibt das doch zuerst, dann such ich mir keinen Wolf in dem Log und frag mich "sieht doch aber gut aus" 😁 Schön zu lesen, danke! |
|
😂😂 Leistung aus dem Netz aktualisiert sich auch schön, ist bei der letzten Version gesteckt. |
|
Ich habs heute mal genauer beobachtet. Kann es sein, dass die neue Regelung die Hystere etwas mehr ausreizt oder gar überschreitet? in meinem Fall sollten es -20W Netzbezug bei 10W Hysterese sein. also eine Einspeisung von 10W bis 30W. ich sehe sehr oft Werte > 30W, der DPL meldet aber kleinere Differenzen und sagt "alles ok" Wahrscheinlich kommen die Abweichungen einfach durch Rundungsfehler in der neuen Berechnung, oder? hier ein Auszug von heute, skaliert auf 0 bis -50W hier ein Auszug von vor dem Update da lag die Regelung näher am Zielwert :) in meinem Fall ist es wohl eher informativer Natur, da ich ja ein reines PV System betreibe und mir es, mehr oder weniger, egal ist, ob ich 10W mehr einspeise oder auch nicht. Bei Akkusystemen kann das aber, je nach Zielwert, ärgerlich werden, oder? Und, ob die Abweichung mit kleinen Wechselrichtern, wie meinem HM-600, anders ist als mit einem hm-1500 bspw, kann ich grad nicht abschätzen, würde es aber nicht ausschließen :D |
|
Die Hysterese wird nun etwas anders interpretiert. Da das vom Inverter genannte Limit nun bekannt ist, wird das neu errechnete Limit mit diesem verglichen. Nur wenn diese Werte hinreichend voneinander abweichen, wird ein neues Limit geschickt. Vorher wurde das zuletzt angefragte Limit mit dem neu berechneten Limit vergleichen. Das vorher zuletzt angefragte Limit und das jetzt gemeldete Limit sind aber nicht derselbe Wert, weil der Inverter rundet. Meiner rundet scheinbar immer ab. Vermutlich rundet auch dein HM-600 auf 1% Schritte. Laut deinem Log hat der Wechselrichter 258W eingestellt, das entspricht genau 43%. Der DPL will jetzt 251W, aber das ist nur 7 Watt vom aktuell gemeldeten Limit entfernt. Daher kein Update. Was du erwartest ist, dass ein neues Limit geschickt wird, wenn der PowerMeter Wert mehr als um die Hysterese vom Ziel-Wert abweicht. Das ist nachvollziehbar, aber da der AC-Output des Hoymiles leider nie so recht beim Limit liegt, würde diese Interpretation lediglich dazu führen, dass ständig dieselben Limit-Updates geschickt werden. Natürlich kann ich nicht leugnen, dass es vorher für dich etwas besser reguliert hat. Was schlägst du denn vor, was man besser machen könnte? Ich muss noch zugeben, dass ich auch die "settling" Phase rausgenommen habe. Es wird nun schneller ein neuer Wert berechnet. Sobald nach einen Limit-Update neue Inverter-Daten und neue Power-Meter Daten vorliegen. Sonst mussten die Inverter-Daten und die Power-Meter Daten mindestens drei Sekunden jünger sein, als das letzte Limit-Update. Nicht sicher, ob das hier auch eine Rolle spielt. |
|
Ne eine konkrete Idee habe ich noch nicht. Wollte es eigentlich auch nur rein informativ darlegen. Ist mir halt als Unterschied zu vorher aufgefallen :) und akut stören tut es in meinem Fall auch nicht, da ich Überschüsse so oder so nicht einspeichern kann.
so war es vorher, oder? Ich kann auch noch nicht recht nachvollziehen, wie er auf den Wert kommt. Im log sieht man ja -34W powermeter value. Ich hätte also vermutet, dass das neue power Limit 14W kleiner ist, als das alte. Unter der Annahme, dass „reported“ (258W) das aktuelle Limit und damit auch die aktuelle einspeiseleistung ist (mit rundungsfehlern), hätte das berechnete neue Limit ja irgendwo um 244W liegen müssen. Wie gesagt, war nur rein informativ. Ich beobachte es weiter und versuche nachzuvollziehen, was da wie werkelt. Dafür braucht es aber mal etwas mehr und länger Sonne :) |
Ne. Vorher habe ich oben schon beschrieben: Da wurde das zuletzt angeforderte Limit in ganzen Watt mit dem neu berechneten Limit verglichen. Der Inverter macht daraus aber ein anderes Limit (Rundung) und er hat dann tatsächlich eine etwas andere Ausgangsleistung, als das Limit, oft etwas höher. Das ist halt so. Alles in allem ergibt dann, dass die realen Messwerte des PowerMeters nicht das wiederspiegeln, was der DPL sich schönrechnet (im Sinne von "ausrechnet unter der Annahme von optimalen Bedingungen"). |
|
Ich habe die Firmware eben via OTA aufgespielt, leider erreiche ich die Weboberfläche nicht mehr, zeigt nur eine leere Seite an. Die Daten kommen aber noch via MQTT. EDIT |
|
WR hat sich heute leider nicht gestartet bzw auf Produktion umgeschaltet!😔
RX Period End |
|
Nochmals getestet… NICHT zugeschaltet. RX Period End |
|
@chrisli01 kannst du deinen Wechselrichter manuell im WebUI starten? der DPL versucht deinen Wechselrichter zu starten, aber er startet nicht. Warum auch immer. Ich hab bei mir mal manuell aus geschalten und den DPL ihn wieder starten lassen. das geht bei meinem HM-600 ohne Probleme Was man aber sieht: einmal gibt es ein falsches Limit. |
|
Ja genau, Neustart über die Weboberfläche. |
Du hat über die Weboberfläche einen Neustart-Befehl verschickt? Also den gelben Button?
Hast du den nächtlichen Neustart des Inverters durch den DPL eingeschaltet/konfiguriert? |
|
|
Ja genau, gelben Restart-Button. |
Magst du das mal machen? In der Hoffnung, dass er sich dann den jeweiligen Tag über brav pausieren und starten lässt? |
|
Klar! |
|
@chrisli01 hast du am HMS-2000 eine Batterie? |
|
Nein. |
|
Nein. Ich meine dass dein wechselrichter damit so oder so ab Sonnenuntergang aus ist und zum Sonnenaufgang Neustartet die Funktion des erzwungenen Neustarts ist für Batterie betriebene wechselrichter eingebaut wurden, da es Probleme gibt, wenn wechselrichter zu lange laufen. (Dauerhaft Spannung auf der DC Seite) Schaden kann ein zusätzlicher Neustart ab um 9 nicht. Aber nötig sein sollte er in deinem Fall glaube nicht. |
|
Guter Punkt, das hab ich gar nicht bedacht. Auch wenn's nicht schadet, wird's wohl auch nichts bringen. Also dann kann ich dir nur noch ein anbieten: Lass die erzählen, wie die beiden HMS-2000 sich verhalten, die demnächst bei meinem Vater online kommen. Vielleicht machen die auch Probleme, dann würde ich dranbleiben. Andernfalls muss jemand anderes noch eine schlaue Idee haben, sonst kommen wir mit deinem Problem nicht weiter. Dass der Inverter Start-Aufforderungen einfach "ignoriert" hab ich sonst noch nirgends gelesen... |
|
Ich habe auch einen HMS-2000. aber der läuft bisher, wie der HM-600, alleine an einem Zähler. Startet nach Sonnenaufgang (ohne Batterie) und speist artig ein. (Ok, der DPL läuft dort auch noch nicht …. Dafür fehlt noch der Shelly 3EM) nach dem Umzug Mitte April wird sich das wohl ändern :) dann sind auch beide wechselrichter im gleichen Haushalt. Mal gucken wie ich dann was regeln muss. Bis dahin läuft es einfach. Einzeln. |
|
Das komische ist, wenn ich auf gelben Neustart Button klicke, funktioniert es beim ersten Klicken. |
|
Könnte man noch einbauen, das der WR nicht in Standby (gelb) geht?? |
|
Wieso denn? Der WR soll nicht produzieren, deshalb Standby. |
|
Damit er Minimum produziert und nicht aufgeweckt werden muss!
Websocket: [/livedata][11] disconnect |
|
@chrisli01 Hast du ein System ohne Batterie? Dann warte bitte die Veröffentlichung von #733 ab und mach den Haken rein "Inverter wird von Solarmodulen gespeist", dann wird dein Inverter auch nicht mehr in den Standby geschickt im Regelbetrieb. |
|
Ein Traum, DANKE!!!! Wird das ein offizielles Update?? |
|
Ja. Und du bist nach @Janorei der zweite der innerhalb von 7 Minuten danach fragt... Muss das "dringend" release't werden? Bis zum nächsten Release kannst du auch die Binaries aus dem Build-Run zu #733 verwenden, siehe https://github.com/helgeerbe/OpenDTU-OnBattery/actions/runs/8215332288?pr=733 |
Also ich kann warten, bis dahin läuft bei mir der Branch. Von mir aus bitte lieber keine überhasteten eiligen neuen Versionen, sonder alles sauber getestet :-) |
|
|
|
Was muss ich da jetzt machen? WR wird von SM gesprist habe ich auf ein. |
|
Wenn ich mich richtig erinnere, sind alle weiteren Einstellungen im DPL egal, wenn der wechselrichter im „solar only“ betrieb is. die Seite muss noch aufgeräumt werden. So dass dann Licht benötigte Elemente verdeckt werden. |
Naja, ganz stimmt das natürlich nicht, es gibt natürlich auch Einstellungen, die für Systeme ohne Batterie dennoch relevant sind. Aber Batterie Schwellwerte und Solar-Passthrough Einstellungen sind in der Tat allesamt irrelevant.
Kommt. Sehr bald. |
Ich habe den Branch aus dem Build-Run zu #733 laufen mit einem geregelten HM 800. |
|
Vielen Dank! werds die nächsten Tage testen. |
|
Habs heute testen können…. |
|
This pull request 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. |
we previously only called commitPowerLimit() if the desired limit changed such that the change was bigger than the hysteresis. we found that if the limit update was not received and the desired limit would not change much, the limit of the inverter was wrong for a long time.
to mitigate this, we introduced re-sending the limit update every 60 seconds, regardless of what the limit reported by the inverter was at that time.
if the power-up command was not received, we also would repeat it only once every 60 seconds.
this leads to a new kind of staleness and the actual inverter state was still not matching the desired state.
this new approach effectively adds an additional control loop at the start of the DPL loop(). that new function compares the requested inverter state to the actual reported state. it sends updates (limit update or power on state) until the desired inverter state is reached, or until a (hard-coded) timeout occurs.
this approach also allows us to send power-up, power-down, and limit update commands independent from one another and in a particular order.
this should make sure that the inverter is in the desired state even if conditions change slowly and commands were not received as expected.