Marstek & domotica; slim sturen en je Energierekening

[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

[Verwijderd]

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 Verwijderd op 30-09-2025 19:38 ]

[Verwijderd]

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]

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

[...]

Hallo @Verwijderd ,
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?

[Verwijderd]

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

Hallo @Verwijderd ,
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 Verwijderd 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.

[SatScan]

Zo nu weer flinke stappen gemaakt met HA, Hier een voorbeeld. De DB is zich nu aan het vullen en over een tijdje heb ik een actueel beeld met voorspellingen die elke dag nauwkeuriger worden.

[dannyro]

SatScan schreef op vrijdag 19 december 2025 @ 19:27:
Zo nu weer flinke stappen gemaakt met HA, Hier een voorbeeld. De DB is zich nu aan het vullen en over een tijdje heb ik een actueel beeld met voorspellingen die elke dag nauwkeuriger worden.

[Afbeelding]

Zeer proper werk. Wel prettig wat men daar allemaal mee kan. Ik ben er ook helemaal weg van. Mooi

[SatScan]

HOME BATTERY CONTROL

** weer mooie nieuwe ontwikkelingen **

Sinds kort gebruik ik dit zelf en ik ben er erg tevreden over. Het werkt stabiel en geeft goede inzichten.

Omdat we dit jaar nog kunnen salderen, is dit een uitstekende periode om verschillende strategieën te testen binnen je eigen energiehuishouding. Denk aan laden/ontladen, verbruik sturen en het combineren van PV, batterij en dynamische prijzen.

Alles wat je nu test en optimaliseert, helpt om goed voorbereid te zijn op 2027 en verder, wanneer salderen volledig verdwijnt. Dan worden keuzes écht belangrijk.

Daarbij spelen twee zaken een centrale rol:
- het kiezen van het juiste energiecontract (vast, variabel of dynamisch)
- de bijbehorende strategieën voor je P1/energiemanagement (PIB), afgestemd op jouw situatie

Deze video geeft een goed overzicht hoe je PIB daar slim voor kunt inzetten :
YouTube: New in version 4.0 of free Home Battery Control for Home Assistant

[Hometek]

Interessante (zij het wat lange) video van de groene nerds over negatieve energieprijzen als salderen is afgeschaft.
Negative bruto prijzen zullen dan vaker ook negatieve netto prijzen opleveren.
Voor iedereen die toch al met domotica bezig is zou ik daarom advieseren: kijk alvast eens naar de mogelijkheden on je zonnepanelen geautomatiseerd te dimmen of uit te schakelen. De (on)mogelijkheden zullen bij iedereen anders zijn, maar je hebt nog bijna 1 jaar de tijd om te bedenken wat je zou kunnen en/of zou willen doen.

[AUijtdehaag]

@Hometek Dat heeft weinig met einde salderen te maken.
Negatieve energie prijzen heb je nu al (hoewel maar enkele dagen) met een dynamisch kontrakt dus dat dimmen zit hier al in. (SMA modbus tcp/ip)
Edit: het wordt wel wat spannender inderdaad na afschaffing salderen met die twilight zone (sorry had filmpje nog niet gezien)

[ Voor 24% gewijzigd door AUijtdehaag op 12-03-2026 16:03 ]

[Tazzios]

Het viel mij op dat er in de TS maar 1 oplossing bij 'Kant en Klare oplossingen' staat.
Ter aanvulling zijn nog 3 andere:

• https://github.com/ffunes/Marstek-Venus-Energy-Manager
• https://github.com/Tazzios/ha-marstek/tree/main/blueprints
• https://github.com/diegoschlauri/marstek_venus_ha

(ja, ook eentje van mijzelf. )

[ Voor 11% gewijzigd door Tazzios op 14-03-2026 09:41 ]

[Mattie112]

Het was even klooien om alles geinstalleerd te krijgen (vooral: in welke mappen van HA moet ja alles zetten en hoe werkt NodeRed). Maar ik heb de boel nu draaien. Ben heel benieuwd. Tijdje "AI" modus gedraaid maar dat sloeg echt nergens op. Opladen met €0,20 en 'verkopen' (of NOM) met €0,21. Ja doei! Toen een tijd lang NOM maar met het weer nu kunnen ze zomaar 'vol' zitten of juist leeg zijn terwijl de stroom wel duur is dus dan lijkt het me interessant als dit wat slimmer te regelen is.

Ik wil dus ook draag de 'dynamic' strategie gebruiken. Maar ik weet niet of ik het nou correct heb.

Wat heb ik geinstalleerd:
- https://github.com/TheFes/cheapest-energy-hours/
- https://github.com/HiDiHo01/home-assistant-frank_energie

In de documentatie van 'cheapest hours' staat:

code:

These parameters are used to determine where the source data can be found. If you use the custom Nordpool integration (can be downloaded using HACS), or an integration which uses the same attributes, you don't need to provide any of the parameters, but it is advised to provide the sensor as it will be more resource friendly if the macro doesn't need to search for it.

Ik begrijp dat dit anders is dan de 'normale' (niet HACS) Nordpool integratie? Maar heb ik die nou wel of niet nodig? Op het dashboard kies in namelijk niet voor Nordpool maar voor Frank.



Of ben ik te ongeduldig en duurt het even voordat dit goed staat?

[Tazzios]

@Mattie112 frank gaat niet werken "or an integration which uses the same attributes". De integratie gebruikt waarschijnlijk de attributen today en tomorrow (waar de kwartieren en de prijzen in staan) die in de Nordpool entiteit zitten, frank heeft ze niet.

De integratie zelf heb ik wel eens bekeken, maar ben toch bij deze gebleven: https://github.com/kotope/aio_energy_management. Er zijn er tegenwoordig aardig wat.

[amvolleb]

Ik heb Home Battery Control geïnstalleerd en probeer daarmee mijn 3 batterijen aan te sturen. Probleem is dat de PID controller bij mij blijkbaar niet goed werkt want hij gaat ipv de batterijen te ontladen (aangezien stroom van het net wordt gehaald) batterijen maximaal opladen. Grid Power schiet omhoog wat dan door PID control wordt gecompenseerd, maar ondertussen neem ik netto stroom van het net af ipv de batterijen te ontladen. Het aanpassen van de controller sensitivity heeft geen effect.
Het heeft eergisteren wel goed gewerkt, maar daarna weer tijdje de CT003 gebruikt en werkt het niet meer.
Iemand een idee?

[SatScan]

amvolleb schreef op woensdag 18 maart 2026 @ 20:48:
Ik heb Home Battery Control geïnstalleerd en probeer daarmee mijn 3 batterijen aan te sturen. Probleem is dat de PID controller bij mij blijkbaar niet goed werkt want hij gaat ipv de batterijen te ontladen (aangezien stroom van het net wordt gehaald) batterijen maximaal opladen. Grid Power schiet omhoog wat dan door PID control wordt gecompenseerd, maar ondertussen neem ik netto stroom van het net af ipv de batterijen te ontladen. Het aanpassen van de controller sensitivity heeft geen effect.
Het heeft eergisteren wel goed gewerkt, maar daarna weer tijdje de CT003 gebruikt en werkt het niet meer.
Iemand een idee?

Lastig zeggen zo uit het niets.. maar heb je in eerste tabblad de sturing goed staan? (control mode) en Controller sen.. op Safe
Laatste tabblad Nummer batterijen op 3 - Hysteries op 10w de Cuttoff en Max power goed staan.
Derde tabblas Default stratery op Self-consumption. Eventeel tariefsensor uit de lijst als die in HA is geïnstalleerd.
En dan de Vijfde tabblad zet insight mode aan en kijk of het juist werkt. Maak wat screenshots om het verscil te kunnen bekijen als het nog niet goed werkt.

Succes het draait hier als een zonnetje met 4.60 icm 2 batterijen

[amvolleb]

SatScan schreef op zondag 22 maart 2026 @ 16:40:
[...]

Lastig zeggen zo uit het niets.. maar heb je in eerste tabblad de sturing goed staan? (control mode) en Controller sen.. op Safe
Laatste tabblad Nummer batterijen op 3 - Hysteries op 10w de Cuttoff en Max power goed staan.
Derde tabblas Default stratery op Self-consumption. Eventeel tariefsensor uit de lijst als die in HA is geïnstalleerd.
En dan de Vijfde tabblad zet insight mode aan en kijk of het juist werkt. Maak wat screenshots om het verscil te kunnen bekijen als het nog niet goed werkt.

Succes het draait hier als een zonnetje met 4.60 icm 2 batterijen

Excuses dat ik je reactie gemist heb. De fout bleek te zitten in dat al een waarde had staan voor de forcible charge power (2500W), na die op 0 gezet hebben gaat het wel goed.

[Hometek]

1 jaar met de Marstek Venus E

Ik heb de Venus E nu een vol jaar in gebruik, en ca. 10 maanden met aansturing via HA.
Mijn huis en PV wijken nogal af van de gemiddelde Nederlandse situatie en mijn aansturing vanuit HA vermoedelijk ook, maar het is wellicht toch nuttig voor anderen om enkele algemene ervaringen te delen.

Mijn situatie:

• Klein huis, stroomverbruik per jaar ca. 1500 kWh, dynamisch contract
• 7 plug-in-zonnepanelen, totaal 2.3 kWp (aangestuurd vanuit HA)
• 2 Venus E waarvan steeds 1 actief is en de andere stand by (aangestuurd vanuit HA)

Strategie in HA (opgebouwd en bijgesteld gedurende afgelopen jaar)
Basis data:

• Voorspellen PV opwek (Solcast)
• Voorspellen energieverbruik (berekend op basis van afgelopen 24h)
• Berekenen minimale SOC om de volgende dag te kunnen halen (zie post).
• Bijhouden stroomprijs en SOC verandering bij opladen van net (zie post)

Optionele functies ik aan of uit kan schakelen:

• Opladen van net bij laagste prijs als SOC te ver onder minimum is.
• Opladen van net uitsluitend indien verschil in hoogste en laagste prijs groot genoeg is.
• Ontladen naar net bij hoogste prijs als SOC ver boven minimum is.
• Aantal PV panelen reduceren als verwachte PV opwek hoger is dan verwachte verbruik.
• Ontladen voor NOM beperken tot momenten dat de stroomprijs voldoende verschilt van de prijs tijdens het opladen (opladen blijft actief)

De functie ‘PV reduceren’ is ter voorbereiding op de situatie dat terugleveren geld gaat kosten.
De functie ‘ontladen naar net bij hoogste prijs’ is bedoeld om de beste prijs voor het PV overschot te krijgen en om batterij capaciteit vrij te maken voor de volgende zonnige dag.

Ervaringen:

• Op zeer zonnige dagen levert de PV meer kWh dan de capaciteit van 2 Venus E.
• Met 2 volle Venus E haal ik meestal makkelijk 24h NOM
• Van April tot September levert de PV per 24h gemiddeld meer stroom dan ik verbruik.
• Van November tot April levert de PV per 24h minder stroom dan ik verbruik.
• Het verlies bij de Venus E tussen stroom opslaan en stroom gebruiken is in mijn geval 25-30% (gemiddeld verbruik 150-400W)
• De grootste prijsverschillen waren het afgelopen jaar in de zomer, in de winter waren de prijsverschillen vaak dagenlang erg klein (minder dan 20%).

Voorlopige conclusies:

• Tijdens de zomermaanden zijn de batterijen een zinvolle toevoeging. Eigen PV opwek kan volledig voor eigen gebruik benut worden en overschot kan tegen de beste prijs teruggeleverd worden aan het net. Dit levert denk ik ook een kleine bijdrage om net congestie tegen te gaan.
• In de wintermaanden is het beeld minder duidelijk. PV opbrengst is zo laag dat deze praktisch onmiddellijk voor eigen gebruik benut wordt. De batterijen stonden vaak dagenlang in standby mode omdat de prijsverschillen te klein waren om opgeslagen stroom rendabel te kunnen inzetten. Mogelijk is deze winter door het rustige weer niet representatief omdat er weinig schommelingen waren in de windenergie. Maar ik vraag me af of het niet zinvoller is om de batterijen ‘s winters gewoon helemaal uit te schakelen. Het stroomverbruik standby weegt mogelijk niet op tegen de enkele pieken die je op kunt vangen.
• Met het afschaffen van de saldering is het ook de vraag of een dynamisch contract straks nog wel handig is. Wellicht is een vast contract goedkoper als je toch alleen maar in de wintermaanden stroom afneemt.

De HA aansturing werkt na vele aanpassingen nu redelijk betrouwbaar. Het is ondertussen echter wel een ratjetoe geworden van flows (node-red) en tientallen helpers omdat vele aanpassingen als toevoegingen er ‘tijdelijk’ op geplakt zijn. Deze zomer wil ik dat zakje eens ontwaren en netjes opbouwen.

[PNARI]

Ik heb een variabel contract en moet betalen bij negatieve prijzen bij injectie. Ik zoek nog een oplossing om automatisch de 2 oude omvormers uit te schakelen via een relais bij negatieve prijzen. Iemand daar een oplossing voor ?

[ Voor 30% gewijzigd door PNARI op 01-05-2026 08:06 ]

[SatScan]

PNARI schreef op vrijdag 1 mei 2026 @ 08:02:
Ik heb een variabel contract en moet betalen bij negatieve prijzen bij injectie. Ik zoek nog een oplossing om automatisch de 2 oude omvormers uit te schakelen via een relais bij negatieve prijzen. Iemand daar een oplossing voor ?

hey, kijk hier eens... wie weet: https://www.ecosoftenergie.nl/pv-op-afroep/

[Kees-Jan]

SatScan schreef op vrijdag 1 mei 2026 @ 08:35:
[...]

hey, kijk hier eens... wie weet: https://www.ecosoftenergie.nl/pv-op-afroep/

Gaat via ModBus. Maar dan zou @PNARI toch wel een HA integration kunnen vinden?
Tenminste, als @PNARI Home Assistant gebruikt?
Er zijn ook USB Modbus adapters die @PNARI zou kunnen gebruiken.
En anders via een Raspberry Pi een relais aansturen, maar dan wel de juiste en gescheiden aansluiting gebruiken anders is die Pi binnen 1 seconden in koolstof veranderd...

[PNARI]

Kees-Jan schreef op vrijdag 1 mei 2026 @ 20:04:
[...]

Gaat via ModBus. Maar dan zou @PNARI toch wel een HA integration kunnen vinden?
Tenminste, als @PNARI Home Assistant gebruikt?
Er zijn ook USB Modbus adapters die @PNARI zou kunnen gebruiken.
En anders via een Raspberry Pi een relais aansturen, maar dan wel de juiste en gescheiden aansluiting gebruiken anders is die Pi binnen 1 seconden in koolstof veranderd...

Ben helaas niet bekend met HA of python. Ik heb een raspbery gekocht en een via wifi bestuurbaar relais. Eens kijken of ik chatgpt een programma kan laten schrijven.

[sun62]

PNARI schreef op zondag 31 mei 2026 @ 20:44:
[...]

Ben helaas niet bekend met HA of python. Ik heb een raspbery gekocht en een via wifi bestuurbaar relais. Eens kijken of ik chatgpt een programma kan laten schrijven.

Als je al een raspberry pi hebt, kan je misschien node-red gebruiken en mijn script aanpassen. Het werkt met visueel programmeren en is heel laag drempelig. Zie linkje sma hieronder.

[PNARI]

sun62 schreef op zondag 31 mei 2026 @ 20:57:
[...]

Als je al een raspberry pi hebt, kan je misschien node-red gebruiken en mijn script aanpassen. Het werkt met visueel programmeren en is heel laag drempelig. Zie linkje sma hieronder.

Thanks maar mijn sma's zijn van 2009 en 2014. Ik denk niet dat die modbus hebben.

[SatScan]

Uit de praktijk: de EV laden op zon met HBC, HPVC en HESC

Een praktijkvoorbeeld van wat ik de afgelopen weken heb gebouwd en wat goed werkt. Misschien heeft iemand er iets aan, of herkent iemand hetzelfde probleem. Het probleem Ik heb thuis drie systemen die elk hun eigen werk doen: Home Battery Control (HBC) stuurt mijn twee Marsteks (2 × 5,12 kWh). Home PV Control (HPVC) knijpt mijn omvormers af als terugleveren geld kost (prijs ≤ € 0,00). De Wallbox laadt de auto in Eco-Smart: hij start pas als er genoeg teruglevering is. Apart werkt alles prima, maar samen zaten ze vast: de laadpaal wacht op overschot, en HPVC zorgt er juist voor dat dat overschot er nooit komt. De zonnepanelen werden dus afgeknepen, en de auto werd niet geladen terwijl er voldoende zonne-energie was. De oplossing: HESC Daarom heb ik Home EV Solar Control (HESC) gebouwd: een Home Assistant-package met een Node-RED-flow die bepaalt wanneer de auto laadt, op zon of in de goedkoopste uren. Zon-vrijgave: Als de auto aangesloten is en de laadpaal op solar laden staat, HPVC afknijpt en Solcast (voorzichtige schatting) nu én over 30 minuten genoeg zon voorspelt, vraagt HESC HPVC om even opzij te gaan. Komt de auto niet op gang, of valt de zon weg, dan neemt HPVC het meteen weer over. Laadplan: Je stelt een doel in, zoals "100% op dinsdag 10:00" of "80% op werkdagen om 07:30". HESC kiest daarvoor de goedkoopste kwartieren, en slaat netstroom over als de zonvoorspelling het al dekt. Zelfstandig: Sinds v1.1 werkt HESC ook zonder HPVC. Je hebt dan alleen een laadpaal met solar laden en een zonvoorspelling nodig. Inzicht: Per laadsessie legt HESC de voorspelde zon naast de werkelijke opbrengst, en een rapportknop maakt een overzicht met advies in gewone taal. Wat het oplevert (23 september – 5 oktober) Wat Resultaat Voorspelling tegenover werkelijkheid Tijdens het laden gemiddeld 87% van de voorspelling gehaald (mediaan per sessie 94%) Een dag in de praktijk (27 september) 's Ochtends laden eerst de batterijen (vanaf 20%) op zon. Om 11:26 ziet het laadplan een uur met een stroomprijs van nul en pakt die kans, ruim voor de deadline van dinsdag 10:00. Rond het middaguur knijpt HPVC de panelen af. HESC vraagt zon voor de auto, maar HPVC weigert terecht: de batterijen zijn nog niet vol. Om 13:36 is de eerste batterij vol en start de auto vanzelf op zon: anderhalf uur, van 70% naar 79%. 's Middags zorgen wolken voor wat start-stop. Vanaf 18:15 draait het huis op de batterijen. Totaal: ± 28 kWh zon (voorspeld 19 kWh), de auto laadde ± 14 kWh in acht sessies, waarvan 67% rechtstreeks van de zon. Auto van 66% naar 86%, batterijen vol. Het hele verhaal staat in A day in practice. Wat ik onderweg geleerd heb Eerst schaduwmodus. HESC beoordeelt dan alles en logt wat hij zou doen, zonder iets te schakelen. Zo zie je eerst of de logica klopt. Weinig schrijven, slim lezen. De engine leest elke 30 seconden zo'n 20 waarden uit de cache van Node-RED en schrijft alleen als er echt iets verandert. Dat was de les uit mijn performance-onderzoek: een zware flow kan Node-RED zo vertragen dat de batterijsturing seconden achterloopt. Bij twijfel terug naar veilig. Na een herstart, ontbrekende data of een time-out zet HESC HPVC altijd weer aan. Wat hij uitzet, zet hij zelf terug, en verder niets. Solcast als hoofdbron, een weerstation als controle. Dan werkt het ook bij mensen zonder eigen weerstation. De zon-teller van de laadpaal is niet heilig. Op één dag telde de Wallbox meer "zon-kWh" dan de panelen leverden. Voor evaluaties gebruik ik daarom de gemeten PV. Zelf proberen? Nodig: Home Assistant met packages, Node-RED met de Home Assistant-plugin, een laadpaal met solar laden en een zonvoorspelling (Solcast). Laadpalen: Er zijn koppeltabellen voor o.a. Wallbox, Alfen, Peblar, Zappi, go-e, Easee en Ohme. Optioneel: HPVC, een weerstation, een batterijsensor en dynamische prijzen. Vanaf v1.3.0 met een eigen prijsvoorspelling (op basis van de afgelopen 14 dagen en de zon van morgen) voor de officiële prijzen er zijn. Code, installatie en uitleg in het Nederlands: github.com/satscan1/home-ev-solar-control (GPL-3.0). Vragen of ideeën? Laat het hier weten. Ervaringen met andere laadpalen hoor ik graag.

[ Voor 5% gewijzigd door SatScan op 06-10-2026 16:18 ]

[SatScan]

Vervolg op mijn praktijkpost eerder vandaag: HESC heeft nu een eigen topic, met uitleg, installatie, een tabel met laadpalen en een FAQ.

👉 Home EV Solar Control (HESC)

Vragen en ervaringen met HESC graag daar. Strategieën voor je batterij en je energierekening blijven hier.