Python Tool voor simulatie thuisbatterij, en resultaten!

[kiang]

Hallo iedereen,

Ik wilde even wat kennis.ervaring delen, zodat zij die het nuttig vinden hier ook gebruik van kunnen maken. Maar ook hoor ik graag feedback, zodat ik mijn tool eventueel kan verbeteren als er fouten in zitten.

Ik was al een tijde naar Thuisbatterijen aan het kijken, maar sinds het nieuws dat GreenChoice je per kWh slechts 0,25 cent en 1 dikke middelvinger zal geven, heb ik nu eindelijk werk gemaakt van het zo goed mogelijk inschatten wat een thuisbatterij voor mijns huishouden kan betekenen. Ik wil namelijk best bijdragen aan duurzaamheid, ik moet er geen dikke winst op maken, maar het moet ook gene bodemloze put zijn waar ik duizenden euro's aan kwijt ben.

Daarom heb ik een python-tooltje gemaakt dat gegeven je verbruik over een bepaalde periode kan inschatten hoeveel stroom je verbruikt en teruglevert. Momenteel vereist het tooltje dat je data aanlevert in het obscure .mbc formaat van het inmiddels gestopte bedrijf BeeClear. Waarom? Omdat dat het dingetje is waarmee ik al jaren mijn P1 poort uitlees Ik wil gerust support inbouwen voor andere formaten indien er veel interesse is.

Het tooltje heeft enkele aannames:

• De laad/ontlaad strategie is altijd 0-op-de-meter. de batterij zal dus greedy opladen/ontladen: als je stroom teruglevert probeert de batterij al die stroom op te slaan, als je stroom gebruikt zal de batterij die hoeveelheid stroom proberen te leveren. (Handelen in stroom interesseert me totaal niet, dus andere strategieën wil ik niet proberen te implementeren)
• Ik neem aan dat de batterij dit perfect kan, aka onmiddellijk en exact reageert.
• de tool houdt geen rekening met verschillende tarieven, een kWh is een kWh. dit omdat mijn huidige vaste contract slechts 0,5cent verschil heeft tussen dal- en en piekuren.
• de tool weet niets over 3 fasen, ik heb zelf een 1 fase aansluiting dus voor mij was dit voldoende

Dit zijn aannames die ongetwijfeld de simulatie wat optimistischer maken dan de realiteit, maar alsnog hoop ik dat de impact ervan meevalt.
Verder heb ik wel geprobeerd de tool zo goed mogelijk een batterij te laten modelleren, gebaseerd op de lekenkennis van thuisbatterijen die ik nu heb. Dat wil zeggen dat de tool rekening houdt met:

• De capaciteit van de batterij (duh)
• De maximale laadsnelheid van de batterij
• De maximale ontlaadsnelheid van de batterij
• De round trip efficiency van de batterij (als percentage). Hiervan weet ik niet heel veel: mijn huidige aanname is dat een RTE van 80% betekent dat 1 kWh die in de batterij gaat betekent dat er 800Wh uit kan gehaald worden. En dan neem ik ook aan dat een batterij van 1kWh met een RTE van 80% volledig opgeladen kan worden met (1 / 0,8) 1,25 kWh, om dan 1 kWh te kunnen leveren. Als dit niet klopt hoor ik dat graag en pas ik het aan!

Mis ik nog wat?

Wie het tooltje wil bekijken en/of gebruiken, deze staat hier op GitHub: https://github.com/btimbermont/BatterySimulator

Resultaten

Nu goed, wat is u het resultaat? Ik dacht altijd dat ik best een 10 kWh batterij zou kunnen gebruiken, maar wat blijkt? 5 kWh is ruim voldoende voor mijn 12 zonnepanelen en jaarverbruik. Ik heb simulaties gedraaid met 1,2,3 en 4 HomeWizard batterijen, en hieronder is het resultaat op verbruik en teruglevering:

Scenario	Cosumptie	Teruglevering	Eigen consumptie
geen batterij	4209,9 kWh	2274,07 kWh	40%
homewizard x1	3546,21 kWh	1444,46 kWh	62%
homewizard x2 (op eigen groep)	3217,32 kWh	1033,34 kWh	73%
homewizard x3 (op eigen groep)	3098,61 kWh	884,96 kWh	77%

Zoals je kan zien kan 1 HomeWizard het eigen verbruik van 40% naar 62% verhogen, best een verschil. Een tweede batterij kan dat verhogen naar 73%, dus die is slechts half zo effectief als de eerste. De derde batterij voegt amper 4% toe, oftewel slechts 150 kWh per jaar. In mijn situatie is een batterij groter dan 5,4 kWh dus niet rendabel.

Financieel is het plaatje als volgt, met een aanname van 26c/kWh (inc belastingen, dat is mijn huidige vaste tarief) en een fictieve trugleververgoeding van 0,25c/.kWh (zoals GreenChoice aankondigde. De opbrengst per jaar is dan:

• 1 HomeWizard batterij: 170 euro per jaar -> terugverdientijd 8 jaar
• 2 HomeWizard batterijen: 255 euro per jaar -> terugverdientijd 10,9 jaar
• 2 HomeWizard batterijen: 285 euro per jaar -> terugverdientijd 14,7 jaar

Conclusie: zodra saldering eraf gaat koop ik zeker 1 HomeWizard batterij, persoonlijk vind ik een terugverdientijd van 8 jaar ok. Een tweede batterij wil ik ook nog wel als de prijs wat zakt (naar, laten we zeggen, 900 euro per batterij), maar een derde batterij (of een ander model van meer dan 5kWh) is voor mijn huishouden dus totaal niet interessant.

Ik ben nu iig blij dat ik een helderder beeld heb bij de impact van een thuisbatterij, hopelijk heeft iemand anders hier ook wat aan

[McNeils]

Ik zocht net specifiek op "reken model energieverbruik en thuisbatterij python"en kom ik hier uit ik vroeg me dus af hoe je beslist of je batterij oplaadt en teruglevert.

Na wat code doorsnuffelen heb ik begrepen dat hij oplaadt als er anders teruggeleverd zou worden en ontlaadt bij verbruik. Nice en simpel.
Werkt dat 'in het echt' ook zo?

[Wilke]

Dat hangt er van af hoe je het instelt, bovenstaande is nul-op-meter.

[Wilke]

Voor TS, interessant, en je bent op Tweakers niet de eerste die hier aan rekent. Er zijn voor Home Assistant ook wel plugins die een accu simuleren, bv. battery_sim.

Maar alhier is een van de eersten die er voor zover ik weet serieus aan gerekend heeft Anton Boonstra, die voor zijn verbruik toen tot vergelijkbare conclusies kwam als jij, zie hier met de tijdmachine naar 2018:

antonboonstra in "De Duurzame Kroeg Deel 3"

Een ander doel kan zijn het handelen op de onbalansmarkt, waar je van alles van kunt vinden. Dan kan een grotere accu allicht zin hebben, maar: vanaf 2027 is het vrijwel zeker afgelopen met dat verdienmodel, en voor die tijd terugverdienen (want dat is dan de enige reden om het te doen) is naar alle waarschijnlijkheid kansloos.

Dus, voor het verhogen van eigen verbruik zullen de meeste huishoudens inderdaad veel minder accu nodig hebben dan wat je zou denken. Op zich goed nieuws natuurlijk. Of slechts nieuws, als je het bekijkt van de andere kant: als je het percentage daarna nog serieus hoger wilt krijgen, moet je echt met tientallen kWh's aan komen zetten. Maar dat staat dan 99% van de tijd niets nuttigs te doen.

Jammer dat Nederland de boel niet op orde heeft om dit op wijkniveau te kunnen doen, zou veel nuttiger zijn.

[kiang]

McNeils schreef op vrijdag 28 maart 2025 @ 20:49:
Ik zocht net specifiek op "reken model energieverbruik en thuisbatterij python"en kom ik hier uit ik vroeg me dus af hoe je beslist of je batterij oplaadt en teruglevert.

Na wat code doorsnuffelen heb ik begrepen dat hij oplaadt als er anders teruggeleverd zou worden en ontlaadt bij verbruik. Nice en simpel.
Werkt dat 'in het echt' ook zo?

Hangt er vanaf welke batterij je koopt en/of hoe je hem instelt: wat is je laad- en ontlaadstrategie?

Wat ik hier heb geïmplementeerd heet nul-op-de-meter, een strategie waar ik fan van ben (het is simpel en relatief resistent voor veranderingen die de overheid, netbeheerder of energieleverancier zouden kunnen doorvoeren de komende jaren).

Er zijn meerdere batterijen die deze strategie ondersteunen (zoals die van marstech, ik denk ook die van Zonneplan, en degene die ik op het oog heb van HomeWizard werkt zelfs enkel en alleen emt deze strategie) dus als je die koopt werkt het ook 'in het echt' zo ja Hoe goed het werkt moet je overigens wel opzoeken: er kan nogal wat verschil zitten tussen batterijen. Mijn code houdt rekening met efficiëntie en (ont)laadsnelheden, en dat kan je ingeven bij je simulatie als je die cijfers van jouw batterij kan vinden.

Voor zover ik weet is de enige blinde vlek in mijn code nog de snelheid waarmee je batterij reageert: mijn code gaat er vanuit dat de batterij onmiddellijk kan reageren op stijgend of dalend verbruik, maar in de realiteit kan dat natuurlijk niet. Uit reviews blijkt echter dat de HomeWizard batterij best snel reageert en daardoor goed in staat is om je verbruik op 0 te krijgen.