Charge planner/optimizer: allow declaring expected consumption (upcoming trip) so cheap hours *before* the trip can be used

[Eernie]

Is your feature request related to a problem? Please describe.

The charge planner is purely reactive: it only compares the vehicle's current SoC against the plan target. It has no way to know that the car will be driven (and lose charge) between now and the target time. This causes it to skip cheap hours that occur before a known trip.

Concrete example (dynamic tariff):

• It's 12:00. Vehicle SoC is 50%. Electricity is cheap right now.
• My repeating plan says: 45% by tomorrow 07:00.
• I already know I will drive this afternoon and return with ~30% SoC.

Because 50% ≥ 45%, the planner does nothing at 12:00. After I return with 30%, it replans and charges the missing 15% during the remaining (more expensive) evening/night hours. The cheapest slot of the day was available at noon, but the planner couldn't use it, because at that moment the target was formally already met.

Describe the solution you'd like

A trip planner, analogous to the existing charge plan dialog. Where a charge plan says "reach X% by time T", a trip entry would say:

• Departure time: when the car leaves
• Return time: when the car is plugged in again
• Expected consumption: in km or % (km could be converted using the vehicle's configured range/capacity)
  Example: "Trip today 14:00–18:00, 60 km (≈20%)".

With this knowledge, the planner can build a complete picture of the SoC over time:

1. Before departure, it knows the car must be at SoC needed at next plan target + trip consumption, so it can use cheap hours before the trip (in my example: charge 15% at noon at the day's lowest price).
2. During the trip window, it knows the car is away and schedules nothing.
3. After return, the existing plan logic continues as today, but ideally little or nothing is left to charge, because the buffer was already added at the cheapest moment of the day.
   Just like charge plans, trips should support one-off and repeating entries (e.g. "Mon–Fri, leave 08:00, back 17:30, 50 km"), commutes are the main use case, and they are perfectly predictable. Both plan types would show up together in the plan preview/prognosis chart, so you can see the expected SoC curve including the dip from the trip.

Describe alternatives you've considered

• Manual one-off plan before leaving ("65% by 14:00 today"): works, but has to be done by hand every single time and defeats the point of repeating plans.
• Price limit (smart grid charging) combined with the plan: does charge during cheap hours regardless of plan state, but again, its something you need to do by hand everyday, if you want it to be optimal.

[github-actions]

Thanks for the detailed write-up. This is a clear feature request rather than a bug: today the planner (core/planner) only reasons about the current SoC vs. the plan target and has no concept of a scheduled trip/consumption event in between, so it can't pull charge forward into cheaper hours ahead of a known departure.

Implementing this well would require:

• a new "trip" entity (departure/return time, expected consumption, one-off and repeating variants) alongside the existing charge plan
• extending the planner's SoC-over-time model to account for a consumption dip during the trip window and add the buffer before departure
• UI changes to define/edit trips and to show them in the plan preview/prognosis chart

That's a fairly large design change spanning planner logic, persistence/API, and UI — it needs maintainer/design discussion rather than a quick fix, so I'm not attempting an implementation here.

🤖 Generated with Claude Code

[andig]

I understand the logic here, but this seems like a lot of mechanics. How often does this really happen and how accurate can these planned trips really be? Would we really expect users to announce upcoming trips en detail?

[Eernie]

In my case, most of this is recurring. So its mostly setup once. Then the other usecase will be something like home assistant that can add more trips to the planner when needed.
But this would also make the optimizer beter right? Knowing the car is gone in 2 hours, should make the optimizer want to try to charge the car first with the excess solar, instead of the otherway around.

[andig]

But this would also make the optimizer beter right?

Mathematically, absolutely. I'm just wondering how practical this is.

@naltatis we have a similar requirement in evcc-io/optimizer#131 that might match.

@Eernie I still think you'd need 2 different kinds of information here:

• vehicle soc demand at time t (the original plan you already have)
• vehicle away between x and y with expected consumption/ soc decrease of z
• vehicle soc demand for departure at time x with x < y < t

So it seems to me that away with soc decrease really might be properties of a second plan targeted at time x? Worth noting that the planner today is atomic in terms on handling a single plan only. We could feed this information into full-auto mode though (feel free to give #32881 a try!

[naltatis]

In my case, most of this is recurring. So it's mostly setup once.

I can see adding something like this on vehicle level, but I wouldn't model it like upcoming trips with expected soc-decrease assumptions. I think this is too complicated/brittle. Especially for a first shot at this.

Having an optional absence/presence plan as hints (evcc-io/optimizer#131) for the planner and optimizer sounds useful. Especially for the optimizer case where better predicting the future can improve short-term decisions.

If behavior is regular (arriving from work at around 18:00 on weekdays) we could also try to infer a presence plan from previous data. This way also casual users (setup and forget) would benefit from this concept.

[andig]

If we do absence plans we should make consumption during that absence part of the picture. Absence implies driving somewhere, so a minimum covered distance should be expected. This would already be enough input for the planner to calculate longer planning window with exclusions and additional need for the soc drop. It would still not cover a second plan for the earlier departure.

It seems to me that an absence plan really is a normal plan. This gives 2 types of plans:

• needs soc X by then
• drops soc Y during absence of duration Z (and may still require soc X to start with but doesn't need to)

This would need to make the planner aware of multiple plans which It isn't atm.