Building Automations on the Cerbo GX with Node-RED: A Practical Starting Point

The Cerbo GX runs Node-RED natively. Most people don't use it.

For commercial deployments where you need logic beyond what stock firmware handles (conditional load shedding, generator sequencing, external alerting, time-of-use scheduling), it's where the real configuration work happens. Here's how to actually get started.

 

 

Getting Node-RED running on Venus OS

Node-RED isn't available in the standard Venus OS image. You first need to switch to Venus OS Large. On the Cerbo GX console, go to Settings → Firmware → Firmware Updates → Image Type and select Large. Check for updates again after switching. It will prompt a second update to install the Large image.

Once you're on Venus OS Large, scroll to the bottom of the Settings menu and go to Settings → Venus OS Large Features and enable Node-RED. Note that installer access level is required to enable it.

Access the Node-RED flow editor at https://venus.local:1881 from a browser on the same network. If venus.local doesn't resolve, use the Cerbo's IP address directly: https://[your-cerbo-ip]:1881. Expect a browser security warning on the HTTPS connection; that's normal, proceed through it.

Reading system data with the Victron nodes

Venus OS Large ships with the Victron node palette pre-installed. You don't need to install node-red-contrib-victron separately. The palette exposes every parameter available on the dbus: battery SOC, voltage, current, inverter state, grid power, solar yield, BMS charge and discharge limits. These are your inputs for any automation logic.

An input-battery node gives you live SOC. An input-gridmeter gives you real-time grid power. An input-inverter gives you inverter state. Only the services and measurements actually present in your system will appear in the node configuration panel. If a parameter isn't showing up, verify the connected device is communicating correctly on the dbus first.

A real example: SOC-triggered load shedding

The most common automation we build for C&I deployments: when SOC drops below a configurable threshold and the system is in a specific state (no solar, no grid, generator not running), automatically shed non-critical loads before the BMS hits its DCL floor.

The flow: input-battery node watching SOC → switch node checking threshold → output-relay node triggering the Cerbo's physical relay outputs to cut non-critical loads. Add a trigger node to prevent rapid cycling. Add an output-notification node to push an alert to VRM when the load shed activates.

Worth noting: Relay 1 on the Cerbo is often pre-assigned to generator start/stop control. If you're using Node-RED to control relays, verify the relay function assignment in Settings → Relay and set the relevant relay to manual control before trying to drive it from a flow.

This kind of conditional logic isn't available in stock ESS configuration. It lives in Node-RED.

Pushing alerts outside VRM

VRM handles internal alarming. When you need events to reach a Slack channel, a dispatch system, an SMS, or a webhook endpoint, Node-RED is the bridge. An http request node on the output side of any flow can hit any external endpoint: Slack's incoming webhook, a Twilio SMS API, a custom backend.

For fleet operators managing multiple sites, this means critical events surface in the tools their team already uses rather than requiring someone to watch a VRM dashboard.

One important note on backups

Node-RED flows do not survive a factory reset and are not backed up by VRM. Before any firmware update, export your flows via Menu → Export → all flows and save the flows.json file somewhere safe. This is easy to skip and painful to learn the hard way on a deployed system.

Where this fits in a C&I deployment

Node-RED on the Cerbo is the difference between a system that runs and a system that operates autonomously. For surveillance trailer fleets, mobile platforms, and commercial BESS installations, the automations you write here determine how the system behaves when nobody is watching, which is most of the time.

If you're building Victron-based systems and need this level of configuration, remote or on-site, that's what we do as a Victron Recommended Software Integrator.

Request a consultation

Back to blog