There was an insignificant amount of AC loads at the time this happened. The only error i got was an error #67 BMS connection lost. After rebooting the Cerbo GX i got my MPPT back, as well after manually switching Quattro off and then back on I got the Quattro back. There doesn’t seem to be any clues under the advanced tab so far as I can tell..?
We have been using this setup for over two years now without many issues. My major concern is the fridge while we are away if this happens again..
What batteries are you using? Several battery manufacturers have been bitten by a dbus change in recent VenusOS updates. Basically the Cerbo gets overloaded and can’t respond quickly enough and the devices “lose” their connection to the BMS briefly. We had an issue with one of our battery suppliers and they identified the issue and issued a fix within a week. In fact, I’m going in to the shop this morning to update their virtual battery driver to solve this issue for a customer’s RV we recently worked on.
Contact your battery manufacturer and see if they have a solution for you.
Hey Ed thank you for the reply! My GX is at version 3.60~25. It’s been modded with GUI mods and has the dbus-serial battery driver installed which i am using for communication through a serial cable to my JK PB model BMS. For what it’s worth I have the Large OS installed and have Node-RED running as well.
Oddly enough dbus did spike at the exact time the Quattro went offline although I’ve seen spikes higher that this in the past and never had the Quattro power down as a result.
DVCC is turned off but I had battery monitor set to automatic. I am changing this to Smart Shunt.. perhaps this setting caused a shut down for lost communication to BMS?
I have a suspicion that Victron will have to release a Cerbo MKIII for more CPU power. It has half the CPU cores of the Ekrano though I don’t know how they differ in interrupt handling and throughput. I’d also bet more than one person inside Victron has said "I wish we would have updated the MKII with the Ekrano CPU
I’m curious, is GuiMods still needed with the new V2 GUI?
If you’re not using DVCC or the JK battery monitor, I would disconnect the comms completely.
I checked the changelog for GuiMods and I don’t see a lot of activity. I would suggest that if you don’t know if you need GuiMods then you probably don’t need GuiMods
Try removing GuiMods and if you don’t need any of the other add-ons, then remove SetupHelper too. Then update VenusOS to the 3.60 released version or 3.62~1 if you’re more adventuresome.
Truthfully, I don’t know if this will reduce your issues or not. But, it gets you updated to the latest official release and removes some potentially unnecessary mods. You also mentioned using the dbus-serial driver with your BMS. Do you need that? Why not use CANbus for communications instead?
Are you using NodeRed with some flows, or do you just have it enabled? If you’re not actively using it, turn it off and see what happens.
@mpvader Do you have any more concrete advice for Rodney?
I SSHed into the GX using the top command to check CPU load and I’m not sure how overloaded it looks but I can see that Node-RED chews up a bit of resources.
@Ed@OGPS Yeah I’ll figure out how to remove Setup Helper/GuiMods. As well, update to latest real official firmware on the GX.
I’ve also considered the thought of removing dbus serial-battery but would only do this as a last resort. I haven’t seen anyone else comment on Github with the issues I’m having and feel I can solve this issue without removal.
I am using Node-RED with a flow that enables me to monitor very granular, historical cell voltages remotely that would also be hard to live without.
@mpvader I will follow your advice. What do you mean by update the mods? Were you referring to dbus serial-battery and GUI Mods?
The JK PB BMS shows up in device list, and continuously seems to function properly in remote console but i do get a lot of error #67 with MPPT and yet another power down about an hour or two ago.
It seems that if i unplug the VE. Bus cable from GX to Quattro, the Quattro powers off ~4 minutes after a disconnect. Is there a way to modify this behavior?
Also Quattro is running at version 4.90, quite old now but I have concerns about breaking something else by updating it.
Thanks again. I’ll get busy on cleaning up the GX asap
Your JK BMS should report cell voltages if connected via CANbus, but I don’t know if it’s to the level you want. In VRM you can export data as a CSV file and then import that into Excel or another tool to manipulate the data. In other words, can you find a lighter touch on the Cerbo to reduce the processing overhead by using more efficient means?
I just tried downloading cell voltage data from the Victron system that powers our business. It doesn’t report the voltage of every cell in every battery (that would be 160 cells for this system) but it does report the highest and lowest cell voltages. For this system the deviation is no more than 10mV so I don’t care for more detailed information. If I saw the max deviation be 100mV then I’d want to dig in deeper to diagnose the issue with another tool. In the end, I’m just suggesting to simplify down to what you really need. The Cerbo is not a supercomputer It is a communication hub that Victron would like to add more and more services to while not overwhelming the capabilities of the hardware.
Hi @NorthTown2022 , I think its best is to contact the provider of that mod of that battery. Perhaps he can help.
And meanwhile, for a more stable system, you could disable DVCC; thereafter power cycle your inverter (or use the reset feature in the menu).
Once having done that the Quattro inverter will just operate as per its configuration that you did in VEConfigure / VictronConnect wrt charge voltages & low voltage shutdown parameters.
And won’t shut down in case for some reason the GX or the mod in it is having issues sending the DVCC data in a proper update rate.
dbus round trip time spiked to 124ms this time.