Marstek PIB Domotica integratie en je Energierekening

[Avenger 2.0]

Hier ook wel gemerkt dat als de SOC 100% is en deze dan iets moet leveren en daalt tot 99% bij voldoende zon nadien niet meer gaat laden en op 99% blijft.

[PNARI]

Richardoe schreef op dinsdag 10 juni 2025 @ 19:27:
Leuk om te lezen van anderen, erg inspirerend, goed initiatief.


52 zonnepanelen:

• 1 set van 24 (Zuid-Oost) met SMA omvormer, die schakel ik via modbus af bij negatieve prijzen (nu nog inclusief belasting)
• 1 set van 28 (Zuid-West) met Solaredge omvormer, die schakel ik via de omvormer automatisch af bij negatieve prijzen (nu nog inclusief belasting)

Samen ongeveer 14kWh (afgelopen maand gemiddeld 55kWh per dag)

Contract: Zonneplan Dynamisch (Nederland)
Ik heb een 3*35A aansluiting omdat ik een bedrijf aan huis heb met 2 lasers en daarbij behorende koeling en ventilatie. Mijn dagverbruik zit ongeveer op 35-40kWh, dat verbruik zakelijk is vrijwel volledig overdag in de goedkope uren.

Verder probleer ik rekening te houden met Hybride auto laden en eind deze week met een EV om die te laden op goedkope uren (overdag)

Accu
Zonneplan 20kwh accu die puur op onbalans handelt, daar doe ik dus niets mee qua instellingen, en dat vond ik saai.

Uit hobby oogpunt dus een 2e accu, in dit geval een marstek 5,12kWh

Aansturing:
Ik meet alles in Home-Assistant en stuur daar zo veel mogelijk aan of via Node-Red als add-on op home-assistant. Wat ik nu doe is het volgende voor de marstek:

• Ik ga voor optimalisatie in Euro's ik kijk dus niet naar 0 op de meter.
• Ik laad/ontlaad nu nog op 800W, kan straks naar 2500W, maar maakt voor de logica niet veel uit.
• Logica via Node-red, aansturing via Lilygo/modbus
• In Node-red haal kijk ik om 06:00 wat de goedkoopste uren zijn in de 24 uren daarna en die uren gebruik ik om 6 uur te laden. Deze hoeven niet opeenvolgend te zijn.
• In Node-red haal kijk ik om 15:30 wat de Duurste uren zijn in de 24 uren daarna en die uren gebruik ik om 6 uur te ontladen. Deze hoeven niet opeenvolgend te zijn. Meestal een paar in de avond en een paar in de ochtend erna.

Dit is nog beter te doen door het in 2 uur te doen met 2500W op een dedicated groep, maar daarvoor wil ik graag de fases kunnen uitmeten en zie hieronder dat kan pas over een paar weken.

Wat opvalt:
Redlijk hoog sluipverbruik van 1kWh, mede door WTW (warmte-terug-win), boiler in schuur, pomp voor vloerverwarming, schrikdraad, lantaarnpalen, IT, extra koel/vries etc. Daar zou ik eigenlijk nog eens goed naar moeten kijken.

Wat loopt er nog:
- Ik heb het gevoel dat ik vrij slecht scoor met mijn Zonneplan accu door mijn trage P1 poort/meter, die is nog DSMR2.2 (dus update per 10 sec) deze wordt einde maand geupgrade naar een DSMR 5.2 meter, ik ben benieuwd wat ik daar van merk. Verder kan ik nu via P1 geen fases meten en werkt de CT003 ook niet dus ook vandaar een update.

Ik heb veel last van te hoge voltages waardoor mijn zonnepanelen willen afschalen, bij mooi weer met regelmaat 1 van de fases boven de 253V (kan ik zien via mijn omvormer eens per 5 minuten) straks meer inzicht hoop ik.

Toekomstzaken.
- Nu nog op gas verwarmen, wellicht een (hybride)warmtepomp in de toekomst.

En een plaatje omdat het kan, hierbij de maand mei om een beeld te krijgen:
[Afbeelding]

Mooie strategie en uitvoering.
Als je de omvormer afschakelt bij negatieve prijzen heb je toch ook geen opbrengst meer voor eigen gebruik of hoe doe je dat ? Mijn SMA omvormers zijn te oud , kunnen dus ook niet via sturing afgesxhakeld worden. Situatie in België is dat je bij veel leveranciers zo goed als niets meer krijgt voor injectie, bij sommige zelfs moet betalen als prijzen laag zijn , hoeven niet eens negatief te zijn. Voor het moment dat ik moet gaan betalen voor injectie zoek ik nog een manier om bv in stappen van 500 of 1000W verwarmingen in te schakelen wanneer er injectie is bij lage/cq negatieve prijzen. Iemand een idee hoe te realiseren ? Heb een Raspberry bestekd om me verder te kunnen verdiepen in HA.

[ Voor 3% gewijzigd door PNARI op 19-06-2025 08:00 ]

[superduper1969]

Danny van Kleef heeft weer een nieuwe video.
Specifiek over dit onderwerp.
https://youtu.be/05ydkt3jjhk

[Hometek]

Voor iedereen die via Home Assistant iets wil automatiseren op basis van stroomprijzen geeft deze site een uitleg van de 'cheapest-energy-hours' integratie.
Het is een beetje puzzelen met de verschillende opties, maar je kunt er handige binary sensors mee maken voor bv de goedkoopste X aaneengesloten uren of de X goedkoopste uren verdeeld over de dag etc.
Het werkt met diverse energieleveranciers, op de site worden Nordpool, Zonneplan en Tibber genoemd, ik gebruik EnergyZero.

[lennartb]

Klopt, als je "lowest=false" erbij zet pakt hij de duurste uren, daarna kun je weer een ontlaadsensor maken voor de duurste uren evt.

[Ellroe32]

https://community.homey.a...133149/71?u=roedi_de_lion

[ Voor 5% gewijzigd door Ellroe32 op 08-07-2025 23:25 ]

[De_Sint]

Hoi SatScan tipte mij over deze topic. Leuk om door te lezen.

Ik zit echt met de volgende vraag (neem hem ff 1 op 1 over van "Marstek Venus / Duravolt PnP Thuisaccu Modbus koppeling" topic)

Zijn er hier ook handige HA mensen die met de gegevens een sensor hebben over wat de besparing is voor de accu op basis van ontlading (dus W uit accu dat niet van het net is gehaald) op uurbasis ivm Dynamisch uur prijs op dat moment?
En met Nutsmeters dit doorrekenen naar dag, week, maand, jaar en ga zo maar door?

Ik heb wel het eea geprobeerd met AI, maar die stuurt me elke keer weer een andere kant op.
Bij de marstek_venus_battery2_control.yaml zie ik al een paar nutsmeters die dat doen bij discharge kWh. Maar niet icm met een prijssensor zoals bijv. sensor.entso_current_electricity_market_price (dat is toevallig mijn entso huidige marktprijs.

Als iemand al zoiets heeft en zou willen delen dan super graag. Of wellicht een noob op weg helpen.

Bvd

[Flesym]

De_Sint schreef op maandag 21 juli 2025 @ 16:39:
Hoi SatScan tipte mij over deze topic. Leuk om door te lezen.

Ik zit echt met de volgende vraag (neem hem ff 1 op 1 over van "Marstek Venus / Duravolt PnP Thuisaccu Modbus koppeling" topic)

Zijn er hier ook handige HA mensen die met de gegevens een sensor hebben over wat de besparing is voor de accu op basis van ontlading (dus W uit accu dat niet van het net is gehaald) op uurbasis ivm Dynamisch uur prijs op dat moment?
En met Nutsmeters dit doorrekenen naar dag, week, maand, jaar en ga zo maar door?

Ik heb wel het eea geprobeerd met AI, maar die stuurt me elke keer weer een andere kant op.
Bij de marstek_venus_battery2_control.yaml zie ik al een paar nutsmeters die dat doen bij discharge kWh. Maar niet icm met een prijssensor zoals bijv. sensor.entso_current_electricity_market_price (dat is toevallig mijn entso huidige marktprijs.

Als iemand al zoiets heeft en zou willen delen dan super graag. Of wellicht een noob op weg helpen.

Bvd

Zou handig zijn maar is ook complex omdat iedere provider andere kostenstructuur hanteert en je te maken hebt met terugleververgoeding, terugleverkosten, kosten per dag, staffelkosten, enz. Wat ik pragmatisch gedaan heb is deze kosten uit mijn contract in een spreadsheet gezet, een inschatting gemaakt van mijn terugleverIng dit jaar en zo de prijs per kWh die ik teruglever uitgerekend. Deze hanteer ik als exportprijs in HA en Marstek

[De_Sint]

Flesym schreef op dinsdag 22 juli 2025 @ 14:41:
[...]

Zou handig zijn maar is ook complex omdat iedere provider andere kostenstructuur hanteert en je te maken hebt met terugleververgoeding, terugleverkosten, kosten per dag, staffelkosten, enz. Wat ik pragmatisch gedaan heb is deze kosten uit mijn contract in een spreadsheet gezet, een inschatting gemaakt van mijn terugleverIng dit jaar en zo de prijs per kWh die ik teruglever uitgerekend. Deze hanteer ik als exportprijs in HA en Marstek

Ik weet niet precies wat je bedoeld. Ik haal de prijzen op van ENTSO-e en leg daar de factor overheen die leveringskosten/terugleveringskosten en belasting meeneemt. Die komt ook goed overeen met wat Essent vraagt per uur.
{% set s = {"extra_cost": 0.02528,"energie_belasting": 0.12286,"VAT": 1} %} {{((current_price + s.extra_cost + s.energie_belasting) * s.VAT) | float}}

Ik heb de sensor van huidige prijs sensor.entso_current_electricity_market_price.
Ik heb de sensor sensor.my_battery_discharging_in_w

Het luk me echter niet om een sensor te maken die van W een kWh maakt en een uur berekening maakt en reset. In mijn beperkte kennis zou je daarna nutsmeters kunnen maken van die sensor om per dag, week, maand, enz.
Ik heb al diverse berekeningen die AI aandraagt in configuration.yaml getest. Maar -of ze komen niet door de developers test of de berekenen verkeerd.

[Flesym]

De_Sint schreef op dinsdag 22 juli 2025 @ 16:21:
[...]


Ik weet niet precies wat je bedoeld. Ik haal de prijzen op van ENTSO-e en leg daar de factor overheen die leveringskosten/terugleveringskosten en belasting meeneemt. Die komt ook goed overeen met wat Essent vraagt per uur.
{% set s = {"extra_cost": 0.02528,"energie_belasting": 0.12286,"VAT": 1} %} {{((current_price + s.extra_cost + s.energie_belasting) * s.VAT) | float}}

Ik heb de sensor van huidige prijs sensor.entso_current_electricity_market_price.
Ik heb de sensor sensor.my_battery_discharging_in_w

Het luk me echter niet om een sensor te maken die van W een kWh maakt en een uur berekening maakt en reset. In mijn beperkte kennis zou je daarna nutsmeters kunnen maken van die sensor om per dag, week, maand, enz.
Ik heb al diverse berekeningen die AI aandraagt in configuration.yaml getest. Maar -of ze komen niet door de developers test of de berekenen verkeerd.

Ok, ik doe in HA iets vergelijkbaars denk ik met mijn wasdroger, niet via Yaml maar via instellingen -> apparaten en diensten -> helpers. Ik weet niet of het je vraag beantwoord maar hierbij wat screenshots van de 2 helpers. De eerste bepaalt de cumulatieve waarde, de tweede maakt er een nuts meter van.

[De_Sint]

[quote]Flesym schreef op dinsdag 22 juli 2025 @ 16:41:
[...]

Ok, ik doe in HA iets vergelijkbaars denk ik met mijn wasdroger, niet via Yaml maar via instellingen -> apparaten en diensten -> helpers. Ik weet niet of het je vraag beantwoord maar hierbij wat screenshots van de 2 helpers. De eerste bepaalt de cumulatieve waarde, de tweede maakt er een nuts meter van.

Interessant.. Ik zie echter nergens de omzetting naar geld, met name de prijs bij dynamisch contract op dat uur.
Wellicht kijk ik erover heen.

[Flesym]

De_Sint schreef op woensdag 23 juli 2025 @ 06:29:
[quote]Flesym schreef op dinsdag 22 juli 2025 @ 16:41:
[...]
Interessant.. Ik zie echter nergens de omzetting naar geld, met name de prijs bij dynamisch contract op dat uur.
Wellicht kijk ik erover heen.

Ah, sorry, nu snap ik pas wat je bedoelt en daarmee kan ik je niet helpen. Ik heb een vast contract dus ik heb nooit gekeken naar de omzetting in geld.

[Hometek]

De_Sint schreef op woensdag 23 juli 2025 @ 06:29:
...
Interessant.. Ik zie echter nergens de omzetting naar geld, met name de prijs bij dynamisch contract op dat uur.
Wellicht kijk ik erover heen.

Misschien help dit topic je een beetje op weg.

[De_Sint]

Hometek schreef op woensdag 23 juli 2025 @ 13:27:
[...]

Misschien help dit topic je een beetje op weg.

Dank.. Helaas is de Topic oud en komen ze nooit tot een oplossing.

Ik denk dat ik het nu succesvol voor elkaar heb gekregen dat een sensor elk uur de kwh opteld en het op dat moment geldige dynamische bedrag erbij rekend, en dan reset voor het volgende uur.
Daar Nutsmeters op gezet voor dag, week, maan en jaar en het lijkt te werken.

Dank iedereen voor het meedenken.

[tinamar]

Kan iemand mij op weg helpen om een automatisering te maken in HA
Als er nu 's morgens niet veel meer in de Marstek zit en in de middag goed weer voorspeld wordt zet ik soms de MT via modbus in discharge om soc eens op 11 te krijgen.
Ik zou een automatisering willen maken zodat wanneer de MT bij soc 11 naar standbij gaat de modbus weer gewoon naar nom gaat zodat het laden terug begint bij voldoende zon.
Er zijn zoveel parameters in HA, of is er een andere/makkelijkere manier om dit voor elkaar te krijgen?
Thanks

[Hometek]

Een ervaringsbericht over het bouwen van een EMS in HA

Ik ben in Mei begonnen met het bouwen van een EMS voor mijn batterijen en zonnepanelen. HA was op dat moment volledig nieuw voor mij. De eerste leercurve was daarom HA leren kennen en een apart wifi netwerk in te richten voor de diverse apparaten.
Het flashen van de Lilygo’s aan hand van de instructies op Tweakers gaf alvast enige hints over de werking van de verschillende onderdelen in HA (voor een HA beginner zijn de instructies behoorlijk cryptisch, er wordt heel wat voorkennis verwacht).
HA blijkt een heerlijk flexibel platform, maar daardoor ook hopeloos complex, je weg zien te vinden tussen add-on’s, integraties, sensoren, entiteiten, helpers, scripts, HACS en de diverse yaml’s is een hele puzzel. Als je er dieper induikt komen daar nog de syntax variaties van java, json en jsonata bovenop.
Er is veel documentatie beschikbaar en veel voorbeelden op diverse forums, het is echter te veel om helemaal te leren, het lijkt er op dat de meeste gebruikers, net als ik, net voldoende leren om dat te realiseren wat ze voor ogen hadden, en net niet voldoende om te begrijpen wat er mis gaat als het niet werkt.
Het grootste struikelblok is de gevoelige syntax, één komma, of één spatie te veel of te weinig en er volgt een hele reeks aan foutmeldingen. Met name in de eerste paar weken kan dat erg frustrerend zijn. Maar op een gegeven moment weet je waar je op moet letten.

Mijn EMS is bedoeld voor een hele specifieke toepassing, een klein huis, een kleine PV installatie en relatief veel batterijcapaciteit (2x Marstek Venus E).
De beoogde strategie is relatief simpel:

• De batterijen elke dag opladen met PV, indien nodig aangevuld van het net gedurend de goedkope uren
• Steeds 1 batterij in auto mode, de andere staat stand-by.
• EV opladen met PV en/of op goedkoopste uren, maar niet via batterij

Deze strategie kan denk ik niet met simpele automatiseringen in HA (althans niet op een overzichtelijke manier). Scripts zijn misschien een optie. Ik heb gekozen voor Node-RED omdat ik de grafische UI prettig vindt.
Nadat ik alle apparaten stabiel aan mijn wifi netwerk en HA had gekoppeld, lukte het al vrij snel om de eerste flows in Node-RED te bouwen voor het automatisch wisselen van de batterij.
De volgende stap kostte meer moeite, voor de strategie is externe data nodig; verwachte PV-opwek, verwachte temperatuur en day-ahead energieprijzen. Voor elk bestaan diverse integraties, HACS en/of add-on’s, elk met zijn eigen voor- en nadelen. Het uitzoeken en testen was vrij veel werk.
Ondertussen groeide het aantal flows in Node-RED, en moest ik ook meer helpers en sensoren in HA toevoegen om de gewenste interacties tussen dashboards, flows en devices te realiseren.

Batterij wissel flow in Node-Red


Op een gegeven moment heb je dan een werkend systeem dat ogenschijnlijk ‘af’ is. Totdat er iets mis gaat, de batterijen raken niet vol of de batterij wissel blijft ‘hangen’. Dan begint de periode van het debuggen en afstellen.
Het lastigste in HA/Node-RED zijn voor mij de voorwaardelijke beslissingen, bv. wissel van batterij A naar B indien SOC zakt tot 20%, maar wissel niet als SOC stijgt naar 20%. Met name als je robust wilt zijn voor plotselinge sprongen in de SOC van bv 21 naar 11%. De beschikbare trend functies in HA zijn hiervoor te traag (of ik gebruik ze niet goed). Ik heb het nu redelijk werkend met een combinatie van threshold helpers in HA en switches in Node-RED. Ook ontstaan er af en toe situaties die ik niet voorzien had. Bv batterij A op 100% en batterij B op 11% terwijl PV opwek ongeveer gelijk is aan het verbruik. Welke batterij moet dan aan?
Verder zijn de weersvoorspellingen niet erg betrouwbaar, waardoor er een grote spreiding in berekende opwek en verbruik ontstaat. Ik heb dit nu voor de zomer situatie redelijk goed afgestemd, maar weet nog niet of dit in herfst en winter ook goed gaat werken.
Waarschijnlijk duurt het tot in de winter voordat alles goed is ingeregeld.

Het is een leuke hobby en ik leer er een hoop van, maar het is meer werk dan ik had verwacht.

Systeem dashbord (plus/min voor grid/use/solar/battery is niet consistent, maar het werkt voor mij )

[Hometek]

@tinamar

Zelf werk ik meer in Node-Red, maar misschien helpt dit je een beetje op weg.
Niet getest, dient slechts als generiek voorbeeld!
Dit voorbeeld is gebaseerd op SOC waarde <12 als trigger, je zou ook naar de inverter state kunnen kijken.

Nieuwe automatisering maken en dan entiteit kiezen


Voor SOC kies je numeric state (voor de inverter state zou je 'state' moeten gebruiken)


De juiste entiteit in HA kiezen (SOC) en de drempewaarde instellen (kleiner dan 12)


Als Actie kies je 'select' (omdat de entiteit een keuze lijst is)


In dit voorbeeld gebruik ik 2 acties.
De eerste schakeld de forced charging uit (stop) (deze actie is misschien niet nodig)
De tweede zet de work mode op NOM (bij mij is dat 'auto', in de github yaml is het 'anti-feed')

[tinamar]

Bedankt, dat helpt, ga ik eens mee verder puzzelen.👍
Maar vandaag niet meer, wat te lang op een terras blijven hangen

[ Voor 38% gewijzigd door tinamar op 02-08-2025 21:06 ]

[Ellroe32]

Hometek schreef op zaterdag 2 augustus 2025 @ 14:38:
Een ervaringsbericht over het bouwen van een EMS in HA

Ik ben in Mei begonnen met het bouwen van een EMS voor mijn batterijen en zonnepanelen. HA was op dat moment volledig nieuw voor mij. De eerste leercurve was daarom HA leren kennen en een apart wifi netwerk in te richten voor de diverse apparaten.
Het flashen van de Lilygo’s aan hand van de instructies op Tweakers gaf alvast enige hints over de werking van de verschillende onderdelen in HA (voor een HA beginner zijn de instructies behoorlijk cryptisch, er wordt heel wat voorkennis verwacht).
HA blijkt een heerlijk flexibel platform, maar daardoor ook hopeloos complex, je weg zien te vinden tussen add-on’s, integraties, sensoren, entiteiten, helpers, scripts, HACS en de diverse yaml’s is een hele puzzel. Als je er dieper induikt komen daar nog de syntax variaties van java, json en jsonata bovenop.
Er is veel documentatie beschikbaar en veel voorbeelden op diverse forums, het is echter te veel om helemaal te leren, het lijkt er op dat de meeste gebruikers, net als ik, net voldoende leren om dat te realiseren wat ze voor ogen hadden, en net niet voldoende om te begrijpen wat er mis gaat als het niet werkt.
Het grootste struikelblok is de gevoelige syntax, één komma, of één spatie te veel of te weinig en er volgt een hele reeks aan foutmeldingen. Met name in de eerste paar weken kan dat erg frustrerend zijn. Maar op een gegeven moment weet je waar je op moet letten.

Mijn EMS is bedoeld voor een hele specifieke toepassing, een klein huis, een kleine PV installatie en relatief veel batterijcapaciteit (2x Marstek Venus E).
De beoogde strategie is relatief simpel:

• De batterijen elke dag opladen met PV, indien nodig aangevuld van het net gedurend de goedkope uren
• Steeds 1 batterij in auto mode, de andere staat stand-by.
• EV opladen met PV en/of op goedkoopste uren, maar niet via batterij

Deze strategie kan denk ik niet met simpele automatiseringen in HA (althans niet op een overzichtelijke manier). Scripts zijn misschien een optie. Ik heb gekozen voor Node-RED omdat ik de grafische UI prettig vindt.
Nadat ik alle apparaten stabiel aan mijn wifi netwerk en HA had gekoppeld, lukte het al vrij snel om de eerste flows in Node-RED te bouwen voor het automatisch wisselen van de batterij.
De volgende stap kostte meer moeite, voor de strategie is externe data nodig; verwachte PV-opwek, verwachte temperatuur en day-ahead energieprijzen. Voor elk bestaan diverse integraties, HACS en/of add-on’s, elk met zijn eigen voor- en nadelen. Het uitzoeken en testen was vrij veel werk.
Ondertussen groeide het aantal flows in Node-RED, en moest ik ook meer helpers en sensoren in HA toevoegen om de gewenste interacties tussen dashboards, flows en devices te realiseren.

Batterij wissel flow in Node-Red
[Afbeelding]

Op een gegeven moment heb je dan een werkend systeem dat ogenschijnlijk ‘af’ is. Totdat er iets mis gaat, de batterijen raken niet vol of de batterij wissel blijft ‘hangen’. Dan begint de periode van het debuggen en afstellen.
Het lastigste in HA/Node-RED zijn voor mij de voorwaardelijke beslissingen, bv. wissel van batterij A naar B indien SOC zakt tot 20%, maar wissel niet als SOC stijgt naar 20%. Met name als je robust wilt zijn voor plotselinge sprongen in de SOC van bv 21 naar 11%. De beschikbare trend functies in HA zijn hiervoor te traag (of ik gebruik ze niet goed). Ik heb het nu redelijk werkend met een combinatie van threshold helpers in HA en switches in Node-RED. Ook ontstaan er af en toe situaties die ik niet voorzien had. Bv batterij A op 100% en batterij B op 11% terwijl PV opwek ongeveer gelijk is aan het verbruik. Welke batterij moet dan aan?
Verder zijn de weersvoorspellingen niet erg betrouwbaar, waardoor er een grote spreiding in berekende opwek en verbruik ontstaat. Ik heb dit nu voor de zomer situatie redelijk goed afgestemd, maar weet nog niet of dit in herfst en winter ook goed gaat werken.
Waarschijnlijk duurt het tot in de winter voordat alles goed is ingeregeld.

Het is een leuke hobby en ik leer er een hoop van, maar het is meer werk dan ik had verwacht.

Systeem dashbord (plus/min voor grid/use/solar/battery is niet consistent, maar het werkt voor mij )
[Afbeelding]

Wat een leuk stukje!! Zo herkenbaar ook.....je denkt er te zijn...maar dan ben je er toch weer niet.

Ik heb een eigen app in Homey gemaakt:https://community.homey.a...140156/27?u=roedi_de_lion

[corsat]

Ik heb mijn beide Marstek batterijen deze week in 2 stappen geupdate naar 153 en bms 215 zonder enig probleem en uiteindelijk mijn lilygos werkend gekregen en staan in HA. Ben beginner met HA en zoek nu naar handvaten om te gaan optimaliseren. Ik heb 3 fasen en op fase 2 staat een Marstek met eigen groep en op fase 3 staat een Marstek met eigen groep op 2500w ontgrendeld en aangestuurd via mijnshelly per fase. Op fase 1 zit alleen mij Alfen laadpaal. Ik wil nu mijn beide Marstek batterijen als 1 batterij via ct003 laten fungeren en als de laadpaal in gebruik komt moeten ze op manual gezet worden totdat de auto vol is. Hier wil ik mee beginnen en later optimaliseren met mijn 30 zonnepanelen. Hoe vlieg ik dit aan, node red heb ik iets over gelezen maar hoe of waar moet ik nu beginnen?

[superduper1969]

corsat schreef op zaterdag 23 augustus 2025 @ 11:34:
Ik heb mijn beide Marstek batterijen deze week in 2 stappen geupdate naar 153 en bms 215 zonder enig probleem en uiteindelijk mijn lilygos werkend gekregen en staan in HA. Ben beginner met HA en zoek nu naar handvaten om te gaan optimaliseren. Ik heb 3 fasen en op fase 2 staat een Marstek met eigen groep en op fase 3 staat een Marstek met eigen groep op 2500w ontgrendeld en aangestuurd via mijnshelly per fase. Op fase 1 zit alleen mij Alfen laadpaal. Ik wil nu mijn beide Marstek batterijen als 1 batterij via ct003 laten fungeren en als de laadpaal in gebruik komt moeten ze op manual gezet worden totdat de auto vol is. Hier wil ik mee beginnen en later optimaliseren met mijn 30 zonnepanelen. Hoe vlieg ik dit aan, node red heb ik iets over gelezen maar hoe of waar moet ik nu beginnen?

Copilot/ChatGPT en andere AI's kunnen Home assistant automatiseringen ontwerpen.
Je moet wel eerst even de namen va de sensors opzoeken en die benoemen en dan zeg je:
Ik wil een home assistant automatisering die xxx doet en als xxx boven 20A is dan moet je dat doen enzovoort. Gebruik sensors x.y.en z enzovoort.
Alle foutmeldingen plak je weer in de AI en vaak krijg je ook als het niet helemaal lukt voldoende feedback en uitleg waarom iets gebeurt op wel moment.

[SatScan]

corsat schreef op zaterdag 23 augustus 2025 @ 11:34:
Ik heb mijn beide Marstek batterijen deze week in 2 stappen geupdate naar 153 en bms 215 zonder enig probleem en uiteindelijk mijn lilygos werkend gekregen en staan in HA. Ben beginner met HA en zoek nu naar handvaten om te gaan optimaliseren. Ik heb 3 fasen en op fase 2 staat een Marstek met eigen groep en op fase 3 staat een Marstek met eigen groep op 2500w ontgrendeld en aangestuurd via mijnshelly per fase. Op fase 1 zit alleen mij Alfen laadpaal. Ik wil nu mijn beide Marstek batterijen als 1 batterij via ct003 laten fungeren en als de laadpaal in gebruik komt moeten ze op manual gezet worden totdat de auto vol is. Hier wil ik mee beginnen en later optimaliseren met mijn 30 zonnepanelen. Hoe vlieg ik dit aan, node red heb ik iets over gelezen maar hoe of waar moet ik nu beginnen?

Met mijn wallbox heb ik kort gezegd het volgende gedaan

Via hacs de Wallbox in de HA geïntegreerd, dit om alle selecteerbare items/sensoren in HA te krijgen.

Uitgaande van KISS
In HA bij instellingen - apparaten en diensten - wallbox (selecteren)

Dan + bij automatiseringen

EV start laden aangemaakt
- apparaat gekozen (wallbox)
- trigger - wallbox pauzeren/hervatten aangezet (deze optie is in wallbox standaard beschikbaar)
- Doe dan verander marstek user mode optie in manual (manual in MT app hebben geen actieve regels dus batterij gaat in standby))

Bij stoppen met laden net andersom....
EV stopt met laden aangemaakt
trigger ... pauzeren en hervatten uitgezet.
doe dan - usermode naar Anti feed (is NOM)

Auto aansluiten en (handmatig)testen maar...

That's all, lekker simpel en effectief.
Bekijk deze even;
YouTube: Automatiseren met Home Assistant - zo doe je dat zonder stress!

1. zorg dat je laadpaal in HA is geïntegreerd
2. bekijk de schakelmogelijkheden/sensoren en de benamingen
3. maak een automatisering aan zoals jij die wil

[ Voor 5% gewijzigd door SatScan op 24-08-2025 16:53 ]

[Hometek]

NOM en PV

Nu ik enige ervaring heb opgedaan met HA, en de basis-functies in mijn systeem redelijk stabiel werken, is het tijd om opties voor specifieke strategieen toe te voegen.

Een belangrijke reden om zelf een EMS te bouwen is voor mij de mogelijkheid om zowel verbruik als ook teruglevering zoveel mogelijk naar NOM te kunnen regelen.
PV opwek sturen is nog geen erg populair thema, veel installaties zijn daar ook niet op ingericht. Maar de energietransitie is moeilijk te voorspellen, en het lijkt mij zinvol om mijn systeem zodanig in te richten dat ik kan kiezen voor maximale PV opwek, met veel teruglevering, of voor gestuurde PV opwek, zonder teruglevering.

Zolang je kunt salderen is terugleveren vanuit financieel oogpunt uiteraard voordeliger. Anderzijds zorgt terugleveren ook voor meer 'drukte' op het stroomnet. Om dit dilemma te omzijlen gebruik ik nu een strategie waarbij het overschot PV pas terug geleverd wordt als de stroomprijs het hoogst is, ervan uitgaande dat er dan op het stroomnet voldoende vraag naar stroom is.

Mijn EMS heeft nu twee aparte regelingen:



Bij zonsopgang wordt berekent hoveel panelen er ingeschakeld moeten worden om aan het einde van de middag de batterij weer vol te hebben




Aan het einde van de middag wordt berekent wat de laagste SOC bij zonsopgang de volgende dag mag zijn om met de verwachte opwek de batterij weer vol te kunnen laden. Met het verwachte verbruik tot zonsopgang wordt dan bepaald hoeveel kWh bij de hoogste prijs ontladen kan worden.


Omdat ik de regelingen apart aan en uit kan zetten heb ik 4 mogelijkheden:




Hieronder een screenshot van het systeem in actie met beide regelingen actief, hoogste stroomprijs is momenteel rond 20:00. Ik heb een onderlimiet van 30% op de SOC als reserve.
Op 22 Augustus bleef de PV opwek achter tov de voorspelling en raakte de batterij niet vol.
De onderste grafiek is het verbruik gemeten door de digitale meter (P1).
Ik heb 2 batterijen die met 1600W ontladen, daarom is de teruglever piek 3200W.

[ Voor 4% gewijzigd door Hometek op 24-08-2025 15:36 ]

[corsat]

SatScan schreef op zondag 24 augustus 2025 @ 10:23:
[...]


Met mijn wallbox heb kort gezegd het volgende gedaan

Via hacs de Wallbox in de HA geïntegreerd, dit om alle selecteerbare items/sensoren in HA te krijgen.

Uitgaande van KISS
In HA bij instellingen - apparaten en diensten - wallbox (selecteren)

Dan + bij automatiseringen

EV start laden aangemaakt
- apparaat gekozen (wallbox)
- trigger - wallbox pauzeren/hervatten aangezet (deze optie is in wallbox standaard beschikbaar)
- Doe dan verander marstek user mode optie in manual (manual in MT app hebben geen actieve regels dus batterij gaat in standby))

Bij stoppen met laden net andersom....
EV stopt met laden aangemaakt
trigger ... pauzeren en hervatten uitgezet.
doe dan - usermode naar Anti feed (is NOM)

Auto aansluiten en (handmatig)testen maar...

That's all, lekker simpel en effectief.
Bekijk deze even;
YouTube: Automatiseren met Home Assistant - zo doe je dat zonder stress!

1. zorg dat je laadpaal in HA is geïntegreerd
2. bekijk de schakelmogelijkheden/sensoren en de benamingen
3. maak een automatisering aan zoals jij die wil

Thks Satscan. Mijn Alfen laadpaal zit al in HA en alle entiteiten zijn beschikbaar. Ik heb een start gemaakt in Node Red maar moet mij nog iets meer verdiepen in de materie. In Node Red heb ik de benodigde entiteiten al gevonden maar moet nu effe uitzoeken hoe ik dat aan elkaar kan knopen.

[SatScan]

corsat schreef op zondag 24 augustus 2025 @ 16:42:
[...]

Thks Satscan. Mijn Alfen laadpaal zit al in HA en alle entiteiten zijn beschikbaar. Ik heb een start gemaakt in Node Red maar moet mij nog iets meer verdiepen in de materie. In Node Red heb ik de benodigde entiteiten al gevonden maar moet nu effe uitzoeken hoe ik dat aan elkaar kan knopen.

Dat is wel een stukje ingewikkelder dan zoals ik het doe

[corsat]

Ik heb jou weg inmiddels ook gevonden en is idd wat eenvoudiger, morgen testen.

[SatScan]

corsat schreef op zondag 24 augustus 2025 @ 22:36:
Ik heb jou weg inmiddels ook gevonden en is idd wat eenvoudiger, morgen testen.

Laat maar weten als ik ergens een duwtje kan geven...

[corsat]

SatScan schreef op maandag 25 augustus 2025 @ 10:16:
[...]


Laat maar weten als ik ergens een duwtje kan geven...

thks Satscan maar het werkt al, gaat sneller dan de lilygo's werkend krijgen Marsteks op de CT003 nu als 1 batterij en als ik ga laden beiden op manual en na het laden weer netjes op zelf consumptie. Nu verder aan de slag met mijn energie dashboard.

[AUijtdehaag]

@corsat
Misschien ook eens naar EVCC kijken.
Heb het sinds gisteren draaien en de M5stack atom esphome code naar modbus tcp/ip geflashed
Marstek communiceert dan met EVCC via de ESP met modbus TCP/IP (over wifi)

Lilygo code kan je ook wel aanpassen vermoed ik (uit mijn voorbeeld code)
https://github.com/fonske...arstek_tcp_ip_bridge.yaml
Misschien wil @superduper1969 het wel voor je veranderen en een nieuwe yaml maken.

nog een tip:
AUijtdehaag in "Evcc slim laden met de zon en dynamische tarieven"

Alfen is ook ondersteund zag ik (tegen kleine betaling/sponsership)
https://docs.evcc.io/en/docs/devices/chargers#alfen

[ Voor 10% gewijzigd door AUijtdehaag op 25-08-2025 17:21 ]

[corsat]

Ik had het bericht over EVCC al gelezen maar zoek nog even naar de toegevoegde waarde van deze intergratie. Ik wil wel mijn zonnepanelen afgifte die op oost/west liggen optimaliseren m.b.t. mijn laadpaal en bijvoorbeeld de weersvoorspelling en mijn weekplanning gaan combineren om zoveel mogelijk opbrengst in de auto te krijgen. Ik heb een gedateerde alfen laadpaal met 1 fase (is genoeg voor mijn plug-in) maar wel met alle licenties.

[corsat]

Vraagje, ik krijg in HA de vraag om mijn lilygo te updaten, herkent iemand dat en moet je via HA je Lilygo updaten?
Andere vraag, kan ik in HA onder de lilygo/Marstek in automatisering een actie aanmaken dat tijdens het laden van mijn auto en ik heb dan nog overschot van mijn zonnepalen wat terug het net opgaat dat dit naar mijn batterij gaat. Ik wil hem dus met mijn shelly entiteit total power weer van manual naar NOM terug laten schakelen. Ik heb een automatisering aangemaakt en vandaag getest maar ik zie de marstek niet terug schakelen.

[SatScan]

corsat schreef op zondag 31 augustus 2025 @ 21:48:
Vraagje, ik krijg in HA de vraag om mijn lilygo te updaten, herkent iemand dat en moet je via HA je Lilygo updaten?
Andere vraag, kan ik in HA onder de lilygo/Marstek in automatisering een actie aanmaken dat tijdens het laden van mijn auto en ik heb dan nog overschot van mijn zonnepalen wat terug het net opgaat dat dit naar mijn batterij gaat. Ik wil hem dus met mijn shelly entiteit total power weer van manual naar NOM terug laten schakelen. Ik heb een automatisering aangemaakt en vandaag getest maar ik zie de marstek niet terug schakelen.

Je kunt gewoon via HA de update doen. Komt regelmatig langs zodra de ESPHome Builder is geüpdatet in HA

je tweede vraag ik weet niet of je tijdens laden van de EV ook het overtollige naar de batt kunt laten gaan.
Mijn Wallbox kijkt wat de real-time opbrengst is en schakelt vermogen bij of af als de panelen meer of minder energie leveren. Als de EV wordt geladen staan mijn batterijen in manueel zonder een taak. Zodra de wallbox stopt met laden worden mijn batterijen terug gezet in modi NOM (HA automation)

Weet dat elke EV andere laadprofielen heeft dus bij jou kan het gedrag hierdoor anders zijn dan bij mij.

[rb1213]

een Home Assistant battery switcher template Sensor
deze keer zonder P1 data en voor 3 batterijen

die probeert altijd zo weinig mogelijk batterijen actief te hebben, het dichts bij max limiet gebaseerd op hun activiteit ( om een beter rendement te hebben)
geeft een json list van de batterijen die minimaal actief moeten zijn , enkel die dan op Self-Feed zetten via een automation
de sensor namen aanpassen uiteraard voor ac_power en soc.

code:

- name: "Battery Manager Final Batteries"
      unique_id: battery_manager_final_batteries
      state: >
        {% set powers = {
          'marstek': states('sensor.marstek_ac_power') | float(0),
          'marstek2': states('sensor.marstek2_ac_power') | float(0),
          'marstek3': states('sensor.marstek3_ac_power') | float(0)
        } %}
    
        {% set socs = {
          'marstek': states('sensor.marstek_battery_soc') | float(0),
          'marstek2': states('sensor.marstek2_battery_soc') | float(0),
          'marstek3': states('sensor.marstek3_battery_soc') | float(0)
        } %}
    
        {% set total_power = powers['marstek'] + powers['marstek2'] + powers['marstek3'] %}
        {% set abs_total = (total_power | abs )+1%}
        {% set mode = 'discharge' if total_power > 2 else 'charge' %}
    
        {% set capacities = namespace(map={}) %}
        {% for name in powers %}
          {% set soc = socs[name] %}
          {% if mode == 'charge' %}
            {% if soc == 99 %}
               {% set capacities.map = capacities.map | combine({ name: 1010 }) %}
            {% elif soc < 100 %}
               {% set capacities.map = capacities.map | combine({ name: 2090 }) %}
            {% endif %}
          {% elif mode == 'discharge' and soc > 11 %}
            {% set capacities.map = capacities.map | combine({ name: 2090 }) %}
          {% endif %}
        {% endfor %}
    
        {% set sorted = namespace(list=[]) %}
        {% for name in capacities.map %}
          {% set inserted = false %}
          {% for i in range(sorted.list | length) %}
            {% set current = sorted.list[i] %}
            {% if powers[name] | abs > powers[current] | abs %}
              {% set sorted.list = sorted.list[:i] + [name] + sorted.list[i:] %}
              {% set inserted = true %}
              {% break %}
            {% endif %}
          {% endfor %}
          {% if not inserted %}
            {% set sorted.list = sorted.list + [name] %}
          {% endif %}
        {% endfor %}
    
        {% set selected = namespace(list=[], total=0) %}
        {% for name in sorted.list %}
          {% if selected.total < abs_total %}
            {% set selected.list = selected.list + [name] %}
            {% set selected.total = selected.total + capacities.map[name] %}
          {% endif %}
        {% endfor %}
        
        {% if selected.list == [] %}
         {% set selected_list = ['marstek', 'marstek2', 'marstek3'] %}
        {% endif %}
    
        {{ selected.list | tojson }}

[Jeepertje]

Hallo,

Ik twijfelde wat om deze post hier of in het Modbus topic te plaatsen, indien ik toch verkeerd heb gekozen mag deze uiteraard verplaatst worden ☺️

Ondertussen heb ik de MT reeds ruim 4 maand in gebruik om NOM aan te houden, met momenteel een RTE 73,3% en een netafname van amper 0,56kWh/dag, dik tevreden van. (Gemeten met homewizard P1 en energie socket)
Ik werk hiervoor met de HW P1 meter wegens eerdere problemen met de CT003.

Echter komt er binnenkort een einde aan de lange zonnige dagen, en zal als Belg de focus van NOM naar Max 2,5kW moeten verlegd worden.

Ik heb een poging gedaan om van de Modbus topic ook maar iets van te begrijpen, maar helaas, dit is allemaal chinees voor mij.
Ik heb enkel een oude MacBook waar ik 2x per jaar wat filmpjes mee monteer, maar daar stopt mijn computergebruik en zeer beperkte kennis.

Dus, kan er iemand mij helpen om iets in elkaar te steken zodat onderstaande plug and play te krijgen is voor een leek zoals ik?
Ik vermoed dat er veel Belgen zijn die dergelijke set-up ook wel handig zullen vinden:

-Bij SOC van 50% en meer, NOM aanhouden.

-SOC onder de 50%, max 2,5kW netafname aanhouden en enkel opladen via overproductie zonnepanelen.

-Onder de 20% SOC, batterij ook opladen met netstroom (max 2,5kW afname aanhouden)

-Om de SOC (en de balans van de cellen) wat correct te houden; om de 7 dagen om 1u 's nachts opladen tot 100% met maximaal vermogen (maar Max 2,5kW netafname)

Uiteraard zou het erg handig zijn om eenvoudig de bovenstaande als variabelen te kunnen aanpassen zodat ieder voor zichzelf dit wat meer kan optimaliseren en ook eenvoudig kan schakelen tussen zomer (NOM) en winter (Max 2,5kW afname).

Alvast dank voor het meedenken

[SatScan]

Jeepertje schreef op dinsdag 2 september 2025 @ 14:27:
Hallo,

Ik twijfelde wat om deze post hier of in het Modbus topic te plaatsen, indien ik toch verkeerd heb gekozen mag deze uiteraard verplaatst worden ☺️

Ondertussen heb ik de MT reeds ruim 4 maand in gebruik om NOM aan te houden, met momenteel een RTE 73,3% en een netafname van amper 0,56kWh/dag, dik tevreden van. (Gemeten met homewizard P1 en energie socket)
Ik werk hiervoor met de HW P1 meter wegens eerdere problemen met de CT003.

Echter komt er binnenkort een einde aan de lange zonnige dagen, en zal als Belg de focus van NOM naar Max 2,5kW moeten verlegd worden.

Ik heb een poging gedaan om van de Modbus topic ook maar iets van te begrijpen, maar helaas, dit is allemaal chinees voor mij.
Ik heb enkel een oude MacBook waar ik 2x per jaar wat filmpjes mee monteer, maar daar stopt mijn computergebruik en zeer beperkte kennis.

Dus, kan er iemand mij helpen om iets in elkaar te steken zodat onderstaande plug and play te krijgen is voor een leek zoals ik?
Ik vermoed dat er veel Belgen zijn die dergelijke set-up ook wel handig zullen vinden:

Alvast dank voor het meedenken

Neem eens contact op met @Edzelf misschien dat hij je verder kan helpen.
https://github.com/Edzelf/venus-control/blob/main/venus.pdf

[ajouwens]

Het leek mij wel leuk om dit te delen:

code:

  - type: custom:gauge-card-pro
    entity: sensor.mt_1_power
    entity2: sensor.lilygo_rs485_marstek_battery_remaining_capacity
    needle: true
    min: -800
    max: 2500
    icon:
      type: battery
      value: sensor.lilygo_rs485_marstek_battery_state_of_charge
    segments:
      - from: -800
        color: var(--green-color)
      - from: 0
        color: var(--blue-color)
      - from: 800
        color: var(--purple-color)
      - from: 1600
        color: var(--orange-color)
      - from: 2500
        color: var(--red-color)
    inner:
      min: 0
      max: 6
      mode: needle
      gradient: true
      gradient_resolution: high
      segments:
        - from: 0
          color: var(--red-color)
        - from: 1
          color: var(--light-blue-color)
        - from: 2
          color: var(--blue-color)
        - from: 3
          color: var(--orange-color)
        - from: 4
          color: var(--light-green-color)
        - from: 5
          color: var(--green-color)
    gradient: true
    gradient_resolution: high
    value_texts:
      primary: "{{ states(entity) | float | round(0) }}W"
      secondary: "{{ states(entity2) | float | round(2) }}kWh"
      secondary_color: "#aaa"
    titles:
      primary: MT-1

Natuurlijk naar eigen inzicht aan te passen
(Meer info: https://github.com/benjam...rd-pro?tab=readme-ov-file)

[rb1213]

deleted had fouten

[ Voor 113% gewijzigd door rb1213 op 08-09-2025 17:32 ]

[Hometek]

De HA Solcast integratie (voorspelling PV opwek) heeft sinds de laatste update een 'Auto-dampen' feature.
Deze feature corrigeert automatisch structurele lokale afwijkingen, bv door schaduw, in de voorspelling. Volgens de beschrijving wordt data van de afgelopen 14 dagen gebruikt om correcties te bepalen.
Ik heb de functie gisteren geactiveerd, en zie vandaag idd een duidelijk betere voorspelling dan de afgelopen dagen. Als dit idd goed blijkt te werken maakt het Solcast een stuk betrouwbaarder.

Voorspelling en opwek gisteren (met handmatige correctie, in de zomer ingesteld)


Voorspelling en opwek vandaag (met automatische correctie)

[ Voor 6% gewijzigd door Hometek op 09-09-2025 09:58 ]

[Ploeftia]

Een reactie op (Meer info: https://github.com/benjam...rd-pro?tab=readme-ov-file)

Hij gebruikt een ESP32-S3_Zero dit is een bordje met een slecht wifi bereik. Daar de keramische antenne te dicht bij de chip zit. Ze hebben geen Antenna keep out area gebruikt bij Waveshare. Een Xiao S3 met externe antenne werkt beter. Of deze op de print past en werkt weet ik niet. Zal wel van niet.

[BertusB404]

Is er iemand die de marstek batterij gebruikt met een smartgridone van eniris?
Daarmee kan men de batterij koppelen aan Frank energie voor handel op de onbalans markt.

Echter vind ik het een moeilijk te vinden apparaat en vermoed dat het nogal prijzig is.
Wellicht is er een omweg te vinden, maar het eniris protocol zal alles behalve open zijn vermoed ik.

[Hometek]

BertusB404 schreef op maandag 15 september 2025 @ 16:43:
Is er iemand die de marstek batterij gebruikt met een smartgridone van eniris?
Daarmee kan men de batterij koppelen aan Frank energie voor handel op de onbalans markt.

Echter vind ik het een moeilijk te vinden apparaat en vermoed dat het nogal prijzig is.
Wellicht is er een omweg te vinden, maar het eniris protocol zal alles behalve open zijn vermoed ik.

Waar heb je gezien dat dit device gekoppeld kan worden aan een Marstek Venus?
Handel op de onbalans markt wordt eigenlijk alleen door de energieleverancier gedaan met een vast geinstaleerde batterij. Bij een stekkerbatterij is er onvoldoende zekerheid dat het apparaat beschikbaar is op het moment dat de energieleverancier het wil inzetten.

Lijkt ook geen consumenten product (van de website):
We do not compete with installers or distributors by selling directly to end customers. Instead, we sell exclusively to installers or distributors, who are then free to offer the SmartgridOne to the end customer through their own business model.

[BertusB404]

Frank energie beweerd zelf dat de marstek middels de smartgridone gekoppeld kan worden. De website van eniris laat ook zien dat marstek batterijen er mee werken.

[Hometek]

BertusB404 schreef op dinsdag 16 september 2025 @ 00:05:
Frank energie beweerd zelf dat de marstek middels de smartgridone gekoppeld kan worden. De website van eniris laat ook zien dat marstek batterijen er mee werken.

Als ik het goed begrijp is het vooral een service die een bedrijf aan consumenten aan kan bieden door het plaatsen van de controler:
Build Your Own Pricing Model
We don’t impose a fixed retail price. Instead, you have the flexibility to choose between a one-time license fee or an annual license fee — both of which we invoice directly to you, not to the end customer. This allows you to develop your own pricing model for your clients, adding value through additional services.

[Hometek]

BertusB404 schreef op maandag 15 september 2025 @ 16:43:
Is er iemand die de marstek batterij gebruikt met een smartgridone van eniris?
Daarmee kan men de batterij koppelen aan Frank energie voor handel op de onbalans markt.

Echter vind ik het een moeilijk te vinden apparaat en vermoed dat het nogal prijzig is.
Wellicht is er een omweg te vinden, maar het eniris protocol zal alles behalve open zijn vermoed ik.

Ik vermoed dat je deze instructies al gezein had?
Als consument kun je niet zelf handelen op de onbalans markt, dat kunnen alleen energieleveranciers. Als consument kun je alleen je batterij beschikbaar stellen.

[iorses]

Hometek schreef op maandag 8 september 2025 @ 12:44:
De HA Solcast integratie (voorspelling PV opwek) heeft sinds de laatste update een 'Auto-dampen' feature.
Deze feature corrigeert automatisch structurele lokale afwijkingen, bv door schaduw, in de voorspelling. Volgens de beschrijving wordt data van de afgelopen 14 dagen gebruikt om correcties te bepalen.
Ik heb de functie gisteren geactiveerd, en zie vandaag idd een duidelijk betere voorspelling dan de afgelopen dagen. Als dit idd goed blijkt te werken maakt het Solcast een stuk betrouwbaarder.

Voorspelling en opwek gisteren (met handmatige correctie, in de zomer ingesteld)
[Afbeelding]

Voorspelling en opwek vandaag (met automatische correctie)
[Afbeelding]

Dit ga ik eens testen👍🏼

[Hometek]

iorses schreef op woensdag 17 september 2025 @ 16:02:
[...]
Dit ga ik eens testen👍🏼

Voor mij werkt de nieuwe functie best goed. Mijn panelen hebben in de namiddag veel schaduw van bomen, wat in deze maanden eerst erger wordt, en dan weer iets minder als het blad er af is. Ik verwacht dat deze functie dat redelijk kan corrigeren.

[antoinevromen]

Hallo medetweakers,

Naar aanleiding van mijn post op het marstek Venus E forum ben ik door @SatScan en @pascallj naar jullie forum hier verwezen.
Mocht er iemand (met kennis van powershell en windows-task-scheduler) interesse hebben om een (of meerdere) Marstek Venus E batterijen middels dedicated powershell-scripts aan te sturen via de local-api (dus zonder additionele hardware of software zoals home-assistant of homey) dan wil ik mijn code wel delen als soort van jump-start.

Bericht op het Marstek-forum (antoinevromen in "Hame / Marstek / Duravolt 5,12kWh plug en play thuisaccu"):
In mijn sturings-applicatie (gebaseerd op de local-api) die ik heb geschreven, wordt geautomatiseerd (via downloads) rekening wordt gehouden met de dynamische-prijzen, de hoeveelheid verwachte W/m2 zonne-energie in mijn woonplaats op de rest van de dag (Weerlive.nl) en de huidige soc / laad/-ontlaad waarden en de RTE die ook invloed heeft op de laad-prijs. Op basis van bovenstaande input kan ik de batterij sturen per kwartier tussen Auto en Manual-laden/ontladen of helemaal pauzeren omdat ik later op de dag zonnestroom wil laden en op de duurdere momenten mijn zonnestroom nog wil invoeren in het net. Uiteraard is dit script voor iedereen met een programmeer-achtergrond in Powershell naar eigen wensen uit te breiden. De powershell omgeving is ook standaard onderdeel van windows. Ik laat zelf periodiek (bijv elk kwartier of elk uur) het script draaien middels task-scheduler die standaard in windows aanwezig is.

[GoBieN-Be]

Ik ben wel benieuwd naar het aansturen van de local-api vanuit Powershell.
Begrijp ik uit je tekst dat jij niet probeert NOM te draaien?

[PNARI]

antoinevromen schreef op vrijdag 19 september 2025 @ 16:31:
Hallo medetweakers,

Naar aanleiding van mijn post op het marstek Venus E forum ben ik door @SatScan en @pascallj naar jullie forum hier verwezen.
Mocht er iemand (met kennis van powershell en windows-task-scheduler) interesse hebben om een (of meerdere) Marstek Venus E batterijen middels dedicated powershell-scripts aan te sturen via de local-api (dus zonder additionele hardware of software zoals home-assistant of homey) dan wil ik mijn code wel delen als soort van jump-start.

Bericht op het Marstek-forum (antoinevromen in "Hame / Marstek / Duravolt 5,12kWh plug en play thuisaccu"):
In mijn sturings-applicatie (gebaseerd op de local-api) die ik heb geschreven, wordt geautomatiseerd (via downloads) rekening wordt gehouden met de dynamische-prijzen, de hoeveelheid verwachte W/m2 zonne-energie in mijn woonplaats op de rest van de dag (Weerlive.nl) en de huidige soc / laad/-ontlaad waarden en de RTE die ook invloed heeft op de laad-prijs. Op basis van bovenstaande input kan ik de batterij sturen per kwartier tussen Auto en Manual-laden/ontladen of helemaal pauzeren omdat ik later op de dag zonnestroom wil laden en op de duurdere momenten mijn zonnestroom nog wil invoeren in het net. Uiteraard is dit script voor iedereen met een programmeer-achtergrond in Powershell naar eigen wensen uit te breiden. De powershell omgeving is ook standaard onderdeel van windows. Ik laat zelf periodiek (bijv elk kwartier of elk uur) het script draaien middels task-scheduler die standaard in windows aanwezig is.

Mooi initiatief maar ik heb begrepen dat api van Venus maar voor een beperkt aantal gebruikers beschikbaar is ?

[HiHaHors]

antoinevromen schreef op vrijdag 19 september 2025 @ 16:31:
Hallo medetweakers,

Naar aanleiding van mijn post op het marstek Venus E forum ben ik door @SatScan en @pascallj naar jullie forum hier verwezen.
Mocht er iemand (met kennis van powershell en windows-task-scheduler) interesse hebben om een (of meerdere) Marstek Venus E batterijen middels dedicated powershell-scripts aan te sturen via de local-api (dus zonder additionele hardware of software zoals home-assistant of homey) dan wil ik mijn code wel delen als soort van jump-start.

Bericht op het Marstek-forum (antoinevromen in "Hame / Marstek / Duravolt 5,12kWh plug en play thuisaccu"):
In mijn sturings-applicatie (gebaseerd op de local-api) die ik heb geschreven, wordt geautomatiseerd (via downloads) rekening wordt gehouden met de dynamische-prijzen, de hoeveelheid verwachte W/m2 zonne-energie in mijn woonplaats op de rest van de dag (Weerlive.nl) en de huidige soc / laad/-ontlaad waarden en de RTE die ook invloed heeft op de laad-prijs. Op basis van bovenstaande input kan ik de batterij sturen per kwartier tussen Auto en Manual-laden/ontladen of helemaal pauzeren omdat ik later op de dag zonnestroom wil laden en op de duurdere momenten mijn zonnestroom nog wil invoeren in het net. Uiteraard is dit script voor iedereen met een programmeer-achtergrond in Powershell naar eigen wensen uit te breiden. De powershell omgeving is ook standaard onderdeel van windows. Ik laat zelf periodiek (bijv elk kwartier of elk uur) het script draaien middels task-scheduler die standaard in windows aanwezig is.

Ik ben zeer geïnteresseerd in jouw scripts!

[AUijtdehaag]

PNARI schreef op zaterdag 20 september 2025 @ 06:46:
[...]

Mooi initiatief maar ik heb begrepen dat api van Venus maar voor een beperkt aantal gebruikers beschikbaar is ?

Kun je zelf aanzetten
https://rweijnen.github.io/marstek-venus-monitor/latest/

[antoinevromen]

GoBieN-Be schreef op zaterdag 20 september 2025 @ 00:30:
Ik ben wel benieuwd naar het aansturen van de local-api vanuit Powershell.
Begrijp ik uit je tekst dat jij niet probeert NOM te draaien?

Jawel ik draai voornamelijk NOM (dus dat is Modus Auto en staat in de app als zelfconsumptie),
maar er kunnen momenten zijn (bijv. 's winters als de batterij bijna nooit vol raakt waarop het script 1 x per week op het laagste tarief toch een keer tot 100% vol laadt t.b.v. behoud accu en soc-drift) of wanneer je bijv. dynamisch tarief hebt en je geraakt niet helemaal door de nacht met de batterij dat je dan de batterij op het laagste tarief gedurende de nacht zoveel bijlaadt dat je in de ochtend over het duurste tarief-moment heen geraakt.
Of bijv. in de winter als de batterij maar voor een deel is vol geraakt en de dure uren rond 19.00/20.00 moeten nog komen zoveel bijlaadt dat je over die dure uren heen geraakt.
Maar ik ben ook nog aan het denken aan het inbouwen van juist verkopen in de zomer op het duurste uur met zonnestroom die gratis in de middag is opgeslagen. Daarnaast ben ik ook nog aan het denken om bijv. in de zomer de batterij niet al van 7 tot 10 te laten volladen (maar die stroom liever naar het net te leveren) en in plaats daarvan op de negatieve uren of 0 uren in de middag hem vol te laden omdat hij toch altijd wel vol raakt op zo'n dag (ook op basis van de voorspellingen van zonne-Watt/m2 die ik download en interpreteer in het script).

[antoinevromen]

@GoBieN-Be @HiHaHors ,
Oke ik zal in de loop van de komende week het script en een beetje van handleiding waar het script de tarieven en zonne-wattage vandaan haalt hier posten. Als je handig bent in programmeren, dan kun je het daarna zelf aanpassen naar eigen sturings-wensen.
Misschien ook een idee om eens van gedachten te wisselen wat bijv. algemene use-cases zouden kunnen zijn om in te bouwen, zoals ik hier al heb beschreven in mijn eerdere post als antwoord op GoBienBe

[Hometek]

antoinevromen schreef op zaterdag 20 september 2025 @ 09:41:
[...]

Jawel ik draai voornamelijk NOM (dus dat is Modus Auto en staat in de app als zelfconsumptie),
maar er kunnen momenten zijn (bijv. 's winters als de batterij bijna nooit vol raakt waarop het script 1 x per week op het laagste tarief toch een keer tot 100% vol laadt t.b.v. behoud accu en soc-drift) of wanneer je bijv. dynamisch tarief hebt en je geraakt niet helemaal door de nacht met de batterij dat je dan de batterij op het laagste tarief gedurende de nacht zoveel bijlaadt dat je in de ochtend over het duurste tarief-moment heen geraakt.
Of bijv. in de winter als de batterij maar voor een deel is vol geraakt en de dure uren rond 19.00/20.00 moeten nog komen zoveel bijlaadt dat je over die dure uren heen geraakt.
Maar ik ben ook nog aan het denken aan het inbouwen van juist verkopen in de zomer op het duurste uur met zonnestroom die gratis in de middag is opgeslagen. Daarnaast ben ik ook nog aan het denken om bijv. in de zomer de batterij niet al van 7 tot 10 te laten volladen (maar die stroom liever naar het net te leveren) en in plaats daarvan op de negatieve uren of 0 uren in de middag hem vol te laden omdat hij toch altijd wel vol raakt op zo'n dag (ook op basis van de voorspellingen van zonne-Watt/m2 die ik download en interpreteer in het script).

Ik ben met iets soortgelijks bezig in Node-RED.
Op basis van gemiddeld verbruik en verwachte opwek voor komende 24 en 48 uur de minimale SOC berekenen en dan bij overschot op dure uren ontladen of bij tekort op goedkope uren bijladen tot aan de minimale SOC.



In dit voorbeeld was op dag 2 het verbruik hoger dan gemiddeld, dus de SOC bleef achter, en omdat ik krappe drempelwaarden had ingesteld werd er van het net opgeladen.
Op dag 3 waren de drempelwaarde ruimer ingesteld en werd er niet opgeladen.

Over een week of twee zal ik wat meer details delen.

[antoinevromen]

Hometek schreef op zaterdag 20 september 2025 @ 22:15:
[...]

Ik ben met iets soortgelijks bezig in Node-RED.
Op basis van gemiddeld verbruik en verwachte opwek voor komende 24 en 48 uur de minimale SOC berekenen en dan bij overschot op dure uren ontladen of bij tekort op goedkope uren bijladen tot aan de minimale SOC.

[Afbeelding]

In dit voorbeeld was op dag 2 het verbruik hoger dan gemiddeld, dus de SOC bleef achter, en omdat ik krappe drempelwaarden had ingesteld werd er van het net opgeladen.
Op dag 3 waren de drempelwaarde ruimer ingesteld en werd er niet opgeladen.

Over een week of twee zal ik wat meer details delen.

Hallo @Hometek ,
Exact. Mooi te lezen dat je ook in diezelfde sturings-richting aan het werken bent. Dat is ook de oplossingsrichting die ik aan het inbouwen ben. Op basis van de zon-voorspelling in Watt/m2 kan ik uitrekenen hoeveel PV-kWh ik nog verwacht op te wekken en dan kijk ik of ik vanaf het huidige uur x t/m maximale prijsuur met de huidige soc en verwachte bijlaadhoeveelheid uit kom rekening houdend met een geschat gemiddeld verbruik per uur. Als het met PV-opwek lukt om die drempel-soc te bereiken dan niet bijladen. Als er niet voldoende PV-opwek is, dan kijken of de huidige Net-prijs (verhoogd met RTE-verlies) opweegt tegen de gemiddelde prijs van de laatste uren vooraf en inclusief het maximale prijsuur waarvoor ik Net-stroom zou moeten bijladen. Ook hier is het nog even spelen met de parameters die bepalen hoeveel PV-kWh daadwerkelijk uit zonne Watt/m2 komt en hoeveel W/uur je verbruikt in de nacht en overdag om in te schatten hoeveel de huidige soc nog zal dalen ten gevolge van dat verbruik.

Ik houd daarbij overigens rekening met 2 max-prijsnivo's per dag ; 1 voor de middag (meestal rond 8 uur 's morgens) en 1 voor na de middag (meestal rond 20.00 's avonds); Zodat ik 2 momenten heb waarop ik de soc kan bijsturen door van het Net te laden met goedkope stroom. Maar zoals ik al schreef zijn er in de zomer wellicht nog andere punten van sturing (zoals bijv. niet laden in de ochtend, maar pas als de prijs minimaal/negatief is als de voorspelling toch voldoende PV-stroom aangeeft); Dan leveren die Net-teruggeleverde kWh's in de ochtend nog iets op en bespaar ik mij (een deel van) de negatieve prijs-uren.

[ Voor 14% gewijzigd door antoinevromen op 21-09-2025 08:56 ]

[Hometek]

antoinevromen schreef op zondag 21 september 2025 @ 08:52:
[...]
Hallo @Hometek ,
Exact. Mooi te lezen dat je ook in diezelfde sturings-richting aan het werken bent. Dat is ook de oplossingsrichting die ik aan het inbouwen ben. Op basis van de zon-voorspelling in Watt/m2 kan ik uitrekenen hoeveel PV-kWh ik nog verwacht op te wekken en dan kijk ik of ik vanaf het huidige uur x t/m maximale prijsuur met de huidige soc en verwachte bijlaadhoeveelheid uit kom rekening houdend met een geschat gemiddeld verbruik per uur. Als het met PV-opwek lukt om die drempel-soc te bereiken dan niet bijladen. Als er niet voldoende PV-opwek is, dan kijken of de huidige Net-prijs (verhoogd met RTE-verlies) opweegt tegen de gemiddelde prijs van de laatste uren vooraf en inclusief het maximale prijsuur waarvoor ik Net-stroom zou moeten bijladen. Ook hier is het nog even spelen met de parameters die bepalen hoeveel PV-kWh daadwerkelijk uit zonne Watt/m2 komt en hoeveel W/uur je verbruikt in de nacht en overdag om in te schatten hoeveel de huidige soc nog zal dalen ten gevolge van dat verbruik.

Ik houd daarbij overigens rekening met 2 max-prijsnivo's per dag ; 1 voor de middag (meestal rond 8 uur 's morgens) en 1 voor na de middag (meestal rond 20.00 's avonds); Zodat ik 2 momenten heb waarop ik de soc kan bijsturen door van het Net te laden met goedkope stroom. Maar zoals ik al schreef zijn er in de zomer wellicht nog andere punten van sturing (zoals bijv. niet laden in de ochtend, maar pas als de prijs minimaal/negatief is als de voorspelling toch voldoende PV-stroom aangeeft); Dan leveren die Net-teruggeleverde kWh's in de ochtend nog iets op en bespaar ik mij (een deel van) de negatieve prijs-uren.

@antoinevromen
Hetzelfde basisprincipe, maar verschillende strategieën. Iedereen heeft zo zijn eigen voorkeuren
Mijn strategie is om de baterij tegen het einde van de middag altijd op het minimum SOC niveau te hebben. Opladen bij laagste prijs en ontladen bij hoogste prijs gebeurt alleen als er op dat moment toevallig een tekort dan wel een overschot is. Hierdoor zou het systeem redelijk ongevoelig moeten zijn voor het verschuiven van de goedkope en dure momenten gedurende het jaar. Ik kijk niet naar de prijzen zelf, alleen of het een maximum of minimum is.
Voor het ontladen kijk ik naar de minimum SOC voor vandaag, voor het opladen kijk ik ook naar de minimum SOC voor de volgende dag om te voorkomen dat ik vandaag stroom inkoop terwijl er morgen voldoende zon is.
Deze strategie is natuurlijk alleen zinvol bij een installatie met een relatief grote batterij die meestal niet leeg raakt gedurende de nacht.

Voor de PV opwek gebruik ik Solcast, deze integratie levert direct de verwachte kWh voor een specifieke installatie, en er zit sinds kort een handige auto-correctie functie in (zie deze post)

[antoinevromen]

@Hometek
Zeker. Ofschoon het misschien niet allemaal qua strategie precies te snappen is en ik de consequenties van jouw keuzes niet helemaal kan inschatten, vind ik het vooral goed dat we ieder voor zich de batterij zo kunnen sturen middels wat eenvoudige scripts als wij dat wensen. En er zelfs functionaliteit bij kunnen maken die er op geen andere wijze in het product zit (ik noem maar eens bijv. 1 x per week tot 100% laden, zodat de batterij in de winter niet steeds leeg staat).
Zo stuurde ik ook eerst op minimum en maximum prijs, maar kwam erachter dat ik ook de RTE (verlies t.g.v. laden/ontladen) in de berekening wilde meenemen omdat ik merkte dat soms een verschil van bijv. x-cent zich door de RTE uiteindelijk vertaalde in het feit dat de minimum-stroomprijs (geladen) toch nog hoger was dan de maximum prijs.
Ik ga nu wat scripts van mij hier posten, zodat eenieder die er interesse in heeft zelf eraan kan sleutelen.
Ik denk dat het nog lastig wordt om een grootste gemene deler te vinden voor wat nu de "juiste" strategie is (als die er al is).

Gr. Antoine

[antoinevromen]

antoinevromen schreef op zaterdag 20 september 2025 @ 09:46:
@GoBieN-Be @HiHaHors ,
Oke ik zal in de loop van de komende week het script en een beetje van handleiding waar het script de tarieven en zonne-wattage vandaan haalt hier posten. Als je handig bent in programmeren, dan kun je het daarna zelf aanpassen naar eigen sturings-wensen.
Misschien ook een idee om eens van gedachten te wisselen wat bijv. algemene use-cases zouden kunnen zijn om in te bouwen, zoals ik hier al heb beschreven in mijn eerdere post als antwoord op GoBienBe

DEEL1
Beste Tweakers (o.a. @GoBieN-Be @HiHaHors),
Zoals eerder geschreven hier alvast wat scripts om de batterij middels local-api te sturen.
Veel hiervan was niet mogelijk geweest zonder de hulp van @bommel , die mij ook een stukje voorbeeldcode heeft gegeven destijds.
Wat weetjes vooraf:
-1 de scripts zijn als windows cmd-bestandjes en windows powershell-scripts gemaakt. Pas ze aan naar hartelust want ik ben de software zelf ook nog aan het uitbreiden, maar heb niet de intentie om daar een soort turn-key-project van te maken.
-2 ik ben nooit ver weg mochten mensen vragen hebben, vraag gerust
-3 de windows cmd-bestandjes laat ik middels windows task-scheduler periodiek (elk kwartier of elk uur) draaien, maar in principe gaat het er maar om dat de cmd-bestandjes gestart worden, dus hoe je dat zelf wilt regelen is up to you.
-4 de cmd-bestandjes starten (al dan niet met meegave van parameters) de powershell-scripts, welke de eigenlijke logica bevatten
-5 bij sommige scriptjes met calls naar externe https-providers is een key t.b.v. de externe api vereist. Ik zal hier beschrijven waar je op eenvoudige/gratis wijze zo'n key voor jezelf kunt krijgen. (mijn eigen key is om die reden niet getoond in de scripts om te voorkomen dat we straks allemaal geen toegang meer krijgen vanwege een te hoog aantal api-calls op die externe site onder 1 account).
-6 het spreekt voor zich dat je local-api op de Marstek Vensus E geactiveerd moet hebben. Dat kan via het officiele kanaal (een feedback bericht in de app, waarbij je verzoekt jouw batterij local-api te enabelen; Het kan ook met behulp van de tool van bommel @bommel (https://rweijnen.github.io/marstek-venus-monitor/latest/) onder system in dat tool tref je activeren local-api op poort 30000 aan (meer hierover is ook te vinden op het moeder-forum (Hame / Marstek / Duravolt 5,12kWh plug en play thuisaccu) )
-7 Ik heb momenteel geen idee hoe ik dit gestructureerd aan jullie moet overbrengen omdat ik niet schijn te vinden hoe ik attachments kan meesturen met een forum-post; Vandaar zal ik de script-code hier in een post stoppen. (zoveel is het nu ook weer niet).
-8 om powershell-scripts te kunnen draaien vanuit een windows cmd-box doe je het volgende:
a) start een windows command processor als admin
b) start nu op de prompt powershell.exe
c) start nu op de prompt Get-ExecutionPolicy -List
dat geeft een lijst van rechten weer waarbij alles undefined zal zijn als default
d) start nu op de prompt set-executionpolicy remotesigned
dit geeft de juiste rechten op localmachine nivo
e) door nogmaals op de prompt Get-ExecutionPolicy -List te starten kun je zien dat die rechten effectief zijn geworden. Vanaf nu kun je op die machine vanuit locale-cmd-bestandjes powershell-scripts draaien

[ Voor 10% gewijzigd door antoinevromen op 21-09-2025 17:34 ]

[antoinevromen]

DEEL2 (scriptje avzetMODEaan.cmd)
=====

code:

c:
cd \netcat-setup
echo inputmode kan zijn: AI, Auto, Passive, ManualLaden, ManualOntladen
set /p inputmode=
powershell.exe -file c:\netcat-setup\avzetMODEaan.ps1 -DeviceIP "192.168.178.234" -Mode %inputmode%
pause

====
powershell-scriptje avzetMODEaan.ps1
=====

code:

# example usage:
# .\MT-LocalApi-Example -DeviceIP 192.168.20.82 -RemotePort 30000 -LocalPort 30000 -PerCallTimeoutMs 2000 -MaxRetries 3
param(
  [Parameter(Mandatory=$true)][string]$DeviceIP = "192.168.178.xxx",
  [Parameter(Mandatory=$true)][string]$Mode = "xx",
  [int]$RemotePort = 30000,
  [int]$LocalPort  = $RemotePort,
  [int]$PerCallTimeoutMs = 5000, 
  [int]$MaxRetries = 3,
  [int]$InterCallDelayMs = 1000 
)

Add-Type -AssemblyName System.Net 

# Create socket, enable reuse, bind to LocalPort (so source port is fixed)
$udp = New-Object System.Net.Sockets.UdpClient
$udp.Client.SetSocketOption([System.Net.Sockets.SocketOptionLevel]::Socket, [System.Net.Sockets.SocketOptionName]::ReuseAddress, $true)
$udp.Client.ExclusiveAddressUse = $false
$udp.Client.Bind([System.Net.IPEndPoint]::new([System.Net.IPAddress]::Any, $LocalPort))
$udp.Client.ReceiveTimeout = 1000 ## 250

function Send-And-Wait([string]$Method, [hashtable]$Params) {
  for($try=1; $try -le $MaxRetries; $try++){
    $rpcId = Get-Random -Minimum 1000 -Maximum 65000       # JSON-RPC id (unique per try)
    $req = @{ id=$rpcId; method=$Method; params=$Params } | ConvertTo-Json -Compress -Depth 6
    Write-Host ($req)
    $bytes = [Text.Encoding]::UTF8.GetBytes($req)
    [void]$udp.Send($bytes, $bytes.Length, $DeviceIP, $RemotePort)
    Write-Host ("→ [{0}/{1}] {2} {3}" -f $try,$MaxRetries,$Method,($Params | ConvertTo-Json -Compress))

    $deadline = [datetime]::UtcNow.AddMilliseconds($PerCallTimeoutMs * [math]::Pow(1.35, $try-1))
    $remote = [System.Net.IPEndPoint]::new([System.Net.IPAddress]::Any,0)

    while([datetime]::UtcNow -lt $deadline){
      try {
        $resp = $udp.Receive([ref]$remote)
        $txt  = [Text.Encoding]::UTF8.GetString($resp)
        $obj  = $txt | ConvertFrom-Json -ErrorAction SilentlyContinue
        if($obj -and $obj.id -eq $rpcId){
          Write-Host ("av1<= [{0}] {1}`n{2}`n" -f $rpcId,$Method,$txt)
          Start-Sleep -Milliseconds $InterCallDelayMs
          return
        }
        # ignore late/unrelated frames and keep waiting
      } catch {
        # slice timeout; keep looping until overall deadline
      }
    }
    Start-Sleep -Milliseconds (100 + (Get-Random -Minimum 0 -Maximum 80))
  }
  Write-Host ("<= [--] {0}  -- timeout after {1} ms x{2}`n" -f $Method,$PerCallTimeoutMs,$MaxRetries)
  Start-Sleep -Milliseconds $InterCallDelayMs
}

# Warm-up (often helps)
Send-And-Wait "Marstek.GetDevice" @{ ble_mac = "0" }
Send-And-Wait "ES.GetMode" @{id=0} 
if ($Mode -eq "AI") {
   ##Write-Host ("Mode={0}" -f $Mode)
   Send-And-Wait "ES.SetMode" @{id=1; config = @{id=1; mode= "AI"; ai_cfg= @{enable=1}}}
}
if ($Mode -eq "Auto") {
   ##Write-Host ("Mode={0}" -f $Mode)
   Send-And-Wait "ES.SetMode" @{id=1; config = @{id=1; mode= "Auto"; auto_cfg= @{enable=1}}}
}
if ($Mode -eq "Passive") {
   ##Write-Host ("Mode={0}" -f $Mode)
   Send-And-Wait "ES.SetMode" @{id=1; config = @{id=1; mode= "Passive"; passive_cfg= @{power=100;cd_time=3}}}
}
if ($Mode -eq "ManualLaden") {
   ##Write-Host ("Mode={0}" -f $Mode)
   ##N.B. laden van de accu moet met een negatief getal bij power
   Send-And-Wait "ES.SetMode" @{id=1; config = @{id=1; mode= "Manual"; manual_cfg= @{time_num=1;start_time="04:00";end_time="05:00";week_set=127;power=-2500;enable=1}}}
}
if ($Mode -eq "ManualOntladen") {
   ##Write-Host ("Mode={0}" -f $Mode)
   ##N.B. ontladen van de accu moet met een positief getal bij power
   Send-And-Wait "ES.SetMode" @{id=1; config = @{id=1; mode= "Manual"; manual_cfg= @{time_num=1;start_time="16:00";end_time="19:00";week_set=127;power=210;enable=1}}}
}

# Optional: drain late packets
$remote = [System.Net.IPEndPoint]::new([System.Net.IPAddress]::Any,0)
while([datetime]::UtcNow -lt $until){
  try {
    $txt = [Text.Encoding]::UTF8.GetString($udp.Receive([ref]$remote))
    Write-Host ("<= [late] {0}:{1}`n{2}`n" -f $remote.Address,$remote.Port,$txt)
  } catch {}
}
$udp.Close()

==============

[antoinevromen]

DEEL3:
Het scriptje avzetMODEaan.ps1 bevat code waarin o.a. de huidige soc, de huidige ongrid-power, de huidige modus worden weergegeven. Daarnaast zitten in het scriptje alle voorbeelden om de mode van de batterij te switchen naar 1 van de volgende: AI, Auto, Manual-laden, Manual-ontladen en Passive

Ik heb zelf momenteel hardcoded het cmd-scriptje en het ps1-scriptje in de direcotry c:\netcat-setup staan, maar binnen in het script wordt van .\ uitgegaan, dus je kunt e.e.a. ook naar een andere directory verplaatsen.

[ Voor 26% gewijzigd door antoinevromen op 21-09-2025 17:00 ]

[antoinevromen]

DEEL4: het bestandje avhaalTARIEVEN.cmd
Onderstaande scriptje haalt op de site jeroen.nl de dynamische tarieven van vandaag op in de vorm van een json-file (dus als je het morgen draait om zeg maar 00:01 uur, dan krijg je uiteraard de tarieven van die dag )
Omdat de inhoud van deze tarieven niet wijzigt sla ik die json-informatie op in een .txt-bestandje (dagtarief.txt), van waaruit ik het later kan inlezen en kan bevragen m.b.t. prijzen en uren waarop die prijzen gelden.
Je ziet dat er in het web-request een key= moet worden meegegeven.
Die key kun je gratis krijgen als je een account aanmaakt bij jeroen.nl . Vervolgens kun je naar de volgende pagina gaan: https://jeroen.nl/account/feeds waar je jouw persoonlijk api-key kunt vinden.
==============

code:

c:
cd \netcat-setup
powershell.exe -file .\avhaalTARIEVEN.ps1

=================
het bestandje avhaalTARIEVEN.ps1
==================

code:

Add-Type -AssemblyName System.Net 
$TarievenVandaag = Invoke-WebRequest 'https://jeroen.nl/api/dynamische-energieprijzen/v2/?period=vandaag&type=json&key=op deze plek je eigen api-key van jeroen.nl'
$TarievenVandaag = $TarievenVandaag -replace ':"-0,', ':"-0.'
$TarievenVandaag = $TarievenVandaag -replace ':"0,', ':"0.'
[System.IO.File]::WriteAllText(".\dagtarief.txt", $TarievenVandaag)

[antoinevromen]

DEEL 5:
Onderstaande scriptje haalt op de site weerlive.nl (van het KNMI) de voorspelde zonne-wattages weer per uur van de dag op een locatie en slaat dit op in de vorm van een json-file (dus als je het morgen draait om zeg maar 00:01 uur, dan krijg je uiteraard de zonnewaarden van die dag )
Omdat de inhoud van zonnewaarden elk uur wijzigt (en betrouwbaarder wordt) sla ik die json-informatie elk uur op in een .txt-bestandje (zonvandaag.txt), van waaruit ik het later kan inlezen en kan bevragen m.b.t. wattages per uur per m2 op die locatie.
Je ziet dat er in het web-request een key= moet worden meegegeven.
Die api-key kun je gratis krijgen via https://weerlive.nl/delen.php en in het script invullen op de plaats achter key=
=====
Het bestandje avhaalZONNEKRACHT.cmd
=====

code:

c:
cd \netcat-setup
powershell.exe -file .\avhaalZONNEKRACHT.ps1

=====
Het bestandje avhaalZONNEKRACHT.ps1
=====

code:

Add-Type -AssemblyName System.Net # ,System.Net.Sockets
$ZonVandaag = Invoke-WebRequest 'https://weerlive.nl/api/weerlive_api_v2.php?key=jouw-persoolijnk-key&locatie=Voerendaal'
[System.IO.File]::WriteAllText(".\zonvandaag.txt", $ZonVandaag)

====

[antoinevromen]

DEEL6:
Onderstaand het script om periodiek (bijv. elk kwartier) te draaien dat op basis van zonnewattage/m2 , dynamische tarieven voor een dag, de huidige informatie uit je batterij en enkele andere logica bepaalt of
de batterij middels Net-stroom geladen moet worden om zodoende geld te verdienen (bijv. door te handelen, of door ervoor te zorgen dat je de dure uren via de batterij kunt doorkomen met goedkoop geladen net-stroom etc.
=====
Het scriptje avzetMODEdynamisch.cmd
=====

code:

c:
cd \netcat-setup
powershell.exe -file .\avzetMODEdynamisch.ps1

======
Het scriptje avzetMODEdynamisch.ps1
=====

code:

# example usage:
# .\MT-LocalApi-Example -DeviceIP 192.168.20.82 -RemotePort 30000 -LocalPort 30000 -PerCallTimeoutMs 2000 -MaxRetries 3
param(
##constanten
  [string]$DeviceIP = "192.168.178.234",
  [string]$tijdstempel_str = (Get-Date).ToString("yyyy-MM-dd HH:mm:ss"),
  [string]$bijladen_gedurende_huidig_contract = "N",
  [int]$RemotePort = 30000,
  [int]$LocalPort  = $RemotePort,
  [int]$PerCallTimeoutMs = 5000, 
  [int]$MaxRetries = 3,
  [int]$InterCallDelayMs = 1000, 
  [int]$BijlaadRekenhoeveelheidPerUur_VM_int = 250,
  [int]$BijlaadRekenhoeveelheidPerUur_NM_int = 500,
  [int]$capaciteit_batterij_int = 5120,
  [int]$max_laadcapaciteit_int_int = 2500,
  [double]$ACDCAComzettnigverlies_double = 0.75,
  [double]$opslag_energieleverancier_double = 0.0233,
  [double]$opslag_energiebelasting_double = 0.10154,
  [double]$btw_perc_double = 0.21,
  [double]$opslagbedragNetLaden_double = 0.03,
  [double]$opp_pv_hoogdak_double = (9 + 6) * 1.5 * 1.05 ,
  [double]$opp_pv_laagdak_double = (    9) * 1.5 * 1.05 ,
  [double]$opp_pv_tuinhuis_double = 4 * 1.7 * 1.05 ,

  ## op 19-sep-2025 in totaal opwek alle panelen 32kWh   45 m2 opp.bij voorspelde 4270 W/m2 = factor 0,166
  ## op 20-sep-2025 in totaal opwek alle panelen 14,3kWh 45 m2 opp bij voorspelde 3170 W/m2 = factor 0,10
  ## op 21-sep-2025 in totaal opwek alle panelen 10,9kWh 45 m2 opp bij voorspelde 1264 W/m2 = factor 0,19
  [double]$ervaringscijfer_kWh_per_zonwaarde = 0.14, ## 32000/(($opp_pv_hoogdak_double + $opp_pv_laagdak_double + $opp_pv_tuinhuis_double)*4270)
##=========================================================================
  [string]$modenieuw_str = "x",
  [string]$modenu_str = "x",
  [string]$modegezet_str = "N",
  [string]$mode_Go_Passive_str = "N",
  [int]$bat_soc_int = 999,
  [int]$ongrid_power_int = 999,
  [int]$huidigemaand_int = 999,
  [int]$huidiguur_int = 999,
  [int]$maxzoekuur_int = -10,
  [int]$minzoekuur_int = 9999,
  [int]$minuur_int = 888,
  [int]$minnegatiefuur_int = 88,
  [int]$maxuur_int = -10,
  [int]$zoekuur_int = 9999,
  [int]$socwaarde_stopladen_int = 9999,
  [int]$zon_som_waarde_van_nu_tm_einde_dag_int = 9999,
  [int]$zon_som_waarde_van_nu_tot_nabijste_maxuur_int = 9999,
  [int]$uren_langer_maxuur_int = 0,
  [int]$te_verwachten_PV_opbrengst_vanNu_totMaxuur_int = 9999,
  [int]$benodigde_Energie_vanNu_tot_en_met_Maxuur_int = 9999,
  [int]$BijlaadHoeveelheidPerUur_int = 9999,
  [int]$Benodigde_Soc_voor_3_uur_int = 9999,
  [double]$mintarief_double = 999,
  [double]$minnegatieftarief_double = 999,
  [double]$maxtarief_double = -10,
  [double]$tariefuur_double = 99,
  [double]$TariefBruto_double = 999, 
  [double]$brutotariefmaxuur_double = 999,
  [double]$brutotariefhuidiguur_omgerekend_verlies_double = 999,
  [double]$brutotariefmaxuur_plus_1_double = 999,
  [double]$brutotariefmaxuur_plus_2_double = 999,
  [double]$gemiddeld_brutotarief_additionele_bijlaaduren_double = 999,
  [double]$nettohuidigtarief_double = 999
)

Add-Type -AssemblyName System.Net # ,System.Net.Sockets

# Create socket, enable reuse, bind to LocalPort (so source port is fixed)
$udp = New-Object System.Net.Sockets.UdpClient
$udp.Client.SetSocketOption([System.Net.Sockets.SocketOptionLevel]::Socket, [System.Net.Sockets.SocketOptionName]::ReuseAddress, $true)
$udp.Client.ExclusiveAddressUse = $false
$udp.Client.Bind([System.Net.IPEndPoint]::new([System.Net.IPAddress]::Any, $LocalPort))
$udp.Client.ReceiveTimeout = 1000 
##===============================================================================================
function Bepaal_ZonWattage_van_tm_Uur ([int]$zon_vanaf_uur_int, [int]$zon_tm_uur_int) {
$ZonVandaag = [IO.File]::ReadAllText(".\zonvandaag.txt")
$ZonVandaag_obj = $ZonVandaag | ConvertFrom-Json 
[int]$som_zon_waarden_int = 0
foreach ($Zon_obj in $ZonVandaag_obj) {
  foreach ($Zon_uur_verw_obj in $Zon_obj[0].uur_verw) {
      $dag = [datetime](Get-Date $Zon_uur_verw_obj[0].uur -f "yyyy-MM-dd HH:mm:ss")
      $uur_int = [int]$dag.hour
      if ($uur_int -ge $zon_vanaf_uur_int -and $uur_int -le $zon_tm_uur_int) {
         $som_zon_waarden_int = $som_zon_waarden_int + $Zon_uur_verw_obj[0].gr
      }
  }
}
Return [double]$som_zon_waarden_int
}
##===============================================================================================
function Bepaal_Tarief_Op_Uur ([int]$vraaguur) {
$TarievenVandaag = [IO.File]::ReadAllText(".\dagtarief.txt")
$TarievenVandaag_obj = $TarievenVandaag | ConvertFrom-Json 

foreach ($Tarief_obj in $TarievenVandaag_obj) {
    $dag = [datetime](Get-Date $Tarief_obj[0].datum_nl -f "yyyy-MM-dd HH:mm:ss")
    if (($vraaguur -eq $dag.Hour)) {
          Return [double]$Tarief_obj[0].prijs_excl_belastingen
    }
}
Return [double]99999
}
##===============================================================================================
function Bepaal_Gem_BrutoTarief_Van_Tm_Uur ([int]$vraaguur_van, [int]$vraaguur_tm) {
$TarievenVandaag = [IO.File]::ReadAllText(".\dagtarief.txt")
$TarievenVandaag_obj = $TarievenVandaag | ConvertFrom-Json 
[double]$som_bedrag_double = 0
[int]$aantal_bedrag_int = 0
$TariefBruto_double = 0
foreach ($Tarief_obj in $TarievenVandaag_obj) {
    $dag = [datetime](Get-Date $Tarief_obj[0].datum_nl -f "yyyy-MM-dd HH:mm:ss")
    if (($dag.Hour -ge $vraaguur_van) -and ($dag.Hour -le $vraaguur_tm)) {
          $TariefBruto_double = [double]($Tarief_obj[0].prijs_excl_belastingen)
          $TariefBruto_double = [double]($TariefBruto_double + $opslag_energieleverancier_double + $opslag_energiebelasting_double)
          $TariefBruto_double = [double]($TariefBruto_double * [double](1 + $btw_perc_double))
          $som_bedrag_double = [double]($som_bedrag_double + $TariefBruto_double)
          $aantal_bedrag_int = $aantal_bedrag_int + 1
    }
}
$TariefBruto_double = $som_bedrag_double / $aantal_bedrag_int
Return $TariefBruto_double
}
##===============================================================================================
function Send-And-Wait([string]$Method, [hashtable]$Params) {
    [string]$modenu = "dummywaarde-modenu"
    [string]$bat_soc_str = "dummywaarde-soc"
    [string]$ongrid_power_str = "dummywaarde-power"
  for($try=1; $try -le $MaxRetries; $try++){
    $rpcId = Get-Random -Minimum 1000 -Maximum 65000       # JSON-RPC id (unique per try)
    $req = @{ id=$rpcId; method=$Method; params=$Params } | ConvertTo-Json -Compress -Depth 6
    $bytes = [Text.Encoding]::UTF8.GetBytes($req)
    [void]$udp.Send($bytes, $bytes.Length, $DeviceIP, $RemotePort)

    $deadline = [datetime]::UtcNow.AddMilliseconds($PerCallTimeoutMs * [math]::Pow(1.35, $try-1))
    $remote = [System.Net.IPEndPoint]::new([System.Net.IPAddress]::Any,0)

    while([datetime]::UtcNow -lt $deadline){
      try {
        $resp = $udp.Receive([ref]$remote)
        $txt  = [Text.Encoding]::UTF8.GetString($resp)
        $obj  = $txt | ConvertFrom-Json -ErrorAction SilentlyContinue
        
        if($obj -and $obj.id -eq $rpcId){
              if ($Method -eq "ES.GetMode") {
                  $modenu = $obj.result.mode
                  $bat_soc_str = $obj.result.bat_soc
                  $ongrid_power_str = $obj.result.ongrid_power
              }
          Start-Sleep -Milliseconds $InterCallDelayMs
          return $Method, $modenu, $bat_soc_str, $ongrid_power_str
        }
        # ignore late/unrelated frames and keep waiting
      } catch {
        # slice timeout; keep looping until overall deadline
      }
    }
    Start-Sleep -Milliseconds (100 + (Get-Random -Minimum 0 -Maximum 80))
  }
  Write-Host ("<= [--] {0}  -- timeout after {1} ms x{2}`n" -f $Method,$PerCallTimeoutMs,$MaxRetries)
  Write-Output ("<= [--] $Method --timeout after $PerCallTimeoutMs ms x $MaxRetries retries") >> .\avzetMODEdynamischOutput.txt 
  Start-Sleep -Milliseconds $InterCallDelayMs
}
##===============================================================================================
##HOOFDPROGRAMMA
## Globale logica flow:
## -1- warm batterij api op door een dummy call (getdevice) te doen
## -2- bepaal huidige mode, huidige soc en huidige power
## -3- afhankelijk van of het huidige uur voormiddag of namiddag is bepaal in die 12 uur het moment van het vroegste uur met het hoogste tarief in die 12 uur
##     beginnend vanaf het nu t/m 11 resp. nu t/m 23
## -4- afhankelijk van of het huidige uur voormiddag of namiddag is bepaal in die 12 uur het moment van het laatste uur met het laagste tarief in die 12 uur 
##     beginnend vanaf nu t/m 11 resp. nu t/m 23 tot maximaal het uur waarin het maximum tarief wordt bereikt in dat 12 uurs-bestek
## -5- bepaal het laagste tariefuur van de gehele dag (t.b.v. eventueel latere sturing op negatieve tarieven
## -6- bepaal of het financieel aantrekkelijk is om de batterij-Soc hoger te laden zodat hij 1 of 2 uur langer dan het max-uur nog stroom heeft.
## -7- bepalen te verwachten PV-opbrengst op basis zonne-wattage de komende uren en het benodigde wattage om 
##     vanaf nu tot en met het max-uur te geraken(eventueel verlengt met 1 of 2 extra uren als dat financieel aantrekkelijk is)
## -6- bepaal tot welke soc waarde minimaal geladen moet worden wanneer er besloten is in dit programma dat de batterij geladen wordt
##     namiddags wordt dit 98%, zodat je zo ver mogelijk de nacht in kunt komen; 
##     voormiddags wordt dit % berekend zodanig dat de batterij op basis van $BijlaadRekenhoeveelheidPerUur Watt leveren tot 2 uur na het voormiddag-maximumtarief nog kan ontladen
## -7- afhankelijk van voormiddag of namiddag inschatten wat de soc-waarde zou moeten zijn om over het dichts-bijzijnde maximum-tarief heen te geraken vanaf uur nu rekening
##     rekening houdend met het geschatte uurverbruik tot max-uur (of maxuur + 1 of 2 uur)
## -8- wanneer er op basis van de huidige soc en te verwachten PV-opbrengst geen energietekort te verwachten is tot max-uur dan socwaarde-laden-int laag zetten zodat er niet wordt geladen
## -9- wanneer er energietekort is om over het max-uur heen te geraken nog bepalen of het huidig tarief (rekening houdend met RTE-verlies) financieel aantrekkelijk is om bij te laden
##     waarbij het omgerekende huidige tarief wordt vergeleken met het gemiddelde-bruto-tarief van max-uur en de uren vooraf aan maxuur die qua soc aangevuld moeten worden.
##-10- bepaal of er geladen moet worden; 
##     a) Als op het huidige uur de gewenste soc lager is dan de huidige soc, dan maximaal bijladen gedurende dit kwartier totdat
##        de stop-laad-waarde waarop hij weer naar Auto gaat wordt bereikt (tarief moet wel lonen t.o.v. omzetverlies plus een opslagbedrag)
##     b) Als soc >= $socwaarde_stopladen_int en modus is niet Auto dan op Auto zetten; anders blijven doorladen en de modus niet veranderen.
##     c) 1x per week op zondagnamiddag gedurende de wintermaanden (okt t/m feb) op goedkoopste uur tot 100% laden (als hij niet al 100% is)
##     d) in de zomer als veel zon verwacht (misschien zelfs negatieve prijzen) dan tot dat (lage/negatieve) moment ontladen en op dat lage/negatieve uur vol laden
##     e) in de zomer als veel zon is geladen met zonnestroom (misschien zelfs negatieve prijzen) dan bij erg hoge prijzen juist verkopen op die max-uren 
##        (kan alleen bij saldering omdat je na einde salderingsregeling de belastingen niet meer terug krijgt en dan die wel zou moeten betalen later op de dag als je weer stroom nodig hebt)
##     f) in de ochtend wanneer het maxuur van die 12 uur nog moet komen kijken of je voldoende soc hebt om 1 uur over dat maxuur te geraken. Als het min-uur nog moet komen en dat ook financieel niet
##        rendabel is kun je de batterij een tijd in passive zetten, zodat je in de ochtend toch nog genoeg over hebt voor het maxuur en het daarop volgende uur.
##
# Warm-up (often helps)
$resultaat = Send-And-Wait "Marstek.GetDevice" @{ ble_mac = "0" }

# Ophalen mode, soc en huidige power
$resultaat = Send-And-Wait "ES.GetMode" @{id=0} 

if ($resultaat[0] -eq "ES.GetMode") {
   $modenu_str = $resultaat[1]
   $bat_soc_int = [int]$resultaat[2]
   $ongrid_power_int = [int]$resultaat[3]
}

$huidigemaand_int = (Get-Date).Month
$huidiguur_int = (Get-Date).Hour
if ($huidiguur_int -gt 11) {
   $maxzoekuur_int = 23
   $minzoekuur_int = 12
   $BijlaadHoeveelheidPerUur_int = $BijlaadRekenhoeveelheidPerUur_NM_int
}else{
   $maxzoekuur_int = 11
   $minzoekuur_int = 0
   $BijlaadHoeveelheidPerUur_int = $BijlaadRekenhoeveelheidPerUur_VM_int
}

$TarievenVandaag = [IO.File]::ReadAllText(".\dagtarief.txt")
$TarievenVandaag_obj = $TarievenVandaag | ConvertFrom-Json ## -ErrorAction SilentlyContinue

## bepaal het vroegste max-tarief en bijbehorende max-uur (tussen 0-11 uur resp. 12-23 uur)
foreach ($Tarief_obj in $TarievenVandaag_obj) {
    $dag = [datetime](Get-Date $Tarief_obj[0].datum_nl -f "yyyy-MM-dd HH:mm:ss")
    if (($dag.Hour -le $maxzoekuur_int) -and ($dag.Hour -ge $minzoekuur_int)) {
       if ([double]$Tarief_obj[0].prijs_excl_belastingen -gt $maxtarief_double) {
          $maxtarief_double = [double]$Tarief_obj[0].prijs_excl_belastingen
          $maxuur_int = $dag.Hour
       }
    }
}
## bepaal het laatste min-tarief en bijbehorende min-uur (tussen Nu-11 uur resp. Nu-23 uur en max-uur binnen dit nu-to-12 uurs-bestek)
$maxzoekuur_int = $maxuur_int
foreach ($Tarief_obj in $TarievenVandaag_obj) {
    $dag = [datetime](Get-Date $Tarief_obj[0].datum_nl -f "yyyy-MM-dd HH:mm:ss")
    if (($dag.Hour -le $maxzoekuur_int) -and ($dag.Hour -ge $huidiguur_int)) {
       if ([double]$Tarief_obj[0].prijs_excl_belastingen -le $mintarief_double) {
          $mintarief_double = [double]$Tarief_obj[0].prijs_excl_belastingen
          $minuur_int = $dag.Hour
       }
    }
}
##Als het uur dat ligt vooraf aan het laatste minimum-tarief, dan kan het minimum-uur op dat voorliggende uur worden gezet, waardoor en meer tijd is om de batterij vol te krijgen
##mocht dat nodig zijn (omdat de soc onder de 50 ligt).
if ($minuur_int -ne 0 -and $minuur_int -ne 12 ) {
   $tariefuur_double = Bepaal_Tarief_Op_Uur ($minuur_int - 1)
   if (($tariefuur_double -eq $mintarief_double) -and ($bat_soc_int -lt 50)) {
      $minuur_int = $minuur_int - 1
   }
}
#zoek het laatste meest negatieve uur vanaf uur 0 tot einde dag
$maxzoekuur_int = 23
$minzoekuur_int = 0
foreach ($Tarief_obj in $TarievenVandaag_obj) {
    $dag = [datetime](Get-Date $Tarief_obj[0].datum_nl -f "yyyy-MM-dd HH:mm:ss")
    if (($dag.Hour -le $maxzoekuur_int) -and ($dag.Hour -ge $minzoekuur_int)) {
       if ([double]$Tarief_obj[0].prijs_excl_belastingen -le $minnegatieftarief_double -and [double]$Tarief_obj[0].prijs_excl_belastingen -lt 0) {
          $minnegatieftarief_double = [double]$Tarief_obj[0].prijs_excl_belastingen
          $minnegatiefuur_int = $dag.Hour
       }
    }
}
##bepaal of het financieel aantrekkelijk is om de batterij-Soc hoger te laden zodat hij 1 of 2 uur langer dan het max-uur nog stroom heeft.
$brutotariefmaxuur_double = Bepaal_Gem_BrutoTarief_Van_Tm_Uur $maxuur_int $maxuur_int
$brutotariefhuidiguur_omgerekend_verlies_double = Bepaal_Gem_BrutoTarief_Van_Tm_Uur $huidiguur_int $huidiguur_int
$brutotariefhuidiguur_omgerekend_verlies_double = ($brutotariefhuidiguur_omgerekend_verlies_double / $ACDCAComzettnigverlies_double) + $opslagbedragNetLaden_double
$nettohuidigtarief_double = Bepaal_Tarief_Op_Uur($huidiguur_int)
if ($maxuur_int -ne 11 -and $maxuur_int -ne 23) {
   $brutotariefmaxuur_plus_1_double = Bepaal_Gem_BrutoTarief_Van_Tm_Uur($maxuur_int + 1)($maxuur_int + 1)
   if ($maxuur_int -ne 10 -and $maxuur_int -ne 22) {
      $brutotariefmaxuur_plus_2_double = Bepaal_Gem_BrutoTarief_Van_Tm_Uur($maxuur_int + 2) ($maxuur_int + 2)
   }
}
if ($brutotariefmaxuur_plus_1_double -gt $brutotariefhuidiguur_omgerekend_verlies_double) {
    $uren_langer_maxuur_int = 1
    if ($brutotariefmaxuur_plus_2_double -gt $brutotariefhuidiguur_omgerekend_verlies_double) {
        $uren_langer_maxuur_int = 2
    }
}
##bepalen te verwachten PV-opbrengst op basis zonne-wattage de komende uren en het benodigde wattage om 
##vanaf nu tot en met het max-uur te geraken(eventueel verlengt met 1 of 2 extra uren als dat financieel aantrekkelijk is)
$zon_som_waarde_van_nu_tm_einde_dag_int = Bepaal_ZonWattage_van_tm_Uur $huidiguur_int 23
$zon_som_waarde_van_nu_tot_nabijste_maxuur_int = Bepaal_ZonWattage_van_tm_Uur $huidiguur_int ($maxuur_int - 1)
$te_verwachten_PV_opbrengst_vanNu_totMaxuur_int = [int]($ervaringscijfer_kWh_per_zonwaarde * $zon_som_waarde_van_nu_tot_nabijste_maxuur_int) * ($opp_pv_hoogdak_double + $opp_pv_laagdak_double + $opp_pv_tuinhuis_double)
$benodigde_Energie_vanNu_tot_en_met_Maxuur_int = [int]($maxuur_int - $huidiguur_int + $uren_langer_maxuur_int) * $BijlaadHoeveelheidPerUur_int

$energietekort_int = [int]($benodigde_Energie_vanNu_tot_en_met_Maxuur_int - $te_verwachten_PV_opbrengst_vanNu_totMaxuur_int - (($bat_soc_int - 11) / 100 * $capaciteit_batterij_int))
##afhankelijk van voormiddag of namiddag inschatten wat de soc-waarde zou moeten zijn om over het dichts-bijzijnde maximum-tarief heen te geraken vanaf uur nu
##rekening houdend met het geschatte uurverbruik tot max-uur (of maxuur + 1 of 2 uur)

$socwaarde_stopladen_int = (11 + ((($maxuur_int + $uren_langer_maxuur_int - $huidiguur_int) * $BijlaadHoeveelheidPerUur_int) / $capaciteit_batterij_int ) * 100)
$Benodigde_Soc_voor_3_uur_int = (15 + ((3 * $BijlaadHoeveelheidPerUur_int) / $capaciteit_batterij_int ) * 100)
if ($socwaarde_stopladen_int -gt 100) {
  $socwaarde_stopladen_int = 100
}
##wanneer er op basis van de huidige soc en te verwachten PV-opbrengst geen energietekort te verwachten is tot max-uur dan socwaarde-laden-int laag zetten zodat er niet wordt geladen
if ($energietekort_int -lt 0) { ##als het energietekort negatief is (er is nog voldoende pv-opbrengst te verwachten incl. huidige staat bat) dan niet bijladen
   $socwaarde_stopladen_int = 10
}else{
     if ($huidiguur_int -lt $maxuur_int) {
        ##er is energietekort om over het max-uur heen te geraken; nu nog bepalen of het huidig tarief (rekening houdend met RTE-verlies) financieel aantrekkelijk is om bij te laden
        $bijlaadSoc_int = $socwaarde_stopladen_int - $bat_soc_int
        $bijlaadduur_int = [int][math]::ceiling(($bijlaadSoc_int / 100 * $capaciteit_batterij_int) / $max_laadcapaciteit_int_int)
        $gemiddeld_brutotarief_additionele_bijlaaduren_double = Bepaal_Gem_BrutoTarief_Van_Tm_Uur ($maxuur_int - $bijlaadduur_int) ($maxuur_int)
        if ($gemiddeld_brutotarief_additionele_bijlaaduren_double -le $brutotariefhuidiguur_omgerekend_verlies_double) { ## financieel niet aantrekkelijk om bij te laden dus socwaarde_stopladen_int laag zetten
           $socwaarde_stopladen_int = 9
           ## het maxuur moet nog komen en er is een energietekort om alle tussenliggende uren tot maxuur te overbruggen en het is financieel niet interessant om bij te laden;
           ## Is het dan misschien mode passive nog een optie wanneer er voldoende soc is op basis van huidig geschat uurverbruik om het duurste uur en de 2 eromheen liggende uren 
           ## nog met batterijstroom te voorzien?
           if ($bat_soc_int -le $Benodigde_Soc_voor_3_uur_int) {
              $mode_Go_Passive_str = "J"
           }
        }
     }else{ ## in de namiddag is het maxuur reeds verstreken; dan kijken of er voldoende soc is om middels mode passive op basis van huidig geschat uurverbruik om 
            ## het duurste uur en de 2 eromheen liggende uren nog met batterijstroom te voorzien?
            if ($huidiguur_int -ge 12 -and $bat_soc_int -le $Benodigde_Soc_voor_3_uur_int) {
              $mode_Go_Passive_str = "J"
            }
     }
}
Write-Host ("av9a: minuur {0}h/ mintar Eur.{1}/ maxuur {2}h/ maxtar Eur.{3}/ minnegatiefuur {4}h/ minnegatieftar Eur.{5}/ maand {6} mnd/ uur {7}h/ huidigtarief Eur.{8}/ maxbrutotar Eur.{9}" -f $minuur_int,$mintarief_double,$maxuur_int,$maxtarief_double, $minnegatiefuur_int, $minnegatieftarief_double, $huidigemaand_int, $huidiguur_int, $nettohuidigtarief_double, $brutotariefmaxuur_double)
Write-Host ("av9b: mode {0}/ soc {1}%/ soc-stop {2}%/ power {3}W/ kWh-need-tot-maxuur {4}W/ PV-tot-maxuur {5}W/ zonwaarde {6}W/m2/ zonwaarde-tot-max {7}W/m2/ Energietekort {8}W/ huidigtar-omgerekend Eur.{9}" -f $modenu_str,$bat_soc_int,$socwaarde_stopladen_int,$ongrid_power_int,$benodigde_Energie_vanNu_tot_en_met_Maxuur_int , $te_verwachten_PV_opbrengst_vanNu_totMaxuur_int, $zon_som_waarde_van_nu_tm_einde_dag_int, $zon_som_waarde_van_nu_tot_nabijste_maxuur_int, $energietekort_int, $brutotariefhuidiguur_omgerekend_verlies_double)
Write-Host ("av9c: uren-langer-max {0}h/ gem-brutotarief-addit-bijlaad Eur.{1}" -f $uren_langer_maxuur_int, $gemiddeld_brutotarief_additionele_bijlaaduren_double)
Write-Output ("--> Mode/Soc/Soc-Stop/Pow/Mnd/uur/kWh-need-tot-maxuur/PV-tot-maxuur/huidigtarief`t$modenu_str`t/$bat_soc_int %`t/$socwaarde_stopladen_int %`t/$ongrid_power_int W`t/$huidigemaand_int mnd`t/$huidiguur_int h`t/$benodigde_Energie_vanNu_tot_en_met_Maxuur_int W`t/$te_verwachten_PV_opbrengst_vanNu_totMaxuur_int W`t/Eur. $nettohuidigtarief_double") >> .\avzetMODEdynamischOutput.txt 
Write-Output ("--> Min/Max/Zon/Zon-tot-maxuur/Energietekort/Minnegatief`t`t`t`t`t`t`t$minuur_int h `t/Eur. $mintarief_double`t/$maxuur_int h`t/Eur. $maxtarief_double`t/$zon_som_waarde_van_nu_tm_einde_dag_int W/m2`t/$zon_som_waarde_van_nu_tot_nabijste_maxuur_int W/m2`t/$energietekort_int W`t/$minnegatiefuur_int h`t/Eur. $minnegatieftarief_double ") >> .\avzetMODEdynamischOutput.txt 
Write-Output ("--> Uren-langer-Max/gem-brutotarief-addit-bijlaad/huidigtar-omgerekend/maxbrutotar`t$uren_langer_maxuur_int h`t`t/Eur. $gemiddeld_brutotarief_additionele_bijlaaduren_double`t/Eur. $brutotariefhuidiguur_omgerekend_verlies_double`t/Eur. $brutotariefmaxuur_double") >> .\avzetMODEdynamischOutput.txt 
##
## Bepalen of er van mode gewisseld moet worden. No-brainer use-cases het eerst geimplementeerd:
## vanaf hier zijn bekend: $modenu_str, $bat_soc_int, $socwaarde_stopladen_int, $ongrid_power_int, $huidigemaand_int, $huidiguur_int, 
##                         $minnegatieftarief_double, $minnegatiefuur_int, $maxtarief_double, $maxuur_int, $minuur_int, $mintarief_double
##                         $te_verwachten_PV_opbrengst_vanNu_totMaxuur_int, $zon_som_waarde_van_nu_tm_einde_dag_int, $zon_som_waarde_van_nu_tot_nabijste_maxuur_int, 

## No-brainer-a: Als het uur van maximaal tarief nog moet komen binnen 12 uur en er is nu een tarief dat bijladen aantrekkelijk maakt en bijladen is nodig om over max-tarief te geraken dan maximaal bijladen dit kwartier tot
## de stop-laad-waarde waarop hij weer naar Auto gaat; Verschil tussen de bruto prijzen op die uren moet de AC/DC/AC-omzetting compenseren plus omzetverliesopslag cent
if ($bat_soc_int -lt $socwaarde_stopladen_int) {
   $modenieuw_str = "Manual laden $max_laadcapaciteit_int"
   $modegezet_str = "J"
   Write-Host ("Tijd: {0} Mode van: {1} --> {2}" -f $tijdstempel_str, $modenu_str, $modenieuw_str)
   Write-Output ("Tijd: $tijdstempel_str                                                           Mode van $modenu_str --> $modenieuw_str") >> .\avzetMODEdynamischOutput.txt ##-Append
   if ($bijladen_gedurende_huidig_contract -eq "J") {
       $resultaat = Send-And-Wait "ES.SetMode" @{id=1; config = @{id=1; mode= "Manual"; manual_cfg= @{time_num=1;start_time="00:00";end_time="23:59";week_set=127;power=-2500;enable=1}}}
   }
}
## No-brainer-c: 1x per week op zondagnamiddag gedurende de wintermaanden (okt t/m feb) op goedkoopste uur tot 100% laden (als hij niet al 100% is)
## Prijs is hierbij niet meer van toepassing
if (((get-date).DayOfWeek -eq "Sunday") -and
    ($huidigemaand_int -ge 10 -or $huidigemaand_int -le 2) -and  
    ($modenu_str -ne "Manual") -and ($minuur_int -eq $huidiguur_int) -and ($bat_soc_int -lt 100) -and ($huidiguur_int -ge 12)) {
   $socwaarde_stopladen_int = 100
   $modenieuw_str = "Manual laden $max_laadcapaciteit_int (1xper week 100%)"
   $modegezet_str = "J"
   Write-Host ("Tijd: {0} Mode van: {1} --> {2}" -f $tijdstempel_str, $modenu_str, $modenieuw_str)
   Write-Output ("Tijd: $tijdstempel_str                                                           Mode van $modenu_str --> $modenieuw_str") >> .\avzetMODEdynamischOutput.txt ##-Append
   if ($bijladen_gedurende_huidig_contract -eq "J") {
       $resultaat = Send-And-Wait "ES.SetMode" @{id=1; config = @{id=1; mode= "Manual"; manual_cfg= @{time_num=1;start_time="00:00";end_time="23:59";week_set=127;power=-2500;enable=1}}}
   }
}
## No-Brainer-d: in de zomer als veel zon wordt verwacht (misschien zelfs negatieve prijzen) dan tot dat (lage/negatieve) moment ontladen en op dat lage/negatieve uur vol laden
## nog te implementeren TODO

## No-Brainer-e: in de zomer als veel zon is geladen met zonnestroom (misschien zelfs negatieve prijzen) dan bij erg hoge prijzen juist verkopen op die max-uren.
## nog te implementeren TODO

## No-Brainer-f: indien mode_Go_Passive_str = J dan naar mode passive switchen.
if ($mode_Go_Passive_str -eq "J") {
   $modenieuw_str = "Passive"
   $modegezet_str = "J"
   Write-Host ("Tijd: {0} Mode van: {1} --> {2}" -f $tijdstempel_str, $modenu_str, $modenieuw_str)
   Write-Output ("Tijd: $tijdstempel_str                                                           Mode van $modenu_str --> $modenieuw_str") >> .\avzetMODEdynamischOutput.txt
   if ($bijladen_gedurende_huidig_contract -eq "J") {
      $resultaat = Send-And-Wait "ES.SetMode" @{id=1; config = @{id=1; mode= "Passive"; passive_cfg= @{power=100;cd_time=3}}}
   }
}  
## No-brainer-b: Als soc >= $socwaarde_stopladen_int en modus is niet Auto dan op Auto zetten
if (($modenu_str -ne "Auto") -and ($bat_soc_int -ge $socwaarde_stopladen_int)) {
   $modenieuw_str = "Auto"
   $modegezet_str = "J"
   Write-Host ("Tijd: {0} Mode van: {1} --> {2}" -f $tijdstempel_str, $modenu_str, $modenieuw_str)
   Write-Output ("Tijd: $tijdstempel_str                                                           Mode van $modenu_str --> $modenieuw_str") >> .\avzetMODEdynamischOutput.txt ##-Append
   $resultaat = Send-And-Wait "ES.SetMode" @{id=1; config = @{id=1; mode= "Auto"; auto_cfg= @{enable=1}}}
}  

if ($modegezet_str -eq "N") {
   $modenieuw_str = $modenu_str
   Write-Host ("Tijd: {0} Mode niet gezet; blijft {1}" -f $tijdstempel_str, $modenu_str)
   Write-Output ("Tijd: $tijdstempel_str                                                           Mode niet gezet; blijft $modenu_str") >> .\avzetMODEdynamischOutput.txt ##-Append
}
##===============================================================================================
# Optional: drain late packets
$remote = [System.Net.IPEndPoint]::new([System.Net.IPAddress]::Any,0)
$until = [datetime]::UtcNow.AddMilliseconds(5000)
while([datetime]::UtcNow -lt $until){
  try {
    $txt = [Text.Encoding]::UTF8.GetString($udp.Receive([ref]$remote))
    Write-Host ("<= [late] {0}:{1}`n{2}`n" -f $remote.Address,$remote.Port,$txt)
    Write-Output ("<= [late] $remote.Address : $remote.Port /$txt") >> .\avzetMODEdynamischOutput.txt 
  } catch {}
}
$udp.Close()

=====

[ Voor 10% gewijzigd door antoinevromen op 22-09-2025 12:27 ]

[AUijtdehaag]

@antoinevromen
Misschien een tip:
Zet het tussen code tags en quote tags, om het leesbaar en duimvriendelijker te maken.

[antoinevromen]

AUijtdehaag schreef op zondag 21 september 2025 @ 18:08:
@antoinevromen
Misschien een tip:
Zet het tussen code tags en quote tags, om het leesbaar en duimvriendelijker te maken.

Geweldig @AUijtdehaag ; Ik wist eerst niet waar je het over had, maar na even zoeken snapte ik dat dit ook kon;

[SatScan]

antoinevromen schreef op zondag 21 september 2025 @ 18:50:
[...]

Geweldig @AUijtdehaag ; Ik wist eerst niet waar je het over had, maar na even zoeken snapte ik dat dit ook kon;

Stukken beter!
Dank!

[antoinevromen]

SatScan schreef op zondag 21 september 2025 @ 18:53:
[...]


Stukken beter!
Dank!

@AUijtdehaag Wat je bedoelt met quote-tags is me nog steeds niet duidelijk; Ik heb ermee geexperimenteerd, maar dan wordt het tekstgebied alleen maar kleiner. Wat bedoelde je daarmee (meer ter lering)?

[SatScan]

antoinevromen schreef op zondag 21 september 2025 @ 18:55:
[...]

@AUijtdehaag Wat je bedoelt met quote-tags is me nog steeds niet duidelijk; Ik heb ermee geexperimenteerd, maar dan wordt het tekstgebied alleen maar kleiner. Wat bedoelde je daarmee (meer ter lering)?

Prima zo, als we vragen hebben kunnen we naar regelnummer verwijzen en knip en plak is ook handiger.

[AUijtdehaag]

@antoinevromen
Als je buiten de code tags nog quote tags plaatst dan worden de velden inderdaad ingeklapt (en kunnen uitgeklapt worden) en zo verklein je de post.
Scheelt weer scrollen op een mobiel

[ Voor 7% gewijzigd door AUijtdehaag op 21-09-2025 18:59 ]

[antoinevromen]

AUijtdehaag schreef op zondag 21 september 2025 @ 18:58:
@antoinevromen
Als je buiten de code tags nog quote tags plaatst dan worden de velden inderdaad ingeklapt (en kunnen uitgeklapt worden) en zo verklein je de post.
Scheelt weer scrollen op een mobiel

Oke. Helder; ga ik nog aanpassen

[antoinevromen]

AUijtdehaag schreef op zondag 21 september 2025 @ 18:58:
@antoinevromen
Als je buiten de code tags nog quote tags plaatst dan worden de velden inderdaad ingeklapt (en kunnen uitgeklapt worden) en zo verklein je de post.
Scheelt weer scrollen op een mobiel

Dank je voor de tip. Heeft een code-dinosaurus weer wat bijgeleerd dat mensen op telefoons zoiets bekijken
Maar het is wel een heel stuk beter met dat inklappen en die regelnummers.

[djdj105]

Hometek schreef op zaterdag 20 september 2025 @ 22:15:
[...]

Ik ben met iets soortgelijks bezig in Node-RED.

[....]
Over een week of twee zal ik wat meer details delen.

Ben zeer geintersseerd hierin. Volg met belangstelling.

[djdj105]

antoinevromen schreef op zondag 21 september 2025 @ 18:50:
[...]

Geweldig @AUijtdehaag ; Ik wist eerst niet waar je het over had, maar na even zoeken snapte ik dat dit ook kon;

Mooi stukje werk @antoinevromen, al snap ik geen snars van PowerShell.
Misschien een idee een github account te maken (als je die nog niet hebt) en het project / je code daar op te plaatsen, dan is het ook terug te vinden en voor revisies is dat ook heel handig.

[antoinevromen]

djdj105 schreef op zondag 21 september 2025 @ 19:17:
[...]


Mooi stukje werk @antoinevromen, al snap ik geen snars van PowerShell.
Misschien een idee een github account te maken (als je die nog niet hebt) en het project / je code daar op te plaatsen, dan is het ook terug te vinden en voor revisies is dat ook heel handig.

@djdj105 Dank je. Tot een week geleden wist ik ook niets van PowerShell, maar ik heb wel een historie van 30+ jaar in de ICT (en programmeren is zoals fietsen, dat verleer je niet).
Ik heb wel een github account, maar ik wil het niet echt als product gaan onderhouden/promoten. Voor mensen die er wel handig in zijn, die kunnen dit als een soort jump-start gebruiken hoe je de batterij aanroept en hoe je een aantal basale basisgegevens zoals prijzen/zon-voorspelling/batterijstatus etc. kunt inzetten bij het sturen van de batterij.
Ik vond dit met name een handig tool omdat je geen extra hardware/software (zoals bijv home-assistant) nodig hebt en alles via de local-api gaat, die Marstek promoot. In het "hoofd-forum" over Marstek Venus E was al sprake ervan dat Marstek de modbus niet meer zou supporten, en mqtt wordt ook steeds lastiger gemaakt door Marstek waardoor integratie met home-assistant straks waarschijnlijk ook niet meer werkt.
Waarschijnlijk omdat je middels mqtt daarmee load op hun eigen servers in China gaat creeeren en over local-mqtt hoor je helemaal niets meer na de local-api.

[tvh23]

Dank @antoinevromen ik heb het hier werkend gekregen, mijn usecase is om te signaleren dat de verbinding tussen te CT en de batterij lang eruit ligt dat Nom niet werkt of dat de EV gestopt is met laden, dus met name verstoringen / afwijkingen signaleren. Ik draai namelijk alleen nom aangezien ik de terugleverkosten van m'n vast contract wil verminderen. Als ik nog wat tijd over heb, zal ik hem omzetten naar Python zodat ik het op een raspberry kan draaien. M'n laptop heb ik namelijk alleen overdag aan (werk thuis) en de api werkt niet vanuit de cloud (gelukkig maar ;-)

[antoinevromen]

tvh23 schreef op maandag 22 september 2025 @ 22:26:
Dank @antoinevromen ik heb het hier werkend gekregen, mijn usecase is om te signaleren dat de verbinding tussen te CT en de batterij lang eruit ligt dat Nom niet werkt of dat de EV gestopt is met laden, dus met name verstoringen / afwijkingen signaleren. Ik draai namelijk alleen nom aangezien ik de terugleverkosten van m'n vast contract wil verminderen. Als ik nog wat tijd over heb, zal ik hem omzetten naar Python zodat ik het op een raspberry kan draaien. M'n laptop heb ik namelijk alleen overdag aan (werk thuis) en de api werkt niet vanuit de cloud (gelukkig maar ;-)

@tvh23 Mooi te lezen dat je er wat aan hebt. Zo kan iedereen op basis van deze voorbeelden het zelf tot maatwerk maken omdat bijna alle aspecten van de sturing in de scripts zitten.
Ik heb in het verleden ook met een raspberry PI gewerkt, maar die is kapot. Maar als je e.e.a. in Python werkend hebt schroom niet het hier te posten.

Gr. Antoine Vromen

[PNARI]

Ik ga vanaf 1 november tot 28 februari over op een dynamisch contract. De 2 batterijen over op AI. De boiler krijgt met de energysocket een dynamische taak van 21u tot 9u. Deze tijdsblok moet misschien wat aangepast worden in de loop van de winter om te voorkomen dat de batterijen en boiler samen laden om de captar niet uit de hand te laten lopen. Zou ook nog willen dat de batterijen in 2 tijdsblokken de laagste 2 uur laden om zo 18kWh capaciteit ter beschikking te hebben. Is dat te doen met HA via de modbus ?

[matramurena]

antoinevromen schreef op zondag 21 september 2025 @ 16:47:
[...]

DEEL1
Beste Tweakers (o.a. @GoBieN-Be @HiHaHors),
Zoals eerder geschreven hier alvast wat scripts om de batterij middels local-api te sturen.

Wow, bedankt! Ik heb nu de local API aan de praat (via Bluetooth) en heb met behulp van deze Powershell scripts ook aantoonbaar de Marstek kunnen aansturen, in de app heb ik kunnen zien dat van Self Consumption naar AI optimized geschakeld en terug, toen ik die commando's zag. Nu moet ik maar eens een Python script gaan maken zodat Domoticz hiermee overweg kan en ik niet telkens op app van Marstek hoef te kijken. Stapje verder en ik kan de batterij echt gaan aansturen. CT002 uitlezen schijnt ook al te kunnen heb ik begrepen uit de HA integratie.

[antoinevromen]

matramurena schreef op donderdag 25 september 2025 @ 12:47:
[...]

Wow, bedankt! Ik heb nu de local API aan de praat (via Bluetooth) en heb met behulp van deze Powershell scripts ook aantoonbaar de Marstek kunnen aansturen, in de app heb ik kunnen zien dat van Self Consumption naar AI optimized geschakeld en terug, toen ik die commando's zag. Nu moet ik maar eens een Python script gaan maken zodat Domoticz hiermee overweg kan en ik niet telkens op app van Marstek hoef te kijken. Stapje verder en ik kan de batterij echt gaan aansturen. CT002 uitlezen schijnt ook al te kunnen heb ik begrepen uit de HA integratie.

Hallo @matramurena , Fijn te lezen dat je iets hebt gehad aan mijn scripts. Het kunnen aansturen van de batterij is vereiste nr. 1 natuurlijk, maar ik ben zelf ook nog steeds de scripts aan het vervolmaken om meer logica erin te brengen m.b.t. de daadwerkelijk sturingslogica (dat is nog een heel apart hoofdstuk als je dat goed wilt doen). Vandaar ook dat deze oplossing zo mooi is dat iedereen dat wat hij/zij wil bereiken er zelf in kan programmeren.

[antoinevromen]

Beste medetweakers,
Onderstaand de uitgangspunten en strategiën die ik in mijn home-brew-automatisering van de Marstek Venus E heb ingebouwd op basis van de local-api.
Misschien heeft iemand nog aanvullende strategiën of kan ik iemand nog op een idee brengen met deze post.
Zo komen we misschien tot een lijst van mogelijke strategiën waaruit iedereen kan kiezen welke hij/zij zinvol vindt om te implementeren en welke niet.

Uitgangspunten:
-1 Sturing heeft betrekking op een batterij in Nederland (NL) bij een Dynamisch Contract
-2 Sturing vindt plaats 1 x per kwartier (niet teveel schakelen met de batterij en focus op macro-perspectief)
-3 De software heeft de beschikking over de dynamische tarieven van "vandaag" (wordt gedownload als json)
-4 De software heeft de beschikking over de voorspelde zonne-energie (W/m2) van het KNMI op een plek (woonplaats) "vandaag"; (wordt gedownload als json)
Hiervan is af te leiden hoeveel PV-stroom jouw installatie naar verwachting gaat opbrengen op de resterende uren van de dag (per uur)
-5 Bij het laden op Net-stroom wordt het laadtarief vergeleken met de gemiddelde tarieven van de uren waarvoor je gaat bijladen omdat je SOC daarvoor op het moment van laden te laag is.
Dit laadtarief is inclusief alle belastingen geteld en in verband met de RTE-verliezen wordt dit tarief door 0,8 gedeeld en verhoogd met een paar cent om
zichtbaar voordeel te hebben t.o.v. de tarieven waarvoor je middels Net-stroom aan het laden zou gaan als je geen SOC in de batterij zou hebben.
-6 Er is sprake van Maxtarief-uur bij 2 tariefmomenten op een dag (1 x voormiddag (0-11) en 1 x namiddag (12-23)), waarbij het maxtarief-uur ook het uur vooraf en het uur
volgend op het maxtarief-uur bevat (in totaal dus 3 uur om te overbruggen).

Strategiën geimplementeerd:
-1 Basis is NOM (=Zelf Consumptie) is actief als geen van de onderstaande strategiën actief is.
-2 Zomer-Passive (dit is bedoeld om overtollige PV-stroom niet te verkopen op de lagere/negatieve tarief-uren); Het betekent dat wanneer er voldoende zonne-stroom
wordt voorspeld je de batterij in de voormiddag niet laat opladen (maar de PV in de voormiddag laat terugleveren naar het net omdat het tarief dan hoger is dan bijv. in de namiddag)
In de namiddag ga je dan de batterij juist volladen om de laagste/negatieve uren te vermijden.
-3 Winter-Passive (dit is bedoeld om op enig moment te beslissen de batterij in Passive stand te zetten (=niet laden/niet ontladen) om zodoende voldoende SOC in de batterij te houden
om de eerstvolgende piek (maxtarief-uur) te overbruggen. Er moet dan voldoende SOC in de batterij zitten om 3 uur (het maxtarief-uur + 2 naastgelegen uren) te overbruggen.
-4 Strategisch bijladen van het Net (kijkend naar de huidige SOC vaststellen dat deze onvoldoende is om over het komende maxtarief-uur te geraken resp. onvoldoende is om zelfs bij
Passive gaan de 3 uur van Maxtarief-uur te overbruggen. Dan wordt gekeken of het met RTE-verlies verhoogde Net-tarief op het huidige uur opweegt tegen
de gemiddelde prijs inclusief belastingen van alle tussenliggende uren t/m maxuur + 1 of gemiddelde prijs inclusief belastingen van de 3 uur rondom het maxuur.
Als dit rendabel is (meestal zal dit op of rond het minimum-uur vooraf aan het maximum-uur zijn) ga je laden (Manual) totdat de gewenste SOC is bereikt en
anders blijf je op NOM staan omdat bijladen financieel niet loont en je toch nog elke Watt PV kunt meenemen die je PV opleveren ook al is dat niet voldoende om
dat aankomende dure max-uur te overbruggen.
-5 Gedurende de winter 1 x per week tot 100% vol laden op het goedkoopste uur (zodat de batterij niet wekenlang op 11% staat bij weinig PV)
-6 Monitoring status batterij (middels logging bij elke sturings-run)
===============================================================================
-7 Afgeleide strategie van -3 (wanneer de batterij in Winter-Passive is gegaan om SOC te sparen tot het maxtariefuur-1, dan wordt de batterij vanzelf op NOM (=Zelf Consumptie) gezet
wanneer het uur voorafgaand aan het maxtarief-uur is aangebroken.
-8 Afgeleide strategie van -2 (wanneer de batterij in Zomer-Passive is gegaan om pas bij het minimum-tariefuur te gaan laden, wordt de batterij vanzelf op NOM (=Zelf Consumptie) gezet
wanneer het minimum-tariefuur is aangebroken
-9 Afgeleide strategie van -4 (wanneer bij het bijladen Manual de gewenste SOC is bereikt wordt de batterij weer vanzelf op NOM (=Zelf Consumptie) gezet (n.b. het zou best kunnen dat
in het daaropvolgende kwartier een van de andere strategiën de batterij dan op Passive gaat zetten)

Strategiën NIET geimplementeerd:
-1 Minimalisatie van CAPTAR (valide strategie, maar specifiek voor België)
-2 Verkopen PV-stroom/Ingekochte-stroom van goedkope uren op Duurste uur/uren (valide strategie, maar volgens mij slechts nog zinvol gedurende de salderingsregeling)

Groeten Antoine Vromen

[olympusdenk]

Ik heb de volgende proof of concept op Github gezet en het plannen van manuele schema's in de Marstek app. Vanuit Home Assistant / in combinatie met Hame Relay:
https://github.com/pcvelz...e/feat/0-proof-of-concept

Deze HA package is gemaakt specifiek voor Venus-E 2.0 op dit moment en zet de batterij op manuele modus waarna de Marstek via de app wordt gevuld met tijdschema’s voor het laden in goedkope uren en ontladen in dure uren, en controle of het prijsverschil hoger is dan het verlies (RTE ligt rond de 75-80% tussen laden en ontladen). Ook rekening houdend met verschillende dagdelen, bijvoorbeeld als je zondagmiddag goedkoop geladen energie kan door de package gebruikt worden dag later op maandagochtend als die uren meer opleveren.



Als de spread goedkoopste uur en duurste uur minder verschil is dan 20% verlies die je hebt bij op- en ontladen de MT standby te zetten.

En, wanneer zoals vandaag de spread tussen goedkoopste uren en de duurste uren hoog genoeg ligt. Dan zoals je bijvoorbeeld hieronder kan zien is use case de MT schema's automatisch te laten laden op goedkoopste uren (12:00 - 15:00 tegen 24ct laden op 2500w + 20 extra minuten voor 99% => 100%) en ontladen on duurste uren (19:00 tegen 52ct op 2500w ontladen en 18:00 tegen 45ct op 2000w ontladen).



Deze HA package heeft zoals je kunt zien in dit voorbeeld hierboven voor vandaag de meest goedkoopste uren gepakt van 12 - 15:00 (+20 minuten tijd buffer voor 99% => 100% laden) en heeft duurste uren vanavond 18:00 - 20:00 om stroom op hoogste tarief uit de batterij te leveren.




Het resultaat wat ik wou bereiken is op het goedkoopste moment laden en duurste moment ontladen, afhankelijk van of er genoeg prijsverschil is laat ik dit met deze HA package tussen de 1 á 2x per dag inplannen:

[ Voor 79% gewijzigd door olympusdenk op 30-09-2025 19:38 ]

[olympusdenk]

Dit vereist nog wel wat installatiewerk binnen HA. Ik ben vooral voor de Hame Relay implementatie weg ingeslagen omdat het voordeel mij leek dat de app ook nog werkend blijft. Het voordeel is ook dat het aansluit binnen HA (qua koppeling met andere automatisering, dashboards etc).
Hoewel @antoinevromen wellicht is dit een interessante om te bekijken en de business logic te vergelijken met powershell script.

[antoinevromen]

olympusdenk schreef op dinsdag 30 september 2025 @ 12:45:
Ook even cross-post:

[...]

Hallo @olympusdenk ,
Goed te lezen dat je ook een batterij-sturings-project gestart bent.

Je schrijft "Ik ben vooral voor de Hame Relay implementatie weg ingeslagen omdat het voordeel mij leek dat de app ook nog werkend blijft. " ; Wanneer werkt de app dan niet meer, dat jij de Hame Relay weg bent ingeslagen, want middels local-api werkt ook de app gewoon? Je weet toch dat Marstek er van alles aan probeert te doen om de werking van Hame Relay en HM2MQTT onmogelijk te maken? (was laatst bij versie V154 al het geval toen ze encryptie in de MQTT-berichten hadden gestopt om gebruik door derden van de Marstek-MQTT-servers (in Europa/China) te voorkomen.

Je schrijft ook dat het misschien interessant is om de business-logic van jou te vergelijken met wat ik in powershell-scripts heb gestopt. Heb je die business-logic ook ergens in een beetje functionele beschrijving staan, zodat ik niet door Home-Assistant-code moet gaan spitten?

[olympusdenk]

antoinevromen schreef op dinsdag 30 september 2025 @ 15:44:
[...]

Hallo @olympusdenk ,
Goed te lezen dat je ook een batterij-sturings-project gestart bent.

Je schrijft "Ik ben vooral voor de Hame Relay implementatie weg ingeslagen omdat het voordeel mij leek dat de app ook nog werkend blijft. " ; Wanneer werkt de app dan niet meer, dat jij de Hame Relay weg bent ingeslagen, want middels local-api werkt ook de app gewoon? Je weet toch dat Marstek er van alles aan probeert te doen om de werking van Hame Relay en HM2MQTT onmogelijk te maken?

Dat klopt, ik volg de ontwikkelingen met Hame Relay op de voet en met v154 werkt op dit moment de HA integratie. Het klopt ook dat MT er alles aan doet (alhoewel ze daar nog wel lachwekkend tekort schieten), ik heb er al wel mee rekening gehouden en de aansturing code apart gehouden van de planning logica. Op dit moment is nog niet bij iedereen de local-API actief, maar het zeker reeel dat meer final versie met local API ga doen als vervanging van deze voor nu deze proof of concept nog tegen Hame Relay

(was laatst bij versie V154 al het geval toen ze encryptie in de MQTT-berichten hadden gestopt om gebruik door derden van de Marstek-MQTT-servers (in Europa/China) te voorkomen.

Ik had ook al de pech hier pas na de firmware upgrade naar v154 achter te komen, de ontwikkelaar heeft gelukkig wel al een werkende versie in de pijplijn deze heb ik momenteel lokaal werkend met v154

Edit link toegevoegd: https://github.com/tomqui...4#issuecomment-3300383403

“ @tomquist 2 weeks ago
A test build is now available. It can be installed in Home Assistant via this repository URL:

https://github.com/tomquist/hame-relay#support-vid
I would specifically be interested if this fixes issues for anyone using a Jupiter with >=v136 or B2500 HMJ with >=v116 or HMB/HMA/HMK/HMF with >= v230 so please provide feedback”

Je schrijft ook dat het misschien interessant is om de business-logic van jou te vergelijken met wat ik in powershell-scripts heb gestopt. Heb je die business-logic ook ergens in een beetje functionele beschrijving staan, zodat ik niet door Home-Assistant-code moet gaan spitten?

Dat zit wel in de pipeline het is nu ook nog proof of concept die ik alvast deel en met beetje Tweaken werkend te krijgen al is lokaal, ik heb twee posts hierboven even een beknopte start gemaakt die heb ik net toegevoegd.

[ Voor 9% gewijzigd door olympusdenk op 30-09-2025 23:13 ]

[Hometek]

Aangepaste strategie voor langdurig lage stroomprijs

Dit weekeinde was de dynamische stroomprijs ca. 36 uur lang praktisch vast op ca. 15 ct (inkoopprijs 0 ct). En er was weining zon.
In deze omstandigheden is het vanwegen de rendements verliezen niet zinvol om de batterij vanuit het net op te laden bij de laagste stroomprijs en dan NOM te draaien.
Ik heb daarom niet opgeladen van het net, en de ontlaad limiet op 0 gezet (via modbus), de batterij laad dan nog wel op als er voldoende PV opwek is, maar ontlaad niet in de zelfconsumptie modus (auto in onderstaand plaatje).

[Hometek]

EMS met SOC als richtwaarde

Een EMS is altijd maatwerk, aangepast aan zowel de installatie, het verbruiksprofiel als ook de persoonlijke doelen die men wil behalen. Maar één ding heeft elk EMS nodig: een richtwaarde. Aan de hand van een theoretisch optimale richtwaarde kan de EMS berekenen of er een bepaalde actie nodig is, bv de batterij opladen van het net met goedkope stroom omdat er morgen weinig zon verwacht wordt.

Ik heb een systeem bedacht om de SOC als richtwaarde te gebruiken. Het systeem is uiteraard volledig afgestemd op mijn verbruik en mijn installatie. Maar het principe kan wellicht als inspiratie dienen voor andere systemen. Ik bouw het systeem in HA/Node-RED en ben momenteel nog aan het testen en inregelen. De flows zijn daardoor nu nogal rommelig. Zodra het stabiel genoeg werkt, zal ik de flows netter structureren en hier delen ter inspiratie. Het zal geen copy/paste toepassing zijn, maar het kan iemand wel op weg helpen, en enkele stukken kunnen wellicht hergebruikt worden.
In deze post alvast het principe en de formules.

Het systeem berekend elke 20 min de optimale SOC waarden:
MSH: minimum SOC nu om de batterij met PV opwek vol te laden
MSL: minimum SOC nu zo dat de batterij met PV opwek morgen ochtend nog niet leeg is

Als de actuele SOC groter is dan MSH is er een overschot dat bij hoogste stroomprijs naar het net ‘verkocht’ kan worden tot SOC=MSH.
Als de actuele SOC kleiner is dan MSL is er een tekort en moet de batterij bij lage stroomprijs opgeladen worden tot SOC=MSL.
Deze strategie is vermoedelijk vooral zinvol voor systemen waarbij de batterij groot genoeg is om makkelijk de volgende dag te halen met NOM.
Alternatief zou je ook uitsluitend op basis van MSH kunnen regelen om altijd een zo vol mogelijke batterij te hebben.
Parallel kunnen ook andere regelingen draaien om bijvoorbeeld laden/ontladen te sturen op basis van actuele stroomprijs.

Variabelen nodig om MSH en MSL te berekenen:
BAT: max batterijcapaciteit in kWh
USE: verwacht gemiddeld stroomverbruik per uur in kW
HRSH: uren tot zonsondergang vandaag
HRST: uren tot 16:00
HRSM: uren tot 00:00
HRSL: uren tot morgen 10:00
SUN1: verwachte PV opwek tot zonsondergang vandaag in kWh
SUN2: verwachte PV opwek morgen in kWh
SUN3: verwachte PV opwek overmorgen in kWh

Berekeningen minimum SOC
MSH1 = ((BAT + (USE * HRSH) - SUN1) / BAT) * 100 vandaag vol
MSH2 = ((BAT + (USE * HRSH+24) - SUN1 - SUN2) / BAT) * 100 morgen vol
MSH3 = ((BAT + (USE * HRSH+48) - SUN1 - SUN2 - SUN3) / BAT) * 100 overmorgen vol
MSL2 = (((USE * HRSL) - SUN1) / BAT) * 100 morgen leeg
MSL3 = (((USE * HRSL+24) - SUN1 - SUN2) / BAT) * 100 overmorgen leeg

LET OP: dit zijn ideale formules, er wordt geen rekening gehouden met verliezen

In een geïdealiseerde simulatie geeft dit de volgende lijnen (MSL2 en MSL3 hebben hier 20% als doel):


Omdat PV opwek niet lineair verloopt en opwek morgen om middernacht verandert in opwek vandaag, heb ik de dag in 3 tijdvakken verdeeld:

middernacht - 10:00 [MSH1 en MSH2 volgens formule]
10:00 - 16:00 [transitie MSH1 naar MSH2, en MSH2 naar MSH3]
16:00 - middernacht [MSH1 = MSH2, MSH2=MSH3 transitie MSL2 naar MSL3]

Tijdvak B loopt tot 16:00 zodat vóór de avondpiek in de stroomprijs de transitie naar MSH2 afgerond is. Transitie tussen 10:00 en 16:00:

MSH1 = MSH2 + ((HRST / 6) * (MSH1 - MSH2))
MSH2 = MSH3 + ((HRST / 6) * (MSH2 - MSH3))

Voor MSL2 en MSL3 hetzelfde, maar dan tussen 16:00 en 00:00

MSL2 = MSL3 + ((HRSM/8) * (MSL2 - MSL3))

Uiteindelijk MSH en MSL bepalen:
MSH = grootste van MSH1 en MSH2
MSL = MSL2

In de ideale simulatie:


Praktijk data voor transitie MSH1/MSH2 (blauw) en MSH2/MSH3 (rood)


Simulatie voor 2 dagen met alleen MSH en MSL


Als er morgen zeer weinig zon is, daalt de SOC onder MSL en moet er stroom van het net opgeladen worden op het eerstvolgende moment dat de prijs gunstig is.


Als er morgen zeer veel zon is, stijgt de SOC boven MSH en kan er stroom naar het net ontladen worden op het eerstvolgende moment dat de prijs hoog is.

[ Voor 3% gewijzigd door Hometek op 08-10-2025 10:07 ]

[Hometek]

antoinevromen schreef op zondag 21 september 2025 @ 16:26:
...
Zo stuurde ik ook eerst op minimum en maximum prijs, maar kwam erachter dat ik ook de RTE (verlies t.g.v. laden/ontladen) in de berekening wilde meenemen omdat ik merkte dat soms een verschil van bijv. x-cent zich door de RTE uiteindelijk vertaalde in het feit dat de minimum-stroomprijs (geladen) toch nog hoger was dan de maximum prijs.
...

Goede tip!
Ik heb het ondertussen hier ook ingebouwd. Bij opladen van het net bij laagste prijs sla ik de prijs van dat uur op, en als later tijdens NOM draaien het prijsverschil te klein wordt zet het systeem de limiet voor Max. Discharge op 0W zodat er nog wel PV overschot wordt opgeslagen (zie ook hier)

[antoinevromen]

Hometek schreef op dinsdag 7 oktober 2025 @ 13:58:
[...]

Goede tip!
Ik heb het ondertussen hier ook ingebouwd. Bij opladen van het net bij laagste prijs sla ik de prijs van dat uur op, en als later tijdens NOM draaien het prijsverschil te klein wordt zet het systeem de limiet voor Max. Discharge op 0W zodat er nog wel PV overschot wordt opgeslagen (zie ook hier)

Hallo @Hometek , Als ik dat zo lees is dat een andere benadering dan bij mij, maar uiteindelijk beperk je het ontladen totdat zich een groter prijsverschil voordoet dan waarvoor je hebt geladen (incl. RTE-verlies) van het net.
Ik doe het andersom. Ik kijk naar welke pieken komen er nog en als het financieel niet interessant is t.g.v. RTE-verlies dan laadt ik niet en neem ook de PV die nog komt op via de NOM-stand.

[antoinevromen]

Hometek schreef op maandag 6 oktober 2025 @ 21:11:
EMS met SOC als richtwaarde

Een EMS is altijd maatwerk, aangepast aan zowel de installatie, het verbruiksprofiel als ook de persoonlijke doelen die men wil behalen. Maar één ding heeft elk EMS nodig: een richtwaarde. Aan de hand van een theoretisch optimale richtwaarde kan de EMS berekenen of er een bepaalde actie nodig is, bv de batterij opladen van het net met goedkope stroom omdat er morgen weinig zon verwacht wordt.

Ik heb een systeem bedacht om de SOC als richtwaarde te gebruiken. Het systeem is uiteraard volledig afgestemd op mijn verbruik en mijn installatie. Maar het principe kan wellicht als inspiratie dienen voor andere systemen. Ik bouw het systeem in HA/Node-RED en ben momenteel nog aan het testen en inregelen. De flows zijn daardoor nu nogal rommelig. Zodra het stabiel genoeg werkt, zal ik de flows netter structureren en hier delen ter inspiratie. Het zal geen copy/paste toepassing zijn, maar het kan iemand wel op weg helpen, en enkele stukken kunnen wellicht hergebruikt worden.
In deze post alvast het principe en de formules.

Het systeem berekend elke 20 min de optimale SOC waarden:
MSH: minimum SOC nu om de batterij met PV opwek vol te laden
MSL: minimum SOC nu zo dat de batterij met PV opwek morgen ochtend nog niet leeg is

Als de actuele SOC groter is dan MSH is er een overschot dat bij hoogste stroomprijs naar het net ‘verkocht’ kan worden tot SOC=MSH.
Als de actuele SOC kleiner is dan MSL is er een tekort en moet de batterij bij lage stroomprijs opgeladen worden tot SOC=MSL.
Deze strategie is vermoedelijk vooral zinvol voor systemen waarbij de batterij groot genoeg is om makkelijk de volgende dag te halen met NOM.

Variabelen nodig om MSH en MSL te berekenen:
BAT: max batterijcapaciteit in kWh
USE: verwacht gemiddeld stroomverbruik per uur in kW
HRSH: uren tot zonsondergang vandaag
HRST: uren tot 16:00
HRSM: uren tot 00:00
HRSL: uren tot morgen 10:00
SUN1: verwachte PV opwek tot zonsondergang vandaag in kWh
SUN2: verwachte PV opwek morgen in kWh
SUN3: verwachte PV opwek overmorgen in kWh

Berekeningen minimum SOC
MSH1 = ((BAT + (USE * HRSH) - SUN1) / BAT) * 100 vandaag vol
MSH2 = ((BAT + (USE * HRSH+24) - SUN1 - SUN2) / BAT) * 100 morgen vol
MSH3 = ((BAT + (USE * HRSH+48) - SUN1 - SUN2 - SUN3) / BAT) * 100 overmorgen vol
MSL2 = (((USE * HRSL) - SUN1) / BAT) * 100 morgen leeg
MSL3 = (((USE * HRSL+24) - SUN1 - SUN2) / BAT) * 100 overmorgen leeg

LET OP: dit zijn ideale formules, er wordt geen rekening gehouden met verliezen

In een geïdealiseerde simulatie geeft dit de volgende lijnen (MSL2 en MSL3 hebben hier 20% als doel):
[Afbeelding]

Omdat PV opwek niet lineair verloopt en opwek morgen om middernacht verandert in opwek vandaag, heb ik de dag in 3 tijdvakken verdeeld:

middernacht - 10:00 [MSH1 en MSH2 volgens formule]
10:00 - 16:00 [transitie MSH1 naar MSH2, en MSH2 naar MSH3]
16:00 - middernacht [MSH1 = MSH2, MSH2=MSH3 transitie MSL2 naar MSL3]

Tijdvak B loopt tot 16:00 zodat vóór de avondpiek in de stroomprijs de transitie naar MSH2 afgerond is. Transitie tussen 10:00 en 16:00:

MSH1 = MSH2 + ((HRST / 6) * (MSH1 - MSH2))
MSH2 = MSH3 + ((HRST / 6) * (MSH2 - MSH3))

Voor MSL2 en MSL3 hetzelfde, maar dan tussen 16:00 en 00:00

MSL2 = MSL3 + ((HRSM/8) * (MSL2 - MSL3))

Uiteindelijk MSH en MSL bepalen:
MSH = grootste van MSH1 en MSH2
MSL = MSL2

In de ideale simulatie:
[Afbeelding]

Praktijk data voor transitie MSH1/MSH2 (blauw) en MSH2/MSH3 (rood)
[Afbeelding]

Simulatie voor 2 dagen met alleen MSH en MSL
[Afbeelding]

Als er morgen zeer weinig zon is, daalt de SOC onder MSL en moet er stroom van het net opgeladen worden op het eerstvolgende moment dat de prijs gunstig is.
[Afbeelding]

Als er morgen zeer veel zon is, stijgt de SOC boven MSH en kan er stroom naar het net ontladen worden op het eerstvolgende moment dat de prijs hoog is.
[Afbeelding]

@Hometek Indrukwekkend al die formules te zien en hoe je op een totaal andere manier toch je eigen use-cases in het systeem aan het inbouwen bent. Op het moment dat je deze stuurlogica begint te verwoorden voor anderen, dan kom je erachter dat er toch wel veel variabelen door elkaar spelen en het "even" in een paar zinnen opschrijven wat er in de programmatuur gebeurt nog niet zo simpel is.
Ik zie dat je ook rekening houdt met de verwachte PV-opbrengst in de toekomst. Ik neem aan dat je daar dezelfde bron als ik voor gebruik (https://weerlive.nl/api/weerlive_api_v2.php) Zo niet, dan ben ik wel benieuwd wat je dan gebruikt. Ik heb zelf op basis van die voorspelde Wattages/m2 en mijn daadwerkelijke PV-opbrengst een soort constante berekend/geschat om die Wattages/m2 om te rekenen naar PV-kWh
(hoe doe jij dat?)

[Hometek]

antoinevromen schreef op dinsdag 7 oktober 2025 @ 14:53:
[...]

@Hometek Indrukwekkend al die formules te zien en hoe je op een totaal andere manier toch je eigen use-cases in het systeem aan het inbouwen bent. Op het moment dat je deze stuurlogica begint te verwoorden voor anderen, dan kom je erachter dat er toch wel veel variabelen door elkaar spelen en het "even" in een paar zinnen opschrijven wat er in de programmatuur gebeurt nog niet zo simpel is.
Ik zie dat je ook rekening houdt met de verwachte PV-opbrengst in de toekomst. Ik neem aan dat je daar dezelfde bron als ik voor gebruik (https://weerlive.nl/api/weerlive_api_v2.php) Zo niet, dan ben ik wel benieuwd wat je dan gebruikt. Ik heb zelf op basis van die voorspelde Wattages/m2 en mijn daadwerkelijke PV-opbrengst een soort constante berekend/geschat om die Wattages/m2 om te rekenen naar PV-kWh
(hoe doe jij dat?)

Het opschrijven helpt mij ook om het zelf beter te begrijpen en vaak vind ik zo ook fouten

Voor de PV opwek voorspelling gebruik ik Solcast, deze HA integratie levert direct de verwachte kWh voor een installatie (specificaties invoeren op hun website), en er zit sinds kort een handige auto-correctie functie in (zie deze post).

[Hometek]

antoinevromen schreef op dinsdag 7 oktober 2025 @ 14:38:
[...]
Hallo @Hometek , Als ik dat zo lees is dat een andere benadering dan bij mij, maar uiteindelijk beperk je het ontladen totdat zich een groter prijsverschil voordoet dan waarvoor je hebt geladen (incl. RTE-verlies) van het net.
Ik doe het andersom. Ik kijk naar welke pieken komen er nog en als het financieel niet interessant is t.g.v. RTE-verlies dan laadt ik niet en neem ook de PV die nog komt op via de NOM-stand.

Mijn aanpak is idd anders, dat komt denk ik vooral omdat mijn batterij capaciteit groter is dan mijn gemiddelde dagverbruik, ik kan dus wachten op dat ene uur met de laagste prijs.
Mijn doelen zijn:

1. zoveel mogelijk eigen PV stroom gebruiken
2. keuzevrijheid om wel of niet overschot terug te leveren aan het net

Mijn EMS heeft 3 functies die ik onafhankelijk van elkaar aan of uit kan zetten:

1. bij te lage SOC batterij opladen van het net tijdens goedkope uren
2. bij te hoge SOC batterij ontladen naar het net tijdens dure uren
3. PV panelen uitschakelen als de verwachte opwek meer is dan het verwachte verbruik

Afgezien van persoonlijk voordeel denk ik dat deze functies ook bijdragen om het stroomnet te ontlasten (mits meer mensen het gaan doen)

[antoinevromen]

Hometek schreef op dinsdag 7 oktober 2025 @ 16:22:
[...]

Het opschrijven helpt mij ook om het zelf beter te begrijpen en vaak vind ik zo ook fouten

Voor de PV opwek voorspelling gebruik ik Solcast, deze HA integratie levert direct de verwachte kWh voor een installatie (specificaties invoeren op hun website), en er zit sinds kort een handige auto-correctie functie in (zie deze post).

@Hometek Heb eens gekeken bij solcast; Weer een andere wijze van werken, maar ik ben er nog niet achter of ik ook historisch gezien gegevens kan opvragen om te vergelijken met de reeds gerealiseerde PV-opbrengst per dag. Api werkt wel nu voor vandaag of voorspelling voor bijv. morgen

[ Voor 4% gewijzigd door antoinevromen op 07-10-2025 17:15 ]

[antoinevromen]

Hometek schreef op dinsdag 7 oktober 2025 @ 17:07:
[...]

Mijn aanpak is idd anders, dat komt denk ik vooral omdat mijn batterij capaciteit groter is dan mijn gemiddelde dagverbruik, ik kan dus wachten op dat ene uur met de laagste prijs.
Mijn doelen zijn:

1. zoveel mogelijk eigen PV stroom gebruiken
2. keuzevrijheid om wel of niet overschot terug te leveren aan het net

Mijn EMS heeft 3 functies die ik onafhankelijk van elkaar aan of uit kan zetten:

1. bij te lage SOC batterij opladen van het net tijdens goedkope uren
2. bij te hoge SOC batterij ontladen naar het net tijdens dure uren
3. PV panelen uitschakelen als de verwachte opwek meer is dan het verwachte verbruik

Afgezien van persoonlijk voordeel denk ik dat deze functies ook bijdragen om het stroomnet te ontlasten (mits meer mensen het gaan doen)

@Hometek Ik neem aan dat er ook iets in zit om bijv. juist niet van het net op te laden en met PV de batterij te vullen. Of juist het uitstellen van het laden van de batterij op PV in de ochtenduren (zomer, in de ochtend terugleveren aan net op relatief duurdere uren i.p.v. laden pv-stroom op die uren) om dan in de middaguren (als de prijs heel laag is / misschien negatief) op PV te gaan laden.

[Hometek]

antoinevromen schreef op dinsdag 7 oktober 2025 @ 17:22:
[...]
@Hometek Ik neem aan dat er ook iets in zit om bijv. juist niet van het net op te laden en met PV de batterij te vullen. Of juist het uitstellen van het laden van de batterij op PV in de ochtenduren (zomer, in de ochtend terugleveren aan net op relatief duurdere uren i.p.v. laden pv-stroom op die uren) om dan in de middaguren (als de prijs heel laag is / misschien negatief) op PV te gaan laden.

Welke strategie de voorkeur heeft hangt voor een groot deel van de persoonlijke voorkeuren af; maximaal financieel voordeel, maximale reserve in de batterij, minimale belasting van het net. Maar ook van de verhouding tussen PV, batterij en verbruik. Die mix zal voor elk huishouden anders zijn

[UsernameIsInUse]

..

[ Voor 198% gewijzigd door UsernameIsInUse op 08-10-2025 10:59 . Reden: reeds beantwoord ]

[Rhelms]

antoinevromen schreef op zondag 21 september 2025 @ 17:25:
DEEL6:
Onderstaand het script om periodiek (bijv. elk kwartier) te draaien dat op basis van zonnewattage/m2 , dynamische tarieven voor een dag, de huidige informatie uit je batterij en enkele andere logica bepaalt of
de batterij middels Net-stroom geladen moet worden om zodoende geld te verdienen (bijv. door te handelen, of door ervoor te zorgen dat je de dure uren via de batterij kunt doorkomen met goedkoop geladen net-stroom etc.
=====
Het scriptje avzetMODEdynamisch.cmd
=====

[...]

======
Het scriptje avzetMODEdynamisch.ps1
=====

[...]

=====

Hi Antoine,

Heel veel dank voor je moeite, ik heb het aan de praat. Ik heb echter 1 probleem met het script: Als de accumodus op "Passive" staat en de uitkomst van het script is schakelen naar "Auto", dan werkt dit niet. Hij blijft op Passive mode staan. Bij het schakelen vanaf een andere modus dan "Passive" naar "Auto" werkt het wel. Enig idee hoe dit kan komen?

Alvast bedankt!

[antoinevromen]

Hallo Rhelms,

Ik heb inmiddels al heel veel extra functionaliteit in het script toegevoegd (ook programmaflow-logging), waardoor ik kan zien waarom er een beslissing is genomen. Zie het meer als een jump-start.
Ik weet niet of je kunt programmeren (en zelf middels write-output statements debugging kunt toevoegen).
Dan kun je zelf achterhalen waar hij komt en waarom het niet werkt. Ik kan je ook mijn allerlaatste versie van de script toesturen. Waarschijnlijk is daar de betreffende situatie al in opgelost. Zeg maar wat je het liefste doet. Als het namelijk loopt is het heel simpel de inhoud van het script door een nieuwe inhoud te vervangen. Of je moet er ook lol aan hebben om het script te doorgronden en zelf mijn denkfout te vinden ;-)
Dan zou je ook je eigen wensen erin kunnen bouwen nu je weet hoe je de basiszaken kunt schakelen en voorbeelden hebt hoe je op basis van inputgegevens tot een beslissing tot schakelen kunt komen.
Groeten Antoine Vromen

[ Voor 11% gewijzigd door antoinevromen op 09-10-2025 14:05 ]

[Rhelms]

antoinevromen schreef op donderdag 9 oktober 2025 @ 13:59:
Hallo Rhelms,

Ik heb inmiddels al heel veel extra functionaliteit in het script toegevoegd (ook programmaflow-logging), waardoor ik kan zien waarom er een beslissing is genomen. Zie het meer als een jump-start.
Ik weet niet of je kunt programmeren (en zelf middels write-output statements debugging kunt toevoegen).
Dan kun je zelf achterhalen waar hij komt en waarom het niet werkt. Ik kan je ook mijn allerlaatste versie van de script toesturen. Waarschijnlijk is daar de betreffende situatie al in opgelost. Zeg maar wat je het liefste doet. Als het namelijk loopt is het heel simpel de inhoud van het script door een nieuwe inhoud te vervangen. Of je moet er ook lol aan hebben om het script te doorgronden en zelf mijn denkfout te vinden ;-)
Dan zou je ook je eigen wensen erin kunnen bouwen nu je weet hoe je de basiszaken kunt schakelen en voorbeelden hebt hoe je op basis van inputgegevens tot een beslissing tot schakelen kunt komen.
Groeten Antoine Vromen

Ah super, ik zou heel graag je nieuwste versie ontvangen. Ik ben absoluut geen held in programmeren haha. Nogmaals dank!

[antoinevromen]

Rhelms schreef op donderdag 9 oktober 2025 @ 15:01:
[...]


Ah super, ik zou heel graag je nieuwste versie ontvangen. Ik ben absoluut geen held in programmeren haha. Nogmaals dank!

Ik zal je die nieuwste versie via PB toesturen

[WargamingPlayer]

Zijn er mensen die het lukt om een Solcast account aan te maken?