Use case GUI => Ladeprofil beeinflussung und zwei Wünsche
Verfasst: Mo Apr 15, 2024 8:20 am
Es gab nun mehrfach Diskussionen zum Thema GUI und dessen direkten Einfluss auf die Einstellungen im Ladeprofil, es hieß u.a. es wird intern diskutiert, mich würde interessieren ob es da ein Ergebnis gab.
z.B. viewtopic.php?t=8070&start=40 und viewtopic.php?t=8184
Für private Anbieter ist es, so wie es aktuell ist, meiner Meinung nach nicht optimal, ich für mich habe das so gelöst, dass ich beim Abstecken folgende Dinge per MQTT zurücksetze:
openWB/set/vehicle/template/charge_template/1/chargemode/pv_charging/max_soc = 101 (101 = AUS)
openWB/set/vehicle/template/charge_template/1/chargemode/selected = pv_charging
openWB/set/vehicle/template/charge_template/1/chargemode/pv_charging/min_current = 0
openWB/set/vehicle/template/charge_template/1/chargemode/pv_charging/min_soc = 0
openWB/set/general/chargemode_config/pv_charging/bat_mode = min_soc_bat_mode
Das sind alles Werte die ich ggf. beim Laden verändere und die möchte ich nach dem Abstecken wieder auf meinen "Standard" haben.
Eventuell brauchen das andere Anwender auch ähnlich und können das nicht z.B. per Node-Red machen. Wäre es nicht sinnvoll dazu ein Option in die openWB einzubauen die ähnliches macht, also Werte nach dem Abstecken wieder auf Standard zu stellen, so wäre das weiterhin für die gewerblichen Anwendungen wie gehabt nutzbar und zusätzlich für die privaten einfacher.
Dann wäre es sehr toll wenn das von der 1.9er übernommen werden könnte: https://github.com/openWB/core/issues/1253 (Wake up Zoe)
Kommt noch eine Änderung das nicht erst mit 1p geladen wird und dann nach Zeit auf 3p umgeschaltet wird, auch wenn schon beim Anstecken mehr als genug Überschuß vorhanden ist? Dazu gibt es auch mehrere Themen, das aktuellste was ich kenne: viewtopic.php?t=8596
Die Begründung zu den 16min in "Verzögerung automat. Phasenumschaltung" war, zum Schutz der Relais openWB und EV seitig, da macht aber genau der Start mit 1p genau das Gegenteil wenn beim anstecken genug Überschuß da ist um dirket mit 3p zu starten.
Sonst bin ich mit der 2.x sehr zufrieden, bei der bzw. meiner Pro gibt es noch mit dem RFID so kleine Zickereien, aber da sind die Entwickler dran und damit kann ich auch leben.
z.B. viewtopic.php?t=8070&start=40 und viewtopic.php?t=8184
Für private Anbieter ist es, so wie es aktuell ist, meiner Meinung nach nicht optimal, ich für mich habe das so gelöst, dass ich beim Abstecken folgende Dinge per MQTT zurücksetze:
openWB/set/vehicle/template/charge_template/1/chargemode/pv_charging/max_soc = 101 (101 = AUS)
openWB/set/vehicle/template/charge_template/1/chargemode/selected = pv_charging
openWB/set/vehicle/template/charge_template/1/chargemode/pv_charging/min_current = 0
openWB/set/vehicle/template/charge_template/1/chargemode/pv_charging/min_soc = 0
openWB/set/general/chargemode_config/pv_charging/bat_mode = min_soc_bat_mode
Das sind alles Werte die ich ggf. beim Laden verändere und die möchte ich nach dem Abstecken wieder auf meinen "Standard" haben.
Eventuell brauchen das andere Anwender auch ähnlich und können das nicht z.B. per Node-Red machen. Wäre es nicht sinnvoll dazu ein Option in die openWB einzubauen die ähnliches macht, also Werte nach dem Abstecken wieder auf Standard zu stellen, so wäre das weiterhin für die gewerblichen Anwendungen wie gehabt nutzbar und zusätzlich für die privaten einfacher.
Dann wäre es sehr toll wenn das von der 1.9er übernommen werden könnte: https://github.com/openWB/core/issues/1253 (Wake up Zoe)
Kommt noch eine Änderung das nicht erst mit 1p geladen wird und dann nach Zeit auf 3p umgeschaltet wird, auch wenn schon beim Anstecken mehr als genug Überschuß vorhanden ist? Dazu gibt es auch mehrere Themen, das aktuellste was ich kenne: viewtopic.php?t=8596
Die Begründung zu den 16min in "Verzögerung automat. Phasenumschaltung" war, zum Schutz der Relais openWB und EV seitig, da macht aber genau der Start mit 1p genau das Gegenteil wenn beim anstecken genug Überschuß da ist um dirket mit 3p zu starten.
Sonst bin ich mit der 2.x sehr zufrieden, bei der bzw. meiner Pro gibt es noch mit dem RFID so kleine Zickereien, aber da sind die Entwickler dran und damit kann ich auch leben.