FeatureRequest/API: liste aller loadpoints / loadpoint-id

[OneLineTwoBugs]

Ein GET-Request auf /api/state gibt uns u.A. eine liste aller loadpoints. Um dann via API mit einem loadpoint zu interagieren, ist die loadpoint-id nötig. Diese ist aber im /api/state JSON nicht enthalten.

Ich vermute dass die loadpoint-id die Position im JSON-Array + 1 ist, wobei ich in der Doku nicht gefunden habe, dass das garantiert wäre. Es ist aus Sicht der Doku nicht einmal klar, ob die loadpoint-id über restarts von evcc konsistent ist.

Aus meiner Sicht wäre das schönste, die loadpoints-objects von /api/state zusäztlich noch die loadpoint-id drinnen hätten.

Alternativ müsste man prüfen und dann dokumentieren, dass die loadpoint-id

1. direkt abhängt von der Reihenfolge, wie der loadpoint in der evcc.yaml steht,
2. die evcc.yaml-Reihenfolge mit der /api/state-Reihenfolge übereinstimmt und
3. die loadpoints-id aus dem JSON von /api/state abgeleitet werden kann, da loadpoint id = array-index + 1

Auch wäre überlegenswert, ob man nicht auch einen endpoint GET /api/loadpoints machen möchte, der eine Liste an loadpoints (inkl. der id) zurückgibt. Das ist aber aus meiner sicht sekundär, da diese Liste via /api/state verfügbar ist.

[premultiply]

Es leitet sich alles aus der Reihenfolge in der Konfiguration ab.

[naltatis]

Ja, es ist genau so wie du schreibst. Aktuell ist die Loadpoint-ID der Index (1-basiert) in der Liste der Loadpoints. Das ist so auch stabil.

Wir sind gerade dabei Stück für Stück auf DB-basierte Konfiguration umzustellen. Dadurch bekommen die Entities auch eineindeutige IDs die unabhängig von einer Reihenfolge bestehen bleiben. Für Fahrzeuge ist das hier bereits der Fall #6199

Nach dem gleichen Muster werden wir das auch für Loadpoints umsetzen. Um Verwirrung zu vermeiden würde ich davon absehen dem Loadpoint für den Übergang ein id Feld zu verpassen was inhaltlich lediglich ein Index (aus yaml abgeleitet) ist.

Ich hab den Punkt aber mal in den Epic #6029 übertragen.

[michiproep]

Hallo zusammen. Darf ich hier nochmal einhaken?
Grundsätzlich habt ihr schon recht, dass das mit der Reihenfolge im Yaml stabil ist.
Das Problem ist nur, wenn man schon ein paar Loadpoints hat und viele Dinge via API steuert und im Nachhinein ein neuer Loadpoint dazu kommt, den man in der UI ggf. ganz vorne haben möchte, dann passt natürlich nichts mehr zusammen.
Ich denke, der einfachste Weg wäre einen "UI-Index" einzuführen. Somit könnte die Steuerung von Berechnung weiterhin auf dem "yaml-index" basieren, aber es ließen sich die Loadpoints in der UI neu anordnen.
Wenn der UI-Index dann noch per API gesteuert werden kann, dann kann jeder nach seiner eigenen Logik die Kacheln hin und herschieben wie er will.
Wäre das machbar?

[OneLineTwoBugs]

ich interagiere mittlerweile via script produktiv mit evcc und habe das Mapping-Problem über den title vom Loadpoint gelöst. Das heisst, dass der title eigentlich meine unique id geworden ist - muss ich halt selber im Griff behalten, aber das kann ich immerhin.

Also, ich merke mir "ich will den loadpoint mit title 'pp20' konfigurieren".

1. result = GET /api/state
2. im result-array loope ich über $.result.loadpoints und suche den loadpoint wo title = 'pp20' ist
3. nun habe ich den index, den ich via API (index+1) konfigurieren kann

Diese Methode belastet die API zusätzlich, weil ich dauernd zuerst GET /api/state machen muss, dafür darf ich in der evcc config loadpoint-Reihenfolge ändern.

In meinem Fall flippe ich den Lademodus je nach Tarif des Netzbetreibers. Bei günstigen Tarifen schalte ich auf now (/api/loadpoints/index+1/mode/now), bei hohen Tarifen auf pv (/api/loadpoints/index+1/mode/pv).

Last but not least kann der VNB mich auch auffordern, alles Laden sofort einzustellen. In dem Fall setze ich alle loadpoints auf off.

[naltatis]

Mit den Arbeiten an der Config UI wird es diesen Endpoint bald geben. Für meter und vehicle gibts das heute bereits.