Next day forecast

[JohnnydeJong]

Area of the proposal

Energy management or control strategy

What problem would this solve?

Currently the PD only calculates with 24 hours prices, but sometimes the next day is very expnsive and you want minimize the pain (of high prices) a day longer. So charge more with low price all the way till max and use a bit more cheap power during the day. Would be nice if there could be an extra feature for that.

Proposed solution

Calculate with 48 hours not 24 hours

Example use case

Electricity is usually cheap on Sundays. It would be great if Omnibattery could calculate the charging schedule so that the battery reaches 100% by sunset, allowing you to run on stored (low-cost) energy for as long as possible the following day. This feature could also be applied to other days.

In the Netherlands, electricity prices for the day are typically known by 1:00 PM or 2:00 PM. It would be very useful if Omnibattery could re-run its calculations at that point, taking into account the following day—especially if high prices are expected.

Who would benefit from this?

Users with a specific installation or workflow

Alternatives or workarounds

Nothing found

Additional context

No response

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.

[Nieass]

I discussed this "issue" with @ffunes before and I am pretty sure this will become a feature in the future.

But might take some time, he is still on vacation and alot of other feature requests and bugs are on the list to add/fix.

[anorakophobia]

I think this is the highest interesting feature, especially now for winter time.

There are several issues with the predictive charging, and mostly due to that the horizon only ends at sunrise and nothing is calculated for tomorrow.

Btw for Tibber the recalculation is done around 1:00 / 2:00 PM, but the planning horizon is just for sunrise.

Extending the forecast planning fully for the next day, including adding a sensor for the tomorrow solar forecast would make a big improvement.

I could contribut with some AI credits and provide an MR, but don't want to go into double work if sometone or ffunes would do it.

[remarkmmj]

So I agree! For the previous period with lots of sun the way to go was indeed waiting for the sun to rise.
Now with this Little Solar power you really need to take Action when Prices are low.
I now manually charge to Full when the Price is low but of course this should be done automatically.

Also In winter with verry low solar, setting the switch to only discharge above the average price should be automated I think.
It could calculate the state of this switch automatically to put it on or off to see when it should or not should discharge.

Isn’t it a good idea to look at BSFAI how this does this and integrate this in to omnibattery?

[remarkmmj]

I just found the "Solar forecast reserve discharge" blueprint and am trying to see if this is able to set the switch to discharge or not.

Is it a correct assumption that it solves the discharging the battery when solar is not enough during low purchase prices?
When yes I set it on the whole day:
Forecast Dump Start Time Earliest time of day when a high solar forecast may allow discharge below the reserve. 0:00:01
Forecast Dump End Time Latest time of day when a high solar forecast may allow discharge below the reserve. 23:59:59

[remarkmmj]

Hum..
It seems this blueprint sets the switch exactly the wrong way round..
"switch.omnibattery_dp_price_discharge_control" off /on
So we can not use it without changing the code in the blueprint on that switch.
For now I added a template switch "switch.omnibattery_winter_omvormer" that does the exact opposite 👍
That way the blueprint can control "switch.omnibattery_winter_omvormer" that now controls the "switch.omnibattery_dp_price_discharge_control" in the oppisit way.

Maybe not the cleanest approach but it works for now. Lets test and see what happens,

Hope to hear some ideas for others?

[anorakophobia]

One thing worth deciding before the horizon is extended, because a longer window makes it matter more: how a charge slot is valued.

Today the plan values grid energy in two ways that do not match:

• The arbitrage ceiling averages the dearest hours_needed of the whole horizon, for the whole deficit at once. A morning peak can then justify a midday charge (closed [BUG] Dynamic pricing: arbitrage ceiling uses dear hours that lie before the selected slots; plan is dropped once the peak has passed #649), and a large deficit dilutes the average until even the first kWh is refused (#662, analysis).
• The depletion deadlines book, for each step of the projected shortfall, the cheapest slot before it. On a flat night that gives short full-power charges that are discharged again within the hour, at the same price minus the round-trip losses (#662, measured on 1.5.1b1).

With a 48-hour window both get worse: the ceiling averages over more hours, and the deadlines scatter pieces over more slots.

A suggestion for the new planner: pair the cheapest charge slots with the dearest hours after them in which the energy is actually used, and keep each pair that clears round-trip efficiency plus min_arbitrage_margin. Energy for the guaranteed floor stays exempt, as in #724. The discharge reserve already keeps stored energy for the dearer hours, so the two sides would use the same rule. Charges then land in the cheapest consecutive slots, and a cheap Sunday can fill the battery for an expensive Monday, which is what this idea asks for.

As a first step I will open a small PR tomorrow for the #649 part (each slot valued only by the hours after it). It works within the current horizon. I am happy to help with the pairing too, if it fits how you want to build this.

[anorakophobia]

Human made comment:

After working on some issues I think there the #710 would be really worth to help for a lot of cases.

Nevertheless see my AI comment what might be a good order and what needs to be considered

@ffunes : I don't want to spam a lot on this to you directly, because I guess you have enough to do after your vacation, therefore just raising it once here:
As this are bigger changes for the price logic, I think your feedback and ok to go towards this changes would be good. Then I am open to bring in tested PRs :)

Before the bigger one, I think I will provide something for the mentioned "short charge + direct discharge" slots, because that is annoying and AI says it would be around a 100 line incremental code change. But of course that is also a short-term fix compared to the bigger planner refactoring + forecast window increase.

Thanks! :)

[ffunes]

Thanks @anorakophobia, the analysis was spot on. I've implemented both parts, merged into release/v1.5.1 for the next beta, so please don't start a PR for #649:

• [BUG] Dynamic pricing: arbitrage ceiling uses dear hours that lie before the selected slots; plan is dropped once the peak has passed #649, per-slot valuation: each charge slot is now valued only against the slots that start after it. An earlier peak no longer justifies a later charge, and the plan doesn't collapse when that peak leaves the horizon. The guaranteed floor keeps its [BUG] Dynamic Pricing deficit plan grid-charges in the evening peak, above every later grid price (loses money; margin not applied) (v1.5.0) #724 exemption (capped by Max Price Threshold). This isn't your full pairing model, but it removes the time-order bug.
• Next day forecast #710, horizon: once tomorrow's prices are published, the charge planner extends to the sunrise after tomorrow. That requires a dated solar forecast for tomorrow (Energy dashboard) and a learned consumption profile; without them nothing changes. Each deadline through tomorrow gets the cheapest slots before it, so tonight is weighed against tomorrow's sun and evening peak. Only tonight's slots are scheduled; tomorrow's are re-planned at the 00:05 run.

Your #662 fix for short charges discharged within the hour is still welcome. Please base it on the next beta so it doesn't conflict with these changes.

[anorakophobia]

(AI-written note on behalf of @anorakophobia)

Thanks @ffunes, that was quick. We won't open a #649 PR and will drop our branch; your per-slot valuation covers what it was for.

My install has run release/v1.5.1 since today (with your #649 and #710 changes, plus #704 and #654), together with the reserve solar-curve PR #755. I'll report what the planner does once tomorrow's prices are in.

The short-charge fix for #662 books a depletion step only in a slot that pays at the time the energy is used, and leaves the step to the grid otherwise. I'll rebuild it on the next beta and open it as its own issue and PR after checking it against a live night. With the deadlines now running through tomorrow it touches more slots, so that check matters more.

[anorakophobia]

(AI-written note on behalf of @anorakophobia)

Seen live on my install (release/v1.5.1 build): when tomorrow's Tibber prices came in at 14:22, the planner re-evaluated at once and energy_horizon_end moved from today's sunrise to 7 Nov 00:00, where the price data ends. The deadlines now run through tomorrow evening, and 4.0 kWh is booked in tonight's 02:45 to 04:30 slots. Works as described, thanks.

[ffunes]

With Dynamic Pricing, once tomorrow's prices are published Omnibattery now plans up to the sunrise after tomorrow, weighing tonight's slots against tomorrow's solar and peaks. It needs a dated solar forecast in the Energy dashboard. This ships in v1.6.0. Thanks @JohnnydeJong.

[JohnnydeJong]

@ffunes Thanks!!