Ervaringen met onbalanshandel door Balans Batterij & Energie

[jeeedeee]

blue eyes schreef op maandag 20 april 2026 @ 15:39:
Toen ik net keek, iets van 3 cent?

Dat is meer dan niks, dus ik zou zeggen niet terugregelen Persoonlijk heb ik 2 cent als limiet, maar ook een behoorlijk overschot...

[scoobs]

blue eyes schreef op maandag 20 april 2026 @ 15:33:
Ik moet dat nog doen, ik word een beetje erg ingehaald nu.
Mijn doel is het max vermogen van de SMA te limiteren, gekoppeld aan prijzen, SOC en opwek hoger dan max verwerking van de Deye.

Ik heb net, 1 minuut geleden, maar even snel handmatig de SMA op 85% gezet; de totale installatie ging al richting de 14000 watt; geen grote verbruikers op mdit moment.

Net was ik aan het exporteren met idd geen goede cijfers

Ik plug graag even mijn eigen plugin opnieuw voor wat inspiratie.

scoobs in "Ervaringen met onbalanshandel door Balans Batterij & Energie"

By default staan er geen grijze zaken aan; alleen normal mode en self consume zijn actief.

Ohja, en ik doe niks met de microinverter; deze ligt dusdanig dat die vanaf 14:30 flink begint te cappen door schaduw, dus ik heb er geen last van. Maar de logica volgt hetzelfde patroon als je er wat mee wilt doen. Hoewel de 85% cutoff eigenlijk al een heel mooie is.

[ Voor 3% gewijzigd door scoobs op 20-04-2026 16:12 ]

[The Legend]

ibak schreef op maandag 20 april 2026 @ 08:48:
[...]

De geste is omdat aFRR langer duurt.
Die inkomsten daarvan zijn 30% voor ons en waar jij naar verwijst.
Dat is er nog niet dus daar is geen tegemoetkoming uit te halen.
Ik had de tegemoetkoming niet zo nodig gevonden want we kenden de risico's immers.
Maar het betekend wel dat ze aan de klanten denken..

Volgens mij hebben we het over verschillende dingen. De 30/70 verdeling geldt volgens het contract niet alleen voor aFRR maar voor alle ‘balanceringsdiensten’. Alle inkoop en verkoop via het EMS is een vorm van balanceren. De ‘geste’ van Don is dat die 30/70 verdeling niet geldt zolang aFRR nog niet actief is. De tegemoetkoming ziet volgens mij niet op de opslag van 2 cent per kWh.

[paQ]

The Legend schreef op maandag 20 april 2026 @ 16:15:
[...]


Volgens mij hebben we het over verschillende dingen. De 30/70 verdeling geldt volgens het contract niet alleen voor aFRR maar voor alle ‘balanceringsdiensten’. Alle inkoop en verkoop via het EMS is een vorm van balanceren. De ‘geste’ van Don is dat die 30/70 verdeling niet geldt zolang aFRR nog niet actief is. De tegemoetkoming ziet volgens mij niet op de opslag van 2 cent per kWh.

Bij balansstroom zie je 0,0048 EUR op slag per kWh.
Als ik de 2 cent opslag van BE weglaat, dan kloppen mijn berekeningen haast precies.
Dus ik denk dat ze ze inderdaad vooralsnog uit hebben gelaten.

[Jerra]

@paQ #DurftTeVragen Heb jij deze berekeningen misschien in een deelbare vorm? Gewoon om zelf eens te kijken hoe ik er financieel voorsta (voorschotten wel voldoende zijn geweest, later dit jaar nog eens invullen om niet voor verrassingen komen te staan in januari)

[The Legend]

Dat zou kunnen idd. Ik snap niet zo goed waarom het zo lastig blijkt om dit soort dingen gewoon duidelijk aan te geven. Net als het dashboard. Het zou kunnen dat de gerealiseerde prijzen daar al verrekend zijn met die van Balans Stroom, maar waarom zetten ze dat er dan niet ff bij? Het levert nog steeds een probleem op bij de afrekening, omdat nu niet is na te gaan met welke getallen ze precies rekenen. Als je een systeem bedenkt waarbij we aan BS betalen, en waarbij BE verrekent, maak dan duidelijk welke bedragen op welke manier worden verrekend

[paQ]

Jerra schreef op maandag 20 april 2026 @ 16:23:
@paQ #DurftTeVragen Heb jij deze berekeningen misschien in een deelbare vorm? Gewoon om zelf eens te kijken hoe ik er financieel voorsta (voorschotten wel voldoende zijn geweest, later dit jaar nog eens invullen om niet voor verrassingen komen te staan in januari)

probeer het eens op deze manier
In de maandoverzichttabel zie je bijv dit:


A = Inkoop kosten (kaal €)
B = Verkoop opbrengsten (kaal €)
E = Import kWh
F = Export kWh

Netto_kWh = E - F = 1.676 - 11,7 = 1.664,3 kWh

= (16,42 - 138,49) × 1,21 = -147,70 (kosten of opbrengsten incl BTW)
+ 1.664,3 × 0,111 × -1 = -184,74 (netto kWh x EB)
- (1.676 + 11,7) × 0,02 = -33,75 (opslag over totaal kWh)

Totaal = -€366,19 incl BTW aan verbruikte stroom.

---

laten we het verifiëren:

Balansstroomportaal toont 402,45 euro betalen voor die maand.
402,45 - 6,77 leveringskosten = 395,68
395,68 - 42,97 transportkosten = 352,71
352,71 + 53,42 vermindering belasting = 406,13

Als we daar dus weer de opslag vanaf halen:
406,13-33,75=372,38

Totale afwijking:
372,38-366,19=6,19, waarschijnlijk de kosten van 17 januari die ontbreekt op het BE dashboard.


Day ahead was dat 4,37. Dus als de onbalans toen net wat rot uitviel, kan dat heel goed kloppen, de rest is afrondingsverschil.

@The Legend En daarom weet ik haast zeker dat je momenteel op BE dashboard de verrekening ziet van de kale stroomprijzen.

---

Als je in balansstroom portaal vervolgens al die reeds berekende zaken uitschakelt, blijf je hier mee over.
De vaste kosten en kortingen. Die strepen nagenoeg tegen elkaar weg.

Ergo: De kosten die je per maand volgens bovenstaande methode kunt berekenen zijn je daadwerkelijke stroomkosten. Op je eindafrekening kun je je voorschotten er weer afhalen.

[ Voor 40% gewijzigd door paQ op 20-04-2026 17:30 ]

[Wolly]

The Legend schreef op maandag 20 april 2026 @ 16:15:
[...]


Volgens mij hebben we het over verschillende dingen. De 30/70 verdeling geldt volgens het contract niet alleen voor aFRR maar voor alle ‘balanceringsdiensten’. Alle inkoop en verkoop via het EMS is een vorm van balanceren. De ‘geste’ van Don is dat die 30/70 verdeling niet geldt zolang aFRR nog niet actief is. De tegemoetkoming ziet volgens mij niet op de opslag van 2 cent per kWh.

Als ze deze handel op onbalans met 30/70 zouden gaan belasten blijft er maar weinig handel over denk ik. Kopen op 8 cent, verkopen op 11 cent is nu al niet winstgevend voor ons.

Dan zou je ook nog 30% van 3 cent winst= 1 cent extra moeten afdragen.

Een spread van 3 cent levert dan 2+2+1 - 3 = 2 cent negatief op.

Een spread van 9 cent levert dan 2+2+3 - 9 = 2 cent winst.

En dat is nog mét saldering, in 2027 is die 14 (?) cent ook weg dus dan moet je echt aan hoge spreads gaan denken die ik vooralsnog niet heel veel zie op sommige dagen.

[Sportmind]

Wolly schreef op maandag 20 april 2026 @ 17:01:
[...]


Als ze deze handel op onbalans met 30/70 zouden gaan belasten blijft er maar weinig handel over denk ik. Kopen op 8 cent, verkopen op 11 cent is nu al niet winstgevend voor ons.

Dan zou je ook nog 30% van 3 cent winst= 1 cent extra moeten afdragen.

Een spread van 3 cent levert dan 2+2+1 - 3 = 2 cent negatief op.

Een spread van 9 cent levert dan 2+2+3 - 9 = 2 cent winst.

En dat is nog mét saldering, in 2027 is die 14 (?) cent ook weg dus dan moet je echt aan hoge spreads gaan denken die ik vooralsnog niet heel veel zie op sommige dagen.

Zelfs 70% afdragen. De 30% is voor de gebruiker.

[paQ]

Sportmind schreef op maandag 20 april 2026 @ 17:06:
[...]


Zelfs 70% afdragen. De 30% is voor de gebruiker.

zie ook:
paQ in "Ervaringen met onbalanshandel door Balans Batterij & Energie"

[Wolly]

paQ schreef op maandag 20 april 2026 @ 17:11:
[...]

zie ook:
paQ in "Ervaringen met onbalanshandel door Balans Batterij & Energie"

Oja dat is waar, maar de discussie over wat ons nu niet berekend zou worden door de vertraging is daarmee nog niet geslecht

Al moet het dan wel haast die 2ct zijn omdat er verder weinig overblijft om te compenseren.

[Speedy-Andre]

Ik post even hoe ik met HA de Deye pv data naar Pvoutput stuur:
In de configuration.yaml of in een aparte yaml die je aanroept:

code:

# rest_command:
  update_pvoutput:
    url: "https://pvoutput.org/service/r2/addstatus.jsp"
    method: POST
    headers:
      X-Pvoutput-Apikey: !secret pvoutput_api_key
      X-Pvoutput-SystemId: !secret pvoutput_system_id_3

    payload: >
      {{
        "d=" ~ now().strftime('%Y%m%d') ~
        "&t=" ~ now().strftime('%H:%M') | urlencode ~
        "&v1=" ~ states('sensor.inverter_today_production') | float * 1000 | int ~
        "&v2=" ~ states('sensor.inverter_pv_power') | float | int ~
        "&v7=" ~ states('sensor.inverter_pv1_voltage') | float | int ~
        "&v8=" ~ states('sensor.inverter_pv2_voltage') | float | int ~
        "&v9=" ~ states('sensor.inverter_pv1_power') | float | int ~
        "&v10=" ~ states('sensor.inverter_pv2_power') | float | int
       }}
    content_type: "application/x-www-form-urlencoded"

De 'secret' items verwijzen naar data in het secrets.yaml bestand:

code:

pvoutput_api_key: abc123abc
pvoutput_system_id_3: 14419 #Deye 7860Wp

Automation:

code:

alias: Deye pv1 to pvoutput
  description: ''
  triggers:
  - type: power
    device_id: 0e087df51277901e44c6f8e482391503
    entity_id: d1fb21d064d50e916b801d8bb81d2f4f
    domain: sensor
    trigger: device
    above: 0
  - trigger: time_pattern
    minutes: /5
  conditions: []
  actions:
  - action: rest_command.update_pvoutput
    metadata: {}
    data: {}
    response_variable: pvo.log
  mode: single

Het resultaat is een beetje verrassend (hoog) komende van 2 SMA omvormers die beperkt zijn tot 4kW ac (4620Wp Z/W) en 2,5kW ac (3240Wp N/O) , een Hoymiles HM700-2t (760Wp Z/W) deed al mee en kan 714W ac leveren.
In de oude situatie had ik maximaal 4000+2500+714W=7214W ac.
Nu gaat het wel om korte pieken bij koel weer, toch leuk om te zien
Daar staat tegenover dat de Deye meer pv spanning nodig heeft om te starten, met harde schaduw zal hij mogelijk minder goed presteren.
De optie MPPT-multi-scanning staat vooralsnog uit, voor zo ver ik kan zien zoekt hij dan vaker naar een optimaal punt maar dat garandeert niet dat het ook lukt.



De Deye rapporteert keurig per string de spanning en het vermogen, veel moeite lijkt hij hier niet mee te hebben in de zin dat er iets ontspoort of blijft hangen.