Yesterday I found an issue after I updated my Cerbo GX MK2 from v3.54 to v3.79 (Normal image type). First off, here is the hardware I have connected in my RV system:
Gateway: Victron Cerbo GX MK2
Touchscreen: Victron GX Touch 50
Inverter, Charger, VE.Bus System: Victron MultiPlus-II 12/3000/120-50 2x120V
Solar Charter: Victron MPPT 150/85
Battery: Renogy REGO 400Ah RBT12400LFPLSHBT v0103
Smart circuit breaker controller: Made by Precisions Circuits
Prior to the upgrade, everything was working well with my system. I could see all of the equipment on the dashboard of the Cerbo GX. The update went fine, and the Cerbo GX was reporting the new version. However, was then getting an alert “#67 BMS connection lost” and another alert “Low battery voltage”. The GX overview screen did not appear to be reading the battery stats anymore. I tried rebooting the Cerbo GX, but it did not change. I then tried doing a full restart of all equipment by turning off and disconnecting the battery and solar power, waiting a minute, and then turning everything back on. It was still in the same state.
I noticed one other thing after the update. There are two VE.Can ports in use on the Cerbo GX - Port 1 and Port 2. Both are set up to use the RV-C (250 kbit/s) CAN-bus profile. Prior to this firmware update, there were 3 devices on port 1 at the following source addresses:
0x8F: Mystery device with unique ID 13275 (I think this may have been the battery)
0xE1: MultiPlus-II 12/3000/120-50 2x120V v556
0x24: SmartSolar MPPT VE.Can 150/85 rev2 v3.16
There were also 4 devices on port 2 at the following source addresses:
0x44: Smart circuit breaker controller by Precision Circuits
0xE1: MultiPlus-II 12/3000/120-50 2x120V v556
0x24: SmartSolar MPPT VE.Can 150/85 rev2 v3.16
0xA0: CAN-Bus BMS battery (the Renogy battery)
After the firmware update, all of the above were the same except on Port 1 address 0x8F was now identifying as RBT12400LFPL-SHBT by RENOGY, and Port 2 was now completely missing the BMS battery.
I found the topic Upgrade to 3.66 lost BMS on RV-C connected Renogy batteries - DIY - Victron Community and a few others which sound like the same issue. Is @Victron doing anything to address this issue? I’ve noticed a bug with v3.64 in which the Wi-Fi connection does not always correctly identify its state and/or the SSID it’s connected to, and I’d like to get that fixed (which may have been addressed in a recent update).
The newer one (1.11.00, in 3.75+) still sees the Renogy nodes — it’ll happily report manufacturer, model and serial — but it no longer creates that battery service. I believe it has a whitelist of certain validated RV-C battery manufacturers - does not include Renogy. No service created, no managed battery, hence #67 and the low-voltage alerts. I went from 3.54 to 3.75 and lost it the same way.
The source address changing from 0xA0 to 0x8F is ordinary RV-C address claiming — REGO nodes re-claim on power-up and the addresses shuffle around.
Victron’s stated position is that RV-C isn’t a supported battery interface, so I wouldn’t hold out for a fix from that direction.
So I wrote a small bridge that reads the REGO’s RV-C frames off can0 and republishes them as a proper Victron battery service, which restores managed battery and DVCC:
Please keep in mind:
Completely unofficial. Not a Victron product, not a Renogy product, no affiliation with either, and nobody supports it. No guarantees it’ll work for you.
I validated it on my own boat: three REGO RBT12400LFPL-SHBT in parallel, Cerbo on 3.75. You have a single battery on 3.79 — I’d expect both to be fine, but neither is a combination I’ve tested.
It’s receive-only on the CAN bus and never transmits, by design. Worst case is that it doesn’t work, not that it disturbs your bank.
The repo includes a read-only diagnostic, rvc-inventory.py, that just decodes what’s on your bus and prints it — no install, no writes. Running that first will tell you whether your battery is publishing the frames the bridge expects. If it looks right, the install is a couple of scripts.
Also worth checking your battery firmware — you mention v0103; another user on the earlier thread had v0104. Might be worth asking Renogy whether anything newer exists.
Happy to help if you try it and it misbehaves — post what rvc-inventory.py shows and I’ll take a look.
Hi @yarrumretep. Thank you for the reply! I’m new to working with the Victron equipment, but I got myself set up to try what you’ve done. I tried running rvc-inventory.py as you recommended, but it returns the following error:
dbus-rvc-renogy 0.4.18
Using Venus battery device instance 1
CAN open failed on can0: [Errno 19] No such device; retrying in 2 s
dbus-rvc-renogy 0.4.18 initialized on can0; waiting for aggregate data
CAN open failed on can0: [Errno 19] No such device; retrying in 4 s
CAN open failed on can0: [Errno 19] No such device; retrying in 8 s
My system is using both VE.Can ports (not sure exactly why it was set up this way) using the RV-C profile for both. Here’s how it shows up from the Cerbo console:
It looks like rvc-inventory.py is listening on can0. Is that VE.Can Port 1? Do I need to be listening on can1 instead? And, is there a way to switch that in the python script?
Hoping you can nudge me in the right direction. I’m interested in trying your fix.
Hi! That error means there’s no interface named can0 on your Cerbo.
On that the Mk2, VE.Can port 1 is vecan0 and port 2 is vecan1. The original Cerbo uses different names, which explains the confusion. Victron’s port mapping
First, run this in the Cerbo’s SSH terminal to confirm the available interface names:
ip link show
You can select the interface without editing Python. Assuming those names appear, try:
The inventory tool only listens; it doesn’t transmit CAN messages or change charging settings. Leave off any --sa filter initially so we can see all the devices on your system.
One detail: the output you pasted is from dbus-rvc-renogy.py, the actual battery bridge. Could you include the exact command you run with the output? If running the inventory command above produces that same bridge banner, we should check that the correct file was downloaded.
Let’s confirm the correct bus and battery compatibility before starting the bridge, because it can become the active BMS and influence charging. Bridge configuration
Please send the inventory output and I’d be happy to take a look.
Hi @yarrumretep. Thanks again for the reply! You were correct, my battery was on vecan0, not can0. I ended up working through the installation with the assistance of Chat-GPT as I had a few errors when I tried running deploy.sh. There were a few files that had Windows \r\n line endings that needed to be converted to only have \n line endings. Not sure exactly why I had this issue, but once the various files were converted, everything deployed correctly.
So, I now have the dbus-rvc-renogy service persistently installed and running with Cerbo GX v3.79. It’s working great! Thank you so much for not only developing this service, but also for sharing it and helping users like me who are new to doing these types of changes through the process!
For other less experienced users, like me, I’ll throw a recommendation to work through this with Chat-GPT. It was scary-impressive how it navigated through the installation, going step-by-step through the process and verifying each step before moving to the next.
That’s great to hear—and thanks for reporting back! Glad you’ve got it running, and it’s useful to have a successful report on Venus OS 3.79.
Thanks also for flagging the line-ending issue. The repository files I checked use Unix line endings througout, so I’m not sure where the conversion happened. If you still have notes on how you downloaded the files and which ones needed converting, those would help me improve the installation instructions.
Appreciate you sticking with it and sharing the results!
I think I may have pulled them into a folder on my Windows PC using the git pull command from PowerShell. I’m guessing Windows did the conversion then.
One other thing I learned since my last post was that the logger data which is visualized on the VRM Advanced page now shows up in widgets under the device Battery Monitor [2]. It threw me for a loop at first when I went in to look at the charts, and there was no data since the firmware update to v3.79. But, when I clicked on the Widgets button, I saw that there were now two battery devices showing in the list. I enabled the widgets for Battery Monitor [2], and all the data was there. So, just an awareness for others.
