It’s no secret that I love Victron’s control ecosystem. On my last three boats, I’ve had Victron bits that have helped provide visibility into the power system. Earlier this year, I finished the conversion on Rendezvous to a mostly-Victron system which I wrote about in Victron + Wakespeed + Battle Born power system.
Thanks so much for this article. I am finally back to work on the Maretron system on MÖBIUS, and I have been at it for several days trying to get the Victron Cerbo to play nice with my N2K network. Your comments in the Victron Community about possibly having a bad cable sent me to considering other troubleshooting issues, and I switched my cable to the other VE can port and voila! Bad cables, bad ports. After that I got the OctoGX online too. But now with 14 MPPT Smart Solar controllers, 3 BVM712s, 5 Multiplus Inverter chargers, I have a huge long list of Instancing issues. Many of these seem to disregard the device instance and data instance which I can change in N2K Analyzer. Is this what you were referring to when you wrote, “Unfortunately, there’s no way I’ve found to configure instance IDs, so this battery status PGN conflicts with the one being sent by the BMV.” I have lots of conflicting battery status instances, and yet when I try to create an element on in screen in N2KView, it doesn’t find anything. Any suggestions as to how to make this mess work?
You’ve found one of the achilles heels of how Victron implemented things. My last boat had three conflicting battery PGNs on the N2K network from their equipment, and using N2KView from Maretron was almost impossible as a result. Several other folks I know are struggling with this same challenge.
I would urge you to open conversations with Victron, as many of us have, and see if they will consider fixing their broken implementation, or at least honoring the way it works through instancing so we could use things.
I’m building my new system on Kaos and will have 6 shunts, 2 inverters, a passel of DC-DC chargers, and a handful of solar controllers, and I expect they will all dump the wrong info onto the network as well.
I know one way I was able to get around this was to use SignalK to grab the Victron data directly from the GX product and put it on the N2K network in a more organized fashion. I need to revisit how I did this and will be doing so shortly.
Thank you so much for this reply. I’ve been looking at this for days and trying to understand what was going on. There are several things that cause our system design to be overly complicated, but these are not unheard of circumstances for today’s vessels. First, we wanted to be a “world boat,” so we while we are basically 240V, we also have 110V. Victron does not recommend attaching two strings of different Multiplus inverters to the same GX device, hence we have both a Cerbo (for 240V) and an Octo GX (for 110V) on our network. Then we have our twenty-four 4V Firefly batteries divided into four subgroups of 6 batteries each. We have 3 BMVs - One for group 1 + 2 which we call bank 1 and the other for bank 2, and the third for both banks combined or our total House Battery capacity. And then we have 14 individual MPPT controllers for each of our solar panels connected to the Cerbo. Thus, can you imagine how many devices were sending out Battery status PGN’s?
This meant when we accessed the VRM, we had two installations, one for the Cerbo and one for the Octo, and everything was neatly separated. We had to switch from one to other to get the whole picture, but that was fine.
What surprised me most was how much information the Victron devices took back off the network when I connected them to N2K. While we were not using the tank or temperature connections on the Cerbo, once connected to N2K, suddenly some of our Maretron tank and temperature sensors appeared as Victron connections in the VRM. Both the Octo and the Cerbo suddenly showed not three, but six BMV’s. I knew this was all related to the instancing, so I tried to find info on Victron’s site.
The two main places I found info was in their section on MFD integration and here on Changing N2K Instances. I am loath to follow any of these instructions for changing instances, since they start off with a warning that they advise you NOT to do this or you might inhibit the Victron devices from talking to each other.
I really appreciate all the information you share on your site, and I will definitely take you up on a couple of your suggestions here. I will both contact Victron about this, and I will start tinkering with the Raspberry Pi we bought recently so perhaps we can use that as a method to sort all this out. Fortunately, you have blogs to teach me about the Pi and SignalK, so I will have plenty to keep me busy while waiting for your SignalK/Victron post.
I’ve seen all of these issues as well unfortunately. The tank thing is particularly irritating.
As I mentioned, I’ve considered not connecting the Victron equipment to my existing NMEA 2000 network and just using SignalK to connect via TCP / ethernet. It could then put specific info back on NMEA 2000 so that N2Kview could process it and alert on it, or alternatively, use other parts of SignalK, Grafana, or the like to provide alerting and monitoring.
There are still some limitations in that approach, but I haven’t found them all yet. Hopefully in the next month that will happen as components are installed and shipments arrive!
