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

Auflistung von gewünschten Features, Ausschreibung zur Umsetzung
gpr
Beiträge: 49
Registriert: Sa Feb 05, 2022 5:54 am
Been thanked: 19 times

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

Beitrag von gpr »

Ich finde die Lademodi so wie sie heute sind gelungen. Mit dem Lademodus drücke ich im Kern aus, was ich will. Es ist ein Unterschied, ob ich sofort laden will, oder einfach ohne Ladeziel möglichst viel PV oder möglichst billigem Strom nutzen will, oder eben auf ein Ziel hin laden. Ein eigener Modus für Zielladen ist also für mich sehr sinnvoll.

Dann wieder in den Nutzergruppen gedacht:
Für Normalnutzer müssen die notwendigen Einstellungen direkt auf der Hauptseite sichtbar und zugänglich sein. Powernutzer sind gut in dem Zahnrad zu den temporären Einstellungen aufgehoben. Ins eigentliche Einstellungsmenü zwingen wir nur den Admin.
Die zusätzlich notwendigen Einstellungen für Normalnutzer auf der Hauptseite sind:
  • Bis zu welcher Begrenzung möchte ich laden? (alle Modi)
  • Wann möchte ich das Ziel erreichen und mache ich das regelmäßig? (nur Zielladen)
  • Ggf noch, vielleicht schon besser beim Powernutzer aufgehoben: Wenn die Begrenzung erreicht ist, möchte ich dann mit PV noch weiter laden? (alle Modi außer PV)
Diese Parameter werden bereits in der ebenfalls sehr gelungenen Ladefortschrittsanzeige angezeigt. Sie von dort aus editierbar zu machen wäre aus meiner Sicht sehr passend.

Abschließend noch mein Senf zu der temporär/persistent Diskussion: Wie man das macht, ist ein grundlegendes Nutzungskonzept. openWB sollte hier unbedingt eine Entscheidung treffen, und nicht die Entscheidung den Nutzern überlassen. Nutzer sollten über so eine Frage nicht nachdenken müssen. Das Ergebnis ist sonst nur unnötige Komplexität, auch in der Technik (Wartbarkeit). Bedeutet, die neue Einstelloption wieder abschaffen.

Mein Vorschlag für die Entscheidung: Normalnutzer wählen temporär aus, was sie machen wollen. Powernutzer verstellen im Zahnrad-Menü temporär die gewünschten Details. Administratoren verstellen im Einstellungsmenü persistent die Defaults für diese Details. Als Sahnehäubchen kann man optional den Admin fragen, ob er die Veränderungen auf aktive Ladevorgänge übertragen will. Ich würde vor dem Sahnehäubchen aber erstmal genauer verstehen wollen warum Leute das noch brauchen, wenn man auf der Hauptseite bzw im Zahnradmenü alles Wichtige einstellen kann (wie oben beschrieben). Sehr wahrscheinlich erkennt man dann einen neuen Use Case (viele Fahrzeuge gleichzeitig umstellen im Ladepark?), den man besser dediziert (=eigenes UI) behandelt, anstatt im Einstellungsmenü.
therobbot
Beiträge: 349
Registriert: So Mai 16, 2021 6:09 pm
Has thanked: 18 times
Been thanked: 10 times

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

Beitrag von therobbot »

Das Problem mit den Lademodi ist aus meiner Sicht vor allem in Kombination mit den temporären Einstellungen zu sehen. Wenn mehrere Nutzer sich das Auto teilen und einer ein Ziel definiert und dafür (temporär) auf Zielladen umstellen muss, müssen die anderen sich dessen bewusst sein und nach jeder Fahrt wieder zurückstellen.

Ich sehe es eher aus Sicht von meinen Mitbenutzern, die allesamt keine Power User sind. Sie wollen normalerweise den PV Modus haben. Ab und zu soll mal temporär auf Sofortladen umgestellt werden. Da ist es sinnvoll, dass das temporär ist. Das war gut vermittelbar. Wenn sie aber einstellen, dass das Auto am nächsten Morgen eine gewisse Ladung haben soll, dann ist es ihnen nicht vermittelbar, dass das wieder verloren geht, wenn jemand anderes abends nochmal kurz wegfährt. Genau das ist aber der Fall, wenn Zielladen ein eigener Lademodus ist und man ihn nicht im Ladeprofil umstellt.

Zum Hintergrund: wir sind 7 Nutzer, die sich ein Auto teilen.
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 »

Wir wäre es, den gerade hinzu gekommenen Persisten-Schalter noch ein wenig mehr Funktion zu geben? Ich denke da an eine vereinfachte Konfiguration für die heimische Installation: Da hat ja das Speichern im Ladeprofil eigebtlich mehr Unbill hervorgerufen, als positives. Andere Dinge im heimischen Umfeld sind die diversen Profile und die daraus erwachsende Komplexität.

Wir wäre es nun, Fahrzeug- und Ladeprofil für eine einfache Konfiguration ins Fahrzug zu packen und bei der Gelegenheit das Ladepunktprofil an den Ladepunkt zu hängen. Wohl gemerkt: nur im UI, hintendran bleibt alles wie gehabt. Es gibt dann also nur noch zwei Konfigurationselemente: Fahrzeug und Laeepunkt. Die hängen „innendrin“ mit ihren Profilen 1:1 am jeweigen Objekt. Und in dieser Oberflächenvariante wäre der Persistent-Schalter auf Aus geschaltet. Schaltet man ihn ein, werden die Profile wieder sichtbar. Ausschalten kann man das erst, wenn die 1:1-Beziehung wieder hergestellt ist. I.e. Überzähleige Profile gelöscht / neue angelegt sind. Den Sxhalter würde ich dann in Ladepark-Konfiguration altivieren umbenennen, in der Hoffnung, dass den möglichst wenige Normalos altivieren, weil sie zuhause ja nun mal keinen Ladepark haben (wollen).
openWB-series2, openWB-Buchse, E3/DC S10pro+19.5kWh, 30kWp Ost-Süd, Model 3 und Ion
gpr
Beiträge: 49
Registriert: Sa Feb 05, 2022 5:54 am
Been thanked: 19 times

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

Beitrag von gpr »

therobbot hat geschrieben: So Nov 02, 2025 8:11 am Wenn sie aber einstellen, dass das Auto am nächsten Morgen eine gewisse Ladung haben soll, dann ist es ihnen nicht vermittelbar, dass das wieder verloren geht, wenn jemand anderes abends nochmal kurz wegfährt. Genau das ist aber der Fall, wenn Zielladen ein eigener Lademodus ist und man ihn nicht im Ladeprofil umstellt.
Interessanter Anwendungsfall. Ich hatte schon mal beschrieben, dass die Zielladeeinstellungen selbst nicht temporär sein sollten, es sich auch nicht um Grundeinstellungen der Box handelt, sondern um Daten die zum Nutzer oder Fahrzeug gehören. Wenn man diese also separat persistiert, bekommst du dein gewünschtes Verhalten, wenn du Zielladen als Default-Modus konfigurierst.

Ich verstehe aber aus deiner Erklärung, dass der Default-Modus eigentlich bei dir PV ist. Insofern verstehe ich deinen Gedanken, dass du meistens im PV Modus bleiben und dort das Zielladen mit abdecken willst. Trotzdem erscheint es mir problematisch, den Modus Zielladen abzuschaffen. Es ist einfach nicht intuitiv wenn die Box auf Sofort steht, dass man dann erst auf PV stellt um ein Ladeziel einzustellen (eindeutig bestätigt durch Rückfrage bei meiner Frau).

Ich habe aus dem Stand nicht die perfekte Lösung, vermute aber dass es sich hier um einen Spezialfall handelt der nur das Zielladen betrifft, den man wenn gewünscht gesondert behandeln muss. Aus deiner Erklärung geht ja auch hervor dass es keine Lösung ist, jede Änderung auf der Hauptseite gleich zu persistieren, da dann der häufige Anwendungsfall nicht mehr funktioniert, dass jemand einmalig auf Sofort stellt und danach wieder PV aktiv sein soll.
therobbot
Beiträge: 349
Registriert: So Mai 16, 2021 6:09 pm
Has thanked: 18 times
Been thanked: 10 times

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

Beitrag von therobbot »

gpr hat geschrieben: So Nov 02, 2025 10:31 am Ich verstehe aber aus deiner Erklärung, dass der Default-Modus eigentlich bei dir PV ist. Insofern verstehe ich deinen Gedanken, dass du meistens im PV Modus bleiben und dort das Zielladen mit abdecken willst. Trotzdem erscheint es mir problematisch, den Modus Zielladen abzuschaffen. Es ist einfach nicht intuitiv wenn die Box auf Sofort steht, dass man dann erst auf PV stellt um ein Ladeziel einzustellen (eindeutig bestätigt durch Rückfrage bei meiner Frau).
Wenn Zielladen alles könnte, was PV-Laden kann, dann könnten wir Zielladen als Defaultmodus setzen. Aber wir haben eingestellt, dass das Auto immer zunächst mit voller Kraft auf 50% lädt, damit immer genug für kurze Fahrten zur Verfügung steht. Das geht im PV-Modus mit der Mindest-SOC Einstellung. Vielleicht habe ich mich mit dem Zielladen-Modus noch nicht genug beschäftigt, aber auf den ersten Blick sehe ich nicht, wie ich das dort hinbekommen könnte. Wenn das nicht geht, ist er für mich als Standard keine Alternative, es sei denn, das würde zusätzlich implementiert.

Den Anwendungsfall deiner Frau verstehe ich gerade nicht. Wenn die Ladeziele unabhängig vom Lademodus für ein einzelnes Auto hinterlegt wären, könnte sie das Ladeziel ja auch im Sofortmodus einstellen.

Mir ist glaube ich das Ziel vom Ziellademodus - abgesehen von den einmaligen Zielen - noch nicht so ganz klar. Wenn es mir darum geht, zu einem bestimmten Zeitpunkt - vermutlich normalerweise früh - immer einen bestimmten Ladestand zu haben, dann ist das doch eigentlich nichts anderes als ein flexibleres und intelligenteres Nachtladen. Und dieses ist ja auch unabhängig vom Lademodus. Oder übersehe ich was? Vielleicht können Leute, die den Ziellademodus als Standard verewenden und nicht nur für einmalige Ladeziele, mal ihren konkreten Use-Case beschreiben.
ChristophR
Beiträge: 1359
Registriert: So Okt 30, 2022 8:07 am
Has thanked: 77 times
Been thanked: 114 times

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

Beitrag von ChristophR »

Den Mindest-SoC im Zielladen kann man mit zugebuchtem Zeitladen 0:00-23:59 Uhr lösen, bis es als Zusatzoption verfügbar wäre. Den Wunsch gab es schon mehrfach.

Nach der letzten Änderung, sind die Zeitpläne nun immer persistent, so dass die Probleme, dass die wieder verschwinden gelöst sind.
Das einzige Problem, was dabei auftritt, ist dass man den Default-Mode dann vermutlich auch auf Zielladen ändert.
Wenn das ein Problem ist, könnte man in den Ladeeinstellungen (EDIT: Ladeprofilen) noch einen Lademodus als Default-Mode aufführen, damit das klarer wird.
Zuletzt geändert von ChristophR am So Nov 02, 2025 1:50 pm, insgesamt 1-mal geändert.
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 »

Für Mindest-SoC in allen Lademodi hatte ich schon einen FR geschrieben - allerdings mit mäßigem Zuspruch.

viewtopic.php?t=11384
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: 77 times
Been thanked: 114 times

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

Beitrag von ChristophR »

therobbot hat geschrieben: So Nov 02, 2025 11:07 am Mir ist glaube ich das Ziel vom Ziellademodus - abgesehen von den einmaligen Zielen - noch nicht so ganz klar. Wenn es mir darum geht, zu einem bestimmten Zeitpunkt - vermutlich normalerweise früh - immer einen bestimmten Ladestand zu haben, dann ist das doch eigentlich nichts anderes als ein flexibleres und intelligenteres Nachtladen. Und dieses ist ja auch unabhängig vom Lademodus. Oder übersehe ich was? Vielleicht können Leute, die den Ziellademodus als Standard verewenden und nicht nur für einmalige Ladeziele, mal ihren konkreten Use-Case beschreiben.
Ich habe feste Wochentage mit Home-Office oder Büro(Präsenz).
An Tagen mit Home-Office brauche ich morgens einen kleineren SoC als bei einer Fahrt ins Büro.
Das habe ich über 2 Zielladepläne mit unterschiedlichen Wochentagen gelöst.
Wenn ich Termine habe, die weiter weg sind, trage ich den einmaligen Termin ein.
Dazwischen läuft immer Überschußladen, den Mindest-SoC habe ich über Zeitladen dazu gebucht.
Im Winter kommt bei mir eh keine Sonne ins Auto, da habe ich einen täglichen Zielladeplan mit einem höheren SoC.

Je nach Situation schalte ich die verschiedenen Pläne an oder aus, manchmal ändere ich auch etwas daran

So habe ich eine Grundeinstellung, die fast immer von selber passt.
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: 10 times

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

Beitrag von therobbot »

Danke. Das alles ginge aber doch auch im PV Modus mit Zeitladepläne für verschiedene Tage, wenn das einmalige Zielladen entkoppelt einstellbar wäre. Warum es dafür einen extra Modus benötigt, ist mir immer noch nicht klar. Ich habe im Grunde genommen auch so etwas für Wochenende und Werktag mit Zeitladen eingestellt.

Was mich allerdings interessiert: wie bekommst du den Mindest SoC mit Zeitladen hin? Einfach dauerhaft bis zu einem bestimmten SoC laden lassen?

Wenn das geht, dann wäre die Mindest SoC Einstellung ja tatsächlich überflüssig.
ChristophR
Beiträge: 1359
Registriert: So Okt 30, 2022 8:07 am
Has thanked: 77 times
Been thanked: 114 times

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

Beitrag von ChristophR »

therobbot hat geschrieben: So Nov 02, 2025 2:19 pm Danke. Das alles ginge aber doch auch im PV Modus mit Zeitladepläne für verschiedene Tage, wenn das einmalige Zielladen entkoppelt einstellbar wäre. Warum es dafür einen extra Modus benötigt, ist mir immer noch nicht klar. Ich habe im Grunde genommen auch so etwas für Wochenende und Werktag mit Zeitladen eingestellt.

Was mich allerdings interessiert: wie bekommst du den Mindest SoC mit Zeitladen hin? Einfach dauerhaft bis zu einem bestimmten SoC laden lassen?

Wenn das geht, dann wäre die Mindest SoC Einstellung ja tatsächlich überflüssig.
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.
openWB Series 2 Standard+, SW-Version 2
SolarEdge SE10K-RWS, BYD LVS 8, 16,8 kWp.
CUPRA Born
Antworten