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.