Looking at new lithium batteries and wanting as deep Victron support as possible. Preferably individual cells,
What is possible over the battery CAN port on a Cerbo GX?
Can we see individual cells with voltage, temp errors etc. if the BMS has support to tell the Cerbo GX?
Many thanks for any info on this.
Yes.
It is possible to get in-depth monitoring on the GX. All cells etc and temps. It does depend on what the manufacturer has shared and to what address.
(Edited: remkved fet temps as they are more of a third party driver -unsupported possibility) And fairly unusual.
Vrm will only log/show min and max and the address of them. (Cell/battery Temps and voltage)
Thanks, great to know. If you or anyone know how to specifically ask for this kind of in depth support from a battery company that would be great.
Are you saying you can get voltage and temps for all individual cells at VRM now also? Warnings for individual cells?
I have had some bad experiences in the past with half-baked CANbus support so will try to avoid it this time around.
If it is not all at the VRM GUI, I would probably try to publish it in Node Red. I am basically looking for security to switch off, probably at the Lynx BMS, based on
error messages, Native Victron would be nice for this with 3d oat BMS but we shall see I guess,
A modern CAN system will expose some 150 can objects per battery, many of the being control or status objects. Only about 20 are parameter objects.
The can system is configured to read all the data and work with it. If you go with a supported battery, it should be about as simple as plug and play.
If you give me the objects from the firmware or a datasheet I can port third-party support for you.
Edited my previous answer.
The temperatures available are as available as the bms physical and firmware monitoring is.
This is not all published in the supported/normal drivers on the GX.
Some bms only have 1 or 2 probes in the battery bank, so that would be all you get if the bms publishes it. Some just use it for their own internal logic.
The usual approach for Victron integration is not Victron persuing all the battery companies in the world (that would be an impossible task) but the battery company approaching Victron to integrate with Victron support.
So if it is something you want from the company you are interested in supporting then you should propose that option to them
I believe it it the responsibility of the user to port logic where possible. As the companies are interested in hardware lock in and full control of their systems. This has been the industry standard for any hardware manufacturer as itâs the only way they can ensure ROI on RnD.
Requesting a manufacturer to open up to the competition is an undertaking that is massively beyond the scope of any potential buyer. Which is why I maintain that users like myself should provide the service for the betterment of the community rather than the financial gain provided to any board of directors.
It is a unique niche as installers need this logic, but manufacturers will most likely refuse the information especially if the compatibility offered competes with their own products.
Since everyone knows that the BMS is the core driver of all systems, maintaining security through obscurity is a fundamental aspect of market dominance.
As a community, Id rather do free work and have systems live on forever than have the company buy in support option that is only valid for as long as they say it is.
All the batteries on the supported list have basically approached Victron, got their required information and integrated.
As you probably know there are a few on Git that have drivers, one of them a pretty âfamousâ one and well used.
One of the reasons why I like Victron is it is open enough for you and I to integrate and have a the opportunity where we can value add or as your self who will do it because they can.
The Venus OS shows the information that the BMS is sending.
Most BMS only send the highest/lowest cell voltage/temperature.
IMO that is enough. Why do you need the voltage/temperature of every single cell?
If you know the highest/lowest than you know all the others are between that.
For sure, that would be the ideal way to go, I am however maintaining the âshould all else failâ aspect, as in my case with super-b / Redarc. Or where I commend Samsung for their transparency in their data sheet, making their batteries fully open.
It shows that such information can be released and that security through obscurity is not a nesecity in their policy.
Thanks for your reply @M_Lange I agree about the highest and lowest being enough for day to day use.
Would also think it can be useful with as much data as possible to catch trends and possible issues in time.
I appreciate the answer and am talking to a few battery makers in pretty much this way,
If it is in the Canbus stream it might be possible to at least get it visible in our Node Red Dashboards.
We shall see!
Thanks. I may get back to you about that porting if I come across it in a few months.
Any time. Will be glad to help out
For relevance and completeness, I will also post here what Iâve posted elsewhere on the forum about what info can be obtained on a Cerbo-like device from a Pylontech set of batteries.
But for this it must be used a custom made utility/script that will interrogate the relevant information from the master battery.
Currently the Venus OS doesnât have such utility.
Example of a small utility written in c:
Thatâs a really good idea. To curate a list of objects available for different batteries.
This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.
