EVCS loses connection to Cerbo GX periodically - "Error finding service with device type evcharger a

Q&A and troubleshooting EVCS
, , , ,
1

System configuration:

  • Cerbo GX, Venus OS v3.75

  • EV Charging Station (EVCS), firmware v2.08, product ID 0xC026

  • MultiPlus II (VE.Bus, slave 227)

  • Carlo Gavazzi EM24 grid meter (slave 30)

    Home Assistant (via sfstar/hass-victron Modbus TCP integration, polling interval 30s)

  • All devices have static IP addresses

  • EVCS connected to Cerbo via Wi-Fi, all other devices via LAN

Problem description

Since a power outage approximately one week ago, the Cerbo GX periodically loses its internal connection to the EVCS. The Remote Console shows the following error under Settings → Services → Modbus TCP:

ERROR "Error processing function code 3, unit id 41... Error finding service with device type evcharger at unit id 41"

The EVCS itself continues to function normally — it charges the car without issues, the LED ring is active, and the device is visible in the VRM portal. The connection between the EVCS and the Cerbo is listed as Modbus TCP 192.168.1.14 in the device details screen.

The error occurs periodically, not continuously. Sometimes the connection works fine for 10-20 minutes, then fails again for a few minutes before recovering.

What has been tried

  • Full power cycle of both Cerbo GX and EVCS (multiple times)
  • Firmware update of EVCS to v2.08 (latest available)
  • Firmware update of Cerbo to Venus OS v3.75 (latest available)
  • Disabled automatic scanning under Settings → Modbus TCP/UDP devices
  • Verified static IP addresses for all devices (no DHCP changes after power outage)
  • Wi-Fi signal strength to EVCS is strong (verified)
  • GX device IP is correctly configured in EVCS settings
  • Disabling the Home Assistant Victron integration eliminates the errors entirely — re-enabling it causes them to return

Key observation

When the Home Assistant Modbus TCP integration is disabled, the Cerbo runs without any errors for extended periods. When it is re-enabled (polling interval 30 seconds, querying slave 41 registers 3800 and 3802), the periodic errors return.

This suggests that simultaneous Modbus TCP polling from Home Assistant and the internal Cerbo↔EVCS Modbus communication are conflicting. The Cerbo appears to lose its internal com.victronenergy.evcharger dbus service for slave 41 when under this combined load, even though direct Modbus queries to slave 41 via pymodbus succeed consistently:

# This always succeeds:
client = ModbusTcpClient('192.168.GX.IP', port=502)
result = client.read_holding_registers(3802, count=26, device_id=41)
# isError: False, registers: [valid data]

Questions

  1. Is there a known issue with Venus OS v3.75 and EVCS communication stability after a power outage?
  2. Is there a way to make the internal dbus service for the EVCS more resilient to external Modbus polling?
  3. Would enabling MQTT on LAN and switching to an MQTT-based integration (instead of Modbus TCP) resolve this conflict?
  4. Is a factory reset of the EVCS recommended in this situation, and would it help restore stable internal communication with the Cerbo?

Additional information

Direct Modbus queries to the EVCS IP (192.168.1.14) on its own Modbus server return only zero values for all registers (5001-5100, all unit IDs 0/1/41), suggesting the EVCS own Modbus server may not be fully operational, or these registers require a different addressing method.

Any guidance from Victron staff would be greatly appreciated.

2

Update: Identified as a Home Assistant integration bug, not Venus OS/EVCS

Following up on my earlier post — after some debugging I found the actual root cause, and it’s not a Venus OS or EVCS communication issue after all.

The Home Assistant Modbus TCP integration (sfstar/hass-victron, a community/HACS integration, not official) had a bug: at startup it tried to read a value that wasn’t available yet, causing the EVCS entity setup to crash entirely. Once crashed, the integration kept logging “no valid data” warnings continuously, even though direct Modbus queries to the Cerbo confirmed the EVCS was responding correctly the entire time.

Locally patching the integration drops the warning from continuous (every 30s) to a handful per hour. The bug is reported upstream to the integration developer.

For anyone hitting the same “Error finding service with device type evcharger at unit id 41” message after a power outage: check whether you’re running a third-party Modbus TCP client (Home Assistant, Node-RED, custom scripts, etc.) and whether disabling it temporarily makes the Cerbo error-free. In my case it did, which pointed me toward a client-side bug rather than the GX/EVCS pairing itself.

Still there is a residual rate of disconnects (~4/hour) that is worth investigating separately since this persists for no obvious reason.

3

Update 2: Problem confirmed as Venus OS GatewayPathUnavailable (exception code 0x0A) on slave 41

Following up with more precise diagnostic information.

After locally fixing two bugs in the Home Assistant sfstar/hass-victron integration (see previous update), all transaction ID mismatches and race conditions are resolved. The integration now polls cleanly and sequentially. However, the underlying issue persists: the Cerbo GX consistently returns Modbus exception code 0x0A (GatewayPathUnavailable) for slave 41 (EV Charging Station).

This is confirmed by direct pymodbus queries, completely independent of Home Assistant:

from pymodbus.client import ModbusTcpClient
client = ModbusTcpClient('192.168.1.13', port=502)
client.connect()
r = client.read_holding_registers(3800, count=1, device_id=41)
print(r.isError(), r.exception_code)
# True, 10  (= 0x0A GatewayPathUnavailable)

According to the Victron Modbus-TCP documentation, exception code 0x0A means: “The requested Unit-ID is defined in the mapping list, but there is no device found on the mapped port.”

This matches what is visible on the Remote Console under Settings → Services → Modbus TCP:

Error processing function code 3, unit id 41, start address 3802, quantity 26:
Error finding service with device type evcharger at unit id 41

Current situation

  • EVCS is physically working and charging normally
  • EVCS appears in the device list on the Cerbo with correct Unit ID 41
  • Direct Modbus queries to the Cerbo for all other slaves (100, 225, 227, 30, 31) succeed perfectly
  • Only slave 41 consistently returns 0x0A
  • Restarting the EVCS via the circuit breaker provides temporary relief (minutes to hours), after which the error returns
  • This started after a power outage approximately one week ago
  • Both Cerbo GX (Venus OS v3.75) and EVCS (firmware v2.08) have been updated to latest firmware since the outage

Questions for Victron staff

  1. Is there a known issue with Venus OS v3.75 where the internal dbus service for the EVCS (com.victronenergy.evcharger) becomes permanently degraded after a power outage?
  2. Would a factory reset of the EVCS restore the internal dbus-to-EVCS communication on the Cerbo?
  3. Is there a way to manually restart the dbus-modbustcp service or the EVCS dbus service on Venus OS without a full Cerbo reboot? (I did not find an SSH access)
  4. The Victron Modbus-TCP FAQ mentions cat /var/log/dbus-modbustcp/current | tai64nlocal for debugging — is there a way to access this log via VRM or the Remote Console without SSH?

System configuration:

  • Cerbo GX MK2, Venus OS v3.75
  • EV Charging Station firmware v2.08, product ID 0xC026
  • Connection type: Modbus TCP
  • VRM instance: 41