EV charging in EMHASS: which use-cases should the docs cover? (and: would a Cookbook section help?)

[OptimalNothing90]

Following up on #789, which started as a question about @tomvanacker85's fork but turned into a real use-case sharing thread. Bringing it here as a discussion so it stays discoverable and we can keep adding patterns.

I'm running EMHASS + EVCC + Node-RED at home, tuning it week by week. EMHASS as the single planner, EVCC handling hardware enforcement, Node-RED in the middle. The patterns below are not theoretical, they're what I actually run. My aim is to get them into shape so the next user can copy a recipe instead of re-deriving it from scratch.

The new EV walkthrough is an early draft on purpose. It covers one pattern: windowed deferrable-load with pre-deadline kWh-target. That's the common case, not the only one.

Looking through #789, at least nine distinct EV use-cases came up. Worth crowdsourcing which deserve full first-class recipes (config + Node-RED/HA snippet + caveats) and which are better as variants on the existing ev.md page.

Use-cases from #789

1. Daily-deadline commute. "60% by 07:00 every weekday". Calendar or fixed schedule. (@tomvanacker85, @marst444, my setup)
2. Opportunistic / surplus-only. Charge from PV excess, never grid. Awkward in the deferrable-load model because the kWh-target is mandatory. (@PerretDavid, @TD944, @scruysberghs)
3. Multi-day weekend window. Plug Friday, deadline Monday morning. 24 h horizon doesn't span the window. (@PerretDavid)
4. Modulating-power chargers. Tesla 3.6–11.5 kW continuous. EMHASS schedules per-timestep on/off at nominal power, so modulation needs either parallel deferrable slots at different powers or post-processing. (@PerretDavid)
5. SoC-deficit-driven operating_hours. hours = (target_kWh - current_kWh) / charger_kW, recomputed per MPC call. Plug-aware: start_timestep = 2h_future when unplugged, 0 when plugged. (@purcell-lab, my setup)
6. Calendar-driven dynamic departure. Google Calendar events translate into deadline + target SoC. Manual edits adjust per-trip range. (@tomvanacker85)
7. Manual mode-selection. User toggle between PV-only, PV+grid, max-charge-now. HA UI selector switches between EMHASS plans or bypasses altogether. (@TD944, @xitation, my "Workday / PV-surplus / Voyage" pattern)
8. Negative-price aware with export-payment. 5-min spot export pricing, battery to 100% before peak-export window, EV charging fills around it. (@TD944)
9. EVCC dispatcher coupling. EMHASS as single planner, EVCC's own optimizer off, EMHASS plan drives evcc/loadpoints/N/mode/set per slot. (my setup, prototyping)

Plus the one @xitation already offered: a simplified pure-HA setup guide (no Node-RED, no EVCC) referenced via sigenergy.annable.me/emhass/, which David already invited to bring into the docs.

What to share

If you run EMHASS with an EV, drop a comment with: which pattern you use (one of the nine, or a new one), why the default deferrable-load didn't work for your case, the actual config or Node-RED/HA snippet, and the edge cases that bit you. Real numbers in runtimeparams payloads are gold. So is anything for modulating chargers (Tesla 3.6–11.5 kW is the worst fit for deferrable-load right now), multi-EV households, and calendar-integration patterns.

A meta-question to @davidusb-geek

Looking at these nine, plus what's already on other pages (DHW deadline profile, MPC payload templates, infeasibility triage), they're recipes. Short, focused, copy-pasteable solutions to "I want to do X with EMHASS". Not narrative walkthroughs like heat_pump_walkthrough.md, not parameter references like thermal_battery.md. They sit between the two, and study_cases/ is starting to feel mismatched as it picks up more of them.

A lot of Python projects solve this with a Cookbook section (scikit-learn is one example most readers know). Each recipe is short, follows a fixed template, stands on its own. Readers grep for "EV", "DHW", "Tibber".

Would a docs/cookbook/ folder be welcome? Walkthroughs in study_cases/ stay narrative, recipes get a scannable home. Happy to sketch an initial structure as a separate small PR if you're interested. If you'd rather keep everything under study_cases/, that's fine too, the recipes just go there.

Where this lands

I'll collect responses and post a normalized draft as a follow-up comment for community review before any PR. Best guess on outcome: 2–3 EV recipes (commute / surplus-only / multi-day), ev.md becoming a single-pattern intro, plus a good_practices.md section for cross-cutting bits. @xitation's pure-HA guide as its own page.

Comments not PR is fine. Screenshots, Node-RED flows, HA YAML all welcome.

cc @davidusb-geek @tomvanacker85 @scruysberghs @marst444 @xitation @PerretDavid @purcell-lab @TD944, since you all put real patterns into #789.

[davidusb-geek]

A lot of Python projects solve this with a Cookbook section (scikit-learn is one example most readers know). Each recipe is short, follows a fixed template, stands on its own. Readers grep for "EV", "DHW", "Tibber".

Would a docs/cookbook/ folder be welcome? Walkthroughs in study_cases/ stay narrative, recipes get a scannable home. Happy to sketch an initial structure as a separate small PR if you're interested. If you'd rather keep everything under study_cases/, that's fine too, the recipes just go there.

Yes a cookbook section is probably a good idea.
Maybe let's the study cases section house the simple onboarding cases (the current "Tutorial" section) and possibly some simple version of the "How-to guides — task-oriented". But then complete walkthroughs on a cookbook section.

[davidusb-geek]

A very related entry to this discussion here: #820
A tool for EV scheduling

[marst444]

Thnx for charing! Seems to work solemnly by a 7day timeframe, wich is infeasible for all dynamic tariff use-cases. But maybe can be modified. Definitely work in same area of interest!

[tomvanacker85]

This seems like a solution to my use case!

@marst444 : for some European users, EpexPredictor, does a more than decent job forecasting 15' electricity market prices which could be fed into the model.

[marst444]

Ah! Have you tried it? /do you use it? For a 7day horizon, only run MPC right? Day ahead is locked at 24hours.

[tomvanacker85]

Running MPC-optimization every 3 minutes for a 3 day horizon (288 timesteps). I used to copy the available EPEX-prices to fill the horizon, leading to large and obvious forecasting errors going from weekdays to weekends and vice versa --> clear improvement!

[marst444]

Hey @tomvanacker85 . not sure if I follow you. Is the EPEX forecast causing the big forecasting error? What led to big improvement? You say "going from weekends to weekdays"- is that something you specify in EPEX? Haven't had time to look into ye. Maybe clearer after doing so!

[marst444]

@OptimalNothing90
Great workup! I would love to see realize what you are suggesting. Maybe your very well outlined cases could be grouped like:

A) Scheduling/calender
1. Daily-deadline commute. "60% by 07:00 every weekday". Calendar or fixed schedule. (@tomvanacker85, @marst444, my setup)
3: Multi-day weekend window. Plug Friday, deadline Monday morning. 24 h horizon doesn't span the window. (@PerretDavid)
6. Calendar-driven dynamic departure. Google Calendar events translate into deadline + target SoC. Manual edits adjust per-trip range. (@tomvanacker85)

B) Charging behavior:
2. Opportunistic / surplus-only. Charge from PV excess, never grid. Awkward in the deferrable-load model because the kWh-target is mandatory. (@PerretDavid, @TD944, @scruysberghs)
4. Modulating-power chargers. Tesla 3.6–11.5 kW continuous. EMHASS schedules per-timestep on/off at nominal power, so modulation needs either parallel deferrable slots at different powers or post-processing. (@PerretDavid)
5. SoC-deficit-driven operating_hours. hours = (target_kWh - current_kWh) / charger_kW, recomputed per MPC call. Plug-aware: start_timestep = 2h_future when unplugged, 0 when plugged. (@purcell-lab, my setup)
8. Negative-price aware with export-payment. 5-min spot export pricing, battery to 100% before peak-export window, EV charging fills around it. (@TD944)
10. (New) Dynamic charging using load balancing a) in 1phase system b) in 3 phase systems

C) User interface (UI):
7. Manual mode-selection. User toggle between PV-only, PV+grid, max-charge-now. HA UI selector switches between EMHASS plans or bypasses altogether. (@TD944, @xitation, my "Workday / PV-surplus / Voyage" pattern)

D) Charger integration:
9. EVCC dispatcher coupling. EMHASS as single planner, EVCC's own optimizer off, EMHASS plan drives evcc/loadpoints/N/mode/set per slot. (my setup, prototyping)

[TD944]

Regarding the opportunistic charging and the mandatory kWh target I've found the solution is a dynamic target. Myself and I suspect many people are running MPC calls fairly frequently (5 minutes for me). This means that I can dynamically update the expected excess (to allocate to the EV) every 5 minutes and the charge duration changes with it.

So although it is "mandatory" on each MPC call it can be recalculated dynamically.

[PerretDavid]

I'm confused with

Modulating-power chargers. Tesla 3.6–11.5 kW continuous. EMHASS schedules per-timestep on/off at nominal power, so modulation needs either parallel deferrable slots at different powers or post-processing.

Isn't it what a non-semi-continuous-deferrable is about ? Like defining the max charging power as nominal load for the deferrable + the minimum power ? I thought that was something that was supported

[TD944]

Is minimum power currently supported? I've seen references to it but not found the actual option.

[PerretDavid]

That's a good question !

The configuration GUI has fields to set a minimum and a nominal power for my deferrables, and given the description of treat_deferrable_load_as_semi_cont, I supposed this was supported.

treat_deferrable_load_as_semi_cont: Define if we should treat each deferrable load as a semi-continuous variable. Semi-continuous variables (True) are variables that must take a value that can be either their maximum or minimum/zero (for example On = Maximum load, Off = 0 W). Non semi-continuous (which means continuous) variables (False) can take any values between their maximum and minimum.

But that's true that I don't see anything about deferrable minimum power in the Configuration page of the documentation (and now that I see that, I notice that deferrables are only expressed in operating hours... so I don't know how it could work with a variable power... like if EMHASS could change the power of my water heater dynamically, it would have to run for a longer period and I don't know how he could manage that)

[TD944]

My current experience is that if you set a load for X time steps or hours at nominal power of Y then if the power allocated is 1/2 Y it will be allocated 2 X time etc.

[scruysberghs]

deferrable loads also have operating_timesteps_of_each_deferrable_load you can use (undocumented runtime parameter if you have timesteps smaller than 1 hour) and they do have minimum and nominal power. Minimal was introduced for ev charging for 6A minimum (1,2kw for 1phase, 4,2kw for 3phase charging)

[TD944]

How does one set the minimum power for a deferrable load?
I haven't seen it in the docs. Does set_minimum_power_of_deferrable_loads work? Or something similar?

Update...
Yup, minimum_power_of_deferrable_loads seems to work just fine. Thanks!!!!

[OptimalNothing90]

Quick status update

Lots of useful feedback in this thread. @marst444's grouping, @TD944's trick of recalculating the kWh target every MPC call for surplus charging, @PerretDavid and @scruysberghs confirming that minimum_power_of_deferrable_loads and operating_timesteps_of_each_deferrable_load already exist (just undocumented), and @informatico-madrid's multi-trip planner in #820. Thanks all.

Three things jumped out:

1. EMHASS can do more EV stuff than people think. Min power, continuous loads, operating timesteps — all there, just hard to find. I've been tracking this separately: there are ~30+ runtime parameters that only exist in prose in passing_data.md or nowhere at all. minimum_power_of_deferrable_loads is a good example — it works, but you'd have to read the source to know it exists. Making those discoverable is a separate effort (issues Add structured unit field to param_definitions.json for AI/openapi readability #826, param_definitions.json: default/type mismatches found in 2026-04-28 schema audit #827) but matters here too.
2. The actual problem is state. Every MPC call currently needs the full EV context passed in again. Fine for a water heater, awkward for an EV. EVs have deadlines, SoC that changes between calls, external APIs that go to sleep, and wallboxes that sometimes just stop responding. Heat pumps and DHW have similar issues — minimum runtimes, temperature drift, deadlines. Reassembling all of that every 5-15 minutes from the outside is brittle.
3. @informatico-madrid's trip planner shows the gap well. He built 12k lines of code in a HA component to assemble the right EMHASS parameters externally — multi-trip window calculation, backward deficit propagation, 168h power profiles. That's good engineering. It's also a sign that EMHASS itself doesn't have a clean way to hold on to this kind of stateful context between runs.

I've been working on an approach that could address this inside EMHASS — not just for EVs, but as a general pattern for flexible loads with state (think heat pumps, DHW deadline profiles, battery priority rules). If it works, it would simplify what @informatico-madrid's component has to do on the outside while letting his trip planning logic and EMHASS's optimizer work together more directly.

@informatico-madrid — would you be up for reviewing an early RFC draft? Your multi-trip window calc and deficit propagation are exactly the kind of domain knowledge that should shape how this gets built.

Next steps on my side:

• Write up the concept as an RFC with scope, API sketch, and a small MVP definition
• Talk it through with @davidusb-geek and @sokorn first — this would touch core architecture
• Get @informatico-madrid's input on where his planner and this intersect
• Stay within the scope corridors from [Discussion] Making EMHASS more AI-agent & AI-coder friendly #808 and EV charging addon capability #789 (EMHASS = optimizer, no hardware coupling)

Separate from all that: cookbook recipes for the patterns that work today. I'll keep collecting input here and start drafting those. The architecture question is its own track.

[TD944]

On the note of things EMHASS can do that is undocumented I've found that at times when the EV duration is set to 0 that the day ahead (but apparently not MPC) planner will plan a charge that seems to neatly use the available excess. It isn't 100% consistent and sometimes plans more than it should resulting in incomplete battery filling. I've tried fiddling around with different inputs but can't consistently get it to work. Occasionally causing infeasible results as the "duration exceeds available time" even if it is 0. Has anyone else experienced this or know more?

[informatico-madrid]

@OptimalNothing90 — Yes, I'm In

would you be up for reviewing an early RFC draft?

Absolutely. Happy to review and contribute domain knowledge. Below is what I think matters for the RFC, drawn from what ha-ev-trip-planner actually does.

---

The Stateful Context Gap (From My Side)

ha-ev-trip-planner is ~12k lines of code. Part of that complexity exists because every optimization call requires re-assembling the full EV context from outside EMHASS. Another part is features that are coded but not yet exposed — for example, we have a full ScheduleMonitor (324 lines) that reads EMHASS optimization results and triggers vehicle charging control automatically, but it's never instantiated because it hasn't been validated in production yet. Same for 4 vehicle control strategies, a notification system, and presence-based charging guards. These are written and tested in unit tests, but not wired to the UI, and not working, planned for the next weeks.

That said, the part relevant to this RFC is what we compute externally that a stateful context API could internalize:

1. Multi-Trip Charging Windows

We chain multiple trips with deadlines. Each trip gets a window (inicio_ventana → fin_ventana):

• Trip 1: Window starts at max(vehicle_return_time, now) (presence-aware)
• Trips 2+: Window starts at previous_trip_start + gap_hours
• All trips: Window ends at trip_departure_time (the deadline)

This produces per-trip def_start_timestep and def_end_timestep for EMHASS. Currently a fixed 4h gap between trips (RETURN_BUFFER_HOURS), planned to be per-trip configurable.

2. Sequential SOC Projection

Each trip's energy need depends on the projected SOC from all previous trips:

projected_soc = current_soc
for trip in ordered_trips:
    projected_soc += (charged_kWh / battery_kWh) * 100
    projected_soc -= (trip_consumption_kWh / battery_kWh) * 100
    # trip N's kwh_needed is computed from this projected_soc

This means def_total_hours for trip N depends on what happened in trips 0..N-1. You can't compute it in isolation.

3. Backward Deficit Propagation

When trip N doesn't have enough charging hours, the deficit propagates backward to trips with surplus capacity. This is a backward pass over all trip windows after the forward SOC projection.

4. 168h Power Profile

All trips are combined into a single 168h power profile (Watts per hour). This is sent as p_deferrable_matrix to EMHASS. We use dayahead-optim re-executed every 30 minutes (not MPC in my use case).

Caveat: Tested with a setup that includes a large home battery. Not validated for shorter horizons or no-home-battery scenarios,

5. Vehicle Presence

A presence monitor tracks home/away state. Critical for charging automation — we don't want HA to start/stop charging when the car isn't home. Currently only affects the first trip's window start. No real-time presence verification for intermediate trips.

---

What ha-ev-trip-planner Passes to EMHASS Today

In my use case, our adapter computer in real time, for each trip as HA sensors (Jinja2 templates read them in EMHASS runtimeparams), and publishes these parameters to EMHASS via shell command.

Parameter	What we compute externally
def_start_timestep	Hours from now to window start (depends on presence for trip 1, gap logic for trips 2+)
def_end_timestep	Hours from previous trip end+security return time to trip departure (the deadline)
def_total_hours	Hours of charging needed: (target_kWh - current_kWh) / charging_power
P_deferrable_nom	Charging power in Watts
p_deferrable	168h power profile per trip (Watts per hour)

The RFC's stateful context concept could potentially simplify this. But that's for the RFC to define — I'm just sharing what we do today and where the complexity lives.

My current live example

---

My weekly trips on the dashboard look wrong, sorry, I plan to fix it. Tomorrow is a holiday and I have a trip paused, so there are 5 trips but only 4 appear on the planner.

---

[informatico-madrid]

I've created a graph showing my last week's loads, the evolution of SOC, and upcoming planned loads.

[purcell-lab]

I really like where this discussion is headed.

My EMHASS native approach thus far had been to calculate def_hours as the difference between current SOC and SOC charge limit, and have an optional switch to turn on/off an end timestep, if I need to force early charging. My vehicle API allows me (also used with OCPP) to vary charge current so I have optimised as a continuous deferrable load. If the vehicle isn't home and plugged into the charger it sets the start timestep to two hours in the future. I send these parameters with my MPC payload.

[OptimalNothing90]

Quick status, I was the last week very busy and will review everything here as soon as possible

[OptimalNothing90]

quick update: I opened a discussion on evcc to understand it they would support an adapter to emhass, as evcc knowns all edge cases already. see evcc-io/evcc#29815 if interessted, but it's in german

[informatico-madrid]

Hi all — apologies for the silence. I've been heads-down for the past few weeks on a significant
technical debt cleanup and refactor of ha-ev-trip-planner. Nothing glamorous, but the codebase
needed it before any serious new work.

Now that it's in better shape, my next focus areas are:

1. Vehicle page UI — the current presentation is rough. I want to make it cleaner and more
   useful day-to-day before exposing the features that are already coded but not yet wired
   to the UI.

2. Calculation algorithm review and consolidation — I've recently added SOC cap logic, which
   prevents the optimizer from scheduling unnecessary charging when the battery is already near
   its target level. Still some edge cases to polish.

3. EV-specific deferrable load type in EMHASS — the more I work on this integration, the more
   convinced I am that a first-class deferrable load type for EVs is genuinely necessary. The
   generic deferrable load model doesn't map cleanly to the EV use case (departure deadline,
   minimum SoC at departure, presence awareness, multi-trip chaining). Building all of that
   externally — as I do today — is functional but brittle.

@OptimalNothing90 — the evcc discussion you opened looks really interesting. I'll dig into it.
The idea of EMHASS as the planner with EVCC handling hardware enforcement is exactly the kind
of clean separation that would reduce a lot of the external glue code I currently maintain.
Looking forward to comparing notes.

[OptimalNothing90]

@OptimalNothing90 — the evcc discussion you opened looks really interesting. I'll dig into it. The idea of EMHASS as the planner with EVCC handling hardware enforcement is exactly the kind of clean separation that would reduce a lot of the external glue code I currently maintain. Looking forward to comparing notes.

In Deutsch, en español, in englisch. I see we are running here trilingual ;)
Yes, I'm really seeing evcc here the hardware glue and real short term reaction while emhass is the overall optimizer. You may want to leave there a comment as well to get more maintainer attraction

[LesIT1]

@OptimalNothing90 @davidusb-geek Happy to pitch in on this, and the evcc side (#9) especially since I've got it running in production rather than in theory.

My setup has EMHASS (naive-mpc) as the planner and evcc as the EV-only enforcement layer for a Tesla. EMHASS owns the optimisation across a few deferrables (an EV must-charge floor, an EV PV-surplus top-up, and a pool pump) against a TOU tariff with a hard export cap and no feed-in tariff. evcc just executes the per-loadpoint decision and reads SoC/range/state back. The Tesla command path is fully self-hosted and free: own Fleet app plus tesla-http-proxy for signed commands, with a Cloudflare Worker serving the well-known public key so Tesla's domain validation passes without standing up a public web server.

A few things worth capturing in the cookbook from actually living with this:

• The separation-of-concerns model OptimalNothing90 and informatico-madrid are describing holds up well. EMHASS decides "how much and when," evcc decides "how to deliver that to this specific car safely." The glue stays small once you stop trying to make EMHASS talk to the charger directly.
• The mandatory-kWh-target friction TD944 raised is real, and I handle it the same way: recompute the deferrable's expected energy and operating window on every MPC pass from live SoC and the next departure, instead of pinning a static target. A recipe that spells out that recompute-each-pass pattern would save newcomers a lot of head-scratching.
• The "hit a target by a deadline, then be free" pattern shows up on the battery side too. I recently had Add optional intermediate battery SoC target (soc_target / soc_target_timestep) — addresses #553 #928 merged, which adds an intermediate battery SoC target (soc_target / soc_target_timestep) so the battery can be required to reach a SoC by a given horizon step rather than only at the end. Same shape as EV deadline charging. It's a hard constraint today, and there's a clean follow-up in a soft-penalty variant so an unreachable target degrades gracefully instead of going infeasible.

I'd be glad to write the evcc-coupling recipe (#9) end to end against this live deployment, following whatever template you settle on, and to review the others. If there's appetite for a first-class EV deferrable type or a stateful-context API, I'm happy to be a daily-driven test bed for it.

[davidusb-geek]

Hi, as discussed before, I completely agree with this approach.
A docs/cookbook/ section is exactly what we need. Instead of trying to build every possible EV edge case into the core of EMHASS, we can provide copy-pasteable recipes for the external "glue" (HA templates, Node-RED flows, etc) that users have already perfected.
@OptimalNothing90 and @LesIT1, I would be very happy to review PRs that add these recipes to the cookbook section.
@LesIT1, your EVCC-coupling recipe sounds like the perfect first addition to this.

Remember that we want to keep EMHASS strictly hardware-agnostic and stateless. Its speed and stability rely on being a stateless MILP optimizer. Building complex, stateful multi-trip logic or hardcoded third-party adapters (like EVCC) directly into the core risks bloating the architecture and slowing down the solver. But don't get me wrong, I do highly respect the engineering that has gone into calculating multi-trip windows and stateful contexts.

I think the Cookbook is the best way to channel this amazing community knowledge on these EV related topics

[LesIT1]

Thanks @davidusb-geek, that split makes sense to me. Keep the solver hardware-agnostic and stateless, and push the EV glue into copy-pasteable recipes.

I had a look at the cookbook as it stands. The EV section already notes the evcc-coupled recipes are waiting on evcc-io/evcc#29815, but that thread is about EMHASS running as an evopt-style backend inside evcc, with evcc as the master. The integration I run is the other way around: EMHASS stays the master MPC across the deferrables and the battery, and evcc only enforces the EV charge downstream. That model doesn't depend on #29815 landing, so I think it can go in now without treading on the backend work.

If it's useful I'll write that one up against _template.md, under the EV category: "EMHASS as planner, evcc as enforcer." Goal, prerequisites, the static EV deferrable config (a deadline floor plus an opportunistic solar top-up), the per-MPC recompute of the EV window from live SoC, and the handoff to evcc, with the same "the plan is a recommendation" framing the Node-RED recipe already uses. Generic and scrubbed, no VINs or tariffs.

@OptimalNothing90, you're driving #29815 and the wider EV pattern list here, so I don't want to overlap. I'm happy to keep mine to the EMHASS-on-top / evcc-as-enforcer angle and leave the evcc-backend recipe and the broader catalogue (daily-commute, calendar-driven, surplus-only, and so on) with you. Does that division work for you both? If so I'll get a draft up for review.

[OptimalNothing90]

@davidusb-geek @LesIT1 I'm just wondering if it makes sense to setup a call as this really needs some LLM free brainstorming/coordination?

[scruysberghs]

Always happy to brainstorm along.
We now use evcc as ui to set ev charging goals (plans, PV, min+pv, low price charging) and to control the charger and have python appdeamon script in HA that reads the evcc api and translates that into deferreable loads in home assistant inputs (min and max power, start and end timesteps) that then get fed to the emhass mpc optimiser api call. Not ideal as we now just mimic in emhass what evcc will do so battery and other loads are optimised around it, but the charging session itself just follows evcc logic.

[LesIT1]

@OptimalNothing90 Yeh, I wouldn't mind this, just to make you aware I am in Australia, so coordinating could be tricky, happy to give it a crack though.

[scruysberghs]

To keep this discussion alive. Using evcc with emhass is see 2 options on the emhass ha side:

• use evcc only as controller for charging station
  pro: you can use emhass optimisations to plan your charging session
  con : you have to recreate the charging goal UI in Home Assistant and UI is what evcc is good at

• use evcc as controller for charging station and as UI to set charging goals
  pro: use controller logic and UI/UX friendly evcc interface to set charging goals
  con: no optimisation of the charging session trough emhass , you have to translate the evcc session into a deferrable load in emhass to optimise your other assets around it which is complicated. evcc has the ui to make plans, do solar charging, solar+pv, fast, pv fast when prices are below limit, stop charging in solar when injection reward is high and also has a ui to control how your battery is supposed to interact with your charging in solar mode)

Anyone here see a 3rd path that would allow evcc as controller and ui, but use emhass as optimiser?
imho yhat would be ideal but would require replacing the current planner/optimiser in evcc with emhass and thus substantial changes to evcc itself.

[davidusb-geek]

Here are two approaches proposed by gemini and that seem reasonable to achieve this using only existing REST and MQTT APIs.

​Approach 1: The "State Override" Bridge (Direct Control)

​This method lets the user interact with the evcc UI, but Home Assistant invisibly steals those inputs, feeds them to EMHASS, and then remote-controls evcc based on the result.

• ​User Input via evcc: The user sets their charging goals in the evcc UI (e.g., target SoC of 80% by 07:00 AM).
• ​HA Interception: Home Assistant reads these values via evcc's MQTT topics (e.g., evcc/loadpoints/1/targetTime and evcc/loadpoints/1/targetSoC).
• ​Dynamic EMHASS Injection: HA runs a script to calculate the required energy (Target SoC minus Current SoC). It then triggers the EMHASS REST API (/action/dayahead-optim or naive-mpc-optim), passing the EV as a dynamic deferrable load with the calculated energy requirement and the evcc targetTime as the deadline.
• ​Execution: EMHASS generates the optimal schedule and outputs it to a Home Assistant sensor.
• ​Enforcement: A simple HA automation listens to the EMHASS schedule.
  • ​When EMHASS says "charge now," the automation pushes the now (Fast charge) mode to the evcc/loadpoints/1/mode/set MQTT topic.
  • ​When EMHASS says "stop," the automation reverts evcc to pv (Solar only) or off.

​Pros: Gives EMHASS absolute authority over the house's energy balance; user keeps the evcc UI.
Cons: The evcc UI will temporarily show that it is in "Fast" mode when EMHASS triggers it, which might briefly confuse users who expect it to say "Smart/Planned."

​Approach 2: The "Fake Tariff" Hack (Elegant Manipulation)

​If you want to keep evcc's internal logic running smoothly without brutally overriding its modes, you can manipulate the data it bases its decisions on. evcc supports custom grid tariffs via MQTT or REST.

• ​EMHASS Optimization: EMHASS continuously calculates the optimal times for heavy loads based on solar forecasts, home consumption, and real grid prices.
• ​Create a "Shadow Price": Have Home Assistant translate the EMHASS optimal charging windows into a dummy MQTT tariff.
  • ​EMHASS says charge: Set the dummy MQTT price to -99 cents.
  • ​EMHASS says wait: Set the dummy MQTT price to 99 cents.
• ​evcc Configuration: In your evcc.yaml, configure the grid tariff to read from this HA MQTT topic. Set evcc's "Cheap energy" price limit to anything above -99.

​Whenever EMHASS determines it's the perfect time to charge (balancing solar, home loads, and real grid prices), it artificially drops the MQTT price. evcc's native planner sees this "plunge" in prices and happily spins up the charger on its own accord.

​Pros: Zero conflict between the two systems. evcc's native planner and UI work exactly as intended, but they are secretly dancing to EMHASS's tune.
Cons: You lose the ability to display the real grid price in the evcc UI, as it will be displaying the "dummy" tariff instead.

[davidusb-geek]

Of course there is also another solution that would simply be a feature request to the evcc team: Add an external planner type.
​If evcc added a configuration that would listen to a custom webhook/MQTT topic for our deferrable schedule, EMHASS could then directly populate evcc's internal planner timeline right?

[OptimalNothing90]

@davidusb-geek EVCC maintainer already signalised that they are open for such additions. We first need to be clear how we want to implement it on emhass side, see #931

[LesIT1]

@davidusb-geek @scruysberghs Approach 1 is basically what I run in production, so I can speak to it rather than in theory. EMHASS (naive-mpc) is the master planner across the deferrables and the battery, and evcc only executes the EV charge. It holds up well.

The override doesn't need MQTT specifically. evcc's REST API exposes the charge goal (its session SoC limit and energy plan) and takes the loadpoint mode (now/pv/off) over the LAN, so a HA rest_command is enough. The piece that matters more than the transport is recomputing the EV's required energy and window from live SoC on every MPC pass, rather than pinning a static kWh target. That's the same point TD944 made earlier, and it's what makes the "mandatory" deferrable behave on a dynamic tariff.

One honest caveat from doing it: EMHASS plans the EV on/off at nominal and does the time-shifting, it isn't modulating the charge current within a slot. Map every planned-on slot to evcc "now" and you charge at the configured rate in the cheap slots EMHASS picked, which is what you want for a deadline. If you'd rather follow PV surplus within the window you run evcc in pv/minpv instead and accept it may deliver less than planned. Worth being clear which of the two you're after.

The "evcc UI shows Fast" point is real but cosmetic. You keep evcc's UI for setting goals and EMHASS overrides the mode underneath, which is the closest answer to @scruysberghs's "evcc as controller and UI, EMHASS as optimiser" question that works on released software today.

On Approach 2, I'd be careful recommending the fake-tariff route where EMHASS is meant to be the optimiser. You end up with two planners: evcc still re-plans against the shadow price on its own cadence, so it can disagree with EMHASS at the edges, and you lose the real price in the evcc UI. Neat nudge, but I wouldn't put it on the control path.

Your external-planner-type idea is the clean long-term answer, and it's close to what @OptimalNothing90's evcc thread (#29815) is circling. Worth pushing there.

I've put the "EMHASS as planner, evcc as enforcer" recipe up as the first cookbook addition, written against this live setup: #990.

[scruysberghs]

I guess it would require a new ("remote" or "optimised") mode in evcc next to the 4 existing modes off/pv/min+pv/now
andig (evcc dev) indicated he is working on this for their own optimiser. evcc-io/evcc#30783

[LesIT1]

Catching up on this one, sorry for the slow reply.

That's the right missing piece I think. A native remote or optimised mode is exactly what your third path needs: today the only way to get "evcc as controller and UI, EMHASS as optimiser" is the mode-override bridge David and I described above, which works but always has the cosmetic wart that the evcc UI shows whatever mode the bridge forced rather than what the user chose. A first-class mode that accepts an external schedule would keep the UI honest and, more importantly, let evcc keep enforcing its own guard rails (min SoC, phase switching, current limits, vehicle wake handling) underneath an externally supplied plan instead of having them fought by mode flips.

Good spot on the PR. Small update since your comment: it actually merged back in mid June, and it's deliberately advisory only for now. It derives a per-device action (charge or stop for a loadpoint) from the optimiser result but doesn't wire that into control yet, and the steady stream of optimizer PRs from andig since then still sits at the suggestion level as far as I can see. That's the encouraging part though: the plumbing for their own optimiser already exists and is actively moving, so once they wire suggestions into actual control the external-planner case becomes "same socket, different plug" rather than the structural change you were worried about in your earlier comment.

Until that control step lands on the evcc side, the override bridge stays the practical answer. It's been running here in production since June without drama, so the pattern itself is sound even if the ergonomics aren't.

On the EMHASS side I don't think a new mode needs anything new from us at first: the planned EV slots already exist in the MPC output, and pushing them at whatever endpoint evcc exposes is a rest_command. The longer-term shape (EMHASS publishing a schedule evcc subscribes to) is basically what #931 sketches, so the two threads may converge.

Happy to test-drive an early build against my live EMHASS and evcc stack when there's something to try, a real house with a real EV is probably the most useful contribution I can make to that effort from the outside.