Zonneplan/Nexus/Waveshare — Zelfbouw EMS, PID-tuning, YAML

[Micronikje]

Er is op dit forum al veel kennis over day-ahead optimizers (DAO, EMHASS) en over Zonneplan/Nexus in het algemeen. Dit topic is bedoeld voor een specifiekere niche: mensen die zelf een EMS gebouwd hebben rond Zonneplan (Nexus/Waveshare) en daarbij echt de diepte in zijn gegaan — PID-tuning, SoC-strategieën, financiële resultaten, en het uitwisselen van concrete YAML-structuren in plaats van algemene uitleg.

Mijn setup

Solis S6 EH1P hybride omvormer, 20 kWh LFP-batterij, 8 kWp PV (8x Solax X1 micro-omvormers)

YouLess P1 + S0 voor meting, Zonneplan voor dynamische tarieven en batterijhandel

Volledig zelfgebouwd EMS in Home Assistant, momenteel op v31/v32, PID-gebaseerd

Waar ik nu mee bezig ben

Ontkoppelde PID-parameters voor laden en ontladen (kp_charge/kp_discharge) i.p.v. één gedeelde gain

Dynamische avondontlading die meeschaalt met de piek-SoC van die dag

Eén uniforme soc_min_pct-logica, elke cyclus weggeschreven naar een centrale input_number, zodat alle downstream-automatiseringen (net-laden, ontladen, reserve) uit dezelfde bron putten

Migratie van het net-laadmodule van uur- naar 15-minuten Zonneplan-pricing, moet voor 1 augustus 2026 live staan

Een eerste opzet voor predictive feed-forward sturing (Solcast-verwachting naast de reactieve PID), waar ik nog tegen dubbeltelling van het netvermogen in de feed-forward term aanloop en de Solcast-integratie nog niet compleet is

Vragen aan de rest

Hoe pakken jullie PID-tuning aan: vaste gains of adaptief (bijv. EMA-gebaseerd)?

Wie heeft al ervaring met 15-minuten Zonneplan-pricing i.p.v. uurprijzen — ik zag dat DAO in dit forum een vergelijkbare uur-naar-kwartier-migratie heeft doorgemaakt, dus ervaringen daaruit zijn ook welkom

Combineert iemand een day-ahead planner (DAO/EMHASS-achtig) met een reactieve PID-laag, waarbij de planner het dagschema zet en de PID corrigeert op realtime afwijkingen?

Wat zijn jullie financiële resultaten — vermeden import, Zonneplan-handelsrevenue, en verwachte impact van het einde van salderen per 1-1-2027?

Ik deel graag concrete YAML-blokken en debug-sensoren zodra er animo is. Input, tegenargumenten en eigen configuraties zijn allemaal welkom — het doel is een zo goed mogelijk resultaat voor iedereen die dit soort setup draait richting 2027.

[Micronikje]

[TKroon]

Yes, druk mee bezig. Nog niet voor de Nexus, maar wel voor de Marstek. Is ook een proof of concept voor de Nexus, mocht de Zonneplan-aansturing me tegen gaan staan. Wat ik nu werkend heb:

1. Omdat de Marstek ook noodstroom kan leveren aan mijn belangrijkste groepen, en directe PV input krijgt, berekent Homey de minimale SoC om 24 uur zonder netspanning te kunnen zitten. Met data uit solar forecast, verwachte tijden van hoger verbruik (verlichting, tv, etc) kom ik bijvoorbeeld vandaag uit op 38% SoC (12% is beveiligd, dus 26% heb ik daadwerkelijk nodig).

2. Met die minimale SoC mag een EPEX-script gaan zoeken naar interessante laadkoppels, waarbij er alleen maar ontladen mag worden als er een later goedkoper prijsuur tegenover staat. Ik zeg wel uur, maar het script werkt inmiddels al met kwartieren.

3. Omdat de aansturing niet vlekkeloos gaat, maar ik wel CT-informatie kan faken, stuur ik daar de Marstek mee aan. Ik kan dus via dezelfde aansturing NOM-draaien (zelfs met een Nexus ernaast die zijn eigen plan trekt), maar ook EPEX-handelen.

4. Homey zelf doet ook aan energiemanagement door prioriteiten toe te kennen aan apparaten. Bijvoorbeeld de auto laden als die nog niet vol is, maar wel bijna weg moet. Of de tank opwarmen als er beperkt warm water is, etc. Op basis van die prioriteiten kunnen apparaten worden beperkt in hun verbruik of zelfs uitgezet. Werkt zowel voor load balancing doeleinden als zonnestroom gebruiken.

5. PID-tuning gaat hier niet te snel en dat is goed genoeg. Anders zit je al te snel op over- of undershoots als de Quooker even 7 seconden aanspringt met 10A. Dat vind ik geen ramp en is gerommel in de marge.

6. Ervaring nog niet, maar voor de batterij met handelen gebruik ik kwartierprijzen, voor zaken als de auto laden, tank opwarmen, etc gebruik ik gewoon nog uurprijzen. Dat zijn langere processen wat niet op een paar cent komt, maar toch meerdere kwartieren beslaat. Als de schommelingen straks te groot blijken pas ik het wellicht nog aan om de blokken in zijn geheel wat te verschuiven, maar ik ga de auto niet elk kwartier laten stoppen en starten met laden.

GaMbiNo schreef op zondag 12 juli 2026 @ 11:35:
[...] Via modbus zorg ik nog wel voor een fatsoenlijke loadbalancing om overbelasting van fases te voorkomen.

Dus je hebt de Zonneplan-dongles er gewoon in, maar je overrulet kortstondig via modbus om direct effect te hebben?

[GaMbiNo]

TKroon schreef op zondag 12 juli 2026 @ 12:02:
[...]

Dus je hebt de Zonneplan-dongles er gewoon in, maar je overrulet kortstondig via modbus om direct effect te hebben?

Klopt.

Ik bereken eigenlijk continu de

code:

number.solis_s6_eh3p10k_h_zp_battery_max_charge_current

en de

code:

number.solis_s6_eh3p10k_h_zp_battery_max_discharge_current

Daar zet ik continu (als die geknepen moet worden) de maximale ruimte die er is om te laden en ontladen. Als er niet geknepen hoeft te worden staat die op de standaard 50A. Zo weet ik zeker dat Zonneplan geen fases gaat overbelasten. Verder laat ik de aansturing geheel aan Zonneplan.

[ Voor 12% gewijzigd door GaMbiNo op 12-07-2026 12:48 ]

[Mauri13]

Heb met modbus aansturing en EVCC geprobeerd, lukt alleen niet om opwek overschot te laden. Ligt waarschijnlijk aan de gemodificeerde omvormer. Werkt waarschijnlijk beter met standaard omvormer.

Met HBC meer succes. Dit werkt goed en je hebt een aantal strategieën die je kan gebruiken zoals NOM, zon laden, EPEX handel of een combinatie van de strategieën.

[Micronikje]

quote: @GaMbiNo

GaMbiNo schreef op zondag 12 juli 2026 @ 11:35:
Eigen topic lijkt mij ook prima.

Ik heb in de afgelopen tijden ook al een heleboel verschillende varianten eigen aansturing geprobeerd. Allemaal via modbus/Home Assistant.

Ik heb o.a. een eigen aansturing die vooral nul op de meter doet maar overgaat op dynamisch handelen bij een hoge spread. Daarnaast laadt die ook op de laagste dynamische prijzen als er onvoldoende zonnestroom voorspeld is. Maar ik moet de kwartierprijzen nog even inbouwen.

Nu draai ik overigens wel weer op Zonneplan aansturing omdat dit een tijdje ook wel weer aardig liep. Via modbus zorg ik nog wel voor een fatsoenlijke loadbalancing om overbelasting van fases te voorkomen.

Interessant, vooral het punt over forecast-gestuurd laden bij te weinig zon — dat raakt precies waar ik met mijn v33 feed-forward tegenaan loop.

Kleine nuance in mijn insteek: mijn focus ligt minder op spread-gedreven handelen en meer op autonomie. Minder import, minder cycli (batterijgezondheid) en minder export leveren mij ook gewoon rendement op, alleen dan via een andere route dan actief handelen. Vandaar dat ik met een continue PID werk in plaats van discrete modes zoals jouw NOM/dynamisch-handelen-omschakeling — ik wil de batterij zo min mogelijk onnodig laten fietsen, en elke cyclus die puur voor arbitrage is (in plaats van voor eigen verbruik) is voor mij eigenlijk een cyclus die niet per se hoeft.

Een paar dingen die ik daarom graag zou willen weten:

Bij jouw omschakeling naar dynamisch handelen bij hoge spread: hoe weeg je dat tegen extra cycli? Of is dat voor jou geen factor omdat de marge dat compenseert?

Je forecast-gestuurde bijladen bij weinig zon — gebruik je dat puur om exportverlies/import te voorkomen (autonomie-doel), of ook om alvast goedkoop in te kopen voor latere handel? Die twee doelen lopen bij mij nogal uiteen in de logica.

Je load-balancing via modbus terwijl Zonneplan de aansturing doet: zit daar ook een SoC-ondergrens in verwerkt voor noodstroom/autonomie, of is dat puur fase-bescherming?

Voor de kwartierprijzen: mijn net-laadmodule is daar al klaar voor gebouwd, maar gaat pas per 1 augustus live (nu draait dat deel nog op v31/uurprijzen). Zodra die overgang achter de rug is deel ik graag wat ik tegenkwam — vooral qua granulariteit van de PID-regeling, want een kwartier is kort genoeg dat je oscillatie/overshoot-gevoeligheid opnieuw moet doorrekenen t.o.v. uurwaarden.

[GaMbiNo]

Micronikje schreef op zondag 12 juli 2026 @ 14:09:
[...]

Interessant, vooral het punt over forecast-gestuurd laden bij te weinig zon — dat raakt precies waar ik met mijn v33 feed-forward tegenaan loop.

Kleine nuance in mijn insteek: mijn focus ligt minder op spread-gedreven handelen en meer op autonomie. Minder import, minder cycli (batterijgezondheid) en minder export leveren mij ook gewoon rendement op, alleen dan via een andere route dan actief handelen. Vandaar dat ik met een continue PID werk in plaats van discrete modes zoals jouw NOM/dynamisch-handelen-omschakeling — ik wil de batterij zo min mogelijk onnodig laten fietsen, en elke cyclus die puur voor arbitrage is (in plaats van voor eigen verbruik) is voor mij eigenlijk een cyclus die niet per se hoeft.

Een paar dingen die ik daarom graag zou willen weten:

Bij jouw omschakeling naar dynamisch handelen bij hoge spread: hoe weeg je dat tegen extra cycli? Of is dat voor jou geen factor omdat de marge dat compenseert?

Je forecast-gestuurde bijladen bij weinig zon — gebruik je dat puur om exportverlies/import te voorkomen (autonomie-doel), of ook om alvast goedkoop in te kopen voor latere handel? Die twee doelen lopen bij mij nogal uiteen in de logica.

Je load-balancing via modbus terwijl Zonneplan de aansturing doet: zit daar ook een SoC-ondergrens in verwerkt voor noodstroom/autonomie, of is dat puur fase-bescherming?

Voor de kwartierprijzen: mijn net-laadmodule is daar al klaar voor gebouwd, maar gaat pas per 1 augustus live (nu draait dat deel nog op v31/uurprijzen). Zodra die overgang achter de rug is deel ik graag wat ik tegenkwam — vooral qua granulariteit van de PID-regeling, want een kwartier is kort genoeg dat je oscillatie/overshoot-gevoeligheid opnieuw moet doorrekenen t.o.v. uurwaarden.

Ik heb voor de eigen aansturing een template gemaakt die eigenlijk bepaald wat de batterij doet.

Daarin doe ik een aantal dingen zoals o.a.:
1. Als het het duurste uur van de dag is, en het verschil tussen het duurste en goedkoopste uur meer dan 20 cent is, dan gaat hij op volle snelheid ontladen. Daarbij kijk ik niet naar extra cycli omdat de opbrengst dan groot genoeg is.

2. De Forecast.solar integratie laat ik een schatting maken van de solar opbrengst van de dag. Als dat te laag is gaat hij op basis van die schatting op de laagste 1, 2 of 3 uur van de dag laden. Om die goedkope stroom later weer te kunnen gebruiken. Of om deze later weer terug te leveren als het prijsverschil groot genoeg is.

De uitkomst van die template bepaald welk deel van de automatisering op dat moment actief is.

Voor het load balancing verhaal icm Zonneplan aansturing kijk ik niet naar SOC. Dat doe ik puur om de fases te beschermen voor een te hoge load van Zonneplan.

Die load balancing doe ik overigens ook in mijn eigen aansturing. Wanneer hij volle bak wil laden/ontladen doet hij dat ook niet meer dan de fasen aan kunnen.

[Jasper79]

Ik heb zelf Forecast solar ML al een tijdje draaien om in te leren.

https://github.com/Zara-Toorox/Solar-Forecast-ML

[Micronikje]

@GaMbiNo

Als ik het goed begrijp, gebruik jij een vaste spread van 20 cent als trigger voor een volle ontlading? Dus bij een dag waar de spread bijv. 15 cent is, doe jij niks ook al is dat de beste mogelijkheid van de dag. mijn automatisering past zich iets meer aan, door naar het prijsverschil te kijken en een max prijs van 6 uur.

Heb je overwogen om je spread flexibel/adaptief te maken door bijv. een exponentieel voortschrijdend gemiddelde te gebruiken? Ik gebruik hiervoor een 7 daags gemiddelde van mijn import/export per dagdeel. Zie hier de code ervan.

YAML: 7 daagse

</max_prijs_6u: |
  {% if not data_missing %}
    {% set ns = namespace(prijzen=[], geteld=0) %}
    {% for e in forecast %}
      {% if e.datetime[:16] >= nu_kwartier_str and ns.geteld < 24 and e.electricity_price > 0 %}
        {% set ns.prijzen = ns.prijzen + [e.electricity_price / 10000000] %}
        {% set ns.geteld = ns.geteld + 1 %}
      {% endif %}
    {% endfor %}
    {{ ns.prijzen | max if ns.prijzen | length > 0 else 0 }}
  {% else %}
    0
  {% endif %}
prijs_verschil: "{{ [max_prijs_6u - tarief_nu, 0] | max | round(4) }}"

ps. forcast en electricity_price zijn Zonneplan sensoren

[ Voor 3% gewijzigd door Micronikje op 12-07-2026 22:17 ]

[Micronikje]

Jasper79 schreef op zondag 12 juli 2026 @ 20:47:
Ik heb zelf Forecast solar ML al een tijdje draaien om in te leren.

https://github.com/Zara-Toorox/Solar-Forecast-ML

Zelf gebruik ik solcast. Ik vind die redelijk accuraat.

[GaMbiNo]

Micronikje schreef op zondag 12 juli 2026 @ 22:15:
@GaMbiNo

Als ik het goed begrijp, gebruik jij een vaste spread van 20 cent als trigger voor een volle ontlading? Dus bij een dag waar de spread bijv. 15 cent is, doe jij niks ook al is dat de beste mogelijkheid van de dag. mijn automatisering past zich iets meer aan, door naar het prijsverschil te kijken en een max prijs van 6 uur.

Heb je overwogen om je spread flexibel/adaptief te maken door bijv. een exponentieel voortschrijdend gemiddelde te gebruiken? Ik gebruik hiervoor een 7 daags gemiddelde van mijn import/export per dagdeel. Zie hier de code ervan.

YAML: 7 daagse

</max_prijs_6u: |
  {% if not data_missing %}
    {% set ns = namespace(prijzen=[], geteld=0) %}
    {% for e in forecast %}
      {% if e.datetime[:16] >= nu_kwartier_str and ns.geteld < 24 and e.electricity_price > 0 %}
        {% set ns.prijzen = ns.prijzen + [e.electricity_price / 10000000] %}
        {% set ns.geteld = ns.geteld + 1 %}
      {% endif %}
    {% endfor %}
    {{ ns.prijzen | max if ns.prijzen | length > 0 else 0 }}
  {% else %}
    0
  {% endif %}
prijs_verschil: "{{ [max_prijs_6u - tarief_nu, 0] | max | round(4) }}"

ps. forcast en electricity_price zijn Zonneplan sensoren

Ik gebruik idd een 20 cents verschil als criteria voor dynamisch handelen. Ik had de code initieel geschreven voor nul op de meter. Maar ik heb hier later wat zaken aan toegevoegd om geen buitenkansjes op dynamisch handelen te missen en ook bij weinig zon te zorgen voor een gevulde batterij.

Verder is het allemaal nog work in progress. Ik ben er een tijdje mee bezig geweest en het werkte prima maar op dat moment presteerde de onbalans ook wel weer oké waardoor ik het weer even heb gelaten.

Dank voor je code. Ik ga hier op een later moment eens voor zitten. Ik moet dan ook de kwartierprijzen integreren.

Wel leuk om ook andermans ideeen hier op te kunnen doen.

[hasseroderman]

Heel mooi initiatief. Ik ga dit topic met veel interesse volgen met het oog op mijn eigen Nexus en de gevolgen van het stoppen van salderen. Erg benieuwd welke kansen er zijn en op welke manier we maximaal rendement kunnen behalen. NOM, zelf aansturen of door ZP laten doen, we gaan het zien.

[Micronikje]

Wie met een Nexus en eigen HA-logica aan de slag gaat, loopt volgens mij vroeg of laat tegen dezelfde vraag aan: hoe zorg je dat je eigen aansturing en Zonneplans Powerplay niet tegelijk aan de knoppen zitten?

Zonneplan werkt met 3 4G-dongles: twee zitten aan de BMS van de batterij, één aan de P1-poort. Zolang die BMS-dongles aangesloten zijn, kan Zonneplan altijd meesturen — ook als jij zelf setpoints naar dezelfde registers schrijft, wat tot conflicten kan leiden (setpoints die elkaar afwisselen, onvoorspelbaar laad/ontlaadgedrag).

Twee benaderingen die ik ken

1. BMS-dongles loskoppelen

Definitief en simpel: zonder verbinding kan Zonneplan niet meer sturen. Kost je wel de Powerplay-vergoeding volledig — die vervalt zodra de dongles niet actief zijn. Ook belangrijk: Zonneplan kan zien dat de dongles offline zijn en kan daar contact over opnemen. Dus dit is geen stille work-around, ze weten het.

2. Dongles laten zitten, alleen begrenzen (clamping)

Zonneplan blijft sturen, maar jij schrijft continu een maximale laad-/ontlaadstroom naar de limiet-registers. Dit is exact wat GaMbiNo eerder in dit topic beschreef: dongles blijven erin, en hij begrenst alleen via de max_charge_current/max_discharge_current-registers, terwijl Zonneplan verder de volledige aansturing behoudt. Vergoeding blijft dan intact, omdat je niets blokkeert — alleen begrenst.

Vragen aan de rest:

Heeft iemand die de BMS-dongles heeft losgekoppeld ervaring met wat Zonneplan precies doet als ze contact opnemen — is dat puur informatief, of zijn er consequenties voor je energiecontract als je aangeeft bewust te zijn losgekoppeld?

Voor wie clamping gebruikt zoals GaMbiNo: hoe reageert Zonneplans aansturing als hun gewenste setpoint boven jouw limiet uitkomt — respecteert het systeem dat gewoon stil, of zie je foutmeldingen/pogingen om alsnog te forceren?

[Jasper79]

Eventuele oplossing is om de dongels van stroom te voorzien maar niet aan de batterij gekoppeld (wellicht een POE switch?)

Dan is de dongle online maar stuurt niet.

[melvinnie]

Micronikje schreef op maandag 13 juli 2026 @ 17:30:
Wie met een Nexus en eigen HA-logica aan de slag gaat, loopt volgens mij vroeg of laat tegen dezelfde vraag aan: hoe zorg je dat je eigen aansturing en Zonneplans Powerplay niet tegelijk aan de knoppen zitten?

Zonneplan werkt met 3 4G-dongles: twee zitten aan de BMS van de batterij, één aan de P1-poort. Zolang die BMS-dongles aangesloten zijn, kan Zonneplan altijd meesturen — ook als jij zelf setpoints naar dezelfde registers schrijft, wat tot conflicten kan leiden (setpoints die elkaar afwisselen, onvoorspelbaar laad/ontlaadgedrag).

Twee benaderingen die ik ken

1. BMS-dongles loskoppelen

Definitief en simpel: zonder verbinding kan Zonneplan niet meer sturen. Kost je wel de Powerplay-vergoeding volledig — die vervalt zodra de dongles niet actief zijn. Ook belangrijk: Zonneplan kan zien dat de dongles offline zijn en kan daar contact over opnemen. Dus dit is geen stille work-around, ze weten het.

2. Dongles laten zitten, alleen begrenzen (clamping)

Zonneplan blijft sturen, maar jij schrijft continu een maximale laad-/ontlaadstroom naar de limiet-registers. Dit is exact wat GaMbiNo eerder in dit topic beschreef: dongles blijven erin, en hij begrenst alleen via de max_charge_current/max_discharge_current-registers, terwijl Zonneplan verder de volledige aansturing behoudt. Vergoeding blijft dan intact, omdat je niets blokkeert — alleen begrenst.

Vragen aan de rest:

Heeft iemand die de BMS-dongles heeft losgekoppeld ervaring met wat Zonneplan precies doet als ze contact opnemen — is dat puur informatief, of zijn er consequenties voor je energiecontract als je aangeeft bewust te zijn losgekoppeld?

Voor wie clamping gebruikt zoals GaMbiNo: hoe reageert Zonneplans aansturing als hun gewenste setpoint boven jouw limiet uitkomt — respecteert het systeem dat gewoon stil, of zie je foutmeldingen/pogingen om alsnog te forceren?

Clamping werkt goed. Zonneplan vraagt 10kW in RC Force Battery Discharge Power maar de omvormer levert uiteindelijk maar 2.5A (~900W) wat ingesteld staat in Battery Max Discharge Current. Geen fouten gehad sinds ik hiermee begon in Februari.

Die waarde blijft gerespecteerd en hoeft dus niet constant overschreven te worden, dat werkt bij de registers welke Zonneplan gebruikt toch niet.

Bij het daadwerkelijk zelf laden/ontladen via Modbus moet je om die rede de dongles uitschakelen. Het is anders vrijwel onmogelijk om te laden/ontladen omdat de registers vrijwel direct worden overschreven.

Beide dongles gaan trouwens uit als je de deze aan de kabel aan de kant van de omvormer losmaakt.

Ik heb in mei contact opgenomen en volgens mij eerlijk aangegeven wat ik doe. Mijn interpretatie van de reactie hieronder is dat het niet verboden is. Misschien denken jullie er nog anders over?






Voor 2027 heb ik nog niet echt een plan. Ik heb maar twee panelen (balkon 5 hoog) en hoop dat het opladen blijft zoals het was. Ik ben aardig gehecht geraakt aan die grote energiebron die vrijwel dagelijks voor 0 euro wordt gevuld

[Micronikje]

@melvinnie

Goed om te horen dat clamping bij jou ook al sinds februari stabiel draait zonder fouten — dat bevestigt dat dit geen toevalstreffer is maar een robuust patroon.

Interessant is vooral je bevestiging dat het limiet-register niet herhaald hoeft te worden weggeschreven, terwijl het setpoint-register (RC Force Battery Discharge Power) wél continu overschreven wordt. Zelf schrijf ik mijn max-current-waarden continu weg als voorzorg, maar als dat register inderdaad stabiel blijft staan zonder Zonneplans inmenging, kan dat een stuk simpeler — alleen schrijven bij een daadwerkelijke wijziging in plaats van iedere cyclus.

En mooi dat je de reactie van Zonneplan hebt gedeeld — bevestigt dat er geen actief verbod is, alleen geen officiële ondersteuning.

Vraag: zet jij een vaste max-waarde, of pas je die dynamisch aan (bijvoorbeeld op basis van SoC, tijdstip, of fase-belasting)? En heb je weleens gezien dat Zonneplan zelf zijn setpoint aanpast nadat het tegen jouw limiet aanloopt, of blijft het gewoon "botsen" tegen het plafond zonder dat ze het setpoint corrigeren?

[Micronikje]

Tussenstand: Zonneplan Nexus + eigen aansturing via Modbus:

Kernpunt: twee soorten registers gedragen zich verschillend

Limiet-registers (Battery Max Charge/Discharge Current): worden door Zonneplan gerespecteerd als plafond. Zonneplan kan er niet overheen, maar blijft verder gewoon zelf bepalen wanneer en hoeveel er geladen/ontladen wordt binnen die grens.

Setpoint-registers (RC Force Battery Charge/Discharge Power): worden door Zonneplan vrijwel continu overschreven zodra de dongles actief zijn. Direct zelf sturen via deze registers werkt dus niet zolang Zonneplan actief verbonden is.

Wat dit betekent voor je eigen aansturing:

code: Tabel 1

Aanpak         Dongles         Register        Vergoeding     Opbrengst juli   Vermeden import juli   Ervaring
Clamping       Blijven zitten  Limiet-reg.     Blijft intact  ?                ?                      Melville: stabiel sinds feb.
                                                                                                      GaMbiNo: ook fase-load-balancing
Volledig zelf  Losgekoppeld    Setpoint-reg.   Vervalt        16,36 euro       39,01 euro             Ikzelf: eigen PID-aansturing

Is er iemand die 1 of beide aanpakken heeft geprobeerd en dus een eerlijke vergelijking kan maken/delen?

[GaMbiNo]

Micronikje schreef op woensdag 15 juli 2026 @ 10:31:
Tussenstand: Zonneplan Nexus + eigen aansturing via Modbus:

Kernpunt: twee soorten registers gedragen zich verschillend

Limiet-registers (Battery Max Charge/Discharge Current): worden door Zonneplan gerespecteerd als plafond. Zonneplan kan er niet overheen, maar blijft verder gewoon zelf bepalen wanneer en hoeveel er geladen/ontladen wordt binnen die grens.

Setpoint-registers (RC Force Battery Charge/Discharge Power): worden door Zonneplan vrijwel continu overschreven zodra de dongles actief zijn. Direct zelf sturen via deze registers werkt dus niet zolang Zonneplan actief verbonden is.

Wat dit betekent voor je eigen aansturing:

code: Tabel 1

Aanpak         Dongles         Register        Vergoeding     Opbrengst juli   Vermeden import juli   Ervaring
Clamping       Blijven zitten  Limiet-reg.     Blijft intact  ?                ?                      Melville: stabiel sinds feb.
                                                                                                      GaMbiNo: ook fase-load-balancing
Volledig zelf  Losgekoppeld    Setpoint-reg.   Vervalt        16,36 euro       39,01 euro             Ikzelf: eigen PID-aansturing

Is er iemand die 1 of beide aanpakken heeft geprobeerd en dus een eerlijke vergelijking kan maken/delen?

Ik gebruik de “clamping” strategie al een hele poos, sowieso sinds eind ‘25 oid. En dat werkte met zowel de oude als de nieuwe ZP aansturing prima.

Maar dat gebruik ik dus alleen samen met de Zonneplan aansturing. Ik neem dmv een template de zwaarst belaste fase, zowel laad als ontlaad en vul aan de hand daarvan de max charge en max discharge. Het is dus niet zo dat ik elke fase afzonderlijk aanstuur.

Een verschil in opbrengst zal er niet/nauwelijks zijn omdat deze aansturing gelukkig niet heel vaak hoeft in te grijpen. Maar ik ben blij dat ik hiermee wel voorkom dat de fases eruit klappen, zoals ik in het verleden wel heb gehad.

[TKroon]

@GaMbiNo Je hebt me voldoende geïnspireerd om hetzelfde op te tuigen ik heb nu goede ervaring met waveshare en de Marstek dat ik het bij de Nexus ook ga doen.

[GaMbiNo]

TKroon schreef op woensdag 15 juli 2026 @ 12:30:
@GaMbiNo Je hebt me voldoende geïnspireerd om hetzelfde op te tuigen ik heb nu goede ervaring met waveshare en de Marstek dat ik het bij de Nexus ook ga doen.

Let wel even op de Amperes waar je mee limiteert. Dit zijn amperes gebaseerd op de Nexus voltages (~425 volt oid). Dit zijn dus andere amperes dan je gewend bent ws.
25A op de max_(dis)charge is dus om en nabij de 10.000 watt.
Zelf gebruik ik de sensor.solis_s6_eh3p10k_h_zp_battery_voltage om mee te rekenen.

Zo bereken ik de max_charge:

code:

{{ ((6000 - states('sensor.max_verbruik_op_1_fase') | float + (states('sensor.hw_energymeter_175af2_vermogen_fase_2') | float ) | float(0)) / states('sensor.solis_s6_eh3p10k_h_zp_battery_voltage') | float * 3) | round(1) }}

- 6000 = de door mij gestelde max op een fase.
- sensor.max_verbruik_op_1_fase = een waarde uit een template. De op dat moment zwaarst belaste fase.
- sensor.hw_energymeter_175af2_vermogen_fase_2 = de huidige activiteit van de Nexus. Dit dmv een HomeWizard driefase meter op de Nexus. Dit zou je evt ook via de Waveshare uit de Nexus kunnen halen.
- sensor.solis_s6_eh3p10k_h_zp_battery_voltage = het huidige voltage van de Nexus om mee te rekenen.

De max_discharge bereken ik met:

code:

{{ ((6000 - states('sensor.max_teruglevering_op_1_fase') | float -
    (states('sensor.hw_energymeter_175af2_vermogen_fase_2') | float if states('sensor.hw_energymeter_175af2_vermogen_fase_2') | float < 0 else 0)) /
    states('sensor.solis_s6_eh3p10k_h_zp_battery_voltage') | float * 3) | round(0) }}

Deze lijkt erop maar met iets andere entiteiten. Wijst zichzelf denk ik.

[ Voor 52% gewijzigd door GaMbiNo op 15-07-2026 13:08 ]

[_PM]

GaMbiNo schreef op woensdag 15 juli 2026 @ 12:05:
[...]

Ik gebruik de “clamping” strategie al een hele poos, sowieso sinds eind ‘25 oid. En dat werkte met zowel de oude als de nieuwe ZP aansturing prima.

Maar dat gebruik ik dus alleen samen met de Zonneplan aansturing. Ik neem dmv een template de zwaarst belaste fase, zowel laad als ontlaad en vul aan de hand daarvan de max charge en max discharge. Het is dus niet zo dat ik elke fase afzonderlijk aanstuur.

Een verschil in opbrengst zal er niet/nauwelijks zijn omdat deze aansturing gelukkig niet heel vaak hoeft in te grijpen. Maar ik ben blij dat ik hiermee wel voorkom dat de fases eruit klappen, zoals ik in het verleden wel heb gehad.

De standaard oplossing hiervoor van Zonneplan werkt voor jou niet?
(voor mij ook een keer niet overigens toen de Zonneplan cloud oplossing eruit lag)

Op basis van jouw clamping oplossing.... Zou het ook mogelijk moeten zijn om in de zonneplan app de aansluiting van 3x25 naar 3x35 te veranderen en de limieten via de max charge en max discharge te regelen, met de potentie dat de batterij meer gebruikt wordt / meer vermogen. Ik heb nu het idee dat hij erg behoudend is als er ook andere verbruikers of de zonnepanelen actief zijn. Zou dit verschil maken?

[TKroon]

GaMbiNo schreef op woensdag 15 juli 2026 @ 12:38:
[...]

Let wel even op de Amperes waar je mee limiteert. Dit zijn amperes gebaseerd op de Nexus voltages (~425 volt oid). Dit zijn dus andere amperes dan je gewend bent ws.
25A op de max_(dis)charge is dus om en nabij de 10.000 watt.
Zelf gebruik ik de sensor.solis_s6_eh3p10k_h_zp_battery_voltage om mee te rekenen.

Zo bereken ik de max_charge:

code:

{{ ((6000 - states('sensor.max_verbruik_op_1_fase') | float + (states('sensor.hw_energymeter_175af2_vermogen_fase_2') | float ) | float(0)) / states('sensor.solis_s6_eh3p10k_h_zp_battery_voltage') | float * 3) | round(1) }}

- 6000 = de door mij gestelde max op een fase.
- sensor.max_verbruik_op_1_fase = een waarde uit een template. De op dat moment zwaarst belaste fase.
- sensor.hw_energymeter_175af2_vermogen_fase_2 = de huidige activiteit van de Nexus. Dit dmv een HomeWizard driefase meter op de Nexus. Dit zou je evt ook via de Waveshare uit de Nexus kunnen halen.
- sensor.solis_s6_eh3p10k_h_zp_battery_voltage = het huidige voltage van de Nexus om mee te rekenen.

De max_discharge bereken ik met:

code:

{{ ((6000 - states('sensor.max_teruglevering_op_1_fase') | float -
    (states('sensor.hw_energymeter_175af2_vermogen_fase_2') | float if states('sensor.hw_energymeter_175af2_vermogen_fase_2') | float < 0 else 0)) /
    states('sensor.solis_s6_eh3p10k_h_zp_battery_voltage') | float * 3) | round(0) }}

Deze lijkt erop maar met iets andere entiteiten. Wijst zichzelf denk ik.

Thanks, dat helpt. Ik gebruik homey en ga eerst eens kijken welke waarden ik allemaal uit kan lezen en hoe ze zich gedragen gedurende een tijdje voordat ik schrijfacties ga doen.

[GaMbiNo]

_PM schreef op woensdag 15 juli 2026 @ 13:28:
[...]

De standaard oplossing hiervoor van Zonneplan werkt voor jou niet?
(voor mij ook een keer niet overigens toen de Zonneplan cloud oplossing eruit lag)

Op basis van jouw clamping oplossing.... Zou het ook mogelijk moeten zijn om in de zonneplan app de aansluiting van 3x25 naar 3x35 te veranderen en de limieten via de max charge en max discharge te regelen, met de potentie dat de batterij meer gebruikt wordt / meer vermogen. Ik heb nu het idee dat hij erg behoudend is als er ook andere verbruikers of de zonnepanelen actief zijn. Zou dit verschil maken?

De Zonneplan oplossing werkt voor mij niet idd. Die is al eens te traag gebleken in een all electric huis met Nexus, laadpaal, Warmtepomp, enz. Hier vlogen de stoppen er eens uit toen er teveel tegelijk werd gevraagd. De Nexus ging volle bak laden terwijl de warmtepomp net een legionellarun deed op 3x16A.

Wat jij beschrijft is precies wat ik gedaan heb. De Zonneplan configuratie staat idd op 3x35A en mijn eigen aansturing zorgt voor het knijpen van de Nexus wanneer nodig.

[ Voor 5% gewijzigd door GaMbiNo op 15-07-2026 13:34 ]

[TKroon]

Dat klinkt perfect en lost mijn grootste klacht van de Nexus op. Ik heb dit onlangs nog besproken aan de hand van meerdere grafieken en cijfers met Zonneplan.

[elbizarre]

Ik ben nu nog lurker, maar tzt ga ik hier ook mee aan de slag.
Wat betreft Nexus of iets anders: dit maakt de k ik niet zoveel uit toch? De logic en aansturing zal grotendeels hetzelfde zijn. Wellicht andere modbus registers her en der.

Ik heb nu een andere omvormer (van SolarEdge) gekocht waar een batterij output in zit. Daarmee hoop ik wat omvormer verliezen te besparen. (Van zonneopbrengst direct de batterij in, ipv 2 maal door een omvormer.)

Ik vermoed ook dat de mensen in dit topic ook wel kleine verschillen met elkaar zullen hebben. Maar het doel en 80-90% van de opzet zal identiek zijn

[Micronikje]

elbizarre schreef op donderdag 16 juli 2026 @ 15:28:
Ik ben nu nog lurker, maar tzt ga ik hier ook mee aan de slag.
Wat betreft Nexus of iets anders: dit maakt de k ik niet zoveel uit toch? De logic en aansturing zal grotendeels hetzelfde zijn. Wellicht andere modbus registers her en der.

Ik heb nu een andere omvormer (van SolarEdge) gekocht waar een batterij output in zit. Daarmee hoop ik wat omvormer verliezen te besparen. (Van zonneopbrengst direct de batterij in, ipv 2 maal door een omvormer.)

Ik vermoed ook dat de mensen in dit topic ook wel kleine verschillen met elkaar zullen hebben. Maar het doel en 80-90% van de opzet zal identiek zijn

Helder punt, en het brengt me bij een eerlijke constatering: mijn insteek verschilt eigenlijk fundamenteel van de meeste reacties hier. Het overgrote deel van de discussie draaide om hoe je omgaat met Zonneplans actieve aansturing. Bij mij speelt dat niet, aangezien ik de dongles al los heb en volledig zelf stuur. Zonneplan mag mijn batterij ook niet meer aansturen om diverse redenen. Ik moet nog wel 1 correctie aanbrengen op mijn openingspost. Ik heb geen Solis S6 EH1P omvormer maar een Solis S6 EH3P10K omvormer. Dus een 3 fase aansluiting.

[GaMbiNo]

Wat mij betreft niet. Ik heb ook tijden op een eigen aansturing gedraaid, zoals jij nu doet. Zonder de dongles dus.

Ik denk dat dat iets is wat ik vanaf 2027 weer meer ga doen. Of eerder als de onbalans vergoeding weer compleet inzakt. Wat mij betreft is die discussie ook zeer welkom.

[ Voor 9% gewijzigd door GaMbiNo op 16-07-2026 19:03 ]

[sbar12]

Is er (ook) al ervaring met aansturen van de nieuwe Pylontech omvormers h3X? aan te sturen?

[Boris2024]

Ik zit er over te denken om mijn zonneplan thuisaccu door mijn openclaw agent aan te laten sturen. Begrijp ik het nu goed dat ik hier rekening mee moet houden bij het berekenen van de marge?
+ 15% laadverlies bij opladen accu
+ 10% energiebelasting (of geld dit pas volgend jaar bij stoppen saldering)

En dat het moment van laden en ontladen daarom dus minimaal 25% verschil moet hebben voor een positief resultaat?
Zijn er nog andere zaken om rekening mee te houden?

Iets anders waar ik aan dacht, interessante onbalans vergoedingen zijn er tegenwoordig weinig. Volgens mij komt dit het vaakst voor op dagen wanneer het windstil is. Iemand die hier wel of geen rekening mee houdt?

[ Voor 18% gewijzigd door Boris2024 op 23-07-2026 11:19 ]

[Micronikje]

Boris2024 schreef op donderdag 23 juli 2026 @ 11:17:
Ik zit er over te denken om mijn zonneplan thuisaccu door mijn openclaw agent aan te laten sturen. Begrijp ik het nu goed dat ik hier rekening mee moet houden bij het berekenen van de marge?
+ 15% laadverlies bij opladen accu
+ 10% energiebelasting (of geld dit pas volgend jaar bij stoppen saldering)

En dat het moment van laden en ontladen daarom dus minimaal 25% verschil moet hebben voor een positief resultaat?
Zijn er nog andere zaken om rekening mee te houden?

Iets anders waar ik aan dacht, interessante onbalans vergoedingen zijn er tegenwoordig weinig. Volgens mij komt dit het vaakst voor op dagen wanneer het windstil is. Iemand die hier wel of geen rekening mee houdt?

Je 15% laadverlies zit binnen de normale bandbreedte (round-trip efficiency van LFP-systemen ligt meestal tussen 85-92%). Zelf meet ik ongeveer 92% (dus 8% verlies) — meet het bij jezelf, want dit verschilt per systeem.

De 10% energiebelasting zou ik niet los optellen. Bij een dynamisch contract zit die belasting al in de prijs die je per uur/kwartier ziet. Als je je marge berekent op het verschil tussen die prijzen, zit de belasting er dus al in — je telt 'm anders dubbel.

Dus geen 25% minimaal verschil nodig, eerder ongeveer je laadverlies (8-15%, zelf meten) als vuistregel.

Over die dubbele belasting: dat is nog niet opgelost. De Tweede Kamer heeft het kabinet gevraagd om hier bij het Belastingplan 2027 iets aan te doen, maar een concrete regeling is er nog niet.

Je punt over de onbalansmarkt klopt: door de toename van thuisbatterijen die allemaal op dezelfde signalen reageren, zijn de opbrengsten in 2026 een stuk lager dan in 2023-2024. Het verband met windstille dagen kan ik niet met harde cijfers bevestigen, maar het is een aannemelijke gedachte — windprognosefouten zijn van oudsher een belangrijke oorzaak van onbalans.

[_PM]

Boris2024 schreef op donderdag 23 juli 2026 @ 11:17:
Ik zit er over te denken om mijn zonneplan thuisaccu door mijn openclaw agent aan te laten sturen. Begrijp ik het nu goed dat ik hier rekening mee moet houden bij het berekenen van de marge?
+ 15% laadverlies bij opladen accu
+ 10% energiebelasting (of geld dit pas volgend jaar bij stoppen saldering)

En dat het moment van laden en ontladen daarom dus minimaal 25% verschil moet hebben voor een positief resultaat?
Zijn er nog andere zaken om rekening mee te houden?

Iets anders waar ik aan dacht, interessante onbalans vergoedingen zijn er tegenwoordig weinig. Volgens mij komt dit het vaakst voor op dagen wanneer het windstil is. Iemand die hier wel of geen rekening mee houdt?

En je kan rekening houden met de afschrijving van je batterij (aanschaf incl installatie / 6000 cycli) = €1,40 (?) per volledige(!) leeg-vol-leeg cyclus. In praktijk gebruik je 75-80% ofzo..

Zo'n 8 ct per kWh

[Boris2024]

Ik ben opzoek naar een manier om de omvormer met UTP te kunnen verbinden, wat gebruiken jullie? Het is mij niet helemaal duidelijk of er nu twee versies zijn een USB versie en een 4 pin versie? Welke wordt hier gebruikt, waar is ervaring mee en waar te kan ik deze het beste kopen?
De USB versie lijkt in Nederland niet goed te koop te zijn..

4 pin: https://www.warmteservice.nl/Duurzaam/Zonnepanelen/Omvormer/Solis-Datalogging-stick-Wifi-LAN/p/07751011

USB: https://sunnergie.nl/product/solis-dual-lan-and-wifi-datalogger-usb/

Bij nader inzien, in zie helemaal geen usb poort op de Omvormer.
Ik zie wel een beschikbare UTP ingang (com poort) op de accu. Wat is de manier om verbinding tot stand te brengen?
Ik heb een: S6-EH3P10K-H-ZP omvormer

[ Voor 23% gewijzigd door Boris2024 op 23-07-2026 15:43 ]

[Boris2024]

_PM schreef op donderdag 23 juli 2026 @ 12:24:
[...]

En je kan rekening houden met de afschrijving van je batterij (aanschaf incl installatie / 6000 cycli) = €1,40 (?) per volledige(!) leeg-vol-leeg cyclus. In praktijk gebruik je 75-80% ofzo..

Zo'n 8 ct per kWh

Bedankt voor de tip!

[Boris2024]

Ik heb nu de RS485 poort gevonden...
Claude stelt dit voor, is dat ook hoe mensen het hier doen?

Omvormer (RS485-poort, pin 4+5) → UTP-kabel → RS485-naar-TCP/WiFi module → je netwerk (WiFi of Ethernet) → Home Assistant leest via Modbus TCP

Concreet:

1. Kabel maken: een RJ45-stekker waarbij alleen pin 4 (RS485B, blauw) en pin 5 (RS485A, blauw/wit) zijn aangesloten. Een gewone kant-en-klare UTP-patchkabel werkt hiervoor prima — pin 4 en 5 vormen samen al het gedraaide blauwe paar in de kabel, wat toevallig ideaal is voor een differentieel RS485-signaal. Je hoeft dus niet per se zelf te knippen/krimpen; een standaard Cat5e/6-kabel volstaat, je gebruikt gewoon alleen dat ene aderpaar.
2. Converter: het andere uiteinde van die kabel (de losse A/B-draden) sluit je aan op de RS485-ingang van bijvoorbeeld een Waveshare RS485 naar ETH/WiFi module, een Elfin EW11, of de eerder genoemde GC-1201 dual-master adapter (die laatste specifiek als je ook Zonneplans eigen RS485-apparaat wilt laten blijven werken op dezelfde bus).
3. Die converter krijgt zelf stroom (meestal 12V, soms via USB) en een netwerkverbinding (WiFi of ethernetkabel naar je router).
4. Home Assistant praat vervolgens niet meer rechtstreeks RS485, maar Modbus TCP over je netwerk naar het IP-adres van die converter — en die stuurt het weer door naar de omvormer als RS485. Dat is precies wat de Pho3niX90-integratie verwacht als je "Modbus TCP" als verbindingstype kiest, in plaats van een lokale seriële poort.

Kort gezegd: de UTP-kabel is puur het fysieke transportmedium tussen omvormer en converter; de converter is het apparaat dat het "vertaalwerk" doet zodat Home Assistant er via WiFi/netwerk bij kan.

[Micronikje]

@Boris2024

Lees hier de uitleg: Het Zonneplan Nexus Thuisbatterij topic - deel 2

[Boris2024]

Micronikje schreef op donderdag 23 juli 2026 @ 19:25:
@Boris2024

Lees hier de uitleg: Het Zonneplan Nexus Thuisbatterij topic - deel 2

Bedankt dat is informatie waar ik wat mee kan.
De Waveshare was al besteld, ik ga er binnenkort mee aan de slag, ben benieuwd.
Het zou fijn om wat meer controle te hebben over die accu

[Micronikje]

Update: kwartierprijzen live en het doel van mijn EMS

Kleine update na een tijdje stilte: mijn net-laadmodule draait inmiddels op de kwartierprijzen van Zonneplan (sinds 1 augustus), na wat aanpassingen die nodig bleken om de overstap van uur- naar kwartierdata soepel te laten verlopen. De regellogica reageerde in eerste instantie te gevoelig op de kortere, grillige prijsbewegingen per kwartier — dat vroeg om wat herijking om te voorkomen dat het systeem te nerveus ging schakelen.

Even iets rechtzetten over waar mijn EMS eigenlijk voor bedoeld is, want dat verschilt volgens mij van veel andere aanpakken die hier voorbijkomen. Ik optimaliseer niet voor NOM (Nul Op de Meter — waarbij je probeert om over een bepaalde periode netto niets meer te importeren of exporteren, dus je verbruik en opwek volledig tegen elkaar wegstrepen). Mijn doel is autonomie: zo min mogelijk import, zo min mogelijk export, én zo min mogelijk cycli om de batterij te ontzien. Dat is dus geen streven naar een sluitende jaarbalans, maar puur het minimaliseren van afhankelijkheid van het net en onnodige slijtage.

Concreet resultaat: in juli heb ik door de zelfaansturing 32% minder kWh heb geïmporteerd en daardoor bespaard op mijn importkosten. Ik deel dit vooral om te laten zien dat autonomie-gericht sturen (in plaats van handelsgericht) ook gewoon meetbaar resultaat oplevert, zonder dat je continu op de spread hoeft te jagen zoals bij dynamisch handelen.

Benieuwd of hier meer mensen zitten die bewust voor autonomie kiezen in plaats van NOM of handel — en zo ja, hoe doen jullie dat dan.

Naast de net-laadmodule draait er ook nog een hoofdmodule (voor gebruik zonne-energie) en een leermodule. Alle drie communiceren ze met elkaar.

[Micronikje]

Ik heb hier op Tweakers inmiddels al het een en ander gepost over mijn EMS voor mijn Zonneplan-thuisbatterij, maar daar is tot nu toe weinig reactie op gekomen.

Dat kan natuurlijk verschillende redenen hebben. Ik ben in ieder geval vooralsnog geen andere Tweaker tegengekomen die een vergelijkbare, zelfgebouwde EMS-regeling voor een Zonneplan-thuisbatterij gebruikt.

Daarom ga ik mijn EMS de komende tijd stap voor stap en in delen met jullie delen.

Het doel is niet om te zeggen dat mijn regeling "af" of optimaal is. Integendeel: ik ben juist benieuwd of anderen vanuit hun kennis van Home Assistant, energiebeheer, regeltechniek en thuisbatterijen verbeterpunten zien die ik zelf over het hoofd zie.

De EMS is inmiddels behoorlijk uitgebreid en gebruikt onder andere:

werkelijk netvermogen als feedback;

werkelijk batterijvermogen;

dynamische SOC-reserves;

PV-forecast;

geleerde verbruiksprofielen;

laad- en ontlaadregeling;

PID-achtige regeling;

bescherming tegen overshoot;

detectie van daadwerkelijk PV-surplus.

Ik zal daarom niet meteen honderden regels YAML plaatsen, maar de verschillende onderdelen afzonderlijk uitleggen en vervolgens de bijbehorende code delen.

Mijn doel: niet alleen mijn eigen installatie beter laten werken, maar kijken of we deze regeling samen verder kunnen verbeteren en uiteindelijk een zo robuust mogelijk EMS-concept voor Home Assistant kunnen maken.

Kritische feedback is dus juist welkom. Als je denkt dat een bepaalde berekening, regelstrategie of beveiliging beter kan, hoor ik graag waarom.

Generieke sensoren (EMS-basislaag)

Voordat we naar regels en forecasts gaan, eerst de basis: de generieke sensoren.

Dit is de rekenlaag van het EMS in Home Assistant.

1. Netmeting (grid power)

• positief = afname
• negatief = teruglevering

Dit is de belangrijkste “basis”.

2. PV-opwek

• actuele zonneproductie
• gebruikt voor surplus en forecast

3. Huisverbruik (afgeleid)

huisverbruik = PV + netafname - batterijvermogen

Geeft het echte verbruik zonder batterij-invloed.

4. Batterijvermogen

• positief = laden
• negatief = ontladen

5. State of Charge (SOC)

Basis voor alle grenzen:

• min/max SOC
• dynamische buffers

6. Dynamische SOC-reserve

Extra buffer bovenop minimum SOC, afhankelijk van forecast en gedrag.

7. PV-surplus

PV - huisverbruik

Bepaalt wanneer laden mag starten (met filtering tegen oscillaties).

8. Geleerd verbruiksprofiel

Historisch gedrag per tijdstip, gebruikt voor voorspellingen en buffers.

---

Waarom deze laag belangrijk is

Zonder deze laag:

• instabiele regeling
• geen goede feedback
• moeilijk te tunen

Met deze laag:

• alles is herleidbaar
• stabiele regelopbouw
• combineerbaar met PID/forecast

---

Volgende stap

In het volgende deel:

• definitie van “overschot”
• opbouw van SOC-reserves
• laad/ontlaad-logica

[GaMbiNo]

Je bent niet de enige. Ik ben sinds een aantal weken ook weer begonnen met volledig zelf aansturen. Ik moest nog even de kwartierprijzen integreren maar dat is voor 1 augustus nog gelukt en sindsdien heb ik de dongle er weer uitgetrokken.

Ik heb geprobeerd een balans te maken tussen nul op de meter en dynamisch handelen. Bij een grote spread tussen de laagste en de hoogste kwartieren zoals de afgelopen dagen handelt hij, en anders gaat hij voor nul op de meter.

En ik maak ook gebruik van PV forecast. Als het erop lijkt dat er onvoldoende opbrengst is van de PV gaat hij in de goedkoopste kwartieren bijladen.

Verder zit er nog load balancing in, houdt hij rekening met EV laden, enz.

En het is idd een hele lap yaml code, allerlei templates, automatiseringen, enz. Ik heb o.a. een template gemaakt die alle kwartierprijzen rangschikt van 1 t/m 96 zodat ik daarmee weer kan aansturen. Bijvoorbeeld bijladen in de uren 1 t/m 5 en ontladen in de uren 92 t/m 96 oid. Dus compleet delen is lastig maar wel leuk om wat te vergelijken.

[ Voor 10% gewijzigd door GaMbiNo op 15-08-2026 12:41 ]

[elbizarre]

Wat is jullie minimale verschil in hoge/lage prijs wanneer jullie gaan handelen? Je zit natuurlijk met kosten en slijtage wat ook kosten met zich meebrengt.
Daarnaast wil je waarschijnlijk 50% oid overhouden om NoM te garanderen?

[Micronikje]

elbizarre schreef op zondag 16 augustus 2026 @ 09:30:
Wat is jullie minimale verschil in hoge/lage prijs wanneer jullie gaan handelen? Je zit natuurlijk met kosten en slijtage wat ook kosten met zich meebrengt.
Daarnaast wil je waarschijnlijk 50% oid overhouden om NoM te garanderen?

Ik stuur de batterij zelf aan en handel er niet mee. Ook nul op de meter vind ik voor mijzelf niet interessant (dus evenveel import als export) vanwege einde salderingsregeling. Mijn doel is een zo groot mogelijke autonomie. Dus zo min mogelijk import, export en batterij cycli (voor de levensduur).

Ik stuur sinds juli zelf aan en heb een besparing van import van 32% gerealiseerd. Dit wil ik nog verder omhoog zien te krijgen naar 40%. Mijn autonomie was in juli 85%. Doel is 90%.

Ook dit levert geld op, maar waarschijnlijk minder dan als Zonneplan de batterij had aangestuurd.

[Micronikje]

Deel 2 — PV-surplus en dynamische SOC-reserve

In het vorige deel heb ik de basislaag van het EMS beschreven: netvermogen, PV-productie, batterijvermogen en SOC.

In dit deel ga ik een stap verder. Twee vragen zijn hierbij essentieel:

1. Wanneer is er daadwerkelijk sprake van een PV-overschot en mag de batterij gaan laden?
2. Hoeveel energie moet de batterij bewaren voor later op de dag of voor de nacht?

Dat klinkt eenvoudig, maar juist hier ontstaan bij een EMS snel ongewenste laad- en ontlaadbewegingen.

---

1. Wanneer is er sprake van PV-surplus?

Je zou kunnen zeggen:

PV-surplus = PV-productie − huisverbruik

Maar in de praktijk gebruik ik daarvoor niet alleen een berekend huisverbruik.

Mijn EMS kijkt primair naar het gemeten netvermogen.

De tekenconventie is:

• positief netvermogen = import
• negatief netvermogen = export

Dus bijvoorbeeld:

code:

PV = 2500 W
Net = -1000 W

→ er wordt 1000 W teruggeleverd
→ er is dus minimaal ongeveer 1000 W aan PV-overschot

Daarmee kan de batterij gaan laden.

Maar er zit een belangrijk probleem aan deze eenvoudige aanpak.

Een negatieve netmeting betekent niet automatisch PV-surplus

Stel dat de batterij zojuist 2000 W aan het ontladen was.

Door een plotselinge verandering in het huisverbruik kan het netvermogen kortstondig omslaan naar bijvoorbeeld:

code:

Net = -800 W

De netmeter zegt dan:

"Er wordt 800 W geëxporteerd."

Maar dat hoeft helemaal geen echte zonne-energie te zijn.

Het kan ook een tijdelijke overshoot van de batterijregeling zijn.

Daarom controleert mijn EMS sinds v40.1 ook of de gemeten export fysiek kan worden verklaard door de actuele PV-productie.

In vereenvoudigde vorm:

code:

werkelijke export <= PV-productie + marge

Bijvoorbeeld:

code:

PV = 1000 W
Export = 850 W

→ logisch
→ PV-surplus kan worden toegestaan

Maar:

code:

PV = 200 W
Export = 850 W

→ fysiek verdacht
→ waarschijnlijk geen echt PV-surplus

In mijn huidige regeling wordt hiervoor een kleine marge gebruikt om meetvertraging en meetruis op te vangen.

Dit voorkomt dat de batterij 's avonds of bij weinig zon ineens gaat laden omdat een tijdelijke batterij-overshoot ten onrechte als PV-overschot wordt gezien.

---

2. Waarom een deadband?

Ook een perfecte meter geeft niet altijd exact nul aan.

Wanneer het werkelijke doel bijvoorbeeld 0 W netverbruik is, kunnen kleine fluctuaties ontstaan:

code:

+12 W
-8 W
+17 W
-14 W

Als de batterij op iedere kleine verandering reageert, krijg je een onrustige regeling.

Daarom gebruik ik een deadband.

Kleine afwijkingen worden genegeerd totdat ze groot genoeg zijn om daadwerkelijk actie te rechtvaardigen.

Dit is vooral belangrijk bij:

• kleine PV-productie;
• wisselend huishoudelijk verbruik;
• meetvertraging;
• batterijreactietijd.

---

3. Dynamische SOC-reserve

Het tweede onderdeel is minstens zo belangrijk.

Je zou een thuisbatterij simpel kunnen laten ontladen tot bijvoorbeeld:

code:

SOC = 10%

Maar dat is voor een EMS meestal niet optimaal.

Stel:

code:

15:00
SOC = 45%

Dan zijn er twee compleet verschillende situaties mogelijk.

Situatie A — veel zon verwacht

De volgende dag of later die middag wordt veel PV verwacht.

Dan hoeft de batterij mogelijk niet zoveel energie achter de hand te houden.

Situatie B — weinig zon verwacht

Er komt nauwelijks PV en er wordt nog een lange avond en nacht verwacht.

Dan is diezelfde 45% SOC misschien juist onvoldoende.

Daarom gebruikt mijn EMS een dynamische SOC-minimumgrens.

Die grens wordt niet alleen bepaald door een vaste waarde, maar onder andere door:

• verwacht avondverbruik;
• verwacht nachtverbruik;
• seizoen;
• huidige tijd;
• verwachte PV-productie;
• geleerd historisch verbruik.

Het minimum-SOC kan daardoor gedurende de dag veranderen.

---

4. Avond- en nachtreserve

De regeling probeert vooraf te bepalen hoeveel energie waarschijnlijk nog nodig is.

Bijvoorbeeld:

code:

verwacht avondverbruik = 4 kWh
verwacht nachtverbruik = 2 kWh

Dan is de geschatte resterende behoefte:

code:

4 + 2 = 6 kWh

Bij een batterij van 20 kWh komt dat grofweg overeen met:

code:

6 / 20 × 100 = 30% SOC

Dat betekent niet automatisch dat de batterij exact op 30% moet blijven.

Er worden namelijk nog grenzen en correcties toegepast.

---

5. Forecast-correctie

De verwachte PV-productie wordt gebruikt om die benodigde reserve verder te corrigeren.

Stel:

code:

Benodigde reserve zonder PV = 40% SOC

maar er wordt later nog veel zonneproductie verwacht.

Dan kan een deel van die toekomstige behoefte door PV worden gedekt.

De benodigde reserve kan dan bijvoorbeeld dalen naar:

code:

30% SOC

Bij weinig of geen verwachte PV gebeurt het tegenovergestelde:

code:

meer reserve nodig
→ hogere SOC-minimumgrens

Het EMS probeert dus niet alleen te reageren op het huidige moment, maar ook rekening te houden met wat er later waarschijnlijk gaat gebeuren.

---

6. Waarom dit belangrijk is voor zelfconsumptie

Het doel is niet:

"Batterij altijd zo leeg mogelijk."

Maar:

"De beschikbare batterijcapaciteit zo inzetten dat er zo weinig mogelijk netimport ontstaat zonder de batterij onnodig vol of leeg te sturen."

Dat betekent soms bewust energie bewaren.

Een batterij die om 18:00 bijna leeg is, kan bijvoorbeeld geen bijdrage meer leveren tijdens een dure nachtelijke periode.

Omgekeerd wil je ook niet onnodig op 70% SOC blijven terwijl je weet dat er de volgende ochtend veel PV beschikbaar komt.

---

7. De combinatie

De twee onderdelen werken uiteindelijk samen:

code:

PV-surplus
     ↓
Mag de batterij laden?

SOC-reserve
     ↓
Hoe ver mag de batterij ontladen?

Netvermogen
     ↓
Hoeveel moet de batterij daadwerkelijk sturen?

Daarmee ontstaan drie verschillende functies:

code:

PV-surplus → laadbeslissing
SOC-reserve → ondergrens
Netvermogen → directe regeling

En juist die combinatie vormt de basis voor de volgende stap.

---

Volgende stap

In het volgende deel ga ik in op de eigenlijke regelkring:

• waarom ik ben afgestapt van alleen geschat huisverbruik;
• waarom net_power de belangrijkste feedback is geworden;
• wat actual_batt_power toevoegt;
• hoe de PID-achtige regeling hiermee het batterijvermogen bepaalt;
• en hoe overshoot wordt beperkt.

Daar begint het EMS volgens mij echt interessant te worden.

[Micronikje]

Deel 3 — Van geschat verbruik naar werkelijk netvermogen

In de vorige delen heb ik de basis van het EMS en de berekening van PV-surplus en de SOC-reserve uitgelegd.

In dit deel komt het belangrijkste onderdeel van mijn huidige regeling: hoe het EMS bepaalt hoeveel vermogen de batterij daadwerkelijk moet leveren of opnemen.

Hier heb ik in de ontwikkeling van het EMS een belangrijke wijziging gemaakt.

De oude aanpak

Een eerdere versie van het EMS gebruikte voornamelijk het berekende huisverbruik als uitgangspunt.

Dat werkt op zich, maar er zit een probleem in:

het huisverbruik is een berekende waarde, terwijl het netvermogen daadwerkelijk gemeten wordt.

Voor een batterijregeling is uiteindelijk niet alleen belangrijk hoeveel het huis verbruikt.

Het belangrijkste is:

Wat gebeurt er daadwerkelijk op de aansluiting met het elektriciteitsnet?

Daarom is de regeling in v40 omgebouwd.

---

1. Netvermogen als feedback

Mijn netmeter geeft het actuele vermogen van de aansluiting weer.

Ik gebruik daarbij:

code:

positief = import
negatief = export

Bijvoorbeeld:

code:

Netvermogen = +800 W

betekent:

het huis haalt op dat moment 800 W uit het net.

De EMS kan vervolgens de batterij opdracht geven om bijvoorbeeld ongeveer 800 W te ontladen.

Maar het interessante komt daarna.

De volgende meting kan bijvoorbeeld zijn:

code:

Netvermogen = +250 W

Dan weet de EMS:

de batterij levert wel vermogen, maar nog niet genoeg om de netimport volledig weg te regelen.

De volgende stap wordt daarop aangepast.

Als de meting vervolgens wordt:

code:

Netvermogen = -150 W

dan is er juist sprake van teruglevering.

De batterij moet dan minder ontladen.

Het systeem gebruikt het net dus als feedbacksignaal.

---

2. Waarom ook het werkelijke batterijvermogen?

Alleen het netvermogen gebruiken is nog niet voldoende.

Een omvormer reageert namelijk niet altijd onmiddellijk op een nieuw commando.

Stel dat de EMS zegt:

code:

Batterij → 1500 W ontladen

maar de batterij levert op dat moment daadwerkelijk maar:

code:

900 W

Dan moet de regeling weten dat er een verschil bestaat tussen:

gevraagd vermogen

en

werkelijk vermogen.

Daarom gebruik ik twee afzonderlijke metingen:

code:

battery_charge_power
battery_discharge_power

Daaruit wordt het actuele batterijvermogen bepaald.

In vereenvoudigde vorm:

code:

actual_batt_power =
werkelijk ontladen − werkelijk laden

Hierdoor weet de regelkring wat de batterij daadwerkelijk doet in plaats van wat het EMS eerder heeft opgedragen.

---

3. Waarom is dit beter?

Een voorbeeld.

Het huis vraagt:

code:

2000 W

De batterij wordt ingesteld op:

code:

2000 W ontladen

Maar door de reactie van de omvormer is het werkelijke batterijvermogen tijdelijk:

code:

1400 W

Het net importeert daardoor nog:

code:

600 W

De EMS ziet dat onmiddellijk terug via de netmeter.

Hij hoeft dus niet te veronderstellen dat de opdracht van 2000 W ook daadwerkelijk 2000 W oplevert.

Dat is het fundamentele verschil.

Oude gedachte:

code:

gevraagd batterijvermogen
        ↓
verwacht resultaat

Nieuwe gedachte:

code:

gevraagd batterijvermogen
        ↓
werkelijk batterijvermogen
        ↓
gemeten netvermogen
        ↓
correctie
        ↓
nieuw batterijvermogen

Dit maakt de regeling veel meer een echte closed-loop regeling.

---

4. De PID-achtige regeling

Om het batterijvermogen te bepalen gebruik ik een PID-achtige regeling.

De drie onderdelen reageren ieder op iets anders.

P — Proportional

De P-component reageert direct op de actuele netafwijking.

Bijvoorbeeld:

code:

+1000 W import

geeft een grotere correctie dan:

code:

+200 W import

De proportional gain bepaalt hoe sterk de regeling daarop reageert.

---

I — Integral

De integrale component kijkt naar een afwijking die blijft bestaan.

Stel dat het net gedurende langere tijd:

code:

+300 W
+280 W
+320 W
+290 W

aangeeft.

Dan is duidelijk dat de batterij structureel iets te weinig vermogen levert.

De I-component bouwt daarom geleidelijk een correctie op.

In mijn regeling wordt deze component begrensd en bovendien onder bepaalde omstandigheden afgebouwd.

Dat voorkomt dat de integrator onbeperkt blijft oplopen.

---

D — Derivative

De D-component kijkt naar de verandering.

Bijvoorbeeld:

code:

+200 W
+500 W
+1000 W

De netafwijking loopt snel op.

De D-component reageert daarop sneller dan de P-component alleen zou doen.

Het doel is vooral om de regeling beter te laten reageren op snelle veranderingen en overshoot te beperken.

---

5. Een belangrijk detail: de batterij zelf zit in de terugkoppeling

Een van de belangrijkste verschillen met mijn eerdere EMS-versies is dat actual_batt_power onderdeel is geworden van de berekening.

Conceptueel ziet de regeling er ongeveer zo uit:

code:

                ┌────────────────────┐
                │  Gewenste toestand │
                │   ≈ 0 W net        │
                └─────────┬──────────┘
                          ↓
                     netfout
                          ↓
                  PID-regeling
                          ↓
                 batterijcommando
                          ↓
                    omvormer
                          ↓
                werkelijk batterijvermogen
                          ↓
                    elektriciteitsnet
                          ↓
                  gemeten netvermogen
                          │
                          └────── feedback ──────┐
                                                  ↓
                                             PID-regeling

Het EMS kijkt dus voortdurend naar het resultaat van zijn eigen actie.

---

6. Waarom niet gewoon import = batterijvermogen?

Dat zou op papier eenvoudiger zijn.

Bijvoorbeeld:

code:

Import = 1200 W
→ batterij = 1200 W ontladen

In de praktijk werkt dat niet altijd goed.

Het huishoudelijke verbruik verandert voortdurend.

Bijvoorbeeld:

code:

01:00  → 400 W
01:02  → 1200 W
01:04  → 600 W
01:06  → 1800 W

Daar komen nog bij:

• meetvertraging;
• reactie van de omvormer;
• veranderingen in huishoudelijke belasting;
• minimale batterijvermogens;
• afrondingen;
• fluctuaties in PV-productie.

Een agressieve regeling kan daardoor gemakkelijk gaan oscilleren:

code:

ontladen
→ export
→ minder ontladen
→ import
→ meer ontladen
→ export
→ ...

Daarom zit er naast de PID-regeling ook filtering en hysterese in het EMS.

---

7. Filtering

Het berekende batterijvermogen wordt niet één-op-één naar de batterij gestuurd.

Er wordt een eenvoudige filtering toegepast.

Het idee is:

code:

nieuw gevraagd vermogen
+
vorige waarde
        ↓
gefilterd vermogen

De verhouding tussen beide is afhankelijk van de situatie.

Bijvoorbeeld bij ontladen:

• bij weinig PV wordt sneller gereageerd;
• bij meer PV wordt de regeling wat rustiger.

Hierdoor wordt geprobeerd om kleine meetfluctuaties niet direct als een nieuwe regelactie te behandelen.

---

8. Hysterese

Daarnaast gebruikt de regeling verschillende drempels voor inschakelen en uitschakelen.

Bijvoorbeeld conceptueel:

code:

> 15 W → starten
< 8 W  → stoppen

Daardoor ontstaat een kleine hysterese.

Zonder hysterese kan een systeem rond een grens voortdurend schakelen.

Met hysterese moet de afwijking eerst voldoende groot worden voordat een toestand verandert.

---

9. Wat probeert deze regeling uiteindelijk te bereiken?

Niet:

"De batterij moet altijd exact het huisverbruik volgen."

Maar:

"Het netvermogen moet zo dicht mogelijk bij nul komen, terwijl rekening wordt gehouden met batterijgrenzen, PV, SOC-reserve en toekomstige energiebehoefte."

Dat is een subtiel maar belangrijk verschil.

De batterij is daarmee niet het doel van de regeling.

Het netvermogen is het belangrijkste feedbacksignaal.

De batterij is het middel waarmee de netfout wordt gecorrigeerd.

---

Een vereenvoudigd voorbeeld

Stel:

code:

PV                 = 2500 W
Huisverbruik       = 3500 W
Batterij           = 0 W
Net                 = +1000 W

De EMS ziet:

code:

+1000 W import

en verhoogt het ontlaadvermogen.

Na enige tijd:

code:

Batterij            = 850 W
Net                  = +150 W

De fout is kleiner geworden.

De regeling hoeft nu dus niet nog eens 1000 W extra te geven.

Vervolgens:

code:

Batterij            = 1050 W
Net                  = -50 W

Nu is er een kleine export.

De regeling kan het batterijvermogen weer iets terugnemen.

Het uiteindelijke doel is ongeveer:

code:

Net ≈ 0 W

zonder dat de regeling voortdurend grote sprongen maakt.

---

Waarom ik dit deel belangrijk vind

Dit was voor mij een van de belangrijkste stappen in de ontwikkeling van het EMS.

Door over te stappen van voornamelijk geschat huisverbruik naar gemeten netvermogen + werkelijk batterijvermogen, wordt de regeling veel meer gebaseerd op wat er fysiek daadwerkelijk gebeurt.

Dat betekent niet automatisch dat deze aanpak perfect is.

Ik ben juist benieuwd of anderen hier vanuit regeltechniek of energiebeheer anders tegenaan kijken.

Is deze manier van closed-loop regelen volgens jullie logisch opgebouwd?

En vooral:

Waar zouden jullie de grootste risico's op oscillatie, overshoot of verkeerde integratie zien?

Dat is precies het soort feedback waarmee ik deze EMS verder wil verbeteren.

---

Volgende deel

In deel 4 ga ik daarom dieper in op de PID-regeling zelf: de keuze van Kp, Ki en Kd, de integratorbegrenzing, filtering en de manier waarop de regeling onderscheid maakt tussen laden en ontladen.

[Micronikje]

Deel 4 — De PID-regeling: hoe bepaalt de EMS het batterijvermogen?

In deel 3 heb ik uitgelegd waarom mijn EMS is overgestapt van geschat huisverbruik naar werkelijk gemeten netvermogen en werkelijk batterijvermogen.

In dit deel ga ik in op de regelkring zelf. De vraag is namelijk niet óf de batterij moet reageren, maar hoeveel vermogen hij op dat moment moet leveren of opnemen.

De kern van mijn EMS is een PID-achtige closed-loop regeling.

---

1. Wat probeert de PID op te lossen?

Het doel is verrassend eenvoudig:

code:

Netvermogen ≈ 0 W

Mijn tekenconventie is:

• positief = import
• negatief = export

Dus:

code:

+1200 W  → we nemen stroom af
0 W      → vrijwel in balans
-800 W   → we leveren terug

De PID probeert de batterij zó aan te sturen dat deze netafwijking zo klein mogelijk wordt.

---

2. De P-component: directe reactie

De P staat voor Proportional.

Deze reageert rechtstreeks op de actuele netfout.

Voorbeeld:

code:

Net = +300 W

geeft een kleine correctie.

code:

Net = +1800 W

geeft een veel grotere correctie.

Conceptueel:

code:

correctie = netfout × Kp

Hoe hoger Kp, hoe sneller de batterij reageert.

Maar té hoog geeft een onrustige regeling:

code:

Import
 ↓
Te veel ontladen
 ↓
Export
 ↓
Te weinig ontladen
 ↓
Import

Daarom is Kp begrensd.

---

3. De I-component: blijvende afwijkingen

De I staat voor Integral.

Deze kijkt niet naar één meting, maar naar een fout die blijft bestaan.

Bijvoorbeeld:

code:

+250 W
+240 W
+260 W
+255 W

Blijkbaar levert de batterij structureel nét iets te weinig vermogen.

De integrator bouwt dan langzaam een extra correctie op.

Dat helpt om kleine blijvende afwijkingen uiteindelijk weg te werken.

---

4. Integrator wind-up voorkomen

Een bekende valkuil van PID-regelingen is wind-up.

Stel dat de batterij maximaal vermogen levert, maar het huis blijft nog steeds importeren:

code:

+900 W
+900 W
+900 W

De integrator zou blijven oplopen en steeds méér correctie willen geven.

Zodra de beperking verdwijnt, ontstaat dan vaak een grote overshoot.

Daarom:

• is de integrator begrensd;
• wordt hij afgebouwd zodra de import verdwijnt;
• wordt hij gereset wanneer de regeling weer in balans is.

Dat maakt de regeling veel stabieler.

---

5. De D-component: reageren op verandering

De D staat voor Derivative.

Deze kijkt naar hoe snel de netfout verandert.

Bijvoorbeeld:

code:

100 W
350 W
800 W
1400 W

De fout loopt snel op.

De D-component reageert daarop eerder dan P alleen.

Omgekeerd:

code:

1200 W
900 W
600 W
300 W

Dan helpt D juist om de regeling af te remmen.

Hij kijkt dus niet naar de grootte van de fout, maar naar de snelheid van verandering.

---

6. Waarom het werkelijke batterijvermogen zo belangrijk is

Hier zit misschien wel het grootste verschil met mijn eerdere EMS-versies.

Stel:

code:

EMS vraagt      : 1500 W ontladen
Batterij levert : 900 W
Net import      : +600 W

Zonder terugkoppeling zou de EMS denken dat de batterij al 1500 W levert.

Mijn huidige regeling ziet juist:

• gevraagd vermogen;
• werkelijk batterijvermogen;
• werkelijk netvermogen.

Daardoor wordt niet gestuurd op de opdracht, maar op het daadwerkelijke resultaat.

Dat maakt de regelkring echt closed-loop.

---

7. Laden en ontladen zijn niet hetzelfde

Ik gebruik bewust aparte instellingen voor laden en ontladen.

Waarom?

Omdat de dynamiek heel anders is.

Ontladen

• vaak relatief stabiel huisverbruik;
• snelle reactie gewenst.

Laden

• afhankelijk van wisselende PV;
• veel meer korte fluctuaties;
• rustiger gedrag gewenst.

Daarom hebben laden en ontladen ieder hun eigen PID-afstelling en filtering.

---

8. Filtering voorkomt een zenuwachtige batterij

De PID berekent eerst een gewenst vermogen.

Dat vermogen gaat niet direct naar de omvormer.

Eerst wordt het gefilterd.

Conceptueel:

code:

Nieuw vermogen
      +
Vorige vermogen
      ↓
Gefilterd vermogen

Hierdoor krijg je geen grote sprongen zoals:

code:

500 W
1800 W
700 W
2100 W

maar een veel vloeiender verloop.

Dat vermindert slijtage én voorkomt oscillaties.

---

9. Hysterese: niet schakelen rond nul

Een tweede stabiliteitslaag is hysterese.

In plaats van één drempel gebruik ik twee grenzen.

Bijvoorbeeld:

code:

>15 W  → starten

<8 W   → stoppen

Daardoor blijft de batterij niet voortdurend wisselen tussen laden, stoppen en ontladen wanneer het net rond nul schommelt.

---

10. De complete regelkring

De volledige logica kun je zien als:

code:

Gemeten netvermogen
         │
         ▼
      Netfout
         │
         ▼
   P + I + D regeling
         │
         ▼
 Gewenst batterijvermogen
         │
         ▼
      Filtering
         │
         ▼
   Omvormer / batterij
         │
         ▼
 Werkelijk batterijvermogen
         │
         ▼
 Nieuw gemeten netvermogen
         └───────────────↺

De batterij is dus niet het doel van de regeling.

Het netvermogen is de belangrijkste feedbackvariabele; de batterij is het middel om die fout te corrigeren.

---

Waarom ik deze aanpak gekozen heb

Mijn ervaring was dat een regeling op basis van berekend huisverbruik prima werkt zolang alles ideaal reageert.

In de praktijk heb je echter te maken met:

• meetvertraging;
• omvormervertraging;
• wisselend huishoudelijk verbruik;
• grillige PV-productie;
• begrensd batterijvermogen.

Door de regelkring volledig te baseren op werkelijk gemeten netvermogen en werkelijk batterijvermogen reageert het EMS op wat er fysiek gebeurt, niet op wat het verwacht dat er gebeurt.

Dat heeft de stabiliteit van mijn installatie duidelijk verbeterd.

---

Volgende deel

In deel 5 ga ik in op de beslislaag boven de PID.

De PID kan namelijk berekenen hoeveel vermogen nodig is, maar bepaalt niet of de batterij dat ook mág doen.

Daar komen zaken als:

• dynamische SOC-reserve;
• avond- en nachtbuffer;
• forecast;
• netladen;
• veiligheidsgrenzen;
• maximale laad- en ontlaadvermogens

bij elkaar.

[Micronikje]

Deel 5 — De beslislaag: wanneer mag de batterij eigenlijk laden of ontladen?

In deel 4 ging het over de PID-regeling. Die berekent hoeveel vermogen de batterij idealiter moet leveren of opnemen.

Maar een goede EMS heeft nog een belangrijkere laag daarboven: de beslislaag.

Die bepaalt namelijk of de batterij op dat moment überhaupt mag laden of ontladen.

Je kunt het zien als twee niveaus:

• PID → hoeveel vermogen is nodig?
• Beslislaag → mag dat vermogen gebruikt worden?

Juist deze laag voorkomt dat de batterij op het verkeerde moment leegloopt of onnodig vol blijft.

---

1. Waarom een beslislaag?

Stel dat het huis 1200 W uit het net haalt.

De PID zegt:

code:

Ontladen met 1200 W

Dat lijkt logisch.

Maar wat als:

• de batterij nog maar 18% SOC heeft?
• er nog een hele avond voor de boeg is?
• morgen nauwelijks zon wordt verwacht?

Dan is direct ontladen misschien helemaal niet de beste keuze.

De beslislaag mag de PID dus overrulen.

---

2. Dynamische SOC in plaats van een vaste ondergrens

Veel batterijen werken met één vaste minimumwaarde, bijvoorbeeld:

code:

Min SOC = 10%

Mijn EMS gebruikt juist een dynamische minimum-SOC.

Die verandert gedurende de dag op basis van:

• tijdstip;
• seizoen;
• verwacht avondverbruik;
• verwacht nachtverbruik;
• PV-forecast;
• historisch verbruik.

Daardoor is 25% SOC niet altijd hetzelfde.

Voorbeeld:

Tijd	Verwachte situatie	Minimum SOC
09:00	Veel PV verwacht	10%
15:00	Avond nadert	20%
20:00	Nachtreserve nodig	30–40%

De batterij bewaart dus automatisch meer energie naarmate de avond dichterbij komt.

---

3. De avond- en nachtbuffer

In plaats van een willekeurige reserve berekent de EMS hoeveel energie waarschijnlijk nog nodig is.

Bijvoorbeeld:

code:

Avondverbruik : 3,8 kWh
Nachtverbruik : 1,9 kWh

Samen:

code:

5,7 kWh

Bij een batterij van 20 kWh is dat ongeveer:

code:

29% SOC

Dat wordt vervolgens gebruikt als richtwaarde voor de minimale reserve.

De batterij probeert dus niet maximaal leeg te raken, maar voldoende energie beschikbaar te houden voor de resterende uren.

---

4. Forecast verlaagt of verhoogt de reserve

De reserve is niet statisch.

Stel dat morgen 14 kWh PV wordt verwacht.

Dan hoeft de batterij minder energie te bewaren.

Bijvoorbeeld:

code:

Reserve zonder forecast : 35%

Forecast-correctie : -10%

Nieuwe reserve : 25%

Omgekeerd werkt het ook.

Bij weinig verwachte zon blijft de reserve juist hoger.

Hierdoor gebruikt de EMS de batterij agressiever op zonnige dagen en conservatiever op donkere dagen.

---

5. Wanneer mag de batterij laden?

Laden gebeurt niet alleen omdat de netmeter export ziet.

Er moeten meerdere voorwaarden tegelijk waar zijn:

• daadwerkelijk PV-surplus;
• voldoende ruimte in de batterij;
• geen blokkering door netladen;
• geen veiligheidslimiet bereikt.

Pas dan mag de PID bepalen hoeveel laadvermogen nodig is.

Dus niet:

code:

Export → laden

maar:

code:

PV-surplus
      +
SOC lager dan maximum
      +
Geen blokkering
      ↓
PID bepaalt laadvermogen

Dat voorkomt veel ongewenste laadacties.

---

6. Wanneer mag de batterij ontladen?

Ontladen werkt op dezelfde manier.

De PID kan 1800 W willen leveren, maar de beslislaag controleert eerst:

• ligt SOC boven de dynamische ondergrens?
• is er geen cooldown actief?
• is er geen netlaad-interlock?
• bevinden we ons binnen de veilige grenzen?

Pas daarna wordt het ontlaadvermogen toegestaan.

---

7. Waarom een cooldown?

Na het beëindigen van netladen wil ik niet dat de batterij direct weer begint te ontladen.

Daarom zit er een korte cooldown in.

Conceptueel:

code:

Netladen stopt
      ↓
15 minuten wachttijd
      ↓
Normale EMS-regeling actief

Dat voorkomt dat twee verschillende regelingen elkaar onmiddellijk gaan tegenwerken.

---

8. Veiligheid vóór optimalisatie

De hoogste prioriteit binnen de EMS is niet rendement maar veiligheid.

Daarom worden extreme situaties altijd eerst afgehandeld.

Bijvoorbeeld:

code:

SOC te laag
→ ontladen uit

SOC extreem hoog
→ laden uit

Override actief
→ alles stoppen

Pas wanneer aan alle veiligheidsvoorwaarden is voldaan, wordt de normale regeling weer actief.

---

9. De complete beslisboom

Vereenvoudigd ziet de logica er zo uit:

code:

Meetwaarden
     │
     ▼
Veiligheidscontrole
     │
     ▼
SOC-reserve berekenen
     │
     ▼
PV-surplus bepalen
     │
     ▼
Mag laden of ontladen?
     │
     ▼
PID berekent vermogen
     │
     ▼
Filtering
     │
     ▼
Omvormer

De PID staat dus bewust niet bovenaan.

Eerst wordt bepaald wat verstandig is, daarna pas hoeveel vermogen gebruikt wordt.

---

Waarom ik deze structuur gekozen heb

Tijdens eerdere versies merkte ik dat een goede PID alleen nog geen goede EMS maakt.

De echte winst zat in het scheiden van twee verantwoordelijkheden:

• Beslislaag: energie bewaren, forecast meenemen en grenzen bewaken.
• Regellaag: het netvermogen zo netjes mogelijk naar nul sturen.

Daardoor blijven beide onderdelen veel eenvoudiger te begrijpen én afzonderlijk te tunen.

---

Volgende deel

In deel 6 ga ik in op de laatste grote bouwsteen: netladen op dynamische kwartierprijzen.

Daar laat ik zien hoe goedkoop tarief, toekomstige prijsstijgingen en PV-forecast samen bepalen wanneer het juist wél verstandig is om bewust stroom uit het net in de batterij op te slaan.

[Micronikje]

Deel 6 — Slim netladen: wanneer is goedkope netstroom wél verstandig?

In de vorige delen ging het vooral over zelfconsumptie: zoveel mogelijk eigen zonnestroom gebruiken en het netvermogen rond nul houden.

Maar een thuisbatterij krijgt na het verdwijnen van de salderingsregeling nog een tweede taak: energie inkopen wanneer die goedkoop is.

Dat klinkt eenvoudig, maar mijn ervaring is dat juist hier veel regelingen te snel of te vaak laden. Daarom staat netladen in mijn EMS volledig los van de normale PID-regeling.

---

1. Waarom een aparte netlaadmodule?

De PID-regeling reageert op seconden.

Dynamische elektriciteitsprijzen veranderen per kwartier.

Dat zijn twee totaal verschillende tijdschalen.

Daarom heb ik de architectuur bewust gescheiden:

code:

Netlaadmodule
      │
      ▼
Beslist OF netladen mag
      │
      ▼
PID wordt tijdelijk geblokkeerd
      │
      ▼
Batterij laadt met ingesteld vermogen

Tijdens actief netladen mag de normale EMS dus niet tegelijkertijd proberen te ontladen.

---

2. Goedkoop is niet automatisch goedkoop genoeg

Een lage prijs alleen is voor mij geen reden om te laden.

Stel:

Tijd	Tarief
02:00	€0,16
03:00	€0,15
04:00	€0,14

Alle uren zijn goedkoop.

Maar als de ochtendprijs ook rond €0,15 blijft, levert laden nauwelijks voordeel op.

Mijn EMS kijkt daarom niet alleen naar de huidige prijs, maar ook naar de verwachte prijsontwikkeling.

De vraag is eigenlijk:

Wordt stroom later duurder?

---

3. Het uplift-principe

Ik gebruik hiervoor een eenvoudige uplift-logica.

Conceptueel:

code:

Toekomstige prijs
      -
Huidige prijs
      =
Prijsverschil

Bijvoorbeeld:

Nu	Later	Verschil
€0,14	€0,28	+€0,14
€0,18	€0,21	+€0,03
€0,22	€0,19	-€0,03

Alleen een voldoende grote positieve uplift maakt netladen interessant.

Daardoor wordt voorkomen dat de batterij voor een paar cent verschil een volledige laadcyclus maakt.

---

4. PV-forecast voorkomt onnodig netladen

Een tweede belangrijke vraag:

Komt er morgen veel zon?

Stel dat de prijs vannacht laag is.

Maar morgen verwacht je:

code:

PV-forecast = 18 kWh

Dan is de kans groot dat de batterij vanzelf weer vol raakt.

In dat geval laat mijn EMS het netladen vaak helemaal vervallen.

Omgekeerd:

code:

PV-forecast = 2 kWh

Dan kan goedkoop laden juist heel logisch zijn.

De forecast werkt dus als een rem op onnodige laadcycli.

---

5. SOC bepaalt hoeveel er geladen wordt

De batterij hoeft ook niet altijd naar 100%.

Ik gebruik een maximaal laadniveau van ongeveer 95%.

Daarnaast speelt de actuele SOC mee.

Bijvoorbeeld:

SOC	Beslissing
18%	Laden toegestaan
52%	Afhankelijk van uplift
91%	Meestal niet meer laden
96%	Laden blokkeren

Hierdoor blijft er ruimte voor regeneratie en voorkom ik langdurig op 100% staan.

---

6. Waarom een interlock?

Tijdens netladen wil ik absoluut voorkomen dat twee regelingen elkaar tegenwerken.

Zonder interlock kan dit gebeuren:

code:

Netlaadmodule
→ laad 2000 W

PID ziet import
→ ontlaad 600 W

Resultaat:
de batterij laadt én ontlaadt tegelijk.

Daarom activeert de netlaadmodule een aparte status:

code:

Grid charging = ON

Zolang die actief is:

• ontladen wordt geblokkeerd;
• de PID mag geen ontlaadcommando geven;
• alleen de netlaadmodule stuurt de batterij.

Dat maakt de regeling veel voorspelbaarder.

---

7. Wanneer stopt netladen?

Netladen stopt niet alleen wanneer de batterij vol is.

Ook deze situaties beëindigen het laden:

• prijsvoordeel verdwenen;
• eind van het goedkope kwartier;
• maximale SOC bereikt;
• forecast maakt verder laden onlogisch;
• handmatige override.

Na het stoppen begint bovendien een korte cooldown, zodat de normale EMS niet direct terugschakelt.

---

8. De complete beslisboom

Vereenvoudigd ziet de netlaadmodule er zo uit:

code:

Kwartierprijs
      │
      ▼
Is prijs goedkoop?
      │
      ▼
Is uplift groot genoeg?
      │
      ▼
PV-forecast controleren
      │
      ▼
SOC onder maximum?
      │
      ▼
Netladen starten
      │
      ▼
Interlock activeert

Hierdoor wordt alleen geladen wanneer meerdere voorwaarden tegelijk gunstig zijn.

---

9. Waarom ik hiervoor heb gekozen

Mijn uitgangspunt is dat een batterij geen handelsrobot is.

Elke laad- en ontlaadcyclus kost efficiëntie en draagt bij aan slijtage.

Daarom probeer ik niet ieder prijsverschil te benutten, maar alleen situaties waarin het verwachte voordeel groot genoeg is én de kans klein is dat de zon hetzelfde gratis oplost.

Dat levert misschien minder laadcycli op, maar hopelijk wel betere laadcycli.

---

Tot nu toe

In deze reeks heb ik de EMS opgebouwd van onder naar boven:

• Deel 1: de basislaag en sensoren
• Deel 2: PV-surplus en dynamische SOC-reserve
• Deel 3: werkelijk netvermogen als feedback
• Deel 4: de PID-regeling
• Deel 5: de beslislaag boven de PID
• Deel 6: slim netladen op kwartierprijzen

In de volgende delen zal ik de volledige generieke Home Assistant YAML publiceren, zodat iedereen de logica kan aanpassen aan zijn eigen sensoren en omvormer.

Ik ben vooral benieuwd hoe anderen de balans zien tussen prijsoptimalisatie, forecast en het beperken van onnodige batterijcycli. Helaas echter nog geen inhoudelijke reacties ontvangern.