evcc
evcc copied to clipboard
evcc-io
Idee: inaktive Loadpoints aus der Regelschleife nehmen
In jedem Intervall werden zwar alle Meter abgefragt, aber es wird immer nur ein Loadpoint (der Reihe nach) geregelt. Bei größern Installationen mit mehreren Loadpoints kann das Regelintervall eines einzigen Loadpoint somit mehrere Minuten betragen.
Ich vermute, alle Loadpoints in jedem Intervall zu "bearbeiten" ist sehr komplex.
Deshalb die Idee, inaktive Loadpoints aus der Regelschleife zu nehmen, sodass nur noch die aktiven der Reihe nach geregelt werden.
Inaktiv wäre ein Loadpoint, wenn er connected: false liefert.
@VolkerK62 auch die Connected-Information muss ja irgendwoher kommen- die liefert erst der Loadpoint beim Update. Man könnte ggf. überlegen, ob ein Loadpoint "nix zu tun" zurück melden kann und dann sofort der nächste dran wäre.
/cc @premultiply
Man könnte ggf. überlegen, ob ein Loadpoint "nix zu tun" zurück melden kann und dann sofort der nächste dran wäre.
ja, wie auch immer es technisch umsetzbar ist. Aber ich denke, die Idee ist klar. Dadurch würden im Allgemeinen "aktive" Loadpoints schneller geregelt werden.
Dieses "nix zu tun" hätte, je nachdem wie das realisiert werden kann, u. U. den Vorteil, dass auch schaltbare Steckdosen (die ja immer verbunden sind) mit beachtet werden würden.
Dieses "nix zu tun" hätte, je nachdem wie das realisiert werden kann, u. U. den Vorteil, dass auch schaltbare Steckdosen (die ja immer verbunden sind) mit beachtet werden würden.
Werden die heute nicht beachtet?
Ich meinte damit, dass die dann bzgl. Abfrage der Inaktivität auch beachtet werden und aus der Regelschleife rausfallen können. Wenn man "connected" als Kriterium nimmt, bleiben die immer in der Regelschleife drin, weil sie immer connected sind.
Ist das Problem nicht auch dadurch zu mildern das interval entsprechend der Anzahl der LPs zu reduzieren?
Die Trägheit hängt ja an den LPs+Vehicle.
30 Sekunden sind imho ein sehr sehr pessimistischer Default. Ich glaub die allerlangsamsten Systeme haben bisher 18s gebraucht.
In jedem Zyklus von jedem LP den Ladezustand (und sogar vielleicht auch alle weiteren Daten) abzufragen wäre meiner Meinung nach gut vertretbar. Ladestatus ist oft nur ein einzelner Request. Wenn nichts connected ist kann man sich weiteres i.d.R. ganz sparen und diesen LP direkt überspringen.
Die wirkliche Zeit geht vor allem bei den schreibenden Sollwertänderungen und dann dem Warten auf die Auswirkungen drauf.
Ist das Problem nicht auch dadurch zu mildern das interval entsprechend der Anzahl der LPs zu reduzieren?
ja, natürlich. Ich habe 4 Loadpoints, aber unter 10s fangen Probleme an. Wenn alle aktiv sind, okay, dann dauert es halt, aber wenn nicht, könnte man dadurch die Qualität verbessern. Auch in Bezug auf Lastmanagement.
Das ist jetzt aber eher ein hypothetisches Problem. Es muss halt immer sichergestellt werden, dass der Einschwingvorgang abgeschlossen ist bevor der nächste Charger etwas tut. Und ob er was tut weisst du erst wenn er aktualisiert wird. Ich sehen keinen guten Algorithmus dafür.
Es wird doch in jedem Intervall die ChargePower abgefragt. Kann man da nicht einfach noch den Verbindungsstatus abfragen und auf der Basis entscheiden, welchen Loadpoint als nächstes an der Reihe ist? Wahrscheinlich stelle ich mir das wieder mal zu einfach vor 😇
was mir gerade noch eingefallen ist: man könnte zusätzlich auch den Modus abfragen. Wenn der off ist, kann der Loadpoint auch übersprungen werden.
Jain. Da muss man zumindest trotzdem schauen ob auch nicht geladen wird wo es nicht darf. Stichwort "charger out of sync".
Gerade nochmal über folgende Vereinfachung nachgedacht:
Kann man nicht einfach immer dann sofort zum nächsten LP hüpfen wenn seitens evcc keine Änderung an einem LP vorgenommen wird?
Ein unverändert (z.B. mit maximaler Leistung) ladender LP ist doch eigentlich regelungstechnisch genauso langweilig und unkritisch wie ein nicht ladender LP.
Alle Abfragen sind unkritisch und dauern in der Regel auch nur ein paar ms pro LP.
Wir müssen nur sicherstellen dass nach einer Änderung bis zur nächsten Änderung mindestens <interval> Sekunden gewartet wird um das System einschwingen zu lassen.
Und im Extremfall am Ende der LP-Liste wenn es keinerlei Änderung gab.
Hab ich was übersehen?
Das wäre dann:
- LP meldet "ich hatte delta" -> lange Wartezeit
- sonst: kurze Wartezeit
- nächster LP
Aber jetzt nochmal die Grundsatzfrage: was bring uns das hier und heute? Notwendig ist das NUR im PV Modus oder im Lastmanagement! Und im PV Modus laufen vmtl. keine 40 Boxen parallel.
sonst: kurze Wartezeit
besser: keine Wartezeit
Notwendig ist das NUR im PV Modus oder im Lastmanagement!
Das ist richtig. Sobald ein LP im PV-Modus ist. Und das ist ja irgendwie unsere Mission 😉
Andererseits würde es generell die Performance, Responsivität und Skalierbarkeit mit mehreren LP stark erhöhen.
Und im PV Modus laufen vmtl. keine 40 Boxen parallel.
Weiß man es? 🙂 Damit hätte eine solche Installation zumindest eine deutlich realistischere Chance, oder?
Noch schöner wäre dann ja, die alle parallel laufen zu lassen, jeder Box im eigenen Rythmus und intervall. Erst wenn eine Box regeln will, müssten sie sich synchronisieren. Dafür müsste das "regeln wollen" dann aber blocken falls das Regelintervall der letzten Box noch nicht abgelaufen ist. Unter Regeln wäre damit aber alles zu verstehen ab Messung.
Und im PV Modus laufen vmtl. keine 40 Boxen parallel.
Weiß man es? 🙂 Damit hätte eine solche Installation zumindest eine deutlich realistischere Chance, oder?
Stichwort : Mini-Loadpoints. Da wird dann vmtl einiges dazu kommen.
Ich habe in https://github.com/GrimmiMeloni/evcc/tree/feature/smartInterval angefangen das ganze zu bauen.
Im Hinblick auf die etwas offene Zukunft (mini loadpoints) erscheint es mir sinnvoll das ganze Thema "Abklappern von Loadpoints" zu abstrahieren. Dazu habe ich jetzt einen Dispatcher eingeführt, dessen Aufgabe es ist Loadpoints an die Site rauszugeben. Ferner erwartet der Dispatcher eine Rückmeldung von der Site nachdem der Loadpoint abgearbeitet ist, damit dieser ggf. die Information in seine Logik einfließen lassen kann. Letzteres finde ich noch nicht so schön, hängt aber auch stark von der Lösung für den Rückkanal aus dem Loadpoint ab (siehe unten).
Aktuell gibt es zwei komplett getestete Dispatcher Implementierungen:
- StaticInterval - entspricht der aktuellen Implementierung in der Site, d.h. 1 Loadpoint pro Interval
- SmartInterval - Implementiert das von @VolkerK62 skizzierte Verhalten, d.h. wenn vom Loadpoint die Rückmeldung kommt das sich nichts geändert hat, wird direkt der nächste rausgegeben. Falls im Intervall alle Loadpoints unverändert sind, wird auf das Interval Ende gewartet.
Im Branch ist die Site jetzt auch auf den StaticIntervalDispatcher umgestellt. Ich habe bisher nur mit der demo.yaml getestet - da scheint alles wie bisher zu funktionieren.
Bis hierher wäre ich jetzt erstmal für Feedback dankbar. Es braucht noch kein volles Codereview, zumindest eine Bestätigung das o.g. den Erwartungen entspricht wäre gut zu haben. (Vermutlich hätte ich schon eher Fragen sollen...)
Für den Rückkanal vom Loadpoint zur Site würde ich gerne nochmal konkretere Ideen mit Euch sammeln. Meiner Ansicht nach ist es Loadpoint.SetLimit(...), wo die entscheidende Info (Enable/Disable, bzw. Current Veränderung) entsteht. Das ist recht "tief" in der Callchain, und es gibt mehrere Pfade dorthin. Ich würde die Rückmeldung daher ungern als Returnvalue wieder hochreichen. Mir schwebt eher ein Feld im Loadpoint vor, dass während Loadpoint.Update(...) dazu verwendet wird den Loadpoint als "changed" zu markieren. Diese Information könnte die Site dann nach Loadpoint.Update() abgreifen und an den Dispatcher zurückgeben. Vielleicht könnte man es noch eleganter mit einem Channel zwischen Loadpoint und Dispatcher lösen.
Gibt es für diesen Ansatz generell Zustimmung, bzw. habt Ihr alternative Ideen?
Schöne technische Lösung, aber:
Es muss halt immer sichergestellt werden, dass der Einschwingvorgang abgeschlossen ist bevor der nächste Charger etwas tut. Und ob er was tut weisst du erst wenn er aktualisiert wird. Ich sehen keinen guten Algorithmus dafür.
Ich habe kein Bild, was dieses "ob er etwas tut" wirklich ist. Haben wir eine vollständige Liste der Aktionen am Loadpoint die "etwas tun" bedeuten? Mir wäre nicht mal klar, in welchen Fällen die untereinander warten müssten und wie wir das feststellen.
Das wäre aber Voraussetzung für eine Imlementierung?
Ja, um hier weiter zu machen brauchen wir zunächst Klarheit was überhaupt den Zustand des Systems verändert. Meiner Ansicht nach sind das schreibenden Calls die der Loadpoint gegen den Charger macht. Technisch gesprochen sind das die folgenden Interfaces, bzw. Methoden:
-
Charger.Enable(bool) -
ChargerEx.MaxCurrentMillis(float64) -
CurrentController.MaxCurrent(int64) -
PhaseSwitcher.Phases1p3p(int)
Alle anderen Schnittstellen sind ReadOnly.
Auf die schnelle geschaut sind es Loadpoint.setLimit() und Loadpoint.scalePhases() wo wir auf Änderungen reagieren könnten. Ich müßte nochmal den kompletten Callgraph durchschauen um es genau zu prüfen.
Wenn das Problem hier gelöst wird, wäre dass schon ein Grundstein zur lösung von #7235
Dann auch gerne der Vollständigkeit halber - ich hab es nicht vergessen, musste aber die letzten Wochen meine Energie anders investieren. Werde die kommenden Tage mal einen ersten Aufschlag für die noch offenen Änderungen am Loadpoint nachliefern.
Ich würde dieses Thema gerne zu machen:
Zur Klarheit: hier gibts kein Problem.
Dazu kommt, dass es m.E. die falsche Lösung für das falsche Thema ist. Statt die Schleife abzukürzen sollten wir überlegen, wie sich die Ladeplanung parallelisieren lässt. Spätestens bei großen Ladeparks wäre es sinnvoll, das Energiebudget zeitgleich auf die Ladepunkte zu verteilen. Das würde bedeutet:
- Budget ermitteln
- Ladepunkte planen
- Ladepunkte steuern
...und zwar für alle gleichzeitig. Dafür muss die Schnittstelle der Ladepunkte geändert werden und https://github.com/grid-x/modbus/pull/70 muss gelöst sein da insbesondere die Modbus Library das heute nicht hergibt.
Gerne separate Diskussion oder noch besser PR um das auszuloten.