Add loadpoint config api (BC)

[andig]

Fix https://github.com/evcc-io/evcc/issues/12903

This PR deprecates the following yaml loadpoint settings:

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

TODO

• [x] UI for loadpoint properties @naltatis
• [x] UI for adding/changing charger @naltatis
• [x] UI for adding/changing lp meter @naltatis
• [ ] e2e tests @naltatis
• [ ] add translations @naltatis
• [x] UI default vehicle select @naltatis
• [x] UI circuit assignment @naltatis
• [x] API for assignable circuits @andig
• [x] API set meter, charger, defaultVehicle @andig
• [x] UI for adding/removing loadpoints @naltatis
• [x] API for adding/remove loadpoints @andig
• [x] implement config as settings
• [x] unable to save priority=0 @andig
• [ ] remove orphan meters/chargers (no site/loadpoint ref) on startup
• [x] fix unit tests @andig
• [x] fix initial lp saving issue (logger, settings) @andig
• [ ] store loadpoint settings in config (based on https://github.com/evcc-io/evcc/pull/15224) @andig
• [ ] handle pointer values like smartcostlimit

Out of scope

• [ ] decide/adapt migration strategy (use evcc migrate?) @andig @naltatis

[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

[andig]

Die Refs sind drin (read-only). socPollMode/socPollInterval gehören m.E. eher ans Fahrzeug wobei sich die Frage stellt, was wir dann mit integrated Devices machen- einfach immer abfragen wie wir lustig sind (These: ja). Thresholds und Delay gehören an den LP können m.E: im ersten Schritt aber weg- weniger ist mehr, die Defaults sind nicht verkehrt.

[naltatis]

Mein eigentlicher Gedanke war, dass wir, wenn wir soc/enable/disable mit dazunehmen eine einfach verständliche Story für den Anwender haben: "Alle Loadpoint Einstellungen sind jetzt im UI." Deutlich einfacher zu verstehen als ein Misch-Setup wo sich von Release zu Release die Verhältnisse verändern.

Thresholds und Delay gehören an den LP können m.E: im ersten Schritt aber weg- weniger ist mehr, die Defaults sind nicht verkehrt.

Wäre für mich bspw. ein Deal Breaker. Ich nutze hier für das Zusammenspiel von EV und Heizstab bewusst nicht die Defaults. Soc-Settings ans Fahrzeug migrieren find ich auch gut, aber würde ich in einem separaten Schritt machen. Hier wäre mein Fokus erstmal "nur" yaml-Einstellungen zu UI-Einstellungen konvertieren.

[naltatis]

@andig Wenn priority am lp 0 ist, bekomme ich keinen Wert und hab damit auch keine Auswahl im UI. Das könnte ich mit nem Default lösen. Schöner wäre aber der echte Wert.

Das eigentliche Problem ist, dass Speichern von Priority != 0 funktioniert. Schaust du da noch mal rein?

[naltatis]

improved layout, more fields

real values, badge colors

[andig]

Wäre für mich bspw. ein Deal Breaker

Verstehe ich nicht. Dir LPs brauchts weiter in der yaml, also sind auch die Settings noch da?

[naltatis]

Verstehe ich nicht. Dir LPs brauchts weiter in der yaml, also sind auch die Settings noch da?

Ja, mir ging es ja um diesen Punkt:

Deutlich einfacher zu verstehen als ein Misch-Setup wo sich von Release zu Release die Verhältnisse verändern.

[andig]

Yoah, aber breaking ist da nix. Schöner wärs.

[andig]

unable to save priority=0

@naltatis ist behoben- auch 0 wird jetzt ausgegeben. Spannend ist allerdings auch SmartCostLimit. Es gibt keine Möglichkeit ein Limit zu löschen und per Default würde <0ct geladen.

[naltatis]

Das Problem hat smartCostLimit ja in der aktuellen api auch schon. 0 bedeutet "aus". Negative Werte sind erlaubt und auch gewünscht. SmartCostLimit würd ich in config ui auch nicht anzeigen. Der ist in den Einstellungen im Main ui gut aufgehoben (Visualisierung und so) und ich würde, wo immer möglich und sinnvoll, nicht mehrere Wege für die gleiche Einstellung anbieten.

[andig]

@naltatis soc ist auch drin. Du müsstest rebasen ;)

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

[naltatis]

@andig Ich hab jetzt die UI für das Hinzufügen und Entfernen von Ladepunkten hinzugefügt. Die entsprechenden Endpunkte (POST, DELETE) habe ich beispielhaft angelegt.

[naltatis]

Anlegen schlägt fehl:

curl 'http://localhost:7070/api/config/loadpoints' \
-X 'POST' \
--data-binary '{"title":"a","phases":0,"minCurrent":6,"maxCurrent":16,"priority":1,"mode":"","thresholds":{"enable":{"delay":2,"threshold":4},"disable":{"delay":3,"threshold":5}},"soc":{"poll":{"mode":"pollconnected","interval":7},"estimate":true},"defaultVehicle":"vehicle_5","charger":"db:38","meter":""}'

{
    "error": "decoding failed due to the following error(s):\n\n'' has invalid keys: defaultVehicle"
}

[andig]

@naltatis das defaultVehicle muss hier vehicle heissen, analog:

	CircuitRef string `mapstructure:"circuit"` // Circuit reference
	ChargerRef string `mapstructure:"charger"` // Charger reference
	VehicleRef string `mapstructure:"vehicle"` // Vehicle reference
	MeterRef   string `mapstructure:"meter"`   // Charge meter reference

[naltatis]

@andig magst du dir hier mal die Lint/Test Fehler anschauen, dass wir den Branch wie der Grün bekommen. Circuit Umbau

[naltatis]

Wir haben hier noch ein Datenproblem. Im UI kann der Nutzer zwischen auto/1p/3p auswählen. Die Auto-Option (0) funktioniert aber nur, wenn der initialisierte Charger am Ladepunkt auch 1p3p Capability hat. Sonst schlägt das Speichern fehl. Aktuell hat die UI keinen Weg das rauszufinden. Hier brauchen wir eine Lösung.

Als schnelle Lösung würde ich vorschlagen, dass wir SetPhases so anpassen, dass die Werte 0,1,3 immer akzeptiert werden.

Langfristig müssen wir hier a) die Info ans UI transportieren damit auch die Auto-Option nur angeboten wird, wenns möglich ist und b) auch bei Szenarien wie "Charger ändern am LP ändern" sicher stellen, dass wir dieses Setting dann entsprechend mit korrigieren.