Marstek PIB Domotica integratie en je Energierekening

[JanAllElectric]

De basisversie van de verdeelfunctie (nb: het duiveltje is 2 sluit acculades):

function distributePower(batteries, targetPower, gridPower, mode) {
// Accu's compenseren de gridPower binnen toegestane targetPower limiet

let remainingPower = 0;
let totalPower = 0;
let buySell = 0;

let totalAvailable = Math.min(targetPower, batteries.reduce((sum, b) => sum + (mode === 'charge' ? b.maxCharge : b.maxDischarge), 0));
let powerPlan = batteries.map(battery => ({ battery: battery.id, power: 0, soc: battery.soc );


for (let i = 0; i < batteries.length && totalAvailable > 0; i++) {
let battery = batteries[i];
let maxPossible = Math.min((mode === 'charge' ? battery.maxCharge : battery.maxDischarge), totalAvailable);
powerPlan[i].power = maxPossible;
totalAvailable -= maxPossible;
}

for (let i = 0; i < batteries.length ; i++) {
totalPower += powerPlan[i].power;
}


// laden/ontladen
totalPower = (mode === 'charge' ? totalPower : -1 * totalPower);

// buy of sell
buySell = gridPower + totalPower;

//remaining power
remainingPower = gridPower + totalPower;

//mode idle als totalPower == 0
mode = (totalPower === 0 ? 'idle' : mode);

//powerPlan: per accu
//buySell: kopen/verkopen
//remainingPower: hoofdmeter na charge/discharge
//totalPower: geladen/ontladen
//Mode: charge/discharge/idle

// waardes kunnen positief en negatief zijn
totalPower = Math.abs(totalPower);
//buySell = Math.abs(buySell);

return { powerPlan, gridPower, remainingPower, mode, totalPower, buySell};

object als resultaat:

[ Voor 16% gewijzigd door JanAllElectric op 07-06-2025 14:47 ]

[badnews.nl]

Ik ga even een handleiding maken hoe ik de Marstek in Homey heb gekregen.
In mijn geval is dat met een lilygo en esphome, die elke 10 seconde mijn homey updaten.
De Marstek zit in de energy tab van Homey als accu. Ik zal het modulair opbouwen, omdat je het op verschillende manieren kan aanpakken. Maar omdat ik de scripts van Homey niet via mijn ipad makkelijk kan copieren, moet ik even de laptop aanslingeren straks.
Het is redelijk simpel, en ik heb het meeste ingefluisterd gekregen van andere hier op het forum.

Dus je krijgt dan op je Homey een accu in Energy, zonder mqtt of home assistant, via de lilygo

[Ellroe32]

badnews.nl schreef op zaterdag 7 juni 2025 @ 18:26:
Ik ga even een handleiding maken hoe ik de Marstek in Homey heb gekregen.
In mijn geval is dat met een lilygo en esphome, die elke 10 seconde mijn homey updaten.
De Marstek zit in de energy tab van Homey als accu. Ik zal het modulair opbouwen, omdat je het op verschillende manieren kan aanpakken. Maar omdat ik de scripts van Homey niet via mijn ipad makkelijk kan copieren, moet ik even de laptop aanslingeren straks.
Het is redelijk simpel, en ik heb het meeste ingefluisterd gekregen van andere hier op het forum.

Dus je krijgt dan op je Homey een accu in Energy, zonder mqtt of home assistant, via de lilygo

[Afbeelding]

-470Wh. Daar moet volgens mij je echte verbruik komen te staan op die dag.


HW denkt:


Maar er is 1,3 kwh verloren gegaan door RTE.

[ Voor 28% gewijzigd door Ellroe32 op 08-06-2025 00:16 ]

[badnews.nl]

Work in progress… nog lang niet af, maar ik ga proberen de lilygo marstek combi in een Homey app te zetten… ben druk, dus niet heel veel tijd helaas, maar eerste basis staat na een vrije dag gisteren

[Hometek]

SatScan schreef op zondag 8 juni 2025 @ 10:21:
[...]
Goedemorgen,

Vraagje tav Zonopwek via Solcast, hoe goed zijn de voorspellingen.
Ik gebruik zelf Solar Forecast maar die wijkt altijd behoorlijk af. De opbrengst is meestal flink hoger dan de voorspelling.

PS ondertussen overgeschakeld naar Solcast, ziet er nu al nauwkeuriger uit en ik kan dagen vooruit kijken.


hgr

Solcast is in mijn ervaring redelijk goed wat betreft de totale opwek over een dag, per uur kunnen er echter flinke verschillen zijn, vooral op dagen met grote, losse woken.
Erg handig vind ik de mogelijkheid om de waarden per uur te 'dempen', daarmee kan ik de schaduw van de bomen aan het einde van de middag op mijn panelen meenemen in de voorspelling.

Voorbeeld van een dag met wolken en opklaringen

[Hometek]

Mijn aansturing van Batterij & PV

Mijn redenen om een thuisbatterij te kopen zijn::

1. Leuk gadget/hobby
2. Meer flexibiliteit om verbruik/opwek aan te passen aan toekomstige regelgeving en energie aanbieders
3. Zelfvoorzienend bij stroomuitval
4. Misschien lagere maandelijkse lasten

ROI en actief handelen met de batterijen is voor mij niet relevant.
Het hoofddoel is het beheer van eigen opwek voor eigen gebruik.

Installatie:
7 stekkerpanelen met microinverters, 2.3 kWp
2 Marstek Venus batterijen, 9 kWh bruikbare capaciteit

Grootste verbruikers
1 kleine AC voor verwarming en koeling
1 EV die af en toe gedeeltelijk opgeladen wordt met laag vermogen

Ik heb naar diverse oplossingen zoals DAO en EMHASS gekeken, maar vond die aanpak te gedetailleerd. Ik heb liever een eenvoudig systeem dat alleen in grote lijnen rekening houdt met de invloeden van zon (opwek panelen) en buitentemperatuur (verbruik AC).

Ik ben nog bezig om een regeling in HA (Node-RED) op te zetten, maar hierbij alvast de strategie in hoofdlijnen:

• NOM regeling door Marstek Venus in ‘auto’ mode (zelfconsumptie)
• panelen 's avonds in/uit schakelen op basis van 24h prognose vraag en opwek
• verwachte vraag bepalen op basis van verwachte temperatuur
• als verwachte vraag hoger dan opwek dan batterij gedeeltelijk opladen bij laagste prijs
• steeds één batterij actief op auto, de andere manual (stand by)
• zodra SOC 99% forced charge naar 100%
• batterijwissel bij 30% en 100%
• na batterijwissel niet terug wisselen als andere batterij ook vol/leeg (hysterese 10%)
• 's avonds wisselen naar batterij met hoogste SOC

Een aantal van deze punten hebben te maken met het gezond houden van de batterijen:

• vaak naar 100% opladen voor balanceren cellen
• niet dagenlang op >90% laten staan

De 30% ondergrens is een reserve voor stroomuitval.

HA opzet
Aansturing batterijen via ESPHome/Lilygo/modbus
Voorspelling opwek volgende dag via Solcast integratie
Voorspelling temperatuur volgende dag via KNMI integratie
Goedkoopste uren stroom met Cheapest Energy Hours integratie
Slimme meter: Shelly Pro EM-50 icm B2500 meter integratie

Aan/uit schakelen zonnepanelen (na zonsondergang!) via slimme stekkers (outdoor versie).
Ik heb de 7 panelen in 3 groepen verdeeld zodat ik 8 stappen heb:



Het aantal benodigde panelen wordt berekend uit de verhouding verwachte vraag/opwek.

Verwachte vraag = gemiddeld verbruik + AC + batterij opladen naar 100%
Verwachte opwek = Solcast PV forcast tomorrow

Voorbeeld: vraag = 6 kWh, opwek = 9 kWh, verhouding 6/9 = 0.67
In dit geval wordt groep 3 ingeschakeld met 4 panelen (0.57)
Ik zou ook naar boven kunnen afronden en groepen 1+3 inschakelen met 5 panelen (0.71), maar op dit moment werk ik met afronden naar beneden.

Nog te doen:

• Opladen EV, ik ben nog aan het nadenken hoe ik dit wil doen, vanuit de batterij, of uitsluitend direct met opwek van de panelen, indien nodig aangevuld met stroom uit het net op de goedkoopste uren.
• Opladen batterijen op goedkoopste uren vanuit het net als er onvoldoende opwek verwacht wordt. Lastige hierbij is dat zonuren en goedkoopste uren soms samenvallen. Ik denk er over om dit op te lossen door een offset mee te geven aan de CT data voor de B2500 meter.

[Richardoe]

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:

[ Voor 4% gewijzigd door Richardoe op 10-06-2025 19:29 ]

[Richardoe]

superduper1969 schreef op dinsdag 10 juni 2025 @ 19:43:
[...]


En 1,48 keer je zwembad gevuld?

Met 16546 liter kun je ongeveer 1,48 zwembaden vullen, afhankelijk van de grootte van het zwembad.
Berekening:
Een gemiddeld zwembad in een Nederlandse tuin heeft een inhoud van ongeveer 11.170 liter. Als we 16546 liter delen door 11.170 liter, dan komt er ongeveer 1,48 uit. Dit betekent dat je met 16546 liter ongeveer 1,48 zwembaden kunt vullen.

Ik snap je vraag, maar nee een zwembad hebben we niet.

Ik kan het niet mooier maken, misschien had ik nog even moeten vermelden dat we ook nog een heel stel paarden hebben, (vandaar het schrikdraad) en ik heb geleerd dat je heel veel water moet drinken dat schijnt gezond te zijn. Dus dat samen maakt toch echt dit verbruik. Er zijn ook uren acher elkaar geen verbruik, het is dus geen lek ofzo,

Een volwassen paard drinkt normaal gesproken tussen de 20 en 40 liter water per dag, afhankelijk van zijn dieet, werk en buitentemperatuur. Sommige bronnen melden dat paarden in de weide, waar ze veel gras eten, tot wel 80 liter vocht per dag kunnen drinken.

Per dag laat het ook wel mooi zien:


en per dag van een dag:

[ Voor 7% gewijzigd door Richardoe op 10-06-2025 20:30 ]

[badnews.nl]

Ellroe32 schreef op woensdag 11 juni 2025 @ 00:06:
[...]


Ah leuk. Ben ik ook mee bezig. Kan niet echt programmeren doe alles met ai. Ik word er een beetje gek van. 😀

Ondertussen kan ik device aanmaken, worden de (belangrijkste) waardes uitgelezen en zichtbaar in nieuwe device.
Werkt op zich goed, alleen is ie nog niet zichtbaar als batterij in energy tab. Nergens ai voor hoeven gebruiken, heb teveel geprogrammeerd in mijn leven (en heb echt een hekel aan nodejs gekregen in 2 dagen tijd)
Zodra ik hem in energy tab krijg (iemand hints?) voeg ik de andeee waardes toe (dag, maand en jaaroverizhten, mode, laad standen) en zal ik hem eens beschikbaar stellen.
Ik vergeet mogelijk ergens een settings, want als ik hem als solar panel toevoeg, is deze gelijk zichtbaar in energy tab. Dus mogelijk een van de capabilities vergeten... maar welke

<never mind> gevonden, heb hem nu als 2e accu kunnen toevoegen. Nu de waardes updaten en fix voor verwijderen die invalid id gaat pollen...:)

[ Voor 12% gewijzigd door badnews.nl op 11-06-2025 08:58 ]

[badnews.nl]

Ik ben een stuk verder met de Marstek+Lilygo app.
Is er iemand die hem eventueel wil testen (dus al een lilygo heeft draaien, maar nog niet in Homey heeft) kan mij even pingen voor een test url voor de app (kan je altijd weer verwijderen als je het crap vindt )

Alleen lezen, dus ik wijzig niets met de app (doet GET commands op de ESPHome Lilygo device)

[ Voor 67% gewijzigd door badnews.nl op 12-06-2025 17:37 ]

[superduper1969]

Niet zozeer sturing, maar een handige Home Assistant /ESP-Home NOM monitor, in een 3D printje onder mijn Google Home.
Met een handige indicatie voor de energieprijs voor het huidige en volgende uur.



12 Led segmenten voor NOM(+/-50W = Blauw), Verbruik(Rood) en Terug levering (Groen)
Dynamische Led bar VU Energiemeter, logaritmische schaal -2500W tot +2500W (aanpasbaar)
Links en Rechts 3Leds segmenten voor Dynamisch contract Huidige Uur + Volgende Uur.
Rood = Duurder dan gemiddeld
Geel = Gemiddeld
Groen = Goedkoper dan gemiddeld
FEL WIT = Prijs onder 0 > Auto laden.
Prijzen haal ik uit Entso-e https://github.com/JaccoR/hass-entso-e

https://github.com/Superduper1969/EnergyMonitor/tree/main
Stukje afknippen van de Led strip, controller niet nodig.

Ik heb er 1 van 1 meter en hem afgegeknipt na 18 leds, als je de ledstrip met de bijgeleverde controller aanzet kun je makkelijk tellen voordat je knipt

Gooi de scripts in ChatGPT/Copilot, die geeft dan aan: wat een fantastische duidelijk code (geen wonder want het komt grotendeels uit ChatGPT) en geef aan wat je wil aanpassen.
De het deel van de aansturing van de Ledjes links en rechts doe ik nu nog met een simpele handmatige automatisering omdat ik het grootste deel al 3 jaar geleden had gedaan.

[ Voor 51% gewijzigd door superduper1969 op 14-06-2025 09:42 ]

[Hometek]

EV opladen

Aanvullend op mijn eerdere post heb ik nu ook het opladen van de EV in HA meegenomen.
Mijn situatie is niet erg gemiddeld, de EV wordt weinig gebruikt, kan dus op de beste momenten opgeladen worden en het is voldoende als per dag slechts gedeeltelijk wordt opgeladen.

Mijn doel is om de EV op te laden als er voldoende PV opwek is, of de stroomprijs laag is.
In beide gevallen wil ik niet dat er vermogen aan de Marstek Venus onttrokken wordt omdat ik dit voor andere apparaten wil gebruiken op momenten dat de stroomprijs hoog is.

Om de EV buiten de NOM regeling te houden heb ik het volgende gedaan:

• Marstek gekoppeld aan HA B2500 meter
• meten PV opwek (PV)
• meten EV laad vermogen (EV)
• meten vermogen van het net (CT)
• input B2500 meter:
  • als PV - EV >= 0 is input B2500 meter = CT
  • als PV - EV < 0 is input B2500 meter = CT + (PV - EV)

Dit zorgt er voor dat de EV uitsluitend met vermogen van PV en van het net wordt opgeladen
(Plug OD4 is de EV):



Automatisering opladen
Het opladen gebeurt automatisch als:

• de EV thuis is
• de EV is aangesloten aan de oplader
• de verwachte PV opwek voldoende is
• bij onvoldoende PV opwek bij de laagste stroomprijs gedurende 5 uur.

Gedurende de zomer is het overzichtelijk wat er gebeurt, de lage prijzen en de zonuren vallen samen. Ik weet nog niet of het in de herfst ook goed zal werken als de lage prijzen langzaam verplaatsen naar de nachtelijke uren.

[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.

[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')

[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 ]

[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)

[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 ]

[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.

[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.

[Verwijderd]

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 Verwijderd op 30-09-2025 19:38 ]

[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]

Het niet ontladen van de batterij als de stroomprijs lager is dan tijdens het opladen van het net maakt het voorspellen van de SOC een stuk complexer.
Op dit moment is de stroomprijs zolang laag dat de batterij meerdere dagen lang niet ontlaadt, pas morgenavond is er een korte piek:
(de groene lijn is de drempelwaarde, prijs tijdens opladen +25%)



Ik probeer nu het aantal uren dat de batterij niet zal ontladen mee te nemen in de SOC voorspelling. Daarnaast laat ik twee tellers bijhouden hoeveel stroom er van het net geladen wordt en hoeveel van PV. PV stroom mag namelijk wel ontladen worden bij een lage prijs.

[AUijtdehaag]

@antoinevromen
Het liefst hou je nog wat reserve in de batterij om de ochtendpiek te overbruggen.
Gisteravond heb ik iets teveel “gedumpt” a 48 ct, waardoor ik nu weer moet bijladen.

Vanavond is er weer een grote piek.
Afhankelijk van de zonopwek (solarcast ?) zou ik dan wel of niet moeten bijladen overdag.
Allemaal ideeen maar nog handwerk voor nu.

Het verschil tussen inkoop en verkoop moet 15 ct zijn ivm belastingen om interessant te zijn dacht ik

Ik waardeer je werk enorm maar ik blijf het liefste bij nodered voor de sturing.

[ Voor 11% gewijzigd door AUijtdehaag op 14-10-2025 04:19 ]

[superduper1969]

Vandaag mijn laadstrategie getest en het lijkt te werken.
Deze is wel afhankelijk van de goede werking van de AI mode.
Ik heb dit gemaakt voor 1 batterij deze staat op een eigen groep zodat ik ook 2500W kan terugleveren.

Het idee is alleen de Workmode aan te passen naar AI, NOM, Manual Mode.
Voor Manual Mode heb ik via de APP een schema gecreëerd om van 00:01 tot 23:59 terug te leveren met 2500W.

De helper zet de prijsdata van Zonneplan om naar een goedkoopste en duurste prijs van die dag.
Ik denk dat weersvoorspelling van zon en windenergie al aardig goed verwerkt zitten in het day ahead model.
Ik doe (nog) niets met de voorspelling van de volgende dag.

Resultaten zijn gunstig vandaag:



Helper om de hoogste en laagste prijs te bepalen:
zonneplanprijs.yaml

code:

template:
  - sensor:
      - name: "Goedkoopste uurprijs vandaag"
        state: >
          {% set forecast = state_attr('sensor.zonneplan_current_electricity_tariff', 'forecast') %}
          {% set vandaag = now().date() %}
          {% set vandaag_forecast = forecast | selectattr('datetime', 'search', vandaag|string) | list %}
          {% set goedkoopste = vandaag_forecast | sort(attribute='electricity_price') | first %}
          {{ (goedkoopste.electricity_price / 10000000) | round(3) }}
        unit_of_measurement: "€/kWh"
        device_class: monetary
        state_class: measurement

      - name: "Duurste uurprijs vandaag"
        state: >
          {% set forecast = state_attr('sensor.zonneplan_current_electricity_tariff', 'forecast') %}
          {% set vandaag = now().date() %}
          {% set vandaag_forecast = forecast | selectattr('datetime', 'search', vandaag|string) | list %}
          {% set duurste = vandaag_forecast | sort(attribute='electricity_price') | last %}
          {{ (duurste.electricity_price / 10000000) | round(3) }}
        unit_of_measurement: "€/kWh"
        device_class: monetary
        state_class: measurement

Automation:
Actie 1:
Kijken of er op die dag een moment is die rechtvaardigt om tegen 35 cent of meer terug te leveren via manual mode.
Actie 2:
Bij lagere prijzen naar AI of NOM met een drempel prijsverschil van 0.12 cent.

code:

alias: Moduskeuze op basis van stroomprijs en prijsverschil
triggers:
  - minutes: /5
    trigger: time_pattern
conditions: []
actions:
  - choose:
      - conditions:
          - condition: template
            value_template: >
              {{ states('sensor.zonneplan_current_electricity_tariff') | float >
              0.36 }}
        sequence:
          - target:
              entity_id: select.lilygo_rs485_marstek_user_work_mode
            data:
              option: manual
            action: select.select_option
      - conditions:
          - condition: template
            value_template: >
              {{ states('sensor.zonneplan_current_electricity_tariff') | float
              <= 0.36 }}
        sequence:
          - choose:
              - conditions:
                  - condition: template
                    value_template: >
                      {{ (states('sensor.duurste_uurprijs_vandaag') | float -
                      states('sensor.goedkoopste_uurprijs_vandaag') | float) >
                      0.12 }}
                sequence:
                  - target:
                      entity_id: select.lilygo_rs485_marstek_user_work_mode
                    data:
                      option: ai
                    action: select.select_option
              - conditions:
                  - condition: template
                    value_template: >
                      {{ (states('sensor.duurste_uurprijs_vandaag') | float -
                      states('sensor.goedkoopste_uurprijs_vandaag') | float) <=
                      0.12 }}
                sequence:
                  - target:
                      entity_id: select.lilygo_rs485_marstek_user_work_mode
                    data:
                      option: selfconsumption
                    action: select.select_option
mode: single

[ Voor 24% gewijzigd door superduper1969 op 15-10-2025 19:13 . Reden: Automation aangepast ]

[SatScan]

Om wat meer in HA bekwaam te worden heb ik deze POCs gebouwd met mijn persoonlijke gegevens.
Next step is om de dynamische energieprijs er aan te koppelen en dan parallel laten werken om te zien wat in mijn situatie het voordeligst is.

De vergelijking tussen statische en Dynamisch toegevoegd. De opslag voor beide gelijk aangehouden.
Op deze manier kan ik de komende maanden zien welk energiecontract het beste bij mij gaat passen irt de twee MT PIB. Tot nu toe is mijn huidige vaste prijs energiecontract het effectiefste met mijn energieprofiel.

[ Voor 31% gewijzigd door SatScan op 28-10-2025 08:44 ]

[Hometek]

JanAllElectric schreef op maandag 3 november 2025 @ 15:24:
[...]
Ik zat hier nog aan te denken:

Ik heb zelf wel eens gedacht aan een soort gewogen gemiddelde inkoopprijs bij het opladen bij te gaan houden.

Prijs PV is dan bv €0

Ik ben aan het experimenteren met zoiets: (kWhGRID / (kWhGrid+kWhPV) ) * inkoopprijs
Maar ben er nog niet helemaal uit.

Ik heb nu 7 tellers om opgeslagen kWh/prijs vast te leggen
(7 is vermoedelijk te veel, meestal zijn er maar 4-5 in gebruik)
Je ziet dat de batterij voor ca. 55% gevuld is met 4 verschillende prijzen (prijzen zijn incl. marge)


Deze grafiek toont de actuele prijzen. De groene en grijze lijnen zijn de prijsdrempels voor NOM. In dit geval dus minstens 48 uur geen NOM. Maar er is wel een gelegenheid om vannacht de resterende 45% capaciteit met goedkopere stroom aan te vullen en die stroom dan wel morgen voor NOM te gebruiken.

[SatScan]

Zo nu weer flinke stappen gemaakt met HA, Hier een voorbeeld. De DB is zich nu aan het vullen en over een tijdje heb ik een actueel beeld met voorspellingen die elke dag nauwkeuriger worden.

[Mattie112]

Het was even klooien om alles geinstalleerd te krijgen (vooral: in welke mappen van HA moet ja alles zetten en hoe werkt NodeRed). Maar ik heb de boel nu draaien. Ben heel benieuwd. Tijdje "AI" modus gedraaid maar dat sloeg echt nergens op. Opladen met €0,20 en 'verkopen' (of NOM) met €0,21. Ja doei! Toen een tijd lang NOM maar met het weer nu kunnen ze zomaar 'vol' zitten of juist leeg zijn terwijl de stroom wel duur is dus dan lijkt het me interessant als dit wat slimmer te regelen is.

Ik wil dus ook draag de 'dynamic' strategie gebruiken. Maar ik weet niet of ik het nou correct heb.

Wat heb ik geinstalleerd:
- https://github.com/TheFes/cheapest-energy-hours/
- https://github.com/HiDiHo01/home-assistant-frank_energie

In de documentatie van 'cheapest hours' staat:

code:

These parameters are used to determine where the source data can be found. If you use the custom Nordpool integration (can be downloaded using HACS), or an integration which uses the same attributes, you don't need to provide any of the parameters, but it is advised to provide the sensor as it will be more resource friendly if the macro doesn't need to search for it.

Ik begrijp dat dit anders is dan de 'normale' (niet HACS) Nordpool integratie? Maar heb ik die nou wel of niet nodig? Op het dashboard kies in namelijk niet voor Nordpool maar voor Frank.



Of ben ik te ongeduldig en duurt het even voordat dit goed staat?