i have done every conceivable update that is released, even tried rolling OS back and still get the error. Have also installed the OS Large. The new update appears to clear the error alarm but still logs a fault. Have changed battery and also changed BMS cable. Am using genuine Victron BMS to CAN cable. Will also be trying this with PYTES batteries to see if fault continues.
UPDATED 2025-01-10 - due to Venus OS v3.53 release which fixes this issue in most cases.
Hi All,
Apologies for the long delay in responding to this.
Anyone who is experiencing this issue with the VE.Can 2 port on the Cerbo GX MK2 should: get in touch with their dealer for an RMA warranty.
- Update to Venus OS v3.53 (officially released earlier this week, announcement).
- Only if that doesn’t fix the issue, contact your dealer for further troubleshooting and if necessary RMA a unit. Venus OS v3.53 fixes the VE.Can port 2 issue for most Cerbo MK2s, but we’ve seen some of them where there really is a hardware issue and RMA is the only solution.
One other thing, if you are not using the other port, VE.Can 1, then moving to that one will also resolve it.
3 Likes
Hi @guystewart
So it’s a defect caused by the update?
Or what is the reason for it?
I’m a bit unsure whether I should do the update…
Thanks for clarification
UPDATED 2025-01-10 - due to Venus OS v3.53 release which fixes this issue in most cases.
On a systems having this issue:
- Check if VE.Can Port 1 is in use as well. Our VRM stats show that often its not. In case not, replug and reconfigure the GX to work on VE.Can 1 port instead.
- If both ports are needed, update to Venus OS v3.53 or later (announcement), which will in most cases fix the issue.
- Only if that doesn’t fix the issue, contact your dealer for further troubleshooting and if necessary replace that Cerbo MK2 (under warranty). Venus OS v3.53 fixes the VE.Can port 2 issue for most Cerbo MK2s, but we’ve seen some of them where there really is a hardware issue and RMA is the only solution.
3 Likes
I have found using Cerbo MK2 straight out of the box and not updating to have resolved mine and my customers issue.
Thank you Guy!
Hi Matthijs.
Thank you for the detailed explanation.
If only the MK2 is affected, it should not affect my Cerbo’s. Then I’ll give the update a chance 
However, the “old” version has also been mentioned here with problems.
Many thanks, Christian
I have updated my above reply with the last findings:
- we’ve made very promising fix in software; which is expected to fix the issue for most systems.
- running gui-v2 aggrevates the issue a lot. Hence, as a quick work around we advice to switch back to gui-v1 for now in case this happens in a system.
Meanwhile we’re working very hard to get this fixed asap.
@mpvader so far, the working solution to the problem is to switch communication from BMS (Pylontech) to the VE.Can 1 port, on firmware 3.52. The temporary solution works for all 6 customers who experienced the new problem on the new UI. Just to confirm Your previous suggestions in this topic.
Regards
ENERP TEAM
[image]
2 Likes
For our client situation it’s not working using old UI workaround.
The Cerbo is not using a Touch so we can access it via VRM by new or old UI.
Please explain if that “also” impacts or if its only the UI setting selected in the Cerbo itself for the purpose of the Touch50/70.
After a reboot the Can.bus LV BMS 500kb/s is reporting STOPPED.
A reboot does not automatically start the Can.bus connecting the BMS.
I need to select disabled and then the Can.bus profile but it shoots in to ERROR immediately.
Sometimes sending 3 sometimes a bit more packets.
When we installed this Cerbo a new it did 9000 RX packets before going into STOPPED state.
@mpvader : We are using the Victron Energy meters on Can.bus 1. Would it be an option to switch them around as that is running on 250kb/s ? So put the Pylontech BMS on Can 1 and the Victron metering on Can 2. ( with their respective correct CAN profiles off course ).
1 Like
This topic was automatically closed 14 days after the last reply. New replies are no longer allowed.
Hi all, last week we released Venus OS v3.53 that fixes the Cerbo MK2 VE.Can port 2 issue for (almost) all systems that we analysed via VRM.
See my above answer that is marked as the solution for our new recommendation on how to troubleshoot and solve systems that have issues with that port,
Commonly visible as an MPPT or other component in the system reporting an Error 67 no BMS.
Have a good weekend
1 Like
Hi Edwin, apologies for the late reply - though I think we had contact over the phone elsewhere since your above message.
You could try swapping, and it would be great if that works. But I expect it wont and then the solution is to replace that Cerbo with a new one.
Yes we did have contact by phone, and we can close this now.
For the readers: we replaced the Cerbo as this was one of the outlier MK2 with a hardware issue. Installed lots of Cerbo MK2’s since then, with no issues. I guess just bad luck.
2 Likes
Hi Matthijs,
the issue just appeared in my setup yesterday although I installed v3.54 some time back.
For tests the system was used and the Pylontech BMS was working well. During the final approval by the local electrical guy, I needed to switch off all components for demo of grid failure, backup via battery, bit also I had to show him how to switch of the batteries.
Since the start up of the system Cerbo-gx is not able to detect the battery BMS, either on the BMS ports nor the VE Can ports with settings changed to 500 bits of data rate.
Besides that, the Pylontech batteries do not show anymore the LED lights.
I have restarted all components several times without any success. Only thing that now works is to use the multiplus as a battery monitor, but the the Pylontech BMS anymore.
Any ideas what I can do or test to bring the Pylontech BMS up again within the Cerbo-gx?
Best regards
Tobias
Hi,
I can see, that power switches are on position, but did you also remember push the red SW push button few sec of the master battery?
1 Like
I think this has nothing to do with the Cerbo or its firmware.
Try disconnecting the batteries completely (DC cables) and then the batteries must start. If not, they are faulty/damaged.
When starting the system from zero, always pre-charge the capacitors in the system (Multiplus, MPPTs…). Otherwise the surge can damage the batteries.
Hello,
the dip-switches have the same position:
I guess this is not right.
Have Fun
Marc