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