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

[Thomas aus W]

Wenn der default aus dem backend inaktiv ist, wäre das für mich schlüssig.

Dann sollten Einmal-Zielladepläne in der Konfiguration nicht aktivierbar sein, denn wenn die dort konfigurierte Zielzeit angelaufen ist ist er ja sowieso nicht mehr aktiv, auch wenn er noch auf "aktiv" steht...

Andererseits wirft es beim unbedarften Benutzer sicher Fragen auf, wenn er einen Ziel-Zeitplan in der Zukunft im Ladeprofil nicht aktivieren kann (oder soll). Jedenfalls wird niemand extra in die Konfiguration gehen, um einen abgelaufenen Plan händisch zu deaktivieren.

Ich denke, eine automatische Deaktivierung ist die intuitivere Lösung.

Wie erwähnt ist die config im Frontend derzeit in der mache.

Deshalb diskutieren wir hier ja so angeregt in der Hoffnung, noch Einfluss auf die Umsetzung nehmen zu können...

bye
TW

[Thomas aus W]

Entweder Frontend = Temporär, backend persistent

Da bin ich voll bei dir.
Und mein Vorschlag widerspricht dem nicht.

bye
TW

[aiole]

Sinnvoll wäre, die (sinnvolle) Trennung von temporären und persistenten Einstellungen zu verbessern, also zb einmaliges Zielladen trotz temporärer Einstellungen zu ermöglichen.

Bei temp. Einstellungen = ja werden die persistenten Ladepläne im Frontend geladen und können dort leicht angepasst werden - ohne extra Abstecken. Braucht, wie openWB schon schrieb, noch etwas.

Vielleicht verstehe ich es noch nicht richtig, aber deine Aussage verstehe ich weiterhin so, als ob nach der Einstellung dann wieder alles, was ich in Frontend einstelle, I'm Backend geändert wird, was ja das Verhalten bis 2.1.7 war. Das ist aber ja nicht das Ziel. Ich finde es weiterhin richtig, dass eine Trennung zwischen Ladeplänen und einzelnen Ladestationen besteht. Wenn ich also eine Ladestation auf Sofort stelle, will ich weiterhin nicht, dass das im Ladeprofil gespeichert wird.

nein
Das Backend (Lade-Profil) macht nur seine Einstellungen am Ladepunkt verfügbar. Ggf. anschließende Modifikationen sind temporär.

Das Problem, was aufgekommen war, betraf ja vor allem das einmalige Zielladen. Das gehört aus meiner Sicht einfach nicht ins Ladeprofil.

Dann müsste man alle Ladepläne rausnehmen. Nur einen Teil woanders zu platzieren, versteht kein Mensch.

Welchen use case gibt es dafür, das für alle Autos eines Typs einzustellen? Es ist aus meiner Sicht eigentlich etwas, das logisch zu einem Auto gehört. Da die openWB einzelne Autos nicht abbildet (abbilden kann), muss man die Krücke akzeptieren, das an der einzelnen Ladestation in Kombination mit dem dort eingestellten Auto Typ festzumachen.

openWB ist der Vorreiter, in Autos zu denken. Das allerdings erweitert um Profile, damit auch große Ladeparks effizient abgedeckt werden können.

Also: es müsste im Frontend die Möglichkeit geben, ein einzelnes Ladeziel einzustellen. Das wird dann nicht im Backend gespeichert, sondern im Frontend in Kombination mit dem eingestellten Autotyp. Wird an der Ladestation ein anderer Autotyp eingestellt, gilt das Ladeziel nicht mehr. Wird wieder auf den ursprünglichen Autotyp zurückgestellt, wird es wieder aktiv. So stelle ich mir das vor.

So der Plan - s. oben

[openWB]

Dann sollten Einmal-Zielladepläne in der Konfiguration nicht aktivierbar sein, denn wenn die dort konfigurierte Zielzeit angelaufen ist ist er ja sowieso nicht mehr aktiv, auch wenn er noch auf "aktiv" steht...

Ich kann dir nicht folgen. Wo ist da das Problem?
Wenn ich temporär aktiv habe und im Frontend einen solche aktiviere kann ich einen bereits aktiven ja auch deaktivieren!?

Ich denke, eine automatische Deaktivierung ist die intuitivere Lösung.

Wenn im backend etwas konfiguriert dann am im Frontend deaktiviert ist halte ich das nicht für intuitiv.
Beispiel, jeden Tag 17uhr 70%.
Das will ich nicht noch nach anstecken aktivieren müssen

[therobbot]

Welchen use case gibt es dafür, das für alle Autos eines Typs einzustellen? Es ist aus meiner Sicht eigentlich etwas, das logisch zu einem Auto gehört. Da die openWB einzelne Autos nicht abbildet (abbilden kann), muss man die Krücke akzeptieren, das an der einzelnen Ladestation in Kombination mit dem dort eingestellten Auto Typ festzumachen.

openWB ist der Vorreiter, in Autos zu denken. Das allerdings erweitert um Profile, damit auch große Ladeparks effizient abgedeckt werden können.

Hm, ich kann natürlich Fahrzeuge abbilden, wenn ich für jedes Auto ein eigenes Fahrzeugprofil anlege. Aber ich dachte, das Ziel der Umstellungen in der 2.1.8 war gerade, dass man bei Fuhrparks mit mehreren Autos eines Typs ein Fahrzeugprofil für mehrere Autos verwenden können will. In diesem Fall gibt es aber in der Logik der openWB dann soweit ich das sehe keine Entsprechung für ein einzelnes Fahrzeug. Aus objektorientierter Sichtweise halte ich das für eine Lücke.

Ich halte es ehrlich gesagt nicht für schlau, zwei verschiedene Optionen für den Umgang mit den Einstellungen anzubieten. Die Notwendigkeit dafür zeigt aus meiner Sicht, dass noch keine gute Lösung gefunden wurde. Ich befürchte, dass das langfristig nur zu noch mehr Verwirrung führen wird.

[openWB]

Ich hole die Diskussion mal hierher aus dem Release Feedbackthread.

Gerne können wir auch ein Meeting hierzu machen wenn gewünscht.
Wenn gleich nicht abends in den kommenden Tagen, Dienstag 28.10, 13 Uhr?

ansonsten hier auch gerne die Diskussion fortführen...

[ChristophR]

Da gehe ich nicht mit.
Entweder Frontend = Temporär, backend persistent
Oder bei deaktivierter temporärer Einstellung (siehe Alpha) alles immer persistent.

Ich weiß das viele für die temporären Änderungen waren, das in der Breite zu vermitteln ist aber schwer.
Eine weitere auftrennung der Logik ist dann noch weniger vermittelbar in meinen Augen.

Zur ViKo: Tagsüber bekomme ich das leider nicht hin, dann doch erstmal hier weiter.

Die klare Trennung zwischen temporär über das Dahsboard/Main-GUI und persistent über die Ladeprofile sollte auf jeden Fall eingehalten werden.

Ich plädiere weiter für die Möglichkeit, bei der Änderung im Ladeprofil diese Änderungen in die temporären Einstellungen zu übernehmen.
Ob das über einen alternativen Speichern Button oder eine weitere Grundeinstellung ermöglicht wird, spielt dabei eigentlich keine Rolle.

Auf jeden Fall muss es eine Möglichkeit ohne erneutes Abstecken geben.
Ich ändere aber öfter auch mal Einstellungen, die sowohl jetzt als auch für die Zukunft gelten sollten, dann müsste ich das 2x machen, einmal temporär und dann nochmal im Ladeprofil. Wenn das Auto nicht angesteckt ist, kümmere ich mich darum noch nicht, daher ist das oft keine Option.
Wenn das zu kompliziert wird, würde ich wahrscheinlich wieder auf die temporäre Einstellung verzichten, was sehr schade wäre.

[openWB]

Die klare Trennung zwischen temporär über das Dahsboard/Main-GUI und persistent über die Ladeprofile sollte auf jeden Fall eingehalten werden.

Sofern die Option hier generell aktiv ist. Ich denke da sind wir uns einige!?

Ich plädiere weiter für die Möglichkeit, bei der Änderung im Ladeprofil diese Änderungen in die temporären Einstellungen zu übernehmen.
Ob das über einen alternativen Speichern Button oder eine weitere Grundeinstellung ermöglicht wird, spielt dabei eigentlich keine Rolle.

Wenn aber die einzige fehlende Option im Frontend (Plan anlegen / editieren) im Frontend verfügbar ist, was wäre der Vorteil das im Backend aufzusplittern?
Was ist der Usecase dafür?

Auf jeden Fall muss es eine Möglichkeit ohne erneutes Abstecken geben.

Da bin ich bei dir, direkt im Frontend.

Ich ändere aber öfter auch mal Einstellungen, die sowohl jetzt als auch für die Zukunft gelten sollten, dann müsste ich das 2x machen, einmal temporär und dann nochmal im Ladeprofil. Wenn das Auto nicht angesteckt ist, kümmere ich mich darum noch nicht, daher ist das oft keine Option.

Das wäre ein Punkt. Was ist das überlicherweise und weshalb? Ich möchte gerne die Hintergründe verstehen.

Wenn das zu kompliziert wird, würde ich wahrscheinlich wieder auf die temporäre Einstellung verzichten, was sehr schade wäre.

Daher der Gedanke die Trennung aufrecht zu erhalten damit es vermittelbarer ist.

[aiole]

Auf jeden Fall gutes Brainstorming hier - Danke!

Alles außer "Pläne für Ziel- und Zeitladen" sollte mit der Temporäroption gut nutz- und erklärbar sein. Sind wir diesbezüglich erstmal einig?

Vielleicht müssen wir noch mal grundsätzlich über die Pläne nachdenken.
Autos bestehen aktuell aus:
1. Fahrzeug-Profil (fahrzeugtyp-abhängige Eigenschaften) - z.B. ID.3 - 3p - 11kW
2. Lade-Profil (präferierte Ladevorgaben) - z.B. PV-Laden mit 1p3p-Automatik
3. direkten Einstellungen zum individuellen Auto - z.B. SoC

In der Anwendung hatte ich bis dato immer für jedes Fahrzeug auch ein zugehöriges Lade-Profil angelegt, was erst dann bei 2 EV z.B. die unterschiedliche Ladung mit PV / Sofort ermöglichte.

Prinzipiell sehe ich die Pläne schon im Lade-Profil, nur ist das handling durch die Temporärbedienung noch zu tricky.
Am besten nochmal eure Verbesserungsvorschläge dazu in möglichst kurzer Form darlegen.

ps
Viko tagsüber ist hier auch schlecht. Lieber abends.

@ChristophR
Also Abstecken durch einen Button ersetzen. Dann überschreibe es aber alle EV mit den gerade aktuellen Profilen. Das sollten wir jetzt im Zuge der Überarbeiten mit beachten.

[ChristophR]

@ChristophR
Also Abstecken durch einen Button ersetzen. Dann überschreibe es aber alle EV mit den gerade aktuellen Profilen. Das sollten wir jetzt im Zuge der Überarbeiten mit beachten.

Wenn man den Button "Speichern+Übernehmen" oder bei den Einstellungen "Speichern überschreibt auch temp-Profile" speichert, ist man sich dessen ja bewusst, es muss nur unauffällig platziert sein, um nicht alle zu verwirren.