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

[Gero]

Na, dann fasse ich doch mal die Anforderungen zusammen. Da gibt es zum Einen das intelligentere Sofortladen: heute, morgen oder vielleicht auch übermorgen zu einem gewissen Zeitpubkt das Auto vollzuhaben. Diese Einstellung muss schnell und intuitiv sein. Und solange der Zieltermin nicht erreicht ist, darf das Ziel nicht vergessen werden. Danach gerne.

Zum Anderen gibt es geplante, tagvariable Ziele. So wie ein Architekt seine Baustellen abfährt, ein IT-Berater seine Kunden besucht oder sonstige weiter entfernt gelegene Ziele immer wieder angefahren werden. Das möchte ich mal als „Flex-Kalender“ bezeichnen. Hier ist Ziel-SoC und Abfahrtszeit konstant, der Tag variiert unvorhersehbar. Deshalb macht es Sinn, solcherart Ziele editierbar zu halten. Es könnten auch Terninvorlagen sein, die beim Aktivieren nach einem Tag fragen.

Denjenigen, die jeden Morgen in das selbe Büro fahren - oder es nur an Teilen der Woche tun, ist mit der aktuellen Implementierung gut gedient. Den anderen, flexibleren, fehlt noch eine Lösung. Und das was @therabbot sucht, ist womöglich das intelligente Sofortladen, damit in der Ladeplanung Sonne und günstige Tarife auch eine Chance bekommen, genutzt zu werden.

[therobbot]

Also, das würde ich gerade nicht wollen. Ich will nicht, dass dann aus Versehen Ladeziele deaktiviert werden. Das Aktivieren und Deaktivieren ist schon gut so, wie es ist. Du denkst aus Sichtweise eines Power Users.

Das wäre dann aber nur temporär, daher nur für den schlimm, der sich verklickt hat.
Der Poweruser darf ruhig in der 3. Ebene rumklicken, es ist genau für einfache Bedienung gedacht.

Daher ist es halt so schwer, alle Wünsche umzusetzen, weil die Anforderungen so unterschiedlich sind...

Ja, aber einmaliges Ladeziel ändern sollte halt nicht nur für Poweruser möglich sein.

[therobbot]

Na, dann fasse ich doch mal die Anforderungen zusammen. Da gibt es zum Einen das intelligentere Sofortladen: heute, morgen oder vielleicht auch übermorgen zu einem gewissen Zeitpubkt das Auto vollzuhaben. Diese Einstellung muss schnell und intuitiv sein. Und solange der Zieltermin nicht erreicht ist, darf das Ziel nicht vergessen werden. Danach gerne.

Zum Anderen gibt es geplante, tagvariable Ziele. So wie ein Architekt seine Baustellen abfährt, ein IT-Berater seine Kunden besucht oder sonstige weiter entfernt gelegene Ziele immer wieder angefahren werden. Das möchte ich mal als „Flex-Kalender“ bezeichnen. Hier ist Ziel-SoC und Abfahrtszeit konstant, der Tag variiert unvorhersehbar. Deshalb macht es Sinn, solcherart Ziele editierbar zu halten. Es könnten auch Terninvorlagen sein, die beim Aktivieren nach einem Tag fragen.

Denjenigen, die jeden Morgen in das selbe Büro fahren - oder es nur an Teilen der Woche tun, ist mit der aktuellen Implementierung gut gedient. Den anderen, flexibleren, fehlt noch eine Lösung. Und das was @therabbot sucht, ist womöglich das intelligente Sofortladen, damit in der Ladeplanung Sonne und günstige Tarife auch eine Chance bekommen, genutzt zu werden.

Danke. Um meine eigenen Anforderungen noch etwas zu präzisieren: ich bräuchte für uns die tagvariablen Ziele nicht. Mir würde es auch reichen, wenn das intelligente Sofortladen im PV Modus verfügbar wäre. Momentan simuliere ich das etwas unschön damit, dass ich im Modus Zielladen ein einmaliges Ladeziel Ende des Jahres gesetzt habe, weil ohne aktives Ziel nicht mit Überschuss geladen würde. Ich nutze den Zielladen Modus eigentlich nur wegen den einmaligen Ladezielen.

[aiole]

Ich habe es mir im Koala nochmal angeschaut, da ich aus o.g. Gründen momentan mehr das Standard-Theme verwende.
Mir fehlt hier tatsächlich eine einfach Möglichkeit, vorhandene Zielpläne zu aktivieren bzw. deaktivieren.
Auf dem Display der openWB kann man einfach die Zielpläne anklicken, sie werden dort Grün(aktiv) oder Rot(inaktiv), da kommt man ziemlich einfach hin.
Im Standard-Theme werden alle Zielpläne des gerade ausgewählten Fahrzeugs unten angezeigt, ich kann sie direkt anklicken, um sie zu (de-)aktivieren, sie werden auch hier rot oder grün.
Im Koala-Theme muss ich das Zahnrad anklicken, dann den Zielplan, dort ganz oben Aktiv umschalten. Ich denke das müsste vereinfacht werden. Entweder z.B. durch langes klicken in der Liste den Plan (de-)aktivieren können, oder noch besser wäre es, wie im Standard-Theme, wenn dies auf der Hauptseite ohne in die Einstellungen zu gehen klappen würde, dann müssten dort bereits alle Ziele angezeigt werden.

Koala soll simple bedienbar bleiben. Deshalb hat die main im Frontend nur 3 basic-Einstellungen, die jede(r) schafft.

1. Ladesperre aktiv/nicht aktiv
2. Fahrzeugauswahl
3. Lademodus
(4.) optional manueller SoC
Alles andere liegt hinter dem Zahnnrad.

Wo man 'drehen' könnte, wäre in den Zahnrad-Submenüs, nicht aber bei der 3-Punkte-Basis.

[Philip]

@aiole, ich hab ja hier auch schon für mehr Einfachheit plädiert. Einfachheit der Bedienung und komplexe Anforderungen passen aber manchmal einfach nicht zusammen, so wie jetzt hier. Eine Idee, die wir vor einiger Zeit schonmal an anderer Stelle diskutiert hatten, war die Möglichkeit, einen Lademodus frei zu definieren. Ich weiß nicht, ob das umsetzbar wäre, aber wenn, dann könnte man z.B. selbst einen intelligenten Sofortlademodus "bauen". Vielleicht wäre dort dann ja sogar im Lademodus auswählbar, ob der Modus persistent sein soll oder nicht.

Kurzum: Die Einfachheit der Bedienung wäre beibehalten, aber bei der Auswahl des Lademodus stünden mehrere freie Optionen zur Verfügung.

[gpr]

Koala soll simple bedienbar bleiben. Deshalb hat die main im Frontend nur 3 basic-Einstellungen, die jede(r) schafft.
...
Wo man 'drehen' könnte, wäre in den Zahnrad-Submenüs, nicht aber bei der 3-Punkte-Basis.

Hallo aiole, das finde ich nicht richtig. Zielladen ist ein Basis-Feature für alle, wenn man es entsprechend reduziert. Ich habe vor einem Monat die für uns notwendige UI der Wallbox im Home Assistant nachgebaut. Meine Frau nutzt zu 100% nur noch das, ich zu 95%. Zielladen habe ich dieses Wochenende ergänzt (es nutzt nicht das Zielladen der openwb sondern rechnet selbst).

Vielleicht hilft es, die UI funktioniert so:

• Der täglich zu bedienende Teil besteht erstmal nur aus 2 Knöpfen "Zielladen" und "Max Leistung". Ansonsten gibt es noch paar Anzeigen. Die Box läuft sonst immer in PV-Laden und wird nach der Ladung dorthin zurückgesetzt.

  

  Screenshot 2026-01-26 07.33.01.png (18.63 KiB) 438 mal betrachtet

• Tippt man auf "Max Leistung", geht die Box auf Sofortladen. Tippt man auf "Zielladen", ändert sich die UI in diese:

  

  Screenshot 2026-01-26 07.37.40.png (30.18 KiB) 438 mal betrachtet

• Wenn die Ladung startet (egal ob manuell oder via Zielladen), ändert sich die UI erneut (gerade kein Screenshot möglich). Dort kann man den Ziel-SoC nachträglich verändern, sieht die Ladeleistung sowie die Uhrzeit, zu der der Ziel-SoC erreicht wird.

Wir sind sehr zufrieden damit.

[Gero]

Das ist doch ein schöner Praxisbericht, der auch zeigt, dass der kleine Ziellademodus, den ich oben skizziert habe, durchaus seine Freunde finden wird. Hier sogar in der reduzierten Form, dass Termine weiter als heute nicht eingegeben werden können. Dass PV der Ruhemodus ist, ist wohl von allen Besitzern einer PV-Anlage sonst auch so eingestellt.

Sofortladen wird mit zunehmender Verbreitung dynamischer Tarife weniger relevant werden, da man mit sofortigem Ladestart den billigen Strom nicht genutzt bekommt. Im Winter mag Eco ein passendrr Ersatz für das sommerliche PV-Laden sein, aber wenn der Strom halt nicht billigst wird, hangelt mal sich des Winters von Fahrt zu Fahrt. Dazu ist Zielladen unabdingbar und dementsprechend auch eine simple Eingabe des Ziels notwendig. Viertelstundenklicker und 10%-Sprünge beim SoC würde m.E. nach gut passen.

So gesehen spricht einiges dafür, den Ziellademodus zu erweitern: um eine möglichst simple Eingabe des nächsten Ladeziels und untendrunterliegendes „billigst-Laden“, sollte kein Ziel aktiv sein. Das ist glaube ich besser, als mehrere Kurzfrist-Termine möglich zu machen. Mehr als einen Termin oder Termine weiter in der Zukunft als heute oder morgen wird vermutlich keiner so recht nutzen. (Statt einer expliziten Auswahl könnte man die am heutigen Tag verganegenen Stunden ja als morgige interpretieren, damit man abends noch ein Ziel für den nächsten Tag definieren kann)

Die sonstigen Ladepläne mögen davon unabhängig bitte weiterhin funktionieren. Und vielleicht die Einmaltermine in der Vergangebheit beim reaktivieren nach einem Tag fragen lassen.

Das wäre für mich der perfekte Ziellademodus.

[Philip]

Die Bedienlogik von @gpr ist echt super - auch das hatten wir neulich schonmal irgendwo: Dass ein Modus wie "Sofortladen" einfach nur Strom abgibt, es sei denn, man stellt in einem Sub-Menü nochmals weitere Einstellungen ein. Und genauso könnte das ja auch für Zielladen gehen: Einfach nur angeklickt, wird mit den im Backend hinterlegten Einstellungen geladen, z.B. wenn man länger als 10 Sek. keine Eingabe vornimmt. Alternativ kann man Parameter wie Ziel-SoC / Ziel-Zeit einfach anpassen. Und dann im besten Fall auch noch auswählen, ob der Lademodus nach Abstecken erneut aktiviert werden soll oder nicht. Ggf. könnte mit einem Button / Häkchen auch die Einstellung im Backend mit den neuen Werten aktualisiert werden.

[gpr]

Nur als Gedanke, nicht spezifisch fürs Zielladen: Jetzt wo die SimpleAPI und darauf aufbauend eine stabile HA-Integration da ist (danke dafür!), kann man vielleicht generell die openWB UI etwas fokussieren.

Wenn man mein Zielladen-Beispiel mal zur Seite legt, ist vielleicht der häufigere Fall, dass im Home Assistant nicht die Leute rumbasteln, die es simpel haben wollen, sondern die, die Geek-Zeug wollen. (Ich habe auch sowas, Stichwort Catch-All-PV, oder auch Schließen der 1p3p Lücke bei 16A - bei niedrigem SoC früh umschalten, beim hohem SoC spät.)

Wenn man akzeptiert, dass Geek-Zeug in einem System wie HA gemacht wird, wo extrem individualisiert werden kann, kann man aus der openWB vielleicht ein paar Feature Requests rausdisktieren (oder gar vorhandene entschlacken). So dass die Nicht-Geeks, die keinen HA o.ä. haben, ein simpleres System haben. Das würde sicherlich auch zur Stabilität und den Release-Zyklen beitragen.

[Gero]

Bin ich voll bei dir, den kompizierten Kram, für den es nur einen spzifischen Use-Case gibt, aus der openWB-Software rauszuhalten.

Aber es gibt doch schon einiges, was in der Breite nutzbar sein sollte, ohne dass diverse Leute selbst herumprogrammieren. Die 1p3-Lücke bei 16A halte ich für entbehrlich, wohingegen der catch-all meiner Meinung nach wichtiger ist. Beides ist nichts, was unter dem Strich große Gewinne (in Euros) abwirft, es tut aber gefühlt mehr weh, wenn es nicht anfängt zu laden als dass es lädt und nur nicht umschaltet.

Aber generell wäre es vielleicht mal eine gute Idee, eine Liste der noch offenen Punkte nach dem Gesichtspunkt „möglichst breite Nutzerbasis“ zu sortieren.