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

[Thomas aus W]

Die Frage ist: brauchen wir neben einem PV-Modus, bei dem man noch Zeit- und Ziel-Pläne mit oder ohne Preisbeachtung und einen Ziel SoC für PVÜberschusslanden von 0% konfigurieren kann noch einen weiteren Modus ohne PV-Überschussladen, bei dem man Zeit- und Ziel-Pläne mit oder ohne Preisbeachtung konfigurieren kann?

[Gero]

Der wichtige Punkt ist bei dieser kurzen Zusammenfassung "mit und ohne Preisbeachtung". Wie @ChristophR schon angemerkt hat, wird es Leute geben, die im Sommer keine Netzladung haben wollen, egal wie billig der Strom ist. Die müssen dann als Grenzpreis -100 Euros oder so etwas einstellen. Da wäre ein reiner PV-Modus intuitiver und würde weniger nach workaround aussehen. Andererseits wäre Zielladen im Modus Nur-PV halt nichts, was ohne Netzbezug zuverlässig funktionieren wird. Aber gut, das ist ja zum Einen offensichtlich und zum Anderen kann man ja den eventuell vorhandenen Zielladeplan deaktivieren, wenn man nur Sonne laden möchte.

Ich würde auch noch einmal anregen, nachzuschauen, warum Zielladen in SW2 einen eigenen Modus bekommen hat. Aber ansonsten wäre ich auch für Zeit- und Zielladen als zusätzlich buchbare Optionen.

Wie ist denn die Sichtweise mit dem Vorschlag die Ladepläne ans Auto statt ans Ladeprofil zu hängen?

[Thomas aus W]

Wie @ChristophR schon angemerkt hat, wird es Leute geben, die im Sommer keine Netzladung haben wollen, egal wie billig der Strom ist. Die müssen dann als Grenzpreis -100 Euros oder so etwas einstellen.

Gerade für die ist das doch dann einfacher.
Die lassen halt alle Zusatzoptionen deaktiviert...

Meine Idee ist doch: wenn man was anderes als stur PV-Überschuss will dann muss man irgendwas konfigurieren. Und dieses irgendwas kann man dann je nach Bedarf aktivieren und deaktivieren. Je feingranularer und je komplexer meine Ansprüche sind, je komplexer wir die Konfiguration.

bye
TW

[ChristophR]

Kann mir jemand die fettgedruckte Änderung aus #2879 erklären? Ist das schon ein Breaking Change oder verstehe ich es nur falsch?
https://github.com/openWB/core/pull/2879

Temp Einstellungen aktiv:

Wechsel des Ladeprofils, das dem Fahrzeug zugeordnet ist -> persistente und temporäre Einstellungen werden für das betroffene Fahrzeug aktualisiert
Änderung im persistenten Ladeprofil-> nur temporäre Einstellungen von Fahrzeugen, die das geänderte Profil verwenden, werden aktualisiert
Änderung im temporären Ladeprofil -> ändert nichts in den persistenten Einstellungen
Abstecken -> persistentes Ladeprofil wird in temporäres kopiert
Anderes Fahrzeug wird dem Ladepunkt zugeordnet -> peristente Ladeprofil Einstellungen des anderen Fahrzeugs werden am Ladepunkt zugeordnet

[Gero]

Ich lese das so, dass immer überschrieben wird. Egal ob Ànderungen am abgesteckten Ladepunkt genacht wurden oder am angesteckten Ladepubkt gerade eine Ladung aktiv ist.

Wäre für mich konsistent, ist aber ein anderes Verhalten als in 2.1.8 ab patch 1.

[aiole]

Es wird nun nicht mehr stoisch überschrieben, sondern vorher geprüft, welche Fahrzeuge das (geänderte) Fahrzeug-Profil tatsächlich nutzen. Nur diese werden dann überschrieben - also keine "Rundum-Überschreibung".

Aktuell geht es bei 2.1.9 zunächst darum, die aus der 2.1.8-er Temporär/Persistent-Nutzung resultierenden Negativ-Effekte bei den Plänen so klein wie möglich zu halten. Zusätzlich die Komplettabschaltoption für Temporärnutzung.

Bezüglich weitergehender Vereinfachungen wie
# Pläne direkt in Fahrzeuge oder
# Pläne nur 1x im Frontend - dann dort aber persistent
# Zielladen als schaltbare Option ähnlich Zeitladen statt eigener Lademodus
# usw.
werden eure Ideen hier gelesen und vom Team bewertet. Das dauert immer etwas.

Zu bedenken ist dabei auch, dass nur wenig Bedieungsumstellungen gefahren werden sollen, da dies ansonsten zu Verwirrung führt. Z.B. ist die in 2.1.8 eingeführte Temporäroption OHNE Abschaltmöglichkeit für Nerds klar, aber für etliche Bestands-user eine Herausforderung, die den Support belastet.

Ich denke, wir sind hier auf einem guten Weg für ein verbessertes Bedienkonzept.

[Gero]

Es wird nun nicht mehr stoisch überschrieben, sondern vorher geprüft, welche Fahrzeuge das (geänderte) Fahrzeug-Profil tatsächlich nutzen. Nur diese werden dann überschrieben - also keine "Rundum-Überschreibung".

Zu 2.1.8p1 wurde eben nicht stoisch überschrieben, sondern nur, wenn „Ladeprofil alt“ == Lladeprofil am Ladepunkt“ war. Diese Prüfung ist nun entfallen. Wie das bei angestecktem Fahrzeug ist, kann ich gerade nicht ausprobieren. Stoisch überschreiben wäre aber gut.

Edit: sogar bei laufender Ladung wird das Ladeprofil in den Ladepunkt geschrieben. Sehr gut, so kann man sich das merken.

[aiole]

Ja - so war es gemeint. Direktübernahme, aber eben nur an den Fahrzeugen, die das betreffende Ladeprofil nutzen.

[ChristophR]

Ja - so war es gemeint. Direktübernahme, aber eben nur an den Fahrzeugen, die das betreffende Ladeprofil nutzen.

Ich bin etwas verwundert, da ich dachte, dass genau das in Ladeparks und WEGs verhindert werden sollte?

Aber so ist es genauso, wie wir es brauchen, Optimierung kann dann wieder mit normaler Priorität weitergehen.

Für mein Seelenheil fehlt jetzt nur noch, dass abgelaufene Ziele nicht mehr aktiv bleiben, aber das gehört hier ja nicht hin.

[Gero]

Ja - so war es gemeint. Direktübernahme, aber eben nur an den Fahrzeugen, die das betreffende Ladeprofil nutzen.

Ich bin etwas verwundert, da ich dachte, dass genau das in Ladeparks und WEGs verhindert werden sollte?

Dss Problem im Ladepark war die Änderung im Ladepunkt, die sich auf alle Fahrzeuge dieses Ladeprofils ausgewirkt hat. Wenn man in der Konfiguration ändert, ändert man ja alle Fahrzeuge dieses Ladeprofils und sollte erwarten, dass man da alle ändert.