I’m looking for experiences from anyone who has implemented full D‑Bus externalisation from a GX device to an external machine (e.g. Raspberry Pi).
Context (to avoid confusion):
I am not trying to move Node‑RED off the GX.
The GX will remain the primary automation device.
All critical flows will continue to run on the GX.
What I would like to do is run some additional, non‑critical Node‑RED flows on a Raspberry Pi.
Some of these flows use Victron nodes and therefore need direct access to the same D‑Bus paths as on the GX (full read/write, same structure and semantics).
I am not interested in:
MQTT‑only solutions (insufficient coverage and different semantics)
WebSocket‑based D‑Bus proxies (more suited for debugging / partial access)
My question:
Has anyone successfully implemented a direct, full D‑Bus bridge/mirror from a GX to a Pi, providing near‑complete or complete D‑Bus access externally (services, paths, methods, signals), suitable for continuous use with Node‑RED?
Probably worth testing it before a post.
Direct socket assumes a manual install on a local venus device.
TCP is for remote devices, and unfortunately, completely insecure.
From the looks of it, the preferential technical solution is to enable Option B insecure TCP. A quick search confirms people are doing this successfully.
The pitfall being that you need to create private subnet to carry plain text D-Bus data, and secure that subnet by other means yourself. Which probably is the lesser complicated part of the solution to get right, and at the same time the more risky pitfall because it is easy to postpone, the ‘nothing is as permanent as a temporary solution’ pitfall.
It’s an interesting topic though, it would be a good way to keep the Cerbo-GX as clean as possible (only running core virtual devices in its VenusOS large Node-RED instance but no further logic), while moving experimental code (hybrid DESS and Marine automations) to another device. Regarding the insecure TCP subnet, I’ll first try to make the secondary device (rPi or VM) double as a router/firewall to ensure the insecure subnet stays private. May require a USB-LAN dongle, I’ll figure it out.
Thanks for the detailed explanation — that really helped me understand the distinction.
For my use‑case I’m mainly reading system data and controlling devices (charger on/off, charge current, logic flows, etc.). From what I can see, all of this works reliably through the MQTT bridge without needing full raw D‑Bus access.
Just to confirm: for this kind of automation, MQTT should be sufficient and there’s no practical advantage in using the TCP D‑Bus option unless I specifically need deep D‑Bus method calls, correct?
Absolutely, I have re assessed the situation after some of the replies. I was under the impression that MQTT would have major limitations which is why I am now double checking if that is really the case. I am currently accessing data from the Victron pallets such as battery state of charge, AC in limit, and other values in general that gets entered into some algorithms within Node-Red functions performing calculations and delivering logic controls back to Victron in order to charge at certain times, or just the current limit, adjust the data between current state of charge and maximum charge to be reached as well as displayng on a dedicated dashboard from which I can control all avoiding using different GX UI pages. So, if all this can be achieved without the need of the unsecured TCP but just by using an MQTT bridge, then yes I would be happy to use that. I apologise for having misled the community but I needed to understand more about this subject.
