Calculation of MaxChargeCurrent and MaxDischargeCurrent for different configurations

[kakariki1]

Hello,

this is an addendum to https://github.com/Dr-Gigavolt/dbus-aggregate-batteries/issues/10

I'm running 3 different systems:

1. single phase system 1x MultiPlus-II 48/5000/70-50 (connected to a single phase) 1x Fronius Symo 12.5-3-M (connected to all 3 phases) 1x 18 LiFePO4 batteries with JK BMS 2A24S20P in 18S1P configuration

2. single phase system 1x MultiPlus-II 48/5000/70-50 (connected to a single phase) 1x Fronius Symo 12.5-3-M (connected to all 3 phases) 2x 18 LiFePO4 batteries with JK BMS 2A24S20P in 18S2P configuration

3. three phase system 3x MultiPlus-II 48/5000/70-50 (one per phase) 1x Fronius Symo 20.0-3-M (connected to all 3 phases) 3x 18 LiFePO4 batteries with JK BMS 2A24S20P in 18S3P configuration

All three systems are running the same Venus OS 2.92, dbus-serialbattery and your dbus-aggregate-batteries. I know, aggregate-batteries is not needed for the 1st system, but I want to keep the software the same for all.

I always noticed quite a great cell drift in the 2nd system and now found the reason, a wrong charge and discharge current calculation. In this configuration the currents have to be divided by two, because 2 batteries are connected to one MultiPlus. So I added a new setting NR_OF_BATTERIES_PER_MULTIPLUS and divide MaxChargeCurrent and MaxDischargeCurrent by this value. Not sure if this interferes with anything. Does this make sense ?

In addition I added a state-machine to prevent a battery-low warning and added a safety feature, but that's another topic. It's fully tested in all 3 configurations and works flawless so far ...

The source code is attached, changes are marked by "lakeroe" and files are renamed to .txt If you're interested feel free to add it (or parts) in your source code.

Best regards, lakeroe

aggregatebatteries.txt settings.txt

[Dr-Gigavolt]

Hello and thank you. I'll review your code at the next opportunity.

[Dr-Gigavolt]

I've just looked through your hardware description. How do you run a 3-phases Symo on single phase? All 3ph parallel? Does the Symo accept it? Why don't you add one more Multi (resulting in 2 x 3ph system) and put all batteries in parallel? That is what Victron recommends. What you do cannot work properly. The most full (or most empty) battery will limit another two.

[kakariki1]

The description is probably a bit unclear. The phases are only regarding the Victron Multiplus, all Fronius Symo are connected on 3 phases ... I've updated the description above.

[Dr-Gigavolt]

Back to your system, why don't you connect all batteries in parallel as recommended by Victron?

[kakariki1]

Why do you think the batteries are not connected in parallel ? They are, as recommended by Victron.

System two has 2x 18 LiFePO4 batteries with JK BMS 2A24S20P in 18S2P (18 series and all 2 in PARALLEL) configuration System three has 3x 18 LiFePO4 batteries with JK BMS 2A24S20P in 18S3P (18 series and all 3 in PARALLEL) configuration

The difference is: System two is single phase and all batteries are connected to 1 Multiplus System three is a three phase system and all 18S3P batteries are connected to 3 parallel Multiplus

[Dr-Gigavolt]

I mean all batteries in one system should be connected in parallel, only one DC busbar per system. If not, how should batteries Nr. 2 and 3 be fully charged if the battery Nr. 1 says "I am full" and the battery driver, either SerialBattery or Aggregate Batteries, stops charging?

[kakariki1]

Yes you're absolutely right, and that's how it is connected, one DC busbar per system ... For example have a look at the three-phase system, I think the bus bar is clearly visible. And it works just perfect !

[Dr-Gigavolt]

My understanding of your description was completely different :-). Could you sketch the schematic diagram?

And I see you have no fuses in the BMS lines. I strongly recommend sand-filled fuses with rating of couple A and cut-off capability of at least 1kA. I have 5A / 1500A in my system. Otherwise you have a risk of fire in case of short circuit.

[kakariki1]

I can sketch a schematic diagram later this day ... What do you mean by "fuses in the BMS lines" ? There are 6x 150A fuses right next to the bus bar ...

[Dr-Gigavolt]

In the measurement/balancing wires. I see no (small) fuses there.

[kakariki1]

Yes you're right. I haven't seen anybody using fuses in the balancing wires so far. In case of a short circuit i reckon the small wires or connectors vaporize within a very short time. But I agree, it's not the most secure or elegant solution ...

[kakariki1]

Please find a VERY simplified schematic diagram from all my 3 systems below:

[Dr-Gigavolt]

After all it is as I understood initially. What is the reason not to make 3x ((18s x 2p) + BMS)) and connect all in parallel? Are they faraway each from other? In this case they should have separate Venus devices.

[kakariki1]

I really don't understand what you mean. All of my 3 systems work perfectly and I won't change anything. I also think I wired everything exactly as Victron recommends in there "Wiring unlimited" book. Maybe that's not clear for you: All 3 systems are at 3 different locations a few km apart ...

My intention when opening this post was to share my experience with different configurations and if you want, to make your driver more flexible to various configurations, not to discuss different wirings.

Anyway thanks for your great work !

[Dr-Gigavolt]

I needed to understand why you needed do change the code. So all three systems are completelly independend, in different locations. That is what I wanted to know. I thought they are in one house with one common Venus device. OK, now I can look on your code modification. Thanks.

[Dr-Gigavolt]

I'm reviewing your code modification now and cannot understand the problem. You reuse charge/discharge parameters from SerialBattery, let's make an example:

Batteries = 2 Battery1: I_charge_max1 = I_discharge_max1 = 100A Battery2: I_charge_max2 = I_discharge_max2 = 80A

Results: I_charge_max = I_discharge_max = 2*min(100A, 80A) = 160A If the resistances of batteries and cables are equal, both batteries will be charged or discharged by max. 80A.

Further, I don't understand PER_MULTIPLUS. If Multis are connected in parallel or as 3 phases they act as a single device.

Thanks for the 0,1A limitation of discharge current, I'll implement it too.

[Dr-Gigavolt]

I see you use VeDbusItemImport. I had to replace by Dbus Monitor, it was too resource consuming and slow. And I haven't understood how you write e.g. self._setting_max_charge_current.set_value (-1.0). Where is the function defined? Thanks a lot for showing how to stop charge or discharge, I didn't know before how to do it. Setting paths AllowTo(Dis)Charge to false didn't work.

What do you use from "utils import *"? I think it is a bit dangerous, the SerialBattery is still under development and the stuff you use may be modified or disapear in the future.

[kakariki1]

Okay, let me try to explain:

The settings for my 3 different systems are: System 1 2 3 NR_OF_BATTERIES 1 2 3 NR_OF_BATTERIES_PER_MULTIPLUS 1 2 1

Regarding the calculation of MaxChargeCurrent/MaxDischargeCurrent the only thing I changed is dividing by NR_OF_BATTERIES_PER_MULTIPLUS: MaxChargeCurrent = self._fn._min(MaxChargeCurrent) NR_OF_BATTERIES / NR_OF_BATTERIES_PER_MULTIPLUS MaxDischargeCurrent = self._fn._min(MaxDischargeCurrent) NR_OF_BATTERIES / NR_OF_BATTERIES_PER_MULTIPLUS

Try to think about all 3 configurations and it should make sense (in any system the current should be the lowest allowed). NR_OF_BATTERIES_PER_MULTIPLUS is only needed in my 2nd system.

Everything else (the state machine below) is just adding different security levels to prevent charge, discharge and battery-low warning, but that's a different story.

Regarding VeDbusItemImport: Like you, this is my first Venus OS / Python project and I still don't understand everything. I "stole" some ideas from here: https://github.com/t0bias-r/venusos_acload_prioritize

The "utils import *" is to get access to MIN_CELL_VOLTAGE and MAX_CELL_VOLTAGE. I know it's not the most elegant solution but works for me.

[Dr-Gigavolt]

Okay, let me try to explain:

The settings for my 3 different systems are: System 1 2 3 NR_OF_BATTERIES 1 2 3 NR_OF_BATTERIES_PER_MULTIPLUS 1 2 1

Regarding the calculation of MaxChargeCurrent/MaxDischargeCurrent the only thing I changed is dividing by NR_OF_BATTERIES_PER_MULTIPLUS: MaxChargeCurrent = self._fn._min(MaxChargeCurrent) NR_OF_BATTERIES / NR_OF_BATTERIES_PER_MULTIPLUS MaxDischargeCurrent = self._fn._min(MaxDischargeCurrent) NR_OF_BATTERIES / NR_OF_BATTERIES_PER_MULTIPLUS

Try to think about all 3 configurations and it should make sense (in any system the current should be the lowest allowed). NR_OF_BATTERIES_PER_MULTIPLUS is only needed in my 2nd system.

In the case 1 and 3 it is clear, of course. But my case is similar as yours, I have 3 Multis and 2 batteries. I just disabled my own parameter calculation to reproduce your preferences.

Each physical battery: AggregateBatteries:

The max. 200A is spread into 2 batteries, each gets or gives max. 100A - correct.

[Dr-Gigavolt]

Everything else (the state machine below) is just adding different security levels to prevent charge, discharge and battery-low warning, but that's a different story.

Regarding VeDbusItemImport: Like you, this is my first Venus OS / Python project and I still don't understand everything. I "stole" some ideas from here: https://github.com/t0bias-r/venusos_acload_prioritize

Thanks a lot for this proposal, I'll test later when will have some time for it.

The "utils import *" is to get access to MIN_CELL_VOLTAGE and MAX_CELL_VOLTAGE. I know it's not the most elegant solution but works for me.

I prefer to collect data from SerialBatteries and calculate everything by my tool.

[Dr-Gigavolt]

And now I'm thinking about Low Battery warning if max. discharge current is zero. Why should we avoid this warning? Is there any reason to set it to zero if the battery is not low?

[kakariki1]

In my case the "Low Battery warning" often pops up if the battery is far away from empty and for sure not low ...

[Dr-Gigavolt]

In my case the "Low Battery warning" often pops up if the battery is far away from empty and for sure not low ...

But then there is no reason to set max. discharge current to zero. Or what do I misunderstand?

[kakariki1]

That's exactly the point. If MaxDischargeCurrent is zero (or below 0.1A) the warning occurs, if greater 0.1 then not.

That's my solution: MaxDischargeCurrent = max (0.1 * NR_OF_BATTERIES / NR_OF_BATTERIES_PER_MULTIPLUS, MaxDischargeCurrent) # to prevent battery-low warning MaxDischargeCurrent is not allowed to be below 0.1A per Multiplus

[Dr-Gigavolt]

That's exactly the point. If MaxDischargeCurrent is zero (or below 0.1A) the warning occurs, if greater 0.1 then not.

That's my solution: MaxDischargeCurrent = max (0.1 * NR_OF_BATTERIES / NR_OF_BATTERIES_PER_MULTIPLUS, MaxDischargeCurrent) # to prevent battery-low warning MaxDischargeCurrent is not allowed to be below 0.1A per Multiplus

I understand the calculation. But not the reason. How can happen MaxDischargeCurrent = 0 if the battery is not empty? Bug in SerialBattery? In my case the alarm was always on before I set everything to False in SerialBattery. Even if I calculate parameters myself, I had some features of SerialBattery active to observe the results on the Dbus.

[kakariki1]

How can happen MaxDischargeCurrent = 0 if the battery is not empty? Bug in SerialBattery?

MaxDischargeCurrent = 0 happens when MIN_CELL_VOLTAGE (i.e. 3.00V) in dbus-serialbattery is reached. This only means to stop discharge, but not an empty or low battery which is for example 2.60V.

There are many posts about this "problem" in the Victron Community, for example: https://community.victronenergy.com/questions/191406/false-low-battery-voltage-alerts.html https://community.victronenergy.com/questions/190864/multiplus-2-483000-unexplainable-low-battery-alarm.html

This is either a "bug" or the intended behaviour of the Multiplus II firmware not dbus-serialbattery.