[FEATURE] Rolling 24-Hour Window (Receding Horizon MPC) for Dynamic Tariffs

[rrozema]

Area of the proposal

Energy management or control strategy

What problem would this solve?

Current predictive charging strategies create a static plan at the start of the day for when and how to charge/discharge up until the next day. For users on dynamic energy contracts, this leaves very little room for optimization:
​The Midnight-to-Sunrise Gap: Between midnight and sunrise, there are typically few cheap charging opportunities, yet demand continues.
​Morning Deficit & Loss: High-priced electricity slots frequently occur right before the new day begins, often causing households to start the morning with an energy deficit or a financial loss.
​Inflexible Planning Horizon: While extending the plan further out (e.g., until the next sunrise) could help, solar and price forecasts are often unreliable or unavailable that far in advance. Furthermore, dynamic contracts often reward delaying battery charging when early-day solar production is active—meaning it can be more lucrative to export initial solar production while running off the battery until market prices drop sufficiently.

Proposed solution

Implement a rolling (moving) 24-hour optimization window based on a receding-horizon approach (Model Predictive Control style):
Recalculate Every 15 Minutes: Trigger an automated re-computation of the optimal 24-hour charging and discharging plan every 15 minutes (aligned with price change intervals).
Incorporate Fresh Telemetry: Feed the latest available data into each re-calculation, including newly updated usage patterns, live dynamic prices, updated solar generation forecasts, and current battery State of Charge (SOC).
Execute and Repeat: Execute the first 15-minute slice of the newly computed 24-hour plan, and then repeat the loop 15 minutes later using the newest known information up to 24 hours into the future.

Example use case

Example Scenario: The Midnight Boundary and the Unplanned Night Deficit
The Static / Midnight-Reset Problem (Current Behavior):

• Time: 00:05 AM (Just after midnight).
• Situation: A new daily plan is generated. It takes whatever State of Charge (SOC) the battery happens to have at midnight as its starting point.
• The Blind Spot: Yesterday’s plan ended at 23:59 and did not account for the energy requirements of the upcoming night. Because yesterday's strategy didn't foresee how much power the household would consume between midnight and sunrise—and crucially, did not know there would be virtually no cheap charging slots during those hours—the battery enters midnight with too little charge.
• What Actually Happens: With no cheap energy available from 00:00 until the sun comes up, the system is caught off guard. It either runs out of battery halfway through the night or is forced to pull expensive grid energy to cover base loads, resulting in an immediate deficit right at the start of the new day.
  The Rolling Window Solution (Proposed Behavior):
• Time: Continuous 24-hour rolling horizon.
• Situation: Because the optimizer runs continuously rather than executing a hard reset at midnight, there is no artificial boundary between "yesterday" and "today."
• Action Taken: Hours before midnight, the rolling 24-hour window is already looking ahead into the night and early morning hours. It recognizes that cheap charging slots are scarce until sunrise and automatically adjusts yesterday afternoon & evening's behavior—retaining more energy in the battery instead of discharging or exporting it too early.
• Result: When the clock strikes midnight, the battery transitions smoothly with a proactively managed SOC. The system already knows the exact energy needed to bridge the gap until the next charging opportunity, completely eliminating the midnight blind spot and morning start-up deficit.

Who would benefit from this?

Most Omnibattery users

Alternatives or workarounds

Extending the horizon to the next sunrise: Helps capture morning spikes, but suffers from inaccurate or even unavailable long-range weather/price forecasting and cannot dynamically react to sudden intraday shifts or delayed solar-charging opportunities. Plus it does not allow exporting high-prized morning solar before starting to charge the battery.

Additional context

This approach would significantly enhance profitability and efficiency for users on hourly or 15-minute dynamic tariffs, preventing morning losses and ensuring the battery adapts smoothly to changing intraday (market) conditions.

Confirmations

• I searched existing discussions and did not find the same proposal.
• This is a general feature idea, not a request to support a new battery brand or model.
• I understand that community interest and technical feasibility influence prioritization, and that no delivery date is guaranteed.
• I removed passwords, tokens, API keys, complete serial numbers, IP addresses, and other sensitive information.

[github-actions[bot]]

Thanks for the suggestion! 🙌

Here's how this works:

• Vote by clicking 👍 on the original post — not in the comments
• The more votes an idea gets, the higher it moves in the priority queue
• I review feature ideas periodically and implement the ones that benefit the most users

If your idea is very specific to your setup, it may not make it into the core integration — I'll try to suggest a workaround in that case.

Feel free to discuss details or alternatives below.

[ffunes]

Thanks for the detailed write-up — but the premise needs correcting, and the good news is that the problem behind it is already fixed.

The midnight boundary is gone. The planning horizon now ends at the next local sunrise, not at 00:00: overnight consumption past midnight is budgeted, the discharge reserve is held through to sunrise, and the plan is rebuilt when tomorrow's prices are published (~13:00 CET). That lands in the next release — it's exactly what #410 asked for.

The plan is not static. It's rebuilt whenever an input it was built on actually moves: prices published, solar forecast revised, an excluded device's solar claim changes, SOC falls below the evaluated level, evening solar wind-down, a configuration knob changes, plus a pre-slot re-check one hour before every window. Each of those rebuilds the full remaining horizon. So we already re-plan on fresh telemetry — we just don't re-plan on a clock.

And that's deliberate. Three reasons a fixed 15-minute rebuild would be worse here:

1. Between events the inputs are unchanged, so ~90 of the 96 daily rebuilds would produce the same plan. On hardware where we already ration Modbus traffic, that's cost without information.
2. Actuation has memory — actuator latency, relay dwell, write budget, and a running charge that already paid its startup cost. Re-deriving a marginally different optimum every 15 minutes chatters the battery. Control-theory MPC handles this with move suppression and a terminal cost, which is another way of saying "don't re-plan freely" — i.e. it would have to reinvent the commitment logic we already have.
3. A rolling window doesn't remove the horizon boundary, it moves it to now+24h — an arbitrary point that needs a terminal value function for stored energy, which is the genuinely hard part and isn't in the proposal. A sunrise horizon puts the boundary at the one predictable moment in the cycle: battery at its floor, PV about to take over. It also only claims data we actually have — before ~13:00 a 24h window is 11–24h short on prices.

So I'm going to close this one as covered by the sunrise horizon work.

The part that isn't covered is your point about exporting high-priced morning solar before charging — that's a real and separate idea, and it's already your own #237. It doesn't need an MPC rewrite, just a price-aware gate on solar charging. Let's keep that conversation there.

[rrozema]

That is exactly where you are wrong: for dynamic contracts "solar production takes over" is not a suitable horizon. As long as it is profitable to export solar energy, i.e. export price is higher than the value of the energy in the battery, we still want to run of the battery even though the panels are producing energy and export all solar energy generated. For doing that we need more energy in the battery than you anticipated using the predictions made based on the sun up horizon.
Charging that expensive, first solar into the battery unnecessarily raises the price of the energy in the battery plus it forfaits the opportunity costs for that high-value, first solar energy.

[rrozema]

I only have a limited history for the prices, so this is not a really convincing example, but it does show what I mean: you can see how the blue line rises in the morning, even though prices were actually lower than the day before. If we had exported that first solar into the grid instead of using it, we had received more than we paid for charging the battery the day before. Plus we would have had a lower price for the.energu in the battery, increasing our profit from running of the battery the next day. This subtle difference was actually the difference between breaking even and actually getting something back for my investment when I ran my simulations for over a year.

[ffunes]

That is exactly where you are wrong

Two different things are being mixed here, and neither is a "no".

This discussion (#489) is about when the plan is recomputed — a rolling 24h window recalculated every 15 minutes. That's what I answered: the plan is already rebuilt on every input that actually moves (new prices, revised solar forecast, SOC drop, pre-slot re-check), and the midnight boundary is gone as of 1.5.0. A fixed 15-minute loop would add cycles without adding information.

What you describe in your follow-up is a different feature: running the house off the battery while exporting expensive morning solar. That is the opportunity-cost strategy from your own #237, and the deliberate-export half of it is #270. Nobody has said those won't be implemented.

Where they actually stand:

• [FEATURE] Predictive Charging should look past midnight to the next sunrise #410 (horizon to sunrise) — shipped in 1.5.0.
• [Feature] Optimize Solar Charging Based on Dynamic Feed-in Tariffs (Opportunity Cost Optimization) #237 — the delay half is in: surplus_price_hold blocks charging so the surplus exports by itself. That scope was agreed with you in [Feature] Optimize Solar Charging Based on Dynamic Feed-in Tariffs (Opportunity Cost Optimization) #237 ("delayed charging as an option separate from forced discharging").
• Force battery discharge during high-price peak spikes #270 — the deliberate-discharge half. A planner is already written: it only sells a kWh when it can be linked 1:1 to a later household deficit that is provably cheaper to re-buy, protected by SOC floor, efficiency and export limits. Not wired into the control loop yet.
• [FEATURE] Stored Energy Cost Sensor (€/kWh) for Dynamic Battery Strategies #269 — the €/kWh cost-of-stored-energy sensor both depend on.

So the sunrise horizon was never meant to be the final word on solar economics — it's the prerequisite the rest is built on. These are large features and they land one at a time, each with hardware validation behind it. Let's keep #489 to the re-evaluation cadence and take the export-economics discussion back to #270, where the spec work already is.

[rrozema]

I am running 1.5.0b2 but haven't noticed better performance yet, the battery still charges at times that economically make no sense.
The morning delay in my example use case was only one situation where existing logic does not seem to make the right decisions yet.

F.e. yesterday was my "weekly charge to 100% day". So from the start of the day it was clear that a SOC of 100% would be the target for that day. From 9:45 until 17:30 the import price sat between 0,1338 and 0,1364 eur/kWh and the export price sat between 0,0910 and 0,0934. My point being: there was plenty of time to charge to 100% cheaply all day. Yet omnibattery decided it would charge over 3kWh after 21:45, when no solar was available anymore and import prices where from 0,2347 (for only 15 minutes) up to 0,2650 eur/kWh.

I will wait for the implementation of the remaining features, but so far I did not see much improvement in the plans made from what was already implemented. And please don't understand me wrong, I am very thankfull for the integration. Zendure's own application does a much worse job driving the battery off my dsmr 4.2 smart meter with an update interval of 10s. That was oscillating like crazy and would never even return the costs of the battery. I can now run Omnibattery off metering updated every 0.6s(!) and this is at least not making the battery a lost cause. It's just that I think Omnibattery can stil be improved to make us earn back the costs of the battery using dynamic contracts.

[ffunes]

@rrozema before 1.5.0 goes stable (planned in the next few days): the weekly 100% day you described (3+ kWh bought after 21:45) was addressed in b3. The weekly day now reserves the cheapest slot after the solar window closes, sized for the whole gap, and cancels it if the sun fills the pack. If you've had a weekly day on 1.5.0b5 since, could you tell me whether it behaved?

[rrozema]

My weekly 100% dat is on Saturdays now, but I can move it to test. Would you want me to move it to a day with sufficient solar or one that has insufficient solar?