Experimental: add heating support

[andig]

This PR provides initial support for dedicated heating units like "Heizstäbe".

TODO

• rebase when Support chargers without vehicle #6316 is merged
• better handling for soc from charger instead of vehicle (done with Support chargers without vehicle #6316)
• better temperature selection
• remove "verbunden" status
• remove all minSoc/targetSoc handling from ui (or leave as-is for time being though over-engineered for heaters?)

[naltatis]

Du hast hier den Fahrzeugwechsel (Gastfahrzeug, ...) bewusst ausgebaut. Das ist sicher auch sinnvoll und vermutlich auch bei vielen Smart-Steckdosen-Anwendungsfällen das gewünschte Verhalten. Ich fänd gut, wenn wir das konfigurationsseitig abbilden. Es gibt ja schon die 1:1 Loadpoint-Vehicle-Zuordnung, da könnten wir dem Loadpoint eine Art fixedVehicle Eigenschaft hinzufügen die die Fahrzeugänderung durch UI und API unterbindet.

[andig]

Du hast hier den Fahrzeugwechsel (Gastfahrzeug, ...) bewusst ausgebaut. Das ist sicher auch sinnvoll und vermutlich auch bei vielen Smart-Steckdosen-Anwendungsfällen das gewünschte Verhalten. Ich fänd gut, wenn wir das konfigurationsseitig abbilden. Es gibt ja schon die 1:1 Loadpoint-Vehicle-Zuordnung, da könnten wir dem Loadpoint eine Art fixedVehicle Eigenschaft hinzufügen die die Fahrzeugänderung durch UI und API unterbindet.

Das könnten wir auch vorab in einen eigenen PR raus ziehen wenn Du magst. Für die Switchsockets ist das schon umgesetzt. Fehlt die Integration ins Vehicle.vue. Wenn Du das hier ergänzen willst würde ich dann splitten.

Was hältst Du davon, dafür auch ein Icon am Charger definierbar zu machen? Spannend wird nochmal, wie ein Vehicle ohne Namen (da ohne Vehicle) dann eigentlich aussehen soll... Auch "verbunden" als Status muss entfallen.

[naltatis]

better name for fixedconnection (noplug?)

noplug find ich nicht so gut. Gerade weil Smartsteckdosen ja immer einen haben, man in der Konfiguration aber sagten will, dass man den nicht umstecken wird.

Wir könnten auch in Richtung withoutVehicle/noVehicle gehen. In den Szenarien nutzen wir ja immer das "Gastfahrzeug".

[naltatis]

proper icon handling for energy flow

Für die UI kann das Icon eigentlich transparent gehandhabt werden. Also selbst wenn wir es am Charger pflegbar machen würde ich vorschlagen das in der API weiterhin als vehicleIcon bereitzustellen. Dann haben wir in der UI keine weiteren Sonderfälle. Und zwei Icon gleichzeitig wollen wir ja ohnehin nicht.

[naltatis]

Das könnten wir auch vorab in einen eigenen PR raus ziehen wenn Du magst.

Finde ich eine gute Idee wenn das vom Aufwand vertretbar ist. Gerne auch erstmal nur die Go Änderungen und ich überleg mir dann den UI Part.

[andig]

proper icon handling for energy flow

Für die UI kann das Icon eigentlich transparent gehandhabt werden. Also selbst wenn wir es am Charger pflegbar machen würde ich vorschlagen das in der API weiterhin als vehicleIcon bereitzustellen. Dann haben wir in der UI keine weiteren Sonderfälle. Und zwei Icon gleichzeitig wollen wir ja ohnehin nicht.

Mache ich so 👍🏻. Die Features würde ich gerne als charger features lassen, da es ja tatsächlich andere Fähigkeiten als am vehicle sind.

[andig]

Und zwei Icon gleichzeitig wollen wir ja ohnehin nicht.

Ist umgesetzt. Damit bietet sich an, das in 2 PRs aufzusplitten:

• Infrastruktur (Support chargers without vehicle #6316)
• Heizstab plus UI (verbleibt hier)

[andig]

Rebased onto master

[dc-redeclipse]

Es geht um die bessere Visualisierung von Akkus z.B. Ecoflows oder eigenbau Akkuspeichern die als Hausspeicher genutzt werden sollen. Dazu gehört auch das die Dialoge nicht mehr z.B. "Warten auf Fahrzeuge" anzeigen.