@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?

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

↔ wider layout (general)
🏷️ loadpoint status

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?

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.

Ah, ok. Aber erstmal ohne Updatefähigkeit?

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

@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

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.

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.

@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?

improved layout, more fields

real values, badge colors

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?

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.

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

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.

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.

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