[FEATURE] Predictive Charging should look past midnight to the next sunrise

[rrozema]

Area of the proposal

Energy management or control strategy

What problem would this solve?

Currently, the energy and consumption predictions reset and operate on a calendar-day window (midnight to midnight).
​When using a dynamic energy contract, this creates a significant gap during the morning peak hours (typically 06:00 – 09:00). At midnight, the integration considers the day "done", but the battery needs enough energy stored to bridge the night until the sun actually starts generating power the next morning.
​As a result, the battery often runs out of charge during the early morning hours, forcing grid consumption during peak-rate hours right before solar generation begins.

Proposed solution

It would be great to have a prediction horizon that looks ahead beyond midnight—ideally until the expected solar generation onset (or a rolling 24-hour window) rather than cutting off at 00:00.

Specifically:
Solar-onset horizon: When calculating required storage/charge levels for the night, the integration should budget for expected consumption from midnight up to the moment solar production exceeds household load the next morning.

Dynamic price awareness for morning peaks: Take into account high energy tariffs during the morning peak (06:00 – 09:00) when deciding whether to charge from the grid overnight (during low-rate hours).

Example use case

Yesterday i had an unusual low solar production -less than needed to get to midnight on the battery alone-. I have Predictive Charging activated, so the integration charged additional energy from the grid. It calculated it needed to charge only .5kWh. that .5kWh did by far not charge my battery to the max soc (it charged to 76%), and as a result the battery was empty around 3am, with my home running the rest of the morning completely on grid power, including the expensive morning peak hours just before sunrise.

Who would benefit from this?

Most Omnibattery users

Alternatives or workarounds

I adjusted predictive charging settings:
Solar safety marging to 4kWh (which is over 50% of my usable soc) and Grid charge margin to 50%, but this lacks dynamic adjustments based on the actual forecasted solar production and household load for the next morning.

Additional context

Dynamic Contract Provider: Tibber
​Solar forecast integration used: Solar forecast ML
Battery: 1x Zendure Solarflow 4000 MIX AC+
Grid type: single fase 1 x 35A

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 do agree with you we need something to cover the night.

Currently this is my prediction until midnight:

✓ Sufficient energy for the rest of today

🔋 Battery: 35% (3.48 kWh usable)
☀️ Solar remaining until midnight: 2.30 kWh
📊 Home consumption remaining until midnight: 5.64 kWh
Basis: learned 15-minute profile

✅ Available for this horizon: 5.78 kWh ≥ 5.64 kWh needed
⚙️ Price thresholds: arbitrage ceiling ≤ 0.2336 €/kWh
No additional grid charging required.

---

This means I will have empty batteries just after midnight.

And this are the prices today and tomorrow, so better could have charged from grid a bit more during cheap hours:

[TobiS87]

I completely second this and already adressed this in #344

We technically already have min SOC settings whcih just dont work as intended

This setting says it will accomodate for morning needs but it just adds slots to the charging to reach the min SOC in the charging window:

The setting is just build if the min prices are in the night-time but thats not the reality. Renewable energies and stuff switched the lowest energy prices in the midday areas of the day so when we set dynamic prices for charging the battery by grid (what hopefully everybody does) the battery charges from the grid at evening and not at night.

Soin my example in the end of the day I am left with 22% SOC which wont be sufficient for the morning needs. When I deactivate min SOC its even worse:

Omnibattery plans on depleting my battery by 22:45. That should not happen imo because i have a really cheap energy window right now and a very expensive energy window later in the day. I am not asking for Omnibattery doing the price calulation (I am already doing in internally and Omnibattery just wanting to cover the acutal household need is fine by me) - but I need a setting which gurantees me a min SOC by the last slot (so at 23:45).

So in my example I would really love a setting "min SOC by end of estimation window" where Omnibattery plans the day (with planned household comsumption, solar and grid charge) so that by the END of the day there is a minimum SOC reached (eg. 40 percent - should be in the settings) - so I can set this value to safely cover the morning energy consumption.

This would be the easiest way I guess because Omnibattery estimates at 0:05 o'clock (i guess) and has to make a decision at one point how far ahead it wants to plan - planning the morning hours as well can leave the hours after that with too less energy. A min SOC at planning window end is customizable and easy to implement (I guess at least).

[Nieass]

Well at 23:59 is an option but I would rather prefer the option "before sunset".

I was also thinking about an option around Midnight and proposed that to @ffunes before.

But at the end best option would be count the night in. Since we have profiles now it could predict your usage for the night.

Night consumption variates alot over the years. Atleast here it does, summers have low night consumption but winters got high consumption because of the heatpump.

Using the learned profile for night consumption prediction would be the best then.

But... would be harder to integrate then just a 23:59 soc limit.

The rolling 24 hours Window would also be a nice idea but also pretty complex to integrate since it has to use solar today and solar tomorrow sensor. And we already have alot of sensors the integration uses.

[syphernl]

One thing that might help scope this: the midnight cut sits on the energy side only, not on the prices.

Where the cut is

Consumption is bounded to the calendar day, via forecast_consumption_between(profile_start, profile_start + timedelta(days=1)) in _should_activate_grid_charging. Prices already run further. With the re-evaluate button the horizon is max(end_of_today, now + 12h), so an afternoon press reads slots well into tomorrow. The planner can price a night it is not allowed to budget for.

This came up before: closing #228, ffunes noted the risk of "leaving the current night insufficiently covered". Same night, and right now it is uncovered by construction.

Both inputs are there in time

Tomorrow's solar forecast is available all day. Day-ahead prices land around 13:00 CET, and after that a re-plan would have both. Nothing triggers a re-plan on price publication today.

Today, here

NL, 10 kWh of Marstek:

Sufficient energy: 8.47 kWh available >= 5.47 kWh consumption
planned grid charge: 0.00 kWh
prices: 12:00 EUR 0.163 | 13:00 EUR 0.163 | 19:00 EUR 0.400

Correct for the horizon it was given, and the two cheapest hours still go unused.

Possible scope

Ending the energy horizon at the next solar onset, kept separate from the extended_horizon flag so restart recovery is untouched, looks like a fairly small change. Happy to write it if you want it.

[TobiS87]

Thanks for digging deeper. Would be great if you could implement that into a pull request. 🙂

Right now I try to cover my morning peak usage by trying to automatically manipulate the min-SOC settings after new energy prices are available. I then test, if charging today for tomorrow's morning needs is economically smart or not. If it is - I automatically set the min SOC threshold of the predictive charging system so that the battery has a given SOC by the end of the day.

That's completely hacky and not a very satisfying solution. I was able to implement nearly every additional feature I wanted from my wanted smart charging/discharging integration and Omnibattery is a great foundation for that but covering the morning peak consumption has been a nightmare so far for me.

[Nieass]

@syphernl would really appreciate if you could code it 😊 for me it looks like I will have empty batteries upcoming night at around 3am. I better should have grid charged then a bit during cheap hours to cover it.

[syphernl]

We'll have to wait until @ffunes signs off on this, once he's done that I could create a PR to implement this change.

[Nieass]

Thanks for digging deeper. Would be great if you could implement that into a pull request. 🙂

Right now I try to cover my morning peak usage by trying to automatically manipulate the min-SOC settings after new energy prices are available. I then test, if charging today for tomorrow's morning needs is economically smart or not. If it is - I automatically set the min SOC threshold of the predictive charging system so that the battery has a given SOC by the end of the day.

That's completely hacky and not a very satisfying solution. I was able to implement nearly every additional feature I wanted from my wanted smart charging/discharging integration and Omnibattery is a great foundation for that but covering the morning peak consumption has been a nightmare so far for me.

Could you share that automation? I could use it until this option will (maybe) be worked out.

[TobiS87]

Thanks for digging deeper. Would be great if you could implement that into a pull request. 🙂
Right now I try to cover my morning peak usage by trying to automatically manipulate the min-SOC settings after new energy prices are available. I then test, if charging today for tomorrow's morning needs is economically smart or not. If it is - I automatically set the min SOC threshold of the predictive charging system so that the battery has a given SOC by the end of the day.
That's completely hacky and not a very satisfying solution. I was able to implement nearly every additional feature I wanted from my wanted smart charging/discharging integration and Omnibattery is a great foundation for that but covering the morning peak consumption has been a nightmare so far for me.

Could you share that automation? I could use it until this option will (maybe) be worked out.

I cant really unfortunately. It's part of a pretty extensive AppDaemon Script wich goes in conjunction with entities from other custom integrations and so on. It does more than automatically covering the morning comsumption.

What this part is doing is checking the 23:45 predicted SOC by Omnibattery and see if its under a certain threshold. If it is I just check a hardcoded morning peak and see if its more benefitial to charge the morning consumption today. As my cheapest grid charging slots are mostly early afternoon I check that right when the energy prices for tomorrow are available. Omnibattery just checks to cover the consumption needs. My script is focussed on being economically efficient. So it might be better to not charge and just use the grid energy (considering roundtrip efficiency and so on). So if its benfitial to charge for tomorrow I just enable the min SOC for predicitve charging and raise it to the predicted peak SOC plus the delta of the predicted SOC at 23:45 and the SOC target at that time.

Might be possible to achieve all this by an automation but you need to access Omnibattery's timeline values by parsing lists and dictionaries.

[stefbontinckx]

Hi everyone, I would like to chime in on this discussion with my specific use case and a related request.

My setup:

• Home Assistant with the Omnibattery integration
• Marstek V3 battery
• Dynamic energy prices
• EVCC managing my EV charging

The issue I'm facing:
During the day, EVCC perfectly routes all my solar surplus to the EV. The home battery does not discharge to the EV (which is intended). However, because the EV consumes all the solar energy, my Marstek V3 ends up completely empty by the late afternoon.

EVCC prioritizes the battery and is aware of the SoC, but the battery priority is overrules by EVCC when there is a charging plan or EVCC sees a low grid price where it's allowed to charge from the grid.

The problem with the current Predictive Charging logic is that it realizes this too late. By the time it evaluates the low SoC and the lack of remaining solar for the day, the cheap grid charging windows have already passed.

Even more problematic: when it does need to charge from the grid, Omnibattery needs to actively "claim" its charging spot/capacity. Currently, EVCC can sometimes counteract by claiming the remaining available grid power. If Omnibattery calculates its plan earlier and schedules a definitive grid-charging block, it could secure its needed charge before the expensive evening hours begin. EVCC should scale down if house or battery starts asking for more power.

My current workaround & feature request:
Right now, I have to manually force a re-evaluation by clicking "Recalculate prices" in the Omnibattery UI when I notice the solar is gone and the battery is empty. I wanted to automate this, but there is no standard HA service exposed for this button.

It would be fantastic if Predictive Charging could be made more dynamically aware of SoC and zero-remaining-solar situations, so it re-evaluates the charging plan earlier in the afternoon. This would allow it to schedule and claim a 'grid charge' block before EVCC takes all the available grid power or the prices peak.

In the meantime, could the "Recalculate prices" action be exposed as a callable service in Home Assistant so we can automate this workaround?

Thanks for all the great work on this integration!

I know it's difficult, because both EVCC and the battery wants to charge - but someone knows how I can handle this.

[iceicerickert]

after installing omnibattery and playing with it im very happy except im missing 2 features. This one, #270 and #237.
They all are very popular and I understand why. With those 3 you have a very complete package and I think nothing else for home-assistant comes close to that feature set.
Maybe we can sign off on those 3 so we can start implementing the changes?

[ffunes]

Implemented — this is in the next 1.5.0 beta.

What changed:

• The planning horizon now ends at the next local sunrise instead of at midnight. Predictive charging budgets the consumption between midnight and sunrise as part of the same plan, so the overnight deficit is sized against the hour the sun actually takes over rather than against 00:00.
• The discharge reserve follows the same horizon, so energy held back in the evening is held through the small hours instead of being released at midnight.
• The plan is rebuilt when tomorrow's prices are published (~13:00 CET), so the overnight slots are chosen once the cheap hours after midnight are actually known — which is what makes the extended horizon useful rather than just longer.
• The sunrise horizon is reported in the predictive-charging diagnostics, so you can see which instant the plan is budgeting to.

The failure mode described in this thread — a small top-up sized to reach midnight, battery flat in the small hours, morning peak covered by the grid — is exactly what this addresses: the charge was budgeted to the wrong deadline.

Once the beta is out, confirmations on a low-production day would be very welcome, from anyone here on a dynamic contract. And if you had raised the solar safety margin or the grid charge margin to compensate for this gap, it's worth winding those back down afterwards and re-checking.

[ffunes]

This is now out in 1.5.0b3, so it can be tested on a real low-production day.

Reminder for anyone who padded the solar safety margin to work around the midnight cut: wind it back down and re-check, the plan now sizes the overnight charge against sunrise by itself.

[TobiS87]

Did that and so far it looks good. Great work! Thanks for explicitly stating the overnight demand as an attribute, too so I was able to read it and treat it differently in my automations (for charging purposes)

For me the "look till sunrise" rule is a bit counterintuitive, because my solar system is facing west. As a refinement I would really like an option for that. Maybe the option to look until sunrise or a specific hour in the morning (like a combo box with options from 6 to 12.o clock or sth).

But so far everything looking good. Thanks again.

[iceicerickert]

this looks awesome, I will migrate from my own custom sensors to the complete solution this week and report back.