Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

UI Planner falsche Anzeige wenn Ziel nicht erreicht. #17704

Open
TobiasHuber1980 opened this issue Dec 12, 2024 — with Slack · 7 comments · May be fixed by #17834
Open

UI Planner falsche Anzeige wenn Ziel nicht erreicht. #17704

TobiasHuber1980 opened this issue Dec 12, 2024 — with Slack · 7 comments · May be fixed by #17834
Assignees
Labels
bug Something isn't working ux User experience/ interface

Comments

Copy link
Contributor

TobiasHuber1980 commented Dec 12, 2024

@Maschga

Planner heute auf 15:30 gestellt, Ladeziel konnte auf Grund zu wenig Zeit bis Zieluhrzeit nicht erreicht werden. UI spring dann auf "morgen" lädt aber trotzdem mit "schnell" weiter um das Ziel heute noch zu erreichen.

Slack Message

image

@andig andig added the question Rather clarification than issue label Dec 12, 2024
@andig
Copy link
Member

andig commented Dec 12, 2024

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

@Maschga
Copy link
Contributor

Maschga commented Dec 12, 2024

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

@andig andig added bug Something isn't working and removed question Rather clarification than issue labels Dec 13, 2024
@andig
Copy link
Member

andig commented Dec 13, 2024

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

@naltatis
Copy link
Member

@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.

@TobiasHuber1980
Copy link
Contributor Author

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

@andig
Copy link
Member

andig commented Dec 13, 2024

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

@naltatis
Copy link
Member

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

@andig andig added the ux User experience/ interface label Dec 14, 2024
@naltatis naltatis assigned Maschga and unassigned naltatis Dec 17, 2024
@Maschga Maschga linked a pull request Dec 20, 2024 that will close this issue
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
bug Something isn't working ux User experience/ interface
Projects
None yet
Development

Successfully merging a pull request may close this issue.

4 participants