How to handle battery specific metrics

[torbennehmer]

Based on current issues, especially #202 and #203 (@volkerrichert, @jh537), i'd like some opinions:

I have not yet introduced any battery-specific metrics yet. Main reason is, that the E3DCs usually have no single battery, but a collection of blocks. My 8 yr old 4,5 kWh battery actually consists of two modules, for example. Consider this data from my unit:

      "get_batteries_data": [
      {
        "asoc": 73.0,
        "chargeCycles": 2250,
        "current": -0.0,
        "dcbCount": 2,
        "dcbs": {
          "0": {
            "current": -0.0,
            "currentAvg30s": -0.0,
            "cycleCount": 2250,
            "designCapacity": 47.279998779296875,
            "designVoltage": 52.0,
            "deviceName": "DCB102ZK",
            "endOfDischarge": 39.0,
            "error": 0,
            "fullChargeCapacity": 34.2140007019043,
            "fwVersion": 2,
            "manufactureDate": 7931,
            "manufactureName": "Panasonic",
            "maxChargeCurrent": 20.0,
            "maxChargeTemperature": 40.0,
            "maxChargeVoltage": 52.0,
            "maxDischargeCurrent": 25.0,
            "minChargeTemperature": 5.0,
            "parallelCellCount": 24,
            "sensorCount": 6,
            "seriesCellCount": 13,
            "pcbVersion": 1,
            "protocolVersion": 5,
            "remainingCapacity": 2.7260000705718994,
            "serialCode": "157<redacted>",
            "serialNo": 3,
            "soc": 7.5,
            "soh": 72.0,
            "status": 0,
            "temperatures": [
              29.700000762939453,
              28.899999618530273,
              28.700000762939453,
              28.0,
              28.0,
              28.600000381469727
            ],
            "voltage": 45.529998779296875,
            "voltageAvg30s": 45.529998779296875,
            "voltages": [
              3.496999979019165,
              3.496999979019165,
              3.496999979019165,
              3.49399995803833,
              3.496999979019165,
              3.496999979019165,
              3.486999988555908,
              3.49399995803833,
              3.49399995803833,
              3.496999979019165,
              3.496999979019165,
              3.496999979019165,
              3.496999979019165
            ],
            "warning": 0
          },
          "1": {
            "current": -0.0,
            "currentAvg30s": -0.0,
            "cycleCount": 2241,
            "designCapacity": 47.279998779296875,
            "designVoltage": 52.0,
            "deviceName": "DCB102ZK",
            "endOfDischarge": 39.0,
            "error": 0,
            "fullChargeCapacity": 34.99599838256836,
            "fwVersion": 2,
            "manufactureDate": 7931,
            "manufactureName": "Panasonic",
            "maxChargeCurrent": 20.0,
            "maxChargeTemperature": 40.0,
            "maxChargeVoltage": 52.0,
            "maxDischargeCurrent": 25.0,
            "minChargeTemperature": 5.0,
            "parallelCellCount": 24,
            "sensorCount": 6,
            "seriesCellCount": 13,
            "pcbVersion": 1,
            "protocolVersion": 5,
            "remainingCapacity": 2.7839999198913574,
            "serialCode": "157<redacted>",
            "serialNo": 6,
            "soc": 7.5,
            "soh": 74.0,
            "status": 0,
            "temperatures": [
              25.799999237060547,
              26.600000381469727,
              26.399999618530273,
              27.200000762939453,
              26.700000762939453,
              26.5
            ],
            "voltage": 45.63999938964844,
            "voltageAvg30s": 45.637779235839844,
            "voltages": [
              3.499000072479248,
              3.496999979019165,
              3.496999979019165,
              3.496999979019165,
              3.4670000076293945,
              3.496999979019165,
              3.496999979019165,
              3.496999979019165,
              3.496999979019165,
              3.496999979019165,
              3.496999979019165,
              3.496999979019165,
              3.496999979019165
            ],
            "warning": 0
          }
        },
        "designCapacity": 94.4000015258789,
        "deviceConnected": true,
        "deviceInService": false,
        "deviceName": "LJ-EBPM02A",
        "deviceWorking": true,
        "eodVoltage": 39.0,
        "errorCode": 1,
        "fcc": 69.19999694824219,
        "index": 0,
        "maxBatVoltage": 52.0,
        "maxChargeCurrent": 33.0,
        "maxDischargeCurrent": 30.0,
        "maxDcbCellTemp": 29.600000381469727,
        "minDcbCellTemp": 25.799999237060547,
        "moduleVoltage": 45.52000045776367,
        "rc": 5.5,
        "readyForShutdown": true,
        "rsoc": 0.0,
        "rsocReal": 7.5,
        "statusCode": 704,
        "terminalVoltage": 0.0,
        "totalUseTime": 0,
        "totalDischargeTime": 0,
        "trainingMode": 0,
        "usuableCapacity": 63.802398681640625,
        "usuableRemainingCapacity": 0.10240030288696289
      }

A lot of data in here, and much of it is specific to the individual modules. The SOH for example also differs by 2%, the cycle count isn't the same as well.

What would be your (as "the userbase") expected behavior?

1. Do you want a central sensor, that for example averages the existing values
2. Do you want a device per DCB, with all sensors in question
3. Maybe a combination?

Feedback's welcome, as I don't want to change the behavior later on, introducing stale or renamed sensors etc.

Cheers, Torben

Cc: @bullitt186

[jh537]

Hi,
I would be very happy about variants 1 and 2.

[bullitt186]

I am torn between these two ways:

• Have no additional devices but have per Battery Module an Entity with SOH as it's value and adding additional health-related values as attributes to the Entity (Cycle Count, Serial No, ...)
  Pros: Not too many new entities, which are used only by the minority of users
  Cons: Some info "hidden" in attributes only accessible to pro users

• Have the battery modules as devices but have in the configuration dialog a checkbox, unchecked by default, "add batteries as entities (advanced)". These Devices could bundle all kinds of info from get_batteries_data, not overloading the hauskraftwerk entity
  Pros: Easily accessible, no crowding of hauskraftwerk, logical grouping of entities.
  Cons: a) Technically, Batteries are part of the Hauskraftwerk, now these parts on the same hierarchical level as the parent device, this is illogical. b) The Services for manual charging / discharge control ask for selecting a E3DC device. We have already today the situation, that you can select a wallbox for these services which does not make sense. With adding more E3DC Devices which are not meant to work with these services, the confusion increases, meaning ideally the services would need refactoring = breaking change.

I tend to favour the device-based solution, as i hate long entity lists for my devices :-)

[jh537]

In my view, this can be kept simple. I only want to use the values for occasional readings. The SOH only changes once a year when there is 1% less capacity and surely you can't use the charge cycles in calculations? As I said, I only want to use the sensors for reading, because I have no other way of accessing the values except via other software.

[volkerrichert]

I would prefer the first way. Having the values as attributes, maybe with a flag to enable it. I think having it for "pro users" is fine, because it't some special data and you should know what to do with kind of detailed information

[torbennehmer]

@jh537 For stuff like SOH, i fully agree. If you want to watch other battery specific metric like temperatures or voltages, things might be different.

@bullitt186 I see the problem with device selection, though I think the selectors can be adjusted accordingly. IIRC we should be able to at filters and stuff there.

I think I need to build some S10 sample configurations repository... I've seen so many different units out there in the past, that it is actually hard to decide what to do.

Does anyone here know if there are S10 units out there with more than one battery? Not a battery with multiple modules/DCBs like mine, but actual different batteries? Does S10 even support this on a single unit?

To be sure: I'm not talking about two distinct E3DCs with one battery each, but a single S10 with 2+ reported batteries, having 1+ DCBs each in turn.

[volkerrichert]

do you mean something like SE? https://www.e3dc.com/en/wp-content/uploads/sites/3/2022/06/E3DC_TD_SE-series.pdf? I don't know, if they count it as "modules" internally. But I would expect that this is like a normal S10 with even more moduls.

[diver-ch]

@torbennehmer Thanks for all your work, I really appreciate the time and effort as its such a stable running integration.

As for the modules, there's lots of systems with f.e. 7 or more modules, via RSCPGUI shown as "DCB #0" to "DCB #6". The whole battery is named "BAT #0" (S10X System)