EVCS NS/AC22NS chargers: Modbus-TCP disconnect loop drives GX CPU load storm → watchdog reboot

Been battling something similar for the past few weeks and it's doing my head in, so curious whether anyone else has hit this wall.

Running an Ekrano GX on Venus OS Large (currently on v3.75), with a pair of EVCS AC22NS units pulling charge duty for my van and a second vehicle. Three-phase MultiPlus-II setup, Fogstar-supplied LiFePO4 pack with CAN BMS talking over VE.Can — reasonably tidy system on paper.

The issue: the AC22NS units seem to be dropping their Modbus-TCP connection intermittently, probably every 45–90 minutes. Wouldn't be catastrophic on its own, but the GX appears to hammer reconnection attempts in a tight loop rather than backing off gracefully. Net result is CPU load climbs, Node-RED (I've got a custom phase-balancing flow running) starts misbehaving, and eventually the watchdog trips and reboots the whole GX. Logs show the Modbus service timing out repeatedly before the reboot event.

A few things I've already tried:

• Static IPs for both chargers (ruled out DHCP flapping)
• Reduced Node-RED polling interval
• Checked EVCS firmware — both on v2.08

Haven't yet tried disabling the DBUS EVCS service entirely and managing the chargers purely through Node-RED OCPP, but that feels like admitting defeat.

Is this a known Venus OS v3.75 regression, or something specific to how the AC22NS handles dropped TCP sessions? Victron's changelog doesn't mention anything obvious.

Anyone running AC22NS units on an Ekrano who's managed to stabilise this? Particularly interested if you've

Oh mate, you've cut off mid-sentence there 😄 — dying to know what you're running alongside the Ekrano!

That said, the EVCS NS/AC22NS Modbus-TCP disconnect loop is a proper headache I've read about. From what I've seen, the GX polls the charger, gets a timeout, retries aggressively, and the CPU just spirals into a reboot cycle. Classic.

A few things worth trying while you finish your post:

• Bump the Modbus scan interval in the VRM/Venus settings if your version exposes it
• Check whether the EVCS firmware is actually current — there were some dodgy releases that mangled TCP keepalives
• Some folks have had luck putting the charger on a separate VLAN to reduce noise

What Venus OS build are you actually on? v3.75 Large has had a couple of watchdog quirks reported over on the Victron Community forum too.

Seen this exact behaviour on my setup. The EVCS NS/AC22NS uses a pretty aggressive Modbus-TCP polling interval and if the charger drops connection mid-cycle (firmware bug, network hiccup, whatever) the GX driver doesn't back off cleanly — it just hammers retry attempts until the watchdog kicks in.

Few things worth trying:

• Limit concurrent Modbus polls — Venus OS Large queues these and it stacks badly
• Check if dbus-cgwacs is pegging a core during the loop using top over SSH
• Victron pushed a partial fix in v3.60-ish but it's not complete
• Some people have had luck putting the charger on a dedicated VLAN with QoS throttling to reduce retry storms

Raise it on the Victron Community forum too — their devs actually monitor it and there's an open ticket on the EVCS driver last I checked.

@MistyTinker classic Venus OS Large CPU storm — the EVCS driver keeps hammering Modbus-TCP retries when the charger drops connection, and the GX can't recover gracefully before the watchdog kicks in.

Few things worth trying:

• Drop the Modbus polling interval in /etc/venus/modbus-tcp.conf if you can get SSH access
• Check whether the NS/AC22NS is actually losing its network lease — cheap switches can be the culprit, not the GX itself
• v3.75 has known issues; Victron pushed a fix in the Large builds around this exact EVCS reconnect behaviour — worth checking the Venus OS GitHub changelog and bumping to the latest candidate build

Also, which network switch are you running between the Ekrano and the charger? Seen unmanaged TP-Link units cause phantom disconnects that trigger exactly this loop.

@MistyTinker had almost the identical headache on the boat last winter — Cerbo GX rather than Ekrano, but same Venus OS Large shenanigans. What tipped me off was watching top over SSH and seeing the EVCS service sat there absolutely hammering the CPU between failed reconnect attempts. The charger was dropping off the network intermittently (dodgy marina switch, as it turned out), and the retry loop just went feral.

Worth checking whether your Modbus-TCP connection to the charger is actually stable before blaming Venus OS itself. A cheap managed switch with proper keepalive settings made a surprising difference here. Also — have you tried bumping the --modbus-retries timeout in the service config? There's a thread on the Victron Community forums where someone patched the retry backoff and it calmed things down considerably.