I have a strange phenomena happening with some brand new Cerbo MK-II devices.
When paired with a Discover Helios battery, connected over CANbus, the Cerbo will recognise the battery as “LG Resu battery”, with a product ID of B0004.
When paired with an older Cerbo MK-II, or an older Cerbo-S, the battery is displayed as “Discover AES battery”, with a product ID of B016.
This even happens if I daisy chain the CANbus of the Cerbo-S and the Cerbo-MK II devices together , so they are both connected to the battery at the same time. Both have the same firmware version, 3.55
The MK-II Cerbo’s I have seen that display “LG resu battery” have serial numbers that start with
HQ244.
The MK-II Cerbo that displayed “Discover AES battery” had a serial number starting with:
HQ233
The Helios battery battery does not broadcast it’s own name, the name is derived from a lookup table on the Cerbo, which can be found here:
The codes in this table are:
45060 LG resu battery (0xB004)
45078 Discover AES battery (0xB016)
I’m wondering if the HQ244 Cerbo’s may have a the wrong table, which isn’t corrected by a firmware update?
There are some known issues with mk2’s which are already documented on this forum.
Try the latest beta on one of these systems, let us know if that resolves the issue.
Some fixes were applied in the current prod version, so you need to be current, but iirc additional are in the beta.
The code is common across all devices, there are only some hardware variations.
What you could do is load the large image, add socketcan to nodered and monitor what is being sent from the BMS, it may help narrow it down.
If the battery is not on the supported list and spoofs another, errors can happen and it can also be firmware issues on the BMS that aren’t tested.
We saw issues with batteries spoofing pylontech for example.
As a community team we can’t really escalate issues for batteries that aren’t on the list.
The battery is definitely on the list: B016 is the correct code.
The battery is currently connected to TWO Cerbo devices at once. One shows it as a LG Resu battery, the other as a Discover battery.
Both Cerbo devices will be receiving the same CANBus frame as each other, it must that either one unit has a different lookup table, or that one unit is somehow corrupting the frame when it reads it?
You can’t be sure of that if the BMS is implementing some kind of spoofing, but you can prove it with binary troubleshooting;
Enable ssh on both cerbo.
ssh to cerbo #1, run candump -e -n60 -x -a any
ssh to cerbo #2, run candump -e -n60 -x -a any
copy/pasta each result into a file on your machine, trim the top of each result until each one starts with the 305 message from the cerbo;
, then diff the two;
diff -y results1 results2|more
If you get the exact same conversation, then its proven that the two cerbo are acting differently. If you get differences, then the BMS is answering each cerbo differently.
Comms are uni-directional. The GX does not query the BMS, it listens for CAN broadcasts and processes it accordingly.
How they process (or don’t) messages may differ if there is a bug, like has been fixed on the MK2 recently, though that was a different issue resulting in the BMS being lost, even though it was connected and correctly identified.
The conversation is bi-directional - as proved by the TX and RX messages in a CAN conversation.
Its true that most messages are in one direction (from the BMS to the GX), but the GX (according to the spec AFAIK) must announce it is there. Whether you consider this a query or not is semantics, but those 305/307 messages must occur. If you block those messages, some batteries go to sleep after a period of not seeing a 305/307
You can see in this CAN conversation, the 305 and 307 messages are the GX announcing that its a Victron inverter (“4VxVIC”), and then it receives the next 7 messages from the BMS