Affected area
Battery communication or availability
Omnibattery version
1.4.0
Home Assistant version
2026.9.1
Installation details
Battery brand and exact model: Marstek Venus v03, 5.12 kWh
Battery firmware version (identical for both batteries): EMS 150, BMS 115, VMS 119, communication module 202409090159
Connection method or adapter: Wired Ethernet, Modbus TCP
Number of batteries: 2
Consumption sensor and update interval: HomeWizard P1 meter, sensor.p1_meter_vermogen, approximately every second
Installation type (single-phase or three-phase): 3-phase, 3x35A
What happened?
Predictive charging evaluates at approximately 00:05 and reads the configured solar forecast sensor. At that moment Forecast. Solar has not yet refreshed its "remaining today" sensor for the new day, so the value is still 0.0 kWh, left over from the previous evening. The integration therefore concludes there is an energy deficit, and plans grid charging slots that are not needed. Later the same morning the integration correctly reports sufficient energy, but the slots planned at midnight remain in the plan and are executed.
Environment (see also above)
- Omnibattery version: 1.4 (please confirm in the attached attributes)
- Home Assistant Core: 2026.9.1
- Batteries: 2x Marstek Venus, 10.24 kWh total
- Grid meter: HomeWizard P1
- Solar forecast sensor: sensor.energy_production_today_remaining
(Forecast.Solar)
- Price integration: Tibber, dynamic pricing mode
- Predictive Grid Charge Margin: 0 %
- Predictive Safety Margin: 0 kWh
- Guaranteed Minimum SOC: switch disabled
Observed on two consecutive days (update for 3rd day: see further down below): On both days solar_forecast_initial_kwh was 0.0 while the actual forecast for the day was over 13 kWh.
Attributes captured from binary_sensor.*_predictive_charging_active:
solar_forecast_initial_kwh: 0.0
solar_forecast_initial_date: '2026-09-18'
evaluation_time: '2026-09-18T00:05:00.399522'
solar_forecast_remaining_sensor: sensor.energy_production_today_remaining
solar_forecast_source: remaining
pricing_mode: dynamic_pricing
schedule_type: deficit
hours_needed: 4.25
estimated_cost: 3.33585
remaining_solar_kwh: 29.2
remaining_consumption_kwh: 10.68
total_available_kwh: 31.5014
energy_deficit_kwh: 0.0
planned_grid_charge_kwh: 0.0
decision_reason: 'Sufficient energy: 31.50 kWh available >= 10.68 kWh consumption'
The decision_reason at 09:50 is correct. The plan created at 00:05 is not. The slot from 09:45 to 10:00 was executed at 0.2746 EUR/kWh while the batteries could have been filled from solar later that day.
On the second day, the same happened: 0.0 kWh at evaluation against 13.5 kWh forecast, with an estimated cost of 0.71 EUR. The batteries reached 99 % SOC by midday, after which the house exported almost 4000 W because there was no storage capacity left.
This is not a configuration problem:
The forecast sensor was changed from sensor.energy_production_today to sensor.energy_production_today_remaining on 10 September, on the explicit request of an Omnibattery repair notification asking for the "remaining today" provider sensor. Reverting is therefore not a solution. Forecast.Solar refreshes on its own schedule, not at midnight. Any installation using a "remaining today" sensor is likely to hit this condition.
Suggested fix:
Treat a solar forecast of exactly 0.0 kWh as suspect when daylight is expected for the coming day, and either postpone the evaluation until the forecast sensor has refreshed, or fall back to the whole-day forecast sensor for that single evaluation. An alternative would be to re-evaluate the remaining slots once the forecast becomes available, and drop slots that are no longer needed when energy_deficit_kwh has returned to 0.
Third consecutive occurrence:
Same pattern again this morning. Captured at 09:21 local time:
solar_forecast_initial_kwh: 0.0
forecast for today (sensor.energy_production_today): 15.299 kWh
hours_needed: 5.25
estimated_cost: 0.9938 EUR
Three consecutive days now. On all three the evaluation at 00:05 read 0.0 kWh while the actual forecast for the day was between 13 and 30 kWh.
A correction to my original report: the re-evaluation does work.
I should correct one thing I said earlier. The integration does re-evaluate during the day, and it does so with a correct forecast. I received two notifications today:
At 08:41 local time, "Predictive Charging: slot 09:45 confirmed - charging needed":
Battery: 31% (1.95 kWh usable)
Solar remaining until midnight: 15.18 kWh
Home consumption remaining until midnight: 19.23 kWh
Basis: learned 15-minute profile
Energy deficit: 2.10 kWh
Slot: 09:45-10:00 @ 0.1357 EUR/kWh
At 09:15 local time, "Predictive Charging: Evening re-evaluation":
Solar ending - batteries not full (28% avg)
Deficit: 1.99 kWh
Cheap slots scheduled: 15:00-15:15 (0.1331), 15:15-15:30 (0.1332),
15:30-15:45 (0.1343), 15:45-16:00 (0.1343)
Both of these are reasonable decisions based on correct data. The deficit calculation is correct and the selected slots are the cheapest of the day. So the impact of the midnight bug is narrower than I first described: the plan is corrected later in the morning. What remains is that slots from the incorrect midnight plan can already have been executed before the first re-evaluation takes place. This happened on the first day.
My suggestion stays unchanged:
Treat a solar forecast of exactly 0.0 kWh as suspect at evaluation time when daylight is expected, would remove the problem at the source and make the first plan of the day correct rather than relying on a later correction.
Thanks for developing Omnibattery.
Steps to reproduce
See previous.
Expected behavior
See previous.
Relevant Home Assistant logs
Diagnostics file
N/A
Additional context
N/A
Confirmations
Affected area
Battery communication or availability
Omnibattery version
1.4.0
Home Assistant version
2026.9.1
Installation details
Battery brand and exact model: Marstek Venus v03, 5.12 kWh
Battery firmware version (identical for both batteries): EMS 150, BMS 115, VMS 119, communication module 202409090159
Connection method or adapter: Wired Ethernet, Modbus TCP
Number of batteries: 2
Consumption sensor and update interval: HomeWizard P1 meter, sensor.p1_meter_vermogen, approximately every second
Installation type (single-phase or three-phase): 3-phase, 3x35A
What happened?
Predictive charging evaluates at approximately 00:05 and reads the configured solar forecast sensor. At that moment Forecast. Solar has not yet refreshed its "remaining today" sensor for the new day, so the value is still 0.0 kWh, left over from the previous evening. The integration therefore concludes there is an energy deficit, and plans grid charging slots that are not needed. Later the same morning the integration correctly reports sufficient energy, but the slots planned at midnight remain in the plan and are executed.
Environment (see also above)
(Forecast.Solar)
Observed on two consecutive days (update for 3rd day: see further down below): On both days solar_forecast_initial_kwh was 0.0 while the actual forecast for the day was over 13 kWh.
Attributes captured from binary_sensor.*_predictive_charging_active:
solar_forecast_initial_kwh: 0.0
solar_forecast_initial_date: '2026-09-18'
evaluation_time: '2026-09-18T00:05:00.399522'
solar_forecast_remaining_sensor: sensor.energy_production_today_remaining
solar_forecast_source: remaining
pricing_mode: dynamic_pricing
schedule_type: deficit
hours_needed: 4.25
estimated_cost: 3.33585
remaining_solar_kwh: 29.2
remaining_consumption_kwh: 10.68
total_available_kwh: 31.5014
energy_deficit_kwh: 0.0
planned_grid_charge_kwh: 0.0
decision_reason: 'Sufficient energy: 31.50 kWh available >= 10.68 kWh consumption'
The decision_reason at 09:50 is correct. The plan created at 00:05 is not. The slot from 09:45 to 10:00 was executed at 0.2746 EUR/kWh while the batteries could have been filled from solar later that day.
On the second day, the same happened: 0.0 kWh at evaluation against 13.5 kWh forecast, with an estimated cost of 0.71 EUR. The batteries reached 99 % SOC by midday, after which the house exported almost 4000 W because there was no storage capacity left.
This is not a configuration problem:
The forecast sensor was changed from sensor.energy_production_today to sensor.energy_production_today_remaining on 10 September, on the explicit request of an Omnibattery repair notification asking for the "remaining today" provider sensor. Reverting is therefore not a solution. Forecast.Solar refreshes on its own schedule, not at midnight. Any installation using a "remaining today" sensor is likely to hit this condition.
Suggested fix:
Treat a solar forecast of exactly 0.0 kWh as suspect when daylight is expected for the coming day, and either postpone the evaluation until the forecast sensor has refreshed, or fall back to the whole-day forecast sensor for that single evaluation. An alternative would be to re-evaluate the remaining slots once the forecast becomes available, and drop slots that are no longer needed when energy_deficit_kwh has returned to 0.
Third consecutive occurrence:
Same pattern again this morning. Captured at 09:21 local time:
solar_forecast_initial_kwh: 0.0
forecast for today (sensor.energy_production_today): 15.299 kWh
hours_needed: 5.25
estimated_cost: 0.9938 EUR
Three consecutive days now. On all three the evaluation at 00:05 read 0.0 kWh while the actual forecast for the day was between 13 and 30 kWh.
A correction to my original report: the re-evaluation does work.
I should correct one thing I said earlier. The integration does re-evaluate during the day, and it does so with a correct forecast. I received two notifications today:
At 08:41 local time, "Predictive Charging: slot 09:45 confirmed - charging needed":
Battery: 31% (1.95 kWh usable)
Solar remaining until midnight: 15.18 kWh
Home consumption remaining until midnight: 19.23 kWh
Basis: learned 15-minute profile
Energy deficit: 2.10 kWh
Slot: 09:45-10:00 @ 0.1357 EUR/kWh
At 09:15 local time, "Predictive Charging: Evening re-evaluation":
Solar ending - batteries not full (28% avg)
Deficit: 1.99 kWh
Cheap slots scheduled: 15:00-15:15 (0.1331), 15:15-15:30 (0.1332),
15:30-15:45 (0.1343), 15:45-16:00 (0.1343)
Both of these are reasonable decisions based on correct data. The deficit calculation is correct and the selected slots are the cheapest of the day. So the impact of the midnight bug is narrower than I first described: the plan is corrected later in the morning. What remains is that slots from the incorrect midnight plan can already have been executed before the first re-evaluation takes place. This happened on the first day.
My suggestion stays unchanged:
Treat a solar forecast of exactly 0.0 kWh as suspect at evaluation time when daylight is expected, would remove the problem at the source and make the first plan of the day correct rather than relying on a later correction.
Thanks for developing Omnibattery.
Steps to reproduce
See previous.
Expected behavior
See previous.
Relevant Home Assistant logs
Diagnostics file
N/A
Additional context
N/A
Confirmations