question

Hi All,

I believe that I found the / an answer to this.

You need to be somehow familiar with the hardware design of the Victron Multi RS and to read between the lines of the following documentation: https://www.victronenergy.com/live/battery_compatibility:start

Especially the following paragraphs:

1. Batteries using a BMS that blocks charge, or discharge current, or sets CCL to 0 when full, can trigger a number of confusing or misleading inverter/charger warnings and alarms.

2. As a battery becomes fully charged, Victron requires the BMS to change the Charge Voltage Limit (CVL) to restrict the power flowing to the battery. If, however, the BMS attempts to restrict power using the Charge Current Limit, without adjusting the Charge Voltage Limit, this can trigger Overcharge, Overvoltage or Overcurrent warnings.

More of that also a comment on the dvcc.py script inside the Victron OS caught my eye, when talking about Pylontech Pelio:

Battery sends CCL=0 at 3.55V per cell and, to ensure good feed-in of excess DC coupled PV, set the lower limit to 20% of capacity, which is what the battery itself imposes at around 98% SOC.

The Pylontechs are setting the CCL to 0 (zero) when reaching 100% SoC, which contravenes with the above.

More of that, when the Multi RS is "alone", without Cerbo, it seems that will never reach the situation to generate such a #29 - Overcharge error.

So it seems, that when the charger is under external (Cerbo) control, the inverter is told that it needs to supply a certain current. That current is published by the Cerbo, on CAN bus, on 0x2015 Victron register.

If that 0x2015 value is 0 (zero), then that error could appear in certain situations when the charger, being at idle starts and then stops. Excess of power, especially when stopping, could trigger that #29 error.

The fact that charger is at idle is also seen on the sawtooth evolution/behavior of the battery pack voltage, which from the float voltage slowly reduces to battery idle voltage, then, when the battery tells that needs topping up the charger starts, rises to float and repeats.

So, the solution became quite clear - try to keep that part of the Multi RS that produces DC power "alive" and not allow it to go to idle, just like when you feed-in.

In my situation, when I don't use Node Red or other similar automation, I had two choices.

1. To modify the /Debug/BatteryOperationalLimits/CurrentOffset to a certain value

2. To modify the dvcc.py script and to add to the function that handle Pylontech quirks additional parameters.

The easy way for anyone, because of the easy access to DBus values, is the first choice. I've asked about its purpose some time ago, but no one answered. This could be a good reasone to use it.

One could add there a value equivalent with battery's C/10. For example, if you have a 300A battery, you set there a value of 30Amps. Pylontech sets anyway a value of C/5, so bigger, when the pack reaches absorbtion. So C/10 is quite OK.

I, for one, because any Cerbo reset will set the value back to 0, I've prefered the modification of the dvcc.py script and at about line 65, where the case of Pylontech with 15 cells case is treated, I've added the following modification:

----- original -------

if charge_voltage > 30:
   return (min(charge_voltage, 52.4), charge_current, feedback_allowed, False)

----- modded -------

if charge_voltage > 30:
   capacity = bms.capacity or 100.0
   return (min(charge_voltage, 52.4), max(charge_current, round(capacity/10.0)), feedback_allowed, False)

A similar modification is made by Victron and already in place for BYD batteries and Pylontech 24V batteries.

That's pretty all. It works flawlessly. More of that, no more sawtooth behavior on the battery voltage.

Also, before the modification, when an apreciable load started, you could see the batteries woke up from the idle state and supply power to the load. You could see all their leds light up from idle state. Then when the MPPT catched up, the batteries were going back to sleep.

Now, they dont even bother and remain at idle...

Have fun,

Alex