API change

[andig]

With #5497 and #5507 we have changed the api structure:

• all indexes become 1-based (instead of 0-based for REST and 1-based for MQTT)
• SoC becomes Soc

This change improves consistency and matches index numbers with log output. It is currently active as of 0.111.0

[thebrainkafka]

Hi.
This means config yaml needs to be adapted by the user (rename every SoC to Soc)?
Thanks

[andig]

Good question- no! Only API users need to update, yaml is case insensitive.

[Olf1337]

Yaml is case sensitive:

https://learn.getgrav.org/16/advanced/yaml

[andig]

Yeah, should have said "the yaml". Mapping to Go structures is not ;)

[thebrainkafka]

Ok.
In der example
https://github.com/evcc-io/evcc/blob/master/evcc.dist.yaml
ist nun auch SoC zu Soc geändert.

Heißt nun doch uf die neue Nomenklatur updaten in der eigenen yaml?

[andig]

Die Antwort steht 3 Fragen weiter oben: #5522 (reply in thread)

yaml is case insensitive.

[emcepe]

Hallo @andig,

darf ich fragen warum SoC nach Soc umbenannt wurde?

Ich bin gerade ziemlich verwirrt mit den verschiedenen Schreibweisen.

Das hier hatte ich an Soc-Krams bis v0.110.1 via MQTT drin:

$DEVICETOPIC/site/batterySoC:.* batterySoC
$DEVICETOPIC/site/bufferSoC:.* bufferSoC
$DEVICETOPIC/site/prioritySoC:.* prioritySoC
$DEVICETOPIC/loadpoints/1/minSoC:.* loadpoints_1_minSoC
$DEVICETOPIC/loadpoints/1/socCharge:.* loadpoints_1_socCharge
$DEVICETOPIC/loadpoints/1/targetSoC:.* loadpoints_1_targetSoC
$DEVICETOPIC/loadpoints/1/vehicleSoC:.* loadpoints_1_vehicleSoC
$DEVICETOPIC/loadpoints/1/vehicleSoc:.* loadpoints_1_vehicleSoc
$DEVICETOPIC/loadpoints/1/vehicleTargetSoC:.* loadpoints_1_vehicleTargetSoC

und seit v0.111.0 kam das unter anderem nun hinzu:

evcc/site/socCharge:.* socCharge
evcc/site/vehicleSoC:.* vehicleSoC
evcc/site/minSoC:.* minSoC
evcc/site/bufferSoc:.* bufferSoc
evcc/site/prioritySoc:.* prioritySoc
evcc/site/batterySoc:.* batterySoc
evcc/site/battery/1/soc:.* battery_1_soc
evcc/loadpoints/1/batterySoC:.* loadpoints_1_batterySoC
evcc/loadpoints/1/bufferSoC:.* loadpoints_1_bufferSoC
evcc/loadpoints/1/prioritySoC:.* loadpoints_1_prioritySoC
evcc/loadpoints/1/targetSoc:.* loadpoints_1_targetSoc
evcc/loadpoints/1/minSoc:.* loadpoints_1_minSoc
evcc/loadpoints/1/vehicleTargetSoc:.* loadpoints_1_vehicleTargetSoc

äh?

site/blaSoc vs loadpoints/1/blaSoC

I am confused :)

Ich seh' vor lauter SoCsocSoc den Baum nicht mehr ;)

--
ciao, Marc

[andig]

Ich versteh das ganze :.* nicht. Einige Werte sind auf der Site, andere auf den Loadpoints. Die sind disjunkt und in meinem MQTT ist das auch so. Zwei altre Schreibweisen waren noch nicht aufgeräumt, siehe dazu #5766.

[rediculum]

Diese Umbenennung hat noch Folgen in der InfluxDB! Hier der Command um die Messwerte vom alten Name auf den Neuen zu übertragen:

> use evcc
Using database evcc
> select * into batterySoc from batterySoC group by *
name: result
time written
---- -------
0    1377020
>

[secuder]

Danke!

[at4hawo1]

Und es hat noch Auswirkungen auf das Messaging. Bei mir funktionierte seit V0.111.1 das Messaging teilweise nicht mehr (nach Beenden wurde keine Message geschickt). Ich lasse mir den Vehicle SoC schicken. Nach Umbennung von vehicleSoC in vehicleSoc geht's wieder.

[VolkerK62]

ist in der Doku geändert.
Tipp: Bei Problemen mit Variablen hilft oft ein Blick in /api/state.

[florian-h05]

Hallo @andig,

nachdem das openHAB Binding Probleme gemacht hat bin ich auch auf den Beitrag hier gestoßen, der erklärt einiges.
Kannst du das nächste mal vielleicht versuchen dran zu denken mich bei API Änderungen anzupingen?

Viele Grüße

[mstormi]

Sehe ich das richtig daß unter /api/state die loadpoints weiterhin ab 0 sind ?
Werden die noch geändert ? Das wäre ja sonst nicht gerade konsistent.

[binderth]

Wie Du darauf zugreifst ist Sache Deiner Programmiersprache.

Halt mich für doof, aber es braucht doch eindeutige Hinweise, wie aus dem Lesen-Array (GET /api/state/) die Infos zum Schreiben-Endpunkt (POST xxx/ID/yyy) auf die jeweils aktuelle ID geschlossen werden kann.
Kann sein, dass ich was übersehe, aber bisher erschließt sich mir eben nicht, wie ich in einer komplett externen Programm/Rule/whatever - also ohne Zugriff auf das evcc-core - nur durch Antwort des GET-Arrays die Nummerierung des POST-Endpunkts herauskriegen soll? 🤷‍♂️

[andig]

Das sprengt jetzt endgültig den Scope dieses Threads.

[florian-h05]

Ich muss @andig zustimmen, dass man das Indexing von Arrays nicht beeinflussen kann, dass beginnt nunmal bei 0. Dementsprechend hätte ich persönlich es geschickter gefunden, alle Inidizes auf 0-basiert statt auf 1-basiert umzustellen, aber solange evcc im loadpoints Array in /api/state die Loadpoints in der Reihenfolge Loadpoint 1, Loadpoint 2, etc. zurückgibt muss Mann letztendlich für Befehle nur +1 zum Index im loadpoints Array hinzufügen, dass ist zum Beispiel im openHAB Binding ein Einzeiler.

[binderth]

aber solange evcc im loadpoints Array in /api/state die Loadpoints in der Reihenfolge Loadpoint 1, Loadpoint 2, etc. zurückgibt

ist das wirklich so? Ich hab da stellenweise unterschiedliche Reihenfolgen. Beim vehicle wurde das durch alphabetische Reihenfolge auf zumindest immer dieselbe ID gesetzt. Bei loadpoints oder anderen Indizes bin ich mir net sicher?

[florian-h05]

Ich weiß es nicht, hab nur einen Ladepunkt (bzw. Noch nicht, da NRGkick immer noch nicht die API veröffentlicht hat).
@andig sollte uns das sagen können.

[Marty56]

Was ich noch wünschenswerte fände, wäre eine Dokumentation, was in den Rest API zurückgegeben wird.