It would be really nice and a safety feature to be able to log and analyze individual cell voltages in VRM. My BMS reports these, as do most BMS’es and they show up in Venus OS with the serialbattery extension.
Now since Victron’s LiFePO₄ batteries have a BMS with cell voltage monitoring I think it would be nice if VRM would be aware of this.
Thanks
Hi there.
The CAN spec does not broadcast this detail, merely high and low cells.
It is pretty much only accessible via a serial connection, which is not used natively.
Serial battery is an unsupported 3rd party, non-CAN connection.
Battery systems can also be enormous, the amount of overhead that would produce and additional resources required by the platform would be expensive.
For the most part that level of detail is only required for troubleshooting, and in those instances supported batteries have tools to access that information.
Sure it would be nice to have but I doubt it is worth the additional complexity and challenges it would create.
Thanks, I can understand that instead of logging two numbers some people have tens of cells and that would cause scaling issues.
My BMS is connected with CAN to Venus OS using serialbattery (running on a raspberry 3b+ + CAN-hat) and I can see Cell Voltages in Venus OS. So surely CAN is able to convey these voltages, I am a total newb here but maybe the chosen protocol is where the differences are?
An alarm for large deviation in cell voltages between min and max will wake people up, but logging creates statistics from where trends can be seen. Maybe i’m just too eager with all this new stuff 
Thanks for a speedy reply.
I think you will find that it isn’t actually communicating using CAN, certainly not the BMS.CAN protocol which has a very defined spec that all BMS’s need to support in order to communicate natively.
This spec does not contain the ability to send that breadth of data, that I am aware of.
There is a large variation in system size, many installations are large and would have hundreds of cells.
Min/Max provides a means to trend potential issues, though they can manifest in different ways where really the upper and lower limits are the most important for fault finding as it is usually one of those that is the cause.
Battery debug requires more detailed info and the inverter isn’t the best place to diagnose that imo.
Most decent batteries are logging extensively and a much wider set of data can be stored and accessed via BMS tools.
I am a data geek myself, so would love to see that info. Just wouldn’t expect to see it given the changes that would be needed.
Anyway, all requests are good and can fully appreciate why someone would like to access this detail, so no need to debate the point, and maybe you get lucky
(don’t forget to vote for it at the top of the post)
Wait, it’s ethical for me to vote for my own suggestion?
Thanks
Presidents in elections get to vote for themselves, so why not.
At present I see the high & low voltage but not the cell ID. That shows “null” for ID. Have that been ever fixed in any up dates? It would be useful in trend monitoring.
Regards Bill
This is a matter of the BMS. I have a JK-Inverter-BMS which reports battery id plus cell id, separated by two colons. Former firmware versions of that BMS did not show the battery id.
As mentioned above, the CAN protocol only communicates the cell id for highest and lowest, for temperature and voltage. If you BMS does not fully implement this protocol, then the cell ID’s may be missing, and only a BMS firmware update can fix that.
The data communicated over the dbus serial battery may well be more exhaustive, and again, the limit of the information may be restricvted either by what the BMS broadcasts, or by the software interface in the Dbus-serial-battery software.
As has also been pointed out, this information is mainly useful only for troubleshooting - as when the battery develops a high value of delta voltage due to an inability to balance.
What I look for here is is the same cell number the first to reach the voltage limit on charge and discharge?
If you want to log this data (individual cell voltages), then you should be able to implement this locally, but I would not expect VRM to do that - this could lead to mega amounts of data - I have 40 cells being tracked by my software, every 5 minutes through the day. I limit this by only retaining the last 24hrs of data. Hope this helps.
Thanks Tom
And thanks Mike.
