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
• 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
• decide/adapt migration strategy (use evcc migrate?) @andig @naltatis
• remove orphan meters/chargers (no site/loadpoint ref) on startup

[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]

@andig master ist drin, ui baut wieder. fehlt nur noch go :D

[andig]

Wir haben irgendwas komisches mit der ThresholdsConfig gemacht, nicht sicher warum.

[naltatis]

[andig]

Bzgl. Phases: wie gehen wir mit „auto“ um falls der Charger 3p angeschlossen ist? „Electrical connection“ trifft es dann ja nicht ganz.

[naltatis]

Aktuell haben wir die Phaseneinstellungen ja bereits im Main UI. Hier mischen wir aber mometan zwei Konzepte im gleichen Property:

• 1p3p Charger: Aktueller Nutzerwunsch mit wie viel Phasen geladen werden soll (1p, 3p, auto) - kann sich ändern
• Non-1p3p Charger: Information über die elektrische Verkabelung des Chargers (1p, 2p, 3p) - ändert sich idR nicht

Ich würd das jetzt trennen. Also die elektrische Verbindung rein im Config UI sehen. Im Main UI gibts die Phasen-Setting (1,3,auto) nur für 1p3p Charger.

In diesem PR allerdings, wenn möglich, erstmal keine Verhaltensänderung im Vergleich zur evcc.yaml.

[premultiply]

Diese Unterscheidung gibt es im Code nicht.

[andig]

Wir können das gerne getrennt machen. Im Main UI sind einige Dinge aber "nur für die Session". Da sollten wir nochmal schauen, dass wir keine Verhalten mischen.