I’d like to share a custom integration I’ve been building over the past months: EV Assistant. In short, it handles the tracking and accounting side of running an EV — the part evcc intentionally doesn’t cover.
The idea
evcc is excellent at charge control (PV surplus, dynamic tariffs, departure planning) — but it only ever sees your own wallbox. The moment your car charges somewhere else, evcc is blind to it. EV Assistant fills exactly that gap and acts as the cross-location evaluator: evcc stays the controller, EV Assistant does the whole-picture accounting across every charging location.
What it does
Off-site charge detection without GPS — spots charging away from home purely from the SoC trend, then asks you for the actual kWh/cost from the receipt
Automatic logbook from the odometer, with CSV export
Cost & CO₂ comparison against an equivalent combustion car (fuel price as a fixed value, a live entity, or automatic Tankerkönig station lookup)
Charging-location breakdown — home vs. off-site, incl. an AC/DC split and per-provider stats
Battery SoH & equivalent full cycles estimated from real charge cycles
Temperature-aware range estimate from your real-world consumption
Leasing mileage budget with a projection to contract end
Maintenance tracker (roadworthiness test, inspection, or freely named) with km and calendar-month intervals
Optional evcc mode control — from a learned weekday usage profile it writes charge mode + target SoC back to evcc (opt-in, off by default)
Built-in sidebar panel, multi-vehicle support, German + English
Being honest about the stage: this is a beta.
I want to be upfront: the integration is feature-rich and well tested (~350 automated tests right now), but real-world testing has so far mostly happened on one setup — a Stellantis vehicle (SoC via the manufacturer’s cloud integration), one evcc version, one wallbox. The detection lives and dies by the quality of the SoC signal, and that’s where real-world variety is huge.
So I’m specifically looking for testers with other vehicles, other SoC-reporting behaviour, other evcc versions and wallboxes. Feedback on those is genuinely wanted — that’s exactly how the detection gets more robust. Two things to know up front:
Leave the evcc write control off at first and just observe (the evcc_mode_control sensor computes its recommendation whether or not writing is enabled). Only turn it on once the recommendations look sensible to you. When active, it sets evcc’s charge mode and min/target SoC — it does not decide where the power comes from (solar/grid/battery); that stays entirely evcc’s job.
Usage profiles need roughly two weeks of buildup before they’re reliable.
All known limitations are stated openly in the README under “Status & Known Limitations”.
Installation (HACS custom repository — not in the default store yet):
There’s a bug-report template that asks for the details that matter (vehicle, how it reports SoC, evcc version…) and an anonymised diagnostics download — that helps me track things down enormously.
I’d love feedback, bug reports and experience from other setups. Thanks for reading!
Just a quick heads-up based on my experience with my own custom car-data analytics integration:
Be careful with some of the Renault integration sensors. They can occasionally produce unrealistic spikes, which may then affect subsequent calculations and statistics.
In my case, one of these spikes resulted in completely unrealistic energy consumption values, as you can see in the screenshots.
I’m now updating my integration to detect and filter out implausible sensor spikes before they are used for any further calculations.
Funny timing – I hit the same class of problem independently, just from a different source: two production cases on my own setup came in via WiCAN/CAN-bus, not a manufacturer cloud integration, but the symptom was identical – physically impossible jumps (3 percentage points in 12 milliseconds, 23 points in 7 seconds) getting logged as completed off-site charges.
I’ve since added a plausibility check to the charge detector: it now discards a detected charge whenever the implied charging power (energy ÷ duration) exceeds 150 kW, checked both for the whole session and for each individual rise step while a session is already active – so a spike partway through a legitimate charge can’t hide behind time already spent charging normally. It’s intentionally source-agnostic rather than Renault- or WiCAN-specific, since the underlying issue (an occasional bad raw reading that isn’t filtered at the sensor level) doesn’t seem to be limited to one vehicle brand or telemetry path.
Given you’re seeing it on the Renault side too, if you ever get a chance to try EV Assistant on that setup I’d be very curious whether the 150 kW threshold catches your spikes as well, or whether Renault’s reporting produces a different failure shape that needs its own handling. Screenshots like yours are exactly the kind of real-world case that’s hard to reproduce synthetically.
Biggest change for anyone without evcc: setup now explicitly asks “how do you charge at home?” (evcc vs. generic wallbox sensors) and routes into its own “Home charging” step accordingly. If you just have a plain wallbox without evcc, you now get a per-session solar-share/cost estimate (needs a PV generation meter, home consumption meter, wallbox energy meter, and feed-in price) — computed the same way as evcc’s own real-time PV override, just without evcc in the loop. The wallbox status card in the panel now works without evcc too.
More robust evcc vehicle matching: name matching between HA and evcc is now tolerant of accent/diacritic differences (Unicode normalization), with a Repair issue raised if it still can’t find a match.
Panel: hideable tabs (Leasing/charging cards/maintenance, if you don’t use them), the three charge-control cards (automatic mode, buffer, charge plan) are now one consolidated card, a live event log with filtering, and config backup/restore.
Battery protection: new configurable max target SoC for the automatic charge control (default 80%), so it doesn’t charge to 100% every single day — the separate opt-in weekly full charge for cell balancing is unaffected.
Also a couple of solid bugfixes: hit Home Assistant’s 16KB attribute limit on the trip/charge history (now served via dedicated WebSocket commands instead of a sensor attribute), and a chain of tricky baseline bugs in the daily/weekly/monthly kWh & cost figures (triggered by evcc’s own session log shrinking over time) got fixed.
Currently at 0.99.22, 439 automated engine tests passing. Still beta as always — still very much looking for testers on other setups, especially anyone without evcc who can try the new solar-estimate path.
