I have a BMS-Can compliant 24v LFP house bank with internal BMS communicating to a Cerbo GX via 500kb/s BMS-Can protocol. I’m adding a new charging source (bi-directional DC-DC from Alternator and starting 12v bank) which communicates at 256kb/s (so either VE.Can or CAN-bus BMS). The VE.Can device cannot detect any CanBus batteries.
The Cerbo GX (Mk1) manual states “ VE.Can and BMS-Can cannot be combined on the same bus. If you wish to use both, they require a GX device with two separate buses, each with 2 RJ45 ports - 4 CANbus ports in total.”
The update Mk2 manual states “ VE.Can and BMS-Can cannot be combined on the same bus. If you wish to use both, they require a GX device such as the Cerbo GX MK2 or Ekrano GX with two separate buses, each with 2 RJ45 ports - 4 CANbus ports in total.”
The CerboGX (Mk1) has 4xRJ45, 2 dedicated to BMS-Can and 2 dedicated to VE.Can, and the Mk2 has 4xRJ45, split between 2 CanBus ports selectable to either BMS-Can or VE.Can, so the above statement is unclear as to whether the 2 seperate buses (BMS-Can and VE.Can) can share battery data from the BMS.
My question therefore, is does anyone have a method of communicating BMS-Can battery data to a VE.Can device on a Cerbo GX MK1? and would the CerboGX Mk2 be able to do this?
By itself Venus OS doesn’t do this.
I mean what it receives on one CAN port from BMS, it doesn’t send onto the other.
But you can design your own driver to do this.
The data from BMS is stored onto the system’s dbus.
You can make a small script to periodically take that data from dbus and broadcast it onto the other’s device (charging source) CAN bus.
Hi Alex,
Thanks for the response, not sure designing drivers and scripting is within my competency at this stage, but I’m learning… An alternative I’m considering is using the relay on my Multi2 to send a stop/start charging message to the DC-DC as a non-CAN workaround. Or drop another $450 on the Mk2 Cerbo, which appears to do this, based on the statement from the manual I quoted above.
Do you have any advice on how to do this, documentation, example script, etc? I have a dbus-aggregate battery and I need it to broadcast its BMS information to a WS500.
That battery and its driver are storing information on dbus.
You can use dbus or dbus-send utilities to read those dbus paths to some variables, inside a bash script.
Then in the same script you can take those variable’s values and send them, at reasonable time intervals, over the CAN bus you desire.
Then make that script to run at runtime.
Example on how to do this are on the Victron and Venus OS help/wiki repositories.
Do you have links to these examples? Not how to read the dbus, but how to send information over the CAN bus and how to format it to act like a BMS? That’s exactly what I’ve been looking for but I’ve had no luck.
You want to send CAN frames over one of the CAN buses, where your “listening” device is, right?
So the question to be asked is how that listening device expect that information and how should it be formatted.
Once you have the format, you can use cansend utility, that is shipped inside Venus OS.
Do you have a Cerbo?
Because on a Cerbo, the BMS-CAN bus is configured as an 11bit CAN bus and the VE.CAN bus is configured as an 29bit CAN bus.
On which type of network configuration is your Wakespeed controller working?
How is it expecting the info from the BMS? In which format?
Is your WS controller connected somehow to your Victron system?
I don’t have an example for you, neither I worked with WS devices, but if I were you, I would try to connect that WS device on a separate CAN bus network, created with one USB to CAN converter supported by Venus OS.
Then on that CAN bus network, I would broadcast, with the parameters and format the WS controller expects, the info from the Venus OS dbus, regarding the battery data.
It’s a CerboGX, the WS500 is connected to one of the VE.can ports set to VE.Can and Can-Bus BMS (250 kb/s). I assume it’s using VE.can to communicate with the cerbo (it shows up in devices and reports it’s voltage and field strength and such), and is listening for Can-Bus messages from a BMS. Which it’s not receiving because the BMS only exists in the Cerbos dbus. So I’d guess it’s expecting 11 bit can bus messages.
I see the cansend command works, is there some documentation on it? Googling or searching the venusos wiki turns up nothing.
As for cansend, just use some “wrong” parameters like cansend xyz 123 and the utility will show you its help.
For example: cansend can1 432#102030 will send on can1 bus (CAN-BMS port) a frame with id 432 and 3 bytes 10, 20 and 30. All values are in hex.
It’s a MK2, since I thought I might configure the other port for RV-C to do some other stuff.
I did find this sheet in a document for communicating with a “SMA/Victron compatible BMS via CAN bus”, which I think would be compatible. I believe the BMS messages have to be continually sent, not just when the dbus values update.
Interesting, I wonder if the blue values are what the lynx BMS adds. The Arco Zeus, another alternator regulator, apparently only works with the Lynx. Anyway the document I’m looking at also has this table, which might be enough to get this working.
It says it’s optional but I plan to send it since my BMS is reporting SOC down to the hundredth. Do you know how to format it for the skipped bytes, should I put in zeros for the odd bytes?
Don’t know how your device is expecting it, CAN rules says that the unused bytes up to 8 bytes of a frame to be padded with 0.
Below all the info that is exchanged on my BMS-CAN. The info repeats at 1 second interval. See the “non-standard” broadcasts.
It’s a Pylontech genuine comm.
The 305 and 307 are broadcasted by Cerbo and is used/needed for the BMS to detect the presence of an “inverter”.
307 has been dropped by Victron since several revisions.
Making progress, I’ll see if the wakespeed can read this tomorrow. It’s annoying in that it requires an ignition signal to turn on. So this is just from plugging the two ports on the cerbo together.
Well I’m stumped. The new BMS is on the network, it shows up in the cerbo device list with all the correct information, but neither regulator will recognize it. I
