It’s possible that you are already knowing this, but a lot of info and clarification can be obtained by studying the scripts in /opt/victronenergy/dbus-systemcalc-py/delegates folder in Venus OS. Especially the dvcc.py…
You’ll find there how the voltages and currents are calculated and how they are bounced back and forth between devices.
1 Like
Thanks, been using Dbus-spy to check on what’s going on…
Found where the 52.5V limit is coming from:
in DVCCL.py in the folder there is a ‘fix’ for a Pylontech battery - or more properly several fixes.
However, the code can only properly differentiate between a 15 and 16 cell Pylontech battery, and not necessarily when other cells are used and the BMS tries to emulates a Pylontech battery.
so the problem is here that for a 16 cell battery, the CVL can drop below 55V -at least for my battery, and the code is assuming that the battery is now a 15 cell battery.
also the default charge voltage is set to 52.5V, which is not useful.
Whilst Pylontech do fit 15 cells into their 48V batteries, I’m using a system based on 8 cell 24V batteries, so 2 in series give me 16 cells - this is a nominal 52.8V, and max 56.8V, well within the capabilities of a 48V system, designed for max Voltage of 62 - 63V.
So it looks like this fix needs a review. Also perhaps the CAN protocol should include a ‘tweak’ for indicating No of cells in series…??
Fixed the default voltage from 52.5 to 52.8 - this is still safe for 15 cell batteries, and the ‘if charge voltage > 55’ to if ‘charge voltage >=53.6’ and that seems to have fixed the immediate problem. However, this won’t survive an update without having to be fixed again.
I think that Pylontech also do make the 16 cell units, but these are 52V batteries, rather than 48v?
I find that when ESS Mode 3 is set (External control) Both the inverter and the solar charger receive 0V as the ‘charge voltage’ !! Why should this be? Does the external control have to set these values too? I’ve seen nothing about that in any documentation (ESS mode 2 and 3 [Victron Energy] is out of date - has the wrong registers and UId - those are no longer accessible., but getting off topic)
Note also that setting the inverter voltage down 0.4V wont work, as then (subject to change in ESS asistant) it would be exporting power all the times. Success of the strategy of increasing the solar charger set point depends on the solar charge power being less than the inverter power, which is usually not the case… so battery will be subject to some small voltage in excess of the CVL set by the BMS.
This was historically a problem for batteries spoofing pylontech, and obviously isn’t tested for non-pylontech systems. Are you not better off spoofing one of the other brands which does not have these dvcc mods?
Hi Nick,
As there is a fairly comprehensive list of Quirks in DVCC.py (including for Victron’s Lynx BMS), I’m not sure that changing the protocol would be beneficial.
Either way, the current protocol is satisfactory, and this is only being used for a test / research set up, not currently for production.
However, the fact that these quirks exist, and that there are so many different protocols is down to the fact that the CAN standard is ‘closed’ not an open standard. This means that one has to pay $$$ for access to the standard, and it is defined by large industry players.
Open Standards - which are free access are far more likely to be implemented in a ‘standard’ fashion, whereas for closed standards, if you are a relatively minor player, and for example, the ‘standard’ doesn’t cover all of the data you want to transfer, then you develop your own proprietary sub standard - which will not be compatible with another developers approach to the same problem. Standards committees are supposed to resolve these issues, but if the committee is European based, then a Chinese manufacturer may not approach the committee for the change. In an open standard, then resolving these types of issue is a little easier.
Hi,
A lot of this has been said already, but I think it would help to have some comment from Victron to clarify a few things.
The Pylontech BMS precedes the current Victron BMS-Can protocol specification. The way the Pylontech behaves specifically around the CVL, CCL and cell balancing, combined with their market size has meant that Victron made an exception in our code for batteries that identify as Pylontech to optimise their performance.
These optimisations are extremely specific to Pylontech BMS and Pylontech cells, and so Pylontech should not be used as a reference design for any other BMS or cell combination. It will not behave as expected and there will be no end of anomalies (as you have seen) which is the absolute last thing you want when charging lithium batteries.
While the Victron BMS-Can specification is not an open source document, it is available from us free of charge by contacting the Victron sales manager for your region and making the polite request.
I am going to edit your accepted solution as well @MikeD - the Pylontech code exceptions do correctly identify between 15 cell and 16 cell Pylontech batteries, but that exception does not (and will not ever be modified to) account for other cells that are trying to emulate Pylontech.
The solution is to properly implement Victron BMS-Can and for the battery and BMS to correctly identify itself.
1 Like
A post was split to a new topic: Incorrect charge voltages