[Bug]: X3-HAC EV Charger - charge_added_cumulative off by factor 65536, and sporadic read timeouts on varying registers

[xzsg4d4khs-svg]

Describe the bug

Two separate issues with plugin_solax_ev_charger.py on an X3-HAC 22kW (Gen2, ARM v2.03), polled as a dedicated hub over Modbus TCP directly to the charger's own LAN address.

Reads are otherwise excellent: communication_success_rate sits at 100.0 % and all 27 enabled sensors return plausible values every 10 s. Writes work too - see Additional context.

1. charge_added_cumulative is off by exactly a factor of 65536 (hi/lo word swap)

sensor.<hub>_ev_charger_charge_added_cumulative   21 141 913.6 kWh

The same charger read through the separate solax_http custom integration (local HTTP API, entirely independent code path) reports the lifetime total as:

sensor.solax_api_charge_added_total              322.6 kWh

And 322.6 x 65536 = 21 141 913.6 - an exact match, not an approximation. Classic symptom of the two 16-bit halves of a 32-bit register being combined in the wrong order.

Related: charge_added_total reads 0.0 kWh at the same moment, while the real lifetime total is 322.6 kWh. So the register that actually holds the lifetime figure appears to be the one mapped to charge_added_cumulative, and charge_added_total looks mislabelled or mapped to a register this firmware does not populate.

PRs #2178 and #2227 touched EVC energy word order, but this sensor is still wrong in 2026.07.4.

2. Register 0x634 (Timer Boost Start Time) never responds

Repeating several times per hour, see the log section below.

In plugin_solax_ev_charger.py, 0x634 is declared twice - once as a SolaXEVChargerModbusTimeEntityDescription and once as a SolaXEVChargerModbusSensorEntityDescription - both with wordcount=2, for Timer Boost Start Time.

The charger answers every other register fine but never this one. Raising time_out from 5 to 15 seconds in the hub options changed nothing: the message still reads after 1 retries, so the retry count appears fixed at 1 and the extra latency budget is not the issue. Either this X3-HAC firmware does not implement that register block, or the address / wordcount is off for Gen2 hardware.

Side effect worth noting: communication_health flips to Degraded while communication_success_rate stays at 100.0 %. Those two contradict each other.

Integration Version

2026.07.4

Homeassistant core version

2026.7.4

Inverter brand

SolaX Power

Plugin used

plugin_solax_ev_charger.py

Serial prefix

Charger: 5030M0011A0102 (X3-HAC 22kW, hardware Gen2). Inverter on site, separate hub, not involved: X3-Ultra-25kW, prefix H3BF

Inverter firmware versions

Charger: ARM v2.03. Inverter (separate hub, for context): DSP 31.04 ARM 31.04-31.10, Gen5

Connection Method

Modbus TCP, tcp type, directly to the charger own LAN address on port 502, read_modbus_addr 70, scan intervals 10/10/10 s, time_out 5 s. Second hub, alongside an inverter hub pointing at a different gateway address.

Dongle firmware

N/A - the charger is reached over its built-in network interface, not a Pocket WiFi dongle

Detailed Error Log

Logger: custom_components.solax_modbus
Source: custom_components/solax_modbus/init.py

Error: device: 70 address: 0x634 -> Modbus Error: [Input/Output]
No response received after 1 retries, continue with next request

Additional context

Writes do work on this setup - I mention it because issue #2225 might suggest otherwise for EV chargers, and I do not want to muddy that report. Writing number.<hub>_ev_charger_max_charge_current (register 0x668) from 32 A to 30 A and back was accepted and held, and the change was confirmed independently by the solax_http integration reading the same charger over HTTP. So the value genuinely reached the device.

One behaviour I could not fully explain, in case it rings a bell: select.<hub>_ev_charger_charger_use_mode (register 0x60D) shows Fast optimistically, then returns to Stop at the next poll. This is with no vehicle connected (run_mode = Available).

No error is logged for 0x60D - the only errors during the test were the unrelated 0x634 ones. I also ruled out interference from my own automations: none of the ones that can set this register fired during the test window (checked via last_triggered), and solax_http never reported Fast either.

So I cannot tell whether the charger silently rejects the write, or accepts it and immediately resets to Stop because no car is plugged in. Writes to 0x668 on the same device do stick, so it is not a general write problem. I will retest with a vehicle connected and report back - flagging it here in case the expected behaviour of 0x60D on an idle charger is already known.

[TCWORLD]

Did this work properly in 2026.07.1?

[xzsg4d4khs-svg]

Thanks for looking. Answering your question first, then correcting my own report on point 2.

Did this work properly in 2026.07.1?

I can't say - this EV charger hub did not exist before 2026.07.4. I added it yesterday as a second hub alongside my inverter hub, so there is no earlier baseline for this device. The charger itself has been in service for months, but only through a separate HTTP integration, never over Modbus.

If it is useful I can downgrade to 2026.07.1 and re-check both symptoms - let me know whether that would actually narrow it down and I'll do it.

Correction on point 2 - my characterisation was wrong

I reported 0x634 as a register that never responds. After a full night of data, that is not accurate. Every one of the 67 timeouts logged overnight landed on a different register, 0x103 (Max Power Charging, REG_INPUT):

Error: device: 70 address: 0x103 -> Modbus Error: [Input/Output]
No response received after 1 retries, continue with next request

67 occurrences, 23:25 -> 09:03

0x634 only failed during a short window yesterday evening, while I happened to be watching. So this is not a dead register: it is sporadic read timeouts landing on varying addresses, roughly 2 % of poll cycles at a 10 s interval. Sorry for the misleading title - I generalised from a single observation, and I have now corrected it.

Raising time_out from 5 to 15 s in the hub options made no difference, and the message still reports after 1 retries, so the retry count looks fixed at 1.

The reporting inconsistency I mentioned still stands, and may be the more useful lead:

communication_health                 Degraded
communication_success_rate           100.0 %
communication_quarantined_registers  0

All 27 enabled sensors keep updating throughout, so the failures are recovered on the following cycle - but communication_health never returns to Healthy.

Point 1 is unchanged, and still exact this morning

charge_added_cumulative      21 141 913.6 kWh   (Modbus)
charge_added_total                322.6 kWh    (independent HTTP integration)

322.6 x 65536             =  21 141 913.6       difference: 0.0

charge_added_total                  0.0 kWh    (Modbus)

Happy to run any test that helps.

[TCWORLD]

It would be useful if you could test 2026.07.1. The word order was flipped in 2026.07.2 which goes against the documentation but apparently worked for one person. I wonder if this is a case of a firmware glitch in some versions reporting reversed word order while others reporting correctly.

[adambogocz]

Hello, my setup also broke, downgrading to 2026.07.1 fixes the problem, the number is now reported correctly.

[adambogocz]

I have checked #2178 and it seems that the dev was targeting/testing X3 EVC 11kW, a first gen charger, me and the reporter have X3-HAC a second gen EVC.

EDIT:
For full info my X3-HAC is running ARM v11.04, had beed using it with solar-modbus for past 2-3 months, no issues until 2026.07.2

[adambogocz]

Also checked my friend installation who have

X3-EVC-11kW
od SolaX Power
Firmware: ARM v1.18 (latest FW)
Hardware: Gen1

That his cumulative total energy reports 801,30 kWh, which is correct, so the #2178 part of EVC patch should apply only to 1st gen

[TCWORLD]

Thanks for confirming. That makes it easier to resolve.

[TCWORLD]

@adambogocz With the latest version (2026.7.4) installed, could you manually apply the patch in the linked PR for both yours and your friends setups then restart HA.

Hopefully with that change applied both will report the correct value.