Batt Charge Current is lower than CCL

[locke987]

Hi, I'm not sure if this is a bug or just a wrong configured system...here is my systems behaviour: I have 2x 16s Batteries in an Victron 3 pase system with jk BMS, aggregated with the Battery Aggregator Version 3.0.50 on a raspi venus 3.21 with serialbattery driver 1.0.20230904dev. All seems fine with the exception that the charge current, my batteries are charged, is often to low. In the screenshot you can see it in detail. The CCL for the two batteries as well as for the aggregated battery is higher than the charge current. My system therefore feeds into the grid instead of charging the batteries with a higher current. It worked in the past without any issues and started to make problems when you added considering the differences in the resistence of the batteries in your code if I remember correct.

Here is the Log: current.log

After a reboot of venus raspi the system works as expected but later jumps back to the described behaviour. As you can see the harging current is much higher and the export to grid is ~0.

Screenshot after reboot:

Log after clean reboot: current after reboot.log

Thanks for helping Stefan

[pulquero]

I've pushed version 3.0.52 where you can add the setting "currentRatioMethod": "capacity" to your config, e.g. (please ensure your JSON is correct) {"currentRatioMethod": "capacity"} This will use the relative capacities of your batteries to determine the current split between the batteries instead of resistance. This is the same method that is used when resistance is initially unavailable, e.g. after a reboot, as it takes time to build up enough measurements and can only be calculated during discharge.

[locke987]

Thanks a lot, I will give it a try!

[Albarge]

I also had the same problem with the Aggregator CCL being lower than the aggregation of all batteries from their: Info/MaxChargeCurrent, but adding {"currentRatioMethod": "capacity"} to the JSON makes it track much closer, but still not exactly the same.

[pulquero]

There is a third option "count" (based on battery count), you could try that. If you really, really want, I could add a "sum" option where the aggregated CCL truely is the sum of the individual CCLs. But I don't believe this is desirable as it makes no attempt to ensure that the aggregated CCL is set such that there wont be overcurrent on an individual battery.

[Albarge]

I hadn't realised you had included a clever factor to try and mitigate overcurrent. Is there anywhere that explains better how it works? It takes the CCL from each battery and also their Ah capacities remaining and splits the CCL by the Ah capacities somehow?

Maybe if that already works, it's a good thing to keep, although with Serial Battery CVL and CCL factors they may also be working well for a similar outcome. The only thing is that it's hard to tell which settings from which driver are doing what.

[pulquero]

Current splits according to the resistances so for each battery the total current across all batteries reqd to meet its ccl is calculated. Then the min of these is taken. There are currently 3 ways to estimate the resistances.

1. Calculate it directly via sampling V and I during discharge. Potentially the most accurate, takes into account soc, temperature, age etc but a bit variable/noisy.
2. Estimate via capacities. Roughly speaking bigger batteries have less resistance.
3. Assume all batteries have identical resistance.

[Albarge]

Well it all seems to work as expected and well for me using the capacity method, I will try the other when I have spare time and sun.

If these are options others may be able to set, will the default behaviour explanation and options be added to the README? I think it's useful feature and interesting to know for others setting up, same goes for "cvlMode": "min_when_balancing" from https://github.com/pulquero/BatteryAggregator/issues/45#issuecomment-2067304744 to be added with explanation.

Thanks

[locke987]

I added the option {"currentRatioMethod": "capacity"} and from what I see it looks better than before. During the weekend the weather will be better and I can give a final statement. I would also think it would be a good idea to put an explanation of the different options somewhere for everybody else. Thx Stefan

[pulquero]

Documentation done.