Batteries: refactor api appearance (BC)

[andig]

TODO

• [x] fix UI @naltatis @Maschga
• [ ] structure: decide totals sub key
• [ ] add remaining settings (mode etc)
• [x] verify influx publishing @MartinRinas
• [x] verify mqtt publishing
• [ ] decide name/title handling to avoid empty @naltatis
• [ ] mqtt: fix excessdc published on battery @andig
• [ ] mqtt: decide squashing devices
• [ ] verify push messaging
• [x] heads-up to integrators @marq24

[andig]

@MartinRinas could I kindly ask you to check what impact this PR has on Influx publishing? I've added the ability to set a preferred influx tag, this should hopefully keep the influx keys stable.

[andig]

Influx should remain stable, for mqtt I'm not entirely happy with the result:

battery/power 1000
battery/soc 98

battery 1 // this is the length of the devices slice
battery/1/power 1000
battery/1/soc 98

I'm not sure we should really squash the devices slices instead of giving it a separate sub-slice? Or do we want to publish any of this as json instead of individual topics?

[Maschga]

I would like to fix UI, but it seems that the new BatteryState has not yet been applied to Websocket or Json API. Or am I missing something?

[andig]

I would expect it to be published as /battery?

[andig]

fixed, aber jetzt!

[Maschga]

Wenn keine Batterie konfiguriert ist, taucht im /api/state ein battery: [] auf. Das ist jetzt nicht mehr sehr passend (es ist ja eig. ein Objekt und kein Array) und macht die Anpassung des UIs schwieriger. Lässt sich das battery Feld in diesem Fall analog zu z.B. forecast einfach entfernen?

[andig]

Wenn keine Batterie konfiguriert ist, taucht im /api/state ein battery: [] auf.

fixed

[naltatis]

\cc @marq24

[marq24]

Verstehe ich das grob richtig, ~~dass das jetzt in dem existierenden battery Objekt noch ein devices Array gibt... das battery object an sich bleibt (ist die Summe aller konfigurierten Batteries) und eben unter devices findet man dann eben für die einzelnen Batterien die genauen Daten - bei "nur" einer konfigurierten Batterie ändert sich nix (außer eben dass es noch eben ein Eintrag im neuen devices Object gibt? [bin gerade ein wenig eingeschränkt, sitze im Auto auf der Rückbank während der Ladung]...~~

[marq24]

ALT:

    "battery": [
      {
        "power": -81.94,
        "soc": 68.69,
        "capacity": 7.5,
        "controllable": false
      }
    ],
    "batteryPower": -81.94,
    "batteryCapacity": 7.5,
    "batterySoc": 68.69,
    "batteryEnergy": 0,
    "batteryDischargeControl": false,
    "batteryMode": "unknown",

NEU:

    "battery": {
      "power": -81.94,
      "capacity": 7.5,
      "soc": 68.69,
      "energy": 0,
      "devices": [
        {
          "power": -81.94,
          "soc": 68.69,
          "capacity": 7.5,
          "controllable": false
        }
      ]
    },
    "batteryDischargeControl": false,
    "batteryMode": "unknown",

also battery ist nun mehr oder minder devices - dafür hat aber eben die neue battery die values, die vorher direct im site Objekt standen...

Und das ist dann ab welcher evcc Versionsnummer so?

[andig]

also battery ist nun mehr oder minder devices - dafür hat aber eben die neue battery die values, die vorher direct im site Objekt standen...

Jaein. Es gibt totals und individuelle Geräte. Verwendest Du HTTP oder MQTT?

[marq24]

also ich verwende den Websocket... der aber meiner bisherigen Erfahrung analog zum HTTP state Endpoint funktioniert...

Wenn die Integration Werte schreibt dann über die HTTP REST API

[marq24]

Also ich habe jetzt "beides" implementiert (aber noch nicht released)...

Also die Integration kommt mit beiden JSON Formaten klar... ich fasse das nochmal zusammen (um sicher zu gehen, dass ich es richtig verstanden habe):

also die Änderungen sind:

• battery ist jetzt ein Objekt
• die site Attribute: batteryPower, batteryCapacity, batterySoc und batteryEnergy wandern in das neue battery object (dann natürlich ohne den Prefix battery)
• das alte battery Array ist jetzt unter dem Namen devices ebenso im battery Objekt

wenn das oben genannte so stimmt, habe ich noch die Frage, warum der batteryMode und auch batteryDischargeControl nicht ebenso in das neue battery Objekt gewandert sind? Ein Unterschied ist ja wohl, das diese beiden Werte Switches/Controls sind - und der Rest "nur" Anzeigewerte...

Und ich wiederhole meine Frage, in welchem Release (Versionsnummer) wohl diese Änderung live geht?

[andig]

Es ist einfach noch nicht fertig…

[marq24]

Es ist einfach noch nicht fertig…

:-) na dann lass ich es noch eine Weile liegen

[naltatis]

@Maschga ui change looks good 🎊. I only introduced a couple of computeds to eliminate redundant checks.

[naltatis]

@andig what do you mean with structure: decide totals sub key?

Moving battery.[soc,power,capacity] to battery.totals.[soc,power,capacity]? I'd see why this would make sense symmetry-wise, but I'd keep this structure as-is right now.

[naltatis]

decide name/title handling to avoid empty

@andig You mean adding a name field to the Measurement entry? If this is technically possible we should add it and use it as a title-fallback in UI. Currently we use a static text "Battery #_". Having the name would be better. But we can also move this discussion to a dedicated PR since it also affects pv,ext,aux.