I install and service marine electrical and electronic systems in San Diego. Have been in the industry for 35 years and work closely with Jim Dixon here.
On larger yachts, getting VE.Direct devices connected to a nav station or helm mounted GX display can often be difficult due to the longer cables required on larger yachts. Orion XS DC-DC chargers near an engine or alternator, and SmartShunts on a remote bank can be 10–20 m of cable away. VE.Direct and USB can de troublesome at those lengths
A Nucleo or other GX at the remote location can handle the devices locally. But as far as I can tell, two GX devices can’t share data. The remote devices end up in a separate system, separate from the master Cerbo or Ekrano and its DVCC, system overview, and VRM installation.
Why the current options fall short
VE.Can versions of the devices. These solve it for the larger MPPTs, but many VE.Direct products have no VE.Can version, including the Orion XS, SmartShunt, and smaller SmartSolars.
Two separate systems. The master’s DVCC can’t control the remote chargers, the overview is incomplete, and the owner sees two VRM installations.
Workarounds. Today’s choices are USB-over-Cat6 extenders, RS-422 serial extension, or custom serial-over-IP and D-Bus/MQTT bridges. They can be made to work, but none of them is supported, and some don’t survive firmware updates.
Requested feature
A gateway or satellite mode for a GX device. A remote GX would forward its locally connected VE.Direct devices to a master GX, so they appear on the master exactly as if they were connected directly. The link could be VE.Can, which is already Victron’s long-distance bus, or Ethernet.
Ideally the bridged devices would:
show up on the master as native devices, with stable device instances,
take part in the master’s DVCC, including charge voltage and current limits and BMS control,
open through remote VictronConnect via VRM, as directly connected devices do,
report under a single VRM installation, with the remote GX either hidden or shown as a sub-device,
behave predictably if the link is lost, for example by falling back to each device’s own settings in the same way they handle a DVCC timeout today.
Why this matters
Victron already makes every piece of this system: the devices, the GX hardware, VE.Can, and Venus OS. A native bridge would remove the need for third-party hardware and unsupported modifications on exactly the larger, more complex systems where installers most want a clean, supportable design.
Thanks for considering it. I’m happy to provide more detail or test a beta.
Thanks for the feature request, not the first one either.I have passed this on.
We have just seen the arrival of bluetooth bridging via Shelly for sensor devices, which is helpful (use it myself). The marine use case and installation challenges could certainly benefit from a bridge device, imagine others would as well.
The issue with that is it won’t integrate with DVCC.
I’m told NMEA 2000 out is also supported for this, but unlikely to work with DVCC either.
You can use ducktape to build systems like these but they won’t always work with the integrated features. Also, while fine for a DIY project, you may not like that approach as a professional boat-builder.
For a lot of set ups where they’re is 2 GX devices but the need for a cohesive system node red,mqtt and other stuff can be added for information sharing etc.
A dashboard for display of all information.
Bit of complexity to the install but also since they are custom installs also a custom solution.
The truth is you already have the complex installation, there is not avoiding that, as an installer now self support (or a tame integrator) should be in the kit bag.
Thank you for the replies. As a professional installer and integrator I’m not shy about complex installations. And if they are done well they can be very reliable. However, custom workarounds and firmware mods can come back to bite you in the future if a Victon update brakes it. I install system on yachts that cross oceans, so reliability of stability are paramount.
Fully agree. Like aviation, marine systems need to be beyond robust, and worst case supportable by the crew in cases of crisis. We advocate extreme caution for remote, off-grid systems. Doesn’t get more remote or off-grid than a vessel at sea.
Using galvanically isolated RS-422 extenders would be the best option I guess.
These are completely transparent beyond the electrical interface and thus are firmware or software agnostic.
Indeed, on IMO-vessels and Navy we use extenders from the brand Phoenix contact, these products are bomb proof and are used and approved by all classification societies for vessels.
These massive Maersk container vessels have 400 meter, control room in the back, and thruster forward, extenders, no option.
Between M/E and other controls, isolators and signal converters, switchable power supplies, etc, etc, simply the best on the market…
Yes, extenders are an option. RS-422 being the best choice if going that route.
I was hoping for a Victron native option that would only require a single “box” at remote end. Seems like a Nucleo at remote end would be an excellent option. Have a “slave” mode that could be enabled on the GX device that turns it into a VE.Direct forwarding device. Any device connected to the remote device’s Ve.Direct or USB ports would be “forwarded” to the master GX device and show there as if they were connected to it directly. Simple/clean one box solution.