Zielladen, temporär vs. persistent, Backend vs. frontend

Auflistung von gewünschten Features, Ausschreibung zur Umsetzung
therobbot
Beiträge: 349
Registriert: So Mai 16, 2021 6:09 pm
Has thanked: 18 times
Been thanked: 11 times

Re: Zielladen, temporär vs. persistent, Backend vs. frontend

Beitrag von therobbot »

ChristophR hat geschrieben: So Nov 02, 2025 3:14 pm
Warum sollte ich mich mit weiteren Zeitplänen rumschlagen?
Ich will nur, dass das Auto zum Zeitpunkt x soundso voll sein soll.
Das soll so spät wie möglich sein, um die Standzeit mit vollem Akku zu minimieren, gerne mit PV, wenn es verfügbar ist.
Um den Rest soll sich die openWB alleine kümmern, für Leute mit dynamischen Tarifen noch so preiswert wie möglich.

Der Zeitplan einfach als Ziel-SoC den gewünschten Mindest-SoC angeben, täglich 0:00 bis 23:59, dann lädt er immer sofort auf den SoC, um den Rest kümmert sich das Zielladen.
OK, dann ist der Mindest-SoC so also tatsächlich im Zielladen emulierbar. Allerdings ist das nun wirklich ein Workaround, der für Normaluser nicht gerade transparent ist.

Ich sehe weiterhin nicht, was der Vorteil eines eigenen Modus für Zielladen ist. Wenn die Zielladepläne ins Fahrzeug wandern würden, könntest du doch im PV Modus alles immer noch so konfigurieren, wie du es jetzt hast. Und die Zielladepläne würden sogar noch funktionieren, wenn der Ladepunkt auf Sofort steht.
ChristophR
Beiträge: 1359
Registriert: So Okt 30, 2022 8:07 am
Has thanked: 78 times
Been thanked: 114 times

Re: Zielladen, temporär vs. persistent, Backend vs. frontend

Beitrag von ChristophR »

therobbot hat geschrieben: Mo Nov 03, 2025 5:48 am
Ich sehe weiterhin nicht, was der Vorteil eines eigenen Modus für Zielladen ist. Wenn die Zielladepläne ins Fahrzeug wandern würden, könntest du doch im PV Modus alles immer noch so konfigurieren, wie du es jetzt hast. Und die Zielladepläne würden sogar noch funktionieren, wenn der Ladepunkt auf Sofort steht.
Sofort lädt sofort, Zeitladen so früh wie möglich, Zielladen so spät wie möglich.
Für Zielladen braucht man den SoC, Sofort und Zeitladen geht notfalls auch ohne.
Für die verschiedenen Anforderungen gibt es die passenden Lösungen. Du musst Zielladen ja nicht benutzen.

Die Ladeprofile werden einem Fahrzeug zugeordnet, gelten also pro Fahrzeug. Eine Profilwanderung würde also an der Funktionsweise nichts ändern, daher kann ich Dir in dem Punkt nicht folgen.

Generell ging es hier ja ursprünglich um Zielladen, nicht ums Abschaffen. Das wäre für viele Anwender bestimmt nicht verständlicher...
openWB Series 2 Standard+, SW-Version 2
SolarEdge SE10K-RWS, BYD LVS 8, 16,8 kWp.
CUPRA Born
Gero
Beiträge: 4555
Registriert: Sa Feb 20, 2021 9:55 am
Has thanked: 46 times
Been thanked: 261 times

Re: Zielladen, temporär vs. persistent, Backend vs. frontend

Beitrag von Gero »

ChristophR hat geschrieben: Mo Nov 03, 2025 6:09 am Die Ladeprofile werden einem Fahrzeug zugeordnet, gelten also pro Fahrzeug. Eine Profilwanderung würde also an der Funktionsweise nichts ändern, daher kann ich Dir in dem Punkt nicht folgen.
Der Hintergrund der Idee, Zeit- und Zielladen andas Auto zu hängen, ist die Problematik persistent vs. temporär und der daraus resultierenden Schwierigkeit der Editierei am Ladepunkt. Denn die ist ja aktuell im persistenten Teil, wird aber eher nur aus dem Haupt-UI, also dem temporären Teil her bedient. Da wäre es eine Lösungsmöglichkeit, die Ladepläne aus dem Bereich persistent/temporär herauszulösen.

Was das Thema Zielladen als eigenen Lademodus angeht, bin ich indifferent. Ich nutze den aktuell nicht, da das ausbalancieren der Zellen damit nicht funktioniert. Die Plan-Eigenschaft spricht für Gleichbehandlung mit den Plänen des Zeitladens, das generelle Verhalten („so spät wie möglich“) eher für einen eigenen Lademodus.

Aber vielleicht ist ja auch die Lösung „eigener Modus aber Plan am Auto“ eine Lösung. Denn Zeitladen als Modus ist ja sehr weit gediehen und beeinhaltet Elemente aller deri Hauptlademodi PV, Eco und Sofort. (Irgendwann ohne Netz, billigst und schnellmöglichst)

Wenn man die persisten/tenporär-Problematik nur Ladeparkbetreibern so richtig offen legt, wäre es für die anzahlmäßigen Hauptnutzer ja noch nicht mal mehr erklärungsbedürftig, den Plan ans Auto, die Funktion aber als Lademodus zu haben. Dem Ladepark ist es sicherlich nicht schwer zu vermittlen, dass Zeitpläne generell am Auto sind. Wenn da Ladepläne überhaupt eine Rolle spielen.
openWB-series2, openWB-Buchse, E3/DC S10pro+19.5kWh, 30kWp Ost-Süd, Model 3 und Ion
ChristophR
Beiträge: 1359
Registriert: So Okt 30, 2022 8:07 am
Has thanked: 78 times
Been thanked: 114 times

Re: Zielladen, temporär vs. persistent, Backend vs. frontend

Beitrag von ChristophR »

Gero hat geschrieben: Mo Nov 03, 2025 6:23 am
Der Hintergrund der Idee, Zeit- und Zielladen andas Auto zu hängen, ist die Problematik persistent vs. temporär und der daraus resultierenden Schwierigkeit der Editierei am Ladepunkt. Denn die ist ja aktuell im persistenten Teil, wird aber eher nur aus dem Haupt-UI, also dem temporären Teil her bedient. Da wäre es eine Lösungsmöglichkeit, die Ladepläne aus dem Bereich persistent/temporär herauszulösen.
Ich nutze das Standard Theme. Wenn ein Fahrzeug mit Ziel- oder Zeitplänen ausgewählt ist, habe ich neben den Plänen ein Zahnrad, das springt ins Ladeprofil, was ich dort ändere ist ja persistent.
Im Koala Theme finde ich diesen Link nicht, da kann ich nur Pläne ein- oder ausschalten. Ist das vielleicht das Problem?
Colors habe ich mir jetzt nicht angeschaut, da geht es bestimmt auch...

Das ein- oder ausschalten vorhandener Pläne in der Übersicht ist temporär, im Ladeprofil persistent. Das finde ich auch konsequent.
Wenn man die Pläne in der Übersicht ändern könnte, müssten sie dort temporär werden, dann hätten wir wieder das Problem der verschwindenen Pläne nach Abstecken. Das wäre schlecht.

Hat das etwas mit Eurer Idee zu tun oder bin ich auf dem falschen Pfad?
openWB Series 2 Standard+, SW-Version 2
SolarEdge SE10K-RWS, BYD LVS 8, 16,8 kWp.
CUPRA Born
therobbot
Beiträge: 349
Registriert: So Mai 16, 2021 6:09 pm
Has thanked: 18 times
Been thanked: 11 times

Re: Zielladen, temporär vs. persistent, Backend vs. frontend

Beitrag von therobbot »

ChristophR hat geschrieben: Mo Nov 03, 2025 6:09 am
Die Ladeprofile werden einem Fahrzeug zugeordnet, gelten also pro Fahrzeug. Eine Profilwanderung würde also an der Funktionsweise nichts ändern, daher kann ich Dir in dem Punkt nicht folgen.

Generell ging es hier ja ursprünglich um Zielladen, nicht ums Abschaffen. Das wäre für viele Anwender bestimmt nicht verständlicher...
Ich habe gerade nicht viel Zeit, aber diese zwei Dinge will ich doch noch kommentieren.

Zur ersten Aussage: zu einem Auto gehört genau ein Ladeprofil, aber ein Ladeprofil kann zu mehreren Autos gehören. Das ist also nicht notwendigerweise eine bijektive Zuordnung. Sonst wäre die Ebene der Ladeprofile unnötig und alles könnte direkt im Auto eingestellt werden. Die Frage ist also, ob man Zielladen für alle Autos haben will, die ein bestimmtes Ladeprofil verwenden oder doch eher für einzelne Autos zumindest bei den einmaligen Zielen halte ich die zweite Option für logischer.

Zur zweiten Aussage: es geht mir gerade nicht ums Abschaffen des Zielladens, sondern darum, daß Zielladen - und dabei vor allem das einmalige Zielladen - einfacher und umfangreicher verfügbar zu machen, nämlich unabhängig vom Lademodus.
Gero
Beiträge: 4555
Registriert: Sa Feb 20, 2021 9:55 am
Has thanked: 46 times
Been thanked: 261 times

Re: Zielladen, temporär vs. persistent, Backend vs. frontend

Beitrag von Gero »

ChristophR hat geschrieben: Mo Nov 03, 2025 6:54 am
Gero hat geschrieben: Mo Nov 03, 2025 6:23 am
Der Hintergrund der Idee, Zeit- und Zielladen andas Auto zu hängen, ist die Problematik persistent vs. temporär und der daraus resultierenden Schwierigkeit der Editierei am Ladepunkt. Denn die ist ja aktuell im persistenten Teil, wird aber eher nur aus dem Haupt-UI, also dem temporären Teil her bedient. Da wäre es eine Lösungsmöglichkeit, die Ladepläne aus dem Bereich persistent/temporär herauszulösen.
Ich nutze das Standard Theme. Wenn ein Fahrzeug mit Ziel- oder Zeitplänen ausgewählt ist, habe ich neben den Plänen ein Zahnrad, das springt ins Ladeprofil, was ich dort ändere ist ja persistent.
Da habe ich mich nicht genau genug ausgedrückt: Das "bedienen aus dem temporären Teil" sollte meinen, dass man dort an dieser Stelle die Dinge einstellt. Dass man da aktuell technisch gesehen in die Konfiguration - dem persistenten Teil - abspringt, ist wohl eher der "Fauelheit" der Programmiere zuzuschreiben als dem UI-Design. Noch mal ganz explizit: Wenn ich den Plan ändere, tue ich das in erster Linie auf dem Haupt-UI, weil ein Absprung in die Konfiguration an dieser Stelle wenig intuitiv ist. (Umstellen des Lademodus mache ich ja auch im UI und nicht in der Konfiguration)

Dieses nicht-vorhandensein eines Editors für Pläne ist bislang nicht groß aufgefallen, da man ja eh nur einen einzigen Speicherort für das Ladeverhalten hatte: Das Ladeprofil. Nun gibt es die temporären Einstellungen und damit gibt es das Problem, dass man - wenn man immer noch ohne Editor an den Plänen ändert - in der Konfiguration ändert und diese Änderungen erst einmal nicht im Ladepunkt reflektiert werden. (werden sie aktuell, das ist ja dazuprogrammiert worden, dass eine Konfigurationsänderung an alle relevanten Ladepunkte durchkopiert wird) So wie es jetzt ist, werden die Ladepläne anders behandelt als die anderen Dinge im Ladeprofil: Der Lademodus hat einen "lokalen Editor", kann also am Ladepunkt temporär geändert werden; die Ladepläne haben das nicht, die können nur in der Konfiguration geändert werden. Für ein identisches Verhalten bräuchte es nun einen "lokalen Editor", was aber zur Folge hätte, dass Änderungen am Ladeplan mit dem nächsten Abstecken verloren gehen. (Täte man das nicht, hätte man sich den ganzen Kram mit persistent und temporär auch sparen können. Denn problematisch war ja eine Änderung am Ladepunkt, die alle Autos dieses Ladprofils mit betrafen: Stellt man am Ladepunkt von PV auf Sofort, laden gleich alle Autos dieses Ladeprofils los)

Festzuhalten bleibt also: Ladepläne haben im Gegensatz zum Lademodus (oder anderen Kleinigkeiten des Ladeprofils) in der Anwendung andere Anforderungen. Da möchte man - weil diese Änderungen aufwendiger durchzuführen sind - die Änderungen dauerhaft gespeichert haben, was beim Wechsel des Lademodus von Eco auf Sofort nicht der Fall ist.

Das bringt mich zu dem Vorschlag, die Ladepläne ans Auto zu hängen. Denn so sind sie logisch aus dem Ladeprofil raus (diese festen Uhrzeiten sind meiner Meinung nach eh eher fahrzeugindividuell) und dadurch dass sie am Auto hängen, haben Änderungen an dieser Stelle auch keine Auswirkungen auf andere aktuell angesteckte Autos)

Da das Ganze für Neueinsteiger fürchterlich kompliziert ist und die Masse der Anwender wahrscheinlich eh nur eine oder zwei Wallboxen und ähnlich viele Autos haben, bin ich auf die Idee gekommen, das für diesen Anwenderkreis zu vereinfachen: Genauso wie es in meinem Howto für den privaten Bereich beschrieben und auch in den Youtube-Videos erklärt ist, lautet ja die Empfehlung ein Ladeprofil je Auto anzulegen. Um das nun noch noch weiter zu vereinfachen und die diversen Profile aus der Konfiguration zu nehmen, würde ich eine 1:1-Beziehung zwischen Fahrzeug und Fahrzeug- und Ladeprofil erzwingen. Damit hat man weniger Objekte zu konfigurieren und muss sich weniger Funktionen und Begriffe merken: Man hat nur noch ein ein Fahrzeug und da hängt alles dran.
Für die Ladeparks und Firmenparkplätze kann man die Konfiguration wieder zu der komplexen mit den Profilen umstellen. Da können dann die Profile wieder ihre Stärken ausspielen. Und der geplagte private Anwender hat nur noch Auto und Ladepunkt zu konfigurieren.
openWB-series2, openWB-Buchse, E3/DC S10pro+19.5kWh, 30kWp Ost-Süd, Model 3 und Ion
Lynx42
Beiträge: 102
Registriert: Fr Sep 18, 2020 2:21 pm
Has thanked: 3 times

Re: Zielladen, temporär vs. persistent, Backend vs. frontend

Beitrag von Lynx42 »

therobbot hat geschrieben: Mo Nov 03, 2025 7:23 am Zur zweiten Aussage: es geht mir gerade nicht ums Abschaffen des Zielladens, sondern darum, daß Zielladen - und dabei vor allem das einmalige Zielladen - einfacher und umfangreicher verfügbar zu machen, nämlich unabhängig vom Lademodus.
Dem möchte ich mich anschließen. Ich wollte gerade im Forum fragen, da habe ich diesen Beitrag gefunden:
Ich möchte meistens den Modus PV aktiviert haben (um mitzunehmen, was geht). Dann habe ich im Winter Zeitladen aktiviert, was mich nachts auf 50% bringt.
Zusätzlich dazu hätte ich jetzt gerne noch die Möglichkeit für jeden Dienstag Zielladen 100% bis 6 Uhr zu aktivieren - im Modus PV - denn immer Dienstags muss meine Frau eine große Strecke fahren. Da sich hier dann Ziel- und Zeitladen überlappen könnte man mit einer Prio-Einstellung den Anwender wählen lassen, was ihm in einem solchen Fall wichtiger ist.
aiole
Beiträge: 8587
Registriert: Mo Okt 08, 2018 4:51 pm
Has thanked: 157 times
Been thanked: 169 times

Re: Zielladen, temporär vs. persistent, Backend vs. frontend

Beitrag von aiole »

Schön zu sehen, wie hier die Köpfe glühen. So wird da was draus.

Ladepläne sind in der Tat speziell und bedürfen besonderer Behandlung. Sie sollten definitiv nur 1x existieren und vor allem leicht aus dem Main-GUI - persistent - zu konfigurieren sein ("lokaler Editor" ;) ). Soweit so gut.

Die Ideen zu Normaluser, Poweruser und Admin sind auch gut nachvollziehbar.

Mal sehen, was das Team von der 1:1-Profilzuordnung hält, um diese dann für Normaluser zu verstecken. Prinzipiell ist das aus deren Sicht sehr zu begrüßen. Diese(r) mag nichts von welchem Profil auch immer wissen.
Schwierig sehe ich nur den Weg von 1:1 zur nicht 1:1-Zuordnung.
Antworten