Node RED flow triggered by Firmware update via VRM

Has anyone else had Node-RED flows go haywire after a Victron firmware update pushed via VRM?

I've got a fairly straightforward setup — Multiplus II, Cerbo GX, and a Honda EU22i generator that I'm auto-starting based on SOC thresholds. The generator needs a pulse signal rather than a latching on/off, so I built a Node-RED flow to handle that properly since the built-in generator start/stop function doesn't really cater for it cleanly.

Everything was running brilliantly for months, then a firmware update landed overnight via VRM and suddenly my flow was behaving oddly — triggering at the wrong thresholds and occasionally sending double pulses to the start relay. Took me a while to even realise a firmware update had happened, which was the root cause.

A few questions for those running similar setups:

• Does a VRM-pushed firmware update actually restart Node-RED, or does it just disrupt MQTT in a way that confuses existing flows?
• Is there a sensible way to build in a startup delay or initialisation check so the flow doesn't fire immediately on reboot before everything has settled?
• Anyone using a watchdog-style node to detect when the Cerbo has just come back up and suppress outputs for a defined period?

I'm thinking about adding a simple timer gate that blocks any generator commands for the first 60 seconds after a MQTT reconnect event, but not sure if that's the right approach or if I'm papering over something more fundamental.

Would be good to hear from anyone running pulse-based generator control through Node-RED — especially if you've found a robust way to handle unexpected reboots mid-night.

@Chris1966 yes, this caught me out badly last year. A VRM-pushed firmware update to my Cerbo reset several MQTT topic paths that my Node-RED flows were subscribing to — flows just silently failed rather than throwing errors, which was the frustrating part.

Worth checking a few things:

• MQTT broker on the Cerbo — did any topics shift structure post-update?
• Node-RED's victron-energy nodes sometimes need reconnecting after a firmware bump
• Check your debug nodes are actually wired in — I'd disabled mine "temporarily" and forgotten

The generator auto-start flow is particularly sensitive because if the SOC trigger doesn't fire, you won't notice until the batteries are flat at 2am.

I'd recommend pinning your Cerbo firmware version via VRM settings until you've tested updates on a non-critical day. Victron's changelog usually mentions any MQTT path changes but it's buried.

@Chris1966 this is a well-documented gotcha with the Cerbo. What I'd strongly recommend is adding a Node-RED inject node that runs on startup and validates your critical MQTT topic subscriptions before any flows execute. Firmware updates can silently rename or restructure com.victronenergy.* topics — particularly around the ESS assistant paths.

In my static caravan setup I also have a watchdog flow that pings the Multiplus II every 60 seconds via MQTT and triggers an alert if the response path has changed unexpectedly. Caught a post-update topic restructure immediately rather than discovering it when the generator failed to auto-start.

Also worth checking: after any VRM-pushed update, your Node-RED Victron nodes (the official node-red-contrib-victron package) may need reinstalling to match the new firmware's API version. Check the package version against your firmware release notes on the Victron community site.

Good shout from @VanGill on the inject node approach. One thing I'd add specifically for the generator auto-start flow — after any firmware update, double-check your AC input current limit MQTT paths, as these seem particularly prone to shifting between Cerbo firmware versions in my experience.

On my motorhome setup I now keep a simple text file alongside my flows documenting every topic path with the firmware version it was confirmed working on. Takes five minutes but saves hours of head-scratching later.

Also worth knowing: the Victron community GitHub has a dbus-mqtt topic list that gets updated with firmware releases. Cross-referencing that before and after a VRM update has saved me more than once.

If your Honda EU22i auto-start is misbehaving specifically, post your flow screenshot — happy to have a look at the logic.

Worth noting that VRM firmware pushes don't give a monkey's what time it is — mine updated at 2am and the generator auto-started because the flow assumed MQTT values that no longer existed post-reboot, which on a narrowboat moored in a marina at stupid o'clock is... not ideal for neighbourly relations. Add a startup delay (I use 90 seconds) before any flow logic executes after a Cerbo reboot — node-red-contrib-cron-plus handles this cleanly. Also, pin your Cerbo firmware version in VRM and disable auto-updates unless you're actually awake and watching it.