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:
- 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.
- 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.
- Give the chargers a dedicated SSID on this AP, different from your main network name, so they can never associate with anything else.
- 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.
- 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-clientthat 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 tookdbus-modbus-clientfrom 25% CPU to negligible.
Happy to answer questions or share the Node-RED logic if anyone’s interested.