Zielladen in 2.1.8 (Beta)

[ChristophR]

Hier folgen die Logs für das o.g. Problem.

2025-10-16 21_22_58-openWB und 1 weitere Seite - Persönlich – Microsoft​ Edge.png (64.48 KiB) 557 mal betrachtet

Das Auto war seit gestern angesteckt, das Ziel täglich 07:00 Uhr 85% ist normalerweise deaktiviert.
Zwischen 21:15 und 21:20 Uhr habe ich dieses Ziel kurz mal aktiviert, da es eigentlich zu morgen früh laden soll.
Da das Auto schon länger dransteckt und das Ziel seitdem bereits einmal hätte erreicht werden können, lädt das Auto sofort los.
Ist so natürlich nicht gewünscht, nun müsste ich das Auto einmal abstecken und neu anstecken damit es wunschgemäß funktioniert.
Bisher war das kein Problem, erst seit das alte Ziel aktiv bleibt, ist dies problematisch:
https://paste.openwb.de/XI8BPaK7pjJHlER

[raffix]

Wenn der Ziel-SoC erreicht ist, wird noch maximal bis zum Überschuss-SoC geladen. Wenn der Zielzeitpunkt vorbei ist und das Auto nicht abgesteckt wird, möchte man nicht, dass es noch weiter geladen wird und dann mit vollem Akku herum steht. Erst wenn der nächste Zieltermin in greifbare Nähe rückt, soll das Auto weiter geladen werden.

Exakt das ist der Grund, weshalb man unterschiedliche Zielladepläne hat. Bei mir soll das Auto immer bis 80% (Plan 1) laden (um den Akku zu schonen), am Sonntag dann aber bis 90% oder 100% (Plan 2), damit ich mit ausreichend gefülltem Akku losfahren kann. Seit V2.1.8 bleibt er aber in Plan 1 hängen.
Es wäre also wichtig wieder zur alten Logik zurückzukehren, wonach wenn ein (Ziellade-)Plan abgelaufen ist, der nächste in der Zukunft liegende wieder greift, sonst lässt sich ein akkuschonendes Laden gar nicht mehr umsetzen. Dafür braucht man mehrere Pläne, die dann aber auch kontrolliert aktiv werden.

[ChristophR]

Hier hatte ich eine ähnliche Anforderung, Du müsstest wahrscheinlich für den Samstag ein weiteres Ziel definieren.
viewtopic.php?t=11036
Sollten wir lieber dort behandeln.

Vielen Dank für den Hinweis. Leider finde ich es schon verwirrend alle paar Wochen in einen neuen Thread zu wechseln, nun wurde der Feedbackthread einer Version noch einmal aufgeteilt?! Puh, wenn das nicht verwirrend ist.

Nun habe ich meine Frage hier aber schon gestellt. Hast du eine Idee wie ich den dritten Plan anlegen müsste, spricht wie die aktuelle Auswertung nun funktioniert, denn dann könnte ich mir selbst den Plan 3 überlegen?

Ich hatte am Anfang den falschen Link rausgesucht, sorry ist korrigiert, da warst Du zu schnell.

Ich glaube Du müsstest fur Samstag einen Plan anlegen mit höherem Überschuss SoC.
Die letzte Info von Lena, wie es funktioniert lautete:
viewtopic.php?p=130918#p130918
Nach meinem Verständnis hängt es aber stark davon ab, wann das Auto angesteckt wurde.

[raffix]

Ich glaube Du müsstest fur Samstag einen Plan anlegen mit höherem Überschuss SoC.
Die letzte Info von Lena, wie es funktioniert lautete:
viewtopic.php?p=130918#p130918
Nach meinem Verständnis hängt es aber stark davon ab, wann das Auto angesteckt wurde.

Vielen Dank, das hilft mir weiter. Leider habe ich jetzt einige zusätzliche Pläne anlegen müssen.
Leider lässt sich die Entwicklung von openWB anscheinend nicht davon überzeugen wieder auf die vorherige vernünftige Auswertung der Zielladepläne zurückzukehren. Das würde mir einiges an Arbeit ersparen.

[ChristophR]

Ich glaube Du müsstest fur Samstag einen Plan anlegen mit höherem Überschuss SoC.
Die letzte Info von Lena, wie es funktioniert lautete:
viewtopic.php?p=130918#p130918
Nach meinem Verständnis hängt es aber stark davon ab, wann das Auto angesteckt wurde.

Vielen Dank, das hilft mir weiter. Leider habe ich jetzt einige zusätzliche Pläne anlegen müssen.
Leider lässt sich die Entwicklung von openWB anscheinend nicht davon überzeugen wieder auf die vorherige vernünftige Auswertung der Zielladepläne zurückzukehren. Das würde mir einiges an Arbeit ersparen.

Ich denke momentan fließt die ganze Energie in die Probleme mit den temporären Zielladeplänen, daher würde ich noch etwas Geduld haben.

[raffix]

Ich denke momentan fließt die ganze Energie in die Probleme mit den temporären Zielladeplänen, daher würde ich noch etwas Geduld haben.

Ja, das könnte sein. Tatsächlich treibt mich die aktuelle Implementierung in den Wahnsinn!

Beispiel: Ich habe einen Zielladeplan für jeden morgen um 3:30 Uhr (90% aufladen und bis dahin mit PV-Überschussladen).
Heute früh (um 8 Uhr) habe ich diesen Plan aktiviert, damit ich morgen früh ein volles Auto habe und was ist passiert?!
Die openWB knallt auf 11kW hoch, um das Auto (ohne PV) jetzt um 8 Uhr morgens voll zu kriegen, weil es den Plan RÜCKWIRKEND auswertet.
Jetzt musste ich extra einen zweiten Plan anlegen auf heute Mittag (Ziel 0% und Überschuss mit 90%), damit die openWB diesen Plan nimmt und aufhört mit dem Blödsinn. Es ist zum Verzweifeln!

Wer kam auf diese verrückte Idee, Pläne rückwirkend auszuwerten?! Ein Ziel liegt ja typischerweise vor einem und nicht hinter einem, deswegen nennt man es ja Zielladen. Ich würde also solche Pläne niemals rückwirkend auswerten. Und es hat so schön bis V2.1.7 geklappt. Am kommenden Wochenende werde ich wieder downgraden und bei der 2.1.7er bleiben. Es kostet einfach zu viele Nerven.

[aiole]

Vermutlich kommt das aus dem Temporär/Persistent-feature der 2.1.8, welches vorrangig die Lademodi mit ihren Detaileinstellungen besser nutzbar macht. Da dort aber auch Zielladen enthalten ist, gab es dieses Problem. Das Team ist mWn. mit Vollstrom dran.

In 2.1.9 ist Temporär/Perstistent in den allgemeinen Einstellungen als Option hinterlegt und default auf Aus = Persistent.
Im Frontend wurde heute etwas zum Zielladen gemerged.

openWB-2.1.9_editierbares_Zielladen_Frontend.png (87.35 KiB) 161 mal betrachtet

[ChristophR]

Vermutlich kommt das aus dem Temporär/Persistent-feature der 2.1.8, welches vorrangig die Lademodi mit ihren Detaileinstellungen besser nutzbar macht. Da dort aber auch Zielladen enthalten ist, gab es dieses Problem. Das Team ist mWn. mit Vollstrom dran.

In 2.1.9 ist Temporär/Perstistent in den allgemeinen Einstellungen als Option hinterlegt und default auf Aus = Persistent.
Im Frontend wurde heute etwas zum Zielladen gemerged.
openWB-2.1.9_editierbares_Zielladen_Frontend.png

Nein, das hat nichts mit persistent/temporär zu tun.
Wenn das Fahrzeug nach erreichen des Ziels nicht abgesteckt wird, bleibt der alte Plan aktiv, selbst wenn das Ziel längst erreicht wurde.
Das hat Lena mit dem Support besprochen, es wurde entschieden, dass das so logischer wäre. (s.o.)
Das muss bitte rückgängig gemacht werden, so bereitet das massiv Probleme.

[gpr]

Folgende Implementierung würde ich glaube ich erwarten:

• Plan wird vor Zielzeitpunkt aktiviert (bzw Fahrzeug wird angesteckt bei aktivem Plan): Ladevorgang bis Ziel-SoC erreicht (auch wenn dies erst nach dem Zielzeitpunkt passiert), danach wird der Plan nicht mehr berücksichtigt
• Plan wird nach ZIelzeitpunkt aktiviert (bzw wie oben): Plan wird nicht berücksichtigt

Übersehe ich was?

[ChristophR]

Folgende Implementierung würde ich glaube ich erwarten:

• Plan wird vor Zielzeitpunkt aktiviert (bzw Fahrzeug wird angesteckt bei aktivem Plan): Ladevorgang bis Ziel-SoC erreicht (auch wenn dies erst nach dem Zielzeitpunkt passiert), danach wird der Plan nicht mehr berücksichtigt
• Plan wird nach ZIelzeitpunkt aktiviert (bzw wie oben): Plan wird nicht berücksichtigt

Übersehe ich was?

Das Problem ist, dass nicht auf den nächsten Plan umgeschaltet wird, obwohl der Ziel-SoC bereits erreicht wurde.

Ich habe z.B. folgende Pläne;
So 7:00 Uhr, Ziel-Soc 45%, Überschuss-Soc 85%.
Mo 7:00 Uhr, Ziel-SoC 65%, Überschuss-SoC 95%.
Wenn ich mit einem SoC von 75% am Sonntag um 6:55 Uhr anstecke, lädt er am Sonntag tagsüber nur bis 85% Überschuss-SoC.
Stecke ich jedoch am Sonntag um 7:05 Uhr an, lädt er bis 95% Überschuss-SoC.

Anderes Beispiel:
Täglich 7:00 Uhr, Ziel-Soc 80%, Überschuss-SoC 95%.
Ich stecke am Samstag Abends mit 50% SoC an. Sonntagmorgen wird auf 80% geladen.
Danach fällt mir ein, dass ich am nächsten Tag lieber 85% hätte, evtl. scheint aber noch ein bisschen Sonne.
Ich ändere also den Plan von 80% auf 85%, damit er am nächsten Morgen bis 85% lädt, falls die Sonne dafür nicht reicht.
Nun wird sofort losgeladen, da der Plan noch in die Vergangenheit schaut und damals nicht 85% erreicht wurden.

Beide Fälle haben in 2.1.7 noch funktioniert, es wurde mit der Einführung der temporären Einstellungen geändert, hat aber nix mit den temporären Einstellungen zu tun.