Fix wrong time display

[Maschga]

Fix #17704

Hi,
dieser PR soll den richtigen Timestamp anzeigen, wenn bei den wiederholenden Plänen die Ladezeit über die festgelegte Zeit hinausgeht.
Diese Implementierung funktioniert soweit schonmal. Ich weiß aber nicht, ob alle Use Cases abgedeckt sind, da wäre es super, wenn ihr auch einmal austestet was geht.

Vielen Dank für das tolle Projekt!
~Maschga

[andig]

Mir ist nicht klar, wie die Lösung hier aussieht. Alle Werte zwischenspeichern? Was ist denn der Root Cause des aktuellen Issues?

[Maschga]

Die wiederholenden Pläne speichern für die Zieluhrzeit keinen Timestamp, sondern Wochentag + Uhrzeit. Deshalb müssen die Timestamp-Zieluhrzeiten der wiederholenden Pläne errechnet werden.
Eine Annahme dafür ist, dass diese Zieluhrzeit (logischerweise) in der Zukunft liegt.
Zudem wird für jede Iteration auf dem Loadpoint die Zieluhrzeit jedesmal neu errechnet, da es sein kann, dass der Benutzer etwas an dem wiederholenden Plan geändert hat.

Wenn jetzt aber ein Auto mit einem wiederholenden Plan geladen wird und das Laden über die vom Benutzer gewünschte Zielzeit hinaus geht (also länger dauert, als evcc angenommen hat), dann wwäreird ab dem Zeitpunkt, bei dem die Zielzeit überschritten wird, diese Zielzeit in der Vergangenheit. Weil aber die Logik annimmt, dass die Zieözeit in der Zukunft liegen muss, wird ab sofort die Zielzeit auf den nächstgelegenen Wochentag geschoben, was zu diesem Fehler führt.

@naltatis hat den Vorschlag gemacht, den Soc und die Zielzeit zwischenzuspeichern, um den oben beschriebenen Fall zu umgehen. Das funktioniert in meiner Implementierung schon, aber bei Änderungen am Plan müssten noch die Variablenwerte angepasst werden. Da habe ich noch keine gute Lösung gefunden.

[Maschga]

Hier ist diese Logik implementiert: https://github.com/evcc-io/evcc/blob/master/util%2Ftime.go#L9

[andig]

Wir haben ja schon die planActive Variable. Könnten wir die nutzen (oder die auf plan- als Pointer zum Plan- und planActiveSlot: bool aufsplitten) anstatt zwei neue hinzu zu fügen? Solange der alte Plan nicht fertig ist würde dann der plan weiter verwendet. Nach der Zielzeit wird ohnehin schnell geladen, ein folgender Plan könnte also auch nichts Besseres bewirken.
Wie sollen Änderungen eines aktiven Plans behandelt werden? Gilt dann die geänderte Variante?

[Maschga]

Eine Variable zu nutzen, um den Plan zu speichern, gefällt mir gut.
Wie mit einer Änderung umgegangen werden soll, bin ich mir noch nicht sicher. Ich weiß nicht, was in einem solchen Fall der Nutzer erwarten würde.

[naltatis]

Diese implizite Zustandsveränderung in einem Getter ist nicht gut und von außen nicht erwartbar.
Das Setzen und Zurücksetzen von lp.planActiveSoc und lp.planActiveTime sollte immer in Sync mit lp.planActive passieren. Ggf. können wir die Notwendigkeit für planActive sogar ersetzen bzw. daraus ableiten ob es eine planActiveTime gibt.

[naltatis]

oder die auf plan- als Pointer zum Plan

Das ist nicht ganz so einfach. Ein Plan Objekt auf das wir verweisen können gibt es in der Form ja nicht. Die aktuelle Planzeit und das Ziel (SoC o. kWh) kann momentan drei Quellen haben:

• kWh Plan am Ladepunkt (Energie + Zeitpunkt)
• fester SoC Plan am Fahrzeug (SoC + Zeitpunkt)
• wiederholender SoC Plan am Fahrzeug (SoC + Wochentagsregel)

Daher ist der Weg, dass wir uns das konkrete Ziel und Zeit beim beginnen der Ladung als primitiven merken schon gut. Wir müssen hier nur die Schreiblogik beieinander halten, dass wir keine inkonsistenten Zustände bekommen.