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.

[volkerrichert]

@torbennehmer There are systems with multiple batteries. My new S10E Pro has two modul packs

get _batteries returns two elements in the array. one with 5 dcbs ans one with 3. There is also a second enclosure connected to the main unit

[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)

[FloX5E70]

Thank you Torben for this great integration. I would very much like to have all the parameters as an entity in HA. entities can be hidden, if you dont use them. For example, I recommend to monitor the cell voltages of lithium polymer batteries as a sensible, safety-relevant function. Currently I have realized that I have the data from the IoBroker adapter sent to me via MQTT in HA, but this is not a clean solution.

[bs0001]

it will be fine and very useful to read those values directly via this hacs integration from Torben!

[bullitt186]

I created a branch for adding detailed battery info here: https://github.com/bullitt186/hacs-e3dc/tree/detailed_battery_infos, still work in progress, but it works and now it's only a matter of tidying it up and making it robust.

The idea is to have an options dialog to add battery devices as well as further diagnostic entities under the hauskraftwerk:

Exposing all information provided via RSCP seems overkill but i am not the best to judge what's relevant. Below's a list of all exposed information (at least on my S10X compact), should all of these info be exposed? What are your thoughts?

Level	Attribute	Description	Example Value (Unit)
Pack	asoc	Absolute State of Charge — charge level relative to original capacity	83 (%)
Pack	chargeCycles	Total number of full charge–discharge cycles of the entire pack	709 (cycles)
Pack	current	Instantaneous battery pack current (negative = discharging)	−0.033 (A)
Pack	dcbCount	Number of battery modules (DCBs) connected in the system	4 (count)
Pack	designCapacity	Original total pack design capacity	33.25 (Ah)
Pack	deviceConnected	Indicates if pack communication is active	True (boolean)
Pack	deviceInService	Service mode flag (maintenance)	False (boolean)
Pack	deviceName	Identifier of the battery controller	AtlSerialBattery1006_0_0
Pack	deviceWorking	Operational status of the pack	True (boolean)
Pack	eodVoltage	End-of-discharge voltage threshold	336 (V)
Pack	errorCode	Pack-level error or fault code	0
Pack	fcc	Full-charge capacity (currently achievable total)	25.10 (Ah)
Pack	index	Internal pack index (multi-pack systems)	0
Pack	maxBatVoltage	Maximum allowed pack voltage	432 (V)
Pack	maxChargeCurrent	Maximum allowed charge current	32 (A)
Pack	maxDischargeCurrent	Maximum allowed discharge current	32 (A)
Pack	maxDcbCellTemp	Highest cell temperature measured among all DCBs	28.7 (°C)
Pack	minDcbCellTemp	Lowest cell temperature measured among all DCBs	24.6 (°C)
Pack	moduleVoltage	Average pack voltage across all DCBs	394.2 (V)
Pack	rc	Remaining capacity of the pack	11.1 (Ah)
Pack	readyForShutdown	Indicates pack is in safe state for power-off	True (boolean)
Pack	rsoc	Relative State of Charge — based on current usable capacity	38.47 (%)
Pack	rsocReal	Raw or unfiltered SoC value	44.0 (%)
Pack	statusCode	Combined status bitfield of pack state	33554435
Pack	terminalVoltage	Output voltage at pack terminals	394.2 (V)
Pack	totalUseTime	Accumulated runtime since commissioning	0 (h)
Pack	totalDischargeTime	Total time spent discharging	0 (h)
Pack	trainingMode	Calibration/training flag of the BMS	0
Pack	usuableCapacity	Calculated total usable energy capacity	22.76 (Ah ≈ energy equivalent)
Pack	usuableRemainingCapacity	Currently available usable energy	8.75 (Ah ≈ energy equivalent)
Module (DCB)	current	Module current (may mirror pack current)	−0.033 (A)
Module (DCB)	currentAvg30s	30-second averaged module current	−0.033 (A)
Module (DCB)	cycleCount	Individual module cycle count	None
Module (DCB)	designCapacity	Nominal module capacity	33.25 (Ah)
Module (DCB)	designVoltage	Nominal design voltage per module	96 (V)
Module (DCB)	deviceName	Module identifier	TODO
Module (DCB)	endOfDischarge	Voltage threshold for end-of-discharge per module	84 (V)
Module (DCB)	error	Error flag of module	0
Module (DCB)	fullChargeCapacity	Current maximum storable capacity of module	25.10 (Ah)
Module (DCB)	fwVersion	Firmware version of DCB controller	101
Module (DCB)	manufactureDate	Manufacturing date (YYMMDD)	230113
Module (DCB)	manufactureName	Manufacturer name	TODO
Module (DCB)	maxChargeCurrent	Max allowed module charge current	32 (A)
Module (DCB)	maxChargeTemperature	Maximum permissible charge temperature	55 (°C)
Module (DCB)	maxChargeVoltage	Maximum permissible charge voltage	108 (V)
Module (DCB)	maxDischargeCurrent	Maximum permissible discharge current	32 (A)
Module (DCB)	minChargeTemperature	Minimum permissible charge temperature	−10 (°C)
Module (DCB)	parallelCellCount	Number of parallel cells within module	30
Module (DCB)	sensorCount	Number of sensors in module	35
Module (DCB)	seriesCellCount	Number of cells in series	0
Module (DCB)	pcbVersion	PCB hardware version	202
Module (DCB)	protocolVersion	Communication protocol version	106
Module (DCB)	remainingCapacity	Current remaining energy in the module	11.10 (Ah)
Module (DCB)	serialCode	Module serial code	TODO
Module (DCB)	serialNo	Module serial number	229
Module (DCB)	soc	State of Charge (module-level)	None
Module (DCB)	soh	State of Health (module-level)	None
Module (DCB)	status	Module status flag	48
Module (DCB)	temperatures	List of temperature sensor readings	[25.7, 28.6, 28.7, 26.6, 27.4] (°C)
Module (DCB)	voltage	Module voltage	98.6 (V)
Module (DCB)	voltageAvg30s	30-second averaged module voltage	98.6 (V)
Module (DCB)	voltages	List of individual cell voltages	[3.288, 3.289, …] (V)
Module (DCB)	warning	Warning flag	0

[bs0001]

great! I will try it in upcoming days/weeks. Currently unfortunately my time is much limited.
Also topics regarding controlling of the Hauskraftwerk would be fine, e.g.

• Switching mode Battery or Car first
• Switch between sun and mixed mode
• Switch to manual charge/discharge as well as to define the W or kW of charge/discharge the battery
• Weather forecast valiues - amount of appreciated kWh for the day (with Grafana it's possible later to compare the values easily how good or bad are the values from E3DC)
• Wallbox start manual charge of a defined amount of kWh into the car (time defined is I think not needed, this triggering can be done to a wished time directly out of HA, e.g. in a phase with less energy prices, if dynamic prices are being used)

Only some ideas. Take it in the backlog if you like such ideas.

BR
Bernd

[bullitt186]

I just filed PR #267.
As I could only verify it's function on my S10X Compact and the change is rather big in size, i understand that it's integration may take quite some time...

[finroba]

Hi, I just found this while looking for a way to display the SoH of my E3DC system. I have v 3.10 installed via HACS (and successfully running) but I seem to be too stupid to find a way to add the battery information to my configuration. Isn't this implemented yet? The readme explains it already...

[bullitt186]

The necessary change is in the code in this repository but there hasn't been a release for general availability via HACS yet.
For testing purposes, you could install in HACS the currently available version 3.10, download this repo as ZIP and overwrite the files on your HA installation under /config/custom_components/e3dc_rscp/

Disclaimer: As this means using a development snapshots, there may be bugs/issues

[torbennehmer]

I just released 3.11 Beta 1 which contains these changes, it can be installed via HACS if you allow prerelease installations.
Happy testing!
https://github.com/torbennehmer/hacs-e3dc/releases/tag/v3.11.0-beta.1

[finroba]

I just released 3.11 Beta 1 which contains these changes, it can be installed via HACS if you allow prerelease installations. Happy testing! https://github.com/torbennehmer/hacs-e3dc/releases/tag/v3.11.0-beta.1

Thank you! Just loaded it and configured the batteries to appear.
My initial impression is that the system / pack SoH is about right but that the calculation of the SoH of the individual batteries is way off. If I show the full charge capacity (e.g. 55) and divide it by the design capacity (64), I should get the correct SoH value (85,9%), shouldn't I? If so, the calculated SoH is off by 5-10%.

Or do I have a flaw in my thinking?

[bullitt186]

I doublechecked the code; see the excerpts below.
I think your percentages of 93/94% come from Hauskraftwerk directly - if the data contains a non-None-Value this is being used instead of the calculated one. My S10X Compact did not return an SoC.
In order to narrow your setup down:

• What model do you have?
• Do you only have two battery Modules? because the Pack SoH is also off - with the provided sensor values it should be 86,01% ((55,10/64,0 + 55,0/64,0)/2*100) but not 86,9%

    def _process_battery_sensor_value(self, data_key: str, value: Any, dcb: dict[str, Any]) -> Any:
(...)
        if data_key == "soh" and value is None:
            return self._calculate_battery_soh_from_capacity(dcb)
(...)
        return value

and

    def _calculate_battery_soh_from_capacity(self, dcb: dict[str, Any]) -> float | None:
(...)
        return (full_charge_capacity / design_capacity) * 100

ps 1 - I just realized that my documentation in the README.md does not state that - if available - the SoH coming from the device is being used, this needs to be updated for sure...

ps 2 - Maybe we need to add a debug sensor indicating whether SoH coming from the device or the calculated one is being used.

[finroba]

Good morning,

I own an S10E with 6 batteries and a resulting gross capacity of 384Ah / 19,5kWh. The screenshot showed only 2 modules but if do the math with all 6 batteries, the battery pack SoH matches perfectly with the one the integration provides.
This indicates that it gets calculated the same way, i.e. that Hauskraftwerk doesn't provide the SoH by itself. Right?

The other question then is: why would E3DC try to tell us that the SoH of each battery is significantly higher than it is?

[bullitt186]

Hi @finroba,

I've implemented a fix that addresses the SoH calculation discrepancy in PR #294

Changes made:

1. Battery module SoH is now always calculated using the formula (full charge capacity / design capacity) × 100 - the same way you calculated it manually

2. The device-reported SoH (which was showing the incorrect values) is now available as a separate diagnostic sensor called "State of health (device-reported)", disabled by default

3. This additional sensor is only created if your E3DC system actually provides a SoH value for that module

This ensures consistent and accurate SoH values across all E3DC systems, while still making the device-reported values available for debugging if needed.

Regarding your question about why E3DC reports higher SoH values: honestly, I can only speculate since we don't have access to their proprietary algorithms. They might be using more sophisticated degradation models that factor in temperature compensation, charge cycles, or internal resistance measurements. It's also possible they're applying correction factors or using different reference points than the simple capacity-based calculation.