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

Node-RED
, ,
1

Posting this mostly as a warning and a recovery recipe for anyone still on older firmware, plus what I found when I went looking in the current source. Short version: on the versions I was running in July, enabling Rate limit on a Victron input node whose D-Bus service was unavailable put Node-RED into a permanent restart loop. It looks fixed in current releases, but the recovery steps are worth having on record.

Setup where it happened

Off-grid Cerbo GX at a cabin. Node-RED runs solar surplus heating, load shedding, EV charging control and BMS charge management, so it’s a big flow with a lot of Victron input nodes. Versions at the time:

  • Cerbo GX, Venus OS v3.72 (official release)
  • Node-RED v4.1.1, Node.js v20.18.2
  • node-red-contrib-victron v1.6.63
  • Linux 6.12.23-venus-8 arm LE

What I did

The input nodes now expose Rounding, Only changes and Rate limit in the edit panel — a nice way to cut message traffic into my function nodes. I went through roughly ten Victron input nodes and enabled combinations of those, with Rate limit at 1 msg/sec or 1 msg/10s.

Important detail: several of those nodes were showing as disconnected in the editor — their D-Bus service/path could not be resolved (the log was full of UnknownObject). The affected ones were the four BMS 24V digital-input-state nodes, the battery power/current/temperature nodes, “Forbrukt Ah”, and “PV Watt”. I set the new options on those too, without thinking much of it.

Then I deployed — and Node-RED went into a continuous restart loop. Come up, run a few seconds, die, get restarted by daemontools, repeat. The editor was unusable and all my automation was down.

The log

DBUS ERROR MESSAGE org.freedesktop.DBus.Error.UnknownObject
DBUS ERROR MESSAGE org.freedesktop.DBus.Error.UnknownObject
DBUS ERROR MESSAGE org.freedesktop.DBus.Error.UnknownMethod
DBUS ERROR MESSAGE org.freedesktop.DBus.Error.UnknownObject
[red] Uncaught Exception:
[error] TypeError: Cannot read properties of undefined (reading 'type')
    at processMessage (/usr/lib/node_modules/@victronenergy/node-red-contrib-victron/src/nodes/victron-nodes.js:192:33)
    at Timeout._onTimeout (/usr/lib/node_modules/@victronenergy/node-red-contrib-victron/src/services/utils.js:467:14)
    at listOnTimeout (node:internal/timers:581:17)
    at processTimers (node:internal/timers:519:7)

…then the same thing again, indefinitely.

What triggers it

  • Nodes that were connected with live values took the same settings without any trouble — including one that had Rate limit set.
  • Rounding and Only changes on disconnected nodes were harmless on their own.
  • It was specifically Rate limit on a disconnected node that crashed it.

The rate-limit feature (in that version) armed a timer to emit the latest value at the end of each interval. On a node whose D-Bus object never existed, there was no cached value, so processMessage() dereferenced .type on undefined. Because that throw came from inside a timer callback, it landed outside Node-RED’s per-node error handling and took the whole process down — which is why it was a full crash loop rather than one node going red.

How to recover (if you hit this on an older version)

The restart loop makes the editor useless, so:

  1. Settings → Integrations → Node-RED → Enabled (safe mode). This starts the editor without running the flows and breaks the loop. (Do not press “Node-RED factory reset” — that deletes your flows.)
  2. In safe mode the Victron node edit panels show empty dropdowns and “Please deploy the flow once and re-open this edit panel”, because the runtime isn’t there to feed them. Cancel out of those — pressing Done with empty dropdowns risks wiping the node’s service/path config.
  3. So don’t fix it in the editor — roll back over SSH. Node-RED keeps the previous deploy automatically:
svc -d /service/node-red-venus
cd /data/home/nodered/.node-red/
cp flows.json flows.json.broken
cp .flows.json.backup flows.json
chown nodered:nodered flows.json
svc -u /service/node-red-venus
  1. Set Node-RED back from safe mode to Enabled.

flows.json.broken is left behind if you want to inspect what changed.

It looks fixed in current releases

I’ve since moved to newer versions, and before posting I went and checked the current source rather than trusting the changelogs (the releases after v1.7.13 are npm-only with no release notes, so a changelog search turns up nothing either way).

In the latest palette (v1.7.27), the rate-limit path has been rewritten. Instead of a timer that emits a separately-cached value, it now uses a trailing-edge throttle() in utils.js that stores the actual received message and replays that when the interval ends. The throttled function is only ever called from inside the subscribe callback, so the timer is never armed unless a real value has arrived — which means a disconnected node that never receives anything can’t trigger it. The pathObj.type access in processMessage is also guarded now.

I’ve read the code, not runtime-tested it on a disconnected node (I’m not going to force a crash loop on a live off-grid system to confirm), so I’ll say “appears resolved” rather than “fixed”. But the failure mode I hit looks structurally gone.

Takeaways

  • If you’re on an older Venus OS / palette 1.6.x: don’t set Rate limit on a Victron input node that shows disconnected. Rounding and Only changes seem safe.
  • If you hit the crash loop: safe mode + SSH rollback above gets you out without losing your flows.
  • On current releases this seems to be handled, so upgrading is the real fix — just be aware of the recovery path in case anyone meets it on older firmware.

Separately: it’s worth sorting out why those nodes were disconnected in the first place (a missing/renamed service or an unconfigured input) — a disconnected input node does nothing useful regardless of this issue.

2 Likes