Das wäre ja erstmal richtig- macht der Planner sonst auch. Er sollte in diesem Fall aber weiter „heute“ als Ziel zeigen?

Ja, genau. Ansonsten verwirrt das - meiner Meinung nach - den Benutzer.

@TobiasHuber1980 gibts ein Logfile? Ich vermute hier wird bei repeating plans der alte Plan bereits beendet was bei laufendem Plan nicht passieren dürfte.

@andig ist technisch ein etwas größeres Thema. Wir haben die Logik, dass laufende Pläne nicht abgebrochen werden sofern das Ziel noch nicht erreicht ist. Das ist das was hier auch zum richtigen Ladeverhalten führt. Für die Anzeige, aber auch um den Plan SoC auf den geladen wird, zu ermitteln betrachten wir momentan immer stumpf die aktuelle Uhrzeit und suchen dann den nächsten Plan raus. In dem Beispiel von @TobiasHuber1980 wird die Ladung nicht abgebrochen weil seine nächste Planzeit (morgen 15:30) auch 80% als Ziel hat. Wäre der nächste Plan unter dem aktuellen Ladestand gewesen hätte er abgebrochen. Heißt wir müssen an die Anzeige und ans Verhalten ran.

Ich bin mir noch nicht ganz sicher, was hier eine gute und nicht zu komplizierte technische Lösung ist. Vmtl. müssen wir die Infos zum aktiven Ladevorgang (aktiv wie "in progress"), also das Ladeziel und den Zeitpunkt noch mal als Kopie halten und erst beim "finish" wieder auf die Suche nach dem nächsten Ladeziel anhand der aktuellen Zeit switchen.

Ja, solange der Ladevorgang des bereits "abgelaufenen" Planners noch läuft, sollte wie beim bisherigen Planner "die Restzeit/Ziel wann" in orange angezeit werden. Wäre mich mich logischer (so wie im Screenshot.)

Log:

[lp-2 ] DEBUG 2024/12/12 17:59:54 plan: charge 25m1s between 2024-12-13 17:00:00 +0100 CET until 2024-12-13 17:30:00 +0100 CET (power: 11040W, avg cost: 0.234)
[lp-2 ] DEBUG 2024/12/12 17:59:54 plan: continuing until end of slot

Wir müssen wohl das aktuelle Ziel mit publishen um die Logik aus dem UI rauszuhalten?

@andig Das aktuelle Ziel wird mWn. schon separat für die UI gepublisht. "Nur" die Logik muss angepasst werden.