Quick Summary (TL;DR)
To forecast how much rooftop solar a household can actually use, combine a time-aligned PV generation forecast with a forecast of the household’s ordinary load, then test both against measured history. Tomorrow’s predicted 20 kWh of solar energy is not 20 kWh of spare energy: your fridge, heating, cooking, batteries and other appliances may already consume a large portion. The useful quantity for scheduling is the positive difference between PV production and expected demand in each time interval, subject to inverter, grid, charger and appliance limits.
Start with reliable grid import, grid export and PV generation readings, ideally as cumulative energy counters suitable for Home Assistant’s Energy dashboard. For a solar-only installation without a battery or another export source, you can infer household consumption from correctly aligned measurements. Next, build weekday/weekend or hour-of-day load profiles and compare those against a service such as Forecast.Solar. Keep a measured forecast-error range, not just a single attractive number, and schedule only genuinely flexible loads with their own approved safety controls.
Best first implementation: record actual PV and household electricity use for at least several weeks, use the forecast to identify likely daylight surplus, and create read-only dashboard sensors or notifications. Test forecast accuracy across cloudy, sunny and changeable conditions before using the estimate to request EV charging or hot-water heating. For essential heating, battery BMS functions, grid-export limiting and EV supply protection, leave the manufacturer’s certified equipment in control.
This guide covers solar forecasting as an engineering and buying decision for Home Assistant users, not just the Energy dashboard forecast overlay. For the PV forecast service comparison, see Solar Forecasting in Home Assistant: Forecast.Solar vs Solcast. For reliable source measurements, see Solar Import and Export Metering: Avoiding Double Counting in Home Assistant.
What solar self-consumption forecasting actually predicts
Three forecasts are frequently confused. A PV production forecast estimates the electricity a solar array will generate. A household demand forecast estimates the electricity the property will consume before optional load-shifting. A solar surplus forecast estimates when PV exceeds the household’s baseline load, leaving energy that might be exported or used by a flexible device. You need at least the first two for a defensible estimate of the third.
A fourth quantity, self-consumption, describes how much of the measured PV output actually remains in the household rather than being exported, under a carefully defined measurement boundary. Self-sufficiency is different: it describes how much of the household’s consumption is supplied by onsite generation, and sometimes by storage charged from that generation. Neither ratio automatically tells you when there is enough power to run an EV charger.
Day-ahead forecasts address a different decision from real-time solar tracking. A day-ahead estimate is useful for choosing a preferred laundry window, preparing an EV departure plan or anticipating hot-water needs. It is not an electrical interlock and cannot guarantee sufficient power at any moment. Real-time closed-loop charging or export management requires appropriately rated metering and manufacturer-approved controllers. Forecasts should inform a schedule; live feedback and native protections must enforce its physical limits.
The simplest useful model divides the day into hours. A more detailed installation can use 30-minute or 15-minute slots, but only if the PV forecast, load model, actual meters and tariff data all refer to the same intervals. Finer granularity does not create accuracy if the input data were only collected once an hour.
| Quantity | Definition | Typical unit | What it is not |
|---|---|---|---|
| PV forecast | Expected energy generated in each interval | kWh per hour or 15 minutes | Instantaneous guaranteed spare power |
| Baseline load forecast | Expected non-deferrable household demand in same interval | kWh per interval | Total consumption including a newly scheduled EV session |
| Positive forecast surplus | max(0, PV forecast − baseline demand) | kWh per interval | An assured minimum export or dispatchable resource |
| Instantaneous headroom | Measured PV power − measured coincident non-flexible demand | W or kW | A prediction of the entire next hour |
| PV self-consumption ratio | PV used on-site ÷ PV generation, using consistent boundaries | % | The same as grid independence |
| Self-sufficiency ratio | Demand served by qualifying onsite energy ÷ total demand | % | The same as PV self-consumption |
| Forecast interval | A timestamped start and end for energy accumulation | Local time or UTC | Just an hour label without timezone |
Select the correct measurement boundary first
Before writing an automation, make a one-line electrical diagram that includes the utility meter, inverter, consumer unit, possible home battery and EV charger. Identify where each device measures energy. An inverter’s DC panel energy is not the same as AC energy delivered at the property busbar: conversion losses, clipping, battery routes and standby consumption may appear between those locations. Likewise, the grid meter is a measure of net exchange with the distribution network, not necessarily the electrical demand of all loads.
For a typical solar-only, AC-measured, no-battery home, a time-aligned relationship is: household load = PV generation + grid import − grid export. Express every term as energy accumulated over the same interval, or as consistently signed simultaneous powers. If you receive grid import/export from separate cumulative kWh meters, take their validated interval deltas before calculating the load. Do not subtract totals covering different clock windows.
For example, during 12:00–13:00 the PV inverter reports 3.2 kWh, the grid import register rises by 0.1 kWh, and the export register rises by 1.4 kWh. The inferred property demand is 3.2 + 0.1 − 1.4 = 1.9 kWh. This is a property total, not an appliance breakdown. It may include hot-water or EV energy that you should remove from a non-flexible baseline to avoid training the model on the very loads you intend to schedule.
A home battery changes that accounting. Using signed AC-side energy flows at the same measurement boundary, an illustrative relationship is load = PV + grid import − grid export + battery discharge − battery charge. The precise formula must follow the actual topology: a hybrid inverter may report PV and battery values on a DC bus, some systems combine house load and inverter self-consumption, and some permit exporting stored grid energy. Never apply the simple no-battery identity to a DC-coupled battery without verifying where conversion losses and storage flows have been measured.
| System topology | Usable baseline reconstruction | What to check first | Common false conclusion |
|---|---|---|---|
| Solar only, no storage | PV AC + grid import − grid export | Same interval and phase boundary | Exported kWh can be subtracted from monthly PV kWh without time alignment |
| AC-coupled battery | Add measured battery discharge and subtract charge | Battery values are AC-side and signed consistently | Export must always come from PV |
| DC-coupled hybrid inverter | Use documented hybrid load entity or validated energy-flow model | Where PV and battery losses are counted | DC PV power equals delivered AC PV power |
| EV charger with own meter | Subtract controllable EV consumption from historical base load if scheduling it | Whether charger kWh includes losses and standby | Past EV charging is ordinary baseline demand |
| Solar thermal or hot-water diversion | Keep electrical PV and immersion energy in electrical boundary | Diverter output and meter topology | Hot-water thermal energy equals electrical PV generation |
| Three-phase system | Measure all phases or use correct whole-site net aggregation | Per-phase netting and importer/exporter rules | A single CT sees the full three-phase household |
Which historical data do you need?
The foundation is not an elaborate machine-learning model; it is a trustworthy dataset. At minimum, collect timestamped PV generation and the household’s net grid exchange, with meter totals retained through reboots. Stronger models add temperature, weekday versus weekend, occupancy proxy, controllable-load operation and local events that meaningfully change demand. The goal is to capture predictable baseline demand while preserving variation caused by cooking, visitors, weather and equipment faults.
Use cumulative meter readings for energy accounting where available. A native inverter energy sensor or a calibrated DIN-rail meter often gives a more defensible kWh series than integrating sporadically updated power samples. Home Assistant’s Integral integration can estimate energy from a power sensor, but its accuracy depends on sampling method and interval. For unusual loads with short power spikes, a 60-second polling rate can miss substantial energy even when the plotted curve looks plausible.
Record the time zone and timestamp convention. A timestamp such as “13:00” is ambiguous: it might represent the start of 13:00–14:00, the hour ending at 13:00, or an instantaneous value sampled at 13:00. Store all observations with explicit times and preferably UTC for joining and archival work, then convert to local civil time for weekday/weekend features and display. Daylight-saving days have 23 or 25 hours in many regions; do not silently insert or drop a repeated 02:00 slot.
Keep an operational inventory for each sensor: entity ID, source device, physical boundary, phase coverage, unit, state class, update frequency, expected reset behaviour and when it became reliable. If a sensor was replaced, an inverter firmware changed its semantics or a home battery was installed, mark that date and treat earlier history separately. Training on technically inconsistent years of data is often worse than training on a few clean weeks.
| Historical field | Recommended observation | Why it matters | Quality check |
|---|---|---|---|
| PV energy | Cumulative AC inverter kWh; interval difference | Actual production and forecast bias | Monotonic except documented resets; comparable to inverter portal |
| Grid import | Import kWh at point of connection | Billing and demand reconstruction | Positive interval deltas, meter rollover handling |
| Grid export | Export kWh at point of connection | Unused PV and lost export revenue | No inverted CT signs; grid meter reconciliation |
| Flexible load energy | EVSE, hot-water and other metered load kWh | Remove historical controllable loads from baseline | Account for charging and heater standby |
| Outdoor temperature | Same-hour temperature with clear location | Heat-pump, HVAC and seasonal changes | No improbable jumps or indoor placement |
| Occupancy or calendar | Home/away, workday, holiday where lawful and useful | Separate systematically different daily profiles | Avoid collecting unnecessary personal detail |
| Battery flows | AC charge/discharge kWh and state of charge | Avoid mistaking battery energy for PV surplus | Check sign, boundary, SOC range |
| Forecast snapshot | Issued-at timestamp and forecast for each future interval | True day-ahead validation | Never validate using forecast updated after event |
| Actual generation time series | Intervals identical to forecasts | PV error and solar surplus actuals | Missing data flags and day-boundary consistency |
How much history is enough?
A sensible pilot can start after two to four weeks of clean hourly data, but that period is only enough to build a basic operational baseline. It is unlikely to capture the range of seasons, holidays, heating modes and weather regimes needed for strong annual decisions. Collect one or two months for a meaningful early comparison, and keep evaluating performance as conditions change. Do not assume that a 30-day average will predict a household through a cold winter or a summer with school holidays.
Prefer a layered baseline over a complex black box. A weekday-by-hour median is a robust first estimate: it often resists one-off dishwasher and oven spikes better than the arithmetic mean. Keep an independent weekend profile. If the home’s heating load depends strongly on outside temperature, condition the forecast on temperature bands or fit a restrained weather model. When individual devices are controllable, exclude their historical consumption from the baseline and model their energy requirements separately.
The median is not a conservative upper bound. Half of observed load samples may exceed it by design. A scheduling algorithm should consider a higher load quantile—say the 75th or 90th percentile of matched historical intervals—to represent a more cautious case. Choose the percentile based on your tolerance for grid import and the cost of being wrong, and validate it on untouched dates rather than treating the percentile as a guarantee.
| Load model | Training input | Advantage | Limitation | Good first use |
|---|---|---|---|---|
| One daily average | Total daily electricity | Fast and simple | No timing resolution | Rough energy budgeting only |
| Hourly weekday/weekend median | Historical grid/PV-derived baseline | Explainable, robust to spikes | Misses heating and occupancy shifts | First implementation |
| Same-day-of-week hourly profile | Past matching weekdays | Captures weekly habits | Low sample count per slot | Stable households with regular schedules |
| Outdoor-temperature regression | Demand, temperature and calendar | Models weather-sensitive load | Hard to separate PV and heating behaviour | Heat pumps and electric heating |
| Quantile baseline | Historical load per hour and cohort | Offers cautious headroom planning | Not a calibrated probability automatically | EV/heat load reservations |
| Autoregressive/ML predictor | Lagged power, weather, calendar | Captures more subtle patterns | Overfitting, missing data and upkeep | After simple model benchmark |
| EMHASS native forecasts | Configured HA/load/PV input entities | Integrated planning and optimisation | More setup and data quality requirements | Complex multi-load scheduling |
Obtaining a solar production forecast in Home Assistant
Home Assistant’s official ‘+link(‘Forecast.Solar integration’,’https://www.home-assistant.io/integrations/forecast_solar/’)+’ estimates PV energy from location, panel orientation, tilt and rated power, using the Forecast.Solar service. The core integration provides sensors for estimated generation today, remaining today, tomorrow and current/next hour, plus power estimates and peak times. The exact entity IDs depend on your installation. You should select entities in Developer Tools rather than copying an example name literally.
The Home Assistant documentation states that Forecast.Solar’s public option supports a single panel plane, at lower forecast resolution; more frequent updates or multiple panel planes require an appropriate paid account. This matters to east-west roofs and arrays with distinct tilts. The integration is cloud-polling, so a local-energy system still needs a fallback when the forecast service or internet is unavailable. That does not mean local inverter measurement must stop; keep observation and cloud forecast as separate dependencies.
Forecast.Solar estimates generated energy, not potential export and not household self-consumption. Use its current-hour and next-hour sensors for the simplest decision aid; to build an entire next-day interval-by-interval dispatch schedule, choose a forecast feed or supported integration exposing the required horizon at the appropriate resolution and verify its units and API terms. Never assume that a “tomorrow” total can be safely split evenly across daylight hours.
The broader ‘+link(‘Home Assistant solar forecasting comparison’,’https://esp32AliExpress price.co.uk/solar-forecasting-in-home-assistant-forecast-solar-vs-solcast/’)+’ discusses forecasting services and support. Solcast-based Home Assistant setups often depend on third-party integration arrangements and product-specific terms; verify current access before choosing one. EMHASS is a separate optimiser that can combine forecasted PV, forecasted load and tariffs, but it does not repair inaccurate sensor boundaries or a missing forecast feed.
| Option | Forecast source | Best fit | Dependency | Check before use |
|---|---|---|---|---|
| Forecast.Solar core integration | Cloud PV model using array geometry and weather | Straightforward PV outlook and Energy dashboard comparison | Internet/service and account tier | Single/multi-plane support, temporal resolution, update rate |
| Solcast-based integration | Solar irradiation and modelling service | Users wanting another PV forecast to backtest | Account/third-party integration and API terms | Current integration maintenance and API limits |
| Inverter vendor forecast | Vendor app/portal or supported gateway | Existing integrated solar ecosystem | Often cloud and vendor-specific | Whether hourly forecast values are accessible locally |
| Simple clear-sky profile | Local clear-sky estimate and learned corrections | Offline fallback and sanity checks | Correct array geometry and seasonal adjustment | Clouds can make errors severe |
| Persistence forecast | Yesterday or recent similar-hour PV | Benchmark only | Local historical measurements | Weather can change rapidly |
| Forecast ensemble | Blend multiple validated forecasts | Users with enough backtest data | Several independent data paths | Weights derived from past error, not intuition |
| EMHASS PV forecast input | Configured external/weather PV forecast | Multi-load scheduling and optimisation | Home Assistant + EMHASS availability | Source, input conventions and solver fallback |
An hourly worked example: from generation to usable surplus
Consider a six-hour daytime forecast for a solar-only house. Every column in the following table is energy in the same one-hour interval, not peak power. The baseline represents household demand excluding the EV charging session you plan to schedule. This example uses illustrative values rather than a claimed typical UK or European household.
The predicted generation totals 11.6 kWh across six hours. Forecast ordinary demand totals 4.65 kWh. The naive daily subtraction gives 6.95 kWh, but that is not the useful surplus because the house imports power in the first hour and can export in others. Summing only the positive interval differences yields 7.20 kWh of estimated surplus and 0.25 kWh of predicted import in the first hour. These quantities reconcile: 11.6 + 0.25 − 7.20 = 4.65 kWh.
That 7.20 kWh is an upper-bound planning pool under the stated assumptions, not seven guaranteed usable kilowatt-hours. A real EV charger needs minimum charging current; appliances can draw short power spikes; the household baseline can be wrong; and excess PV energy in one hour cannot be stored for the next hour unless a battery or other storage exists. Thus scheduling based only on the daily total can lead to import even when the total forecast seems favourable.
| Clock interval | Forecast PV (kWh) | Baseline demand (kWh) | Positive surplus (kWh) | Grid import if unchanged (kWh) |
|---|---|---|---|---|
| 09:00–10:00 | 0.40 | 0.65 | 0.00 | 0.25 |
| 10:00–11:00 | 1.30 | 0.70 | 0.60 | 0.00 |
| 11:00–12:00 | 2.70 | 0.80 | 1.90 | 0.00 |
| 12:00–13:00 | 3.40 | 0.90 | 2.50 | 0.00 |
| 13:00–14:00 | 2.80 | 0.85 | 1.95 | 0.00 |
| 14:00–15:00 | 1.00 | 0.75 | 0.25 | 0.00 |
| Total | 11.60 | 4.65 | 7.20 | 0.25 |
Why hourly energy surplus still does not prove appliance compatibility
Imagine a 1.5 kWh dishwasher cycle lasting 100 minutes, with brief 1.8–2.2 kW heating stages. The forecast may show a total of 3 kWh excess across two hours, yet there may be minutes when only 0.8 kW is truly available. Starting the dishwasher may still import electricity during heater spikes; that can be financially acceptable, but it is not “100% solar-powered”. Use actual appliance power measurements where practical, and consider whether your tariff objective values energy cost more than zero-grid-import purity.
EV chargers add a stricter control dimension. A single-phase AC EV charging session commonly has a minimum nominal current of 6 A under IEC 61851-style control, equivalent to about 1.38 kW at 230 V before charging losses. This does not mean every charger supports smoothly reducing to that current, nor that every car behaves identically. A measured or forecast spare 0.6 kW for an hour cannot sustain ordinary single-phase AC EV charging at that minimum. Phase switching, charge-enable deadbands and charger-native load balancing need to be supported by the exact product and installation.
A home battery can shift PV between hours but changes the economics: round-trip efficiency, backup reserve, tariff prices, cycling losses and any export restrictions must enter the schedule. A hot-water cylinder can store thermal energy but is subject to manufacturer-approved temperature controls, independent overheating protection and local hygiene requirements. The forecast should suggest an eligible period to an approved controller; it must never become the sole over-temperature safeguard.
| Flexible load | Typical decision variable | Constraint that dominates | Common mistake | Practical recommendation |
|---|---|---|---|---|
| Dishwasher | Start time / complete by deadline | Non-interruptible cycle and power spikes | Assume average cycle power is constant | Use manufacturer-supported delay-start and assess measured energy |
| Washing machine | Start time / cycle complete | Safety, unattended operation, water supply | Assume smart plugAliExpress price can press start | Use supported appliance controls or manual recommendation |
| EV charging | Start time / supported current request | Charger/car minimum current, departure time, certified limits | Request below supported minimum current | Use charger-native solar mode and fail-safe limits |
| Hot-water cylinder | Allowed heat period / target within approved controls | Thermostat, hygiene, independent cut-out | Directly switch immersion with arbitrary plug | Use certified hardware and installer-approved controller |
| Heat pump | Setpoint or allowed window within manufacturer interface | COP, weather compensation, compressor cycling | Force heat pump ON/OFF like an immersion | Use supported supervisory setpoint with modest changes |
| Battery charge | Approved reserve or charge target | BMS, inverter export limit, backup requirement | Assume any forecast excess must fill battery | Let native controller enforce operating envelope |
| Pool pump | Runtime within acceptable service window | Filtration, pump duty, manufacturer approvals | Cut mains repeatedly against controls | Use approved schedule and adequate runtime |
Build a proper baseline using measured load history
A baseline should represent the demand expected if you do not run the controllable load you are scheduling. Start by segmenting days into sensible cohorts: weekdays, weekends, holidays, summer/winter or heating-on/heating-off. Then calculate an hourly median for each group. More groups can improve specificity but increase the chance that each hourly bucket has too few examples; a 24×7 profile trained from only three weeks supplies just three examples for each weekday-hour combination.
Do not confuse a baseload with the absolute minimum power observed at night. Refrigerators cycle, immersion heaters may start at dawn, ventilation runs continuously in some homes, and heat pumps can make daytime load strongly temperature-dependent. The relevant baseline is the expected demand in the same future interval under the conditions anticipated for that day. A weekday lunchtime baseline can be higher or lower than nighttime demand depending on people and appliances.
For a simple first model, use the median of all matching historical hours from the preceding four to eight weeks, and compare to a fixed daily-average benchmark. When enough days accumulate, test separate weekday/weekend cohorts. If a heat pump dominates electricity demand, add a weather covariate and compare model errors in temperature bands. Preserve the simplest model that actually improves out-of-sample performance; a complicated predictor that does not beat yesterday’s profile is not adding value.
Exclude data that are invalid before computing the median: communication dropouts, counter resets, inverted CTs and periods when an EV was deliberately charging. It is acceptable for the baseline to include normal cooking and ordinary appliance variability; you are modelling demand, not deleting every inconvenient peak. Mark excluded intervals, so an analyst can reproduce the training set months later.
Separating what was forecast from what was known afterwards
One of the most common forecasting mistakes is to compare an actual sunny afternoon with a PV prediction that was refreshed at 14:00 that same afternoon, then claim an excellent day-ahead score. That is a nowcast, not a true advance prediction. If you intend to choose tomorrow’s water-heating or EV plan at 20:00 tonight, save the forecast snapshot issued at 20:00 and score that exact version against tomorrow’s meter readings. A forecast issued after the energy was generated must not be substituted during validation.
Store at least four fields per predicted interval: issuance timestamp, interval start, interval end, and expected energy. A forecast from another provider can use a different timestep or timezone. Resample by properly summing energy across matching boundaries; do not average interval kWh values as though they were power. When a price feed has 15-minute intervals and a PV forecast has hourly kWh, you may distribute energy across quarters only under a stated interpolation assumption, then report the approximation as a source of uncertainty.
The load model must be validated with the same rigour as the PV model. It is not enough to show that PV forecasts are accurate to 5% on clear days if consumption predictions are wrong by 1.5 kWh every evening. Evaluate PV error, baseline-load error, positive-surplus error and eventually the actual cost of the resulting schedules. A forecast that is excellent in kWh totals can be poor at predicting the one hour that matters most to an EV departure deadline.
| Data timestamp | Represents | Required alignment | Mistake to avoid |
|---|---|---|---|
| Forecast issued at 20:00 Monday | Information actually available on Monday evening | Save snapshot immutably | Replacing it with Tuesday noon forecast |
| Generation 12:00–13:00 Tuesday | Energy delivered across hour | Match Tuesday 12:00 start/end | Comparing with point-in-time forecast in W |
| Baseline 12:00–13:00 Tuesday | House demand excluding deferrable action | Same hour and AC boundary | Including scheduled EV charging in training target |
| Grid export 12:00–13:00 Tuesday | Net energy delivered to grid | Same site meter and local tariff | Treating all export as PV when battery can export |
| Tariff 12:00–13:00 Tuesday | Retail marginal import/export rate | Correct contract and settlement slot | Using day-ahead wholesale rate as bill rate |
| Daylight-saving transition | Skipped or repeated local civil clock hour | UTC interval key and local time label | Dropping duplicated hour or doubling kWh |
Quantify forecast accuracy with errors you can act on
Use multiple metrics rather than a single percentage. Mean absolute error (MAE) is the average magnitude of hourly or daily errors and is easy to interpret in kWh. Mean signed error, or bias, shows whether the model routinely overpredicts surplus or underpredicts demand. Weighted absolute percentage error (WAPE) divides total absolute error by total actual energy, and is more stable than taking individual percentage errors when a cloudy dawn interval has near-zero generation. Root mean squared error (RMSE) is useful if rare large misses matter especially to a device with strict deadlines.
For intervals with observed quantities A and forecasts F: error = F − A. Over N intervals, MAE = Σ|F−A|/N; bias = Σ(F−A)/N; WAPE = Σ|F−A|/ΣA when the denominator is meaningful and non-zero. You can report these separately for PV, demand and surplus. A low daily energy MAE is not proof that hour-by-hour surplus predictions are good. Also track the count of times a supposed 2 kW solar window actually imported 1 kW or more.
Use a chronological split: train on the past, score on the future, then roll the forecast date forward and repeat. A random split can leak patterns from neighbouring hours or include portions of the same weather event in both training and testing. Compare against at least two simple baselines: yesterday’s load at the same hour and a weekday/weekend hourly median. If the new model does not improve the errors that govern your intended action, keep the simpler one.
When estimating uncertainty, use historical residuals from the same forecast horizon and operating conditions. A rough interval could be central forecast ± an empirically measured error quantile, but a symmetric band is not automatically calibrated. A particularly cautious scheduling policy can use the 10th percentile of verified forecast surplus or the 90th percentile of expected baseline load. The band must be tested for coverage on days excluded from fitting, because the claimed “90%” interval may cover far fewer actual cases on stormy days.
| Metric | Calculation | Interpretation | Watch-out |
|---|---|---|---|
| Hourly PV MAE | Average |predicted PV − actual PV| | Typical absolute generation miss, kWh/slot | Not the same as daily MAE |
| Hourly baseline MAE | Average |predicted demand − actual baseline| | Quality of load model | Remove intentionally shifted loads |
| Signed bias | Average (forecast − actual) | Persistent over/underprediction | Positive predicted-surplus bias causes unexpected imports |
| WAPE | Σ absolute errors ÷ Σ actual values | Scale-normalised energy forecast error | Undefined or misleading with zero/negative denominators |
| RMSE | sqrt(mean(error²)) | Penalises occasional large misses | Sensitive to rare extreme days |
| Prediction interval coverage | Fraction actual values inside claimed bounds | Whether uncertainty band is calibrated | Train and test dates must be disjoint |
| False solar-window rate | Share of predicted safe windows needing unwanted grid import | Operationally meaningful failure | Choose an import threshold first |
| Financial regret | Actual cost of selected schedule − best feasible comparator | Does forecast improve household outcome? | Define comparator and feasible constraints fairly |
Worked uncertainty example: why conservative planning is different
Suppose the 12:00–13:00 forecast predicts 3.4 kWh PV and 0.9 kWh base demand, so estimated surplus is 2.5 kWh. A backtest of comparable lead-time forecasts shows that actual PV can be 0.8 kWh below forecast on a cautious case, while household baseline can be 0.4 kWh above forecast. Under that illustrative combination, a planning surplus becomes 3.4 − 0.8 − (0.9 + 0.4) = 1.3 kWh. If you schedule a 2.0 kWh noninterruptible load in that hour, grid import becomes plausible even though the point forecast seemed generous.
This arithmetic uses two adverse deviations for illustration, not a statistically proven joint confidence level. Weather-driven PV error and temperature-driven heating load error may be correlated. The proper approach is to evaluate combined surplus residuals directly, or use a joint simulation that preserves the relationship between PV and load. Adding unrelated upper and lower bands mechanically can be too conservative in some conditions and not conservative enough in others.
A low-risk appliance with a good tariff may still be worth scheduling despite import risk. A homeowner whose goal is to avoid any grid import might use a large reserve margin and accept less solar utilisation. Someone optimising bills may choose a less conservative window if the retail import cost is low and the export tariff is modest. These are different objective functions; do not label one mathematically “best” without stating the goal.
| Case | PV for hour | Base load | Estimated usable surplus | Suitable interpretation |
|---|---|---|---|---|
| Central forecast | 3.4 kWh | 0.9 kWh | 2.5 kWh | Expected, not guaranteed |
| Illustrative PV shortfall | 2.6 kWh | 0.9 kWh | 1.7 kWh | Cloud cover lowers available energy |
| Illustrative load spike | 3.4 kWh | 1.3 kWh | 2.1 kWh | Occupancy/appliances reduce headroom |
| Both adverse outcomes | 2.6 kWh | 1.3 kWh | 1.3 kWh | Cautious scenario, not calibrated percentile |
| No battery or flexible load | Same actual PV | Same actual load | Export where generation exceeds use | Unused energy cannot move in time |
Use Home Assistant to monitor, not blindly command
A safe first deployment creates read-only forecast and surplus sensors. It should not actuate an immersion heater, change inverter reserve levels or switch EV charger supplies. Start by checking the actual entity names in Developer Tools → States, validating power and energy units, and observing updates when your internet connection disappears. A template sensor that displays 0 kWh during an unavailable forecast can falsely look like a valid prediction, so its availability must reflect the source rather than hiding missing values.
The examples below are illustrative YAML fragments for configuration.yaml. Replace their entity IDs with actual installed devices, and use Home Assistant’s configuration check before reloading. The templates assume the Solar forecast next-hour sensor produces kWh for the next hour and a manually maintained input_number helper represents a measured next-hour baseline estimate, also in kWh. That manual helper is a transparent starting point; it is not an automated historical median. Move to a trained forecast only after validating the initial data.
Keep this article separate from hardware wiring instructions. For a low-cost way to verify measured and estimated energy, read ‘+link(‘How to Verify Home Assistant Energy Data Against Your Utility Bill’,’https://esp32AliExpress price.co.uk/how-to-verify-home-assistant-energy-data-against-your-utility-bill/’)+’. For standalone physical monitoring, read ‘+link(‘Whole-Home Energy Monitoring Without Cloud’,’https://esp32AliExpress price.co.uk/whole-home-energy-monitoring-without-cloud-hardware-and-integration-options/’)+’.
YAML example 1: an explicitly configured load-baseline helper
Create a baseline value representing next-hour expected ordinary demand. The helper deliberately does not pretend to predict occupancy or weather; enter a cautious measured value from your own dataset, or have an independently validated model maintain it later. The example below defines the helper in YAML; do not define a duplicate helper with the same entity ID through the UI.
input_number:
solar_load_baseline_next_hour_kwh:
name: Solar baseline next hour
min: 0
max: 20
step: 0.05
unit_of_measurement: kWh
icon: mdi:home-lightning-bolt
initial: 0.8The initial value is only an illustrative default. If a home normally consumes 0.8 kWh per hour at midday but runs a heat pump on cold days, a fixed 0.8 kWh estimate will be inadequate in winter. Treat the helper as input to a proof-of-concept display, not a basis for unattended high-load control.
YAML example 2: next-hour PV surplus estimate with real availability
The next template reads a documented Forecast.Solar next-hour energy entity. Actual entity IDs vary, so inspect your instance; this is sensor.energy_production_next_hour only as an example. Importantly, unavailable or unknown source values propagate as an unavailable sensor instead of defaulting to zero.
template:
- sensor:
- name: Solar forecast surplus next hour
unique_id: solar_forecast_surplus_next_hour
unit_of_measurement: kWh
state_class: measurement
availability: >-
{{ has_value('sensor.energy_production_next_hour')
and has_value('input_number.solar_load_baseline_next_hour_kwh') }}
state: >-
{% set pv = states('sensor.energy_production_next_hour') | float(0) %}
{% set base = states('input_number.solar_load_baseline_next_hour_kwh') | float(0) %}
{{ [0, pv - base] | max | round(2) }}This is a forecast energy amount per next-hour interval, not a cumulative energy meterAliExpress price. Its state_class: measurement is intentional; it must not be added to the Energy dashboard as a total-increasing PV generation sensor. Because the time horizon rolls forward when the source integration updates, record the forecast-issue timestamp separately when backtesting. The template may hold an old source state through a service outage unless source freshness is monitored too.
YAML example 3: notification only when the predicted surplus seems worthwhile
This automation sends a notification after the next-hour surplus estimate crosses a chosen value. It neither starts an EV charger nor energises a water heater. The 2 kWh threshold is an example, not a safe minimum power or a guaranteed battery-free dispatch allowance. Before enabling notifications, confirm your Home Assistant installation has a working persistent_notification.create action.
automation:
- id: forecast_solar_surplus_notification
alias: Notify when next-hour solar surplus looks promising
mode: single
triggers:
- trigger: numeric_state
entity_id: sensor.solar_forecast_surplus_next_hour
above: 2
for: "00:05:00"
actions:
- action: persistent_notification.create
data:
title: Solar forecast review
message: >-
The next-hour solar forecast surplus is above 2 kWh.
Check live PV generation, household load, your tariffs,
and appliance constraints before starting a flexible load.The numeric-state trigger fires when the value crosses the threshold; it will not repeat every hour while the condition remains true. Do not use this example as a recurring scheduler without adding a separate trigger and an explicit stale-data test. If the sensor is unavailable, the automation should not run from a fabricated zero or last-known value.
YAML example 4: integrate measured surplus power only for retrospective analysis
For historical comparison, calculate a non-negative measured export or surplus power stream from existing local power sensors, then integrate over time. If a battery is present, this is not necessarily solar-only surplus; use the correct battery-aware measurement boundary. The example entities are in watts and describe a solar-only, no-battery system. For validating exported energy, the physical grid export kWh counter remains the authoritative value.
template:
- sensor:
- name: Solar measured surplus power
unique_id: solar_measured_surplus_power
unit_of_measurement: W
device_class: power
state_class: measurement
availability: >-
{{ has_value('sensor.pv_ac_power')
and has_value('sensor.household_load_power') }}
state: >-
{% set pv = states('sensor.pv_ac_power') | float(0) %}
{% set load = states('sensor.household_load_power') | float(0) %}
{{ [0, pv - load] | max | round(0) }}
sensor:
- platform: integration
source: sensor.solar_measured_surplus_power
name: Solar measured surplus energy estimate
unique_id: solar_measured_surplus_energy_estimate
unit_prefix: k
unit_time: h
method: left
round: 3
max_sub_interval:
minutes: 5The integrated surplus energy is an estimate derived from sampled power. If a power state remains stale during an outage, time integration may accumulate energy that was not actually measured. Set source freshness checks, tune the integration method to the sensor’s reporting behaviour, and compare the daily result with a proper grid export kWh counter before relying on it. This is not interchangeable with a revenue-grade meter or the utility bill.
When Recorder, long-term statistics and external storage matter
Home Assistant’s Recorder retains detailed history for a configurable period; the default detailed history is limited, whereas eligible long-term statistics are maintained much longer. To train a week-by-week hourly baseline for several months, verify that you have the right statistics or export strategy instead of assuming every raw state is still present. An hour-aggregated kWh dataset is usually sufficient for early planning, but resolving appliance spikes may require shorter raw sampling intervals.
Do not rewrite accumulated kWh sensor history to make charts look smoother. Distinguish actual meter totals, estimated energy inferred from sampled watts, and forecast outputs. Forecasts have their own horizon and issue time; they are not a replacement for measured cumulative values. A separate InfluxDB or file export can be justified when you need immutable forecast snapshots and detailed backtesting, but it adds maintenance, backup requirements and another data path to secure.
Preserve a daily audit extract containing PV generated kWh, grid imported kWh, grid exported kWh, controllable loads, forecast day-ahead issued-at details and the model version. Save both raw figures and the computed baselines so that a configuration change cannot silently rewrite your historical savings. If you later automate decisions with EMHASS, retain the inputs and decisions as well as the resulting actual energy use. That makes a fair comparison against simple native Home Assistant rules possible.
| Data storage | Suitable data | Strength | Weakness | Recommendation |
|---|---|---|---|---|
| Recorder raw history | Recent power and state changes | Simple and integrated | Default detailed retention limited | Fine for initial observations |
| Home Assistant long-term statistics | Eligible meter/hourly aggregates | Longer historical comparison | Not all raw state detail remains | Great for baseline energy totals |
| CSV/Parquet snapshot export | Issued forecasts and interval actuals | Reproducible, portable, auditable | Requires export process and backup | Best simple backtest archive |
| InfluxDB or time-series DB | High-frequency power, historic forecasts | Detailed querying and trends | Additional host/storage/admin | Only if resolution genuinely needed |
| Grafana | Dashboard queries over existing datasource | Flexible analyses | Does not store observations itself | Use after reliable data pipeline |
| Vendor portal | External inverter historical view | Useful independent cross-check | Cloud/API terms and timestamps vary | Do not make sole evidence store |
The economics: extra self-consumption is not always extra profit
Increasing solar self-consumption is a useful technical goal, but a financial decision must recognise both the price of imported electricity avoided and the export revenue sacrificed. Suppose you shift a 2.0 kWh load from the evening to a sunny afternoon, and all 2.0 kWh would otherwise have been exported. If the future evening import costs £0.27/kWh and export earns £0.12/kWh, the approximate bill benefit is 2.0 × (£0.27 − £0.12) = £0.30. This is an illustrative marginal calculation, assuming equal delivered appliance energy and no added standby or losses. It is not a typical tariff claim.
If instead the shifted load would have run in a £0.08/kWh overnight import window and export pays £0.12/kWh, consuming solar can actually worsen the financial result relative to exporting during the day and importing at night. This reversal is possible on some contracts, but you must verify the real import and export settlement terms, unit rates, taxes, fees and any conditions on eligibility or export. Daily forecast totals alone cannot identify it.
For EV charging, energy delivered at the wall differs from battery energy added because charging has conversion and vehicle overhead losses. Heat pumps differ from simple resistive heaters: producing 2 kWh of useful heat with COP 3 requires roughly 0.67 kWh of electrical input, not 2 kWh. A schedule that maximises midday kWh self-consumption may increase heat-pump temperature, lower efficiency or drive additional thermal losses. Optimise a stated household objective—cost, carbon, comfort, or backup reserve—not a marketing ratio.
For a battery, charging and discharging losses, cycle degradation and reserve policies matter. Merely increasing the annual self-consumption percentage by storing PV can have little monetary value if export payments are strong and the battery is expensive. Conversely, a household with low export compensation and high evening prices may benefit, subject to the verified hardware economics. Keep battery dispatch within inverter/BMS-supported commands, and avoid an unsupported Home Assistant script that bypasses protective controls.
| Illustrative event | Without shifting | With shifting | Marginal benefit | Why the answer could change |
|---|---|---|---|---|
| 2 kWh laundry moved from 27p evening to foregone 12p export | 2 × £0.27 import | 2 × £0.12 export opportunity cost | £0.30 saved | Uncertain PV, appliance cycles, different energy used |
| 2 kWh moved from 8p overnight to 12p export opportunity | 2 × £0.08 import | 2 × £0.12 export foregone | £0.08 worse | Contract details, standing charges not marginal |
| 2.5 kWh forecast solar surplus but only 1.3 actual | May export/import depending hour | 2.0 kWh device needs at least 0.7 kWh grid | Not a full solar-only load | Instantaneous power peaks could import more |
| Charging EV with vehicle overhead | Wall energy differs from EV battery gain | Shift physical charging session | Model wall kWh, not dash display only | Temperature and charging rate alter losses |
| Heat pump daytime preheat | Existing comfort and COP schedule | Advance heat delivery | Requires COP and building-loss comparison | High flow temperature can offset cheap electricity |
| Battery-assisted shift | PV could be exported | PV may be stored then discharged | Subtract wear and round-trip loss | Reserve and native inverter dispatch limits |
Forecasting solar self-consumption versus forecasting solar export
In a simple no-storage house where the PV inverter, grid meter and demand boundary are measured consistently, instantaneous export is approximately the positive part of PV minus onsite demand. Thus historical export can be a useful validation target for forecast surplus. But there is a crucial difference between what would have been exported and what the home actually exported after an automated EV charger or diverter consumed the spare PV.
Once you start a flexible load, actual grid export falls, sometimes nearly to zero. A simplistic machine-learning model trained on observed export alone might then conclude that the solar surplus forecast was overly optimistic. It could progressively stop scheduling the very appliance that made the forecast useful. This is feedback contamination. Instead reconstruct the counterfactual baseline by removing scheduled flexible loads from consumption, or record forecast before the control action and the action’s metered power separately.
For a battery installation, observed export is an even less reliable training target. The battery may absorb midday solar, discharge in the evening or export under a particular tariff. A zero export reading can coexist with genuine potential surplus. Model the unconstrained PV generation forecast, ordinary demand, battery charge/discharge policy and optional load dispatch as separate quantities. This separation also allows a fair comparison between battery-first, EV-first and bill-minimising strategies.
Worked household scenarios
Case A: UK solar-only house with a washing machine and dishwasher
A 4 kWp array in an illustrative mid-season day is forecast to generate 14 kWh, with baseline household demand of 8 kWh across 24 hours. The 6 kWh difference is not necessarily available as usable solar surplus: some of the 8 kWh occurs overnight, so simultaneous daytime demand might be only 3 kWh and the predicted export could be closer to 11 kWh before flexible loads. A correctly aligned hourly model identifies those daylight hours and their power margins.
After a month of clean meter data, the house finds that the 11:00–14:00 period commonly provides at least 1 kWh each hour, but cloudy-day variability is substantial. Instead of automatically energising a washing machine via a generic smart plug, the owner uses a supported delayed-start feature where the appliance manufacturer permits it or receives a notification to start manually. They log energy consumed and actual grid import during the cycle, and compare the bill with the old evening routine.
The outcome to measure is net household cost, not the number of notifications. If the household already uses a cheap overnight tariff, daytime self-consumption could be financially worse than exporting; record the export opportunity cost in the analysis. Four weeks of stable results do not establish annual savings, because both PV generation and household demand change with season.
Case B: Three-phase EV charger with variable charging limits
A household has a three-phase PV inverter, an EV charger and a native dynamic-load-balancing controller. Historical data show midday baseline demand of 1.2–1.6 kW, while the PV forecast fluctuates between 2 and 6 kW. A daily 10 kWh “surplus” estimate cannot safely specify a charging-current profile. The charger’s own phase mode, car minimum current, permitted start/stop frequency and installer-set supply limits determine whether solar-following is practical.
Home Assistant uses the forecast to decide whether to propose a midday charging session and to avoid starting an expensive overnight charge that is not needed before departure. The charger’s native solar tracking, protective load management and maximum current remain authoritative. If the forecast misses, the owner either accepts grid import under the contract or completes the required charge in the known, bounded fallback window before departure.
Measure planned versus actual wall kWh, percentage of the session supplied by coincident solar, extra cost, start/stop frequency and whether the departure energy target was reached. Exclude unusually short or interrupted sessions from simple savings averages but document them as reliability failures. A strategy that saves a few pence but repeatedly leaves a car insufficiently charged is not successful.
Case C: Battery-first home with solar export payments
A home battery stores midday PV and supplies evening consumption. The inverter app reports “self-consumption increased”, but that number can combine direct PV use with electricity routed through storage. When evaluating an alternative EV charging schedule, the model must ask: Would the marginal kWh otherwise charge the battery, be exported, or be curtailed? Those three counterfactual outcomes have different financial values.
If the battery would otherwise be charged for the evening peak, diverting solar to an EV now may force expensive grid import later. If the battery is already full and export rates are low, the same EV charging opportunity may be valuable. If the system has a backup reserve requirement, that reserve is an explicit constraint, not energy assumed available for optimisation.
Start with the battery controller’s documented load priorities and daily energy logs. In Home Assistant, create a dashboard showing forecast PV, demand, state of charge, battery charge/discharge and grid export. Test the interpretation with real inverter registers before sending any supervisory setpoints. The BMS, inverter current limits and anti-islanding protection remain independent of the forecast system.
Case D: Heat pump and hot-water cylinder
Consider a heat-pump home where midday PV production is relatively high but heating demand is temperature dependent. A crude load model sees high winter household electricity as normal and forecasts almost no midday surplus. In reality, some heat delivery may be moved within an allowed comfort range, but this changes thermal storage and compressor efficiency. The model needs heat-pump input energy, outdoor temperature, flow-temperature targets and the thermal response of the building before claiming savings.
For a hot-water cylinder, scheduling a heat cycle near expected PV generation can reduce grid import, but only within manufacturer-approved controls and local hot-water hygiene practice. A system may need a programmed disinfection regime, an independent over-temperature cut-out and periodic backup heating. An internet forecast that says “no solar tomorrow” must never disable required hot-water safety functions.
Evaluate the amount of delivered hot water or useful heating service, electrical energy input and any additional standing losses. A forecast-adjusted schedule can be worthwhile if it reduces net energy cost without pushing heat-pump COP down or leaving occupants without hot water. Do not infer useful thermal energy merely from an immersion relay’s ON time.
| Household | Primary measurements | Prediction to validate | Main system safeguard | Financial comparator |
|---|---|---|---|---|
| Solar-only and laundry | PV, import, export, appliance wall kWh | Hour of positive PV surplus | Manufacturer-supported appliance operation | Import avoided minus export foregone |
| EV and solar | PV, grid, charger wall kWh, charging current | Usable time with EV min current | Certified EVSE/load manager | Cost and departure energy vs native timer |
| Hybrid PV/battery | PV AC/DC boundary, battery flows, SOC, export | Marginal PV after storage policy | BMS and inverter-native reserve | Battery wear/loss and foregone export |
| Heat pump and cylinder | PV, heat-pump electrical input, delivered heat, tank temp | PV and heating availability | Compressor/hygiene/temperature controls | Energy cost and equal comfort/service |
| Pool pump or other flexible load | PV, meter kWh, approved run time | Longest uninterrupted workable slot | Pump controller and service requirement | Solar cost benefit without shortening duty |
Buying guide: what to purchase, and what to avoid
For a house that already has PV and a local inverter integration, the first purchase may be nothing. Use the existing data for a month and check whether your metering is consistent. If grid export measurement is missing, a compatible certified meter or CT monitoring system installed by a competent electrician often provides more value than an additional cloud forecasting subscription. If the inverter is cloud-only, consider a manufacturer-supported local gateway before buying third-party middleware.
A reliable Home Assistant host matters because missing samples undermine training. For continuous logging, a modern Home Assistant Green, a suitable mini PC or supported NAS deployment can be reasonable. Choose based on the rest of the automation system, available local backups and storage endurance, not on an unsupported promise that a faster CPU makes the weather forecast more accurate. Ethernet is useful for fixed infrastructure where possible, but a good WLAN can be sufficient for many non-critical sensors.
Before subscribing to a premium forecast provider, measure the forecast errors that actually affect scheduling. A second forecast can help if it materially reduces your false solar-window rate; it is difficult to justify on a bill-savings basis if a simple tariff timer already performs nearly as well. For dedicated EV charging, a compatible solar-diverting wallbox and approved load-management meter may be the correct hardware purchase, even if it costs more than an ESP32 project. Forecast software cannot substitute for rated protective hardware.
| Potential purchase | Use case | Must verify | Avoid buying when |
|---|---|---|---|
| Grid import/export meter | No trustworthy boundary measurements | Phase coverage, installation, local data access | Existing utility/inverter meter already fits the model |
| Local PV inverter gateway | Cloud portal lacks hourly local production | Exact inverter/firmware and supported protocol | Supported native integration already works |
| Home Assistant host/SSD | Existing host unreliable or database too short-lived | Backups, endurance, power and network | Current host already preserves reliable stats |
| Premium PV forecast subscription | More planes/resolution/refresh speed needed | Account tier, API policy, forecast backtest | Free forecast suffices for current decisions |
| EV wallbox solar mode | Need closed-loop PV following and certified supply limits | Car current minimum, phase support, native fail-safe | Goal is only next-day charge planning |
| Approved immersion controller | Existing cylinder can safely accept timed PV heating | Independent thermostat/hygiene protection | Arbitrary smart plug is the only proposed control |
| InfluxDB or similar storage | Need reproducible granular historical series | Storage cost, upkeep and export quality | Recorder and hourly CSV history already suffice |
Five-year cost and savings: do not confuse a model with a business case
The operational payback comes from additional optimised consumption compared with what the household would otherwise have done, not from the value of all the solar energy the panels produce. Compare a forecast-driven strategy against the simplest reasonable alternative, such as the supplier’s fixed off-peak schedule, a charger’s native solar mode, or manual daytime appliance use. Evaluate energy prices at the time of each action and count export revenue foregone.
Suppose a forecast-based notification leads to 300 additional annual kWh being used on site instead of exported, with a net £0.10/kWh advantage after the relevant marginal import/export rates. That is about £30/year; over five years it is £150 before equipment, maintenance, electricity for servers, and any subscription cost. If the system cost another £200 beyond equipment already owned, simple undiscounted payback would not occur within five years. Change the shifted kWh and actual margin to fit your home; these numbers are only worked assumptions.
A forecast with better numerical error can still deliver less money if it predicts the wrong hours or requires expensive installation. A free model can be economically optimal if the marginal benefit of a better service is very small. Conversely, a reliable forecast that improves a high-energy flexible load’s schedule may earn its cost rapidly when tariffs are favourable. Measure incremental performance over a sufficiently long period; do not multiply one lucky sunny week by 52 and call it an annual estimate.
| Illustrative sensitivity | Extra shifted solar kWh/year | Net margin per shifted kWh | Annual gross value | Five-year gross value |
|---|---|---|---|---|
| Modest opportunity | 150 | £0.06 | £9 | £45 |
| Small steady load | 300 | £0.10 | £30 | £150 |
| Frequent flexible load | 600 | £0.12 | £72 | £360 |
| High opportunity | 1,000 | £0.14 | £140 | £700 |
| Strong export tariff, cheap import | 400 | −£0.04 | −£16 | −£80 |
Commissioning plan: a four-week shadow-mode trial
Begin in shadow mode: calculate predictions and proposed schedules, but let the appliances follow their current arrangements. Each day, compare predicted versus actual PV, inferred baseline, grid import and export. Save the day-ahead forecast as issued, not a later refreshed version. Use the first week to diagnose obvious meter errors and the second to judge basic load-profile accuracy; use subsequent weeks to gather enough events for a fair comparison across weather conditions.
After at least several weeks of satisfactory data, try one low-risk flexible load with a human-readable proposed window. Keep a simple no-forecast baseline: for example, a fixed overnight EV schedule or normal user-controlled appliance start. Measure whether the forecast schedule genuinely reduces the bill, taking export value and any losses into account. Do not enable multiple optimisations simultaneously; otherwise it becomes difficult to attribute a change in cost to its actual cause.
A failed day is diagnostic evidence, not a reason to silently delete the observation. Record why it failed: unexpected cloud, unexpected cooker/heat-pump demand, tariff change, stale data, appliance refusing remote start, internet outage or user override. Update the model only after identifying the failure mechanism and confirm that a new model improves future performance on data it has not seen.
- Week 1: verify physical meter boundaries, units, counter monotonicity and hourly alignment; compare one full day against inverter and utility readings.
- Week 2: calculate weekday/weekend median baseline, preserve genuine appliance loads and flag unexpected missing intervals.
- Week 3: collect immutable day-ahead PV forecast snapshots and measure hourly PV, load and surplus errors on untouched dates.
- Week 4: propose one flexible-load window per eligible day, compare against manual/fixed schedule and log all rejected or false-positive windows.
- After validation: if adding supported automation, retain manufacturer-native electrical/hygiene protection, conservative margins, timeouts and manual override.
- On every change: rerun verification when adding a battery, changing tariffs, replacing a meter, upgrading firmware or substantially changing occupancy.
Fault diagnosis: when forecast savings appear unrealistically good
| Symptom | Likely explanation | Verification | Corrective approach |
|---|---|---|---|
| Forecast says surplus all afternoon; meter imports | Predicted PV too high or demand omitted | Compare live PV and import against same interval | Reduce forecast bias and measure missing loads |
| PV total good; charging still imports | Intra-hour variability and EV minimum current | Log 1–5 minute power and current | Use native charger solar mode and threshold margin |
| Self-consumption ratio over 100% | Meter boundaries mixed or units wrong | Check AC/DC and cumulative totals | Rebuild energy-flow accounting; do not clamp error invisibly |
| Sudden 1,000 kWh spike in hourly data | Counter reset/rollover or wrong unit | Inspect raw cumulative readings | Flag interval, adjust conversion before forecasting |
| Surplus unexpectedly zero after solar diversion | Training on actual grid export after load ran | Subtract metered controllable loads from base | Train counterfactual baseline, not post-control export |
| Forecast seems perfect in a report | Look-ahead leakage or later-issued forecasts used | Inspect forecast issuance timestamps | Score immutable snapshots available at decision time |
| Summer model performs badly in December | Heating/season regime changed | Group errors by temperature and season | Weather-correct baseline; retrain carefully |
| Cheap solar schedule increases bill | Export payment exceeds import cost in other window | Price each interval with actual retail rates | Optimise net bill rather than self-consumption |
| Forecast sensor shows 0 through outage | Jinja float(0) masking missing state | Test unknown/unavailable transitions | Use availability and freshness checks |
| Electricity price/solar slots shifted one hour | Timezone or DST handling mismatch | Compare UTC interval keys and tariff timestamps | Resample energy with explicit interval start/end |
| Underprediction persists on sunny days | Inverter clipping/array orientation or forecast model bias | Inspect noon power plateau and panel geometry | Set correct plane tilt, azimuth, inverter size |
| History disappears after two weeks | Recorder purge/detailed storage policy | Inspect Recorder settings and statistics | Archive hourly measured and issued forecast series |
Frequently asked questions
Can Home Assistant predict tomorrow’s unused solar energy?
Yes, approximately, by combining a PV generation forecast with a household baseline-load prediction for matching future intervals. The result is probabilistic headroom, not a guarantee, and should be evaluated against metered history.
Is the Forecast.Solar tomorrow total the same as available solar surplus?
No. It is estimated total PV generation, some of which the household may already use. You must subtract expected coincident baseline consumption and respect the timing of energy generation.
How do I estimate household demand if I have PV generation and grid import/export sensors?
For a consistent solar-only, no-battery AC measurement boundary: load = PV generation + grid import − grid export within each interval. Battery and hybrid topologies require additional terms or documented native load telemetry.
What if I also have a home battery?
Model battery charge/discharge and loss boundaries separately. A zero export interval may contain energy stored for later, not zero potential solar surplus. Do not assume exports always originate from PV.
How much load history should I collect?
Two to four clean weeks are a reasonable pilot for basic hourly weekday/weekend baselines. More history and seasonally varied conditions are necessary for stronger claims. Regular validation is more important than an arbitrary training duration.
Should I use mean or median household demand?
An hourly median provides a robust first baseline when history includes a few one-off appliance spikes. Use quantiles for more cautious planning and compare against a simple fixed benchmark on future dates.
Can I use historical grid export as the forecast target?
Only carefully. In solar-only systems it can validate actual unused energy, but once an EV, diverter or battery responds to solar, export no longer represents the counterfactual surplus before that action.
What is the difference between kW and kWh in these calculations?
kW measures instantaneous power; kWh measures energy accumulated over an interval. A forecast of 2 kWh across an hour does not guarantee 2 kW is continuously available, particularly during cloudy conditions.
What does a 90% forecast confidence range mean?
Only a band that has been calibrated and tested out of sample supports a coverage statement. Two arbitrarily added error margins are cautious scenarios, not automatically a formal 90% confidence interval.
Will an EV charge using 0.8 kW of solar excess?
Normal AC charging often requires at least roughly 6 A on one phase, about 1.38 kW at 230 V, and vehicle/charger-specific limits apply. A 0.8 kW surplus cannot support that ordinary minimum on its own.
Is a paid solar forecast worth the price?
Only when its measured improvement leads to enough additional bill savings or operational reliability to justify the fee. Compare forecast-induced net benefit against the free service and a simple timing baseline.
Should I schedule a dishwasher with a smart plug?
Do not assume so. Many appliances cannot safely or reliably resume after power interruption or accept remote start. Use supported manufacturer controls or a manual start recommendation, and consider the appliance’s short power peaks.
Can solar forecasting safely manage a hot-water cylinder?
It can propose a preferred heating window, but independent thermostat, overheating protection and required hygiene schedules must remain under manufacturer-approved control. Do not use a generic plug as the sole electrical or temperature protection.
Does maximising solar self-consumption always save money?
No. Export compensation, cheaper off-peak imports, battery losses, heat-pump COP and equipment costs can reverse the benefit. Compare marginal import avoided with export revenue foregone and other losses.
Why should I preserve the forecast issuance timestamp?
To avoid look-ahead bias. A “tomorrow” prediction refreshed on the day is not the same as information available when an evening schedule was chosen. Validate against what the controller actually knew.
Is hourly resolution accurate enough?
It is enough for a first day-ahead window estimate and financial comparison. It is not sufficient to control instantaneous export power, handle brief appliance spikes or replace the certified EV charger load manager.
What happens when the forecast service or internet fails?
A well-designed installation keeps physical monitoring local and marks missing forecast data unavailable. Use a preapproved fallback schedule, native device controls and explicit timeouts rather than stale prices or old PV forecasts.
Does EMHASS replace a baseline forecast?
No. EMHASS can optimise load and storage schedules using forecast inputs, but inaccurate PV and baseline-load data still lead to poor schedules. Compare its outcome against a validated, simpler Home Assistant rule set.
Official documentation and further reading
- Home Assistant: Forecast.Solar integration
- Home Assistant: Home Energy Management
- Home Assistant: Integrating individual device energy usage
- Home Assistant: Integral (Riemann sum) integration
- Home Assistant: Template sensor integration
- Home Assistant: Statistics integration
- Home Assistant: History and Recorder retention
- EMHASS: Official project and forecasting overview
- EMHASS: Forecast model documentation
- ESP32.co.uk: Solar forecasting integration comparison
- ESP32.co.uk: Solar import/export metering
- ESP32.co.uk: Solar surplus control for hot water
- ESP32.co.uk: Dynamic EV charging on electricity tariffs
Final recommendation: prove the forecast improves decisions before automating
A useful solar self-consumption forecast needs just two reliable things: a production estimate for each future interval and a realistic baseline demand estimate for the same interval. Start with measured, consistent electrical boundaries, a weekday/weekend hourly median and an official PV forecast. Score immutable day-ahead snapshots against physical energy data and report errors for the surplus windows that matter, not just a pretty daily PV total.
The next stage is conservative and reversible: a notification suggesting when to run a supported appliance, or a proposed EV charging window subject to its own manufacturer-approved load controls and departure deadline. Compare cost against your normal routine, including solar export income forgone. Keep independent safety, comfort and hygiene systems outside Home Assistant’s experimental prediction loop.
Only after this simple model wins a fair chronological backtest should you add finer time intervals, outside temperature, probability bands, battery models or EMHASS optimisation. The objective is not to maximise the sophistication of your dashboard. It is to turn uncertain forecasts into measurable, auditable and worthwhile decisions without compromising a reliable household energy system.