Heads-up: "Rate limit" on a disconnected Victron input node could crash-loop Node-RED v3.72

Ran into something similar on my boat setup last winter — took me an embarrassingly long time to track down.

I had a Rate limit option ticked on a Victron input node that was pointing at a MPPT which wasn't always connected (I disconnect it seasonally). Node-RED was just... dying. Repeatedly. No obvious error in the logs at first glance, and I kept blaming the Raspberry Pi being underpowered.

Eventually spotted the crash loop was happening specifically on reconnection attempts when the rate limiter fired against a null state. Messy.

Few things worth noting for anyone else on this:

• Check your Node-RED version — I believe the behaviour changed somewhere around v3.x but I'm not 100% certain of the exact build
• If you're on older firmware on the Cerbo or Venus OS, the interaction seems worse
• Disabling Rate limit on any input node tied to intermittent hardware fixed it for me immediately

My emergency backup system ashore runs a more conservative Node-RED config and never had the issue — probably because everything there stays connected permanently.

Anyone else seen this with nodes pointing at devices that go offline periodically? I'm wondering if it's specifically a Victron node library issue or something deeper in how Node-RED handles the reconnection state. The Victron Node-RED nodes on npm haven't had a huge amount of updates recently from what I can see.

Would be useful to know if people on Venus OS Large (with Node-RED baked in) are seeing the same, versus those of us running Node-RED separately on a Pi alongside a Cerbo GX.

@CliffGazer — seen exactly this in my motorhome setup. Worth adding: the crash loop seems to worsen if you've got persistent context enabled in Node-RED's settings.js. The rate limiter apparently tries to write state before the connection is fully torn down, and with persistent context it hammers the filesystem on every failed attempt.

My workaround before updating was wrapping the offending Victron input in a catch node scoped to that tab only, which at least kept the rest of the flows alive.

Also worth checking your /root/.node-red/flows_cred.json — I found mine had ballooned after a few of these loops, presumably from repeated write attempts.

Victron's Venus OS 3.x complicates this further if you're running Node-RED directly on a Cerbo rather than a separate Pi. Different file permission behaviour seems to affect recovery.

@CliffGazer this caught me out on the shepherds hut build last autumn — nearly identical scenario. I'd wired up a Victron MPPT via VE.Direct and the input node was polling something that wasn't yet online. The Rate limit combined with a null return apparently stacks up something in the event loop that Node-RED v3.72 just can't handle gracefully.

What actually saved me was wrapping the Victron node output in a catch node scoped to that tab, which at least broke the loop long enough to diagnose properly. Dropping the Rate limit tick entirely and handling throttling downstream with a simple delay node instead was the clean fix.

Worth checking your settings.js logging level too — bumping it to debug briefly made the offending node obvious within about 30 seconds of restart.

Has anyone confirmed whether this affects all versions of the Victron node package or just specific releases? I'm running Node-RED on a Raspberry Pi in my motorhome and I've got several Victron input nodes set up — some pointing at an MPPT that isn't always connected depending on which hook-up I'm on.

Slightly nervous now because I do have rate limiting enabled on at least one of those nodes. Is the fix simply unticking Rate limit on disconnected inputs, or is there a more permanent patch available through the package update?

Also — does this only trigger when the node is actively disconnected at runtime, or can it happen if the device just wasn't present when Node-RED first started up?

@Moorey44 good question — from what I've seen it's not version-specific to the Victron node package itself, more a Node-RED v3.x behaviour change in how it handles timer callbacks when the underlying connection drops mid-cycle. Earlier Node-RED versions seemed to fail more gracefully.

Worth checking your Node-RED version first rather than downgrading the Victron nodes. If you're on 3.72, temporarily disabling the Rate limit on any disconnected inputs is the quickest workaround while you investigate properly.

I'd also suggest keeping an eye on your debug console during the restart loop — you'll often see a telltale "Cannot read properties of undefined" error just before it dies, which at least confirms this is your culprit rather than something else entirely.

Cheers for flagging this @CliffGazer — I hit something very similar on my narrowboat install about six months back and it drove me absolutely mental trying to isolate it.

One thing worth adding that I haven't seen mentioned yet: I found that wrapping the problematic Victron input node in a catch node gave me much earlier warning before things spiralled. The catch node would surface the error in the debug panel rather than letting it silently hammer the event loop into oblivion.

@Moorey44 — in my experience the Node-RED version matters more than the Victron package version here. v3.72 specifically seems less forgiving about how it handles the retry behaviour on disconnected nodes generally, not just Victron ones.

Temporarily disabling Rate limit until the device is confirmed online is the quickest workaround I've found. Worth adding a comment in your flow so you remember to revisit it!