Marstek PIB Domotica integratie en je Energierekening

[Ploeftia]

Een reactie op (Meer info: https://github.com/benjam...rd-pro?tab=readme-ov-file)

Hij gebruikt een ESP32-S3_Zero dit is een bordje met een slecht wifi bereik. Daar de keramische antenne te dicht bij de chip zit. Ze hebben geen Antenna keep out area gebruikt bij Waveshare. Een Xiao S3 met externe antenne werkt beter. Of deze op de print past en werkt weet ik niet. Zal wel van niet.

[BertusB404]

Is er iemand die de marstek batterij gebruikt met een smartgridone van eniris?
Daarmee kan men de batterij koppelen aan Frank energie voor handel op de onbalans markt.

Echter vind ik het een moeilijk te vinden apparaat en vermoed dat het nogal prijzig is.
Wellicht is er een omweg te vinden, maar het eniris protocol zal alles behalve open zijn vermoed ik.

[Hometek]

BertusB404 schreef op maandag 15 september 2025 @ 16:43:
Is er iemand die de marstek batterij gebruikt met een smartgridone van eniris?
Daarmee kan men de batterij koppelen aan Frank energie voor handel op de onbalans markt.

Echter vind ik het een moeilijk te vinden apparaat en vermoed dat het nogal prijzig is.
Wellicht is er een omweg te vinden, maar het eniris protocol zal alles behalve open zijn vermoed ik.

Waar heb je gezien dat dit device gekoppeld kan worden aan een Marstek Venus?
Handel op de onbalans markt wordt eigenlijk alleen door de energieleverancier gedaan met een vast geinstaleerde batterij. Bij een stekkerbatterij is er onvoldoende zekerheid dat het apparaat beschikbaar is op het moment dat de energieleverancier het wil inzetten.

Lijkt ook geen consumenten product (van de website):
We do not compete with installers or distributors by selling directly to end customers. Instead, we sell exclusively to installers or distributors, who are then free to offer the SmartgridOne to the end customer through their own business model.

[BertusB404]

Frank energie beweerd zelf dat de marstek middels de smartgridone gekoppeld kan worden. De website van eniris laat ook zien dat marstek batterijen er mee werken.

[Hometek]

BertusB404 schreef op dinsdag 16 september 2025 @ 00:05:
Frank energie beweerd zelf dat de marstek middels de smartgridone gekoppeld kan worden. De website van eniris laat ook zien dat marstek batterijen er mee werken.

Als ik het goed begrijp is het vooral een service die een bedrijf aan consumenten aan kan bieden door het plaatsen van de controler:
Build Your Own Pricing Model
We don’t impose a fixed retail price. Instead, you have the flexibility to choose between a one-time license fee or an annual license fee — both of which we invoice directly to you, not to the end customer. This allows you to develop your own pricing model for your clients, adding value through additional services.

[Hometek]

BertusB404 schreef op maandag 15 september 2025 @ 16:43:
Is er iemand die de marstek batterij gebruikt met een smartgridone van eniris?
Daarmee kan men de batterij koppelen aan Frank energie voor handel op de onbalans markt.

Echter vind ik het een moeilijk te vinden apparaat en vermoed dat het nogal prijzig is.
Wellicht is er een omweg te vinden, maar het eniris protocol zal alles behalve open zijn vermoed ik.

Ik vermoed dat je deze instructies al gezein had?
Als consument kun je niet zelf handelen op de onbalans markt, dat kunnen alleen energieleveranciers. Als consument kun je alleen je batterij beschikbaar stellen.

[iorses]

Hometek schreef op maandag 8 september 2025 @ 12:44:
De HA Solcast integratie (voorspelling PV opwek) heeft sinds de laatste update een 'Auto-dampen' feature.
Deze feature corrigeert automatisch structurele lokale afwijkingen, bv door schaduw, in de voorspelling. Volgens de beschrijving wordt data van de afgelopen 14 dagen gebruikt om correcties te bepalen.
Ik heb de functie gisteren geactiveerd, en zie vandaag idd een duidelijk betere voorspelling dan de afgelopen dagen. Als dit idd goed blijkt te werken maakt het Solcast een stuk betrouwbaarder.

Voorspelling en opwek gisteren (met handmatige correctie, in de zomer ingesteld)
[Afbeelding]

Voorspelling en opwek vandaag (met automatische correctie)
[Afbeelding]

Dit ga ik eens testen👍🏼

[Hometek]

iorses schreef op woensdag 17 september 2025 @ 16:02:
[...]
Dit ga ik eens testen👍🏼

Voor mij werkt de nieuwe functie best goed. Mijn panelen hebben in de namiddag veel schaduw van bomen, wat in deze maanden eerst erger wordt, en dan weer iets minder als het blad er af is. Ik verwacht dat deze functie dat redelijk kan corrigeren.

[antoinevromen]

Hallo medetweakers,

Naar aanleiding van mijn post op het marstek Venus E forum ben ik door @SatScan en @pascallj naar jullie forum hier verwezen.
Mocht er iemand (met kennis van powershell en windows-task-scheduler) interesse hebben om een (of meerdere) Marstek Venus E batterijen middels dedicated powershell-scripts aan te sturen via de local-api (dus zonder additionele hardware of software zoals home-assistant of homey) dan wil ik mijn code wel delen als soort van jump-start.

Bericht op het Marstek-forum (antoinevromen in "Hame / Marstek / Duravolt 5,12kWh plug en play thuisaccu"):
In mijn sturings-applicatie (gebaseerd op de local-api) die ik heb geschreven, wordt geautomatiseerd (via downloads) rekening wordt gehouden met de dynamische-prijzen, de hoeveelheid verwachte W/m2 zonne-energie in mijn woonplaats op de rest van de dag (Weerlive.nl) en de huidige soc / laad/-ontlaad waarden en de RTE die ook invloed heeft op de laad-prijs. Op basis van bovenstaande input kan ik de batterij sturen per kwartier tussen Auto en Manual-laden/ontladen of helemaal pauzeren omdat ik later op de dag zonnestroom wil laden en op de duurdere momenten mijn zonnestroom nog wil invoeren in het net. Uiteraard is dit script voor iedereen met een programmeer-achtergrond in Powershell naar eigen wensen uit te breiden. De powershell omgeving is ook standaard onderdeel van windows. Ik laat zelf periodiek (bijv elk kwartier of elk uur) het script draaien middels task-scheduler die standaard in windows aanwezig is.

[GoBieN-Be]

Ik ben wel benieuwd naar het aansturen van de local-api vanuit Powershell.
Begrijp ik uit je tekst dat jij niet probeert NOM te draaien?

[PNARI]

antoinevromen schreef op vrijdag 19 september 2025 @ 16:31:
Hallo medetweakers,

Naar aanleiding van mijn post op het marstek Venus E forum ben ik door @SatScan en @pascallj naar jullie forum hier verwezen.
Mocht er iemand (met kennis van powershell en windows-task-scheduler) interesse hebben om een (of meerdere) Marstek Venus E batterijen middels dedicated powershell-scripts aan te sturen via de local-api (dus zonder additionele hardware of software zoals home-assistant of homey) dan wil ik mijn code wel delen als soort van jump-start.

Bericht op het Marstek-forum (antoinevromen in "Hame / Marstek / Duravolt 5,12kWh plug en play thuisaccu"):
In mijn sturings-applicatie (gebaseerd op de local-api) die ik heb geschreven, wordt geautomatiseerd (via downloads) rekening wordt gehouden met de dynamische-prijzen, de hoeveelheid verwachte W/m2 zonne-energie in mijn woonplaats op de rest van de dag (Weerlive.nl) en de huidige soc / laad/-ontlaad waarden en de RTE die ook invloed heeft op de laad-prijs. Op basis van bovenstaande input kan ik de batterij sturen per kwartier tussen Auto en Manual-laden/ontladen of helemaal pauzeren omdat ik later op de dag zonnestroom wil laden en op de duurdere momenten mijn zonnestroom nog wil invoeren in het net. Uiteraard is dit script voor iedereen met een programmeer-achtergrond in Powershell naar eigen wensen uit te breiden. De powershell omgeving is ook standaard onderdeel van windows. Ik laat zelf periodiek (bijv elk kwartier of elk uur) het script draaien middels task-scheduler die standaard in windows aanwezig is.

Mooi initiatief maar ik heb begrepen dat api van Venus maar voor een beperkt aantal gebruikers beschikbaar is ?

[HiHaHors]

antoinevromen schreef op vrijdag 19 september 2025 @ 16:31:
Hallo medetweakers,

Naar aanleiding van mijn post op het marstek Venus E forum ben ik door @SatScan en @pascallj naar jullie forum hier verwezen.
Mocht er iemand (met kennis van powershell en windows-task-scheduler) interesse hebben om een (of meerdere) Marstek Venus E batterijen middels dedicated powershell-scripts aan te sturen via de local-api (dus zonder additionele hardware of software zoals home-assistant of homey) dan wil ik mijn code wel delen als soort van jump-start.

Bericht op het Marstek-forum (antoinevromen in "Hame / Marstek / Duravolt 5,12kWh plug en play thuisaccu"):
In mijn sturings-applicatie (gebaseerd op de local-api) die ik heb geschreven, wordt geautomatiseerd (via downloads) rekening wordt gehouden met de dynamische-prijzen, de hoeveelheid verwachte W/m2 zonne-energie in mijn woonplaats op de rest van de dag (Weerlive.nl) en de huidige soc / laad/-ontlaad waarden en de RTE die ook invloed heeft op de laad-prijs. Op basis van bovenstaande input kan ik de batterij sturen per kwartier tussen Auto en Manual-laden/ontladen of helemaal pauzeren omdat ik later op de dag zonnestroom wil laden en op de duurdere momenten mijn zonnestroom nog wil invoeren in het net. Uiteraard is dit script voor iedereen met een programmeer-achtergrond in Powershell naar eigen wensen uit te breiden. De powershell omgeving is ook standaard onderdeel van windows. Ik laat zelf periodiek (bijv elk kwartier of elk uur) het script draaien middels task-scheduler die standaard in windows aanwezig is.

Ik ben zeer geïnteresseerd in jouw scripts!

[AUijtdehaag]

PNARI schreef op zaterdag 20 september 2025 @ 06:46:
[...]

Mooi initiatief maar ik heb begrepen dat api van Venus maar voor een beperkt aantal gebruikers beschikbaar is ?

Kun je zelf aanzetten
https://rweijnen.github.io/marstek-venus-monitor/latest/

[antoinevromen]

GoBieN-Be schreef op zaterdag 20 september 2025 @ 00:30:
Ik ben wel benieuwd naar het aansturen van de local-api vanuit Powershell.
Begrijp ik uit je tekst dat jij niet probeert NOM te draaien?

Jawel ik draai voornamelijk NOM (dus dat is Modus Auto en staat in de app als zelfconsumptie),
maar er kunnen momenten zijn (bijv. 's winters als de batterij bijna nooit vol raakt waarop het script 1 x per week op het laagste tarief toch een keer tot 100% vol laadt t.b.v. behoud accu en soc-drift) of wanneer je bijv. dynamisch tarief hebt en je geraakt niet helemaal door de nacht met de batterij dat je dan de batterij op het laagste tarief gedurende de nacht zoveel bijlaadt dat je in de ochtend over het duurste tarief-moment heen geraakt.
Of bijv. in de winter als de batterij maar voor een deel is vol geraakt en de dure uren rond 19.00/20.00 moeten nog komen zoveel bijlaadt dat je over die dure uren heen geraakt.
Maar ik ben ook nog aan het denken aan het inbouwen van juist verkopen in de zomer op het duurste uur met zonnestroom die gratis in de middag is opgeslagen. Daarnaast ben ik ook nog aan het denken om bijv. in de zomer de batterij niet al van 7 tot 10 te laten volladen (maar die stroom liever naar het net te leveren) en in plaats daarvan op de negatieve uren of 0 uren in de middag hem vol te laden omdat hij toch altijd wel vol raakt op zo'n dag (ook op basis van de voorspellingen van zonne-Watt/m2 die ik download en interpreteer in het script).

[antoinevromen]

@GoBieN-Be @HiHaHors ,
Oke ik zal in de loop van de komende week het script en een beetje van handleiding waar het script de tarieven en zonne-wattage vandaan haalt hier posten. Als je handig bent in programmeren, dan kun je het daarna zelf aanpassen naar eigen sturings-wensen.
Misschien ook een idee om eens van gedachten te wisselen wat bijv. algemene use-cases zouden kunnen zijn om in te bouwen, zoals ik hier al heb beschreven in mijn eerdere post als antwoord op GoBienBe

[Hometek]

antoinevromen schreef op zaterdag 20 september 2025 @ 09:41:
[...]

Jawel ik draai voornamelijk NOM (dus dat is Modus Auto en staat in de app als zelfconsumptie),
maar er kunnen momenten zijn (bijv. 's winters als de batterij bijna nooit vol raakt waarop het script 1 x per week op het laagste tarief toch een keer tot 100% vol laadt t.b.v. behoud accu en soc-drift) of wanneer je bijv. dynamisch tarief hebt en je geraakt niet helemaal door de nacht met de batterij dat je dan de batterij op het laagste tarief gedurende de nacht zoveel bijlaadt dat je in de ochtend over het duurste tarief-moment heen geraakt.
Of bijv. in de winter als de batterij maar voor een deel is vol geraakt en de dure uren rond 19.00/20.00 moeten nog komen zoveel bijlaadt dat je over die dure uren heen geraakt.
Maar ik ben ook nog aan het denken aan het inbouwen van juist verkopen in de zomer op het duurste uur met zonnestroom die gratis in de middag is opgeslagen. Daarnaast ben ik ook nog aan het denken om bijv. in de zomer de batterij niet al van 7 tot 10 te laten volladen (maar die stroom liever naar het net te leveren) en in plaats daarvan op de negatieve uren of 0 uren in de middag hem vol te laden omdat hij toch altijd wel vol raakt op zo'n dag (ook op basis van de voorspellingen van zonne-Watt/m2 die ik download en interpreteer in het script).

Ik ben met iets soortgelijks bezig in Node-RED.
Op basis van gemiddeld verbruik en verwachte opwek voor komende 24 en 48 uur de minimale SOC berekenen en dan bij overschot op dure uren ontladen of bij tekort op goedkope uren bijladen tot aan de minimale SOC.



In dit voorbeeld was op dag 2 het verbruik hoger dan gemiddeld, dus de SOC bleef achter, en omdat ik krappe drempelwaarden had ingesteld werd er van het net opgeladen.
Op dag 3 waren de drempelwaarde ruimer ingesteld en werd er niet opgeladen.

Over een week of twee zal ik wat meer details delen.

[antoinevromen]

Hometek schreef op zaterdag 20 september 2025 @ 22:15:
[...]

Ik ben met iets soortgelijks bezig in Node-RED.
Op basis van gemiddeld verbruik en verwachte opwek voor komende 24 en 48 uur de minimale SOC berekenen en dan bij overschot op dure uren ontladen of bij tekort op goedkope uren bijladen tot aan de minimale SOC.

[Afbeelding]

In dit voorbeeld was op dag 2 het verbruik hoger dan gemiddeld, dus de SOC bleef achter, en omdat ik krappe drempelwaarden had ingesteld werd er van het net opgeladen.
Op dag 3 waren de drempelwaarde ruimer ingesteld en werd er niet opgeladen.

Over een week of twee zal ik wat meer details delen.

Hallo @Hometek ,
Exact. Mooi te lezen dat je ook in diezelfde sturings-richting aan het werken bent. Dat is ook de oplossingsrichting die ik aan het inbouwen ben. Op basis van de zon-voorspelling in Watt/m2 kan ik uitrekenen hoeveel PV-kWh ik nog verwacht op te wekken en dan kijk ik of ik vanaf het huidige uur x t/m maximale prijsuur met de huidige soc en verwachte bijlaadhoeveelheid uit kom rekening houdend met een geschat gemiddeld verbruik per uur. Als het met PV-opwek lukt om die drempel-soc te bereiken dan niet bijladen. Als er niet voldoende PV-opwek is, dan kijken of de huidige Net-prijs (verhoogd met RTE-verlies) opweegt tegen de gemiddelde prijs van de laatste uren vooraf en inclusief het maximale prijsuur waarvoor ik Net-stroom zou moeten bijladen. Ook hier is het nog even spelen met de parameters die bepalen hoeveel PV-kWh daadwerkelijk uit zonne Watt/m2 komt en hoeveel W/uur je verbruikt in de nacht en overdag om in te schatten hoeveel de huidige soc nog zal dalen ten gevolge van dat verbruik.

Ik houd daarbij overigens rekening met 2 max-prijsnivo's per dag ; 1 voor de middag (meestal rond 8 uur 's morgens) en 1 voor na de middag (meestal rond 20.00 's avonds); Zodat ik 2 momenten heb waarop ik de soc kan bijsturen door van het Net te laden met goedkope stroom. Maar zoals ik al schreef zijn er in de zomer wellicht nog andere punten van sturing (zoals bijv. niet laden in de ochtend, maar pas als de prijs minimaal/negatief is als de voorspelling toch voldoende PV-stroom aangeeft); Dan leveren die Net-teruggeleverde kWh's in de ochtend nog iets op en bespaar ik mij (een deel van) de negatieve prijs-uren.

[ Voor 14% gewijzigd door antoinevromen op 21-09-2025 08:56 ]

[Hometek]

antoinevromen schreef op zondag 21 september 2025 @ 08:52:
[...]
Hallo @Hometek ,
Exact. Mooi te lezen dat je ook in diezelfde sturings-richting aan het werken bent. Dat is ook de oplossingsrichting die ik aan het inbouwen ben. Op basis van de zon-voorspelling in Watt/m2 kan ik uitrekenen hoeveel PV-kWh ik nog verwacht op te wekken en dan kijk ik of ik vanaf het huidige uur x t/m maximale prijsuur met de huidige soc en verwachte bijlaadhoeveelheid uit kom rekening houdend met een geschat gemiddeld verbruik per uur. Als het met PV-opwek lukt om die drempel-soc te bereiken dan niet bijladen. Als er niet voldoende PV-opwek is, dan kijken of de huidige Net-prijs (verhoogd met RTE-verlies) opweegt tegen de gemiddelde prijs van de laatste uren vooraf en inclusief het maximale prijsuur waarvoor ik Net-stroom zou moeten bijladen. Ook hier is het nog even spelen met de parameters die bepalen hoeveel PV-kWh daadwerkelijk uit zonne Watt/m2 komt en hoeveel W/uur je verbruikt in de nacht en overdag om in te schatten hoeveel de huidige soc nog zal dalen ten gevolge van dat verbruik.

Ik houd daarbij overigens rekening met 2 max-prijsnivo's per dag ; 1 voor de middag (meestal rond 8 uur 's morgens) en 1 voor na de middag (meestal rond 20.00 's avonds); Zodat ik 2 momenten heb waarop ik de soc kan bijsturen door van het Net te laden met goedkope stroom. Maar zoals ik al schreef zijn er in de zomer wellicht nog andere punten van sturing (zoals bijv. niet laden in de ochtend, maar pas als de prijs minimaal/negatief is als de voorspelling toch voldoende PV-stroom aangeeft); Dan leveren die Net-teruggeleverde kWh's in de ochtend nog iets op en bespaar ik mij (een deel van) de negatieve prijs-uren.

@antoinevromen
Hetzelfde basisprincipe, maar verschillende strategieën. Iedereen heeft zo zijn eigen voorkeuren
Mijn strategie is om de baterij tegen het einde van de middag altijd op het minimum SOC niveau te hebben. Opladen bij laagste prijs en ontladen bij hoogste prijs gebeurt alleen als er op dat moment toevallig een tekort dan wel een overschot is. Hierdoor zou het systeem redelijk ongevoelig moeten zijn voor het verschuiven van de goedkope en dure momenten gedurende het jaar. Ik kijk niet naar de prijzen zelf, alleen of het een maximum of minimum is.
Voor het ontladen kijk ik naar de minimum SOC voor vandaag, voor het opladen kijk ik ook naar de minimum SOC voor de volgende dag om te voorkomen dat ik vandaag stroom inkoop terwijl er morgen voldoende zon is.
Deze strategie is natuurlijk alleen zinvol bij een installatie met een relatief grote batterij die meestal niet leeg raakt gedurende de nacht.

Voor de PV opwek gebruik ik Solcast, deze integratie levert direct de verwachte kWh voor een specifieke installatie, en er zit sinds kort een handige auto-correctie functie in (zie deze post)

[antoinevromen]

@Hometek
Zeker. Ofschoon het misschien niet allemaal qua strategie precies te snappen is en ik de consequenties van jouw keuzes niet helemaal kan inschatten, vind ik het vooral goed dat we ieder voor zich de batterij zo kunnen sturen middels wat eenvoudige scripts als wij dat wensen. En er zelfs functionaliteit bij kunnen maken die er op geen andere wijze in het product zit (ik noem maar eens bijv. 1 x per week tot 100% laden, zodat de batterij in de winter niet steeds leeg staat).
Zo stuurde ik ook eerst op minimum en maximum prijs, maar kwam erachter dat ik ook de RTE (verlies t.g.v. laden/ontladen) in de berekening wilde meenemen omdat ik merkte dat soms een verschil van bijv. x-cent zich door de RTE uiteindelijk vertaalde in het feit dat de minimum-stroomprijs (geladen) toch nog hoger was dan de maximum prijs.
Ik ga nu wat scripts van mij hier posten, zodat eenieder die er interesse in heeft zelf eraan kan sleutelen.
Ik denk dat het nog lastig wordt om een grootste gemene deler te vinden voor wat nu de "juiste" strategie is (als die er al is).

Gr. Antoine

[antoinevromen]

antoinevromen schreef op zaterdag 20 september 2025 @ 09:46:
@GoBieN-Be @HiHaHors ,
Oke ik zal in de loop van de komende week het script en een beetje van handleiding waar het script de tarieven en zonne-wattage vandaan haalt hier posten. Als je handig bent in programmeren, dan kun je het daarna zelf aanpassen naar eigen sturings-wensen.
Misschien ook een idee om eens van gedachten te wisselen wat bijv. algemene use-cases zouden kunnen zijn om in te bouwen, zoals ik hier al heb beschreven in mijn eerdere post als antwoord op GoBienBe

DEEL1
Beste Tweakers (o.a. @GoBieN-Be @HiHaHors),
Zoals eerder geschreven hier alvast wat scripts om de batterij middels local-api te sturen.
Veel hiervan was niet mogelijk geweest zonder de hulp van @bommel , die mij ook een stukje voorbeeldcode heeft gegeven destijds.
Wat weetjes vooraf:
-1 de scripts zijn als windows cmd-bestandjes en windows powershell-scripts gemaakt. Pas ze aan naar hartelust want ik ben de software zelf ook nog aan het uitbreiden, maar heb niet de intentie om daar een soort turn-key-project van te maken.
-2 ik ben nooit ver weg mochten mensen vragen hebben, vraag gerust
-3 de windows cmd-bestandjes laat ik middels windows task-scheduler periodiek (elk kwartier of elk uur) draaien, maar in principe gaat het er maar om dat de cmd-bestandjes gestart worden, dus hoe je dat zelf wilt regelen is up to you.
-4 de cmd-bestandjes starten (al dan niet met meegave van parameters) de powershell-scripts, welke de eigenlijke logica bevatten
-5 bij sommige scriptjes met calls naar externe https-providers is een key t.b.v. de externe api vereist. Ik zal hier beschrijven waar je op eenvoudige/gratis wijze zo'n key voor jezelf kunt krijgen. (mijn eigen key is om die reden niet getoond in de scripts om te voorkomen dat we straks allemaal geen toegang meer krijgen vanwege een te hoog aantal api-calls op die externe site onder 1 account).
-6 het spreekt voor zich dat je local-api op de Marstek Vensus E geactiveerd moet hebben. Dat kan via het officiele kanaal (een feedback bericht in de app, waarbij je verzoekt jouw batterij local-api te enabelen; Het kan ook met behulp van de tool van bommel @bommel (https://rweijnen.github.io/marstek-venus-monitor/latest/) onder system in dat tool tref je activeren local-api op poort 30000 aan (meer hierover is ook te vinden op het moeder-forum (Hame / Marstek / Duravolt 5,12kWh plug en play thuisaccu) )
-7 Ik heb momenteel geen idee hoe ik dit gestructureerd aan jullie moet overbrengen omdat ik niet schijn te vinden hoe ik attachments kan meesturen met een forum-post; Vandaar zal ik de script-code hier in een post stoppen. (zoveel is het nu ook weer niet).
-8 om powershell-scripts te kunnen draaien vanuit een windows cmd-box doe je het volgende:
a) start een windows command processor als admin
b) start nu op de prompt powershell.exe
c) start nu op de prompt Get-ExecutionPolicy -List
dat geeft een lijst van rechten weer waarbij alles undefined zal zijn als default
d) start nu op de prompt set-executionpolicy remotesigned
dit geeft de juiste rechten op localmachine nivo
e) door nogmaals op de prompt Get-ExecutionPolicy -List te starten kun je zien dat die rechten effectief zijn geworden. Vanaf nu kun je op die machine vanuit locale-cmd-bestandjes powershell-scripts draaien

[ Voor 10% gewijzigd door antoinevromen op 21-09-2025 17:34 ]

[antoinevromen]

DEEL2 (scriptje avzetMODEaan.cmd)
=====

code:

c:
cd \netcat-setup
echo inputmode kan zijn: AI, Auto, Passive, ManualLaden, ManualOntladen
set /p inputmode=
powershell.exe -file c:\netcat-setup\avzetMODEaan.ps1 -DeviceIP "192.168.178.234" -Mode %inputmode%
pause

====
powershell-scriptje avzetMODEaan.ps1
=====

code:

# example usage:
# .\MT-LocalApi-Example -DeviceIP 192.168.20.82 -RemotePort 30000 -LocalPort 30000 -PerCallTimeoutMs 2000 -MaxRetries 3
param(
  [Parameter(Mandatory=$true)][string]$DeviceIP = "192.168.178.xxx",
  [Parameter(Mandatory=$true)][string]$Mode = "xx",
  [int]$RemotePort = 30000,
  [int]$LocalPort  = $RemotePort,
  [int]$PerCallTimeoutMs = 5000, 
  [int]$MaxRetries = 3,
  [int]$InterCallDelayMs = 1000 
)

Add-Type -AssemblyName System.Net 

# Create socket, enable reuse, bind to LocalPort (so source port is fixed)
$udp = New-Object System.Net.Sockets.UdpClient
$udp.Client.SetSocketOption([System.Net.Sockets.SocketOptionLevel]::Socket, [System.Net.Sockets.SocketOptionName]::ReuseAddress, $true)
$udp.Client.ExclusiveAddressUse = $false
$udp.Client.Bind([System.Net.IPEndPoint]::new([System.Net.IPAddress]::Any, $LocalPort))
$udp.Client.ReceiveTimeout = 1000 ## 250

function Send-And-Wait([string]$Method, [hashtable]$Params) {
  for($try=1; $try -le $MaxRetries; $try++){
    $rpcId = Get-Random -Minimum 1000 -Maximum 65000       # JSON-RPC id (unique per try)
    $req = @{ id=$rpcId; method=$Method; params=$Params } | ConvertTo-Json -Compress -Depth 6
    Write-Host ($req)
    $bytes = [Text.Encoding]::UTF8.GetBytes($req)
    [void]$udp.Send($bytes, $bytes.Length, $DeviceIP, $RemotePort)
    Write-Host ("→ [{0}/{1}] {2} {3}" -f $try,$MaxRetries,$Method,($Params | ConvertTo-Json -Compress))

    $deadline = [datetime]::UtcNow.AddMilliseconds($PerCallTimeoutMs * [math]::Pow(1.35, $try-1))
    $remote = [System.Net.IPEndPoint]::new([System.Net.IPAddress]::Any,0)

    while([datetime]::UtcNow -lt $deadline){
      try {
        $resp = $udp.Receive([ref]$remote)
        $txt  = [Text.Encoding]::UTF8.GetString($resp)
        $obj  = $txt | ConvertFrom-Json -ErrorAction SilentlyContinue
        if($obj -and $obj.id -eq $rpcId){
          Write-Host ("av1<= [{0}] {1}`n{2}`n" -f $rpcId,$Method,$txt)
          Start-Sleep -Milliseconds $InterCallDelayMs
          return
        }
        # ignore late/unrelated frames and keep waiting
      } catch {
        # slice timeout; keep looping until overall deadline
      }
    }
    Start-Sleep -Milliseconds (100 + (Get-Random -Minimum 0 -Maximum 80))
  }
  Write-Host ("<= [--] {0}  -- timeout after {1} ms x{2}`n" -f $Method,$PerCallTimeoutMs,$MaxRetries)
  Start-Sleep -Milliseconds $InterCallDelayMs
}

# Warm-up (often helps)
Send-And-Wait "Marstek.GetDevice" @{ ble_mac = "0" }
Send-And-Wait "ES.GetMode" @{id=0} 
if ($Mode -eq "AI") {
   ##Write-Host ("Mode={0}" -f $Mode)
   Send-And-Wait "ES.SetMode" @{id=1; config = @{id=1; mode= "AI"; ai_cfg= @{enable=1}}}
}
if ($Mode -eq "Auto") {
   ##Write-Host ("Mode={0}" -f $Mode)
   Send-And-Wait "ES.SetMode" @{id=1; config = @{id=1; mode= "Auto"; auto_cfg= @{enable=1}}}
}
if ($Mode -eq "Passive") {
   ##Write-Host ("Mode={0}" -f $Mode)
   Send-And-Wait "ES.SetMode" @{id=1; config = @{id=1; mode= "Passive"; passive_cfg= @{power=100;cd_time=3}}}
}
if ($Mode -eq "ManualLaden") {
   ##Write-Host ("Mode={0}" -f $Mode)
   ##N.B. laden van de accu moet met een negatief getal bij power
   Send-And-Wait "ES.SetMode" @{id=1; config = @{id=1; mode= "Manual"; manual_cfg= @{time_num=1;start_time="04:00";end_time="05:00";week_set=127;power=-2500;enable=1}}}
}
if ($Mode -eq "ManualOntladen") {
   ##Write-Host ("Mode={0}" -f $Mode)
   ##N.B. ontladen van de accu moet met een positief getal bij power
   Send-And-Wait "ES.SetMode" @{id=1; config = @{id=1; mode= "Manual"; manual_cfg= @{time_num=1;start_time="16:00";end_time="19:00";week_set=127;power=210;enable=1}}}
}

# Optional: drain late packets
$remote = [System.Net.IPEndPoint]::new([System.Net.IPAddress]::Any,0)
while([datetime]::UtcNow -lt $until){
  try {
    $txt = [Text.Encoding]::UTF8.GetString($udp.Receive([ref]$remote))
    Write-Host ("<= [late] {0}:{1}`n{2}`n" -f $remote.Address,$remote.Port,$txt)
  } catch {}
}
$udp.Close()

==============

[antoinevromen]

DEEL3:
Het scriptje avzetMODEaan.ps1 bevat code waarin o.a. de huidige soc, de huidige ongrid-power, de huidige modus worden weergegeven. Daarnaast zitten in het scriptje alle voorbeelden om de mode van de batterij te switchen naar 1 van de volgende: AI, Auto, Manual-laden, Manual-ontladen en Passive

Ik heb zelf momenteel hardcoded het cmd-scriptje en het ps1-scriptje in de direcotry c:\netcat-setup staan, maar binnen in het script wordt van .\ uitgegaan, dus je kunt e.e.a. ook naar een andere directory verplaatsen.

[ Voor 26% gewijzigd door antoinevromen op 21-09-2025 17:00 ]

[antoinevromen]

DEEL4: het bestandje avhaalTARIEVEN.cmd
Onderstaande scriptje haalt op de site jeroen.nl de dynamische tarieven van vandaag op in de vorm van een json-file (dus als je het morgen draait om zeg maar 00:01 uur, dan krijg je uiteraard de tarieven van die dag )
Omdat de inhoud van deze tarieven niet wijzigt sla ik die json-informatie op in een .txt-bestandje (dagtarief.txt), van waaruit ik het later kan inlezen en kan bevragen m.b.t. prijzen en uren waarop die prijzen gelden.
Je ziet dat er in het web-request een key= moet worden meegegeven.
Die key kun je gratis krijgen als je een account aanmaakt bij jeroen.nl . Vervolgens kun je naar de volgende pagina gaan: https://jeroen.nl/account/feeds waar je jouw persoonlijk api-key kunt vinden.
==============

code:

c:
cd \netcat-setup
powershell.exe -file .\avhaalTARIEVEN.ps1

=================
het bestandje avhaalTARIEVEN.ps1
==================

code:

Add-Type -AssemblyName System.Net 
$TarievenVandaag = Invoke-WebRequest 'https://jeroen.nl/api/dynamische-energieprijzen/v2/?period=vandaag&type=json&key=op deze plek je eigen api-key van jeroen.nl'
$TarievenVandaag = $TarievenVandaag -replace ':"-0,', ':"-0.'
$TarievenVandaag = $TarievenVandaag -replace ':"0,', ':"0.'
[System.IO.File]::WriteAllText(".\dagtarief.txt", $TarievenVandaag)

[antoinevromen]

DEEL 5:
Onderstaande scriptje haalt op de site weerlive.nl (van het KNMI) de voorspelde zonne-wattages weer per uur van de dag op een locatie en slaat dit op in de vorm van een json-file (dus als je het morgen draait om zeg maar 00:01 uur, dan krijg je uiteraard de zonnewaarden van die dag )
Omdat de inhoud van zonnewaarden elk uur wijzigt (en betrouwbaarder wordt) sla ik die json-informatie elk uur op in een .txt-bestandje (zonvandaag.txt), van waaruit ik het later kan inlezen en kan bevragen m.b.t. wattages per uur per m2 op die locatie.
Je ziet dat er in het web-request een key= moet worden meegegeven.
Die api-key kun je gratis krijgen via https://weerlive.nl/delen.php en in het script invullen op de plaats achter key=
=====
Het bestandje avhaalZONNEKRACHT.cmd
=====

code:

c:
cd \netcat-setup
powershell.exe -file .\avhaalZONNEKRACHT.ps1

=====
Het bestandje avhaalZONNEKRACHT.ps1
=====

code:

Add-Type -AssemblyName System.Net # ,System.Net.Sockets
$ZonVandaag = Invoke-WebRequest 'https://weerlive.nl/api/weerlive_api_v2.php?key=jouw-persoolijnk-key&locatie=Voerendaal'
[System.IO.File]::WriteAllText(".\zonvandaag.txt", $ZonVandaag)

====

[antoinevromen]

DEEL6:
Onderstaand het script om periodiek (bijv. elk kwartier) te draaien dat op basis van zonnewattage/m2 , dynamische tarieven voor een dag, de huidige informatie uit je batterij en enkele andere logica bepaalt of
de batterij middels Net-stroom geladen moet worden om zodoende geld te verdienen (bijv. door te handelen, of door ervoor te zorgen dat je de dure uren via de batterij kunt doorkomen met goedkoop geladen net-stroom etc.
=====
Het scriptje avzetMODEdynamisch.cmd
=====

code:

c:
cd \netcat-setup
powershell.exe -file .\avzetMODEdynamisch.ps1

======
Het scriptje avzetMODEdynamisch.ps1
=====

code:

# example usage:
# .\MT-LocalApi-Example -DeviceIP 192.168.20.82 -RemotePort 30000 -LocalPort 30000 -PerCallTimeoutMs 2000 -MaxRetries 3
param(
##constanten
  [string]$DeviceIP = "192.168.178.234",
  [string]$tijdstempel_str = (Get-Date).ToString("yyyy-MM-dd HH:mm:ss"),
  [string]$bijladen_gedurende_huidig_contract = "N",
  [int]$RemotePort = 30000,
  [int]$LocalPort  = $RemotePort,
  [int]$PerCallTimeoutMs = 5000, 
  [int]$MaxRetries = 3,
  [int]$InterCallDelayMs = 1000, 
  [int]$BijlaadRekenhoeveelheidPerUur_VM_int = 250,
  [int]$BijlaadRekenhoeveelheidPerUur_NM_int = 500,
  [int]$capaciteit_batterij_int = 5120,
  [int]$max_laadcapaciteit_int_int = 2500,
  [double]$ACDCAComzettnigverlies_double = 0.75,
  [double]$opslag_energieleverancier_double = 0.0233,
  [double]$opslag_energiebelasting_double = 0.10154,
  [double]$btw_perc_double = 0.21,
  [double]$opslagbedragNetLaden_double = 0.03,
  [double]$opp_pv_hoogdak_double = (9 + 6) * 1.5 * 1.05 ,
  [double]$opp_pv_laagdak_double = (    9) * 1.5 * 1.05 ,
  [double]$opp_pv_tuinhuis_double = 4 * 1.7 * 1.05 ,

  ## op 19-sep-2025 in totaal opwek alle panelen 32kWh   45 m2 opp.bij voorspelde 4270 W/m2 = factor 0,166
  ## op 20-sep-2025 in totaal opwek alle panelen 14,3kWh 45 m2 opp bij voorspelde 3170 W/m2 = factor 0,10
  ## op 21-sep-2025 in totaal opwek alle panelen 10,9kWh 45 m2 opp bij voorspelde 1264 W/m2 = factor 0,19
  [double]$ervaringscijfer_kWh_per_zonwaarde = 0.14, ## 32000/(($opp_pv_hoogdak_double + $opp_pv_laagdak_double + $opp_pv_tuinhuis_double)*4270)
##=========================================================================
  [string]$modenieuw_str = "x",
  [string]$modenu_str = "x",
  [string]$modegezet_str = "N",
  [string]$mode_Go_Passive_str = "N",
  [int]$bat_soc_int = 999,
  [int]$ongrid_power_int = 999,
  [int]$huidigemaand_int = 999,
  [int]$huidiguur_int = 999,
  [int]$maxzoekuur_int = -10,
  [int]$minzoekuur_int = 9999,
  [int]$minuur_int = 888,
  [int]$minnegatiefuur_int = 88,
  [int]$maxuur_int = -10,
  [int]$zoekuur_int = 9999,
  [int]$socwaarde_stopladen_int = 9999,
  [int]$zon_som_waarde_van_nu_tm_einde_dag_int = 9999,
  [int]$zon_som_waarde_van_nu_tot_nabijste_maxuur_int = 9999,
  [int]$uren_langer_maxuur_int = 0,
  [int]$te_verwachten_PV_opbrengst_vanNu_totMaxuur_int = 9999,
  [int]$benodigde_Energie_vanNu_tot_en_met_Maxuur_int = 9999,
  [int]$BijlaadHoeveelheidPerUur_int = 9999,
  [int]$Benodigde_Soc_voor_3_uur_int = 9999,
  [double]$mintarief_double = 999,
  [double]$minnegatieftarief_double = 999,
  [double]$maxtarief_double = -10,
  [double]$tariefuur_double = 99,
  [double]$TariefBruto_double = 999, 
  [double]$brutotariefmaxuur_double = 999,
  [double]$brutotariefhuidiguur_omgerekend_verlies_double = 999,
  [double]$brutotariefmaxuur_plus_1_double = 999,
  [double]$brutotariefmaxuur_plus_2_double = 999,
  [double]$gemiddeld_brutotarief_additionele_bijlaaduren_double = 999,
  [double]$nettohuidigtarief_double = 999
)

Add-Type -AssemblyName System.Net # ,System.Net.Sockets

# Create socket, enable reuse, bind to LocalPort (so source port is fixed)
$udp = New-Object System.Net.Sockets.UdpClient
$udp.Client.SetSocketOption([System.Net.Sockets.SocketOptionLevel]::Socket, [System.Net.Sockets.SocketOptionName]::ReuseAddress, $true)
$udp.Client.ExclusiveAddressUse = $false
$udp.Client.Bind([System.Net.IPEndPoint]::new([System.Net.IPAddress]::Any, $LocalPort))
$udp.Client.ReceiveTimeout = 1000 
##===============================================================================================
function Bepaal_ZonWattage_van_tm_Uur ([int]$zon_vanaf_uur_int, [int]$zon_tm_uur_int) {
$ZonVandaag = [IO.File]::ReadAllText(".\zonvandaag.txt")
$ZonVandaag_obj = $ZonVandaag | ConvertFrom-Json 
[int]$som_zon_waarden_int = 0
foreach ($Zon_obj in $ZonVandaag_obj) {
  foreach ($Zon_uur_verw_obj in $Zon_obj[0].uur_verw) {
      $dag = [datetime](Get-Date $Zon_uur_verw_obj[0].uur -f "yyyy-MM-dd HH:mm:ss")
      $uur_int = [int]$dag.hour
      if ($uur_int -ge $zon_vanaf_uur_int -and $uur_int -le $zon_tm_uur_int) {
         $som_zon_waarden_int = $som_zon_waarden_int + $Zon_uur_verw_obj[0].gr
      }
  }
}
Return [double]$som_zon_waarden_int
}
##===============================================================================================
function Bepaal_Tarief_Op_Uur ([int]$vraaguur) {
$TarievenVandaag = [IO.File]::ReadAllText(".\dagtarief.txt")
$TarievenVandaag_obj = $TarievenVandaag | ConvertFrom-Json 

foreach ($Tarief_obj in $TarievenVandaag_obj) {
    $dag = [datetime](Get-Date $Tarief_obj[0].datum_nl -f "yyyy-MM-dd HH:mm:ss")
    if (($vraaguur -eq $dag.Hour)) {
          Return [double]$Tarief_obj[0].prijs_excl_belastingen
    }
}
Return [double]99999
}
##===============================================================================================
function Bepaal_Gem_BrutoTarief_Van_Tm_Uur ([int]$vraaguur_van, [int]$vraaguur_tm) {
$TarievenVandaag = [IO.File]::ReadAllText(".\dagtarief.txt")
$TarievenVandaag_obj = $TarievenVandaag | ConvertFrom-Json 
[double]$som_bedrag_double = 0
[int]$aantal_bedrag_int = 0
$TariefBruto_double = 0
foreach ($Tarief_obj in $TarievenVandaag_obj) {
    $dag = [datetime](Get-Date $Tarief_obj[0].datum_nl -f "yyyy-MM-dd HH:mm:ss")
    if (($dag.Hour -ge $vraaguur_van) -and ($dag.Hour -le $vraaguur_tm)) {
          $TariefBruto_double = [double]($Tarief_obj[0].prijs_excl_belastingen)
          $TariefBruto_double = [double]($TariefBruto_double + $opslag_energieleverancier_double + $opslag_energiebelasting_double)
          $TariefBruto_double = [double]($TariefBruto_double * [double](1 + $btw_perc_double))
          $som_bedrag_double = [double]($som_bedrag_double + $TariefBruto_double)
          $aantal_bedrag_int = $aantal_bedrag_int + 1
    }
}
$TariefBruto_double = $som_bedrag_double / $aantal_bedrag_int
Return $TariefBruto_double
}
##===============================================================================================
function Send-And-Wait([string]$Method, [hashtable]$Params) {
    [string]$modenu = "dummywaarde-modenu"
    [string]$bat_soc_str = "dummywaarde-soc"
    [string]$ongrid_power_str = "dummywaarde-power"
  for($try=1; $try -le $MaxRetries; $try++){
    $rpcId = Get-Random -Minimum 1000 -Maximum 65000       # JSON-RPC id (unique per try)
    $req = @{ id=$rpcId; method=$Method; params=$Params } | ConvertTo-Json -Compress -Depth 6
    $bytes = [Text.Encoding]::UTF8.GetBytes($req)
    [void]$udp.Send($bytes, $bytes.Length, $DeviceIP, $RemotePort)

    $deadline = [datetime]::UtcNow.AddMilliseconds($PerCallTimeoutMs * [math]::Pow(1.35, $try-1))
    $remote = [System.Net.IPEndPoint]::new([System.Net.IPAddress]::Any,0)

    while([datetime]::UtcNow -lt $deadline){
      try {
        $resp = $udp.Receive([ref]$remote)
        $txt  = [Text.Encoding]::UTF8.GetString($resp)
        $obj  = $txt | ConvertFrom-Json -ErrorAction SilentlyContinue
        
        if($obj -and $obj.id -eq $rpcId){
              if ($Method -eq "ES.GetMode") {
                  $modenu = $obj.result.mode
                  $bat_soc_str = $obj.result.bat_soc
                  $ongrid_power_str = $obj.result.ongrid_power
              }
          Start-Sleep -Milliseconds $InterCallDelayMs
          return $Method, $modenu, $bat_soc_str, $ongrid_power_str
        }
        # ignore late/unrelated frames and keep waiting
      } catch {
        # slice timeout; keep looping until overall deadline
      }
    }
    Start-Sleep -Milliseconds (100 + (Get-Random -Minimum 0 -Maximum 80))
  }
  Write-Host ("<= [--] {0}  -- timeout after {1} ms x{2}`n" -f $Method,$PerCallTimeoutMs,$MaxRetries)
  Write-Output ("<= [--] $Method --timeout after $PerCallTimeoutMs ms x $MaxRetries retries") >> .\avzetMODEdynamischOutput.txt 
  Start-Sleep -Milliseconds $InterCallDelayMs
}
##===============================================================================================
##HOOFDPROGRAMMA
## Globale logica flow:
## -1- warm batterij api op door een dummy call (getdevice) te doen
## -2- bepaal huidige mode, huidige soc en huidige power
## -3- afhankelijk van of het huidige uur voormiddag of namiddag is bepaal in die 12 uur het moment van het vroegste uur met het hoogste tarief in die 12 uur
##     beginnend vanaf het nu t/m 11 resp. nu t/m 23
## -4- afhankelijk van of het huidige uur voormiddag of namiddag is bepaal in die 12 uur het moment van het laatste uur met het laagste tarief in die 12 uur 
##     beginnend vanaf nu t/m 11 resp. nu t/m 23 tot maximaal het uur waarin het maximum tarief wordt bereikt in dat 12 uurs-bestek
## -5- bepaal het laagste tariefuur van de gehele dag (t.b.v. eventueel latere sturing op negatieve tarieven
## -6- bepaal of het financieel aantrekkelijk is om de batterij-Soc hoger te laden zodat hij 1 of 2 uur langer dan het max-uur nog stroom heeft.
## -7- bepalen te verwachten PV-opbrengst op basis zonne-wattage de komende uren en het benodigde wattage om 
##     vanaf nu tot en met het max-uur te geraken(eventueel verlengt met 1 of 2 extra uren als dat financieel aantrekkelijk is)
## -6- bepaal tot welke soc waarde minimaal geladen moet worden wanneer er besloten is in dit programma dat de batterij geladen wordt
##     namiddags wordt dit 98%, zodat je zo ver mogelijk de nacht in kunt komen; 
##     voormiddags wordt dit % berekend zodanig dat de batterij op basis van $BijlaadRekenhoeveelheidPerUur Watt leveren tot 2 uur na het voormiddag-maximumtarief nog kan ontladen
## -7- afhankelijk van voormiddag of namiddag inschatten wat de soc-waarde zou moeten zijn om over het dichts-bijzijnde maximum-tarief heen te geraken vanaf uur nu rekening
##     rekening houdend met het geschatte uurverbruik tot max-uur (of maxuur + 1 of 2 uur)
## -8- wanneer er op basis van de huidige soc en te verwachten PV-opbrengst geen energietekort te verwachten is tot max-uur dan socwaarde-laden-int laag zetten zodat er niet wordt geladen
## -9- wanneer er energietekort is om over het max-uur heen te geraken nog bepalen of het huidig tarief (rekening houdend met RTE-verlies) financieel aantrekkelijk is om bij te laden
##     waarbij het omgerekende huidige tarief wordt vergeleken met het gemiddelde-bruto-tarief van max-uur en de uren vooraf aan maxuur die qua soc aangevuld moeten worden.
##-10- bepaal of er geladen moet worden; 
##     a) Als op het huidige uur de gewenste soc lager is dan de huidige soc, dan maximaal bijladen gedurende dit kwartier totdat
##        de stop-laad-waarde waarop hij weer naar Auto gaat wordt bereikt (tarief moet wel lonen t.o.v. omzetverlies plus een opslagbedrag)
##     b) Als soc >= $socwaarde_stopladen_int en modus is niet Auto dan op Auto zetten; anders blijven doorladen en de modus niet veranderen.
##     c) 1x per week op zondagnamiddag gedurende de wintermaanden (okt t/m feb) op goedkoopste uur tot 100% laden (als hij niet al 100% is)
##     d) in de zomer als veel zon verwacht (misschien zelfs negatieve prijzen) dan tot dat (lage/negatieve) moment ontladen en op dat lage/negatieve uur vol laden
##     e) in de zomer als veel zon is geladen met zonnestroom (misschien zelfs negatieve prijzen) dan bij erg hoge prijzen juist verkopen op die max-uren 
##        (kan alleen bij saldering omdat je na einde salderingsregeling de belastingen niet meer terug krijgt en dan die wel zou moeten betalen later op de dag als je weer stroom nodig hebt)
##     f) in de ochtend wanneer het maxuur van die 12 uur nog moet komen kijken of je voldoende soc hebt om 1 uur over dat maxuur te geraken. Als het min-uur nog moet komen en dat ook financieel niet
##        rendabel is kun je de batterij een tijd in passive zetten, zodat je in de ochtend toch nog genoeg over hebt voor het maxuur en het daarop volgende uur.
##
# Warm-up (often helps)
$resultaat = Send-And-Wait "Marstek.GetDevice" @{ ble_mac = "0" }

# Ophalen mode, soc en huidige power
$resultaat = Send-And-Wait "ES.GetMode" @{id=0} 

if ($resultaat[0] -eq "ES.GetMode") {
   $modenu_str = $resultaat[1]
   $bat_soc_int = [int]$resultaat[2]
   $ongrid_power_int = [int]$resultaat[3]
}

$huidigemaand_int = (Get-Date).Month
$huidiguur_int = (Get-Date).Hour
if ($huidiguur_int -gt 11) {
   $maxzoekuur_int = 23
   $minzoekuur_int = 12
   $BijlaadHoeveelheidPerUur_int = $BijlaadRekenhoeveelheidPerUur_NM_int
}else{
   $maxzoekuur_int = 11
   $minzoekuur_int = 0
   $BijlaadHoeveelheidPerUur_int = $BijlaadRekenhoeveelheidPerUur_VM_int
}

$TarievenVandaag = [IO.File]::ReadAllText(".\dagtarief.txt")
$TarievenVandaag_obj = $TarievenVandaag | ConvertFrom-Json ## -ErrorAction SilentlyContinue

## bepaal het vroegste max-tarief en bijbehorende max-uur (tussen 0-11 uur resp. 12-23 uur)
foreach ($Tarief_obj in $TarievenVandaag_obj) {
    $dag = [datetime](Get-Date $Tarief_obj[0].datum_nl -f "yyyy-MM-dd HH:mm:ss")
    if (($dag.Hour -le $maxzoekuur_int) -and ($dag.Hour -ge $minzoekuur_int)) {
       if ([double]$Tarief_obj[0].prijs_excl_belastingen -gt $maxtarief_double) {
          $maxtarief_double = [double]$Tarief_obj[0].prijs_excl_belastingen
          $maxuur_int = $dag.Hour
       }
    }
}
## bepaal het laatste min-tarief en bijbehorende min-uur (tussen Nu-11 uur resp. Nu-23 uur en max-uur binnen dit nu-to-12 uurs-bestek)
$maxzoekuur_int = $maxuur_int
foreach ($Tarief_obj in $TarievenVandaag_obj) {
    $dag = [datetime](Get-Date $Tarief_obj[0].datum_nl -f "yyyy-MM-dd HH:mm:ss")
    if (($dag.Hour -le $maxzoekuur_int) -and ($dag.Hour -ge $huidiguur_int)) {
       if ([double]$Tarief_obj[0].prijs_excl_belastingen -le $mintarief_double) {
          $mintarief_double = [double]$Tarief_obj[0].prijs_excl_belastingen
          $minuur_int = $dag.Hour
       }
    }
}
##Als het uur dat ligt vooraf aan het laatste minimum-tarief, dan kan het minimum-uur op dat voorliggende uur worden gezet, waardoor en meer tijd is om de batterij vol te krijgen
##mocht dat nodig zijn (omdat de soc onder de 50 ligt).
if ($minuur_int -ne 0 -and $minuur_int -ne 12 ) {
   $tariefuur_double = Bepaal_Tarief_Op_Uur ($minuur_int - 1)
   if (($tariefuur_double -eq $mintarief_double) -and ($bat_soc_int -lt 50)) {
      $minuur_int = $minuur_int - 1
   }
}
#zoek het laatste meest negatieve uur vanaf uur 0 tot einde dag
$maxzoekuur_int = 23
$minzoekuur_int = 0
foreach ($Tarief_obj in $TarievenVandaag_obj) {
    $dag = [datetime](Get-Date $Tarief_obj[0].datum_nl -f "yyyy-MM-dd HH:mm:ss")
    if (($dag.Hour -le $maxzoekuur_int) -and ($dag.Hour -ge $minzoekuur_int)) {
       if ([double]$Tarief_obj[0].prijs_excl_belastingen -le $minnegatieftarief_double -and [double]$Tarief_obj[0].prijs_excl_belastingen -lt 0) {
          $minnegatieftarief_double = [double]$Tarief_obj[0].prijs_excl_belastingen
          $minnegatiefuur_int = $dag.Hour
       }
    }
}
##bepaal of het financieel aantrekkelijk is om de batterij-Soc hoger te laden zodat hij 1 of 2 uur langer dan het max-uur nog stroom heeft.
$brutotariefmaxuur_double = Bepaal_Gem_BrutoTarief_Van_Tm_Uur $maxuur_int $maxuur_int
$brutotariefhuidiguur_omgerekend_verlies_double = Bepaal_Gem_BrutoTarief_Van_Tm_Uur $huidiguur_int $huidiguur_int
$brutotariefhuidiguur_omgerekend_verlies_double = ($brutotariefhuidiguur_omgerekend_verlies_double / $ACDCAComzettnigverlies_double) + $opslagbedragNetLaden_double
$nettohuidigtarief_double = Bepaal_Tarief_Op_Uur($huidiguur_int)
if ($maxuur_int -ne 11 -and $maxuur_int -ne 23) {
   $brutotariefmaxuur_plus_1_double = Bepaal_Gem_BrutoTarief_Van_Tm_Uur($maxuur_int + 1)($maxuur_int + 1)
   if ($maxuur_int -ne 10 -and $maxuur_int -ne 22) {
      $brutotariefmaxuur_plus_2_double = Bepaal_Gem_BrutoTarief_Van_Tm_Uur($maxuur_int + 2) ($maxuur_int + 2)
   }
}
if ($brutotariefmaxuur_plus_1_double -gt $brutotariefhuidiguur_omgerekend_verlies_double) {
    $uren_langer_maxuur_int = 1
    if ($brutotariefmaxuur_plus_2_double -gt $brutotariefhuidiguur_omgerekend_verlies_double) {
        $uren_langer_maxuur_int = 2
    }
}
##bepalen te verwachten PV-opbrengst op basis zonne-wattage de komende uren en het benodigde wattage om 
##vanaf nu tot en met het max-uur te geraken(eventueel verlengt met 1 of 2 extra uren als dat financieel aantrekkelijk is)
$zon_som_waarde_van_nu_tm_einde_dag_int = Bepaal_ZonWattage_van_tm_Uur $huidiguur_int 23
$zon_som_waarde_van_nu_tot_nabijste_maxuur_int = Bepaal_ZonWattage_van_tm_Uur $huidiguur_int ($maxuur_int - 1)
$te_verwachten_PV_opbrengst_vanNu_totMaxuur_int = [int]($ervaringscijfer_kWh_per_zonwaarde * $zon_som_waarde_van_nu_tot_nabijste_maxuur_int) * ($opp_pv_hoogdak_double + $opp_pv_laagdak_double + $opp_pv_tuinhuis_double)
$benodigde_Energie_vanNu_tot_en_met_Maxuur_int = [int]($maxuur_int - $huidiguur_int + $uren_langer_maxuur_int) * $BijlaadHoeveelheidPerUur_int

$energietekort_int = [int]($benodigde_Energie_vanNu_tot_en_met_Maxuur_int - $te_verwachten_PV_opbrengst_vanNu_totMaxuur_int - (($bat_soc_int - 11) / 100 * $capaciteit_batterij_int))
##afhankelijk van voormiddag of namiddag inschatten wat de soc-waarde zou moeten zijn om over het dichts-bijzijnde maximum-tarief heen te geraken vanaf uur nu
##rekening houdend met het geschatte uurverbruik tot max-uur (of maxuur + 1 of 2 uur)

$socwaarde_stopladen_int = (11 + ((($maxuur_int + $uren_langer_maxuur_int - $huidiguur_int) * $BijlaadHoeveelheidPerUur_int) / $capaciteit_batterij_int ) * 100)
$Benodigde_Soc_voor_3_uur_int = (15 + ((3 * $BijlaadHoeveelheidPerUur_int) / $capaciteit_batterij_int ) * 100)
if ($socwaarde_stopladen_int -gt 100) {
  $socwaarde_stopladen_int = 100
}
##wanneer er op basis van de huidige soc en te verwachten PV-opbrengst geen energietekort te verwachten is tot max-uur dan socwaarde-laden-int laag zetten zodat er niet wordt geladen
if ($energietekort_int -lt 0) { ##als het energietekort negatief is (er is nog voldoende pv-opbrengst te verwachten incl. huidige staat bat) dan niet bijladen
   $socwaarde_stopladen_int = 10
}else{
     if ($huidiguur_int -lt $maxuur_int) {
        ##er is energietekort om over het max-uur heen te geraken; nu nog bepalen of het huidig tarief (rekening houdend met RTE-verlies) financieel aantrekkelijk is om bij te laden
        $bijlaadSoc_int = $socwaarde_stopladen_int - $bat_soc_int
        $bijlaadduur_int = [int][math]::ceiling(($bijlaadSoc_int / 100 * $capaciteit_batterij_int) / $max_laadcapaciteit_int_int)
        $gemiddeld_brutotarief_additionele_bijlaaduren_double = Bepaal_Gem_BrutoTarief_Van_Tm_Uur ($maxuur_int - $bijlaadduur_int) ($maxuur_int)
        if ($gemiddeld_brutotarief_additionele_bijlaaduren_double -le $brutotariefhuidiguur_omgerekend_verlies_double) { ## financieel niet aantrekkelijk om bij te laden dus socwaarde_stopladen_int laag zetten
           $socwaarde_stopladen_int = 9
           ## het maxuur moet nog komen en er is een energietekort om alle tussenliggende uren tot maxuur te overbruggen en het is financieel niet interessant om bij te laden;
           ## Is het dan misschien mode passive nog een optie wanneer er voldoende soc is op basis van huidig geschat uurverbruik om het duurste uur en de 2 eromheen liggende uren 
           ## nog met batterijstroom te voorzien?
           if ($bat_soc_int -le $Benodigde_Soc_voor_3_uur_int) {
              $mode_Go_Passive_str = "J"
           }
        }
     }else{ ## in de namiddag is het maxuur reeds verstreken; dan kijken of er voldoende soc is om middels mode passive op basis van huidig geschat uurverbruik om 
            ## het duurste uur en de 2 eromheen liggende uren nog met batterijstroom te voorzien?
            if ($huidiguur_int -ge 12 -and $bat_soc_int -le $Benodigde_Soc_voor_3_uur_int) {
              $mode_Go_Passive_str = "J"
            }
     }
}
Write-Host ("av9a: minuur {0}h/ mintar Eur.{1}/ maxuur {2}h/ maxtar Eur.{3}/ minnegatiefuur {4}h/ minnegatieftar Eur.{5}/ maand {6} mnd/ uur {7}h/ huidigtarief Eur.{8}/ maxbrutotar Eur.{9}" -f $minuur_int,$mintarief_double,$maxuur_int,$maxtarief_double, $minnegatiefuur_int, $minnegatieftarief_double, $huidigemaand_int, $huidiguur_int, $nettohuidigtarief_double, $brutotariefmaxuur_double)
Write-Host ("av9b: mode {0}/ soc {1}%/ soc-stop {2}%/ power {3}W/ kWh-need-tot-maxuur {4}W/ PV-tot-maxuur {5}W/ zonwaarde {6}W/m2/ zonwaarde-tot-max {7}W/m2/ Energietekort {8}W/ huidigtar-omgerekend Eur.{9}" -f $modenu_str,$bat_soc_int,$socwaarde_stopladen_int,$ongrid_power_int,$benodigde_Energie_vanNu_tot_en_met_Maxuur_int , $te_verwachten_PV_opbrengst_vanNu_totMaxuur_int, $zon_som_waarde_van_nu_tm_einde_dag_int, $zon_som_waarde_van_nu_tot_nabijste_maxuur_int, $energietekort_int, $brutotariefhuidiguur_omgerekend_verlies_double)
Write-Host ("av9c: uren-langer-max {0}h/ gem-brutotarief-addit-bijlaad Eur.{1}" -f $uren_langer_maxuur_int, $gemiddeld_brutotarief_additionele_bijlaaduren_double)
Write-Output ("--> Mode/Soc/Soc-Stop/Pow/Mnd/uur/kWh-need-tot-maxuur/PV-tot-maxuur/huidigtarief`t$modenu_str`t/$bat_soc_int %`t/$socwaarde_stopladen_int %`t/$ongrid_power_int W`t/$huidigemaand_int mnd`t/$huidiguur_int h`t/$benodigde_Energie_vanNu_tot_en_met_Maxuur_int W`t/$te_verwachten_PV_opbrengst_vanNu_totMaxuur_int W`t/Eur. $nettohuidigtarief_double") >> .\avzetMODEdynamischOutput.txt 
Write-Output ("--> Min/Max/Zon/Zon-tot-maxuur/Energietekort/Minnegatief`t`t`t`t`t`t`t$minuur_int h `t/Eur. $mintarief_double`t/$maxuur_int h`t/Eur. $maxtarief_double`t/$zon_som_waarde_van_nu_tm_einde_dag_int W/m2`t/$zon_som_waarde_van_nu_tot_nabijste_maxuur_int W/m2`t/$energietekort_int W`t/$minnegatiefuur_int h`t/Eur. $minnegatieftarief_double ") >> .\avzetMODEdynamischOutput.txt 
Write-Output ("--> Uren-langer-Max/gem-brutotarief-addit-bijlaad/huidigtar-omgerekend/maxbrutotar`t$uren_langer_maxuur_int h`t`t/Eur. $gemiddeld_brutotarief_additionele_bijlaaduren_double`t/Eur. $brutotariefhuidiguur_omgerekend_verlies_double`t/Eur. $brutotariefmaxuur_double") >> .\avzetMODEdynamischOutput.txt 
##
## Bepalen of er van mode gewisseld moet worden. No-brainer use-cases het eerst geimplementeerd:
## vanaf hier zijn bekend: $modenu_str, $bat_soc_int, $socwaarde_stopladen_int, $ongrid_power_int, $huidigemaand_int, $huidiguur_int, 
##                         $minnegatieftarief_double, $minnegatiefuur_int, $maxtarief_double, $maxuur_int, $minuur_int, $mintarief_double
##                         $te_verwachten_PV_opbrengst_vanNu_totMaxuur_int, $zon_som_waarde_van_nu_tm_einde_dag_int, $zon_som_waarde_van_nu_tot_nabijste_maxuur_int, 

## No-brainer-a: Als het uur van maximaal tarief nog moet komen binnen 12 uur en er is nu een tarief dat bijladen aantrekkelijk maakt en bijladen is nodig om over max-tarief te geraken dan maximaal bijladen dit kwartier tot
## de stop-laad-waarde waarop hij weer naar Auto gaat; Verschil tussen de bruto prijzen op die uren moet de AC/DC/AC-omzetting compenseren plus omzetverliesopslag cent
if ($bat_soc_int -lt $socwaarde_stopladen_int) {
   $modenieuw_str = "Manual laden $max_laadcapaciteit_int"
   $modegezet_str = "J"
   Write-Host ("Tijd: {0} Mode van: {1} --> {2}" -f $tijdstempel_str, $modenu_str, $modenieuw_str)
   Write-Output ("Tijd: $tijdstempel_str                                                           Mode van $modenu_str --> $modenieuw_str") >> .\avzetMODEdynamischOutput.txt ##-Append
   if ($bijladen_gedurende_huidig_contract -eq "J") {
       $resultaat = Send-And-Wait "ES.SetMode" @{id=1; config = @{id=1; mode= "Manual"; manual_cfg= @{time_num=1;start_time="00:00";end_time="23:59";week_set=127;power=-2500;enable=1}}}
   }
}
## No-brainer-c: 1x per week op zondagnamiddag gedurende de wintermaanden (okt t/m feb) op goedkoopste uur tot 100% laden (als hij niet al 100% is)
## Prijs is hierbij niet meer van toepassing
if (((get-date).DayOfWeek -eq "Sunday") -and
    ($huidigemaand_int -ge 10 -or $huidigemaand_int -le 2) -and  
    ($modenu_str -ne "Manual") -and ($minuur_int -eq $huidiguur_int) -and ($bat_soc_int -lt 100) -and ($huidiguur_int -ge 12)) {
   $socwaarde_stopladen_int = 100
   $modenieuw_str = "Manual laden $max_laadcapaciteit_int (1xper week 100%)"
   $modegezet_str = "J"
   Write-Host ("Tijd: {0} Mode van: {1} --> {2}" -f $tijdstempel_str, $modenu_str, $modenieuw_str)
   Write-Output ("Tijd: $tijdstempel_str                                                           Mode van $modenu_str --> $modenieuw_str") >> .\avzetMODEdynamischOutput.txt ##-Append
   if ($bijladen_gedurende_huidig_contract -eq "J") {
       $resultaat = Send-And-Wait "ES.SetMode" @{id=1; config = @{id=1; mode= "Manual"; manual_cfg= @{time_num=1;start_time="00:00";end_time="23:59";week_set=127;power=-2500;enable=1}}}
   }
}
## No-Brainer-d: in de zomer als veel zon wordt verwacht (misschien zelfs negatieve prijzen) dan tot dat (lage/negatieve) moment ontladen en op dat lage/negatieve uur vol laden
## nog te implementeren TODO

## No-Brainer-e: in de zomer als veel zon is geladen met zonnestroom (misschien zelfs negatieve prijzen) dan bij erg hoge prijzen juist verkopen op die max-uren.
## nog te implementeren TODO

## No-Brainer-f: indien mode_Go_Passive_str = J dan naar mode passive switchen.
if ($mode_Go_Passive_str -eq "J") {
   $modenieuw_str = "Passive"
   $modegezet_str = "J"
   Write-Host ("Tijd: {0} Mode van: {1} --> {2}" -f $tijdstempel_str, $modenu_str, $modenieuw_str)
   Write-Output ("Tijd: $tijdstempel_str                                                           Mode van $modenu_str --> $modenieuw_str") >> .\avzetMODEdynamischOutput.txt
   if ($bijladen_gedurende_huidig_contract -eq "J") {
      $resultaat = Send-And-Wait "ES.SetMode" @{id=1; config = @{id=1; mode= "Passive"; passive_cfg= @{power=100;cd_time=3}}}
   }
}  
## No-brainer-b: Als soc >= $socwaarde_stopladen_int en modus is niet Auto dan op Auto zetten
if (($modenu_str -ne "Auto") -and ($bat_soc_int -ge $socwaarde_stopladen_int)) {
   $modenieuw_str = "Auto"
   $modegezet_str = "J"
   Write-Host ("Tijd: {0} Mode van: {1} --> {2}" -f $tijdstempel_str, $modenu_str, $modenieuw_str)
   Write-Output ("Tijd: $tijdstempel_str                                                           Mode van $modenu_str --> $modenieuw_str") >> .\avzetMODEdynamischOutput.txt ##-Append
   $resultaat = Send-And-Wait "ES.SetMode" @{id=1; config = @{id=1; mode= "Auto"; auto_cfg= @{enable=1}}}
}  

if ($modegezet_str -eq "N") {
   $modenieuw_str = $modenu_str
   Write-Host ("Tijd: {0} Mode niet gezet; blijft {1}" -f $tijdstempel_str, $modenu_str)
   Write-Output ("Tijd: $tijdstempel_str                                                           Mode niet gezet; blijft $modenu_str") >> .\avzetMODEdynamischOutput.txt ##-Append
}
##===============================================================================================
# Optional: drain late packets
$remote = [System.Net.IPEndPoint]::new([System.Net.IPAddress]::Any,0)
$until = [datetime]::UtcNow.AddMilliseconds(5000)
while([datetime]::UtcNow -lt $until){
  try {
    $txt = [Text.Encoding]::UTF8.GetString($udp.Receive([ref]$remote))
    Write-Host ("<= [late] {0}:{1}`n{2}`n" -f $remote.Address,$remote.Port,$txt)
    Write-Output ("<= [late] $remote.Address : $remote.Port /$txt") >> .\avzetMODEdynamischOutput.txt 
  } catch {}
}
$udp.Close()

=====

[ Voor 10% gewijzigd door antoinevromen op 22-09-2025 12:27 ]

[AUijtdehaag]

@antoinevromen
Misschien een tip:
Zet het tussen code tags en quote tags, om het leesbaar en duimvriendelijker te maken.

[antoinevromen]

AUijtdehaag schreef op zondag 21 september 2025 @ 18:08:
@antoinevromen
Misschien een tip:
Zet het tussen code tags en quote tags, om het leesbaar en duimvriendelijker te maken.

Geweldig @AUijtdehaag ; Ik wist eerst niet waar je het over had, maar na even zoeken snapte ik dat dit ook kon;

[SatScan]

antoinevromen schreef op zondag 21 september 2025 @ 18:50:
[...]

Geweldig @AUijtdehaag ; Ik wist eerst niet waar je het over had, maar na even zoeken snapte ik dat dit ook kon;

Stukken beter!
Dank!

[antoinevromen]

SatScan schreef op zondag 21 september 2025 @ 18:53:
[...]


Stukken beter!
Dank!

@AUijtdehaag Wat je bedoelt met quote-tags is me nog steeds niet duidelijk; Ik heb ermee geexperimenteerd, maar dan wordt het tekstgebied alleen maar kleiner. Wat bedoelde je daarmee (meer ter lering)?

[SatScan]

antoinevromen schreef op zondag 21 september 2025 @ 18:55:
[...]

@AUijtdehaag Wat je bedoelt met quote-tags is me nog steeds niet duidelijk; Ik heb ermee geexperimenteerd, maar dan wordt het tekstgebied alleen maar kleiner. Wat bedoelde je daarmee (meer ter lering)?

Prima zo, als we vragen hebben kunnen we naar regelnummer verwijzen en knip en plak is ook handiger.

[AUijtdehaag]

@antoinevromen
Als je buiten de code tags nog quote tags plaatst dan worden de velden inderdaad ingeklapt (en kunnen uitgeklapt worden) en zo verklein je de post.
Scheelt weer scrollen op een mobiel

[ Voor 7% gewijzigd door AUijtdehaag op 21-09-2025 18:59 ]

[antoinevromen]

AUijtdehaag schreef op zondag 21 september 2025 @ 18:58:
@antoinevromen
Als je buiten de code tags nog quote tags plaatst dan worden de velden inderdaad ingeklapt (en kunnen uitgeklapt worden) en zo verklein je de post.
Scheelt weer scrollen op een mobiel

Oke. Helder; ga ik nog aanpassen

[antoinevromen]

AUijtdehaag schreef op zondag 21 september 2025 @ 18:58:
@antoinevromen
Als je buiten de code tags nog quote tags plaatst dan worden de velden inderdaad ingeklapt (en kunnen uitgeklapt worden) en zo verklein je de post.
Scheelt weer scrollen op een mobiel

Dank je voor de tip. Heeft een code-dinosaurus weer wat bijgeleerd dat mensen op telefoons zoiets bekijken
Maar het is wel een heel stuk beter met dat inklappen en die regelnummers.

[djdj105]

Hometek schreef op zaterdag 20 september 2025 @ 22:15:
[...]

Ik ben met iets soortgelijks bezig in Node-RED.

[....]
Over een week of twee zal ik wat meer details delen.

Ben zeer geintersseerd hierin. Volg met belangstelling.

[djdj105]

antoinevromen schreef op zondag 21 september 2025 @ 18:50:
[...]

Geweldig @AUijtdehaag ; Ik wist eerst niet waar je het over had, maar na even zoeken snapte ik dat dit ook kon;

Mooi stukje werk @antoinevromen, al snap ik geen snars van PowerShell.
Misschien een idee een github account te maken (als je die nog niet hebt) en het project / je code daar op te plaatsen, dan is het ook terug te vinden en voor revisies is dat ook heel handig.

[antoinevromen]

djdj105 schreef op zondag 21 september 2025 @ 19:17:
[...]


Mooi stukje werk @antoinevromen, al snap ik geen snars van PowerShell.
Misschien een idee een github account te maken (als je die nog niet hebt) en het project / je code daar op te plaatsen, dan is het ook terug te vinden en voor revisies is dat ook heel handig.

@djdj105 Dank je. Tot een week geleden wist ik ook niets van PowerShell, maar ik heb wel een historie van 30+ jaar in de ICT (en programmeren is zoals fietsen, dat verleer je niet).
Ik heb wel een github account, maar ik wil het niet echt als product gaan onderhouden/promoten. Voor mensen die er wel handig in zijn, die kunnen dit als een soort jump-start gebruiken hoe je de batterij aanroept en hoe je een aantal basale basisgegevens zoals prijzen/zon-voorspelling/batterijstatus etc. kunt inzetten bij het sturen van de batterij.
Ik vond dit met name een handig tool omdat je geen extra hardware/software (zoals bijv home-assistant) nodig hebt en alles via de local-api gaat, die Marstek promoot. In het "hoofd-forum" over Marstek Venus E was al sprake ervan dat Marstek de modbus niet meer zou supporten, en mqtt wordt ook steeds lastiger gemaakt door Marstek waardoor integratie met home-assistant straks waarschijnlijk ook niet meer werkt.
Waarschijnlijk omdat je middels mqtt daarmee load op hun eigen servers in China gaat creeeren en over local-mqtt hoor je helemaal niets meer na de local-api.

[tvh23]

Dank @antoinevromen ik heb het hier werkend gekregen, mijn usecase is om te signaleren dat de verbinding tussen te CT en de batterij lang eruit ligt dat Nom niet werkt of dat de EV gestopt is met laden, dus met name verstoringen / afwijkingen signaleren. Ik draai namelijk alleen nom aangezien ik de terugleverkosten van m'n vast contract wil verminderen. Als ik nog wat tijd over heb, zal ik hem omzetten naar Python zodat ik het op een raspberry kan draaien. M'n laptop heb ik namelijk alleen overdag aan (werk thuis) en de api werkt niet vanuit de cloud (gelukkig maar ;-)

[antoinevromen]

tvh23 schreef op maandag 22 september 2025 @ 22:26:
Dank @antoinevromen ik heb het hier werkend gekregen, mijn usecase is om te signaleren dat de verbinding tussen te CT en de batterij lang eruit ligt dat Nom niet werkt of dat de EV gestopt is met laden, dus met name verstoringen / afwijkingen signaleren. Ik draai namelijk alleen nom aangezien ik de terugleverkosten van m'n vast contract wil verminderen. Als ik nog wat tijd over heb, zal ik hem omzetten naar Python zodat ik het op een raspberry kan draaien. M'n laptop heb ik namelijk alleen overdag aan (werk thuis) en de api werkt niet vanuit de cloud (gelukkig maar ;-)

@tvh23 Mooi te lezen dat je er wat aan hebt. Zo kan iedereen op basis van deze voorbeelden het zelf tot maatwerk maken omdat bijna alle aspecten van de sturing in de scripts zitten.
Ik heb in het verleden ook met een raspberry PI gewerkt, maar die is kapot. Maar als je e.e.a. in Python werkend hebt schroom niet het hier te posten.

Gr. Antoine Vromen

[PNARI]

Ik ga vanaf 1 november tot 28 februari over op een dynamisch contract. De 2 batterijen over op AI. De boiler krijgt met de energysocket een dynamische taak van 21u tot 9u. Deze tijdsblok moet misschien wat aangepast worden in de loop van de winter om te voorkomen dat de batterijen en boiler samen laden om de captar niet uit de hand te laten lopen. Zou ook nog willen dat de batterijen in 2 tijdsblokken de laagste 2 uur laden om zo 18kWh capaciteit ter beschikking te hebben. Is dat te doen met HA via de modbus ?

[matramurena]

antoinevromen schreef op zondag 21 september 2025 @ 16:47:
[...]

DEEL1
Beste Tweakers (o.a. @GoBieN-Be @HiHaHors),
Zoals eerder geschreven hier alvast wat scripts om de batterij middels local-api te sturen.

Wow, bedankt! Ik heb nu de local API aan de praat (via Bluetooth) en heb met behulp van deze Powershell scripts ook aantoonbaar de Marstek kunnen aansturen, in de app heb ik kunnen zien dat van Self Consumption naar AI optimized geschakeld en terug, toen ik die commando's zag. Nu moet ik maar eens een Python script gaan maken zodat Domoticz hiermee overweg kan en ik niet telkens op app van Marstek hoef te kijken. Stapje verder en ik kan de batterij echt gaan aansturen. CT002 uitlezen schijnt ook al te kunnen heb ik begrepen uit de HA integratie.

[antoinevromen]

matramurena schreef op donderdag 25 september 2025 @ 12:47:
[...]

Wow, bedankt! Ik heb nu de local API aan de praat (via Bluetooth) en heb met behulp van deze Powershell scripts ook aantoonbaar de Marstek kunnen aansturen, in de app heb ik kunnen zien dat van Self Consumption naar AI optimized geschakeld en terug, toen ik die commando's zag. Nu moet ik maar eens een Python script gaan maken zodat Domoticz hiermee overweg kan en ik niet telkens op app van Marstek hoef te kijken. Stapje verder en ik kan de batterij echt gaan aansturen. CT002 uitlezen schijnt ook al te kunnen heb ik begrepen uit de HA integratie.

Hallo @matramurena , Fijn te lezen dat je iets hebt gehad aan mijn scripts. Het kunnen aansturen van de batterij is vereiste nr. 1 natuurlijk, maar ik ben zelf ook nog steeds de scripts aan het vervolmaken om meer logica erin te brengen m.b.t. de daadwerkelijk sturingslogica (dat is nog een heel apart hoofdstuk als je dat goed wilt doen). Vandaar ook dat deze oplossing zo mooi is dat iedereen dat wat hij/zij wil bereiken er zelf in kan programmeren.

[antoinevromen]

Beste medetweakers,
Onderstaand de uitgangspunten en strategiën die ik in mijn home-brew-automatisering van de Marstek Venus E heb ingebouwd op basis van de local-api.
Misschien heeft iemand nog aanvullende strategiën of kan ik iemand nog op een idee brengen met deze post.
Zo komen we misschien tot een lijst van mogelijke strategiën waaruit iedereen kan kiezen welke hij/zij zinvol vindt om te implementeren en welke niet.

Uitgangspunten:
-1 Sturing heeft betrekking op een batterij in Nederland (NL) bij een Dynamisch Contract
-2 Sturing vindt plaats 1 x per kwartier (niet teveel schakelen met de batterij en focus op macro-perspectief)
-3 De software heeft de beschikking over de dynamische tarieven van "vandaag" (wordt gedownload als json)
-4 De software heeft de beschikking over de voorspelde zonne-energie (W/m2) van het KNMI op een plek (woonplaats) "vandaag"; (wordt gedownload als json)
Hiervan is af te leiden hoeveel PV-stroom jouw installatie naar verwachting gaat opbrengen op de resterende uren van de dag (per uur)
-5 Bij het laden op Net-stroom wordt het laadtarief vergeleken met de gemiddelde tarieven van de uren waarvoor je gaat bijladen omdat je SOC daarvoor op het moment van laden te laag is.
Dit laadtarief is inclusief alle belastingen geteld en in verband met de RTE-verliezen wordt dit tarief door 0,8 gedeeld en verhoogd met een paar cent om
zichtbaar voordeel te hebben t.o.v. de tarieven waarvoor je middels Net-stroom aan het laden zou gaan als je geen SOC in de batterij zou hebben.
-6 Er is sprake van Maxtarief-uur bij 2 tariefmomenten op een dag (1 x voormiddag (0-11) en 1 x namiddag (12-23)), waarbij het maxtarief-uur ook het uur vooraf en het uur
volgend op het maxtarief-uur bevat (in totaal dus 3 uur om te overbruggen).

Strategiën geimplementeerd:
-1 Basis is NOM (=Zelf Consumptie) is actief als geen van de onderstaande strategiën actief is.
-2 Zomer-Passive (dit is bedoeld om overtollige PV-stroom niet te verkopen op de lagere/negatieve tarief-uren); Het betekent dat wanneer er voldoende zonne-stroom
wordt voorspeld je de batterij in de voormiddag niet laat opladen (maar de PV in de voormiddag laat terugleveren naar het net omdat het tarief dan hoger is dan bijv. in de namiddag)
In de namiddag ga je dan de batterij juist volladen om de laagste/negatieve uren te vermijden.
-3 Winter-Passive (dit is bedoeld om op enig moment te beslissen de batterij in Passive stand te zetten (=niet laden/niet ontladen) om zodoende voldoende SOC in de batterij te houden
om de eerstvolgende piek (maxtarief-uur) te overbruggen. Er moet dan voldoende SOC in de batterij zitten om 3 uur (het maxtarief-uur + 2 naastgelegen uren) te overbruggen.
-4 Strategisch bijladen van het Net (kijkend naar de huidige SOC vaststellen dat deze onvoldoende is om over het komende maxtarief-uur te geraken resp. onvoldoende is om zelfs bij
Passive gaan de 3 uur van Maxtarief-uur te overbruggen. Dan wordt gekeken of het met RTE-verlies verhoogde Net-tarief op het huidige uur opweegt tegen
de gemiddelde prijs inclusief belastingen van alle tussenliggende uren t/m maxuur + 1 of gemiddelde prijs inclusief belastingen van de 3 uur rondom het maxuur.
Als dit rendabel is (meestal zal dit op of rond het minimum-uur vooraf aan het maximum-uur zijn) ga je laden (Manual) totdat de gewenste SOC is bereikt en
anders blijf je op NOM staan omdat bijladen financieel niet loont en je toch nog elke Watt PV kunt meenemen die je PV opleveren ook al is dat niet voldoende om
dat aankomende dure max-uur te overbruggen.
-5 Gedurende de winter 1 x per week tot 100% vol laden op het goedkoopste uur (zodat de batterij niet wekenlang op 11% staat bij weinig PV)
-6 Monitoring status batterij (middels logging bij elke sturings-run)
===============================================================================
-7 Afgeleide strategie van -3 (wanneer de batterij in Winter-Passive is gegaan om SOC te sparen tot het maxtariefuur-1, dan wordt de batterij vanzelf op NOM (=Zelf Consumptie) gezet
wanneer het uur voorafgaand aan het maxtarief-uur is aangebroken.
-8 Afgeleide strategie van -2 (wanneer de batterij in Zomer-Passive is gegaan om pas bij het minimum-tariefuur te gaan laden, wordt de batterij vanzelf op NOM (=Zelf Consumptie) gezet
wanneer het minimum-tariefuur is aangebroken
-9 Afgeleide strategie van -4 (wanneer bij het bijladen Manual de gewenste SOC is bereikt wordt de batterij weer vanzelf op NOM (=Zelf Consumptie) gezet (n.b. het zou best kunnen dat
in het daaropvolgende kwartier een van de andere strategiën de batterij dan op Passive gaat zetten)

Strategiën NIET geimplementeerd:
-1 Minimalisatie van CAPTAR (valide strategie, maar specifiek voor België)
-2 Verkopen PV-stroom/Ingekochte-stroom van goedkope uren op Duurste uur/uren (valide strategie, maar volgens mij slechts nog zinvol gedurende de salderingsregeling)

Groeten Antoine Vromen

[olympusdenk]

Ik heb de volgende proof of concept op Github gezet en het plannen van manuele schema's in de Marstek app. Vanuit Home Assistant / in combinatie met Hame Relay:
https://github.com/pcvelz...e/feat/0-proof-of-concept

Deze HA package is gemaakt specifiek voor Venus-E 2.0 op dit moment en zet de batterij op manuele modus waarna de Marstek via de app wordt gevuld met tijdschema’s voor het laden in goedkope uren en ontladen in dure uren, en controle of het prijsverschil hoger is dan het verlies (RTE ligt rond de 75-80% tussen laden en ontladen). Ook rekening houdend met verschillende dagdelen, bijvoorbeeld als je zondagmiddag goedkoop geladen energie kan door de package gebruikt worden dag later op maandagochtend als die uren meer opleveren.



Als de spread goedkoopste uur en duurste uur minder verschil is dan 20% verlies die je hebt bij op- en ontladen de MT standby te zetten.

En, wanneer zoals vandaag de spread tussen goedkoopste uren en de duurste uren hoog genoeg ligt. Dan zoals je bijvoorbeeld hieronder kan zien is use case de MT schema's automatisch te laten laden op goedkoopste uren (12:00 - 15:00 tegen 24ct laden op 2500w + 20 extra minuten voor 99% => 100%) en ontladen on duurste uren (19:00 tegen 52ct op 2500w ontladen en 18:00 tegen 45ct op 2000w ontladen).



Deze HA package heeft zoals je kunt zien in dit voorbeeld hierboven voor vandaag de meest goedkoopste uren gepakt van 12 - 15:00 (+20 minuten tijd buffer voor 99% => 100% laden) en heeft duurste uren vanavond 18:00 - 20:00 om stroom op hoogste tarief uit de batterij te leveren.




Het resultaat wat ik wou bereiken is op het goedkoopste moment laden en duurste moment ontladen, afhankelijk van of er genoeg prijsverschil is laat ik dit met deze HA package tussen de 1 á 2x per dag inplannen:

[ Voor 79% gewijzigd door olympusdenk op 30-09-2025 19:38 ]

[olympusdenk]

Dit vereist nog wel wat installatiewerk binnen HA. Ik ben vooral voor de Hame Relay implementatie weg ingeslagen omdat het voordeel mij leek dat de app ook nog werkend blijft. Het voordeel is ook dat het aansluit binnen HA (qua koppeling met andere automatisering, dashboards etc).
Hoewel @antoinevromen wellicht is dit een interessante om te bekijken en de business logic te vergelijken met powershell script.

[antoinevromen]

olympusdenk schreef op dinsdag 30 september 2025 @ 12:45:
Ook even cross-post:

[...]

Hallo @olympusdenk ,
Goed te lezen dat je ook een batterij-sturings-project gestart bent.

Je schrijft "Ik ben vooral voor de Hame Relay implementatie weg ingeslagen omdat het voordeel mij leek dat de app ook nog werkend blijft. " ; Wanneer werkt de app dan niet meer, dat jij de Hame Relay weg bent ingeslagen, want middels local-api werkt ook de app gewoon? Je weet toch dat Marstek er van alles aan probeert te doen om de werking van Hame Relay en HM2MQTT onmogelijk te maken? (was laatst bij versie V154 al het geval toen ze encryptie in de MQTT-berichten hadden gestopt om gebruik door derden van de Marstek-MQTT-servers (in Europa/China) te voorkomen.

Je schrijft ook dat het misschien interessant is om de business-logic van jou te vergelijken met wat ik in powershell-scripts heb gestopt. Heb je die business-logic ook ergens in een beetje functionele beschrijving staan, zodat ik niet door Home-Assistant-code moet gaan spitten?

[olympusdenk]

antoinevromen schreef op dinsdag 30 september 2025 @ 15:44:
[...]

Hallo @olympusdenk ,
Goed te lezen dat je ook een batterij-sturings-project gestart bent.

Je schrijft "Ik ben vooral voor de Hame Relay implementatie weg ingeslagen omdat het voordeel mij leek dat de app ook nog werkend blijft. " ; Wanneer werkt de app dan niet meer, dat jij de Hame Relay weg bent ingeslagen, want middels local-api werkt ook de app gewoon? Je weet toch dat Marstek er van alles aan probeert te doen om de werking van Hame Relay en HM2MQTT onmogelijk te maken?

Dat klopt, ik volg de ontwikkelingen met Hame Relay op de voet en met v154 werkt op dit moment de HA integratie. Het klopt ook dat MT er alles aan doet (alhoewel ze daar nog wel lachwekkend tekort schieten), ik heb er al wel mee rekening gehouden en de aansturing code apart gehouden van de planning logica. Op dit moment is nog niet bij iedereen de local-API actief, maar het zeker reeel dat meer final versie met local API ga doen als vervanging van deze voor nu deze proof of concept nog tegen Hame Relay

(was laatst bij versie V154 al het geval toen ze encryptie in de MQTT-berichten hadden gestopt om gebruik door derden van de Marstek-MQTT-servers (in Europa/China) te voorkomen.

Ik had ook al de pech hier pas na de firmware upgrade naar v154 achter te komen, de ontwikkelaar heeft gelukkig wel al een werkende versie in de pijplijn deze heb ik momenteel lokaal werkend met v154

Edit link toegevoegd: https://github.com/tomqui...4#issuecomment-3300383403

“ @tomquist 2 weeks ago
A test build is now available. It can be installed in Home Assistant via this repository URL:

https://github.com/tomquist/hame-relay#support-vid
I would specifically be interested if this fixes issues for anyone using a Jupiter with >=v136 or B2500 HMJ with >=v116 or HMB/HMA/HMK/HMF with >= v230 so please provide feedback”

Je schrijft ook dat het misschien interessant is om de business-logic van jou te vergelijken met wat ik in powershell-scripts heb gestopt. Heb je die business-logic ook ergens in een beetje functionele beschrijving staan, zodat ik niet door Home-Assistant-code moet gaan spitten?

Dat zit wel in de pipeline het is nu ook nog proof of concept die ik alvast deel en met beetje Tweaken werkend te krijgen al is lokaal, ik heb twee posts hierboven even een beknopte start gemaakt die heb ik net toegevoegd.

[ Voor 9% gewijzigd door olympusdenk op 30-09-2025 23:13 ]

[Hometek]

Aangepaste strategie voor langdurig lage stroomprijs

Dit weekeinde was de dynamische stroomprijs ca. 36 uur lang praktisch vast op ca. 15 ct (inkoopprijs 0 ct). En er was weining zon.
In deze omstandigheden is het vanwegen de rendements verliezen niet zinvol om de batterij vanuit het net op te laden bij de laagste stroomprijs en dan NOM te draaien.
Ik heb daarom niet opgeladen van het net, en de ontlaad limiet op 0 gezet (via modbus), de batterij laad dan nog wel op als er voldoende PV opwek is, maar ontlaad niet in de zelfconsumptie modus (auto in onderstaand plaatje).

[Hometek]

EMS met SOC als richtwaarde

Een EMS is altijd maatwerk, aangepast aan zowel de installatie, het verbruiksprofiel als ook de persoonlijke doelen die men wil behalen. Maar één ding heeft elk EMS nodig: een richtwaarde. Aan de hand van een theoretisch optimale richtwaarde kan de EMS berekenen of er een bepaalde actie nodig is, bv de batterij opladen van het net met goedkope stroom omdat er morgen weinig zon verwacht wordt.

Ik heb een systeem bedacht om de SOC als richtwaarde te gebruiken. Het systeem is uiteraard volledig afgestemd op mijn verbruik en mijn installatie. Maar het principe kan wellicht als inspiratie dienen voor andere systemen. Ik bouw het systeem in HA/Node-RED en ben momenteel nog aan het testen en inregelen. De flows zijn daardoor nu nogal rommelig. Zodra het stabiel genoeg werkt, zal ik de flows netter structureren en hier delen ter inspiratie. Het zal geen copy/paste toepassing zijn, maar het kan iemand wel op weg helpen, en enkele stukken kunnen wellicht hergebruikt worden.
In deze post alvast het principe en de formules.

Het systeem berekend elke 20 min de optimale SOC waarden:
MSH: minimum SOC nu om de batterij met PV opwek vol te laden
MSL: minimum SOC nu zo dat de batterij met PV opwek morgen ochtend nog niet leeg is

Als de actuele SOC groter is dan MSH is er een overschot dat bij hoogste stroomprijs naar het net ‘verkocht’ kan worden tot SOC=MSH.
Als de actuele SOC kleiner is dan MSL is er een tekort en moet de batterij bij lage stroomprijs opgeladen worden tot SOC=MSL.
Deze strategie is vermoedelijk vooral zinvol voor systemen waarbij de batterij groot genoeg is om makkelijk de volgende dag te halen met NOM.
Alternatief zou je ook uitsluitend op basis van MSH kunnen regelen om altijd een zo vol mogelijke batterij te hebben.
Parallel kunnen ook andere regelingen draaien om bijvoorbeeld laden/ontladen te sturen op basis van actuele stroomprijs.

Variabelen nodig om MSH en MSL te berekenen:
BAT: max batterijcapaciteit in kWh
USE: verwacht gemiddeld stroomverbruik per uur in kW
HRSH: uren tot zonsondergang vandaag
HRST: uren tot 16:00
HRSM: uren tot 00:00
HRSL: uren tot morgen 10:00
SUN1: verwachte PV opwek tot zonsondergang vandaag in kWh
SUN2: verwachte PV opwek morgen in kWh
SUN3: verwachte PV opwek overmorgen in kWh

Berekeningen minimum SOC
MSH1 = ((BAT + (USE * HRSH) - SUN1) / BAT) * 100 vandaag vol
MSH2 = ((BAT + (USE * HRSH+24) - SUN1 - SUN2) / BAT) * 100 morgen vol
MSH3 = ((BAT + (USE * HRSH+48) - SUN1 - SUN2 - SUN3) / BAT) * 100 overmorgen vol
MSL2 = (((USE * HRSL) - SUN1) / BAT) * 100 morgen leeg
MSL3 = (((USE * HRSL+24) - SUN1 - SUN2) / BAT) * 100 overmorgen leeg

LET OP: dit zijn ideale formules, er wordt geen rekening gehouden met verliezen

In een geïdealiseerde simulatie geeft dit de volgende lijnen (MSL2 en MSL3 hebben hier 20% als doel):


Omdat PV opwek niet lineair verloopt en opwek morgen om middernacht verandert in opwek vandaag, heb ik de dag in 3 tijdvakken verdeeld:

middernacht - 10:00 [MSH1 en MSH2 volgens formule]
10:00 - 16:00 [transitie MSH1 naar MSH2, en MSH2 naar MSH3]
16:00 - middernacht [MSH1 = MSH2, MSH2=MSH3 transitie MSL2 naar MSL3]

Tijdvak B loopt tot 16:00 zodat vóór de avondpiek in de stroomprijs de transitie naar MSH2 afgerond is. Transitie tussen 10:00 en 16:00:

MSH1 = MSH2 + ((HRST / 6) * (MSH1 - MSH2))
MSH2 = MSH3 + ((HRST / 6) * (MSH2 - MSH3))

Voor MSL2 en MSL3 hetzelfde, maar dan tussen 16:00 en 00:00

MSL2 = MSL3 + ((HRSM/8) * (MSL2 - MSL3))

Uiteindelijk MSH en MSL bepalen:
MSH = grootste van MSH1 en MSH2
MSL = MSL2

In de ideale simulatie:


Praktijk data voor transitie MSH1/MSH2 (blauw) en MSH2/MSH3 (rood)


Simulatie voor 2 dagen met alleen MSH en MSL


Als er morgen zeer weinig zon is, daalt de SOC onder MSL en moet er stroom van het net opgeladen worden op het eerstvolgende moment dat de prijs gunstig is.


Als er morgen zeer veel zon is, stijgt de SOC boven MSH en kan er stroom naar het net ontladen worden op het eerstvolgende moment dat de prijs hoog is.

[ Voor 3% gewijzigd door Hometek op 08-10-2025 10:07 ]

[Hometek]

antoinevromen schreef op zondag 21 september 2025 @ 16:26:
...
Zo stuurde ik ook eerst op minimum en maximum prijs, maar kwam erachter dat ik ook de RTE (verlies t.g.v. laden/ontladen) in de berekening wilde meenemen omdat ik merkte dat soms een verschil van bijv. x-cent zich door de RTE uiteindelijk vertaalde in het feit dat de minimum-stroomprijs (geladen) toch nog hoger was dan de maximum prijs.
...

Goede tip!
Ik heb het ondertussen hier ook ingebouwd. Bij opladen van het net bij laagste prijs sla ik de prijs van dat uur op, en als later tijdens NOM draaien het prijsverschil te klein wordt zet het systeem de limiet voor Max. Discharge op 0W zodat er nog wel PV overschot wordt opgeslagen (zie ook hier)

[antoinevromen]

Hometek schreef op dinsdag 7 oktober 2025 @ 13:58:
[...]

Goede tip!
Ik heb het ondertussen hier ook ingebouwd. Bij opladen van het net bij laagste prijs sla ik de prijs van dat uur op, en als later tijdens NOM draaien het prijsverschil te klein wordt zet het systeem de limiet voor Max. Discharge op 0W zodat er nog wel PV overschot wordt opgeslagen (zie ook hier)

Hallo @Hometek , Als ik dat zo lees is dat een andere benadering dan bij mij, maar uiteindelijk beperk je het ontladen totdat zich een groter prijsverschil voordoet dan waarvoor je hebt geladen (incl. RTE-verlies) van het net.
Ik doe het andersom. Ik kijk naar welke pieken komen er nog en als het financieel niet interessant is t.g.v. RTE-verlies dan laadt ik niet en neem ook de PV die nog komt op via de NOM-stand.

[antoinevromen]

Hometek schreef op maandag 6 oktober 2025 @ 21:11:
EMS met SOC als richtwaarde

Een EMS is altijd maatwerk, aangepast aan zowel de installatie, het verbruiksprofiel als ook de persoonlijke doelen die men wil behalen. Maar één ding heeft elk EMS nodig: een richtwaarde. Aan de hand van een theoretisch optimale richtwaarde kan de EMS berekenen of er een bepaalde actie nodig is, bv de batterij opladen van het net met goedkope stroom omdat er morgen weinig zon verwacht wordt.

Ik heb een systeem bedacht om de SOC als richtwaarde te gebruiken. Het systeem is uiteraard volledig afgestemd op mijn verbruik en mijn installatie. Maar het principe kan wellicht als inspiratie dienen voor andere systemen. Ik bouw het systeem in HA/Node-RED en ben momenteel nog aan het testen en inregelen. De flows zijn daardoor nu nogal rommelig. Zodra het stabiel genoeg werkt, zal ik de flows netter structureren en hier delen ter inspiratie. Het zal geen copy/paste toepassing zijn, maar het kan iemand wel op weg helpen, en enkele stukken kunnen wellicht hergebruikt worden.
In deze post alvast het principe en de formules.

Het systeem berekend elke 20 min de optimale SOC waarden:
MSH: minimum SOC nu om de batterij met PV opwek vol te laden
MSL: minimum SOC nu zo dat de batterij met PV opwek morgen ochtend nog niet leeg is

Als de actuele SOC groter is dan MSH is er een overschot dat bij hoogste stroomprijs naar het net ‘verkocht’ kan worden tot SOC=MSH.
Als de actuele SOC kleiner is dan MSL is er een tekort en moet de batterij bij lage stroomprijs opgeladen worden tot SOC=MSL.
Deze strategie is vermoedelijk vooral zinvol voor systemen waarbij de batterij groot genoeg is om makkelijk de volgende dag te halen met NOM.

Variabelen nodig om MSH en MSL te berekenen:
BAT: max batterijcapaciteit in kWh
USE: verwacht gemiddeld stroomverbruik per uur in kW
HRSH: uren tot zonsondergang vandaag
HRST: uren tot 16:00
HRSM: uren tot 00:00
HRSL: uren tot morgen 10:00
SUN1: verwachte PV opwek tot zonsondergang vandaag in kWh
SUN2: verwachte PV opwek morgen in kWh
SUN3: verwachte PV opwek overmorgen in kWh

Berekeningen minimum SOC
MSH1 = ((BAT + (USE * HRSH) - SUN1) / BAT) * 100 vandaag vol
MSH2 = ((BAT + (USE * HRSH+24) - SUN1 - SUN2) / BAT) * 100 morgen vol
MSH3 = ((BAT + (USE * HRSH+48) - SUN1 - SUN2 - SUN3) / BAT) * 100 overmorgen vol
MSL2 = (((USE * HRSL) - SUN1) / BAT) * 100 morgen leeg
MSL3 = (((USE * HRSL+24) - SUN1 - SUN2) / BAT) * 100 overmorgen leeg

LET OP: dit zijn ideale formules, er wordt geen rekening gehouden met verliezen

In een geïdealiseerde simulatie geeft dit de volgende lijnen (MSL2 en MSL3 hebben hier 20% als doel):
[Afbeelding]

Omdat PV opwek niet lineair verloopt en opwek morgen om middernacht verandert in opwek vandaag, heb ik de dag in 3 tijdvakken verdeeld:

middernacht - 10:00 [MSH1 en MSH2 volgens formule]
10:00 - 16:00 [transitie MSH1 naar MSH2, en MSH2 naar MSH3]
16:00 - middernacht [MSH1 = MSH2, MSH2=MSH3 transitie MSL2 naar MSL3]

Tijdvak B loopt tot 16:00 zodat vóór de avondpiek in de stroomprijs de transitie naar MSH2 afgerond is. Transitie tussen 10:00 en 16:00:

MSH1 = MSH2 + ((HRST / 6) * (MSH1 - MSH2))
MSH2 = MSH3 + ((HRST / 6) * (MSH2 - MSH3))

Voor MSL2 en MSL3 hetzelfde, maar dan tussen 16:00 en 00:00

MSL2 = MSL3 + ((HRSM/8) * (MSL2 - MSL3))

Uiteindelijk MSH en MSL bepalen:
MSH = grootste van MSH1 en MSH2
MSL = MSL2

In de ideale simulatie:
[Afbeelding]

Praktijk data voor transitie MSH1/MSH2 (blauw) en MSH2/MSH3 (rood)
[Afbeelding]

Simulatie voor 2 dagen met alleen MSH en MSL
[Afbeelding]

Als er morgen zeer weinig zon is, daalt de SOC onder MSL en moet er stroom van het net opgeladen worden op het eerstvolgende moment dat de prijs gunstig is.
[Afbeelding]

Als er morgen zeer veel zon is, stijgt de SOC boven MSH en kan er stroom naar het net ontladen worden op het eerstvolgende moment dat de prijs hoog is.
[Afbeelding]

@Hometek Indrukwekkend al die formules te zien en hoe je op een totaal andere manier toch je eigen use-cases in het systeem aan het inbouwen bent. Op het moment dat je deze stuurlogica begint te verwoorden voor anderen, dan kom je erachter dat er toch wel veel variabelen door elkaar spelen en het "even" in een paar zinnen opschrijven wat er in de programmatuur gebeurt nog niet zo simpel is.
Ik zie dat je ook rekening houdt met de verwachte PV-opbrengst in de toekomst. Ik neem aan dat je daar dezelfde bron als ik voor gebruik (https://weerlive.nl/api/weerlive_api_v2.php) Zo niet, dan ben ik wel benieuwd wat je dan gebruikt. Ik heb zelf op basis van die voorspelde Wattages/m2 en mijn daadwerkelijke PV-opbrengst een soort constante berekend/geschat om die Wattages/m2 om te rekenen naar PV-kWh
(hoe doe jij dat?)

[Hometek]

antoinevromen schreef op dinsdag 7 oktober 2025 @ 14:53:
[...]

@Hometek Indrukwekkend al die formules te zien en hoe je op een totaal andere manier toch je eigen use-cases in het systeem aan het inbouwen bent. Op het moment dat je deze stuurlogica begint te verwoorden voor anderen, dan kom je erachter dat er toch wel veel variabelen door elkaar spelen en het "even" in een paar zinnen opschrijven wat er in de programmatuur gebeurt nog niet zo simpel is.
Ik zie dat je ook rekening houdt met de verwachte PV-opbrengst in de toekomst. Ik neem aan dat je daar dezelfde bron als ik voor gebruik (https://weerlive.nl/api/weerlive_api_v2.php) Zo niet, dan ben ik wel benieuwd wat je dan gebruikt. Ik heb zelf op basis van die voorspelde Wattages/m2 en mijn daadwerkelijke PV-opbrengst een soort constante berekend/geschat om die Wattages/m2 om te rekenen naar PV-kWh
(hoe doe jij dat?)

Het opschrijven helpt mij ook om het zelf beter te begrijpen en vaak vind ik zo ook fouten

Voor de PV opwek voorspelling gebruik ik Solcast, deze HA integratie levert direct de verwachte kWh voor een installatie (specificaties invoeren op hun website), en er zit sinds kort een handige auto-correctie functie in (zie deze post).

[Hometek]

antoinevromen schreef op dinsdag 7 oktober 2025 @ 14:38:
[...]
Hallo @Hometek , Als ik dat zo lees is dat een andere benadering dan bij mij, maar uiteindelijk beperk je het ontladen totdat zich een groter prijsverschil voordoet dan waarvoor je hebt geladen (incl. RTE-verlies) van het net.
Ik doe het andersom. Ik kijk naar welke pieken komen er nog en als het financieel niet interessant is t.g.v. RTE-verlies dan laadt ik niet en neem ook de PV die nog komt op via de NOM-stand.

Mijn aanpak is idd anders, dat komt denk ik vooral omdat mijn batterij capaciteit groter is dan mijn gemiddelde dagverbruik, ik kan dus wachten op dat ene uur met de laagste prijs.
Mijn doelen zijn:

1. zoveel mogelijk eigen PV stroom gebruiken
2. keuzevrijheid om wel of niet overschot terug te leveren aan het net

Mijn EMS heeft 3 functies die ik onafhankelijk van elkaar aan of uit kan zetten:

1. bij te lage SOC batterij opladen van het net tijdens goedkope uren
2. bij te hoge SOC batterij ontladen naar het net tijdens dure uren
3. PV panelen uitschakelen als de verwachte opwek meer is dan het verwachte verbruik

Afgezien van persoonlijk voordeel denk ik dat deze functies ook bijdragen om het stroomnet te ontlasten (mits meer mensen het gaan doen)

[antoinevromen]

Hometek schreef op dinsdag 7 oktober 2025 @ 16:22:
[...]

Het opschrijven helpt mij ook om het zelf beter te begrijpen en vaak vind ik zo ook fouten

Voor de PV opwek voorspelling gebruik ik Solcast, deze HA integratie levert direct de verwachte kWh voor een installatie (specificaties invoeren op hun website), en er zit sinds kort een handige auto-correctie functie in (zie deze post).

@Hometek Heb eens gekeken bij solcast; Weer een andere wijze van werken, maar ik ben er nog niet achter of ik ook historisch gezien gegevens kan opvragen om te vergelijken met de reeds gerealiseerde PV-opbrengst per dag. Api werkt wel nu voor vandaag of voorspelling voor bijv. morgen

[ Voor 4% gewijzigd door antoinevromen op 07-10-2025 17:15 ]

[antoinevromen]

Hometek schreef op dinsdag 7 oktober 2025 @ 17:07:
[...]

Mijn aanpak is idd anders, dat komt denk ik vooral omdat mijn batterij capaciteit groter is dan mijn gemiddelde dagverbruik, ik kan dus wachten op dat ene uur met de laagste prijs.
Mijn doelen zijn:

1. zoveel mogelijk eigen PV stroom gebruiken
2. keuzevrijheid om wel of niet overschot terug te leveren aan het net

Mijn EMS heeft 3 functies die ik onafhankelijk van elkaar aan of uit kan zetten:

1. bij te lage SOC batterij opladen van het net tijdens goedkope uren
2. bij te hoge SOC batterij ontladen naar het net tijdens dure uren
3. PV panelen uitschakelen als de verwachte opwek meer is dan het verwachte verbruik

Afgezien van persoonlijk voordeel denk ik dat deze functies ook bijdragen om het stroomnet te ontlasten (mits meer mensen het gaan doen)

@Hometek Ik neem aan dat er ook iets in zit om bijv. juist niet van het net op te laden en met PV de batterij te vullen. Of juist het uitstellen van het laden van de batterij op PV in de ochtenduren (zomer, in de ochtend terugleveren aan net op relatief duurdere uren i.p.v. laden pv-stroom op die uren) om dan in de middaguren (als de prijs heel laag is / misschien negatief) op PV te gaan laden.

[Hometek]

antoinevromen schreef op dinsdag 7 oktober 2025 @ 17:22:
[...]
@Hometek Ik neem aan dat er ook iets in zit om bijv. juist niet van het net op te laden en met PV de batterij te vullen. Of juist het uitstellen van het laden van de batterij op PV in de ochtenduren (zomer, in de ochtend terugleveren aan net op relatief duurdere uren i.p.v. laden pv-stroom op die uren) om dan in de middaguren (als de prijs heel laag is / misschien negatief) op PV te gaan laden.

Welke strategie de voorkeur heeft hangt voor een groot deel van de persoonlijke voorkeuren af; maximaal financieel voordeel, maximale reserve in de batterij, minimale belasting van het net. Maar ook van de verhouding tussen PV, batterij en verbruik. Die mix zal voor elk huishouden anders zijn

[UsernameIsInUse]

..

[ Voor 198% gewijzigd door UsernameIsInUse op 08-10-2025 10:59 . Reden: reeds beantwoord ]

[Rhelms]

antoinevromen schreef op zondag 21 september 2025 @ 17:25:
DEEL6:
Onderstaand het script om periodiek (bijv. elk kwartier) te draaien dat op basis van zonnewattage/m2 , dynamische tarieven voor een dag, de huidige informatie uit je batterij en enkele andere logica bepaalt of
de batterij middels Net-stroom geladen moet worden om zodoende geld te verdienen (bijv. door te handelen, of door ervoor te zorgen dat je de dure uren via de batterij kunt doorkomen met goedkoop geladen net-stroom etc.
=====
Het scriptje avzetMODEdynamisch.cmd
=====

[...]

======
Het scriptje avzetMODEdynamisch.ps1
=====

[...]

=====

Hi Antoine,

Heel veel dank voor je moeite, ik heb het aan de praat. Ik heb echter 1 probleem met het script: Als de accumodus op "Passive" staat en de uitkomst van het script is schakelen naar "Auto", dan werkt dit niet. Hij blijft op Passive mode staan. Bij het schakelen vanaf een andere modus dan "Passive" naar "Auto" werkt het wel. Enig idee hoe dit kan komen?

Alvast bedankt!

[antoinevromen]

Hallo Rhelms,

Ik heb inmiddels al heel veel extra functionaliteit in het script toegevoegd (ook programmaflow-logging), waardoor ik kan zien waarom er een beslissing is genomen. Zie het meer als een jump-start.
Ik weet niet of je kunt programmeren (en zelf middels write-output statements debugging kunt toevoegen).
Dan kun je zelf achterhalen waar hij komt en waarom het niet werkt. Ik kan je ook mijn allerlaatste versie van de script toesturen. Waarschijnlijk is daar de betreffende situatie al in opgelost. Zeg maar wat je het liefste doet. Als het namelijk loopt is het heel simpel de inhoud van het script door een nieuwe inhoud te vervangen. Of je moet er ook lol aan hebben om het script te doorgronden en zelf mijn denkfout te vinden ;-)
Dan zou je ook je eigen wensen erin kunnen bouwen nu je weet hoe je de basiszaken kunt schakelen en voorbeelden hebt hoe je op basis van inputgegevens tot een beslissing tot schakelen kunt komen.
Groeten Antoine Vromen

[ Voor 11% gewijzigd door antoinevromen op 09-10-2025 14:05 ]

[Rhelms]

antoinevromen schreef op donderdag 9 oktober 2025 @ 13:59:
Hallo Rhelms,

Ik heb inmiddels al heel veel extra functionaliteit in het script toegevoegd (ook programmaflow-logging), waardoor ik kan zien waarom er een beslissing is genomen. Zie het meer als een jump-start.
Ik weet niet of je kunt programmeren (en zelf middels write-output statements debugging kunt toevoegen).
Dan kun je zelf achterhalen waar hij komt en waarom het niet werkt. Ik kan je ook mijn allerlaatste versie van de script toesturen. Waarschijnlijk is daar de betreffende situatie al in opgelost. Zeg maar wat je het liefste doet. Als het namelijk loopt is het heel simpel de inhoud van het script door een nieuwe inhoud te vervangen. Of je moet er ook lol aan hebben om het script te doorgronden en zelf mijn denkfout te vinden ;-)
Dan zou je ook je eigen wensen erin kunnen bouwen nu je weet hoe je de basiszaken kunt schakelen en voorbeelden hebt hoe je op basis van inputgegevens tot een beslissing tot schakelen kunt komen.
Groeten Antoine Vromen

Ah super, ik zou heel graag je nieuwste versie ontvangen. Ik ben absoluut geen held in programmeren haha. Nogmaals dank!

[antoinevromen]

Rhelms schreef op donderdag 9 oktober 2025 @ 15:01:
[...]


Ah super, ik zou heel graag je nieuwste versie ontvangen. Ik ben absoluut geen held in programmeren haha. Nogmaals dank!

Ik zal je die nieuwste versie via PB toesturen

[WargamingPlayer]

Zijn er mensen die het lukt om een Solcast account aan te maken?

[antoinevromen]

WargamingPlayer schreef op zaterdag 11 oktober 2025 @ 22:29:
Zijn er mensen die het lukt om een Solcast account aan te maken?

Ja is mij gelukt. zo'n gratis account

[ Voor 4% gewijzigd door antoinevromen op 12-10-2025 09:20 ]

[WargamingPlayer]

antoinevromen schreef op zondag 12 oktober 2025 @ 09:20:
[...]

Ja is mij gelukt. zo'n gratis account

Heel vreemd, kreeg steeds de melding “Cannot create account” en toch opeens een mailtje dat ik een account heb.

[antoinevromen]

WargamingPlayer schreef op zondag 12 oktober 2025 @ 11:19:
[...]

Heel vreemd, kreeg steeds de melding “Cannot create account” en toch opeens een mailtje dat ik een account heb.

Heb je al eens geprobeerd in te loggen met zo'n account; Je ziet dan een persoonlijk API-key, die je in je webservicecall kunt stoppen.

[antoinevromen]

WargamingPlayer schreef op zondag 12 oktober 2025 @ 11:19:
[...]

Heel vreemd, kreeg steeds de melding “Cannot create account” en toch opeens een mailtje dat ik een account heb.

Probeer eens via https://toolkit.solcast.com.au/ in te loggen (onder je account zie je de api-key die je in de webcall kunt gebruiken)

[Hometek]

Het niet ontladen van de batterij als de stroomprijs lager is dan tijdens het opladen van het net maakt het voorspellen van de SOC een stuk complexer.
Op dit moment is de stroomprijs zolang laag dat de batterij meerdere dagen lang niet ontlaadt, pas morgenavond is er een korte piek:
(de groene lijn is de drempelwaarde, prijs tijdens opladen +25%)



Ik probeer nu het aantal uren dat de batterij niet zal ontladen mee te nemen in de SOC voorspelling. Daarnaast laat ik twee tellers bijhouden hoeveel stroom er van het net geladen wordt en hoeveel van PV. PV stroom mag namelijk wel ontladen worden bij een lage prijs.

[WargamingPlayer]

antoinevromen schreef op zondag 12 oktober 2025 @ 11:27:
[...]

Probeer eens via https://toolkit.solcast.com.au/ in te loggen (onder je account zie je de api-key die je in de webcall kunt gebruiken)

Inmiddels gelukt, account was aangemaakt en heb hem werken. Ik zit nu een beetje te twijfelen. Heb nu twee integraties welke uitgaan van zelfde gegevens:

• Forecast.Solar
• Solarcast PV Forecast

Beide wijken nogal af van elkaar. Waarbij de eerste voor mijn gevoel dichter bij de waarheid zit. Hoewel de uur Forecast van de tweede weer nauwkeuriger is.

Wat ik eigenlijk gehoopt had is dat er een integratie was welke een JSON terg zo geven met verwachtte zon opbrengst per uur of per kwartier. Of een sensor met een array van waarden (komma gescheiden reeks van 24 of 100 items). Want daar kan je een dag strategie mee maken.

Edit: ik zie dat de tweede netjes dit in een attribuut heeft zitten

[ Voor 3% gewijzigd door WargamingPlayer op 13-10-2025 15:04 ]

[antoinevromen]

WargamingPlayer schreef op maandag 13 oktober 2025 @ 15:02:
[...]

Inmiddels gelukt, account was aangemaakt en heb hem werken. Ik zit nu een beetje te twijfelen. Heb nu twee integraties welke uitgaan van zelfde gegevens:

• Forecast.Solar
• Solarcast PV Forecast

Beide wijken nogal af van elkaar. Waarbij de eerste voor mijn gevoel dichter bij de waarheid zit. Hoewel de uur Forecast van de tweede weer nauwkeuriger is.

Wat ik eigenlijk gehoopt had is dat er een integratie was welke een JSON terg zo geven met verwachtte zon opbrengst per uur of per kwartier. Of een sensor met een array van waarden (komma gescheiden reeks van 24 of 100 items). Want daar kan je een dag strategie mee maken.

Edit: ik zie dat de tweede netjes dit in een attribuut heeft zitten

Zo'n voorspelling op basis van json heb ik in mijn powershell-script opgenomen. Dat werkt dus per uur en voorspelt op mijn huis hoeveel Watt er per m2 wordt verwacht elk uur; Die cijfers passen zich ook elk uur aan (natuurlijk zijn de voorspellingscijfers voor bijv. 14.00 uur van 's morgens 8 uur betrouwbaarder dan die van 1 uur 's nachts.
Wat ik doe is de m2 zonnepanelen vermenigvuldigen met die W/m2 . Daar komt een cijfer uit (als je alle uren van een dag bij elkaar telt). Dat cijfer klopt natuurlijk van geen kant. Dus heb ik de daadwerkelijk opbrengst elke dag bijgehouden en een factor uitgerekend waarmee ik de voorspelde waarde moet vermenigvuldigen. En dan krijg je een redelijk betrouwbaardere schatting van hoeveel PV-kWh elk uur gaat opleveren. Eerlijkheid gebied te zeggen dat die factor toch nog steeds kan liggen tussen 0,1 en 0,2 (dus ik houdt zo ongeveer 0,15 aan ; bij mijn zonnepanelen en mijn huis). Maar het blijft een voorspelling en het blijft een schatting. Uiteindelijk fluctueert het verbruik in je huis ook continue en als er in totaal op een dag bijv. 10 kWh door je PV voorspelt wordt om opgewekt te worden, dan gaat een deel daarvan niet de batterij in, maar wordt meteen verbruikt. https://weerlive.nl/api/weerlive_api_v2.php?key=<hier jouw key>&locatie=Voerendaal

[WargamingPlayer]

Stap twee in mijn pogingen om de winter door te komen is de prijzen op te halen. Daarvoor gebruik ik ENTSO-e. Heb netjes de API key, maar toch werkt de integratie niet in HA. Want om een schema te maken is ook de prijs van belang. Niet de huidige prijs, die haal ik anders binnen, maar wel de prijzen zoals deze bepaald worden voor de hele dag. Ik wacht nog even af of er vannacht nog wat binnen gaat komen, maar heb zo mijn twijfels.

Django/Jinja:

{% set s = {"extra_cost": 0.04,"energie_belasting": 0.1088,"VAT": 1} %} 
{{((current_price + s.extra_cost + s.energie_belasting) * s.VAT) | float}}

[antoinevromen]

WargamingPlayer schreef op maandag 13 oktober 2025 @ 19:25:
Stap twee in mijn pogingen om de winter door te komen is de prijzen op te halen. Daarvoor gebruik ik ENTSO-e. Heb netjes de API key, maar toch werkt de integratie niet in HA. Want om een schema te maken is ook de prijs van belang. Niet de huidige prijs, die haal ik anders binnen, maar wel de prijzen zoals deze bepaald worden voor de hele dag. Ik wacht nog even af of er vannacht nog wat binnen gaat komen, maar heb zo mijn twijfels.
Modifier:

Django/Jinja:

{% set s = {"extra_cost": 0.04,"energie_belasting": 0.1088,"VAT": 1} %} 
{{((current_price + s.extra_cost + s.energie_belasting) * s.VAT) | float}}

Ik haal mijn prijzen voor period=vandaag en voor period=morgen per kwartier in json gratis op van internet. Staat allemaal in een post van mij hier op dit forum . Ik haal die data van de prijzen van jeroen.nl (moet je wel ook gratis een api-key voor krijgen, die je krijgt als je je registreert).
Omdat die toch niet veranderen en je slechts een beperkt aantal calls gratis per dag mag doen sla ik het resultaat op in een txt-bestandje, dat je eenvoudig kunt inlezen in een object.

Hieronder het jobje om het op te halen in powershell-script, maar kan met elke tool:

code:

Add-Type -AssemblyName System.Net # ,System.Net.Sockets
$TarievenVandaag = Invoke-WebRequest 'https://jeroen.nl/api/dynamische-energieprijzen/v2/?period=vandaag&type=json&key=<hier jouw api-key>'
##$TarievenVandaag = '[{"datum_nl":"2025-09-10 00:00:00","datum_utc":"2025-09-09 22:00:00","prijs_excl_belastingen":"0,100700"},{"datum_nl":"2025-09-10 00:15:00","datum_utc":"2025-09-09 22:15:00","prijs_excl_belastingen":"0,100700"},{"datum_nl":"2025-09-10 00:30:00","datum_utc":"2025-09-09 22:30:00","prijs_excl_belastingen":"0,100700"},{"datum_nl":"2025-09-10 00:45:00","datum_utc":"2025-09-09 22:45:00","prijs_excl_belastingen":"0,100700"},{"datum_nl":"2025-09-10 01:00:00","datum_utc":"2025-09-09 23:00:00","prijs_excl_belastingen":"0,101200"},{"datum_nl":"2025-09-10 01:15:00","datum_utc":"2025-09-09 23:15:00","prijs_excl_belastingen":"0,101200"},{"datum_nl":"2025-09-10 01:30:00","datum_utc":"2025-09-09 23:30:00","prijs_excl_belastingen":"-0,101200"},{"datum_nl":"2025-09-10 01:45:00","datum_utc":"2025-09-09 23:45:00","prijs_excl_belastingen":"0,101200"},{"datum_nl":"2025-09-10 02:00:00","datum_utc":"2025-09-10 00:00:00","prijs_excl_belastingen":"0,098500"},{"datum_nl":"2025-09-10 02:15:00","datum_utc":"2025-09-10 00:15:00","prijs_excl_belastingen":"0,098500"},{"datum_nl":"2025-09-10 02:30:00","datum_utc":"2025-09-10 00:30:00","prijs_excl_belastingen":"0,098500"},{"datum_nl":"2025-09-10 02:45:00","datum_utc":"2025-09-10 00:45:00","prijs_excl_belastingen":"0,098500"},{"datum_nl":"2025-09-10 03:00:00","datum_utc":"2025-09-10 01:00:00","prijs_excl_belastingen":"0,099200"},{"datum_nl":"2025-09-10 03:15:00","datum_utc":"2025-09-10 01:15:00","prijs_excl_belastingen":"0,099200"},{"datum_nl":"2025-09-10 03:30:00","datum_utc":"2025-09-10 01:30:00","prijs_excl_belastingen":"0,099200"},{"datum_nl":"2025-09-10 03:45:00","datum_utc":"2025-09-10 01:45:00","prijs_excl_belastingen":"0,099200"},{"datum_nl":"2025-09-10 04:00:00","datum_utc":"2025-09-10 02:00:00","prijs_excl_belastingen":"0,100100"},{"datum_nl":"2025-09-10 04:15:00","datum_utc":"2025-09-10 02:15:00","prijs_excl_belastingen":"0,100100"},{"datum_nl":"2025-09-10 04:30:00","datum_utc":"2025-09-10 02:30:00","prijs_excl_belastingen":"0,100100"},{"datum_nl":"2025-09-10 04:45:00","datum_utc":"2025-09-10 02:45:00","prijs_excl_belastingen":"0,100100"},{"datum_nl":"2025-09-10 05:00:00","datum_utc":"2025-09-10 03:00:00","prijs_excl_belastingen":"0,107600"},{"datum_nl":"2025-09-10 05:15:00","datum_utc":"2025-09-10 03:15:00","prijs_excl_belastingen":"0,107600"},{"datum_nl":"2025-09-10 05:30:00","datum_utc":"2025-09-10 03:30:00","prijs_excl_belastingen":"0,107600"},{"datum_nl":"2025-09-10 05:45:00","datum_utc":"2025-09-10 03:45:00","prijs_excl_belastingen":"0,107600"},{"datum_nl":"2025-09-10 06:00:00","datum_utc":"2025-09-10 04:00:00","prijs_excl_belastingen":"0,129700"},{"datum_nl":"2025-09-10 06:15:00","datum_utc":"2025-09-10 04:15:00","prijs_excl_belastingen":"0,129700"},{"datum_nl":"2025-09-10 06:30:00","datum_utc":"2025-09-10 04:30:00","prijs_excl_belastingen":"0,129700"},{"datum_nl":"2025-09-10 06:45:00","datum_utc":"2025-09-10 04:45:00","prijs_excl_belastingen":"0,129700"},{"datum_nl":"2025-09-10 07:00:00","datum_utc":"2025-09-10 05:00:00","prijs_excl_belastingen":"0,217600"},{"datum_nl":"2025-09-10 07:15:00","datum_utc":"2025-09-10 05:15:00","prijs_excl_belastingen":"0,217600"},{"datum_nl":"2025-09-10 07:30:00","datum_utc":"2025-09-10 05:30:00","prijs_excl_belastingen":"0,217600"},{"datum_nl":"2025-09-10 07:45:00","datum_utc":"2025-09-10 05:45:00","prijs_excl_belastingen":"0,217600"},{"datum_nl":"2025-09-10 08:00:00","datum_utc":"2025-09-10 06:00:00","prijs_excl_belastingen":"0,167800"},{"datum_nl":"2025-09-10 08:15:00","datum_utc":"2025-09-10 06:15:00","prijs_excl_belastingen":"0,167800"},{"datum_nl":"2025-09-10 08:30:00","datum_utc":"2025-09-10 06:30:00","prijs_excl_belastingen":"0,167800"},{"datum_nl":"2025-09-10 08:45:00","datum_utc":"2025-09-10 06:45:00","prijs_excl_belastingen":"0,167800"},{"datum_nl":"2025-09-10 09:00:00","datum_utc":"2025-09-10 07:00:00","prijs_excl_belastingen":"0,125000"},{"datum_nl":"2025-09-10 09:15:00","datum_utc":"2025-09-10 07:15:00","prijs_excl_belastingen":"0,125000"},{"datum_nl":"2025-09-10 09:30:00","datum_utc":"2025-09-10 07:30:00","prijs_excl_belastingen":"0,125000"},{"datum_nl":"2025-09-10 09:45:00","datum_utc":"2025-09-10 07:45:00","prijs_excl_belastingen":"0,125000"},{"datum_nl":"2025-09-10 10:00:00","datum_utc":"2025-09-10 08:00:00","prijs_excl_belastingen":"0,095500"},{"datum_nl":"2025-09-10 10:15:00","datum_utc":"2025-09-10 08:15:00","prijs_excl_belastingen":"0,095500"},{"datum_nl":"2025-09-10 10:30:00","datum_utc":"2025-09-10 08:30:00","prijs_excl_belastingen":"0,095500"},{"datum_nl":"2025-09-10 10:45:00","datum_utc":"2025-09-10 08:45:00","prijs_excl_belastingen":"0,095500"},{"datum_nl":"2025-09-10 11:00:00","datum_utc":"2025-09-10 09:00:00","prijs_excl_belastingen":"0,089900"},{"datum_nl":"2025-09-10 11:15:00","datum_utc":"2025-09-10 09:15:00","prijs_excl_belastingen":"0,089900"},{"datum_nl":"2025-09-10 11:30:00","datum_utc":"2025-09-10 09:30:00","prijs_excl_belastingen":"0,089900"},{"datum_nl":"2025-09-10 11:45:00","datum_utc":"2025-09-10 09:45:00","prijs_excl_belastingen":"0,089900"},{"datum_nl":"2025-09-10 12:00:00","datum_utc":"2025-09-10 10:00:00","prijs_excl_belastingen":"0,078100"},{"datum_nl":"2025-09-10 12:15:00","datum_utc":"2025-09-10 10:15:00","prijs_excl_belastingen":"0,078100"},{"datum_nl":"2025-09-10 12:30:00","datum_utc":"2025-09-10 10:30:00","prijs_excl_belastingen":"0,078100"},{"datum_nl":"2025-09-10 12:45:00","datum_utc":"2025-09-10 10:45:00","prijs_excl_belastingen":"0,078100"},{"datum_nl":"2025-09-10 13:00:00","datum_utc":"2025-09-10 11:00:00","prijs_excl_belastingen":"0,075900"},{"datum_nl":"2025-09-10 13:15:00","datum_utc":"2025-09-10 11:15:00","prijs_excl_belastingen":"0,075900"},{"datum_nl":"2025-09-10 13:30:00","datum_utc":"2025-09-10 11:30:00","prijs_excl_belastingen":"0,075900"},{"datum_nl":"2025-09-10 13:45:00","datum_utc":"2025-09-10 11:45:00","prijs_excl_belastingen":"0,075900"},{"datum_nl":"2025-09-10 14:00:00","datum_utc":"2025-09-10 12:00:00","prijs_excl_belastingen":"0,074600"},{"datum_nl":"2025-09-10 14:15:00","datum_utc":"2025-09-10 12:15:00","prijs_excl_belastingen":"0,074600"},{"datum_nl":"2025-09-10 14:30:00","datum_utc":"2025-09-10 12:30:00","prijs_excl_belastingen":"0,074600"},{"datum_nl":"2025-09-10 14:45:00","datum_utc":"2025-09-10 12:45:00","prijs_excl_belastingen":"0,074600"},{"datum_nl":"2025-09-10 15:00:00","datum_utc":"2025-09-10 13:00:00","prijs_excl_belastingen":"0,079200"},{"datum_nl":"2025-09-10 15:15:00","datum_utc":"2025-09-10 13:15:00","prijs_excl_belastingen":"0,079200"},{"datum_nl":"2025-09-10 15:30:00","datum_utc":"2025-09-10 13:30:00","prijs_excl_belastingen":"0,079200"},{"datum_nl":"2025-09-10 15:45:00","datum_utc":"2025-09-10 13:45:00","prijs_excl_belastingen":"0,079200"},{"datum_nl":"2025-09-10 16:00:00","datum_utc":"2025-09-10 14:00:00","prijs_excl_belastingen":"0,091700"},{"datum_nl":"2025-09-10 16:15:00","datum_utc":"2025-09-10 14:15:00","prijs_excl_belastingen":"0,091700"},{"datum_nl":"2025-09-10 16:30:00","datum_utc":"2025-09-10 14:30:00","prijs_excl_belastingen":"0,091700"},{"datum_nl":"2025-09-10 16:45:00","datum_utc":"2025-09-10 14:45:00","prijs_excl_belastingen":"0,091700"},{"datum_nl":"2025-09-10 17:00:00","datum_utc":"2025-09-10 15:00:00","prijs_excl_belastingen":"0,121100"},{"datum_nl":"2025-09-10 17:15:00","datum_utc":"2025-09-10 15:15:00","prijs_excl_belastingen":"0,121100"},{"datum_nl":"2025-09-10 17:30:00","datum_utc":"2025-09-10 15:30:00","prijs_excl_belastingen":"0,121100"},{"datum_nl":"2025-09-10 17:45:00","datum_utc":"2025-09-10 15:45:00","prijs_excl_belastingen":"0,121100"},{"datum_nl":"2025-09-10 18:00:00","datum_utc":"2025-09-10 16:00:00","prijs_excl_belastingen":"0,152600"},{"datum_nl":"2025-09-10 18:15:00","datum_utc":"2025-09-10 16:15:00","prijs_excl_belastingen":"0,152600"},{"datum_nl":"2025-09-10 18:30:00","datum_utc":"2025-09-10 16:30:00","prijs_excl_belastingen":"0,152600"},{"datum_nl":"2025-09-10 18:45:00","datum_utc":"2025-09-10 16:45:00","prijs_excl_belastingen":"0,152600"},{"datum_nl":"2025-09-10 19:00:00","datum_utc":"2025-09-10 17:00:00","prijs_excl_belastingen":"0,232400"},{"datum_nl":"2025-09-10 19:15:00","datum_utc":"2025-09-10 17:15:00","prijs_excl_belastingen":"0,232400"},{"datum_nl":"2025-09-10 19:30:00","datum_utc":"2025-09-10 17:30:00","prijs_excl_belastingen":"0,232400"},{"datum_nl":"2025-09-10 19:45:00","datum_utc":"2025-09-10 17:45:00","prijs_excl_belastingen":"0,232400"},{"datum_nl":"2025-09-10 20:00:00","datum_utc":"2025-09-10 18:00:00","prijs_excl_belastingen":"0,156900"},{"datum_nl":"2025-09-10 20:15:00","datum_utc":"2025-09-10 18:15:00","prijs_excl_belastingen":"0,156900"},{"datum_nl":"2025-09-10 20:30:00","datum_utc":"2025-09-10 18:30:00","prijs_excl_belastingen":"0,156900"},{"datum_nl":"2025-09-10 20:45:00","datum_utc":"2025-09-10 18:45:00","prijs_excl_belastingen":"0,156900"},{"datum_nl":"2025-09-10 21:00:00","datum_utc":"2025-09-10 19:00:00","prijs_excl_belastingen":"0,105500"},{"datum_nl":"2025-09-10 21:15:00","datum_utc":"2025-09-10 19:15:00","prijs_excl_belastingen":"0,105500"},{"datum_nl":"2025-09-10 21:30:00","datum_utc":"2025-09-10 19:30:00","prijs_excl_belastingen":"0,105500"},{"datum_nl":"2025-09-10 21:45:00","datum_utc":"2025-09-10 19:45:00","prijs_excl_belastingen":"0,105500"},{"datum_nl":"2025-09-10 22:00:00","datum_utc":"2025-09-10 20:00:00","prijs_excl_belastingen":"0,091800"},{"datum_nl":"2025-09-10 22:15:00","datum_utc":"2025-09-10 20:15:00","prijs_excl_belastingen":"0,091800"},{"datum_nl":"2025-09-10 22:30:00","datum_utc":"2025-09-10 20:30:00","prijs_excl_belastingen":"0,091800"},{"datum_nl":"2025-09-10 22:45:00","datum_utc":"2025-09-10 20:45:00","prijs_excl_belastingen":"0,091800"},{"datum_nl":"2025-09-10 23:00:00","datum_utc":"2025-09-10 21:00:00","prijs_excl_belastingen":"0,078200"},{"datum_nl":"2025-09-10 23:15:00","datum_utc":"2025-09-10 21:15:00","prijs_excl_belastingen":"0,078200"},{"datum_nl":"2025-09-10 23:30:00","datum_utc":"2025-09-10 21:30:00","prijs_excl_belastingen":"0,078200"},{"datum_nl":"2025-09-10 23:45:00","datum_utc":"2025-09-10 21:45:00","prijs_excl_belastingen":"0,078200"}]'
$TarievenVandaag = $TarievenVandaag -replace ':"-0,', ':"-0.'
$TarievenVandaag = $TarievenVandaag -replace ':"0,', ':"0.'
[System.IO.File]::WriteAllText(".\dagtarief.txt", $TarievenVandaag)[/quote]
[quote]

[ Voor 92% gewijzigd door antoinevromen op 13-10-2025 19:44 ]

[antoinevromen]

Ps. aan je naam zou ik afleiden dat je ook World of Tanks speelt/hebt gespeeld? (ik heb een o.a een E-100 IS7, maar speel het sinds de oorlog in Oekraine niet meer gezien de betrokkenheid van Wit-Rusland.

[ Voor 44% gewijzigd door antoinevromen op 13-10-2025 19:37 ]

[WargamingPlayer]

antoinevromen schreef op maandag 13 oktober 2025 @ 19:35:
Ps. aan je naam zou ik afleiden dat je ook World of Tanks speelt/hebt gespeeld? (ik heb een o.a een E-100 IS7, maar speel het sinds de oorlog in Oekraine niet meer gezien de betrokkenheid van Wit-Rusland.

WoT en WoW/

Maar WoT vind ik niet zo leuk meer na laatste wijzigingen. Te ingewikkeld geworden met alle keuzes. Nu alleen nog Warships

[AUijtdehaag]

@antoinevromen
Ik krijg weer een zere duim van het scrollen

[antoinevromen]

AUijtdehaag schreef op maandag 13 oktober 2025 @ 19:42:
@antoinevromen
Ik krijg weer een zere duim van het scrollen

Your welcome, Bad habits seldom die

[antoinevromen]

@AUijtdehaag Ik heb (door jouw op het idee gebracht) in mijn script ook een strategie ingebouwd om op het laagste-uur te laden en op het duurste uur te ontladen.
Psychologisch voelt het raar om een volle batterij leeg te storten, terwijl je nog de rest van de nacht door moet komen (en daar dus van het net moet intrekken), maar vandaag of morgen zijn uitgelezen dagen met een flinke delta tussen die 2 uren.
Wat gebruik jij uit ervaring als grenswaarde voor dat verschil waar je zegt het loont nog om te laden/ontladen op basis van verschillen in prijzen op laagste/duurste uur? (ik kan het wel exact berekenen wanneer ik rekening houdt met RTE, maar ik vind dat er minstens x-cent winst zou moeten zijn anders zou ik het niet doen om de batterij niet onnodig te verslijten.

Overigens; Ik heb zelf nog geen dynamisch contract, maar houd me er nu met het powershell-script meer mee bezig. Is dat normaal dat opeens de prijs in de top-uren 60/70-cent per kWh is? Of zijn zich hier nu ook alweer energieboeren aan het verrijken aan? (misschien zie ik spoken)

[WargamingPlayer]

WargamingPlayer schreef op maandag 13 oktober 2025 @ 19:25:
Stap twee in mijn pogingen om de winter door te komen is de prijzen op te halen. Daarvoor gebruik ik ENTSO-e. Heb netjes de API key, maar toch werkt de integratie niet in HA. Want om een schema te maken is ook de prijs van belang. Niet de huidige prijs, die haal ik anders binnen, maar wel de prijzen zoals deze bepaald worden voor de hele dag. Ik wacht nog even af of er vannacht nog wat binnen gaat komen, maar heb zo mijn twijfels.

Django/Jinja:

{% set s = {"extra_cost": 0.04,"energie_belasting": 0.1088,"VAT": 1} %} 
{{((current_price + s.extra_cost + s.energie_belasting) * s.VAT) | float}}

Inmiddels opgelost, de originele integratie is "kapot" op de 15 minuten prijzen. Gelukkig is er een goede fork.

[AUijtdehaag]

@antoinevromen
Het liefst hou je nog wat reserve in de batterij om de ochtendpiek te overbruggen.
Gisteravond heb ik iets teveel “gedumpt” a 48 ct, waardoor ik nu weer moet bijladen.

Vanavond is er weer een grote piek.
Afhankelijk van de zonopwek (solarcast ?) zou ik dan wel of niet moeten bijladen overdag.
Allemaal ideeen maar nog handwerk voor nu.

Het verschil tussen inkoop en verkoop moet 15 ct zijn ivm belastingen om interessant te zijn dacht ik

Ik waardeer je werk enorm maar ik blijf het liefste bij nodered voor de sturing.

[ Voor 11% gewijzigd door AUijtdehaag op 14-10-2025 04:19 ]

[robkrekel]

antoinevromen schreef op maandag 13 oktober 2025 @ 20:05:
Overigens; Ik heb zelf nog geen dynamisch contract, maar houd me er nu met het powershell-script meer mee bezig. Is dat normaal dat opeens de prijs in de top-uren 60/70-cent per kWh is? Of zijn zich hier nu ook alweer energieboeren aan het verrijken aan? (misschien zie ik spoken)

Dat gebeurd de laatste tijd vaker als er geen wind en geen zon is, en Duitsland gaat opeens overal stroom inkopen.

Handig, die kerncentrales uitzetten....

[antoinevromen]

AUijtdehaag schreef op dinsdag 14 oktober 2025 @ 03:55:
@antoinevromen
Het liefst hou je nog wat reserve in de batterij om de ochtendpiek te overbruggen.
Gisteravond heb ik iets teveel “gedumpt” a 48 ct, waardoor ik nu weer moet bijladen.

Vanavond is er weer een grote piek.
Afhankelijk van de zonopwek (solarcast ?) zou ik dan wel of niet moeten bijladen overdag.
Allemaal ideeen maar nog handwerk voor nu.

Het verschil tussen inkoop en verkoop moet 15 ct zijn ivm belastingen om interessant te zijn dacht ik

Ik waardeer je werk enorm maar ik blijf het liefste bij nodered voor de sturing.

[Afbeelding]

Ja nu met salderen is 15 ct oke ivm rte verlies. Ik heb dit inderdaad nu geautomatiseerd in het script erbij. Maar iedereen moet gebruiken waar hij affiniteit mee heeft. Dat is het mooie van deze batterij dat je op diverse wijzen kunt sturen. Ook dat van zonvoorspelling zit er in, maar dat is toch vrij ruime schatting. Ik heb nu geprogrammeerd beide batterijen 1 uur laden op minimum tarief en beiden ontladen 1 uur op max tarief, dan blijft per saldo meer in de batterijen achter dan ik erin heb gestopt omdat ik de tweede op 800W heb staan. Toch een deel winst pakken met tariefverschil maar ook genoeg overhouden. Wat je moet overhouden om de volgende piek door te komen is ook weer een schatting en afhankelijk van verbruik

[superduper1969]

Vandaag mijn laadstrategie getest en het lijkt te werken.
Deze is wel afhankelijk van de goede werking van de AI mode.
Ik heb dit gemaakt voor 1 batterij deze staat op een eigen groep zodat ik ook 2500W kan terugleveren.

Het idee is alleen de Workmode aan te passen naar AI, NOM, Manual Mode.
Voor Manual Mode heb ik via de APP een schema gecreëerd om van 00:01 tot 23:59 terug te leveren met 2500W.

De helper zet de prijsdata van Zonneplan om naar een goedkoopste en duurste prijs van die dag.
Ik denk dat weersvoorspelling van zon en windenergie al aardig goed verwerkt zitten in het day ahead model.
Ik doe (nog) niets met de voorspelling van de volgende dag.

Resultaten zijn gunstig vandaag:



Helper om de hoogste en laagste prijs te bepalen:
zonneplanprijs.yaml

code:

template:
  - sensor:
      - name: "Goedkoopste uurprijs vandaag"
        state: >
          {% set forecast = state_attr('sensor.zonneplan_current_electricity_tariff', 'forecast') %}
          {% set vandaag = now().date() %}
          {% set vandaag_forecast = forecast | selectattr('datetime', 'search', vandaag|string) | list %}
          {% set goedkoopste = vandaag_forecast | sort(attribute='electricity_price') | first %}
          {{ (goedkoopste.electricity_price / 10000000) | round(3) }}
        unit_of_measurement: "€/kWh"
        device_class: monetary
        state_class: measurement

      - name: "Duurste uurprijs vandaag"
        state: >
          {% set forecast = state_attr('sensor.zonneplan_current_electricity_tariff', 'forecast') %}
          {% set vandaag = now().date() %}
          {% set vandaag_forecast = forecast | selectattr('datetime', 'search', vandaag|string) | list %}
          {% set duurste = vandaag_forecast | sort(attribute='electricity_price') | last %}
          {{ (duurste.electricity_price / 10000000) | round(3) }}
        unit_of_measurement: "€/kWh"
        device_class: monetary
        state_class: measurement

Automation:
Actie 1:
Kijken of er op die dag een moment is die rechtvaardigt om tegen 35 cent of meer terug te leveren via manual mode.
Actie 2:
Bij lagere prijzen naar AI of NOM met een drempel prijsverschil van 0.12 cent.

code:

alias: Moduskeuze op basis van stroomprijs en prijsverschil
triggers:
  - minutes: /5
    trigger: time_pattern
conditions: []
actions:
  - choose:
      - conditions:
          - condition: template
            value_template: >
              {{ states('sensor.zonneplan_current_electricity_tariff') | float >
              0.36 }}
        sequence:
          - target:
              entity_id: select.lilygo_rs485_marstek_user_work_mode
            data:
              option: manual
            action: select.select_option
      - conditions:
          - condition: template
            value_template: >
              {{ states('sensor.zonneplan_current_electricity_tariff') | float
              <= 0.36 }}
        sequence:
          - choose:
              - conditions:
                  - condition: template
                    value_template: >
                      {{ (states('sensor.duurste_uurprijs_vandaag') | float -
                      states('sensor.goedkoopste_uurprijs_vandaag') | float) >
                      0.12 }}
                sequence:
                  - target:
                      entity_id: select.lilygo_rs485_marstek_user_work_mode
                    data:
                      option: ai
                    action: select.select_option
              - conditions:
                  - condition: template
                    value_template: >
                      {{ (states('sensor.duurste_uurprijs_vandaag') | float -
                      states('sensor.goedkoopste_uurprijs_vandaag') | float) <=
                      0.12 }}
                sequence:
                  - target:
                      entity_id: select.lilygo_rs485_marstek_user_work_mode
                    data:
                      option: selfconsumption
                    action: select.select_option
mode: single

[ Voor 24% gewijzigd door superduper1969 op 15-10-2025 19:13 . Reden: Automation aangepast ]

[r03n_d]

@superduper1969 ik heb iets soortgelijks, maar dan via een andere route. Ik gebruik een combinatie van solcast en "cheapest-energy-prices". Standaard staat de batterij bij mij in AI mode, maar daarin laadt hij te weinig op (als de stroom duur is is de batterij leeg). Ik laat cheapest-energy-prices de 3 goedkoopste uren per dag selecteren, en laat gedurende die uren de batterij geforceerd laden, tenzij de prognose voor stroomopwekking dat uur meer dan 1000 wat is; dan laat ik hem gewoon op die stroom opladen.

De volgende stap is er iets in verwerken dat er voor zorgt dat hij niet gaat ontladen als het prijsverschil maar een paar cent is.

[ Voor 11% gewijzigd door r03n_d op 15-10-2025 07:43 ]

[HiHaHors]

@superduper1969 Dat is een mooie strategie! Hoe heb je die bedragen 0.35 en 0.12 bepaald?

[superduper1969]

12 cent is ongeveer wat door anderen genoemd wordt nadat ze een berekening hebben gedaan.
6 cent aan afschrijving en een 2 a 3 cent ontlaadverliezen + een gokje van mij = 12 cent.
Als je het zoekwoord cent gebruikt in het het hoofdforum zie je zat berekeningen.
Die 35 cent komt uit de gegevens van Zonneplan waarbij je tegenwoordig ook een aantal dagen in de week een sterke stijging ziet voor 2 uren, en met een volle accu kun je met 2500w net je accu leegdumpen voor 35cent of meer in die 2 uur.
Ik heb in de afgelopen maanden gemonitord , soms ook bijna 60 cent maar eigenlijk nooit meer dan 2 uur achter elkaar.
Soms is er nog een ochtend piekje van 1 uur, ik heb deze nooit 2 uur achter elkaar gezien. Als er een AI lading is geweest in de nacht kun je die ook nog meepakken en houd je een halfvolle accu over aan de start van de dag.

[WargamingPlayer]

superduper1969 schreef op donderdag 16 oktober 2025 @ 16:00:
12 cent is ongeveer wat door anderen genoemd wordt nadat ze een berekening hebben gedaan.
6 cent aan afschrijving en een 2 a 3 cent ontlaadverliezen + een gokje van mij = 12 cent.
Als je het zoekwoord cent gebruikt in het het hoofdforum zie je zat berekeningen.
Die 35 cent komt uit de gegevens van Zonneplan waarbij je tegenwoordig ook een aantal dagen in de week een sterke stijging ziet voor 2 uren, en met een volle accu kun je met 2500w net je accu leegdumpen voor 35cent of meer in die 2 uur.
Ik heb in de afgelopen maanden gemonitord , soms ook bijna 60 cent maar eigenlijk nooit meer dan 2 uur achter elkaar.
Soms is er nog een ochtend piekje van 1 uur, ik heb deze nooit 2 uur achter elkaar gezien. Als er een AI lading is geweest in de nacht kun je die ook nog meepakken en houd je een halfvolle accu over aan de start van de dag.

(Aanschafprijs/6000)=Prijs per Cycle
Je moet echter in 10 jaar afschrijven ipv 16.
(PPC/10)*16=Prijs per Cycle corrected
Een Cycle is 5.120*0,89=4.556,8 uit
Een Cycle is 4.556,8*(100/rendement)=Wh
Een Cycle in kWh is dus (Wh in/1000)
Een kWh kost dus (Kost per cycle/kWh in)

(1300/6000)=0,217
(0,217/10)*16=0,347
4.556,8*(100/74)=6.157,838
6.157,838/1000=6,158
0,347/6,158=0,0563

Dus voor 1 accu kost moet het verschil tussen inkoop en verkoop ten minste € 0,0563 cent zijn. Bij 1 accu.

Bij 2 accu’s veranderd er niet veel, de prijs is misschien ander, aantal cycli blijft gelijk.
In mijn situatie is accu 1:
1.800/6000=0,3
(0,3/10)*16=0,48
4.556,8*(100/73)=6.242,192
6.242,192/1000=6,242
0,48/6,242192=0,0769
Voor accu 2 is het:
0,0563

Dus voor mij geldt: 0,0563+0,0769=0,133 = € 0,14

Dus in moet ontladen naar het net of zelf consumptie hebben met 14 cent hoger tarief om de afschrijving terug te verdienen.

Daarom is het van belang om de inkoop kosten zo laag mogelijk te hebben. In de zomer wanneer tarief overdag 0 is maak je winst in de uren dat verbruik hoog is en kosten van net afname hoog is. Zolang je kan salderen is dat niet echt een usecase, maar op het moment dat je niet kan salderen dan wordt het economisch heel aantrekkelijk. Want dan krijg je dus nul voor je stroom en maak je de winst op momenten dat je normaal zou betalen.

[Kees-Jan]

superduper1969 schreef op dinsdag 14 oktober 2025 @ 23:03:
Vandaag mijn laadstrategie getest en het lijkt te werken.
Deze is wel afhankelijk van de goede werking van de AI mode.
Ik heb dit gemaakt voor 1 batterij deze staat op een eigen groep zodat ik ook 2500W kan terugleveren.

Het idee is alleen de Workmode aan te passen naar AI, NOM, Manual Mode.
Voor Manual Mode heb ik via de APP een schema gecreëerd om van 00:01 tot 23:59 terug te leveren met 2500W.

De helper zet de prijsdata van Zonneplan om naar een goedkoopste en duurste prijs van die dag.
Ik denk dat weersvoorspelling van zon en windenergie al aardig goed verwerkt zitten in het day ahead model.
Ik doe (nog) niets met de voorspelling van de volgende dag.

Resultaten zijn gunstig vandaag:
[Afbeelding]


Helper om de hoogste en laagste prijs te bepalen:
zonneplanprijs.yaml

code:

template:
  - sensor:
      - name: "Goedkoopste uurprijs vandaag"
        state: >
          {% set forecast = state_attr('sensor.zonneplan_current_electricity_tariff', 'forecast') %}
          {% set vandaag = now().date() %}
          {% set vandaag_forecast = forecast | selectattr('datetime', 'search', vandaag|string) | list %}
          {% set goedkoopste = vandaag_forecast | sort(attribute='electricity_price') | first %}
          {{ (goedkoopste.electricity_price / 10000000) | round(3) }}
        unit_of_measurement: "€/kWh"
        device_class: monetary
        state_class: measurement

      - name: "Duurste uurprijs vandaag"
        state: >
          {% set forecast = state_attr('sensor.zonneplan_current_electricity_tariff', 'forecast') %}
          {% set vandaag = now().date() %}
          {% set vandaag_forecast = forecast | selectattr('datetime', 'search', vandaag|string) | list %}
          {% set duurste = vandaag_forecast | sort(attribute='electricity_price') | last %}
          {{ (duurste.electricity_price / 10000000) | round(3) }}
        unit_of_measurement: "€/kWh"
        device_class: monetary
        state_class: measurement

Automation:
Actie 1:
Kijken of er op die dag een moment is die rechtvaardigt om tegen 35 cent of meer terug te leveren via manual mode.
Actie 2:
Bij lagere prijzen naar AI of NOM met een drempel prijsverschil van 0.12 cent.

code:

alias: Moduskeuze op basis van stroomprijs en prijsverschil
triggers:
  - minutes: /5
    trigger: time_pattern
conditions: []
actions:
  - choose:
      - conditions:
          - condition: template
            value_template: >
              {{ states('sensor.zonneplan_current_electricity_tariff') | float >
              0.36 }}
        sequence:
          - target:
              entity_id: select.lilygo_rs485_marstek_user_work_mode
            data:
              option: manual
            action: select.select_option
      - conditions:
          - condition: template
            value_template: >
              {{ states('sensor.zonneplan_current_electricity_tariff') | float
              <= 0.36 }}
        sequence:
          - choose:
              - conditions:
                  - condition: template
                    value_template: >
                      {{ (states('sensor.duurste_uurprijs_vandaag') | float -
                      states('sensor.goedkoopste_uurprijs_vandaag') | float) >
                      0.12 }}
                sequence:
                  - target:
                      entity_id: select.lilygo_rs485_marstek_user_work_mode
                    data:
                      option: ai
                    action: select.select_option
              - conditions:
                  - condition: template
                    value_template: >
                      {{ (states('sensor.duurste_uurprijs_vandaag') | float -
                      states('sensor.goedkoopste_uurprijs_vandaag') | float) <=
                      0.12 }}
                sequence:
                  - target:
                      entity_id: select.lilygo_rs485_marstek_user_work_mode
                    data:
                      option: selfconsumption
                    action: select.select_option
mode: single

Dit gaat toch alleen goed als het teruglever-tijdstip láter is dan het goedkoopste laad-tijdstip? Het gebeurd wel eens dat de piek in de ochtend is rond 08:00, en het goedkoopste laad-tijdstipin de middag, rond 14:00.
Eigenlijk zou je de prijs van het laad-tijdstip moeten opslaan en die gebruiken op de rest van de dag te kijken of de prijs op het teruglever-tijdstip (ergens later op de dag) een positieve delta heeft (van minimaal x cent) tov de prijs van het laad-tijdstip; dan maakt het niet uit wát de prijs is, maar als er voldoende delta-prijs is je tóch kunt verdienen aan het terugleveren van de energie...

of heb ik het fout?

[superduper1969]

Kees-Jan schreef op zaterdag 18 oktober 2025 @ 09:35:
[...]

Dit gaat toch alleen goed als het teruglever-tijdstip láter is dan het goedkoopste laad-tijdstip? Het gebeurd wel eens dat de piek in de ochtend is rond 08:00, en het goedkoopste laad-tijdstipin de middag, rond 14:00.
Eigenlijk zou je de prijs van het laad-tijdstip moeten opslaan en die gebruiken op de rest van de dag te kijken of de prijs op het teruglever-tijdstip (ergens later op de dag) een positieve delta heeft (van minimaal x cent) tov de prijs van het laad-tijdstip; dan maakt het niet uit wát de prijs is, maar als er voldoende delta-prijs is je tóch kunt verdienen aan het terugleveren van de energie...

of heb ik het fout?

In de vorige winter waren er vaak goedkoopste momenten om 01:00 dus dan kan de ochtendpiek worden meegenomen.
En als er voor de ochtendpiek geen goedkoop moment is dan is het vaak ook niet de moeite om daarvoor te gaan laden.

[Hometek]

NOM met PV stroom op donkere dagen met kleine prijsverschillen

Zoals diverse anderen hier al opgemerkt hebben is het opladen van het net en vervolgens NOM draaien niet altijd een goede strategie. NOM heeft pas zin als de actuele stroomprijs duidelijk hoger is dan tijdens het opladen. Hoe groot dat verschil moet zijn zal van de situatie afhangen, in dit voorbeeld gebruik ik gemakshalve 25%, maar het zou ook een vast bedrag kunnen zijn.

Ik regel de modus van mijn batterij via HA en gebruik een voorspelling om te bepalen of er voldoende PV opwek zal zijn of dat er van het net bijgeladen moet worden. Opladen gebeurt altijd op het goedkoopste moment van de dag.
Als de prijs tijdens het opladen 20ct is, zal ik deze stroom pas voor NOM inzetten als de actuele prijs 25% hoger is, dus 25ct of meer.
Als ik geen NOM draai, zet ik de Max. Discharge op 0W, de batterij blijft dan opladen als er PV overschot is. Deze stroom kan wel gebruikt worden voor NOM ongeacht de actuele prijs, maar bij voorkeur gebruik ik deze stroom tijdens de dure uren.

Om onderscheid te kunnen maken tussen de ‘ingekochte’ netstroom en de ‘gratis’ PV stroom in de batterij gebruik ik een teller die de SOC verandering telt op het moment dat er van PV geladen wordt.
Als ik niet geforceerd oplaad maar de SOC stijgt van bv. 40% naar 60% dan gaat de PV teller van 0 naar 20. In de batterij is dan 40% van de capaciteit van het net en 20% van PV. Die 20% PV kan ik nu voor NOM gebruiken tijdens de dure uren. Daarbij gaat de PV teller dan van 20 naar 0. Bij 0 stopt de NOM.

Het tellen van SOC is uiteraard geen absoluut accurate manier om PV en netstroom ‘eenheden’ te tellen, maar het leek mij een redelijke benadering om het systeem iets efficiënter in te zetten.

[SatScan]

Om wat meer in HA bekwaam te worden heb ik deze POCs gebouwd met mijn persoonlijke gegevens.
Next step is om de dynamische energieprijs er aan te koppelen en dan parallel laten werken om te zien wat in mijn situatie het voordeligst is.

De vergelijking tussen statische en Dynamisch toegevoegd. De opslag voor beide gelijk aangehouden.
Op deze manier kan ik de komende maanden zien welk energiecontract het beste bij mij gaat passen irt de twee MT PIB. Tot nu toe is mijn huidige vaste prijs energiecontract het effectiefste met mijn energieprofiel.

[ Voor 31% gewijzigd door SatScan op 28-10-2025 08:44 ]

[Hometek]

SatScan schreef op zondag 26 oktober 2025 @ 14:09:
Om wat meer in HA bekwaam te worden heb ik deze POCs gebouwd met mijn persoonlijke gegevens.
Next step is om de dynamische energieprijs er aan te koppelen en dan parallel laten werken om te zien wat in mijn situatie het voordeligst is.
...

Ik zie bij mij dat met een dynamisch contract op dagen zonder zon en kleine prijsverschillen de gevolgde strategie voor laden en NOM belangrijk is.
Het is nadelig om de batterij op NOM te zetten als de actuele prijs niet ca. 25% hoger is dan de prijs tijdens opladen.
Nog ingewikkelder wordt het als er meerdere dagen achtereen zijn waarbij de batterij niet leeg raakt omdat de prijsverschillen te klein zijn, maar er wel weer opgeladen wordt. Dat bij-laden gebeurt dan telkens met een andere prijs. Dan moet je bijhouden hoeveel kWh er met welke prijs is 'ingekocht' en dienovereenkomstig alleen NOM gebruiken zolang er nog kWh beschikbaar zijn met een inkoop prijs die laag genoeg was.

[JanAllElectric]

Hometek schreef op maandag 3 november 2025 @ 13:24:
[...]

Ik zie bij mij dat met een dynamisch contract op dagen zonder zon en kleine prijsverschillen de gevolgde strategie voor laden en NOM belangrijk is.
Het is nadelig om de batterij op NOM te zetten als de actuele prijs niet ca. 25% hoger is dan de prijs tijdens opladen.
Nog ingewikkelder wordt het als er meerdere dagen achtereen zijn waarbij de batterij niet leeg raakt omdat de prijsverschillen te klein zijn, maar er wel weer opgeladen wordt. Dat bij-laden gebeurt dan telkens met een andere prijs. Dan moet je bijhouden hoeveel kWh er met welke prijs is 'ingekocht' en dienovereenkomstig alleen NOM gebruiken zolang er nog kWh beschikbaar zijn met een inkoop prijs die laag genoeg was.

Aangezien voor mij zelfgebruik de belangrijkste drijfveer is draai ik toch NOM als die 25% (bij een RTE van ca 80%) maar deels wordt gehaald.

Wel onder condities dat er voldoende (toekomstige) PV-opbrengst is en/of voldoende (toekomstige) laadmomenten met marge >=25% zijn. Op deze manier weet ik zeker dat de accu in het verleden is opgeladen met een marge >=25%.

Aanname (niet berekend): winst en verlies bij NOM draaien middelt dan bij dit soort vlakke dagen en enkele uitschieters wel uit. @Hometek : als jij een eenvoudige formule hebt houd ik mij aanbevolen Ik heb zelf wel eens gedacht aan een soort gewogen gemiddelde inkoopprijs bij het opladen bij te gaan houden.

Ik vind het toch wel zonde de accu vol ongebruikt te laten .

[ Voor 19% gewijzigd door JanAllElectric op 03-11-2025 15:22 ]

[Hometek]

JanAllElectric schreef op maandag 3 november 2025 @ 15:02:
[...]
Aangezien voor mij zelfgebruik de belangrijkste drijfveer is doe toch NOM als die 25% (bij een RTE van ca 80%) maar deels wordt gehaald. Wel onder condities dat er voldoende (toekomstige) PV-opbrengst is en/of laadmomenten met voldoende marge (>=25%) zijn.

Ik vind het toch wel zonde de accu vol ongebruikt te laten .

Ik maak verschil tussen kWh die van PV of van het net geladen worden.
Eigen kWh (van PV) worden altijd voor NOM gebruikt. Maar als er weinig eigen kWh beschikbaar zijn worden deze alleen tijdens de 8 duurste uren voor NOM gebruikt.
'Ingekochte' kWh (van het net) worden alleen gebruikt als het verschil tussen de prijs tijdens laden met de actuele prijs groot genoeg is.

Ik heb een vrij kleine PV installatie, in deze tijd van het jaar blijft er nauwelijk stroom over. Ik moet het dus vooral hebben van het opladen van het net tijdens de goedkope uren.

[JanAllElectric]

Hometek schreef op maandag 3 november 2025 @ 15:22:
[...]

Ik maak verschil tussen kWh die van PV of van het net geladen worden.
Eigen kWh (van PV) worden altijd voor NOM gebruikt. Maar als er weinig eigen kWh beschikbaar zijn worden deze alleen tijdens de 8 duurste uren voor NOM gebruikt.
'Ingekochte' kWh (van het net) worden alleen gebruikt als het verschil tussen de prijs tijdens laden met de actuele prijs groot genoeg is.

Ik heb een vrij kleine PV installatie, in deze tijd van het jaar blijft er nauwelijk stroom over. Ik moet het dus vooral hebben van het opladen van het net tijdens de goedkope uren.

Ik zat hier nog aan te denken:

Ik heb zelf wel eens gedacht aan een soort gewogen gemiddelde inkoopprijs bij het opladen bij te gaan houden.

Prijs PV is dan bv €0

[ Voor 11% gewijzigd door JanAllElectric op 03-11-2025 15:26 ]

[Hometek]

JanAllElectric schreef op maandag 3 november 2025 @ 15:24:
[...]
Ik zat hier nog aan te denken:

Ik heb zelf wel eens gedacht aan een soort gewogen gemiddelde inkoopprijs bij het opladen bij te gaan houden.

Prijs PV is dan bv €0

Ik ben aan het experimenteren met zoiets: (kWhGRID / (kWhGrid+kWhPV) ) * inkoopprijs
Maar ben er nog niet helemaal uit.

Ik heb nu 7 tellers om opgeslagen kWh/prijs vast te leggen
(7 is vermoedelijk te veel, meestal zijn er maar 4-5 in gebruik)
Je ziet dat de batterij voor ca. 55% gevuld is met 4 verschillende prijzen (prijzen zijn incl. marge)


Deze grafiek toont de actuele prijzen. De groene en grijze lijnen zijn de prijsdrempels voor NOM. In dit geval dus minstens 48 uur geen NOM. Maar er is wel een gelegenheid om vannacht de resterende 45% capaciteit met goedkopere stroom aan te vullen en die stroom dan wel morgen voor NOM te gebruiken.

[JanAllElectric]

Hometek schreef op maandag 3 november 2025 @ 15:44:
[...]

Ik ben aan het experimenteren met zoiets: (kWhGRID / (kWhGrid+kWhPV) ) * inkoopprijs
Maar ben er nog niet helemaal uit.

Ik heb nu 7 tellers om opgeslagen kWh/prijs vast te leggen
(7 is vermoedelijk te veel, meestal zijn er maar 4-5 in gebruik)
Je ziet dat de batterij voor ca. 55% gevuld is met 4 verschillende prijzen (prijzen zijn incl. marge)
[Afbeelding]

Deze grafiek toont de actuele prijzen. De groene en grijze lijnen zijn de prijsdrempels voor NOM. In dit geval dus minstens 48 uur geen NOM. Maar er is wel een gelegenheid om vannacht de resterende 45% capaciteit met goedkopere stroom aan te vullen en die stroom dan wel morgen voor NOM te gebruiken.
[Afbeelding]

Wanneer je echt geen verlies wilt maken zou je alleen NOM mogen draaien
- wat je als PV hebt geladen (liefst op duurdere inkoopmomenten)
- of wat een grotere marge heeft dan 25% op de huidige inkooprijs (anders kan je beter GRID kopen).

Aangezien ik nog een vast contract heb tot eind 2026 werkt mijn software al in de "geen salderings mode". Dat betekent dat ik vandaag (tot nu toe) 0 kWh mag ontladen in NOM (PV geladen = 0 kWh) en dat ik morgenmiddag om 16:25 1 kwartier kan mag ontladen in NOM met voldoende marge .

Misschien dat ik ook nog kan kijken naar toekomstige PV-opbrengst. Die is morgen ca 9.1kWh, waarvan ik ca 60% kan laden: 5,5kWh.

[ Voor 4% gewijzigd door JanAllElectric op 03-11-2025 16:45 ]

[Hometek]

JanAllElectric schreef op maandag 3 november 2025 @ 16:31:
[...]
Wanneer je echt geen verlies wilt maken zou je alleen NOM mogen draaien
- wat je als PV hebt geladen (liefst op duurdere inkoopmomenten)
- of wat een grotere marge heeft dan 25% op de huidige inkooprijs (anders kan je beter GRID kopen).

Dat is inderdaad wat ik probeer te realiseren door bij te houden hoeveel kWh uit de batterij tegen welke prijs voor NOM gebruikt kan worden.

[JanAllElectric]

Hometek schreef op maandag 3 november 2025 @ 16:54:
[...]

Dat is inderdaad wat ik probeer te realiseren door bij te houden hoeveel kWh uit de batterij tegen welke prijs voor NOM gebruikt kan worden.

Je hebt me overtuigd om NOM strakker te organiseren. Namelijk alleen op momenten dat marge ook voldoende is om RTE-verlies te compenseren. Dit was eenvoudig in mijn software aan te scherpen.

Ik houd de hoeveelheid 'PV geladen vandaag' bij en ook het ontladen en laden. Een extra teller om bij te houden of ik dan NOM met PV kan draaien moet niet zo moeilijk zijn. NOM dan alleen op de duurdere momenten. Ik houd nu al "duurder" bij als >=1,15 * gemiddelde prijs. Zo werkt ook mijn CFOS laadstation voor EV, maar dan voor "goedkoper" als <= 0.9 * gemiddelde prijs.

if (pvAccuIn - accuOntladen ) > 0 && prijsHuidigKwartier === 'duurder') { NOM } else { IDLE}

Verder blijf ik vooralsnog de accu's NOM ontladen (=leeg genoeg maken) wanneer er voldoende toekomstige PV-opbrengst is of laadmomenten met voldoende marge.

[ Voor 4% gewijzigd door JanAllElectric op 03-11-2025 17:54 ]

[ThaReaper]

Vanuit het niets is vandaag de home assistant hamerelay en hame2mqtt combo er mee gestopt. Hebben meer mensen hier last van? Hamerelay lijkt zijn werk te doen als ik de logs bekijk, maar hame2mqtt zegt geen gegevens te krijgen en loopt op een timeout

[dannyro]

ThaReaper schreef op vrijdag 7 november 2025 @ 13:22:
Vanuit het niets is vandaag de home assistant hamerelay en hame2mqtt combo er mee gestopt. Hebben meer mensen hier last van? Hamerelay lijkt zijn werk te doen als ik de logs bekijk, maar hame2mqtt zegt geen gegevens te krijgen en loopt op een timeout

Neen, hier werkt alles normaal.

[JanAllElectric]

ThaReaper schreef op vrijdag 7 november 2025 @ 13:22:
Vanuit het niets is vandaag de home assistant hamerelay en hame2mqtt combo er mee gestopt. Hebben meer mensen hier last van? Hamerelay lijkt zijn werk te doen als ik de logs bekijk, maar hame2mqtt zegt geen gegevens te krijgen en loopt op een timeout

Leve de lilygo/modbus koppeling. Ik blijf op mijn 3 Marsteks V2 lekker op firmware 151, geen ct003 koppeling en ook de app niet (meer) nodig. Werkt vanaf 1-5-2025 probleemloos.