# Battery name correct on older Cerbo units, incorrect on new Cerbo units **URL:** \ **Category:** Q&A and troubleshooting\ **Tags:** gx\_device, cerbo\_gx, offgrid\ **Created:** [9 May 2025 05:03 UTC](https://community.victronenergy.com/t/battery-name-correct-on-older-cerbo-units-incorrect-on-new-cerbo-units/31622 "2025-05-09T05:03:51Z")\ **Posts on this page:** 18\ **Page:** 1
**Author:** ![Gareth\_Thomas](https://avatars.discourse-cdn.com/v4/letter/g/46a35a/32.png) [@Gareth\_Thomas](https://community.victronenergy.com/u/Gareth_Thomas)\ **Post date:** [9 May 2025 05:03 UTC](https://community.victronenergy.com/t/battery-name-correct-on-older-cerbo-units-incorrect-on-new-cerbo-units/31622/1 "2025-05-09T05:03:51Z")
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? ---
**Author:** ![nickdb](https://dub1.discourse-cdn.com/victron/user_avatar/community.victronenergy.com/nickdb/32/51440_2.png) [@nickdb](https://community.victronenergy.com/u/nickdb)\ **Post date:** [9 May 2025 06:05 UTC](https://community.victronenergy.com/t/battery-name-correct-on-older-cerbo-units-incorrect-on-new-cerbo-units/31622/2 "2025-05-09T06:05:09Z")
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. ---
**Author:** ![Gareth\_Thomas](https://avatars.discourse-cdn.com/v4/letter/g/46a35a/32.png) [@Gareth\_Thomas](https://community.victronenergy.com/u/Gareth_Thomas)\ **Post date:** [9 May 2025 07:27 UTC](https://community.victronenergy.com/t/battery-name-correct-on-older-cerbo-units-incorrect-on-new-cerbo-units/31622/3 "2025-05-09T07:27:39Z")
Thanks for the quick reply. I’ve updated the firmware to the beta version on multiple devices, power cycled, redetected the battery etc. No change. ---
**Author:** ![nickdb](https://dub1.discourse-cdn.com/victron/user_avatar/community.victronenergy.com/nickdb/32/51440_2.png) [@nickdb](https://community.victronenergy.com/u/nickdb)\ **Post date:** [9 May 2025 07:37 UTC](https://community.victronenergy.com/t/battery-name-correct-on-older-cerbo-units-incorrect-on-new-cerbo-units/31622/4 "2025-05-09T07:37:47Z")
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. Maybe someone else has some insight for you. ---
**Author:** ![Gareth\_Thomas](https://avatars.discourse-cdn.com/v4/letter/g/46a35a/32.png) [@Gareth\_Thomas](https://community.victronenergy.com/u/Gareth_Thomas)\ **Post date:** [9 May 2025 23:09 UTC](https://community.victronenergy.com/t/battery-name-correct-on-older-cerbo-units-incorrect-on-new-cerbo-units/31622/5 "2025-05-09T23:09:34Z")
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? ---
**Author:** ![nickdb](https://dub1.discourse-cdn.com/victron/user_avatar/community.victronenergy.com/nickdb/32/51440_2.png) [@nickdb](https://community.victronenergy.com/u/nickdb)\ **Post date:** [11 May 2025 19:09 UTC](https://community.victronenergy.com/t/battery-name-correct-on-older-cerbo-units-incorrect-on-new-cerbo-units/31622/6 "2025-05-11T19:09:40Z")
Indeed Discover was added not that long ago. The requirements are documented here: > **[Victron Energy and Discover AES Rackmount Batteries \[Victron Energy\]](https://www.victronenergy.com/live/battery_compatibility:discover)** It also isn’t supported to connect a bms to two different GX’s. ---
**Author:** ![RoarPowerNZ](https://avatars.discourse-cdn.com/v4/letter/r/8c91f0/32.png) [@RoarPowerNZ](https://community.victronenergy.com/u/RoarPowerNZ)\ **Post date:** [28 May 2025 21:26 UTC](https://community.victronenergy.com/t/battery-name-correct-on-older-cerbo-units-incorrect-on-new-cerbo-units/31622/7 "2025-05-28T21:26:48Z")
> [@Gareth\_Thomas](#): > > Both Cerbo devices will be receiving the same CANBus frame as each other, 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; ```auto root@nanopi:~# candump -n40 -e -x -a can0 can0 TX B E 305 [8] 00 00 00 00 00 00 00 00 '........' can0 TX B E 307 [8] 12 34 56 78 56 49 43 00 '.4VxVIC.' can0 RX - - 311 [8] 02 40 00 00 03 E8 04 29 '.@.....)' can0 RX - - 312 [8] 00 00 00 00 01 00 00 10 '........' can0 RX - - 313 [8] 14 DE 00 00 01 0E 64 64 '......dd' can0 RX - - 314 [8] 27 0D 27 10 00 07 00 01 ''.'.....' can0 RX - - 319 [8] C0 0D 10 0D 09 0C 08 10 '........' can0 RX - - 320 [8] 00 00 00 00 64 62 BA 25 '....db.%' can0 RX - - 311 [8] 02 40 00 00 03 E8 04 29 '.@.....)' can0 RX - - 312 [8] 00 00 00 00 01 00 00 10 '........' can0 RX - - 313 [8] 14 DE 00 00 01 0E 64 64 '......dd' can0 RX - - 314 [8] 27 0D 27 10 00 07 00 01 ''.'.....' ``` , 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. ---
**Author:** ![Gareth\_Thomas](https://avatars.discourse-cdn.com/v4/letter/g/46a35a/32.png) [@Gareth\_Thomas](https://community.victronenergy.com/u/Gareth_Thomas)\ **Post date:** [28 May 2025 22:57 UTC](https://community.victronenergy.com/t/battery-name-correct-on-older-cerbo-units-incorrect-on-new-cerbo-units/31622/8 "2025-05-28T22:57:20Z")
Fantastic! I’ll try that tomorrow! ---
**Author:** ![nickdb](https://dub1.discourse-cdn.com/victron/user_avatar/community.victronenergy.com/nickdb/32/51440_2.png) [@nickdb](https://community.victronenergy.com/u/nickdb)\ **Post date:** [29 May 2025 06:03 UTC](https://community.victronenergy.com/t/battery-name-correct-on-older-cerbo-units-incorrect-on-new-cerbo-units/31622/9 "2025-05-29T06:03:47Z")
> [@RoarPowerNZ](#): > > 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. ---
**Author:** ![RoarPowerNZ](https://avatars.discourse-cdn.com/v4/letter/r/8c91f0/32.png) [@RoarPowerNZ](https://community.victronenergy.com/u/RoarPowerNZ)\ **Post date:** [29 May 2025 20:31 UTC](https://community.victronenergy.com/t/battery-name-correct-on-older-cerbo-units-incorrect-on-new-cerbo-units/31622/10 "2025-05-29T20:31:03Z")
That’s not quite correct. 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 > can0 TX B E 305 [8] 00 00 00 00 00 00 00 00 ‘…’ > can0 TX B E 307 [8] 12 34 56 78 56 49 43 00 ‘.4VxVIC.’ > can0 RX - - 375 [8] 30 34 00 00 30 30 30 30 ‘04..0000’ > can0 RX - - 376 [8] 30 31 00 00 30 30 30 30 ‘01..0000’ > can0 RX - - 377 [8] 30 31 00 00 30 30 30 30 ‘01..0000’ > can0 RX - - 378 [8] 00 00 00 00 00 00 00 00 ‘…’ > can0 RX - - 379 [8] 10 27 00 00 FF 25 00 00 ‘.’…%..’ > can0 RX - - 380 [8] 30 4A 48 50 42 59 38 45 ‘0JHPBY8E’ > can0 RX - - 381 [8] 32 52 30 30 51 30 30 30 ‘2R00Q000’ This is quite different to RS485, which has a more query-\>answer format, but both are still bi-directional. ---
**Author:** ![Gareth\_Thomas](https://avatars.discourse-cdn.com/v4/letter/g/46a35a/32.png) [@Gareth\_Thomas](https://community.victronenergy.com/u/Gareth_Thomas)\ **Post date:** [2 June 2025 02:56 UTC](https://community.victronenergy.com/t/battery-name-correct-on-older-cerbo-units-incorrect-on-new-cerbo-units/31622/11 "2025-06-02T02:56:36Z")
> [@RoarPowerNZ](#): > > diff -y results1 results2|more Ran the comparison, they seem to be identical. The only difference is the Can port used on the device, BMSCan on one Cerbo and the VE.Can port on the Cerbo-S ![image](https://europe1.discourse-cdn.com/victron/original/3X/8/e/8e8b3d798b656d89392d00a8c836f40783da6e99.png) I think the answer must lie in the lookup table described here: > I managed to run the octal dump vecan-dbus but it didn’t seem to have the register numbers associated. The od command also doesn’t like the width control (-w) ---
**Author:** ![nickdb](https://dub1.discourse-cdn.com/victron/user_avatar/community.victronenergy.com/nickdb/32/51440_2.png) [@nickdb](https://community.victronenergy.com/u/nickdb)\ **Post date:** [2 June 2025 11:50 UTC](https://community.victronenergy.com/t/battery-name-correct-on-older-cerbo-units-incorrect-on-new-cerbo-units/31622/12 "2025-06-02T11:50:16Z")
Independent broadcasts and bi-directional comms are not the same thing. The GX has some victron only capabilities, but while it is announcing itself, it is by no means sending instructions to the third party BMS. Hence why many batteries need to be preset to use the Victron spec Perhaps, read-only is a better term as the GX will never control the BMS, it is controlled by the BMS broadcasts. The exception that I recall is a newly added battery that can be firmware updated via CAN iirc. ---
**Author:** ![nickdb](https://dub1.discourse-cdn.com/victron/user_avatar/community.victronenergy.com/nickdb/32/51440_2.png) [@nickdb](https://community.victronenergy.com/u/nickdb)\ **Post date:** [2 June 2025 11:51 UTC](https://community.victronenergy.com/t/battery-name-correct-on-older-cerbo-units-incorrect-on-new-cerbo-units/31622/13 "2025-06-02T11:51:54Z")
> [@Gareth\_Thomas](#): > > The only difference is the Can port used on the device, BMSCan on one Cerbo and the VE.Can port on the Cerbo-S And this port has been configured to use the BMS profile and baud rate? ---
**Author:** ![Gareth\_Thomas](https://avatars.discourse-cdn.com/v4/letter/g/46a35a/32.png) [@Gareth\_Thomas](https://community.victronenergy.com/u/Gareth_Thomas)\ **Post date:** [3 June 2025 00:37 UTC](https://community.victronenergy.com/t/battery-name-correct-on-older-cerbo-units-incorrect-on-new-cerbo-units/31622/14 "2025-06-03T00:37:15Z")
Yes, all ports are set to Canbus BMS 500. If they are not they will not communicate at all with the Cerbo. ---
**Author:** ![wandreis](https://avatars.discourse-cdn.com/v4/letter/w/848f3c/32.png) [@wandreis](https://community.victronenergy.com/u/wandreis)\ **Post date:** [20 June 2025 21:48 UTC](https://community.victronenergy.com/t/battery-name-correct-on-older-cerbo-units-incorrect-on-new-cerbo-units/31622/15 "2025-06-20T21:48:00Z")
@RoarPowerNZ I’m wondering if I can use this technique to find a solution for a different issue… I’ve 6 x DEYE SG5.3 Li Batteries connected to my VE CAN, and being recognized as LG Resu batteries as well… all the batteries parameters (CVL, CCL, DCL) are correct, but the current is inverted… it shows the opposite Amps… charging when it’s discharging, and vice versa… maybe dumping the CAN info could help isolating the issue if I realize that this is a BMS thing other than config? ---
**Author:** ![RoarPowerNZ](https://avatars.discourse-cdn.com/v4/letter/r/8c91f0/32.png) [@RoarPowerNZ](https://community.victronenergy.com/u/RoarPowerNZ)\ **Post date:** [22 June 2025 19:08 UTC](https://community.victronenergy.com/t/battery-name-correct-on-older-cerbo-units-incorrect-on-new-cerbo-units/31622/16 "2025-06-22T19:08:26Z")
So far, all debugging suggests that the inverted current sign is a decision the BMS authors have made, and i haven’t seen a BMS yet that allows inverting the sign as a setting, so the best solution is arguably a BMS firmware update. ---
**Author:** ![Gareth\_Thomas](https://avatars.discourse-cdn.com/v4/letter/g/46a35a/32.png) [@Gareth\_Thomas](https://community.victronenergy.com/u/Gareth_Thomas)\ **Post date:** [22 June 2025 23:17 UTC](https://community.victronenergy.com/t/battery-name-correct-on-older-cerbo-units-incorrect-on-new-cerbo-units/31622/17 "2025-06-22T23:17:03Z")
I have used a CANBus USB device like this in parallel with the CANBus from the battery to the Cerbo: > **[USB to CAN Adapter Model A, STM32 Chip Solution, Multiple Working modes,...](https://core-electronics.com.au/usb-to-can-adapter-model-a-stm32-chip-solution-multiple-working-modes-multi-system-compatible.html)** > > USB to CAN Adapter Model A, STM32 Chip Solution, Multiple Working modes, Multi-system Compatible... This will allow you to sniff the canbus data easily, then you just need to translate the hexadecimal code, which isn’t difficult. I think I used SavvyCan to interact with the USB interface. I think it is unlikely that the Cerbo is transforming a value from positive to negative. More likely to be a BMS issue. ---
**Author:** ![Northy](https://avatars.discourse-cdn.com/v4/letter/n/58f4c7/32.png) [@Northy](https://community.victronenergy.com/u/Northy)\ **Post date:** [5 April 2026 15:46 UTC](https://community.victronenergy.com/t/battery-name-correct-on-older-cerbo-units-incorrect-on-new-cerbo-units/31622/18 "2026-04-05T15:46:51Z")
@wandreis Hi, in case you still have this issue: I created a github repository to fix this: [GitHub - NorthyIE/victron-virtualbattery-inverted · GitHub](https://github.com/NorthyIE/victron-virtualbattery-inverted) however I only have a single battery (Deye RW-F16) so far, I have not tested it with a multi battery setup. Feel free to try it out and if you have any issues let me know so I can fix it 🙂