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. Fourteen electrical loads run through a Victron Ekrano GX, and the system’s job is to combine vehicle-running state, shore power, battery state of charge, operator requests, and timers into one guarded operating model that decides what is allowed to be on.

Venus OS is the Linux system that runs on Victron’s GX devices, and it is built around D-Bus, a message bus on which every service publishes what it knows as named paths that any other service can read or ask to change. The battery monitor publishes state of charge there, the inverter publishes its mode, and the touchscreen interface is a QML application reading from the same bus. That structure is what makes a project like this possible on hardware that ships as a monitoring device. The control logic, the interface, and the device drivers are separate processes talking over a bus, and the boundaries between them are real boundaries rather than conventions.

The control boundary is deliberate, and it runs between the interface and everything that can switch a load. The QML interface presents current state and sends requests. That is all it does. It never has the authority to energize a load, whatever it displays and whatever the operator presses. A request is a value written to a path on the bus that says what the operator wants, and the interface has no path it can write that turns anything on.

Authority lives in the Node-RED runtime. It owns the state machine, which is the explicit list of states the system can be in and the transitions allowed between them, with every guard condition written down: the kind of rule that says a load which needs the engine running cannot be requested on while the vehicle is off, a load which depends on shore power cannot be requested when shore power is absent, nothing can be requested while the battery is below the lockout threshold, and a load with a timer turns itself off when the timer expires whether or not anyone asked. Node-RED checks every system-wide and load-specific request against that machine, publishes status through a project D-Bus service so the interface and anything else on the bus can see what it decided, and commands the Ethernet-connected switches only when the operating conditions and the output permissions both allow it. Even then, a command is not a confirmation. Commanded state and device-reported output state are kept separate: matching feedback from the device confirms what the switch says it did, and whether the connected load actually responded is still something that has to be verified physically, because a relay can report closed with a blown fuse on the other side of it.

Development has moved from mock data and offline tests into staged commissioning on the truck itself. Because the state machine runs against paths on the bus rather than against hardware, the runtime could be exercised with mock devices publishing battery and engine state long before a real switch was wired, and the same checks now run against the truck. The 14-load interface and the baseline runtime are deployed, and output channels are being brought live one at a time, each one followed from request through permission through command through reported feedback before the next is enabled. The validation work at this stage treats network interruptions, device identity, stale feedback, low-battery lockout, and restart behavior as explicit system conditions rather than edge cases: what the runtime does when a switch stops answering over Ethernet, how it confirms it is talking to the switch it thinks it is talking to before commanding it, how old a feedback reading can be before it is treated as unknown, what happens when the battery crosses the lockout threshold with loads already on, and what state every output comes up in after a power cycle. Each of those has a defined answer, which keeps the control logic testable without ever letting development or presentation code reach around the hardware safety boundary.