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

Q&A and troubleshooting EVCS
, , , ,
1

System:

  • Ekrano GX, Venus OS Large v3.75
  • 2× EV Charging Station NS (AC22NS), firmware v2.08
  • 3× Docan Panda 48 kWh LiFePO4 (CAN BMS on VE.Can), 3-phase MultiPlus-II
  • Custom Node-RED EV phase balancer (reads/writes the chargers over the GX dbus, 1-second control loop, protecting a 38 A/phase limit)

The problem:

Both AC22NS chargers are on a dedicated 2.4 GHz IoT wifi network with a mesh AP less than 2 m away, static IPs, and Bluetooth disabled. Despite the strong signal, they continuously drop and re-appear on the GX. The dbus-modbus-client log shows a constant cycle, roughly every 15–30 seconds, 24/7 — even when the chargers are completely idle and not charging:

[tcp:192.168.#.#:502:1] Device failed: Modbus Error: [Connection] Failed to connect
[tcp:192.168.#.#:502:1] Found EV charger: Victron Energy AC22NS
registered ourselves on D-Bus as com.victronenergy.evcharger.evc_...

Ping tests to both chargers show severe latency and packet loss on an otherwise healthy LAN (spikes from ~5 ms to 2000–2700 ms, 5–10% packet loss), which is why the Modbus reads time out (“No response received, expected at least 8 bytes”).

The consequence:

This constant disconnect/reconnect churn keeps re-registering the chargers on dbus, which in turn keeps the whole dbus chain busy (vecan-dbus, dbus_systemcalc, vrmlogger, flashmq). Combined with my Node-RED balancer polling the chargers every second, dbus-modbus-client sits at ~25% CPU permanently. This has twice escalated into a full CPU load storm (load average >40, 0% idle) that triggered a hardware watchdog reboot — taking the whole system down, including AC output while in island mode. The watchdog_processlist.txt confirms the dbus/CAN chain saturating at the moment of the reset.

I’ve isolated it with before/after CPU measurements:

  • Chargers ON + balancer ON → dbus-modbus-client at 25% CPU, system near the edge
  • Chargers OFF + balancer ON → still 25% (balancer keeps hammering the now-dead chargers)
  • Chargers ON + balancer OFF → dbus-modbus-client negligible, 83% idle

So the chargers on their own are fine; it’s the combination of their wifi instability and any client polling them that creates the churn.

My questions to the community:

  1. Is this AC22NS wifi/Modbus instability a known issue, and is there any firmware or config fix that makes the connection stable? (I’ve already tried: dedicated IoT SSID, static IP, Bluetooth off, matched subnet mask, scan period 0.)
  2. Is there a way to make the GX dbus-modbus-client more tolerant of an unresponsive charger — e.g. back off and stop re-registering instead of retrying every few seconds — so a flaky charger can’t drive the whole dbus chain into a load storm?
  3. Has anyone successfully moved these chargers to a wired connection, given the AC22NS has no ethernet port? Any bridge/adapter approach that actually resolved it?
  4. More broadly: should a single misbehaving Modbus device really be able to escalate to a watchdog reboot of the GX? Is there any GX-side protection against this?

Any pointers appreciated — happy to share more logs (dbus-modbus-client, watchdog_processlist, ping traces) if useful.

2

Are you running on the beta of venus?

If so, you could upgrade your EVCS to the beta firmware as well, and follow this guide ( https://ve4.nl/evcs-mqtt-migration) to switch the EVCS to mqtt communication.

Mqtt is more reliable on bad wifi.

Ofc, if the wifi issues are “too big”, that also may not result in a all stable connection.

I also have a multi-accesspoint wifi and a lot of wifi devices often pick the accesspoint on the other side of the building, rather than the one close to it.

Best (for any wifi client) is to ensure (by adjusting placement and accesspoint sending power) to avoid overlapping areas of the signal, where devices sometimes even start to jump back and forth between two accesspoints causing recurring disconnects.

For some devices that is tricky to achieve, as they roam “on free will” and the unfavorable physical placement cannot be changed. For them, i’ve created SSIDs per-accesspoint (i.e. “My Wifi (Garage)”) and then switch these devices to their designated closest per-accesspoint-wifi.

Don’t use your wifis system “stick to accesspoint” feature: That will/can NOT prevent the device to try to roam, it’ll just refuse connection on any other accesspoints, making things actually worse than better, because it may take longer to fall back to the “only permitted accesspoint”.

3

Thanks, this is very helpful — the AP-roaming explanation especially, since I do have a mesh AP quite close to both chargers that could be causing exactly that back-and-forth.

Two follow-up questions on the MQTT migration:

  1. I’m currently running EVCS firmware v2.08 (installed a few days ago). The migration guide only mentions v2.06-beta-16+ as the minimum, and explicitly excludes v2.07. Does v2.08 support MQTT pairing, or would I need to roll back to a v2.06 beta?

  2. Has anyone done this migration specifically on an Ekrano GX (rather than Cerbo)? I want to confirm the beta GX firmware (v3.80-beta-26+) is fully supported on Ekrano before I move my GX off the stable release branch, since I’ve just spent a fair bit of effort stabilizing this system (had a CPU load storm / watchdog reboot triggered partly by the constant Modbus reconnect churn from these chargers).

Appreciate any input before I take the plunge.

4

The Guide is a bit aged and references a quite early beta. But once you upgraded the EVCS to that firmware, it will automatically propose to upgrade to the latest beta as well.

The venus 3.80 beta is close to be released officially, so can be considered quite stable.
(Running it on 3 ekranos as well)

But that said, you could also wait for that to happen, if you don’t want to hop on the beta-release-track.

Yeah, side-local roaming is a tricky thing. Ultimately the decission is up to the device, and the ap-network can only “propose” accesspoint selections, which the device may or may not follow. (And most the time it’s “not” :upside_down_face:)

Any ap-system related measures like sticky accesspoint selection, signal-strength-based disconnects etc. usually makes it worse. Dedicated single-AP SSID is the only reliable solution for devices that do not physically roam and don’t need a “backup link” if that AP fails.

5

Update: solving EVCS wifi instability without beta firmware or MQTT migration

I wanted to give an update to everybody about this problem.

I decided not to upgrade to the beta firmware or migrate to full MQTT yet, but to first try stabilizing the wifi for the two EVCS in a different way. I had an old TP-Link Archer C7 lying around, which I dusted off, upgraded to the latest firmware, and configured as a dedicated access point, connected by ethernet to the rest of the network.

The C7 doesn’t do mesh. I turned off the 5GHz radio entirely and limited the 2.4GHz radio to a fixed 20MHz channel width (instead of 20/40MHz auto). I also fixed the channel to 11, which was relatively quiet in my environment. I then moved both EVCS onto this dedicated SSID.

The results, in three stages:

Before the C7 (both chargers on my mesh network, with a mesh AP less than 2m away): ping showed 5–10% packet loss with latency spikes up to 2700ms, and the dbus-modbus-client log showed a Device failed → Found → registered on D-Bus cycle every 15–30 seconds, around the clock — even with the chargers completely idle. This constant dbus churn was what eventually drove my GX into CPU load storms and watchdog reboots.

After the C7: immediate and substantial improvement, but not flawless. Ping loss dropped to 0–3% with occasional spikes still reaching ~1300ms, and the modbus disconnects went down to roughly one per hour, with occasional bursts (I logged 6 disconnects in 32 minutes on one occasion). Noticeably worse during active charging, which I suspect is RF interference from the charger’s own power electronics.

After an Ekrano GX reboot (which happened for an unrelated reason): zero issues since. Ping is now 0% packet loss with latency between 2.8ms and 12ms (average ~5ms — no spikes at all), and there have been no modbus disconnects whatsoever in 6 days. System stability improved drastically: no more load storms, no more watchdog reboots.

What I think is going on: the dedicated non-mesh AP fixed the roaming/RF layer, which was the bulk of the problem. But something in the GX itself — possibly accumulated state in dbus-modbus-client or in connman’s view of the network interfaces after days of uptime — seems to have contributed to the remaining instability, and only a full reboot cleared that. I can’t prove this definitively with a controlled test, but the before/after difference is stark and consistent across both measurements.

My recommendations to anyone dealing with Victron EVCS units disconnecting, destabilizing their GX, and making Node-RED scripts unreliable:

  1. Install a cheap (but secure) dedicated 2.4GHz router as an access point for the chargers only. It must be non-mesh — a single, standalone radio. Connect it by ethernet to your existing network and put it in AP mode (or, if your router lacks an explicit AP mode, disable its DHCP server and give it a static IP within your existing subnet). Keep it on the same subnet as your GX so Modbus TCP keeps working.
  2. Disable the 5GHz radio and fix the 2.4GHz settings manually: 20MHz channel width (not 20/40 auto), and a fixed channel (1, 6, or 11 — pick whichever is least congested in your area). Don’t leave anything on “auto” — the goal is a completely predictable, unchanging RF environment for these sensitive ESP32-based devices.
  3. Give the chargers a dedicated SSID on this AP, different from your main network name, so they can never associate with anything else.
  4. Reboot your GX device after making these changes. In my case this turned out to be the difference between “much better” and “perfect”, and it costs nothing to try.
  5. Harden any Node-RED scripts that talk to the chargers. My phase balancer was polling both chargers every second and kept hammering them even when they’d dropped off — this created a feedback loop with dbus-modbus-client that pushed CPU load high enough to trigger watchdog reboots. I added a per-charger staleness check (if a charger hasn’t sent fresh data in 30 seconds, treat it as offline and stop writing to it entirely) plus an early exit when both are offline. This alone took dbus-modbus-client from 25% CPU to negligible.

Happy to answer questions or share the Node-RED logic if anyone’s interested.

6

Hi Araaf,
That’s great work.

When I get my wifi operation stabilised, I plan to use some simple NodeRed with the EVCS.

I would appreciate if you could share your NodeRed logic.

My EVCS appears to be behaving itself at the moment, but I’m away from home this week and there is no vehicle interaction/charging happening, which could be a factor.

Many thanks.