The Forecast Wasn't Lying — I Was Throttling The Inverter

• 17.2 kWp17.2 kWpeffective capacity of the 19.38 kWp array
• ~63 kWha day of solar thrown away on the sunniest days
• 33 → 68 %battery charged by hand from the grid on a cloudy day, about 18 kWh

Everything here comes from one system: a 19.38 kW Jinko array, a 48.36 kWh Sigenstor battery, suburban Melbourne, Amber’s pass-through pricing. Personal experience, not advice.

---

I had a story ready for this post. Forecast.Solar is fine on clear days and catastrophic on cloudy ones, overpredicting daily generation by 117 to 414 per cent on the worst days. I had the numbers. I had the framing. I was going to use it to sell the need for on-site irradiance calibration as the next engineering move.

Then I did the analysis properly and the story fell over.

The hidden variable

I had compared the day-ahead forecast with measured inverter output. Between the panels and the meter sits a battery that fills by late morning on most sunny days, and an inverter that throttles itself when there’s nowhere for the electrons to go. “Measured PV” is not “available PV”. On a clear summer day my system is throttling for hours, and that shows up in the data as missing generation. Compare forecast to measured without backing out the throttling and you are blaming the weather service for the controller turning the tap off.

The honest comparison is forecast against potential: what the arrays could have produced under the irradiance actually measured on the roof. That needs a transfer function from irradiance to PV output, fitted on intervals where the system definitely wasn’t clipping.

Building the transfer function

The on-site weather station logs irradiance every minute. I took the daylight intervals where the battery had headroom and grid export was nowhere near the 15 kW limit, and fitted output against irradiance.

That left about 860 clean half-hours across 50 days. The fit says the array behaves like 17.2 kWp against the 19.38 kWp nameplate, about 89 per cent. That is the combined hit from tilt, inverter losses, cabling and soiling, and about right for a healthy recent install. The fit isn’t perfect, but it is tight enough to make honest comparisons with.

I applied it to every daylight interval, rolled up by day, and sorted the days into clear, mixed and cloudy by how much sun the roof sensor measured.

What the data says

Forecast error by sky condition, over 50 days. The kWh columns are daily averages; the percentages average each day’s own error, so they are not the ratio of the averages:

Sky	Days	Measured (kWh/day)	Potential (kWh/day)	Forecast (kWh/day)	Average daily error vs measured	Average daily error vs potential
Clear	28	54	117	134	+214%	+14%
Mixed	19	50	78	82	+88%	+8%
Cloudy	3	46	52	70	+55%	+39%

Against measured output, Forecast.Solar looks like a catastrophe. Against potential, it is within 15 per cent on the days the sun is out. That is a working weather service telling me the truth about a roof having most of its output thrown away.

The gap between potential and actual on clear days is the headline: about 63 kWh a day on the sunniest days. A second household’s daily consumption, turned away at the inverter because the battery was full.

That is not the negative-price curtailment where the automation deliberately chokes export. It is the larger, more boring kind: battery full, grid not wanting any more. The arrays are oversized for the load, and in midsummer there are hours with nothing to do with the energy. The inverter throttles, which is correct. But my original comparison was “what the weather allowed” against “what the controller permitted”, and I was calling the difference forecast error.

The cloudy days

Cloudy days are the one place the forecast still overpredicts: +39 per cent. A weather model’s cloud field is averaged over a grid square kilometres across, and real cloud over one suburban roof can be thicker or thinner than the model expects.

Three days is not a sample. It is a direction. The real number needs a bigger window, ideally with winter in it.

The day I stopped trusting the forecast

On a cloudy day in February, with solar trickling at one to two kilowatts and the battery down to 33 per cent, I opened the inverter app, hit the manual grid-charge override and pushed about 18 kWh into the battery over 90 minutes. State of charge went from 33 to 68 per cent. Then I walked away.

I didn’t plan it as an experiment. I looked at the sky, the forecast and the battery, and didn’t fancy the evening’s chances. Peak rates step up sharply at three in the afternoon; midday off-peak was about a third of that. The controller had no rule for the situation, so my thumb did it.

On the cloudy day where the forecast mattered most, I stopped relying on it and paid for certainty instead.

That is the shape of a winter automation I haven’t built yet: if tomorrow’s solar looks thin, the evening peak is expensive and the battery isn’t well placed, pre-buy at off-peak and stop trying to be clever. That is not a forecasting problem. It is a decision rule with the forecast as one input, and the forecast only has to say “don’t count on the sun”. The cost of being wrong is lopsided. Pre-charge and the sun shows up, and I’ve paid a small penalty. Don’t, and the sun stays away, and I import at peak all evening.

So the next automation isn’t a tighter day-ahead number. It is encoding the rule I ran on that day and letting the controller do at midday what I did with my thumb. I have one clean instance in the data, on a day I remember making the decision. That’s enough to know the rule is real.

Damping, and why I’m leaving it alone

I had a section drafted on the Forecast.Solar damping setting, a per-plane correction for nearby trees and buildings that I’ve never tuned. I planned to argue that damping can’t fix cloud-cover error and that I should build an irradiance cross-calibration layer instead.

The logic was right and the motivation wrong. I wanted the calibration because I thought the forecast was broken on cloudy days. It isn’t. The real reason is smaller: a forecast in units of what my roof will produce under today’s sky, so the controller can reason about headroom without overreacting. A refinement, not a rescue. Damping still isn’t the lever.

What this means for automation

Clear days: trust the forecast, watch for throttling. The worry is not whether solar shows up but whether the battery is full by 11 am with five hours of sun to waste. That is a storage-sizing question dressed up as a forecasting one.

Mixed days: trust it within ten per cent. Tight enough for every morning charge decision.

Cloudy days: discount it by 30 to 40 per cent. Indicative only, until there is winter data. Don’t gamble morning off-peak charging on a forecast that says solar will rescue the afternoon.

The other dead end

I once looked for a correlation between battery state of charge at 7 am and that day’s solar. It told a tidy story and had no mechanism. The 7 am charge reflects last night’s load, not today’s weather. Out it went.

The rule I’m teaching myself: don’t tune what you can’t fix, and don’t predict from what can’t predict. Damping doesn’t fix cloud cover. The 7 am charge doesn’t predict weather.

Takeaway

I nearly lied to myself by comparing the wrong two numbers. Forecast against measured generation tests the controller. Forecast against potential generation tests the forecast.

Before you blame your solar forecast, check whether your inverter was clipping or your battery was full when the missing generation was due. If so, the forecast was probably right.

Next post: the automation stack, and the Sunday morning the controller did exactly what it was told and lost me fifty cents.

---

Sources: Forecast.Solar Pro; Home Assistant inverter and weather station logs, December 2025 to April 2026.