Wrong battery SoC in dual battery tower topology

[mlukasek]

Version of the custom_component

0.13.1

Configuration

Power Storage DC 10.0
two battery towers 11,5 kWh each, total 23 kWh

Describe the bug

Recently new firmware in PS DC 10.0 allows connecting and using 2 battery towers together. Everyhting seems to work OK, but SoC is reported wrong in low values. 7% of SoC is reported as 14% by home assistant component. The upper values are OK as 97% is reported as 97%. There was the same bug in RCT power portal until recent update 1.4.5, which corrects this. The Android application reports SoC correctly.

Logs

There seems to be nothing interesting in the logs for this issue.

[weltenwort]

Thanks for reporting this. Seems like RCT again tries to fix the inconsistencies in their API with client-side mitigations. Any idea how we might do that? I don't have two towers available for testing, unfortunately.

If anyone feels able to provide a packet capture of the communication between app and inverter or portal and inverter I might be able to find a hint there.

[HWE70]

Hi, this is not a bug. In the RCT registry there are distinct OIDs per tower for most battery values. For the first tower/battery they always started with a leading battery. while for second battery they start with battery_placeholder[0]. As the HA plugin today just polls the values for the first battery, simply these values are shown in HA, while the values for the second battery are missing (by the way the inverter decides more or less randomly at startup, which tower is the first one, and which is the second, at least it may change when applying a new firmware, that's what I figured out so far)

Above applies to all other values where dedicated measurements are available as of rctclient.registry.py:

    key="battery_placeholder[0].bms_sn",
    key="battery_placeholder[0].bms_software_version",
    key="battery_placeholder[0].module_sn[0]",
    key="battery_placeholder[0].module_sn[1]",
    key="battery_placeholder[0].module_sn[2]",
    key="battery_placeholder[0].module_sn[3]",
    key="battery_placeholder[0].module_sn[4]",
    key="battery_placeholder[0].module_sn[5]",
    key="battery_placeholder[0].current",
    key="battery_placeholder[0].voltage",
    key="battery_placeholder[0].maximum_charge_voltage",
    key="battery_placeholder[0].minimum_discharge_voltage",
    key="battery_placeholder[0].maximum_discharge_current",
    key="battery_placeholder[0].temperature",
    key="battery_placeholder[0].ah_capacity",
    key="battery_placeholder[0].soc",
    key="battery_placeholder[0].soh",
    key="battery_placeholder[0].status2",                            

I added them all to my entities.py (see attachment, based on version 0.14.1) and now have all values available for the second battery as well. I also added battery.status2 for the first battery as this OID is much more helpful than battery.status. And it is separated by battery and not just global like the standard one. I am not sure, how the inverter reacts when battery_placeholder[0]. OIDs are queried without a second battery in place (did not test, because I have a second tower for quite a while now). But as the OIDs are in the registry for at least three years, it should not make a difference, even when running an older firmware (just a few unneeded polls). If needed, polling of the additional OIDs could be skipped, if power_mng.n_batteries is not 2. But this would need additional coding in the plugin.

Of course, if one likes to see the overall SOC, this needs to be calculated using a helper (SOC1 + SOC2)/2 (or the plugin could do ;-)). However, the inverter does not care about the overall SOC at all. It simply stops charging as soon as one of the batteries reaches SOCmax and its stops discharging as soon as the one of the batteries reaches SOCmin. This unfortunately also applies for calibration, meaning that generally a least one battery never gets properly calibrated, and capacity is wasted. SOC differences of 10% - 20% are not uncommon. So huge amounts of capacity might be wasted :-|

It would be great, if the plugin could be extended officially to support the second tower/battery ;-) To map status2 to a human understandable output the following investigation might be helpful: svalouch/python-rctclient#39 . So far I personally have seen:

2048 = balancing required/pending
2304 = balancing required and in progress (SOC target = 100%)

Here a small example, how the battery SOCs differ about one day. Even though the discharge was quite small, the SOC already differs more than 16% at max:

The calculation of the overall SOC in the RCT app seems to be more than a simple average. For example jumps the overall SOC to 99.9% if the first tower reaches 99.9%, regardless of the SOC of the other tower. The concrete formula would be interesting. However, I just use a simple average in Ha so far.

entities_py.txt