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

[therobbot]

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.

Das Problem, was aufgekommen war, betraf ja vor allem das einmalige Zielladen. Das gehört aus meiner Sicht einfach nicht ins Ladeprofil. 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.

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.

[Gero]

Das Problem, was aufgekommen war, betraf ja vor allem das einmalige Zielladen. Das gehört aus meiner Sicht einfach nicht ins Ladeprofil. 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.

Das ist eine Sichtweise, die ich für überlegenswert halte. Dann aber auch mit den Zeitladeplänen zusammen. Für mich war es immer so, dass eine einmalige Umstellung auf Sofort nicht in den Grundeinstellungen gespeichert werden darf, weil es halt eine temporäre ist. Bei den Ladeplänen ist es ja etwas komplizierter, da dort ja auch zum editieren in die Konfiguratuon abgesprungen wird. Das mag der „Programmiererabstaktion oder -faulheit“ entsprungen sein, macht aber deutlich, dass diese Plan-Einstellungen wesentlich komlizierter sind. Ich hatte gedanklich mit dem Ersetzen der Ladepläne durch einen neuen, wenn man am Ladepunkt editiert, gespielt. Einfach auch dafür, dass die Unterscheidung in temporäres, ladepunktspezifisches und der Konfiguration deutlixh gemacht wird.
Da wäre das Herauslösen der Zeit- und Zielladepläne aus dem Ladeprofil heraus vielleicht auch eine Option.

Gegen eine Lösung mit den zwei Knöpfen „Speichern“ und „Übernehmen“ spreche ich mich immer noch aus. Denn zum einen ist die Differenzierung sprachlich nicht erkennbar und zum anderen sollte man den Benutzer nicht dazu zwingen, das doch sehr komplexe Datenmodell der openWW verstehen zu müssen. Da ist das mit dem überschreiben des tenporären Ladeprofils am Ladepunkt aus der Konfiguration heraus schon undurchsichtig genug. (Letztens habe ich bei abgesteckten Auto in der Konfiguration geändert und mich darüber gewundert, dass sich die Ladepunkteinstellungen geändert haben. Das hat auch alles mit dem vertrackten Überschreiben beim Abstecken zu tun. Aber macht man es beim Anstecken, wird die vor einer Minute gemachte Änderung von Sofort auf PV wieder überschrieben. Also die Minute, bevor man das Auto eingesteckt hat. Und den Ladepunkt hat man ja geändert, damit es nach Anstecken nicht sofort loslädt…g

[openWB]

Zwischen einmaligem und wiederkehrenden Zielladen zu unterscheiden halte ich nicht für richtig.

Wenn die config auch im Frontend möglich ist, sehe ich aber auch kein Problem dort ein einmaliges zu konfigurieren.
Alternativ einen Plan anlegen und im Frontend dann temporär nur die einmalige Zeit ändern.

Übersehe ich etwas?

[Gero]

Wenn die config auch im Frontend möglich ist, sehe ich aber auch kein Problem dort ein einmaliges zu konfigurieren.

Das ist ja gerade das ursächlichen Problem der Benutzerführung. Man ändert am Objekt „Ladepunkt“ die Konfig für alle, die diese Konfig verwenden. Und das ist dem Änderer nicht klar, weil er ja am konkreten Objekt „Ladepunkt“ herumändert und nicht in der Konfig am Objekt „Mitarbeiterfahrzeug“. Ändert er an dieser Stelle, ist ihm klar, dass das nun alle Mitarbeiterfahrzeuge betrifft.

[Thomas aus W]

Alternativ einen Plan anlegen und im Frontend dann temporär nur die einmalige Zeit ändern.

Das wäre genau das Verhalten, dass ich für einmaliges Zielladen erwarte. Im Plan stehen die "Leistungsedaten" und im Frontend will ich nur die Zielzeit anpassen.

Wie gesagt stelle ich mir das so vor, dass, wenn man in der Hauptansicht auf einen deaktivierten Einmalzeitplan klickt, automatisch die Datum/Zeit-Auswahl (und sonst nichts) auf geht und wenn man auf einen aktiven Einmalzeitplan klickt dieser schlicht deaktiviert wird (bisheriges Verhalten).

Zusätzlich könnte so ein Plan nach Abstecken des Fahrzeugs automatisch inaktiv werden.

bye
TW

[Gero]

Zusätzlich könnte so ein Plan nach Abstecken des Fahrzeugs automatisch inaktiv werden.

Genau. Statt „inaktiv“ würde ich sogar verwerfen und durch die Konfig ersetzen. Einfach um die Trennung zwischen „Temporär am Ladepunkt geändert“ und „Konfiguratiin“ deutlich zu halten. Wer diese Unterscheidung nicht mag, möge bitte - wiederum in der Konfiguratiion - die neu geschaffene Option wählen.

Ganz schlimm fände ich einen Mischmasch: Ladenodus ist temporär und Zeiten des Zeit- oder Zeilladens sind Konfiguration. Oder noch schlimmer: Zeit- und Zielladepläne werden unterschiedlich behandelt.

Oh, und beim Ändern der Konfiguration, wenn eine solche am Ladepunkt aktiv ist, würde ich immer überschreiben. Oder, um es noch deutlicher zu machen - die Auswahl des Autos zurücksetzen. Eine laufende Ladung würde ich unangetastet lassen. Vielleicht wäre ein Popup beim Speichern in der Konfiguration auch eine Lösung

[Thomas aus W]

einen Mischmasch: Ladenodus ist temporär und Zeiten des Zeit- oder Zeilladens sind Konfiguration

Also eigentlich finde ich diesen "Mischmasch" - nur eben umgekehrt - durchaus sinnvoll.
Im Frontend will ich temporär nur konkrete Zeiten ändern, vielleicht noch einen Ziel SoC (eigentlich aber nicht). Den Rest vom Plan will ich nicht temporär ändern (können), da würde ich ja einfach einen anderen vorbereiteten Plan aktivieren.

Dafür müssten aber im Ladeprofil neu angelegte Pläne immer sofort (deaktiviert) in der Hauptansicht sichtbar sein, sobald sie erzeugt wurden.

bye
TT

[openWB]

Wenn die config auch im Frontend möglich ist, sehe ich aber auch kein Problem dort ein einmaliges zu konfigurieren.

Das ist ja gerade das ursächlichen Problem der Benutzerführung. Man ändert am Objekt „Ladepunkt“ die Konfig für alle, die diese Konfig verwenden. Und das ist dem Änderer nicht klar, weil er ja am konkreten Objekt „Ladepunkt“ herumändert und nicht in der Konfig am Objekt „Mitarbeiterfahrzeug“. Ändert er an dieser Stelle, ist ihm klar, dass das nun alle Mitarbeiterfahrzeuge betrifft.

Wenn er das im Frontend tut und die temporären Einstellungen aktiv sind ändert er das ja auch nicht für alle.

[openWB]

Alternativ einen Plan anlegen und im Frontend dann temporär nur die einmalige Zeit ändern.

Das wäre genau das Verhalten, dass ich für einmaliges Zielladen erwarte. Im Plan stehen die "Leistungsedaten" und im Frontend will ich nur die Zielzeit anpassen.

Wie gesagt stelle ich mir das so vor, dass, wenn man in der Hauptansicht auf einen deaktivierten Einmalzeitplan klickt, automatisch die Datum/Zeit-Auswahl (und sonst nichts) auf geht und wenn man auf einen aktiven Einmalzeitplan klickt dieser schlicht deaktiviert wird (bisheriges Verhalten).

Zusätzlich könnte so ein Plan nach Abstecken des Fahrzeugs automatisch inaktiv werden.

bye
TW

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

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

[openWB]

einen Mischmasch: Ladenodus ist temporär und Zeiten des Zeit- oder Zeilladens sind Konfiguration

Also eigentlich finde ich diesen "Mischmasch" - nur eben umgekehrt - durchaus sinnvoll.
Im Frontend will ich temporär nur konkrete Zeiten ändern, vielleicht noch einen Ziel SoC (eigentlich aber nicht). Den Rest vom Plan will ich nicht temporär ändern (können), da würde ich ja einfach einen anderen vorbereiteten Plan aktivieren.

Dafür müssten aber im Ladeprofil neu angelegte Pläne immer sofort (deaktiviert) in der Hauptansicht sichtbar sein, sobald sie erzeugt wurden.

bye
TT

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


Ich weiß, dass 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.