The Felicity LiFePo4 batteries 350AH 48V batteries obtainable in my area (which appear to be the same model as this) are compatible to some extent with the Cerbo GX over CAN. To get the system working:
Connect the CANL-PCS on pin 3 from the battery to pin 8 of the RJ45 connector to the Cerbo GX.
Connect the CANH-PCS on pin 4 from the battery to pin 7 of the RJ45 connector to the Cerbo GX.
If using the CANBUS-BMS port on a Cerbo GX, no further configuration should be required. For the VE.CAN port, got to Settings>Services>VE.CAN port and set the “CAN-Bus Profile” to CAN-Bus BMS LV (500 kbps).
The battery should then show up in the device list as a Pylontech Battery and automatically force DVCC. Obviously this is not a Victron tested integration, but so far I have not noticed any issues aside from an occasional “High Voltage” alarm that is easily ignored. If you have multiple batteries and addresses are set correctly, it seems to correctly calculate the total DCL/CCL. Either end of the battery bank seems to work for the canbus, it doesn’t seem to need to be connected to #1.
Would be nice if someone comes up with a solution to suppress the “Battery High Voltage” warnings.
Let me know if this works for you or if you have any issues or questions on getting it going.
No offense, but are you sure that’s OK to suppress those warnings?
Because, if the comms are OK, then the status info is correctly received and then those warnings have a reason…
Just my 2 cents…
Or do you mean something else when you are saying “a solution to suppress the warnings” ?
I’m not sure that it’s okay to suppress the warnings. However, they are generated by the BMS which is also controlling the charge voltage. I saw somewhere that they are normal on actual Pylontech systems…
Less than 56 volts, and the specs on this battery say that it charges to 57.6 volts. I have found that anything over 56.8 is really too much. But under 56 volts is fine. The alerts are not warnings, but they show up as notifications on the Cerbo GX, which is a bit annoying and can drown actual important notifications.
That alarm bit description says: Cell or module high voltage.
You say that the stored voltage when error appeared was under 56V, so 3.5V per cell.
Therefore it must be a Cell HV, which indicates a pretty unbalanced battery or a battery that didn’t get too many chances to balance.
They’re not really high quality batteries, so it’s possible that a cell is out of balance. However, the BMS is controlling the voltage, so I don’t see any reason it should complain about it being too high unless it is a specific cell. But as I said, I saw on the old forum or somewhere that this is normal for even Pylontech batteries.
High voltage warnings are generated by the BMS and are related to balancing etc.
If you need them to go away, first let them balance properly on extended charge, or consider reducing, temporarily, the CVL via DVCC.
Many topics on this subject which can be find via some googling.
Unfortunately most of those topics are related to actual Pylontech batteries, not other batteries using the same CAN Bus protocol. Is there any way to see all the messages that the Cerbo GX is receiving over CAN? I’d like to see if there are any messages that are not being properly interpreted.
The make doesn’t matter. HV alert is an event sent by the battery. If you are getting these then you need to look at the battery and bms and ideally speak to the manufacturer as it is unsupported.
The reasons it happens on a pylon is the same reason you see it on most other batteries, its just more prevalent on a 15 cell battery.
None of this is anything victron can resolve.
can1 is usually the can port used on Cerbo MK1 for BMS.
If you have a Cerbo MK2 and you’ve connected the battery on the other can port, use can0.
Anyway it’s a good utility to sniff on the can ports traffic.
hello , well a lot of pylontech batteries have this error, and its resolved by the bms.
imho the pylontech bms software is a bit slow, basically one cell reaches 3.65 volts, the alarm is set and the ccl is reduced,
IMHO the bms should reduce the CCL (CVL) a bit sooner as in 10 min the cell balance is often reached. and its not a problem for really well cell matched systems. but that gets more and more difficult with larger and larger systems. the amount of energy difference is very little as the balancing resistors is very litt.e
how to stop this from happening ?
well a lot of people have reduced the dvcc max charge volt to 52 volt, and i have tried more and more. this can often help, but not always, if you reduce it to much the cells are below the upper knee so the balancing circuits have little effect.
what i have also done is with node red, reduced charge current in the top 5-10 % of charge of the battery, this gives the pack a bit of a chance to balance the cells and let the pack reach full voltage and do its reset to 100%
ultimately the cells not perfect, the bms software not ideal.
Thanks for the helpful tips. This battery is 16 cells, so the voltages would have to be adjusted accordingly. Overall I think the batteries are now fine. The alarms set do not trigger a VRM alarm, but they do trigger an alarm on the remote console. It will be interesting to see if Victron adds any support to avoid BMS issues on supported or unsupported batteries.
I’m happy that the battery is communicating, and not terribly worried about these warnings.
I moved this back to the modifications space. Don’t want everyone spending a lot of time trying to troubleshoot my Pylontech clone batteries.
I just posted the initial guide in case someone else might be interested in getting these batteries to talk.
As the batteries are identified as Pylontech, the “quirks” for Pylontech in the Venus OS scripts apply.
There is in this moment a very good approach to handle the over voltages for the Pylontech batteries, but that approach is applied only for the 15 cell batteries.
The 16 cell batteries are left alone, assuming that their BMS knows what to do. It seems that they not always do…
A solution for your problem is to modify that script in order to also handle in the same way the 16 cell batteries.
Maybe @iburger can apply the same algorithm for 16 cell batteries too, because I believe there is nothing wrong with that. Only to gain.
If not, and you know your way around Venus OS, SSH access and Python scripts, you can try to make the necessary modifications, following the code from here and apply it here.
@alexpescaru , thanks for the tip. I vaguely remember reading something about the algorithm for the 15S Pylontech batteries. It’s not a huge deal for me, but I would be interested in seeing it implemented.
well its the bms that is the problem imho. if it would lower ccl cvl sooner the cell imbalance woudnt be enough to trigger the alarm. the alarm is an alarm becase cell voltage is exceeding the recommended max voltage.
