I’ve been spending a lot of time under the hood of my setup lately, which got me thinking about the 10–15 year lifecycle of these units. While the hardware is “built like a tank,” I feel the software ecosystem can occasionally become a bottleneck for those wanting to integrate with evolving EU standards or custom BMS setups.
I am considering starting a project to create a comprehensive, open-source documentation and implementation of the communication protocols—specifically VE.Direct and perhaps an other legacy protocols that still abide in the inside side of the system (that is to say on the low voltage side).
The Vision
The goal is to provide a community-owned “dictionary” for how these units communicate. This is strictly about the communication layer and data visibility. *
Safety First: I 100% agree that low-level power-switching and phase-sync logic must remain the domain of official firmware. We want to read the data, not rewrite the safety-critical timing.
Future Proofing: Ensuring these units can talk to the world long after official support cycles might shift.
Integration: Making it easier to bridge Victron hardware into professional, custom-built energy management systems.
Questions for Staff, Experts, and Power Users:
Do you see a significant risk in having a community-maintained spec?
Would a fully open-source bridge be something you’d actually use or implement?
Are there specific “No-Go” zones or “edge cases” I should be aware of before starting?
On Hardware Clones:
Some might worry that documenting protocols opens the door for clones. However, Victron’s value lies in the massive copper transformers, the 5-year warranty, and the global support network. An open protocol actually makes genuine hardware more valuable because it lowers the friction for professional integration.
On Security: The current “Security through Obscurity” model is already transparent to anyone with a debugger. From unencrypted VNC to D-Bus accessibility, the data is already out there. We have two choices:
A messy, unofficial “hacker” version of the protocol floating around.
A clean, community-vetted, and safe specification that respects the hardware’s limits.
I want this to be a “peaceful” project that adds value to the ecosystem rather than breaking it. I’d love to hear your thoughts on whether this helps the community or if I’m overstepping.
VE.Bus is locked largely due to grid-code compliance, certification, and safety requirements. These aren’t optional constraints.
Writing firmware that directly drives power hardware requires far more than understanding the code paths. It depends on intimate knowledge of hardware limitations, tolerances, timing, and failure modes. Opening that layer would necessarily require exposing much more than just protocol details, which quickly enters safety-critical and intellectual property territory.
Because of that, I can fully understand why VE.Bus is not opened at a deeper level. And certaiy not open to general public.
It’s also worth noting that there is already extensive command and data access available for monitoring, configuration, and integration. In practice, this provides what’s needed for external systems without exposing the parts that must remain tightly controlled.
So this isn’t really a case of “security through obscurity.” The system is closed where it needs to be closed, and open where it makes sense. From that perspective, there doesn’t seem to be a strong justification for pushing access any deeper.
Hard to warranty your hardware if code loaded on it has cause an issue. (I point to a windows 11 update and a suppsed link to hard drive faliures).
The failure on an inverter is much more costly life wise and reputation damaging than photos and someones work lost.
Note that not all registers exist for all hardware. This is a (full?) sorted list.
For example only green/yellow marked exists for Multi RS (my hardware)
PS. Hope you didn’t take it personally in the other thread…
