Battery CCL ignored by MPPT control

[weichenb]

CCL defined by BMS or in DVCC should actually assure battery health.
Such definitions are not properly instructed to Multiplus's and MPPTs.
When CCL is set to 0 by BMS MPPTs continue charinging until having reached float voltage and are NOT properly controlled by VenusOS.
In the example below please see a case where a BYD LVL provided CCL=0, but MPPT and Multipluses provided up to 46A during a period of 6 minutes. "dvcc.py" seems only to consider CVL.

I would appreciate, if MPPTs are not only controlled by CVL but also by CCL.
All VenusOS versions impacted, example documented on 3.50~24.

[thepaulcooper]

I wonder if this is why I get very frequent "BYD Premium LV battery - Warning - High voltage" messages where the reported voltage momentarily peaks at over 56 volts? Weichenb, do you get the same? My setup is a MultiPlus II GX, MPPT RS 450/100 and 12kWh of BYD LV batteries with the BYD BMS.

[weichenb]

@thepaulcooper : On my side I haven't experienced any over-voltage issues.

Setup:

• MultiPlus-II 48/5000/70-48 - 3 phase setup - grid feed-in
• SmartSolar MPPT VE.Can 250/100 rev2
• Fronius Symo 6.0-3-M attached to AC-OUT

The issue seems to be partially related in dvcc.py

def _byd_quirk(dvcc, bms, charge_voltage, charge_current, feedback_allowed):
	""" Quirk for the BYD batteries. When the battery sends CCL=0, float it at
	   55V. """
	if charge_current == 0:
		return (55, 40, feedback_allowed, False, False)
	return (charge_voltage, charge_current, feedback_allowed, False, False)

Why is charge_current = 40 defined?
I think, setting charge_current to "1" would stop Multiplus charging at least, but assuring float phase.
MPPT charging however would still continue (they currently also ignore current defined in DVCC settings).

Main MPPT problem might be related in that constraint:

		# Do not limit max charge current when feedback is allowed. The
		# rationale behind this is that MPPT charge power should match the
		# capabilities of the battery. If the default charge algorithm is used
		# by the MPPTs, the charge current should stay within limits. This
		# avoids a problem that we do not know if extra MPPT power will be fed
		# back to the grid when we decide to increase the MPPT max charge
		# current.

A potential solution approach could be to set charger voltage to battery voltage (or slightly above). This would stop battery charging, but assuring grid feed-in.

[asdt1803]

Is it possible, that this issue not only affects BYD batteries? I'm having similar issues with my Gobel Power batteries.
The Pace BMS also does not feature a function to limit CCL. As the DVCC CCL does not have any affect on my RS450/200 and RS450/100 MPPT, it happens on days with highly fluctuating Solar Power, that one of the batteries goes into Cell overvoltage protection when the weakest cell of the batterypack peaks due to a suddenly high charge current.
Unfortunately the Pace BMS transmits only the lowest battery voltage over CAN. As the voltage of the battery in protection state decreases, the Victron system continues to charge the remaining batteries.
But: It does that without respecting the CVL-Limit configured in the DVCC setting and in the BMS settings (in my case both configured to 55,2 V)! I can measure up to 57,6 V directly at the Lynx Busbar, so that the remaining batteries enter into overvoltage protection one after another until all batteries are in protection state.

The DMM on the picture is connected directly to the Lynx Busbar.

Strangely the overshooting voltage is not visible in the VRM graphics even though this bevaviour sometimes occurs for more than a minute.

My System:

3 x MPII 8000
1 x RS450/200
1 x RS450/100
1 x Fronius Symo 10.0-3 in AC input
4 x Gobel Power PG-SR1-PC200 (Pace BMS)
29,92 kWp

[weichenb]

My System:

3 x MPII 8000 1 x RS450/200 1 x RS450/100 1 x Fronius Symo 10.0-3 in AC input 4 x Gobel Power PG-SR1-PC200 (Pace BMS) 29,92 kWp

Btw. what voltages did you set in Pace BMS?

In case you configured Pylontech simulation in Pace, voltage is directly taken from Pace.

		if charge_voltage > 55:
			# 48V battery (16 cells.) Assume BMS knows what it's doing.
			return (charge_voltage, charge_current, feedback_allowed, False, False)

and manual charge voltage from DVCC seems to be supported only, if Pace provides a reasonable CVL.

		# Override the battery charge voltage by taking the lesser of the
		# voltage limits. Only override if the battery supplies one, to prevent
		# a voltage being sent to a Multi in a system without a managed battery.
		# Otherwise the Multi will go into passthru if the user disables this.
		if charge_voltage is not None:
			user_charge_voltage = self._settings['maxchargevoltage']
			if user_charge_voltage > 0:
				charge_voltage = min(charge_voltage, user_charge_voltage)

[asdt1803]

Btw. what voltages did you set in Pace BMS?

In case you configured Pylontech simulation in Pace, voltage is directly taken from Pace.

The BMS uses Pylontech protocol. In the BMS-settings I left the default value of 55.2 V.
In fact I usually set a lower voltage via CVL, especially when I'm away from home, to avoid this charge voltage overshoots. As said, CVL usually works for me. The only trouble occurs with full or nearly full batteries in combination with highly fluctuating solar power as described above. In that case the Charge voltage exceeds the configured limits for whatever reason.

For the Product ID of my batteries there seems to be no quirk defined in dvcc.py
root@einstein:/var/log/can-bus-bms.can1# grep Product /var/log/can-bus-bms.can1/current
@40000000657721540d94a194 INF.can-bms: Product ID from settings: B007