Marstek Venus / Duravolt PnP Thuisaccu Modbus koppeling

[Ies Korpershoek]

Rik Mertens schreef op woensdag 24 september 2025 @ 19:00:
[Afbeelding]

Hun "support" schiet wel alle kanten uit moet ik zeggen. Modbus op de V3 is niet mogelijk (maar ze voorzien wel 'n dedicated poort...)

Anyhow, nu heb ik intussen de API beschikbaar in de app, maar tegelijk lijkt het ook dat de homewizard P1 nu veel minder vaak refresht en het vermogen trager aanpast (elke 30 sec).

Elke keer 'n avontuur dus als er remote iets gewijzigd wordt (en ook niet OK dat dat zomaar kan...)

De Homewzard p1 is eigenlijk vrij 'dom' hij krijgt serieel een telegram van de slimme meter ( type 4 elke 10 sec en type 5 elke sec) en vertaald dit naar zijn API ( API versie v1 of v2) in de frequentie van ontvangst. Jouw 30 sec worden zeker niet in de P1 veroorzaakt maar elders. Wat ik zelf ontdekt heb is dat de P1 behoorlijk snel overbelast is. Als ik 3 apparaten de API laat bevragen kon de p1 dat niet verwerken en gaf storingen of 'hing' zich zelf soms op. Een reset was dan de enige oplossing.

[bvansteenselen]

Goedemiddag allemaal,

Leuk om te zien dat hier zoveel mensen actief bezig zijn met de Modbus aansturing.
zelf heb ik inmiddels Ha zover dat ik de belangrijkste systemen voor mijn energiehuishouding gekoppeld heb en daarmee ook leuke automatiseringen kan doen
gekoppelde apparaten:
- Zonnepanelen(goodwe)
- Panasonic warmtepomp(viaHeishamon)
- Marstek V1(via Ew11 met @[RNMC] Viper hacks integratie)

wanneer de Marstek vol is heb ik nu de volgende automatisering opgezet:

code:

alias: Batterij vol, Aquarea starten
description: ""
triggers:
  - type: battery_level
    device_id: 6d3adf55b68f1ba5a74074a3bb9484d0
    entity_id: de3411abd89208d0ae3550a31b061f1a
    domain: sensor
    trigger: device
    above: 99
conditions:
  - condition: time
    before: "14:28:00"
actions:
  - device_id: 6d3adf55b68f1ba5a74074a3bb9484d0
    domain: number
    entity_id: 640d3d680526bbc8182fc501789210b8
    type: set_value
    value: 2500
  - action: notify.mobile_app_sm_a556b
    metadata: {}
    data:
      message: Soc 100%
  - delay:
      hours: 0
      minutes: 10
      seconds: 0
      milliseconds: 0
  - device_id: 1e0de7f8b08544bb052731d6a95cd393
    domain: select
    entity_id: 2e5c3b2b880eb5f8960e15e75f974e27
    type: select_option
    option: Heat+DHW
  - action: notify.mobile_app_sm_a556b
    metadata: {}
    data:
      message: Soc 100% aquarea starten
mode: single

verder ben ik benieuwd hoe jullie reactie om te voorkomen dat de batterij in de winter gedurig leeg is. heb ik in een andere automatisering ingesteld dat wanneer de SOC onder 50%( in mijn geval de waarde om de batterij nu toch nog vol te krijgen) komt de discharge power op 0 gaat en ik daarbij gewoon NOM blijf draaien en zoveel mogelijk teruglevering van zonne energie voorkom maar daardoor wel de batterij vol krijg in de winter met zonnig weer.

code:

alias: Marstek onder 50%
description: ""
triggers:
  - type: battery_level
    device_id: 6d3adf55b68f1ba5a74074a3bb9484d0
    entity_id: de3411abd89208d0ae3550a31b061f1a
    domain: sensor
    trigger: device
    below: 50
conditions: []
actions:
  - device_id: 6d3adf55b68f1ba5a74074a3bb9484d0
    domain: number
    entity_id: 640d3d680526bbc8182fc501789210b8
    type: set_value
    value: 0
  - action: notify.mobile_app_sm_a556b
    metadata: {}
    data:
      message: Soc onder 50% discharge off
mode: single

en uiteraard dan ook weer discharge power aanzet als de batterij boven 50% SOC komt:

code:

alias: Marstek 50%
description: ""
triggers:
  - type: battery_level
    device_id: 6d3adf55b68f1ba5a74074a3bb9484d0
    entity_id: de3411abd89208d0ae3550a31b061f1a
    domain: sensor
    trigger: device
    above: 50
conditions: []
actions:
  - device_id: 6d3adf55b68f1ba5a74074a3bb9484d0
    domain: number
    entity_id: 640d3d680526bbc8182fc501789210b8
    type: set_value
    value: 1250
  - action: notify.mobile_app_sm_a556b
    metadata: {}
    data:
      message: Soc 50% discharge 1250w aan
mode: single

hiermee komt de batterij in deze maanden toch wel vol en behoud ik de load balancing

[Rik Mertens]

Waarden komen in andere systemen wél tijdig door én issue is gestart nadat de ‘support’ vanop afstand aan het toestel heeft lopen wriemelen kan toeval zijn natuurlijk, maar ik zou de oorzaak toch bij marstek durven zoeken.

Nugoed, dan alsnog maar hun eigen P1 meter achter een splitter steken helaas.

Tot dusver nog niet erg onder de indruk van het toestel. Blijft toch nog wat buggy van zodra je van de écht standaard gebruiksmerhode afwijkt (wat ze wel zelf aangeven dat zou moeten kunnen).

Plots krijg je remote dan tóch nieuwe firmware gepusht, krijg je tegenstrijdige antwoorden,…

Nog wat werk aan de winkel voor Marstek. Jammer, want zaken als bouwkwaliteit ed zitten dan weer wel prima. Zeker bij de V3

Ies Korpershoek schreef op donderdag 25 september 2025 @ 08:00:
[...]

De Homewzard p1 is eigenlijk vrij 'dom' hij krijgt serieel een telegram van de slimme meter ( type 4 elke 10 sec en type 5 elke sec) en vertaald dit naar zijn API ( API versie v1 of v2) in de frequentie van ontvangst. Jouw 30 sec worden zeker niet in de P1 veroorzaakt maar elders. Wat ik zelf ontdekt heb is dat de P1 behoorlijk snel overbelast is. Als ik 3 apparaten de API laat bevragen kon de p1 dat niet verwerken en gaf storingen of 'hing' zich zelf soms op. Een reset was dan de enige oplossing.

[AUijtdehaag]

bvansteenselen schreef op donderdag 25 september 2025 @ 13:09:

hiermee komt de batterij in deze maanden toch wel vol en behoud ik de load balancing

Dus als ik het goed volg:

1. Ga je pas verwarmen als de batterij is volgeladen voor half 3 smiddags.
2. Stop je met energie terug leveren uit de batterij onder de 50% soc via de batterij

Ik hoop dat de zon een keer schijnt in de winter

[Alan969]

In België zou dan de optie moeten bestaan dat als (bvb.) SOC < 50% dan de batterij enkel ontlaadt om een max van 2500kW naar het net toe te staan ipv NOM. Zo blijft CapTar op de min. waarde.
Op een aantal heel sombere dagen na elkaar, lees SOC blijft nabij 11%, zou het misschien interessant zijn om de batterij ietsje uit het net te laden om dan tijdens het koken niet boven de 2500W uit te komen. Ik vraag me echter af als dat financiëel interessant is. Dat moet ik nog eens narekenen.

[ Voor 56% gewijzigd door Alan969 op 25-09-2025 15:18 ]

[AUijtdehaag]

Alan969 schreef op donderdag 25 september 2025 @ 15:15:
In België zou dan de optie moeten bestaan dat als (bvb.) SOC < 50% dan de batterij enkel ontlaadt om een max van 2500kW naar het net toe te staan ipv NOM. Zo blijft CapTar op de min. waarde

Dat wordt dan een belgische nodered flow ipv een nederlandse

[superduper1969]

bvansteenselen schreef op donderdag 25 september 2025 @ 13:09:
verder ben ik benieuwd hoe jullie reactie om te voorkomen dat de batterij in de winter gedurig leeg is.

De simpelste vorm is de batterij minimaal 1 keer in de week naar 100% te laden, bijvoorbeeld via de AI mode.

Zelf ga ik waarschijnlijk een heel simpel schema maken die switcht tussen:
- AI > Als prijsverschil van die dag hoog is (Meer dan 14 Cent verschil tussen Hoog/Laag)
- NOM > Als prijsverschil van die dag te laag is om AI te rechtvaardigen. (Dus onder de 14 cent)
- Kalenderprogramma met overdag leeg programma en in de avond 2500W ontladen.

Het lege programma is voor overdag als álle Zonne opbrengst direct in de warmtepomp gaat, dit scheelt energieverbruik van de MT en is dan dus zuiniger dan NOM, als de warmtepomp weer stopt of minder verbruikt terug naar NOM.
Of eventueel wanneer ik overdag (in het weekend) mijn auto oplaad.
En het 2500W avond programma als er weer eens keer 40cent of meer wordt betaald voor wat er in de accu zit.

Ik ga ook geen ingewikkelde dingen doen als 1 dag vooruit kijken, ik moet het zelf ook nog snappen.

[bvansteenselen]

AUijtdehaag schreef op donderdag 25 september 2025 @ 15:11:
[...]

Dus als ik het goed volg:

1. Ga je pas verwarmen als de batterij is volgeladen voor half 3 smiddags.
2. Stop je met energie terug leveren uit de batterij onder de 50% soc via de batterij

Ik hoop dat de zon een keer schijnt in de winter

1 elke dag start de warmtepomp nu om 11 uur met het verwarmen van 200L bufervat maar was de batterij soms al eerder vol en heb ik deze regel toegepast. omdat de zon vooral smorgens op de panelen zit. (Die is dan ook vooral van toepassing in de zomer.)

2 ik krijg de batterij nu ook met heel mooi weer niet meer vol maar lukt nog wel om van 50% SOC naar 100% SOC te gaan. Het klopt dat de batterij dan nu ontlaad tot 50% SOC en daarna stopt.

Voordeel hiervan is dat ik de batterij zo nog wel vol krijg en omdat er veel discussie is dat
Alleen bij 100%SOC de cellen gebalanceerd worden dat ook gedaan wordt.

Ander voordeel zou zijn dat ik daardoor bij stroomuitval nog steeds backup stroom heb.

2 is dus voor iedereen interessant als je de batterij(en) in de winter niet meer vol krijgt.
En dus niet elke week Manuel wilt bijladen wat dan duurder zou zijn als deze instellingen. 😀

[ Voor 3% gewijzigd door bvansteenselen op 25-09-2025 15:38 ]

[Rik Mertens]

Alan969 schreef op donderdag 25 september 2025 @ 15:15:
In België zou dan de optie moeten bestaan dat als (bvb.) SOC < 50% dan de batterij enkel ontlaadt om een max van 2500kW naar het net toe te staan ipv NOM. Zo blijft CapTar op de min. waarde.
Op een aantal heel sombere dagen na elkaar, lees SOC blijft nabij 11%, zou het misschien interessant zijn om de batterij ietsje uit het net te laden om dan tijdens het koken niet boven de 2500W uit te komen. Ik vraag me echter af als dat financiëel interessant is. Dat moet ik nog eens narekenen.

De 2500W optie kan je prima bereiken in combinatie mer HA.

Je kan dan via de B2500 add-on een meter simuleren met vermogen dat 2500W onder je netvermogen ligt. Zo kan je NOM bekomen met je nulpunt op 2500 ipv 0W

[S-ven]

Hallo,

Ik heb een V3 en heb een python script geschreven om de API te pollen https://gist.github.com/s...7b81104ae441b217a669e55d7

Het werkt, maar de respons van de V3 is soms een ramp (geen reactie gedurende uren). Feedback in de App ingevuld en heb de laatste firmware gekregen (V139) maar dat verandert niet veel. De batterij antwoord niet op de API call.

Als het werkt heb ik een mooie grafiek in Home Assistant van de SoC en de charge/discharge.. maar het is jammer genoeg sporadisch.

Ik ben geen coder en misschien dat het niet robust genoeg is geschreven, dus als iemand die kan verbeteren..

[WargamingPlayer]

S-ven schreef op donderdag 25 september 2025 @ 19:37:
Hallo,

Ik heb een V3 en heb een python script geschreven om de API te pollen https://gist.github.com/s...7b81104ae441b217a669e55d7

Het werkt, maar de respons van de V3 is soms een ramp (geen reactie gedurende uren). Feedback in de App ingevuld en heb de laatste firmware gekregen (V139) maar dat verandert niet veel. De batterij antwoord niet op de API call.

Als het werkt heb ik een mooie grafiek in Home Assistant van de SoC en de charge/discharge.. maar het is jammer genoeg sporadisch.

Ik ben geen coder en misschien dat het niet robust genoeg is geschreven, dus als iemand die kan verbeteren..

Eigenlijk is het UDP protocol gewoon beroerd om iets van vaste polling te doen op een sensor. Je zit met te veel onzekerheid of het antwoord wel terug komt. Het werkt eigenlijk als volgt:

1. Een wacht socket openen.
2. API Call verzenden
3. Wachten tot antwoord op de wacht socket binnen komt, met een maximale wachttijd.
4. Indien binnen gekomen sensor bijwerken.
5. Anders na timeout. Stoppen met wachten en vergeten.
6. Wacht socket weer sluiten.

Wanneer je een soort integratie gaat bouwen krijg je eigenlijk een aantal processen welke gebruik maken van een karakterestiek van de Marsktek API. Deze is het "id" veld in ieder call die je verstuurd. Hiervan kan je eenvoudig gebruik maken. Net zoals ieder andere UDP gebaseerde polling op een API werk je meestal als volgt:

1. Initalisatiefase waarin je de volgende zaken definieert:
   • De sensors, wanneer deze nog niet bestaan, indien ze bestaan met de laatste waarde.
   • Een API Queue, dit is een dynamische lijst waarin ieder record een ID heeft, een tijdstip, de maximale timeout waarde en welke sensor.
   • Je opent een luister socket op UDP op een vrije poort.
   • Je initieert een luister process in een separate thread welke wakker wordt wanneer de luister socket een pakket binnen krijgt.
   • Je initieert een poll proces in een separate thread.
2. Een cleanup taak, welke alleen stopt wanneer het poll process is gestopt.
   • Deze gooit de queue weg.
   • Deze sluit de luister socket.

Het poll process ziet er als volgt uit (pseudocode):

code:

set PollID=1
while not Stop begin
  foreach Sensor in SensorDefinitons do begin
     set APIcall.Id= PollID
     set APIcall.Message= Sensor.Message
     call AddMessage2Queue PollID, Sensor.Name, Sensor.Waittimeout, Time.Now
     call SendMessageToAPI APIcall
  end
  set PollID= PollID+1
  call wait 5 seconds
end

Het luister process ziet er eigenlijk als volgt uit (pseudocode):

code:

   while not Stop begin
     set Data=WaitForDataOnPort( port=30000, timeout=0,5s)
     if Data is not Null begin
        set Message= GetMessageFromQueue( Data.id )
        if Message is not Null begin
           call DiscardMessageFromQueue( Message )
           call UpdateSensor Message, Data
        end 
     end
     foreach Message in MessageQueue do begin
         if MessageIsExpired( Message ) call DiscardMessageFromQueue( Message )
     end 
   end

Eigenlijk is het dus vrij eenvoudig wanneer je dit in bijvoorbeeld Phyton weet te doen. ik zou het in Powershell kunnen, maar dan ben ik een avondje bezig en op het moment heb ik daar niet echt de behoefte aan.

[bruneelm]

Rik Mertens schreef op donderdag 25 september 2025 @ 15:51:
[...]


De 2500W optie kan je prima bereiken in combinatie mer HA.

Je kan dan via de B2500 add-on een meter simuleren met vermogen dat 2500W onder je netvermogen ligt. Zo kan je NOM bekomen met je nulpunt op 2500 ipv 0W

Echter dit is niet de ideaalste maar eenvoudigste benadering van de CAPTAR.
Idealiter ga je bijsturen zodat je niet boven de 625Wh per kwartier uitkomt.

[Alan969]

Rik Mertens schreef op donderdag 25 september 2025 @ 15:51:
[...]


De 2500W optie kan je prima bereiken in combinatie mer HA.

Je kan dan via de B2500 add-on een meter simuleren met vermogen dat 2500W onder je netvermogen ligt. Zo kan je NOM bekomen met je nulpunt op 2500 ipv 0W

Ja, maar wat gebeurt er als je verbruik onder die 2500W daalt? Zal de MT dan laden om de ‘NOM’ op een waarde van 2500W te houden? Dat wil ik zeker niet want ik vrees dat de verlezen groter zullen zijn dan de besparingen op Captar.

[bvansteenselen]

bruneelm schreef op vrijdag 26 september 2025 @ 09:05:
[...]

Echter dit is niet de ideaalste maar eenvoudigste benadering van de CAPTAR.
Idealiter ga je bijsturen zodat je niet boven de 625Wh per kwartier uitkomt.

Aleen hoe ga je dat voor elkaar krijgen met Inductie koken?

[Alan969]

bvansteenselen schreef op vrijdag 26 september 2025 @ 09:13:
[...]


Aleen hoe ga je dat voor elkaar krijgen met Inductie koken?

Als het verbruik geblokt wordt op 2500W dat zit je daar onder. Met inductie koken zijn er 2MT’s nodig. Die leveren tot 5kW. Zo blijf je mooi op max 2500W
Als er in dat kwartier een deel lager is dan 2500W dan kan je in de rest van de tijd even boven die 2500W gaan.
Het gemiddelde per kwartier moet 2500 W of lager zijn. Als je tot op die grens wil gaan dan zal de bepaling van die grens moeilijker zijn. Dan moet het gemiddelde constant berekend worden en moet die grens daaraan aangepast worden.

[r03n_d]

superduper1969 schreef op donderdag 25 september 2025 @ 15:31:
[...]
Zelf ga ik waarschijnlijk een heel simpel schema maken die switcht tussen:
- AI > Als prijsverschil van die dag hoog is (Meer dan 14 Cent verschil tussen Hoog/Laag)
- NOM > Als prijsverschil van die dag te laag is om AI te rechtvaardigen. (Dus onder de 14 cent)

Hoe kom je tot die 14 cent?

[bvansteenselen]

Alan969 schreef op vrijdag 26 september 2025 @ 09:24:
[...]

Als het verbruik geblokt wordt op 2500W dat zit je daar onder. Met inductie koken zijn er 2MT’s nodig. Die leveren tot 5kW. Zo blijf je mooi op max 2500W
Als er in dat kwartier een deel lager is dan 2500W dan kan je in de rest van de tijd even boven die 2500W gaan.
Het gemiddelde per kwartier moet 2500 W of lager zijn. Als je tot op die grens wil gaan dan zal de bepaling van die grens moeilijker zijn. Dan moet het gemiddelde constant berekend worden en moet die grens daaraan aangepast worden.

Als ik het goed begrepen heb moet de marstek pas ontladen bij afname boven de 2499w

Wanneer je de marstek kan bedienen via HA
Dan zou je de volgende automatisering moeten maken

code:

alias: Marstek Discharge bij vermogen boven 2500w
description: ""
triggers:
  - trigger: numeric_state
    entity_id:
      - sensor.p1_meter_power
    above: 2499
  - trigger: numeric_state
    entity_id:
      - sensor.p1_meter_power
    below: 2499
conditions: []
actions:
  - choose:
      - conditions:
          - condition: numeric_state
            entity_id: sensor.p1_meter_power
            above: 2499
        sequence:
          - device_id: 6d3adf55b68f1ba5a74074a3bb9484d0
            domain: number
            entity_id: 640d3d680526bbc8182fc501789210b8
            type: set_value
            value: 2500
      - conditions:
          - condition: numeric_state
            entity_id: sensor.p1_meter_power
            below: 2499
        sequence:
          - device_id: 6d3adf55b68f1ba5a74074a3bb9484d0
            domain: number
            entity_id: 640d3d680526bbc8182fc501789210b8
            type: set_value
            value: 0
mode: single

Met deze automatisering ontlaad je dus alleen bij vermogens boven 2500w
Uiteraard kun je zoveel regels toevoegen als je wilt.

[bruneelm]

Als ik het goed begrepen heb moet de marstek pas ontladen bij afname boven de 2499w

Dit is eenvoudige benadering van het probleem: de '0' waarde verschuiven naar 2500 (2.5OM versus NOM of 0OM, OM staat voor op de meter)

maar eigenlijk wordt voor de mensen die CAPTAR niet gevolgd hebben met de 2500W op een verkeerd been gezet.
de 2500W is de laagste grens en is het vermogen die een volledig kwartier verbruikt moet worden om die grens te bereiken. In werkelijkheid gaat het over de energie die in een kwartier werd verbruikt en dat is die 2500/4 (4 kwartieren) dus over 625Wh.
Gezien verbruik in een huisnet fluctueert is het correct hierop inspelen niet zo eenvoudig voor een thuisbaccu

Wat je nodig hebt:

• hoeveel energie werd reeds verbruikt sinds de laatste kwartierdoorgang (actueel)
• met de reeds verbruikte hoeveelheid energie, het huidig verbruik en de resterende tijd tot de volgende kwartierdoorgang kan je berekenen wat zou de CAPTAR zijn bij de volgende kwartierdoorgang (predict)
• met een ingestelde te verwachten CAPTAR hoeveel is het toegelaten vermogen (+ nog ruimte, - overschrijden van de CAPTAR limiet) (beschikbaar)
• indien in het punt hierboven, beschikbaar, + dan moet de thuisbatterij ingrijpen en dit vanaf een punt dat dit haalbaar is, weet wel dat het afgenomen vermogen binnen het lopende kwartier nog kan dalen, waardoor ingrijpen niet nodig (niet wenselijk in de winter) was of dat de ondersteuning van de thuisaccu niet capabel is om de doelstelling te halen indien het vermogen plots nog stijgt (bijsturing)

de termen actueel, predict zijn enerigie in Wh de termen beschikbaar en bijsturing zijn vermogens in W

aanvulling inductiekookplaten:

Indien je 2 kookplaten van 2kW start tijdens een kwartierdoorgang en 15min gebruikt dan heb je een energieverbruik in dat kwartier van 1000Wh, de thuisaccu zal ondersteuning geven voor 375Wh wat geen probleem is met een vermogenscapaciteit van 2500W
Echter in normale kookomstandigheden, zullen die 2 kookplaten 15min op vol vermogen werken? Indien niet dan zal de thuisaccu assistentie lager zijn.

Maar niet iedereen kijkt op de klok om op kwartierdoorgang te starten met koken
Indien je diezelfde 2 kookplaten halverwege het kwartier zou aanzetten, dan is het energieverbruik in het startend kwartier slechts 500Wh waar er geen ondersteuning van de thuisaccu gewenst is. (en dit in tegenstelling met het verschuiven van de NOM naar de 2.5OM)
Vermoedelijk zal in het daaropvolgende kwartier het afgenomen vermogen van de kookplaten worden verlaagd.
De redenering kan natuurlijk verder gaan indien er nog andere verbruikers op hetzelfde ogenblik actief zijn, maakt de uitleg alleen iets ingewikkelder
In BE zijn de kosten en lasten bovenop de zuivere elektriciteitskost niet verwaarloosbaar zodat in de winter, wanneer de thuisaccu niet alleen van zon maar ook van het net van stroom moet worden voorzien om die CAPTAR te beperken, de tussenkomst van de thuisaccu best beperkt wordt tot uiterst noodzakelijk. Hier zal ook rekening gehouden moeten worden met de SOC en de dagen dat er in de winter wel voldoende zon is om misschien NOM te draaien (boven een bepaald % van de SOC)

Naar het aansturen van een aanstuurbare grootverbruiker de EV met min van 6A en max van 3*16, 1* 32A of uitzonderlijk 3*32A kan je nog een stap verder gaan voor de CAPTAR (zonder thuisaccu ondersteuning):
je kan een continue basis laadstroom instellen van 6A (2A Tesla) en op basis van de 'beschikbaar ' van hierboven een burst mode gebruiken, wat betekent dat je naar het eind van het kwartier (te berekenen met het max af te nemen vermogen en het huidge verbruik) de bijna max laadvermogen in te schakelen tot aan de volgende kwartierdoorgang.
Niet het max vermogen, gezien er nog huisverbruikers uitgeschakeld kunnen worden. mochten er zware verbruikers aangeschakeld worden dan schakelt het laadvermogen automatisch ook terug
Welk vermogen en wanneer zal via een berekening afgeleid worden van het huidige verbruik en de resterende tijd.
Deze regeling zal ervoor zorgen dat je voor elk kwartier de maximale hoeveelheid energie verbruikt binnen de gestelde CAPTAR limiet, het distributiebedrijf zal minder gelukkig zijn met die piekbelasting echter zij hebben de CAPTAR gedefinieerd

[ Voor 44% gewijzigd door bruneelm op 26-09-2025 11:38 ]

[AUijtdehaag]

r03n_d schreef op vrijdag 26 september 2025 @ 09:50:
[...]

Hoe kom je tot die 14 cent?

je krijgt (in NL) geen energie belasting terug over teruggeleverde stroom, en de belasting is dan 14 cent (+/-)
Dus het verschil tussen laden en ontladen via het net met een dynamisch kontrakt moet groter zijn dan dat om er iets mee te verdienen.

[ Voor 21% gewijzigd door AUijtdehaag op 26-09-2025 11:36 ]

[Rik Mertens]

Je kan in je sturing uiteraard zo ver gaan als je maar wil

Je kan een (plug-in) batterij gaan gebruiken om louter verbruik te counteren en/of peak shaving te gaan doen.

Wanneer je plug-in batterij niet op 'n apparte groep zit en dus 800W kan ontladen kan je daarmee je capaciteitspiek met 800W per maand verlagen (indien er telkens SoC is). Dat scheelt je dan maximaal +- €3,5 per maand.

Ga je met 2,5kW ontladen dan stijgt dat al iets meer door natuurlijk.

[bvansteenselen]

bruneelm schreef op vrijdag 26 september 2025 @ 11:01:
[...]


Dit is eenvoudige benadering van het probleem: de '0' waarde verschuiven naar 2500 (2.5OM versus NOM of 0OM, OM staat voor op de meter)

maar eigenlijk wordt voor de mensen die CAPTAR niet gevolgd hebben met de 2500W op een verkeerd been gezet.
de 2500W is de laagste grens en is het vermogen die een volledig kwartier verbruikt moet worden om die grens te bereiken. In werkelijkheid gaat het over de energie die in een kwartier werd verbruikt en dat is die 2500/4 (4 kwartieren) dus over 625Wh.
Gezien verbruik in een huisnet fluctueert is het correct hierop inspelen niet zo eenvoudig voor een thuisbaccu

Wat je nodig hebt:

• hoeveel energie werd reeds verbruikt sinds de laatste kwartierdoorgang (actueel)
• met de reeds verbruikte hoeveelheid energie, het huidig verbruik en de resterende tijd tot de volgende kwartierdoorgang kan je berekenen wat zou de CAPTAR zijn bij de volgende kwartierdoorgang (predict)
• met een ingestelde te verwachten CAPTAR hoeveel is het toegelaten vermogen (+ nog ruimte, - overschrijden van de CAPTAR limiet) (beschikbaar)
• indien in het punt hierboven, beschikbaar, + dan moet de thuisbatterij ingrijpen en dit vanaf een punt dat dit haalbaar is, weet wel dat het afgenomen vermogen binnen het lopende kwartier nog kan dalen, waardoor ingrijpen niet nodig (niet wenselijk in de winter) was of dat de ondersteuning van de thuisaccu niet capabel is om de doelstelling te halen indien het vermogen plots nog stijgt (bijsturing)

de termen actueel, predict zijn enerigie in Wh de termen beschikbaar en bijsturing zijn vermogens in W

aanvulling inductiekookplaten:

Indien je 2 kookplaten van 2kW start tijdens een kwartierdoorgang en 15min gebruikt dan heb je een energieverbruik in dat kwartier van 1000Wh, de thuisaccu zal ondersteuning geven voor 375Wh wat geen probleem is met een vermogenscapaciteit van 2500W
Echter in normale kookomstandigheden, zullen die 2 kookplaten 15min op vol vermogen werken? Indien niet dan zal de thuisaccu assistentie lager zijn.

Maar niet iedereen kijkt op de klok om op kwartierdoorgang te starten met koken
Indien je diezelfde 2 kookplaten halverwege het kwartier zou aanzetten, dan is het energieverbruik in het startend kwartier slechts 500Wh waar er geen ondersteuning van de thuisaccu gewenst is. (en dit in tegenstelling met het verschuiven van de NOM naar de 2.5OM)
Vermoedelijk zal in het daaropvolgende kwartier het afgenomen vermogen van de kookplaten worden verlaagd.
De redenering kan natuurlijk verder gaan indien er nog andere verbruikers op hetzelfde ogenblik actief zijn, maakt de uitleg alleen iets ingewikkelder
In BE zijn de kosten en lasten bovenop de zuivere elektriciteitskost niet verwaarloosbaar zodat in de winter, wanneer de thuisaccu niet alleen van zon maar ook van het net van stroom moet worden voorzien om die CAPTAR te beperken, de tussenkomst van de thuisaccu best beperkt wordt tot uiterst noodzakelijk. Hier zal ook rekening gehouden moeten worden met de SOC en de dagen dat er in de winter wel voldoende zon is om misschien NOM te draaien (boven een bepaald % van de SOC)

Naar het aansturen van een aanstuurbare grootverbruiker de EV met min van 6A en max van 3*16, 1* 32A of uitzonderlijk 3*32A kan je nog een stap verder gaan voor de CAPTAR (zonder thuisaccu ondersteuning):
je kan een continue basis laadstroom instellen van 6A (2A Tesla) en op basis van de 'beschikbaar ' van hierboven een burst mode gebruiken, wat betekent dat je naar het eind van het kwartier (te berekenen met het max af te nemen vermogen en het huidge verbruik) de bijna max laadvermogen in te schakelen tot aan de volgende kwartierdoorgang.
Niet het max vermogen, gezien er nog huisverbruikers uitgeschakeld kunnen worden. mochten er zware verbruikers aangeschakeld worden dan schakelt het laadvermogen automatisch ook terug
Welk vermogen en wanneer zal via een berekening afgeleid worden van het huidige verbruik en de resterende tijd.
Deze regeling zal ervoor zorgen dat je voor elk kwartier de maximale hoeveelheid energie verbruikt binnen de gestelde CAPTAR limiet, het distributiebedrijf zal minder gelukkig zijn met die piekbelasting echter zij hebben de CAPTAR gedefinieerd

Met het script wat ik had gemaakt laad de batterij wel normaal NOM alleen gaat deze er voor zorgen dat je hogere vermogens voorkomt.

Voorbeeld: apparaat1 met vermogen 1200w gaat aan batterij gaat nog niet terug leveren.
Wanneer apparaat2 met vermogen van 1500w aan gaat is totaal vermogen 2700w en zal de batterij gaan terugleveren met maximaal 2500w omdat totaal uit komt boven 2499w.

Ander voorbeeld: Apparaat1(inductiekookplaat) wordt aangezet met 3 zones 2200w, 2200w, 1200w
Op vol vermogen van alle 3 zones zou de afname normaal zijn 5600w alleen zullen de meeste de zones niet allemaal op vol vermogen maar op bijvoorbeeld half vermogen aanzetten en gaat een inductiekookplaat net als een magnetron pendelen en neemt deze per zone om de zoveel seconden 2200w af. Waardoor je pieken krijgt.

Daarmee werkte het script wat ik had gemaakt het beste omdat de batterij er dan voor zorgt dat het gemiddelde lager wordt.

Script kun je makkelijk met HA automatiseringen via jaml toevoegen, en dan alleen eigen apparaten goed koppelen.

[timvanloon]

iemand die weet welke van de poorten op de marstek venus E de lan aansluiting is, links of rechts?

[pascallj]

timvanloon schreef op vrijdag 26 september 2025 @ 13:24:
iemand die weet welke van de poorten op de marstek venus E de lan aansluiting is, links of rechts?

De handleiding had je dat kunnen vertellen

[timvanloon]

Bedankt!

[Alan969]

AUijtdehaag schreef op vrijdag 26 september 2025 @ 11:33:
[...]

je krijgt (in NL) geen energie belasting terug over teruggeleverde stroom, en de belasting is dan 14 cent (+/-)
Dus het verschil tussen laden en ontladen via het net met een dynamisch kontrakt moet groter zijn dan dat om er iets mee te verdienen.

Hou je dan geen rekening met de slijtage van de MT: kostprijs v/d MT /(6000cyclussen x aantal kWh per cyclus) = +\- 4ct/kWh?

[superduper1969]

Alan969 schreef op vrijdag 26 september 2025 @ 15:09:
[...]

Hou je dan geen rekening met de slijtage van de MT: kostprijs v/d MT /(6000cyclussen x aantal kWh per cyclus) = +\- 4ct/kWh?

Ik het eenmaal heb geprogrammeerd kan ik gewoon een tijd kijken wat het effect is.
Daarna kan ik het gewoon wijzigen in een andere drempelwaarde.
Het gaat niet om euro's per dag dusdat valt mee.

[AUijtdehaag]

@Alan969
6000 cyclussen is 15 jaar?
Dan staat er een nieuwe

[pascallj]

AUijtdehaag schreef op vrijdag 26 september 2025 @ 15:32:
@Alan969
6000 cyclussen is 15 jaar?
Dan staat er een nieuwe

Dan is je afschrijving dus nog vele malen hoger

[AUijtdehaag]

De nieuwe koelkast reken ik ook niet uit hoor.

[bruneelm]

bvansteenselen schreef op vrijdag 26 september 2025 @ 12:19:
[...]


Met het script wat ik had gemaakt laad de batterij wel normaal NOM alleen gaat deze er voor zorgen dat je hogere vermogens voorkomt.

Voorbeeld: apparaat1 met vermogen 1200w gaat aan batterij gaat nog niet terug leveren.
Wanneer apparaat2 met vermogen van 1500w aan gaat is totaal vermogen 2700w en zal de batterij gaan terugleveren met maximaal 2500w omdat totaal uit komt boven 2499w.

Om CAPTAR 2500 te vermijden dien je batterij maar 200W te compenseren en geen 2500

Ander voorbeeld: Apparaat1(inductiekookplaat) wordt aangezet met 3 zones 2200w, 2200w, 1200w
Op vol vermogen van alle 3 zones zou de afname normaal zijn 5600w alleen zullen de meeste de zones niet allemaal op vol vermogen maar op bijvoorbeeld half vermogen aanzetten en gaat een inductiekookplaat net als een magnetron pendelen en neemt deze per zone om de zoveel seconden 2200w af. Waardoor je pieken krijgt.

Mijn AEG inductieplaten van 2200W verbruiken 1100W op half vermogen die gaan niet pendelen tussen 0 en 2200W

Daarmee werkte het script wat ik had gemaakt het beste omdat de batterij er dan voor zorgt dat het gemiddelde lager wordt.

Script kun je makkelijk met HA automatiseringen via jaml toevoegen, en dan alleen eigen apparaten goed koppelen.

[GAEvakYD]

Afgelopen week de NodeRed automatisering weer iets uitgebreid op: https://github.com/gitcodebob/marstek-venus-rs485-node-red

O.a. door een extra strategy toe te voegen genaamd "Grid-charge-or-wait". Deze gebruik ikzelf in twee usecses:
1) Als ik inschat dat de PV opwekking op de dag de accu's niet volkrijg, dan wil ik op het laagste prijsniveau van de dag de accu's opladen vanuit de grid. Bijv stel dat prijzen zijn 15 cent overdag en in de avond boven de 30 cent. Dan is het een prima keuze om de accu's vol te gooien en de RTE verliezen voorlief te nemen.
2) Mijn accu capaciteit is helaas op sommige dagen net niet genoeg om de hele avond en nacht door te komen, incl de ochtend piek. In de ochtend rond 7 en 8 uur is de stroomprijs erg hoog. Het komt voor dat er dan weinig zonopwekking is en de accu's leeg. In dat geval wil ik liever dat hij in de nacht als de prijs relatief laag is eventjes 2 uur niet ontlaad.

Deze casussen zijn te regelen dus met de strategy "Grid-charge-or-wait" en de volgende entiteiten in HA.


Alle code voor Nodered en HA zitten in de GitHub repo.

[AUijtdehaag]

@GAEvakYD
Komt mooi uit met de donkere dagen in aantocht.
We gaan hem eens uitproberen. Dank.

[GAEvakYD]

AUijtdehaag schreef op zaterdag 27 september 2025 @ 09:32:
@GAEvakYD
Komt mooi uit met de donkere dagen in aantocht.
We gaan hem eens uitproberen. Dank.

Hehe same here. Deze strategie is ontstaan doordat mijn PV de accu's niet meer volkrijgen, maar ik wel zie dat overdag er nog mooie prijsdalen in de (dynamische) energieprijzen zitten. Als deze strategie een beetje goed werkt wil ik hem wel verder automatiseren, zodat hij meer automatisch de settings gaat aansturen.

Net in het Marstek hoofdtopic ook een dilemma gedeeld om meer accu capaciteit bij te kopen. Die pubers hier in huis in combinatie met en all-electric huis zorgt ervoor dat mijn huidig systeem niet toereikend is.

[gho]

Heb van alles geprobeerd, maar krijg totaal GEEN wifi verbinding bij de Marstek Modbus koppeling met de Lilygo !!!
ERROR Connecting to 192…… port 3232 failed: [Errno 111] Connection refused
Vermoedelijk omdat Home Assistant Green als device op UTP Windows 11 PC draait (??)
Marstek batterij draait overigens maandenlang perfect met TPLink Deco x20 wifi verbinding, op PC inschakelen Deco Wifi geeft geen verbinding.

Wat te doen?
Zelf totaal geen verstand van IP adress gedoe, net zomin of TPLink, of PC instelling dienen te worden aangepast, maar bergrijp er niets van.

Jullie hulp en tips wordt hoogst gewaardeerd , graag jullie reacties alvast dank voor de moeite

[AUijtdehaag]

@gho Kun je die Home Assistant Green niet gewoon in je netwerk hangen ipv aan een pc?
Dan krijgt die dezelfde ip range en subnet als de lilygo natuurlijk. Nu niet.

[ Voor 30% gewijzigd door AUijtdehaag op 27-09-2025 10:37 ]

[pascallj]

GAEvakYD schreef op zaterdag 27 september 2025 @ 09:09:
Afgelopen week de NodeRed automatisering weer iets uitgebreid op: https://github.com/gitcodebob/marstek-venus-rs485-node-red

O.a. door een extra strategy toe te voegen genaamd "Grid-charge-or-wait". Deze gebruik ikzelf in twee usecses:
1) Als ik inschat dat de PV opwekking op de dag de accu's niet volkrijg, dan wil ik op het laagste prijsniveau van de dag de accu's opladen vanuit de grid. Bijv stel dat prijzen zijn 15 cent overdag en in de avond boven de 30 cent. Dan is het een prima keuze om de accu's vol te gooien en de RTE verliezen voorlief te nemen.
2) Mijn accu capaciteit is helaas op sommige dagen net niet genoeg om de hele avond en nacht door te komen, incl de ochtend piek. In de ochtend rond 7 en 8 uur is de stroomprijs erg hoog. Het komt voor dat er dan weinig zonopwekking is en de accu's leeg. In dat geval wil ik liever dat hij in de nacht als de prijs relatief laag is eventjes 2 uur niet ontlaad.

Deze casussen zijn te regelen dus met de strategy "Grid-charge-or-wait" en de volgende entiteiten in HA.
[Afbeelding]

Alle code voor Nodered en HA zitten in de GitHub repo.

Misschien vind je het gewoon heel leuk om zoveel mogelijk PV zelf te gebruiken, maar als je een dynamisch contract hebt en in NL woont (dus nog kan salderen) is de beste optimalisatie qua geld gezien altijd om op de goedkoopste uren van de dag te laden en in de duurste uren te ontladen (onder voorbehoud van een kleine marge die ergens tussen de 7-12 cent ongeveer ligt).

[swforlife]

Voor de geinteresseerd, Marstek heeft ook een lokale API die je kan aan laten zetten door hun support. Ik heb er een minimale home assistant integratie voor geschreven voor de liefhebber. https://github.com/swavans/home-assistant-marstek-local-api

[gho]

AUijtdehaag schreef op zaterdag 27 september 2025 @ 10:36:
@gho Kun je die Home Assistant Green niet gewoon in je netwerk hangen ipv aan een pc?
Dan krijgt die dezelfde ip range en subnet als de lilygo natuurlijk. Nu niet.

Dank voor de reactie, echter Home Assistant Green heeft uitsluitend UTP aansluiting dus geen Wifi verbinding, weet niet of er adapters voor zijn? Dat zou inderdaad het gemakkelijkste zijn

[AUijtdehaag]

@gho
En je hebt geen router waar die bedraad ethernet stekker in past van de green ???

[ Voor 32% gewijzigd door AUijtdehaag op 27-09-2025 15:11 ]

[superduper1969]

gho schreef op zaterdag 27 september 2025 @ 10:07:
Heb van alles geprobeerd, maar krijg totaal GEEN wifi verbinding bij de Marstek Modbus koppeling met de Lilygo !!!
ERROR Connecting to 192…… port 3232 failed: [Errno 111] Connection refused
Vermoedelijk omdat Home Assistant Green als device op UTP Windows 11 PC draait (??)
Marstek batterij draait overigens maandenlang perfect met TPLink Deco x20 wifi verbinding, op PC inschakelen Deco Wifi geeft geen verbinding.

Wat te doen?
Zelf totaal geen verstand van IP adress gedoe, net zomin of TPLink, of PC instelling dienen te worden aangepast, maar bergrijp er niets van.

Jullie hulp en tips wordt hoogst gewaardeerd , graag jullie reacties alvast dank voor de moeite

Visueel dan:

[gho]

wow daar heb ik niet aan gedacht, lijkt me een goede oplossing en ga ik uitproberen, hartelijk dank voor deze tip jullie horen nog

[gho]

Helaas om wanhopig van te worden, nog geen verbinding met de LilyGo, de led blijft ook nu rood branden....

[superduper1969]

gho schreef op zaterdag 27 september 2025 @ 18:54:
Helaas om wanhopig van te worden, nog geen verbinding met de LilyGo, de led blijft ook nu rood branden....

Het probleem wat je hebt wordt waarschijnlijk veroorzaakt door iets wat je ons niet verteld. De kleinste details kunnen belangrijk zijn.
In een eerdere post hat het het over een iot netwerk?
Deco heeft standaard deze ip range:192.168.68.1 heb je deze ooit veranderd?
In de deco app moet je al je apparaten kunnen vinden.
Als je nog aan het troubleshooten bent moet je alles op hetzelfde netwerk zetten.
Dus geen iot netwerk en zeker niet het wifi netwerk van je internet provider. Normaal als je met decos werkt zet je de WiFi van je internet provider uit.
En als je wil weten hoe dat nu zit met netwerken, dan heb je deze "gouwe ouwe" https://youtu.be/EOYe71RWMvk