State-Governed Load Control on Venus OS

I’m building a custom Venus OS control and HMI system for an Echodyne on-the-move radar truck. The system manages 14 electrical loads through a Victron Ekrano GX, combining vehicle-running state, shore power, battery state of charge, operator requests, and timers into one guarded operating model.

The control boundary is deliberate. QML presents current state and sends requests; it never has authority to energize a load. A Node-RED runtime owns the state machine, validates every global and per-load request, publishes status through a project D-Bus service, and sends commands to Ethernet-connected switching hardware only when the operating conditions and output gates agree. Commanded and observed relay state remain separate so an accepted request is not treated as confirmed output state until device feedback arrives.

Development has moved from mock data and offline tests into staged commissioning on the truck. The 14-load interface and baseline runtime are deployed, output channels are brought live one at a time, and the current validation work treats network interruptions, device identity, stale feedback, low-battery lockout, and restart behavior as explicit system conditions. That process keeps the control logic testable without letting development or presentation code bypass the hardware safety boundary.