Logboek: mijn zonprognose zat 26 % te laag. Nu corrigeer ik hem per maand

Logboek, 10 oktober 2026. De zonprognose waarop EMHASS mijn thuisbatterij plant, zat structureel te laag. In dit logboek: hoe ik dat mat, wat een externe bron erover zei, waarom je een zonprognose niet met één factor kunt corrigeren, en hoe de correctie nu per maand in de planning zit.

Waarom dit ertoe doet

EMHASS plant elk kwartier wat de thuisbatterij gaat doen: laden uit de zon, bijladen uit het net in goedkope uren, of ontladen op de avondpiek. Daarvoor moet hij weten hoeveel zon er de komende uren komt.

• Een prognose die te laag zit, is duur. EMHASS laadt onnodig bij uit het net, en het overschot dat er wél komt, gaat tegen de terugleverwaarde het net op.
• Een prognose die te hoog zit, is erger. Dan loopt de batterij ’s avonds leeg in de verwachting dat de zon hem morgen vult, en komt die zon niet.

Wat ik heb gebruikt

• Open-Meteo Solar Forecast in Home Assistant, met de gegevens van het dak: 18 panelen van 295 Wp (5,31 kWp), azimut 205°, helling 30°, en micro-omvormers die samen maximaal 4,32 kW AC leveren. Deze prognose gaat als lijst van kwartierwaarden naar EMHASS.
• Een eigen meetlus die per dag de werkelijke opbrengst, gemeten door de omvormer, deelt door de voorspelde, en na zeven dagen een mediaan geeft. Hoe die werkt, staat op Meten en kalibreren.
• Een externe referentie: de stroomanalyse van jeroen.nl. Die berekent uit twaalf maanden eigen opwek per maand hoe ver de standaardprognose ernaast zit. Gratis, op basis van je eigen data.

Waarom ik twee bronnen naast elkaar leg

Eén meting is een getal. Twee metingen die iets anders meten, vertellen je ook waarom dat getal is wat het is. Mijn meetlus is precies, maar kort: zeven dagen, uit één week weer. De analyse van jeroen.nl is grover, maar lang: twaalf maanden, met elk seizoen en elke grijze dag erin. Komen ze uit op hetzelfde, dan heb ik vertrouwen. Wijken ze af, dan is dat verschil zelf de informatie.

Wat de metingen zeiden

Bron	Periode	Werkelijk t.o.v. voorspeld
Eigen meetlus	7 dagen, 3–9 oktober	+26 % (mediaan)
jeroen.nl	oktober, uit 12 maanden	+14 %
jeroen.nl	maart–juni, augustus–september	+22 tot +28 %
jeroen.nl	januari–februari	+3 tot +5 %
jeroen.nl	december	−10 %

De twee bronnen spreken elkaar niet tegen; ze meten iets anders. Mijn zeven dagen waren overwegend helder, en op heldere dagen onderschat het weermodel de instraling het meest. De analyse van jeroen.nl kijkt naar hele maanden, met grijze dagen erbij. Voor een correctie die een maand moet gelden, is die tweede waarde de betere.

Waarom één factor niet werkt

Mijn eerste ingeving was een gemiddelde: over twaalf maanden komt dat uit op +16 %, energiegewogen zelfs +22 %. Maar het patroon is sterk seizoensgebonden. Met één factor van +16 % zou de prognose in december bijna 30 % te hoog zitten, en in april ruim 10 % te laag.

En juist in de winter is dat de verkeerde kant op. Een te hoge prognose laat de batterij ’s avonds onnodig leeglopen, precies in de maanden waarin de zon hem de volgende dag het minst kan bijvullen.

Wat ik heb aangepast

Een correctietabel per maand, niet in de weersintegratie maar in de payload die Home Assistant naar EMHASS stuurt. Elk kwartier wordt de prognose vermenigvuldigd met de factor van de lopende maand:

Maand	Factor	Maand	Factor
januari	1,05	juli	1,19
februari	1,03	augustus	1,22
maart	1,22	september	1,27
april	1,28	oktober	1,14
mei	1,27	november	1,08
juni	1,26	december	0,90

• Een plafond van 4,32 kW blijft gelden, ook na de correctie. De micro-omvormers kunnen niet meer, dus een prognose daarboven is per definitie fout.
• Een fijnregelknop (standaard 1,00) bovenop de tabel, voor als de meetlus over een paar weken toch een structurele afwijking laat zien.
• De weersintegratie blijft op de echte dakgegevens: 5,31 kWp en de standaardfactor 0,92. De correctie zit op één plek, en de meetlus blijft de ongecorrigeerde prognose toetsen. Die hoort in oktober dus rond +14 % te blijven melden. Dat is nu geen advies meer, maar een controle of de tabel klopt.

De kern van de correctie, zoals hij in de payload staat:

pv_maand = {1: 1.05, 2: 1.03, 3: 1.22, 4: 1.28, 5: 1.27, 6: 1.26,
            7: 1.19, 8: 1.22, 9: 1.27, 10: 1.14, 11: 1.08, 12: 0.90}
factor    = pv_maand[maand] * extra_correctie
prognose  = min(open_meteo_kwartierwaarde * factor, 4320)

De 4320 is het plafond in watt. Hoe de payload verder in elkaar zit, staat in EMHASS en de batterij.

In evcc bleek de azimut verkeerd. evcc, dat de auto plant, gebruikt dezelfde Open-Meteo-prognose. Daar rekent Open-Meteo met 0 = zuid, niet met een kompasrichting. 205° op het kompas is daar dus 25.

Wat ik nog uitzoek

• De dakhelling. In mijn configuratie staat 30°, in de analyse van jeroen.nl 45°. Mogelijk is dat een standaardwaarde: jeroen.nl rekent ook in zijn eigen onderzoek naar opwek per plaats met 45°. In de winter is dat verschil niet onschuldig: een steiler dak vangt meer laagstaande zon, en een deel van het seizoenspatroon zou daarbij passen. Ik meet de helling na voordat ik iets verander.
• De tabel na een jaar opnieuw berekenen uit eigen data, zodra de meetlus twaalf maanden heeft. Dan hoeft de externe referentie er niet meer tussen.

De les

Meet eerst, corrigeer daarna, en corrigeer niet meer dan je metingen rechtvaardigen. Zeven heldere dagen zijn geen maand, en een jaargemiddelde is geen seizoen. Als twee bronnen verschillen, is de vraag niet wie gelijk heeft, maar wat ze precies meten.

Waarom een horizon van 36 uur de batterij ’s avonds niet meer leeg laat lopen, lees je in De horizon van EMHASS.

Alle logboeken op een rij: Logboek. Alle incidenten en lessen: Lessen uit de praktijk.

---

Dit werkt in mijn situatie: één dak in zuidwestelijke richting, één week eigen meetdata en de analyse van jeroen.nl over twaalf maanden. Correctiefactoren gelden voor één installatie. Controleer het tegen je eigen documentatie en je eigen metingen. Stand: oktober 2026.