You are solving it wrong, and the reason is a good one to internalise because it applies to all three of your loads differently.
"Cheapest N hours" optimises price and ignores the constraint. Each of your loads is really a storage problem with its own rules, and the rules are what make the schedule feasible:
- The car needs a total amount of energy before a deadline. It does not care when, but it usually cannot pause and resume for free — and some cars and chargers handle interrupted sessions badly. So it wants contiguous cheap hours, or at least few segments.
- The hot water tank is a store that leaks. Heat it at two in the morning and some of it is gone by the evening shower. It also has a hard constraint you must not optimise away: the tank needs to reach a high enough temperature regularly for hygiene reasons, regardless of price.
- The house is a store with a large capacity and a slow response. You can heat it early and coast, but only within the comfort band, and how far you can coast depends on the outdoor temperature and how leaky the building is.
So the correct framing is: for each load, what is the minimum energy needed, by when, subject to what constraints — and then place that energy in the cheapest hours that satisfy the constraints. Price is the objective; the constraints come first.
A concrete shape that works and is not hard to implement:
- Define a horizon and a deadline per load. Car: by 07:00. Tank: hot by 18:00. Heating: comfort band maintained continuously.
- Estimate the energy each needs. For the car, target minus current state of charge, divided by charge rate, gives hours needed. For the tank, a fixed number of hours from cold is a fine first approximation. For heating, this is the hard one — see below.
- Within each load's own window, rank hours by price and allocate. For the car, prefer the cheapest contiguous block long enough to finish, rather than the cheapest scattered hours. That fixes your unfinished-charge problem directly.
- Respect minimum run times. A heat pump or a compressor cycled on and off hourly is being damaged and is running inefficiently. If an hour is cheap and the next is not, do not toggle — put a minimum-on constraint in.
- Always have a fallback. If prices are unavailable, or the day is uniformly expensive, the system must fall back to "just heat the house" rather than doing nothing. Comfort failures are far more expensive in household goodwill than a few hours at a bad price.
On the heating specifically, this is where "cheapest hours" fails worst. Preheating works, but only if the building holds it. A well-insulated house with underfloor heating can coast for hours; a leaky one with radiators loses it in forty minutes and you have paid for heat that went outside. Measure your own coast rate before designing around it: heat to the top of the band, turn everything off, and time how long it takes to fall to the bottom. That number is the only thing that tells you how much preheating is worth doing.
Start with a threshold rather than an optimiser — run when the price is below some percentile of the day — measure for a fortnight, and only then decide whether the extra complexity pays. It frequently does not.