Add loadpoint config api (BC)

[andig]

Fix #12903

This PR deprecates the following yaml loadpoint settings:

• mode
• title
• phases
• min/max current
• priority

TODO

• UI for loadpoint properties @naltatis
• UI for adding/changing charger @naltatis
• UI for adding/changing lp meter @naltatis
• e2e tests @naltatis
• add translations @naltatis
• UI default vehicle select @naltatis
• UI circuit assignment @naltatis
• API for assignable circuits @andig
• API set meter, charger, defaultVehicle @andig
• UI for adding/removing loadpoints @naltatis
• API for adding/remove loadpoints @andig
• implement config as settings
• unable to save priority=0 @andig
• remove orphan meters/chargers (no site/loadpoint ref) on startup
• fix unit tests @andig
• fix initial lp saving issue (logger, settings) @andig
• store loadpoint settings in config (based on chore: persist device details as json #15224) @andig
• handle pointer values like smartcostlimit
• decide/adapt migration strategy (use evcc migrate?) @andig @naltatis
  • evcc migrate --reset removes all ui configured entities (vehicles, meters, chargers, loadpoints)
  • migrating these entities from yaml to ui will be done in a separate issue later
• demo mode solution @naltatis
• loadpoint settings adapter (config & runtime values) @andig

[naltatis]

@andig die APIs sehen gut aus. Funktioniert alles wie es soll. Wir hatten ja gesagt, wir wollten den Scope klein halten und Vehicle/Charger erstmal ausklammern. Ich glaub es ist doch ne gute Idee, wenn wir die Referenz-Felder hier gleich mit aufnehmen. Sonst haben wir einen komischen Zwischenstand den man schwer releasen kann. Magst du die beiden Felder ergänzen?

[andig]

Mache ich. Am Fahrzeug könnten wir dann noch maxCurrent1p und minCurrent3p ergänzen 🙃.

[naltatis]

↔ wider layout (general)
🏷️ loadpoint status

[andig]

Ich glaub es ist doch ne gute Idee, wenn wir die Referenz-Felder hier gleich mit aufnehmen.

So, jetzt nochmal langsam. Was meinst Du damit konkret? Phases z.B. ist doch drin?

[naltatis]

Mit Referenz Felder meine ich:

• lp.vehicle
• lp.charger
• lp.meter

Da stehen dann die 'name's der am loadpoint verknüpften devices drin und sind darüber auch änderbar.

[andig]

Ah, ok. Aber erstmal ohne Updatefähigkeit?

[naltatis]

Wie es passt. Update wäre cool (bspw default Fahrzeug). Lesen wäre aber auch ein Fortschritt.

[naltatis]

@andig wollen wir, wo wir gerade dabei sind, nicht auch gleich soc und enable/disable mit reinnehmen? Dann sind wir hier durch und wir haben keinen Zwischenstand, den wir wieder erklären müssen. Könnten wir einfach flach abbilden. So viele Werte sind das ja glücklicherweise nicht.

• socPollMode
• socPollInterval
• socEstimate
• enableThreshold
• enableDelay
• disableThreshold
• disableDelay

[naltatis]

Setup von evcc mit einer leeren evcc.yaml 🎉

setup.webm

[naltatis]

@andig ich hab gerade noch mal ausprobiert wie sich die Einstellungen von UI-konfigurierten Fahrzeugen an UI-konfigurierten Ladepunkten verhalten. Das sieht alles korrekt, bzw. wie erwartet aus. Die fahrzeugspezifischen Werte (bspw. vehicle.db:329.planSoc) landen weiterhin gepräfixt in der settings Tabelle. Heißt das Fahrzeug kann zwischen den Ladepunkte weiterhin hin und verwechseln ohne dass wir Daten verlieren.

Dementsprechend steht hier nur noch eine gute Lösung für den Demo-Modus aus. Hier tendiere ich gerade dazu das aktuelle Verhalten erst einmal zu belassen:

• keine evcc.yaml > Demo Modus
• existierende evcc.yaml > Normaler Modus (Welcome Dialog, wenn keine Ladepunkte)

Ein explizites Anwählen des Demo Modus (bspw. durch CLI Param) würd ich erst dann machen, wenn wir Config UI nicht mehr hinter experimental Flag haben.