EMHASS plant standaard 24 uur vooruit. Dat klinkt genoeg, maar het leverde bij mij elke avond hetzelfde vreemde plan op: de batterij exporteren aan het einde van de horizon. Zo ben ik bij 36 uur uitgekomen.
Het horizoneffect
Voor de solver is energie die aan het einde van de horizon nog in de batterij zit, boven het doel-SoC, niets waard. Als het dan toevallig iets oplevert om terug te leveren, plant hij die export. Bij een horizon die om middernacht ophoudt, ziet hij de ochtendpiek van morgen niet, en de avondpiek van morgen al helemaal niet.
Hoe dat in de praktijk uitpakt: op 3 oktober plande EMHASS aan het eind van zijn horizon 6 kWh te verkopen voor 27 cent per kWh. De avond erna had ik diezelfde stroom voor 42 cent terug moeten kopen. Ik zag het op tijd, maar het liet zien dat een horizon die om middernacht ophoudt, structureel verkeerde keuzes maakt.
Een export die 18 uur of meer vooruit gepland staat, wordt meestal niet uitgevoerd: latere runs kennen meer prijzen en houden de energie vast. Maar het plan is minder goed dan het kan zijn. Een langere horizon laat EMHASS overdag de avondpiek van morgen zien, zodat hij bijvoorbeeld ’s middags goedkoop kan netladen (bij mij rond 0,19 €/kWh) voor een avond rond 0,40 €/kWh.
Prijzen voor uren die nog niet bekend zijn
Tibber publiceert de kwartierprijzen van morgen rond 13:00. Daarna ken je zo’n 140 kwartieren; daarvoor maar de rest van vandaag. Voor de kwartieren daarna herhaalt de payload de laatst bekende dag, per kwartier van de dag. Dat is een aanname, maar een redelijke: het patroon van dal en piek is van dag tot dag vergelijkbaar.
De zonprognose komt van Open-Meteo, met twee dagen vooruit. Het tapwater blijft binnen de eerste 24 uur gepland, zodat het blok niet naar morgen kan schuiven.
Voorwaarde: een lastprognose die meeschuift
De ingebouwde naive-prognose van EMHASS verschuift bij een langere horizon. Daarom bouwde ik eerst een eigen prognose: de naive-lastprognose verschuift bij een langere horizon. Zolang die buffer niet vol is, blijft de horizon 96.
Waarom 48 uur niet lukte
Een instelbare bovengrens maakte 96 tot 192 kwartieren mogelijk. De eerste tests met 192 stappen (48 uur) gingen goed, op verschillende momenten van de dag. Een dag later liep de solver bij 192 stappen tegen zijn timeout van 180 seconden aan.
De rekentijd groeit sterk met de horizon, en hangt ook af van hoe ingewikkeld het plan die dag is. Ik draai nu op 144 stappen (36 uur). Dat dekt de avond van morgen, en de rekentijd blijft ruim binnen de grens.
Mijn advies
- Begin met 96 stappen.
- Maak eerst je lastprognose onafhankelijk van de horizon.
- Verhoog stapsgewijs en volg de rekentijd in het log. Die is de maatstaf, niet wat technisch kan.
- Bouw een schakelaar om terug te vallen op 96, voor als de solver vastloopt.
De hele opzet: EMHASS en de batterij. Alle incidenten: Lessen uit de praktijk.
Deze waarden gelden voor één installatie. Controleer ze tegen je eigen documentatie; werk aan 230/400 V laat je over aan een erkend installateur.
Geef een reactie