EVC: fix segmented-register reads (vendor-confirmed); firmware-version gating; doc-aligned entities

[Bl00d-B0b]

Stacked on #2279 (sub-device infrastructure), which the EV Parallel sub-device uses. Review the last commit only — the diff includes the parent until it merges.

SolaX support (ticket 703158, replying to my bug report about MaxChargeCurrent reading 0) disclosed that the EVC holding registers are internally segmented: 0x600-0x650 is one segment and 0x660-0x66F another (used for internal master-slave parallel operation). A function 0x03 read spanning the boundary silently returns 0 for second-segment registers.

Reproduced on an X3-EVC-11kW Gen1 (serial C31103I9612443, ARM V1.18):

Read	Value at 0x668
single register 0x668	1600 (16.00 A)
0x660 count 16 (within segment)	1600
0x640 count 48 (crosses boundary)	0
0x64C count 32 (crosses boundary)	0

Everything below was verified on that charger over Modbus TCP, and the register semantics were confirmed with SolaX support.

Segmentation fix

• newblock=True on the Max Charge Current readback pins the read-block boundary at 0x668, so no read can cross the segment boundary.
• block_size returns from 32 to the default 100 - the 32 was a blind workaround for this same symptom (fix(solax): unify firmware version display and key naming across all inverter types #2064), added before the segmentation was known. Both resulting holding blocks and the input blocks were verified against single-register reads.

Firmware-version gating

The plugin now reads its firmware version once at startup (input 0x25, e.g. V1.18 -> 118) and publishes it as hub.modbus_protocol_version, activating the existing modbus_min/modbus_max machinery for EV chargers. Thresholds come from the protocol document's revision history and its protocol-to-firmware matching table.

Every register that moved across firmware versions is now one entity identity whose backing register follows the firmware - the Alt-suffixed duplicates are gone:

Entity	Legacy register	Current register
Charge Power / L1/L2/L3	0x08-0x0A (<= V1.11)	0x100-0x102 (>= V1.12)
Run Mode	0x1D (<= V1.11)	0x106 (>= V1.12)
Charge Phase (select)	0x625 (<= V1.10)	0x63B (>= V1.11)
Charge Mode	0x104 sensor (V1.12-V1.13)	0x641 select (>= V1.14); 0x669 select on GEN2

Other dated entities (control_command, charge_current, the boost family, modbus_address, the 0x100 input block) carry matching modbus_min gates. Unknown firmware falls back to the legacy definitions.

Max charge current

Support suggested using the documented 0x64F (limit_current_allmode) for the maximum current, and clarified its behaviour: 0x64F is the Modbus-dedicated current setting - writes only take effect while a vehicle is connected, and it reverts to the charger's rated maximum when the gun is unplugged, whereas the value written from SolaXCloud is the persistent setpoint in 0x668. (Our earlier write tests to 0x64F appeared to be ignored because they were all performed with no vehicle connected.) Support also confirmed that the charger caps the actual charging current at its rated value regardless of what is written to 0x668.

Accordingly:

• Max Charge Current stays on 0x668, the persistent setpoint SolaXCloud itself writes;
• a new optional max_key field on number descriptions dynamically overrides native_max_value from a sensor value. It is fed by the charger's rated current, derived from TypePower (0x21) and TypePhase (0x22) - 11 kW three-phase gives 16 A - so the slider ceiling matches the hardware and never follows a dynamic setpoint. It falls back to the static maximum if those registers cannot be read.

Parallel entities

SolaX support provided the Gen1 meaning of 0x0642, which the document still describes as an on/off enable: 0 = Master, 1 = Slave, 2 = Parallel operation with Gen2 chargers. It is exposed as a **Parallel Role is a read-only diagnostic sensor: live testing showed writes are accepted but an internal sync re-asserts the stored value after 10–15 seconds, so a writable control would silently revert.

Both appear only on chargers that actually support parallel operation: the type detection probes 0x0107 at startup and sets a PARALLEL_TYPE feature flag, the same pattern the plugin already uses for OCPP detection via 0x0023.

Other doc-based entities and alignments

New (disabled by default unless noted): Unbalanced Power 0x63C + Unbalanced Switch 0x63D (X3, >= V1.11), Mode Button 0x63E and Min Charge Current 0x63F (>= V1.12), Datahub Charge Power 0x643 and Green 30s Delay switch 0x644 (>= V1.14), and the string diagnostics Serial Number 0x600, WiFi S/N 0x607, Customized S/N 0x629 (standard REGISTER_STR sensors; the startup serial read used for model detection is unchanged).

Alignments: Overload Limit renamed Overvoltage Limit (doc: OverVoltSet, 1 V); Charger Type name unified across GEN1/GEN2 (options stay per-generation); RSSI renamed WiFi RSSI; per-phase Charge Current sensors and Datahub Charge Current consistently disabled by default; charge_added_cum second definition narrowed from GEN2 | GEN3 | GEN4 to GEN2 (no GEN3/GEN4 EVC exists or is detected); the X1 measured-current diagnostic (input 0x4) renamed key charge_current -> charge_current_measured, which previously collided with the setpoint readback and made the Charge Current number flicker between setpoint and measurement.

Input 0x2D–0x30 (Lock State, Main Breaker Limit State, Random Delay State, Ban State) are gated to second-generation chargers: SolaX support confirmed these registers do not exist on Gen1 and will be removed from the Gen1 protocol document.

Platform fixes

Modbus switches and numbers now publish the accepted value locally after a successful write, instead of waiting for the next readback poll. Without this the entity keeps reporting the previous value until the register is polled again, which shows up as a switch flipping back or a slider snapping back for one cycle.