EVCS stuck in "Waiting" / 2-to-4 minute cutouts after enabling MQTT and HA updates (Stellantis EV /

Q&A and troubleshooting EVCS
,
1

Hello everyone,

I am experiencing an issue where my Victron EV Charging Station (EVCS) gets stuck in a “Waiting” state or cuts out after 2 to 4 minutes of manual charging (6A–13A). This system has worked flawlessly for two years without a single adjustment, but the issues started last week immediately after enabling MQTT access on my Cerbo GX and updating my Home Assistant Core integration.

My System Setup:

  • GX Device: Cerbo GX running Venus OS (recently updated/shifted to Venus OS Large)
  • EV Charger: Victron EVCS , wired as 3-phase but currently charging a single-phase vehicle.
  • Vehicle: DS7 Crossback (Stellantis platform, draws max 13A/3kW on L1). Car port flashes green (Charging in progress), but the EVCS reads “Waiting” or cuts out after a few minutes.
  • Storage & Solar: 10.5 kW solar panels + 10.5 kW battery bank + VM-3P75CT Grid Meter.
  • Additional Software: Background Python driver running a 3-phase Shelly meter (com.victronenergy.shelly).

What I have uncovered so far:

  1. Modbus Unit ID Collisions: Initially, my Cerbo GX log was filled with Modbus errors (“Error finding service with device type battery at unit id 226” and “Error finding service with device type system at unit id 100”). We found that the background Shelly driver, the core system (com.victronenergy.system), and the VM-3P75CT grid meter were all overlapping or competing on Unit ID 100/Device Instance 0.
  2. Steps taken to isolate IDs: I successfully re-mapped the SmartShunt away from 226 to Instance 279, and moved the VM-3P75CT grid meter to Instance 30 to clear the Modbus bottlenecks.
  3. Switch to MQTT: To bypass the Unit ID 100 collision caused by the background Shelly script, I completely shifted the EVCS configuration from Modbus TCP to MQTT. This completely cleared the W-104 communication warnings and blanked out the Modbus error logs on the Cerbo GX.
  4. The 2-to-4 Minute Cutout persists: Even with no Modbus errors, no W-104 codes, and dropping the charger to a conservative 6A manual limit, the charger initiates cleanly but drops the contactor relay after 2 to 4 minutes. The battery metrics show the system is healthy, the loads on L1 are stable within limits, but a heartbeat or firmware-level watchdog timer seems to override the charging session.

Since this hardware setup was rock-solid for two years, it appears that the recent Home Assistant updates or enabling the raw MQTT cluster wrote an unexpected variable or tight timeout threshold to the EVCS/Venus database registers that I cannot see or alter through the standard UI.

Has anyone seen a case where enabling MQTT or custom integrations forces an aggressive heartbeat/watchdog timeout on the EVCS side? Any guidance on how to completely reset the underlying communication timers or check for hidden register overwrites on the EVCS would be highly appreciated.

Thanks in advance!

2

UPDATE:

I tested charging with EVCS–GX communication disabled in the EVCS settings.

Result: The DS7 continued charging normally for more than 10 minutes, with the EVCS displaying approximately 1,560 W and 0.32 kWh delivered.

I then disabled the three Home Assistant Victron automations and disabled the custom Victron v0.6.4 integration, delete Cerbo SG-X (Victron GX integration) while leaving EVCS–GX communication disabled.

Next, I re-enabled EVCS–GX communication using MQTT, leaving those Home Assistant automations and the custom integration disabled.

Result: Charging continued smoothly for more than 20 minutes, without returning to “Waiting for start”.

This is longer than the original 2–4 minute failure window.

5. Current status

At the time of writing:

  • EVCS–GX communication is enabled using MQTT.

  • The EVCS is in Manual mode.

  • The three Home Assistant Victron automations remain disabled.

  • The custom Victron v0.6.4 integration remains disabled.

  • Charging has continued normally for more than 20 minutes.

I have not yet re-enabled the custom integration or the automations individually, so the root cause has not been confirmed!!!

Following questions arise:

  1. Could the custom Home Assistant Victron v0.6.4 integration, communicating with the Cerbo GX over Modbus TCP, interfere with EVCS charging control even if its automations are disabled?

  2. Is the Modbus error for com.victronenergy.evcharger at Unit ID 40 significant if the service is present in the Cerbo’s Available services list?

  3. Is there a way to determine from the Cerbo GX or EVCS logs whether a charging session was stopped by the GX, by a control command, or by the EVCS itself?

  4. Are there known EVCS MQTT pairing, Venus OS v3.85, or Home Assistant integration issues that could produce this behaviour?

  5. Which logs or diagnostic information should I collect before re-enabling the Home Assistant integration and automations?
    Thank you for any suggestions.

3

Solutions: DELETE custom Home Assistant Victron v0.6.4 integration and use only Home Assistant Victron GX integration