evcc-io
Do not call API every 10 sec. during charging
@andig Auf ein Neues.
Um nicht in die Gefahr zu laufen, das zu oft das API aufgerufen wird und man immer das identische Verhalten hat, unabhängig von den Poll Modes, habe ich im socPollAllowed() alle Ausnahmen entfernt.
- Ich habe keinen Grund für "lp.connected() && lp.socUpdated.IsZero()" finden können. Auch nicht nahc ausführlichem Testen.
- Charging wurde anders gelöst.
Vorteil:
- Auch im Charging sieht man jetzt die Debugausgabe wann die nächste Abfrage kommt.
- Man wartet explizit und nicht implizit über das Caching
Leider hat die Funktion socPollAllowed() nicht nur das API beschützt, sondern indirekt noch den Takt für den Loadpoint vorgegeben in der Funktion publishSoCAndRange(). Das ganze aber nur, wenn die Ladestation den Takt nicht vorgeben konnte.
- Daher wurde "if lp.socPollAllowed() || lp.socProvidedByCharger()" entfernt. Somit gibt es nun immer den gleichen Takt und der "estimator" kann wenn er denn eingestellt ist arbeiten.
Vorteil:
- Alle Funktionloops laufen immer mit der gleichen Geschwindigkeit (EVCC Takt)
Die API Aufrufe Tätigt die Klasse Estimator, also schadet es nicht wenn diese über socPollAllowed() bescheid weis und damit intern arbeitet. Das reduziert Abhängigkeiten und Komplexität in der Laufzeit. socPollAllowed wurde der Klasse Estimator zur Verfügung gestellt.
Die Klasse Estimator macht in der Funktion SOC() zwei Dinge. Sie holt einen neuen SOC vom Vehicle oder Charger API. und danach kommt ggf. noch die Estimation, wenn configuriert. Das könnte, und sollte man wahrscheinlich noch auseinanderziehen und ggf. das holen der SOCs in eine Funktion des Loadpoints stecken.
Damit nun nicht zu oft gefragt wird, habe ich die SOC APIs hinter socPollAllowed() gehängt. Der zweite Teil des Estimators wird immer durchlaufen.
Somit kann jetzt socPollAllowed nur noch gaaanz wenig beeinflussen und das so tief wie möglich.
Noch offen:
- Die Cache duration vom aktuellen Auto in socPollAllowed() für den Charginmode nutzen. Aktuell fest auf 15min gesetzt.
- Ggf. das SOC besorgen aus den Estimator in eine Funktion des Loadpoints verschieben. (nice to have)
Um nicht in die Gefahr zu laufen
Da ist keine Gefahr, denn die APIs sind gecached. Oder willst Du die Caches loswerden? Das wäre eine Idee.
Auch im Charging sieht man jetzt die Debugausgabe wann die nächste Abfrage kommt.
Nice. Dann bräuchte es aber 1 Setting je Auto da die sich durchaus unterscheiden. Nicht alle müssen gleich selten abgefragt werden. Aktuell sieht man übrigens im TRACE of da wirklich eine Abfrage passiert.
Nochmal: welches Problem willst Du hier lösen? Und ist das wirklich ein Problem?
Ich habe keinen Grund für "lp.connected() && lp.socUpdated.IsZero()" finden können.
Das ist der Zustand beim Programmstart
Um nicht in die Gefahr zu laufen
Da ist keine Gefahr, denn die APIs sind gecached. Oder willst Du die Caches loswerden? Das wäre eine Idee.
Auch im Charging sieht man jetzt die Debugausgabe wann die nächste Abfrage kommt.
Nice. Dann bräuchte es aber 1 Setting je Auto da die sich durchaus unterscheiden. Nicht alle müssen gleich selten abgefragt werden. Aktuell sieht man übrigens im TRACE of da wirklich eine Abfrage passiert.
Nochmal: welches Problem willst Du hier lösen? Und ist das wirklich ein Problem?
Also ich wollte beim Chargeing die Ausgabe sehen und war dann verwirt. Ein Bug und wirkliches Problem ist es nicht. Wenn ihr andere Baustellen habt ist auch gut. Änderungen haben ja auch immer ein Risiko. Ich finde aber regelmäßige kleine Überarbeitung wenn sie z.B. einen Wartbarkeitsvorteil haben auch nicht schlecht.
Ich würde eine Statemachine eher so pflegen das man ggf. den Cache plötzlich garnicht mehr braucht.
Also ich finde es besser so, habe eine Menge gelernt. Jetzt gucke ich welche Prioritäten ihr im Projekt setzt und gucke wo ich helfen kann. :-)
Ich würde eine Statemachine eher so pflegen das man ggf. den Cache plötzlich garnicht mehr braucht.
Spricht nix dagegen. Der Punkt unterschiedlicher Cachezeiten je Fahrzeug ist aber weiter offen.
Ich würde eine Statemachine eher so pflegen das man ggf. den Cache plötzlich garnicht mehr braucht.
Spricht nix dagegen. Der Punkt unterschiedlicher Cachezeiten je Fahrzeug ist aber weiter offen.
Das gucke ich mir mal an. Ich dachte da kennt ihr euch vielleicht mit den Templates aus. Also der Loadpoint kennt doch das aktuell Verbundene Vehicle?! da müsste dann der Wert in irgendeine Interface funktion und die würde man in PollAllowed() auslesen und gut ist.
Ich habe keinen Grund für "lp.connected() && lp.socUpdated.IsZero()" finden können.
Das ist der Zustand beim Programmstart
Edit: deleted
Edit2: Ich mache die Tests grün und melde mich dann wieder
Ich würde mich dann mal um die Tests kümmern, ob wir das mergen oder nicht. Dann lerne ich mal wie das geht. Ich hoffe es ist ok, wenn wir dein ein paar Tage offen lassen. Gerade habe ich schon mal den Linter geradegezogen.
@andig Ich habe einen voll kompatiblen Zwischenschritt erreicht, bei dem ich auch einen Bug beheben konnte. Diese Version ermöglicht es zusätzlich mit einem Charging Intervall > 0 zu testen und es weiter umzubauen.
Änderungen:
- Alle Modi setzen "honourUpdateInterval" damit gibt es keinen Sonderfall mehr. Hab es auf meine Art programmiert, Ich könnte es aber auch minimalinversiv in die aktuelle Version einbauen. Und die Werte vom "return" in die "honourUpdateInterval" Ebene verschieben.
- Der Reset mit lp.socUpdated.IsZero() geht dann auch so durch, da die Differenz sehr groß wird. Hier braucht es keine extra logic.
- Für Charging würde ich erstmal ein Intervall für 0 annehmen, damit geht es dann auch immer sofort durch und verhält sich identisch zu vorher.
- socProvidedByCharger() aus der Mainloop entfernt und via Intervall 0 gelöst, siehe Bugfix.
Bugfix:
- Ich habe auch für socProvidedByCharger() ein Intervall eingetragen. Früher wäre da bei jedem Setting in "honourUpdateInterval" eine Logmeldung erschienen, die in der Realität aber nicht passiert wäre, da der Estimator den SOC sofort und direkt vom Charger geholt hätte.
Ich versteh grad nur Bahnhof. Kannst Du bitte nochmal kurz sagen, was der PR tut und inwiefern unterschiedliche Abfrageintervalle je Fahrzeug damit harmonieren?
Ich versteh grad nur Bahnhof. Kannst Du bitte nochmal kurz sagen, was der PR tut und inwiefern unterschiedliche Abfrageintervalle je Fahrzeug damit harmonieren?
- Es behebt einen logging Bug, wenn die Wallbox den SOC bereitstellt. Da in dem Fall socPollAllowed() nicht mehr loggt.
- Da im charging mode noch das Intervall 0 gesetzt ist, hat sich real das Verhalten nicht geändert. Es gibt also noch kein Problem mit verschiedenen Fahrzeugen.
Aber du hast Recht. wenn es mehrere Fahrzeuge "gleichzeitig" gibt, ist die finale Lösung garnicht so einfach und in dem PR auch noch nicht adressiert.
wenn es mehrere Fahrzeuge "gleichzeitig" gibt, ist die finale Lösung garnicht so einfach und in dem PR auch noch nicht adressiert.
Ich mache vorerst mal zu da Rückschritt ggü. Status Quo.