when attempting VE.Bus tunnel operations remotely via the VRM portal (such as firmware updates or writing configurations to MultiPlus/Quattro units via MK3-USB). It appears to be an architecture/library compatibility issue specific to the 64-bit Pi 5 community port when handling legacy MK2/VE.Bus binary translation during remote portal sessions.
Was under the impression this functionality required a GX device and that PI wasn’t supported.
But 2 versions before it was functional on RPI VENUS…100% YES
Should be fixed in v3.80~53 (beta version)
Dear Jeroen,
thank you very much for info.
Let me share a thought. I’ve been using Victron products in various installations for about 15 years now. I am extremely satisfied with Victron, and the platform you’ve created is truly fascinating.
I have systems that have run without a hitch so far, but once I started implementing automated controls and pushing the system to its limits, I needed to process large amounts of data in conjunction with Victron. I handle this natively using Node-RED.
During this processing, the Cerbo GX (which wasn’t even the main Node-RED server) was under extreme CPU load.
That’s why I turned to a Raspberry Pi 5 running Venus OS. I recognize—and can see—that this setup (even on older Raspberry Pi models) acts, in a way, as a development platform. And it likely always will, given that Victron has its own proprietary GX devices, which remain the primary focus of your support efforts.
Personally, though, I don’t understand why Victron doesn’t just manufacture its own RPi-Victron HAT—even if it cost €500—that is guaranteed to work perfectly. It could feature proprietary BMS-Can, VE.Can, and VE.Direct ports,
along with an SD card pre-loaded with Venus OS.
I am convinced that plenty of enthusiasts—people who want high performance backed by the Victron guarantee—would buy it. And you wouldn’t have to deal with supporting DIY Raspberry Pi projects the way you do now…
The GX range has/is getting a bump in performance.
The ekrano is meaty, so is the nucleo and soon the cerbo.
Supporting a new product is an expensive endeavour, probably better invested in keeping the GX portfolio up to speed, so to speak ![]()