Eveus EV Charger — Home Assistant integration (local-only, HACS)

Share your Projects! Custom Integrations
, ,
1

Hi all :waving_hand: I've been maintaining a Home Assistant integration for Eveus EV chargers and wanted to share it with the community. It's local-only — polls the charger directly over your LAN, no cloud account, no telemetry.

Repo: GitHub - ABovsh/eveus: Eveus EV charger integration for Home Assistant (HACS) — local-only, no cloud. Live power/energy/cost, SOC estimates, adaptive charging. · GitHub
HACS: Custom repository (instructions below)

What it does

  • Local polling over LAN via the charger's HTTP API. Supports http:///https://, custom ports, IP or hostname.
  • Live electrical telemetry — voltage, current, power, current-limit setpoint, box/plug temperatures, ground status, internal backup battery voltage.
  • Energy & cost straight from the charger's own counters, so values don't jump when tariffs switch mid-session:
    • Session / Total Energy, resettable Counter A & B (kWh)
    • Session Cost (uses native sessionMoney, integrated at the active rate per moment)
    • Counter A/B Cost, Primary/Active/Rate 2/Rate 3 rate sensors
  • Optional EV battery (SOC) estimates — add four input_number helpers and you get SOC kWh, SOC %, time-to-target, and a device_class: timestamp Charging Finish Time for cards & automations.
  • Adaptive charging & schedule visibility — see which slot the charger is following.
  • Automation-friendly entities out of the box: Car Connected, Charging Finish Time, Session Cost — no template sensors required.
  • Multi-charger support.
  • Optimistic UI — controls feel instant; state reconciles on the next poll.

Why a separate integration?

Eveus has no official HA integration. This one is built around the charger's native fields (especially sessionEnergy and sessionMoney) instead of trying to recompute energy/cost in HA — which means no fragile per-restart baselines and no off-by-one when the day/night tariff flips.

Install (HACS)

  1. HACS → Integrations → ⋮ → Custom repositories
  2. URL: https://github.com/ABovsh/eveus, Category: Integration
  3. Install Eveus, restart Home Assistant
  4. Settings → Devices & services → Add Integration → Eveus, enter host/credentials

Feedback welcome

Issues, feature requests, and PRs all go to the repo. Thanks :folded_hands:

2

New 4.9.0 version of the integration is out

What's new:

  • Writable schedules. Both on-device slots get a full HA control surface:
    • switch.eveus_schedule_1_enabled / schedule_2_enabled — arm / disarm.
    • time.eveus_schedule_1_start / _stop and schedule_2_start / _stop — native HA time pickers. Shift the window from a card, a script, or an
      automation.
  • Adaptive mode toggle. switch.eveus_adaptive_mode turns the charger's voltage-sag throttle on / off, complementing the existing Adaptive
    Charging / Current Limit / Voltage Threshold diagnostic sensors.
  • Clock & time zone.
    • select.eveus_time_zone — readable/writable time-zone offset (-12..+14).
    • button.eveus_sync_time — push HA's current time to the charger. No more drifting clocks.
  • 3-phase support. New Phases field (1 or 3) in setup and reconfigure. When set to 3, you get four extra sensors: Current Phase 2/3 and
    Voltage Phase 2/3. Existing single-phase setups migrate transparently.
  • Leakage current sensors.
    • sensor.eveus_leakage_current (mA) — live RCD reading.
    • sensor.eveus_leakage_current_peak (mA) — peak-hold, useful for catching transient faults.
  • Quick refresh. button.eveus_force_refresh triggers an immediate coordinator poll instead of waiting for the next tick.
  • Lovelace dashboard. docs/dashboard.yaml in the repo.

Fixes worth calling out:

  • Starting a charging session now reflects in HA within ~10–20 s instead of taking up to a minute for the next idle poll.
  • Connection Quality reports unknown on internal error instead of falsely showing 100%.
  • Reconfigure / reauth / repair flows preserve device_number correctly in multi-charger setups.

Security & UX: masked password fields in setup and reauth; diagnostic dumps redact host and unique_id in addition to credentials; a warning is logged when the charger is configured over plain HTTP.

Heads-up: if you had switch.eveus_reset_counter_a referenced anywhere, it's been replaced by button.eveus_reset_counter_a (proper one-shot
action). button.eveus_reset_counter_b mirrors it.

Release notes & full changelog: Release v4.9.0 · ABovsh/eveus · GitHub

As always — feedback, bug reports, and feature requests very welcome.

3

Eveus update — 4.9.1 → 4.9.2

Two releases since the 4.9.0 post above. Headline items are two new sensors and a batch of reliability/statistics fixes.

New sensors (4.9.2)

  • sensor.eveus_wifi_signal — WiFi signal strength (dBm) straight from the charger. If you ever see polling hiccups or entities briefly
    going unavailable, this lets you correlate it directly with weak RF at the charger's spot. Nice on a history card next to Connection
    Quality.
  • binary_sensor.eveus_session_active (device_class: running) — turns on whenever a charging session is running, and stays on
    through brief mid-session pauses    . Use it as a single, clean automation trigger instead of templating on the textual State sensor.

Statistics & cost (4.9.2)

  • Cost sensors now use HA's monetary device class (UAH) — Counter A/B Cost and Session Cost accumulate correctly across session
    and counter resets, and the Energy dashboard can pick them up as costs. Per-kWh tariffs still display ₴/kWh. You may see a one-time "units
    changed" notice after upgrading.
  • SOC Energy and Session Energy use valid sensor types — clears an "impossible state class" warning at startup; history is
    unaffected.

Reliability & correctness (4.9.1 + 4.9.2)

  • Corrupt or impossible readings now show unknown instead of plausible-but-wrong values — voltage, current, power, per-phase, leakage,
    battery voltage, WiFi signal, tariffs, and the charger clock. Current Set is also bounded by your model's max (e.g. 40 A on a 16 A unit
    reads unknown).
  • Non-Eveus / partial responses are refused — a captive portal or proxy can no longer bring the integration online with blank or garbage
    values.
  • Controls survive a restart while the charger is offline — Charging Current, schedule pickers, and switches keep their restored value
    through the grace window instead of dropping to unknown/off.
  • Smarter connection handling — transient 5xx/429/network errors back off properly, permanent 4xx command errors fail fast, and a
    401 kicks off reauthentication.
  • A paused-but-active session keeps fast polling — SOC sensors and charging-time estimates no longer slow to the idle cadence when a
    session pauses mid-charge.
  • Time Zone no longer snaps back to the old offset before the next poll, and Car Connected reports unknown (not "unplugged")
    while the charger is in an error state.
  • Connection Quality reads unknown before the first poll / on internal error instead of a misleading 100%.

Privacy

  • Stored password is never echoed back to the reauth/reconfigure form.
  • Logs and connection errors no longer include the charger host/IP.
  • Richer Device page & safer diagnostics — real model/manufacturer/HW/serial on the Devices view, and Download diagnostics ships a
    full sanitized /main snapshot with serial, station ID, LAN IP, firmware CRC, and anything address/SSID/MAC/token-like auto-redacted.

Still local-polling only, HACS-installable, no cloud. Update via HACS and reload — no entities renamed or removed since 4.9.0, so existing
setups upgrade transparently.

Full details: CHANGELOG.md

4

:package: Release catch-up: 4.10.0 → 4.15.0

The thread fell a few releases behind — here's everything that landed since 4.9.2, oldest to newest. All on HACS;

4.10.0

  • :ukraine: Full Ukrainian localization — every entity name, setup screens, mode options and notices; appears automatically when HA runs in Ukrainian (entity
    IDs unchanged).
  • Automatic SOC inputs — the four battery inputs are now native number.eveus_ev_charger_* entities instead of hand-made input_number.ev_* helpers,
    with new Basic / Advanced integration modes (switch anytime via Configure; existing SOC users migrate automatically).
  • OCPP control — a Connect to OCPP switch links/unlinks the charger's backend straight from HA, with a binary sensor for the live state and a
    Repairs notice (that clears itself) while OCPP is on.
  • Minimum Home Assistant version is now 2025.1.

4.10.1

  • Snappier, consistent controls — dragging the Charging Current slider or quickly re-tapping a switch no longer flashes an older value, and a slow
    reply can't overwrite your newest command.
  • Clean mode switching — entities that no longer apply (SOC entities in Basic, phase 2/3 sensors in single-phase) are removed instead of left behind as
    unavailable; the cleanup waits for a successful reload so nothing is lost during a brief outage.
  • Statistics hardening — energy, cost, temperature, leakage and SOC sensors ignore corrupt/impossible readings, so one glitch can't poison history or
    fake a "target reached".

4.11.0

  • Low charger battery warning — Repairs notice when the charger's internal CR2032 coin cell runs low; clears itself once replaced.
  • Controls recover cleanly across backward system-clock jumps (NTP/VM resume), Time Zone keeps your selection through outages, and more corrupt
    readings safely read as unknown.

4.12.0

  • Safety notices in Repairs — missing or disabled ground, current leakage, box/plug overheating (early warning at 80 °C, before the 85 °C cutoff),
    and relay/pilot/diode/overcurrent/voltage/GFCI faults. Self-reported faults alert immediately; raw checks need several consecutive readings + recovery
    hysteresis so a single glitch can't raise a false alarm. Plain-language messages in EN/UK.
  • Ground Protection switch (switch.eveus_ev_charger_ground_protection) mirrors the charger's groundCtrl — block charging without a detected ground,
    or allow it.

4.12.1

  • Fix: setup/reconfigure could be rejected with "value must be one of [1, 3]" on some frontends (the mobile app submits the Phases dropdown as text) —
    now handled.

4.13.0

  • Energy to Target SOC and Cost to Target SOC sensors (Advanced) — kWh still needed from the grid (losses included) and its cost at the current
    tariff.
  • Drifted-clock Repairs notice — warns when the charger clock is >10 min off and walks you through Time Zone → Sync Time; clears once they genuinely
    agree.
  • Advanced mode now prompts for battery capacity/efficiency instead of generic defaults; externally started charging shows up faster; a powered-back-on
    charger reappears within ~1 min; a wrong password no longer looks like "offline".

4.14.0

  • Time Drift sensor replaces System Time — shows the charger-clock offset in seconds (0 s = in sync) without writing a recorder row every poll
  • Device page shows both firmware versions the charger reports again; plus reliability fixes — Connection Quality and estimates stay readable through
    outages, a sub-7 A current set on the charger no longer makes entities unavailable, and broad hardening against corrupt charger data.

4.15.0 :star:

  • Charge limits from HA — Time / Energy / Cost session limits, each with its own enable switch plus a master Limit: disable all; Stop at
    Target SOC     (Advanced) halts charging when the car hits your target level; and per-schedule current/energy caps.
  • Adaptive Mode is now a selector — Off / Voltage / Auto / Power (the old switch could only force Voltage and couldn't show the active mode) — and
    the undervoltage threshold is an adjustable number (210–220 V) instead of a read-only sensor.
  • Minimum voltage dropdown sets the charger's undervoltage threshold (150–200 V).

:warning: 4.15.0 replaces the old Adaptive Mode switch and adaptive-threshold sensor (auto-removed on update) — update any automations or dashboard cards
that referenced them.

:link: Latest release: Release v4.15.0 · ABovsh/eveus · GitHub
:clipboard: Full changelog: eveus/CHANGELOG.md at 5f5ae12b53847c0967b2f60bcea1b2220fb8cecd · ABovsh/eveus · GitHub
Everything installs/updates via HACS.

5

Writing here, because I'm still unable to solve my issue: cannot connect my Eveus Pro charger via HA integration.
I'm getting "Failed to connect to charger, please verify the IP address", but I'm successfully connecting to chargers' GUI via browser by that IP. Can you suggest something?

I'm suspecting old firmware of the charger ( GRM070A-R3.01.8 and GRW001A-R3.01.8) and can't update it, because checking new version on the Update page says "Connection to station lost"

6

The issue resolved by updating firmware on the charger itself. Thanks a lot to @ABovsh for help!

1 Like
7

Hi, @sh3vik
I have the same problem (version GRM070A-R3.01.8). How did you manage to update firmware? Help me, please.

8

@ABovsh can you help me, please?

1 Like
9

Hi @Mike-Opanasiuk - based on the previous case (sh3vik's report above) I changed how the integration handles setup to extend compatibility - it now accepts a charger even when its firmware returns a non-standard response, instead of just failing with "Failed to connect." That shipped in 4.16.0, which is the latest version.

Can you please check the following and share the results with me:

  1. What integration version are you currently on (Settings → Devices & Services → Eveus, or HACS)?
  2. What's the exact error you're getting when adding the integration?

As for updating the charger's firmware, here are two options:

  1. If you have the Grizzl-E app linked to your charger, you can push the firmware update from there directly.
  2. If not, message @energy_star on Telegram — he can add you to the charger channel where the update files and instructions are shared.
10

@Mike-Opanasiuk - there is one more thing that would help me solve the issue for R3.01.8 owners once and for all: seeing what your charger actually answers on its API endpoint. Could you run these two commands from any computer on the same network (use the same IP, username and password that work in the browser):
curl -i -sS -X POST -u eveus:YOUR_PASSWORD http://CHARGER_IP/main
curl -i -sS -u eveus:YOUR_PASSWORD http://CHARGER_IP/main
and paste the full output here? Feel free to mask the serial number or any address-like values in the body first. On Windows, curl.exe in PowerShell works the same.
That output will show exactly where the integration's request fails on your firmware - and whether I can add support for it without requiring a firmware update.

11

Releases 4.16.0 and 4.17.0

Two updates since the last post re newer versions here.
4.16.0

  • 40A charger model — setup now offers a 40A option alongside 16A/32A/48A, for EVEUS Pro units whose hardware maximum is 40 A.
  • Older firmware now should be added without setup errors — setup accepts any responding Eveus charger instead of rejecting units whose older firmware reports fewer fields.
  • Setup tells you what actually went wrong — a reachable charger that doesn't return a valid Eveus response now gets a specific "invalid response" message instead of a generic "Failed to connect".
  • Target-SOC timing is now exact (no more stopping up to ~0.5% early on large batteries), Time Drift clears after a clock sync, sub-7A setpoints set on the charger are displayed, and a batch of smaller fixes.

4.17.0

12

@ABovsh Here is response:

It seems strange, that instead of showing my serialNum it shows � symbols only:

curl -i -sS -X POST http://192.168.0.102/main
HTTP/1.1 200 OK
Content-Type: application/json
Content-Length: 1748
Access-Control-Allow-Origin: *
Allow: HEAD,GET,PUT,POST,DELETE,OPTIONS
Access-Control-Allow-Methods: GET, POST, PUT
Access-Control-Allow-Headers: Content-Type

{
"verFWMain": "GRM070A-R3.01.8 ",
"verFWWifi": "GRW001A-R3.01.8",
"serialNumCPU": "",
"serialNum": "�����������������",
"stationId": "",
"fwCRC32": "23C0A223",
"verFWStatus": 1,
"pilot": 0,
"state": 2,
"subState": 0,
"currentSet": 20,
"curDesign": 32,
"minCurrent": 7,
"minVoltage": 180,
"gridRange": 0,
"typeEvse": 1,
"typeRelay": 0,
"aiModecurrent": 7,
"aiStatus": 0,
"aiVoltage": 200,
"aiVoltageStart": 0,
"aiVoltageDrop": -224,
"aiPowerDrop": 0,
"ground": 1,
"groundCtrl": 0,
"tarif": 100,
"activeTarif": 0,
"tarifAEnable": 0,
"tarifBEnable": 0,
"tarifAValue": 100,
"tarifBValue": 100,
"tarifAStart": 0,
"tarifAStop": 0,
"tarifBStart": 0,
"tarifBStop": 0,
"timerType": 0,
"timeZone": 0,
"systemTime": 1782977307,
"timeMsg": 0,
"timeLimitS": 0,
"energyLimitS": 0,
"moneyLimitS": 0,
"evseEnabled": 0,
"suspendErrors": 0,
"suspendLimits": 0,
"oneCharge": 0,
"delayedLimit": 0,
"timeLimit": 0,
"energyLimit": 0,
"moneyLimit": 0,
"sh1Enabled": 0,
"sh1Start": 0,
"sh1Stop": 0,
"sh1CurrentEnable": 0,
"sh1CurrentValue": 12,
"sh1EnergyEnable": 0,
"sh1EnergyValue": 0,
"sh2Enabled": 0,
"sh2Start": 0,
"sh2Stop": 0,
"sh2CurrentEnable": 0,
"sh2CurrentValue": 12,
"sh2EnergyEnable": 0,
"sh2EnergyValue": 0,
"totalEnergy": 0,
"sessionTime": 0,
"sessionEnergy": 0,
"sessionMoney": 0,
"sessionStarted": 0,
"IEM1": 0,
"IEM2": 0,
"IEM1_money": 0,
"IEM2_money": 0,
"curMeas1": 0,
"curMeas2": 0,
"curMeas3": 0,
"voltMeas1": 224,
"voltMeas2": 0,
"voltMeas3": 0,
"powerMeas": 0,
"temperature1": 22,
"temperature2": 22,
"leakValue": 0,
"leakValueH": 28,
"vBat": 3.0199999809265137,
"adapter": 255,
"scanComplete": 0,
"lang": 1,
"STA_IP_Addres": "192.168.0.102",
"RSSI": -39
}

13

@ABovsh you cannot even imagine how thankful I am. I have resolved the issue by messaging @energy_star.

What did I do:

  1. Messaged @energy_star.
  2. He shared bin with 1PGRW001A-R3.05.5 update. I've opened http://192.168.0.102/update and uploaded that bin archive.
  3. After update @energy_star shared a serial number which I entered in "Advanced" section on http://192.168.0.102 in serial number field and applied changes.
  4. Finally, I opened grizzl-E app on my iPhone and was able to connect my charger via serial number (via wi-fi it does not work).

I really appreciate your help!

1 Like
14

@Mike-Opanasiuk Sure, no problem - glad it worked out! BTW, your curl output turned out to be really valuable: based on it I identified exactly why the integration couldn't connect on your old firmware - and it was precisely the serial number. When no serial has ever been entered on the charger, that firmware returns raw garbage bytes in the serialNum field (that's what the � symbols were), and the integration treated the whole response as unreadable and failed setup. Everything else in your charger's output was perfectly fine. So thanks to your report, the upcoming version improves compatibility with old firmwares.

15

Release 4.18.0

  • Charging events + device triggers — the integration now fires events on real charger transitions: charging started/finished, car connected/disconnected, error. The finished event carries the session summary (energy, cost, duration), and all of them show up in the automation editor as ready-made device triggers — no manual event YAML.
  • Last Session sensors — the charger clears its session counters when the next session starts, so the previous session's totals used to vanish as soon as you plugged in again. Three new sensors (last_session_energy, last_session_cost, last_session_duration) capture each finished session and keep it across HA restarts and charger downtime; past sessions stay visible in the sensors' history.
  • State and Substate are enum sensors now — automation state triggers offer a dropdown of all possible values instead of a free-text field.
  • Better old-firmware compatibility — chargers with an unset serial number (seen on GRM070A-R3.01.8) can now be added; setup doesn't require the full field set from the firmware; the setup dialog states the specific connection failure (HTTP status, timeout, invalid response) with details logged without debug logging; and the README gained a section on updating the charger firmware via its web interface.

Full changelog

16

Hi! Thanks a lot for developing and maintaining this integration.

I have a feature request regarding the SOC_MODE_ADVANCED behavior. Currently, EVSocPercentSensor and other related EV metrics rely entirely on the internal soc_calculator (calculating SOC based on charged energy/kWh).

Many Home Assistant users (myself included) have direct access to their vehicle’s telemetry via third-party integrations, which provide an exact battery_level / SOC sensor directly from the car.

Proposed Feature / Improvement: It would be amazing to have an optional setting in the integration configuration (or Options Flow) to specify an External Vehicle SOC Sensor (e.g., sensor.car_battery_level).

  • Default Behavior: If no external sensor is provided, the integration continues to work as it does now (using purely calculated values).

  • Enhanced Behavior: If an external sensor is set:

    1. The integration uses the real vehicle SOC as the initial baseline when charging starts (or updates dynamically when available).

    2. The soc_calculator automatically aligns/recalibrates its calculated metrics (TimeToTargetSoc, EnergyToTargetSoc, CostToTargetSoc, etc.) based on this real telemetry.

This would significantly improve accuracy for target SOC calculation, charge completion time estimates, and cost forecasting without requiring manual initial SOC input.

Thanks for considering this enhancement!

17

Hi @IMitsan, thanks for the feature request - it’s in 4.20.0, partially.

You can now point the integration at your car’s battery sensor (setup, or Configure → Car SOC sensor, Advanced mode only). Its reading becomes the Initial SOC when charging starts, so no more setting it by hand. Leave it empty and nothing changes.

The continuous re-sync during charging I decided against. Car integrations differ too much to trust mid-session: they sleep, they poll every 15–30 minutes, they go unavailable, and some keep publishing the last known value as if it were current. That last case is the one that worries me - a stale reading looks perfectly valid, and every derived number would follow it: SOC, Time to Target, Energy to Target, Cost to Target. The charger’s own energy meter is local, polled constantly, and never sleeps, so it stays the source between readings. The car gives the best single reference point, and that’s exactly where it’s used.

If you hit any issues with the new version, let me know. Thanks.

18

Two updates since the last post here.

4.19.0

  • Not Charging Reason sensor — the car is plugged in but nothing is happening, and one sensor now tells you why: Waiting for Car, Stopped by User, Energy/Time/Cost Limit Reached, Waiting for Schedule, Paused by Adaptive Mode, Charge Complete, Error and more. Previously that meant reading State and Substate together and knowing which substate texts apply in which state. The automation editor offers the full list as a dropdown.
  • Six more sensors are dropdowns in the automation editor — Ground, Rate 2/3 Status, Adaptive Charging and Schedule 1/2 now declare their full set of values, so an automation can’t sit there never firing because of a misspelled state. Existing automations keep working.
  • Rate 2 and Rate 3 Status moved out of Diagnostics to sit beside their costs on the device page. Entity IDs unchanged.
  • No more phantom “charging started” while the car sits plugged in and idle — if the charger left its firmware version out of a single reply, that reply was read as firmware 1.x and could flip State to Charging and fire the event. The firmware generation is now worked out once and remembered.
  • Dashboard and docs — Not Charging Reason added to the Status card, a broken “Final SOC” row removed from the Last Session card, and the README gained a guide for adding the charger to the Energy Dashboard.

4.20.0

  • Initial SOC can fill itself in from your car’s own battery sensor — pick a sensor with device class battery during setup or under Configure → Car SOC sensor (Advanced mode only), and its reading becomes the Initial SOC when charging starts. It’s read once per plug-in, so pausing, stopping and restarting, or topping up after Charge Complete don’t re-read it; if the car is asleep when charging begins it keeps trying until a reading arrives. A value you set by hand is never overwritten. Optional and empty by default — leave it empty and nothing changes.
  • A charging session cut short by a charger fault is now recorded like any other — when the charger tripped into Error and then settled into Standby, Connected or Charge Complete, the session was never reported as finished: Last Session Energy, Cost and Duration kept showing the previous session and the finished trigger never fired.
  • SOC Energy and SOC Percent no longer dip to the Initial SOC value if the charger leaves session energy out of a single reply — that used to read as “0 kWh delivered so far” and pulled both sensors back to where the session started before snapping back on the next reply.
  • Diagnostics now include a soc block — the four SOC inputs, the configured car sensor and what it reads, and whether this plug-in was filled in or the reason it wasn’t.
  • The Last Session sensors no longer store an arbitrary “reason” sent by anything on the event bus — the numbers were already re-checked; the reason text now gets the same treatment.

Full changelog: eveus/CHANGELOG.md at 6ff8c668cb72612cd752c39841aee59347347632 · ABovsh/eveus · GitHub

19

[quote=“ABovsh, post:17, topic:1010628, full:true”]
Hi @IMitsan, thanks for the feature request - it’s in 4.20.0, partially.

You can now point the integration at your car’s battery sensor (setup, or Configure → Car SOC sensor, Advanced mode only). Its reading becomes the Initial SOC when charging starts, so no more setting it by hand. Leave it empty and nothing changes.

The continuous re-sync during charging I decided against. Car integrations differ too much to trust mid-session: they sleep, they poll every 15–30 minutes, they go unavailable, and some keep publishing the last known value as if it were current. That last case is the one that worries me - a stale reading looks perfectly valid, and every derived number would follow it: SOC, Time to Target, Energy to Target, Cost to Target. The charger’s own energy meter is local, polled constantly, and never sleeps, so it stays the source between readings. The car gives the best single reference point, and that’s exactly where it’s used.

Thank you very much for implementing the Car SOC sensor feature in 4.20.0!

I have updated to 4.20.0, selected my car’s battery sensor in Configure → Car SOC sensor, and tested it.

Everything works exactly as described. The integration takes the car’s actual SOC as the Initial SOC when a new charging session starts. I confirmed that the Initial SOC is updated at the beginning of the session, while it is not continuously re-synced during charging.

I think your decision not to continuously synchronize the SOC during the session is a very good one. The car’s SOC sensor can indeed be delayed or become unavailable, while the charger’s session energy is a much more reliable local source for calculating the SOC during an active charging session.

So the feature works perfectly for my use case, and I no longer need to set the Initial SOC manually.

Thanks again for the quick implementation and for considering the feature request!