Batteries: refactor api appearance (BC)

[andig]

TODO

• fix UI @naltatis @Maschga
• structure: decide totals sub key
• add remaining settings (mode etc)
• verify influx publishing @MartinRinas
• 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
• heads-up to integrators @marq24

[sourcery-ai]

Hey there - I've reviewed your changes - here's some feedback:

• Publishing only the raw measurements slice under keys.Battery means power, soc, capacity, and energy aren’t included; consider publishing the full site.battery struct instead.
• Make sure to update downstream MQTT/Influx publishers and the UI to consume the new batteryState JSON structure rather than individual battery metric keys.
• Since the individual battery metric keys were removed, document or version this breaking change so existing integrations aren’t silently broken.

Prompt for AI Agents

Please address the comments from this code review:

## Overall Comments
- Publishing only the raw measurements slice under keys.Battery means power, soc, capacity, and energy aren’t included; consider publishing the full site.battery struct instead.
- Make sure to update downstream MQTT/Influx publishers and the UI to consume the new batteryState JSON structure rather than individual battery metric keys.
- Since the individual battery metric keys were removed, document or version this breaking change so existing integrations aren’t silently broken.

---

Sourcery is free for open source - if you like our reviews please consider sharing them ✨

• X
• Mastodon
• LinkedIn
• Facebook

_{Help me be more useful! Please click 👍 or 👎 on each comment and I'll use the feedback to improve your reviews.}

[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