Support for max Soc/max Energy

[requiemmg]

Hi,

title has it all: would it be possible not only to set the charging mode but also to set the charging limit (method: SoC or Charged Energy with their respective values) through this addon?

[a529987659852]

Hallo zusammen, ich habe mir diesen Fall einmal angesehen: Mindeststrom für PV-/Sofortladen, Begrenzung (keine, SoC, Engerie), Energiemenge bzw. Ziel-SoC und andere Parameter sind im Ladeprofil (und nicht am Ladepunkt) hinterlegt. Das Ladeprofil ist einem Fahrzeug zugeordnet. Das Fahrzeug wiederum ist an einem Ladepunkt angesteckt.

Folgendes wäre möglich:

• im HA eine numerische Entität definieren, z.B. für Mindeststrom oder Ziel-SoC
• Wenn der User einen Wert ändert, z.B. den Ziel-SoC auf 50 % ändert, kann der Wert an die openWB übermittelt werden. Das SET-MQTT-Thema ist zwar dynamisch (Ladepunkt -> Welches Fahrzeug steckt gerade? -> Welches Ladeprofil ist diesem Fahrzug zugeordnet?). --> Das wäre aber machbar, da ich einen Sensor habe, der das aktuelle Ladeprofil anzeigt.

Jetzt das Problem (am Beispiel des Ziel-SoC).

• Der User wählt einen Wert (z.B. 50 % auf einem Schieberegler).
• Im HA wird der Wert nun mit 50 % angezeigt.
• Der Wert wird auf MQTT publiziert.
• Die openWB nimmt die Änderung an oder eben nicht (z.B. falscher Wert, keine Netzwerkverbindung, sonstiges)
• Wenn die Änderung angenommen wird, stimmt das Setting im HA mit der openWB überein und alles ist gut.
• Wenn die Änderung nicht angenommen wird, zeigt HA 50 % an, der User meint, seine Änderung kam an, aber die openWB arbeitet mit dem alten Wert.

Um den NIO-Fall abzudecken, hatte ich in der alten Version den Wert erst auf dem UI geändert, wenn die openWB die Änderung umgesetzt hatte. Das ging einfach, da der Ladepunkt diese Info hatte und man einfach für jeden Ladepunkt ein bestimmtes MQTT-Topic subscribieren konnte. In der neuen Version ist das leider dynamisch (s.o.: Ladepunkt -> Fahrzeug -> Ladeprofil), sodass ich kein MQTT-Topic abonieren kann wenn der Sensor erstellt wird. Prinzipiell müsste man alle Ladeprofile abonieren und dann schauen, welches Fahrzeug mit welchem Ladeprofil am aktuellen Ladepunkt steckt und dann erst den Wert auf dem UI ändern, wenn die Umsetzung auch tatsächlich gemacht wurde.

Ein ähnliches Problem haben wir beim Neustart von HA: HA zeigt einen Wert x an und wird neu gestartet. Ist der Wert x dann immernoch der korrekte, da es ja sein könnte, dass jemand in der Zwischenzeit den Wert auf der openWB direkt geändert hat. Oder aber ich zeige bei jedem Neustart N/A an. Dann weiß man aber leider nicht, wie die Einstellung gerade aussieht.

Es mag sein, dass es sich für euch reichlich 'overengineered' anhört, da die meisten vielleicht eh nur einen Ladepunkt, ein Fahrzeug und ein Ladeprofil haben. Aber leider kann ich das nicht vorhersehen und die Architektur der openWB ist in der Version 2 etwas komplexer geworden als in der Version 1.

Um es zusammenzufassen: Aktuell sehe ich leider nicht, wie man das so ohne weiteres umsetzen kann. Wer eine Idee hat, möge sie bitte posten. Falls nicht, gibt es das Feature erstmal leider nicht.

Gruß Andreas

[scrichab]

Hallo, passend zu o.g. Anfrage wollte ich ja auch Auswahl Fahrzeug und Anzahl Phasen PV Ladung mit der Integration abdecken. Das läuft bei mir mit manuell angelegten Entitäten per mqtt seit Umstellung auf openWB 2 ohne Probleme. Hatte bisher nicht das Problem das eine Änderung von der Wallbox nicht angenommen wurde . Ein Beispiel wäre ja Fahrzeug Auswahl wenn hier der Ladevorgang schon gestartet ist kann man das Fahrzeug nicht mehr umstellen. Und das gleiche passiert dann auch in HA. oWB steht auf FZ 1 - stelle in HA auf FZ 2 und das wird sofort wieder umgestellt da es von der oWB nicht angenommen wird und somit das topic wieder geändert wird.

vg just my two cents

[a529987659852]

Wie lauten deine SET-Topics? Und auf welchen MQTT-Topics steht das Resultat? Können wir sicher sein, dass das Resultat-Topic beim Erzeugen der Integration feststeht und sich nicht ändert? Falls ja, geht das. Falls nicht, haben wir ein Problem, da ein Sensor (Dropdown, Nummer, etc.) beim Erzeugen in HA ein MQTT-Topic für den aktuellen Wert subscribieren muss.

[scrichab]

für die Fahrzeug Auswahl openWB/chargepoint/4/get/connected_vehicle/info - daraus json id openWB/set/chargepoint/4/config/ev für PV Laden Anzahl Phasen openWB/general/chargemode_config/pv_charging/phases_to_use openWB/set/general/chargemode_config/pv_charging/phases_to_use

[a529987659852]

Danke - das sollte machbar sein, da die Topics nicht änderbar aussehen (PV Laden Anzahl Phasen) oder pro Ladepunkt fix sind (Fahrzeugauswahl). Da ich nicht weiß, wie viele Fahrzeug-IDs es gibt, werde ich einfach mal ein Dropdown mit 1...10 zur Auswahl bieten.

[freddeh]

Hallo zusammen, ich habe mir diesen Fall einmal angesehen: Mindeststrom für PV-/Sofortladen, Begrenzung (keine, SoC, Engerie), Energiemenge bzw. Ziel-SoC und andere Parameter sind im Ladeprofil (und nicht am Ladepunkt) hinterlegt. Das Ladeprofil ist einem Fahrzeug zugeordnet. Das Fahrzeug wiederum ist an einem Ladepunkt angesteckt.

Folgendes wäre möglich:

• im HA eine numerische Entität definieren, z.B. für Mindeststrom oder Ziel-SoC
• Wenn der User einen Wert ändert, z.B. den Ziel-SoC auf 50 % ändert, kann der Wert an die openWB übermittelt werden. Das SET-MQTT-Thema ist zwar dynamisch (Ladepunkt -> Welches Fahrzeug steckt gerade? -> Welches Ladeprofil ist diesem Fahrzug zugeordnet?). --> Das wäre aber machbar, da ich einen Sensor habe, der das aktuelle Ladeprofil anzeigt.

Jetzt das Problem (am Beispiel des Ziel-SoC).

• Der User wählt einen Wert (z.B. 50 % auf einem Schieberegler).
• Im HA wird der Wert nun mit 50 % angezeigt.
• Der Wert wird auf MQTT publiziert.
• Die openWB nimmt die Änderung an oder eben nicht (z.B. falscher Wert, keine Netzwerkverbindung, sonstiges)
• Wenn die Änderung angenommen wird, stimmt das Setting im HA mit der openWB überein und alles ist gut.
• Wenn die Änderung nicht angenommen wird, zeigt HA 50 % an, der User meint, seine Änderung kam an, aber die openWB arbeitet mit dem alten Wert.

Um den NIO-Fall abzudecken, hatte ich in der alten Version den Wert erst auf dem UI geändert, wenn die openWB die Änderung umgesetzt hatte. Das ging einfach, da der Ladepunkt diese Info hatte und man einfach für jeden Ladepunkt ein bestimmtes MQTT-Topic subscribieren konnte. In der neuen Version ist das leider dynamisch (s.o.: Ladepunkt -> Fahrzeug -> Ladeprofil), sodass ich kein MQTT-Topic abonieren kann wenn der Sensor erstellt wird. Prinzipiell müsste man alle Ladeprofile abonieren und dann schauen, welches Fahrzeug mit welchem Ladeprofil am aktuellen Ladepunkt steckt und dann erst den Wert auf dem UI ändern, wenn die Umsetzung auch tatsächlich gemacht wurde.

Ein ähnliches Problem haben wir beim Neustart von HA: HA zeigt einen Wert x an und wird neu gestartet. Ist der Wert x dann immernoch der korrekte, da es ja sein könnte, dass jemand in der Zwischenzeit den Wert auf der openWB direkt geändert hat. Oder aber ich zeige bei jedem Neustart N/A an. Dann weiß man aber leider nicht, wie die Einstellung gerade aussieht.

Es mag sein, dass es sich für euch reichlich 'overengineered' anhört, da die meisten vielleicht eh nur einen Ladepunkt, ein Fahrzeug und ein Ladeprofil haben. Aber leider kann ich das nicht vorhersehen und die Architektur der openWB ist in der Version 2 etwas komplexer geworden als in der Version 1.

Um es zusammenzufassen: Aktuell sehe ich leider nicht, wie man das so ohne weiteres umsetzen kann. Wer eine Idee hat, möge sie bitte posten. Falls nicht, gibt es das Feature erstmal leider nicht.

Gruß Andreas

Spontan musste ich an das Thermostat Device in Homeassistant mit Setpoint und Value denken.. weiß nicht ob das ein gangbarer Workaround wäre, wollte den Gedanken nur teilen, da ich das Feature sehr vermisse. Für mich persönlich wären auch zwei separate Entitäten OK und die Einschränkung nach Neustart ebenso…