Marstek PIB Domotica integratie en je Energierekening

[SatScan]

15-06-2025 - WORK IN PROGRESS

Waarom dit Topic?

De komende periode en misschien wel jaren zal de energiemarkt in België en Nederland flink in beweging zijn.
Bijvoorbeeld In België worden de eerste goedkeuringen van de zo geheten Plug In Batterijen (PIB) verwacht. Daarna is de verwachting dat er een grote interesse zal ontstaan in dit soort oplossingen om je energieverbruik en de daaraan gekoppelde energierekening in toom te houden.

In Nederland wordt bijvoorbeeld de salderingsregeling per 1 jan 2027 afgeschaft. De verwachting is dat de huidige energiecontracten hierdoor zullen veranderen. Ook hier zal naar verwachting de thuisbatterij een grote rol gaan vervullen om tijdens de dure energie uren het inkopen van energie te verminderen of geheel te voorkomen.

Tijdelijke energieopslag bied ook mogelijkheden om te gaan handelen met energie of hoe laad ik mijn EV op een zo’n voordelige manier. En hoe schakel ik mijn warmtepomp of andere energieverbruikers slim met mijn Marstek batterij(en)
In dit topic volgen we deze ontwikkelingen op de voet en dat in relatie tot het gebruik van de Marstek thuisbatterij(en).
.

Doel van dit topic?

We lezen graag welke strategieën jij gebruikt en welke domotica oplossing(en) jij hanteert.
Welke energiecontract contract past het beste in jou situatie met jouw Marstek energieopslagsysteem. Hoe integreer je slim je diverse energiesystemen met elkaar. Waar moet je op letten en wat komt erbij kijken om je huis met deze Marstek batterijen slimmer te maken.
.

Hoe dit Topic te gebruiken?

In dit topic willen we dus graag met elkaar op zoek naar passende oplossingen, door praktijkervaringen en voorbeelden te delen.
Het delen van je code wordt zeer gewaardeerd, het zou fijn zijn als daar de code tag voor gebruikt.
Als het meer dan pakweg 20 regels zijn, wordt het erg gewaardeerd als je het ook in een quote zet

code:

Regel 1
Andere regel
Goto 1

En als je wil reageren op een stukje code kan je met line= het beginnummer aanpassen:[code line=9]
Zie ook ook de UBB-codes

Om een slimme strategie te kunnen bepalen is het handig om gebruik te maken van de energieprijzen uit het verleden. Deze kun je hier terug vinden;
https://jeroen.nl/dynamis...20prijs,00%20en%2015%3A00


Links naar andere Marstek / Duravolt Venus Batterij topics
Hame / Marstek / Duravolt 5,12kWh plug en play thuisaccu
Marstek / Duravolt Venus PnP Thuisaccu gebruiken als backup
Plug & Play wetgeving Belgie - Van het kastje naar de muur
Marstek Venus / Duravolt PnP Thuisaccu Modbus koppeling
Hoe zat dat toch ook alweer...
Het grote topic voor Elektra huisinstallaties - Deel 3
.

Topic regels

Wat we graag lezen
Het delen van je domotica code voor je strategie en oplossing
Dat je daar de code tag voor gebruikt
Je ervaringen van je gehanteerde oplossing
Bij welk type energiecontract de beste gebruikers-strategie past
Dat je je signatuur vult met relevantie informatie bijvoorbeeld of


Wat we minder graag lezen
Hoe je bijvoorbeeld Home Assist installeert

Wat er niet in thuishoort
Hoe je een batterij installeert
Hoe je bijvoorbeeld een lilygo installeert
Waar de andere Marstek topics voor zijn
JIJ bakken!

Disclaimer
blabla chocoladevla...

[ Voor 85% gewijzigd door SatScan op 15-06-2025 12:31 ]

[PNARI]

Mijn strategie voor Vlaanderen en mijn gebruikersprofiel en installatie :
Zoveel mogelijk eigen zonneproductie gebruiken en opslaan.
Opslag 2x 5.12 kWh MT batterij met effectieve opslag van 9 kWh en daarbij RTE van 75 % en 2500W ontladen. Daarnaast een electrische boiler van 150l voor 2 personen en 3000W verwarmingselement die overtollige zonneelectriciteit gebruikt vanaf 1500W injectie, dan helpen de batterijen 1500W bij. ' s Morgens beginnen batterijen volgens NOM te laden. Die geraken dus eerst bijna vol tot er meer dan 1500W injectie is, dan begint de boiler op te warmen en helpen de batterijen. Uiteraard alles met mijn gebruiksprofiel. Wanneer mijn stookolieketel versleten is zal ik twee opties overwegen : warmtepomp of hybride gasketel. Met 9kWh batterijen kan een hybrideketel in de tussenseizoenen interessant zijn. Alles hangt af van wat er aan extra taken op fossiele brandstoffen komt in de toekomst, zowel voor verwarming als transport.

[gielvd]

Mijn strategie in belgie (vast contract, terugleververgoeding 2ct, prijs kwh (incl belasting) 26ct):

Indien er overschot is (in deze volgorde):
- 1 Marstek 5.12kwh (NOM)
- Zwembadpomp aan indien 800W over (verbruikt 700W)
- Boiler aan indien 1200W over (verbruikt 1200W)

Boiler:
Ik heb de boiler aansturing gehad die met een variabel vermogen werkt op basis van een M240. Nadat ik 2x een M240 ondanks grote koelvin kapot zijn gegaan heb ik dit vervangen door een simpele shelly stopcontact. Eigenlijk wil ik de boiler voorrang geven aan de zwembadpomp maar door het hogere inschakelvermogen van de boiler werkt dat niet lekker. Dat is een van de reden dat ik de boiler weer variabel aanstuurbaar wil maken met een SSR en een shelly 0-10v. Dit werkt ook beter in voorjaar als het overschot niet vaak genoeg boven de 1200W komt. Wordt nog wel een uitdaging om dit stabiel te krijgen in combinatie met de marstek.Ik wil dat de marstek voorrang krijgt op de boiler. Mijn enige idee is dat de boiler minder agressief/snel vermogen opbouwt dan de marstek, en indien tekort heel snel terugschakeld. Maar hier heb ik nog geen ervaring mee.
Indien de boiler temperatuur te laag wordt, schakeld de CV op mazout bij. Maar in de zomer staat die uit.

Zwembadpomp:
Ik heb ook nog een frequentie regelaar op mijn zwembadpomp. Hiermee kan ik het vermogen lager zetten om het verbruik te verkleinen. Maar met de lage terugleverkosten en het alleen aanzetten bij overschot is dit eigenlijk overbodig.

Aansturing:
Ik stuur alles aan vanuit een python script dat op mijn NAS draait. Dus geen afhankelijkheid van mijn home-assistent. Ik vind het belangrijk dat dit essentiele stuk logica gewoon altijd blijft werken. Ik wil dit python script verhuizen naar een esp32 C3 waar micropython op draait. Ik verwacht dat het daardoor nog onafhankelijker wordt.

Wat ik graag zou willen is 'peak-shaving' om de piekbelasting die we in belgie hebben te reduceren. In de winter wanneer de marstek veel minder effectief gebruikt kan worden door afwezigheid van zon zou de batterij in een modus kunnen staan waarbij boven X kw gebruik van grid de batterij ontlaad, en onder Y kw gebruik van grid de batterij oplaadt. Volgens mij moet het zelfs mogelijk zijn om die X en Y threshold dynamisch te laten bepalen doordat de batterij ziet dat hij voor een bepaalde periode niet helemaal vol raakt, of te vaak helemaal vol is.

[PNARI]

gielvd schreef op vrijdag 6 juni 2025 @ 21:41:
Mijn strategie in belgie (vast contract, terugleververgoeding 2ct, prijs kwh (incl belasting) 26ct):

Indien er overschot is (in deze volgorde):
- 1 Marstek 5.12kwh (NOM)
- Zwembadpomp aan indien 800W over (verbruikt 700W)
- Boiler aan indien 1200W over (verbruikt 1200W)

Boiler:
Ik heb de boiler aansturing gehad die met een variabel vermogen werkt op basis van een M240. Nadat ik 2x een M240 ondanks grote koelvin kapot zijn gegaan heb ik dit vervangen door een simpele shelly stopcontact. Eigenlijk wil ik de boiler voorrang geven aan de zwembadpomp maar door het hogere inschakelvermogen van de boiler werkt dat niet lekker. Dat is een van de reden dat ik de boiler weer variabel aanstuurbaar wil maken met een SSR en een shelly 0-10v. Dit werkt ook beter in voorjaar als het overschot niet vaak genoeg boven de 1200W komt. Wordt nog wel een uitdaging om dit stabiel te krijgen in combinatie met de marstek.Ik wil dat de marstek voorrang krijgt op de boiler. Mijn enige idee is dat de boiler minder agressief/snel vermogen opbouwt dan de marstek, en indien tekort heel snel terugschakeld. Maar hier heb ik nog geen ervaring mee.
Indien de boiler temperatuur te laag wordt, schakeld de CV op mazout bij. Maar in de zomer staat die uit.

Zwembadpomp:
Ik heb ook nog een frequentie regelaar op mijn zwembadpomp. Hiermee kan ik het vermogen lager zetten om het verbruik te verkleinen. Maar met de lage terugleverkosten en het alleen aanzetten bij overschot is dit eigenlijk overbodig.

Aansturing:
Ik stuur alles aan vanuit een python script dat op mijn NAS draait. Dus geen afhankelijkheid van mijn home-assistent. Ik vind het belangrijk dat dit essentiele stuk logica gewoon altijd blijft werken. Ik wil dit python script verhuizen naar een esp32 C3 waar micropython op draait. Ik verwacht dat het daardoor nog onafhankelijker wordt.

Wat ik graag zou willen is 'peak-shaving' om de piekbelasting die we in belgie hebben te reduceren. In de winter wanneer de marstek veel minder effectief gebruikt kan worden door afwezigheid van zon zou de batterij in een modus kunnen staan waarbij boven X kw gebruik van grid de batterij ontlaad, en onder Y kw gebruik van grid de batterij oplaadt. Volgens mij moet het zelfs mogelijk zijn om die X en Y threshold dynamisch te laten bepalen doordat de batterij ziet dat hij voor een bepaalde periode niet helemaal vol raakt, of te vaak helemaal vol is.

Bij wie krijg je vast 2ct voor teruglevering ? En zijn de 26ct incl alle kosten en accijnzen ?

[Avenger 2.0]

Momenteel 1 Marstek in gebruik, vooral om nachtverbruik te dekken en door de dag en in avond bij te leveren. Monitoring met HomeWizard Energy Display en Energy Plugs en ook om de WAF te vergroten
- Voorlopig via HW Energy Plug ook integratie in Homey Domotica systeem (Energy Tab), samen met P1 meter en PV panelen. Hopelijk in de toekomst een app in Homey zodat ik ook de batterijstaat kan zien (hoeveel geladen) en eventueel kan sturen.
- Warmtepomp en aangesloten boilervat zijn de grootverbruikers. Spijtig genoeg weinig sturing mogelijk behalve tijdsgestuurd. Boilervat laat ik in de vroege namiddag verwarmen zodat de Marstek reeds bijgeladen is om te helpen en nadien ook nog terug kan laden voor de avond/nacht. Maar gezien grote verbruik verwarming vooral in de wintermaanden is (en dan weinig zon) en de andere seizoenen andersom zal de batterij hiervoor weinig helpen.
- Elektrische handdoekradiator om badkamer te verwarmen voorzien van HW Plug om te meten en te regelen. Al verwacht ik van dat regelen niet al te veel (als er weinig zon is zal deze namelijk vooral moeten verwarmen).
- Bij toekomstige EV aan het denken om dan eventueel 2de batterij te kopen zodat bij zon in late namiddag deze kan helpen om aan minimale oplaadstroom te geraken ipv van het net moeten te halen. Maar zal ook wat afhangen van (nieuwe komende) regelgeving in België en wat nog mag en niet.

[gielvd]

PNARI schreef op zaterdag 7 juni 2025 @ 00:16:
[...]

Bij wie krijg je vast 2ct voor teruglevering ? En zijn de 26ct incl alle kosten en accijnzen ?

Ecopower

[JanAllElectric]

Ik heb voor mijn 3 Marsteks (op 1 groep aangesloten) geprobeerd een verdeelfunctie te maken om het gewenste vermogen (TargetPower) te verdelen over de 3 accu's, rekening houdend met de ingestelde waarden max(ont)laden per accu.

Op 1 groep is TargetPower natuurlijk maximaal 3600W. Per Marsteks is max(ont)laden 2500W.
NB: moet ook voor 3 marsteks werken ieder op eigen groep aangesloten: TargetPower dan bv max 7500W.

NB: ik heb chatGPT gevraagd de verdeelfunctie compact te maken. Helaas komt dat niet ten goede aan de leesbaarheid.

Door met beide waarden te "spelen" kan je de verdeelfunctie goed laten werken:

******************************************************
//targetPower bepalen
if (status.beslissing == "kopen" || status.beslissing == 'bijkopen') { charge_discharge = 'charge'; targetPower = targetPowerLaden }
if (status.beslissing == "verkopen" ) { charge_discharge = 'discharge'; targetPower = targetPowerOntladen }
if (status.beslissing == 'NOM' || status.beslissing == 'NOM+' || status.beslissing == 'NOM-'){
if (hoofdmeter <= 0 ){
targetPower = Math.min(targetPowerLaden, -1 * hoofdmeter);
charge_discharge = 'charge'
if (status.beslissing == 'NOM-') { targetPower = 0 }
} else {
targetPower = Math.min(targetPowerOntladen, hoofdmeter);
charge_discharge = 'discharge'
if (status.beslissing == 'NOM+') { targetPower = 0 }
}
}
if (status.beslissing == 'geen actie'){ charge_discharge = 'charge'; targetPower = 0 }

**************************************************************
Volgens mij is sequentieel de accu's (ont)laden efficienter dan parallel:

****************************************************************
//** zorgt ervoor dat eerste de 1e accu optimaal (met maxontladen vermogen) wordt geladen/ontladen en daarna de 2e met het restvermogen tot targetpower*/
//** met bv vermogen_laden/ontladen = targetPower/3 worden beide accu's gelijkmatig geladen/ontladen */
for (let i = 0; i < aantal_accus; i++) {

//vermogen (ont)laden bepalen
Marstek[i].vermogen_ontladen = (Marstek[i].vulgraad <= Marstek[i].minimum_level ? 0 : Marstek_vermogen_ontladen_max);
Marstek[i].vermogen_laden = (Marstek[i].vulgraad >= Marstek[i].inhoud ? 0 : Marstek_vermogen_laden_max);

//** correcties */
//bij >95% SOC wordt Marstek_vermogen_laden_max getrottled tot 1200W
Marstek[i].vermogen_laden = (Marstek[i].soc >= 95 && Marstek[i].vermogen_laden > 1200 ? 1200 : Marstek[i].vermogen_laden);
//bij <15% SOC wordt Marstek_vermogen_ontladen_max getrottled tot 1200W
Marstek[i].vermogen_ontladen = (Marstek[i].soc <= 15 && Marstek[i].vermogen_ontladen > 1200 ? 1200 : Marstek[i].vermogen_ontladen);
}

*************************************************
aanroep van de verdeelfunctie
************************************************
//** Functie aanroep distributieplan met verdeling targetPower: laden/ontladen per accu, remaining power en buy/sell */
//** Houdt rekening met XOM en reserveGridPower */
var batteries = [];
for (let i = 0; i < aantal_accus; i++){
batteries.push({ id:i, maxCharge: Marstek[i].vermogen_laden, maxDischarge: Marstek[i].vermogen_ontladen, soc: Marstek[i].soc
}

var plan = distributePower(batteries, targetPower, hoofdmeter, charge_discharge, xom_level1, xom_level2, reserveGridPower);


*****************************************
verdeelfunctie. naast verdelen van targetpower of de 3 accu's zijn er andere dingen "ingeslopen""
- corrigeren voor resevegrid (bv om EV laden buiten de accu te houden)
- wisselen van de primaire accu als het verschil Soc 10% is
- nomlevel1: indien gevraagde power van een accu <= nomlevel1 is dan corrigeren naar 0 (bv <100W)
- nomlevel 2: indien gevraagde poer per accu > nomlevel1 en <= nomlevel2 is dat corrigeren naar nomlevel2 (bv 200W)
- bijhouden buy/sell van grid in dien targetpower niet geleverd kan worden

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

// Reserveer een deel van het netvermogen voor bv autoladen
let adjustedTargetPower = targetPower - reserveGridPower;
adjustedTargetPower = (adjustedTargetPower < 0 ? 0 : adjustedTargetPower);
targetPower = (mode === 'charge' ? targetPower : adjustedTargetPower);

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, xom: 'power', soc: battery.soc );

//***************** Sorteer de accu's op maximale SOC bij ontladen en minimale SOC bij laden als verschil 10% is *****************//
const getActiveBattery = (batteries, mode, delta, last) => {
// Werk SOC, maxCharge en MaxDischarge van vorige volgorde bij met actuele waarden.
const updatedLast = last.map(b => {const fresh = batteries.find(c => c.id === b.id); return fresh ? { ...b, ...fresh } : b; });
const sorted = [...batteries].sort((a, b) => mode === 'charge' ? a.soc - b.soc : b.soc - a.soc);
const diff = Math.abs((updatedLast[0]?.soc ?? 0) - (updatedLast[1]?.soc ?? 0));
const useNewOrder = !last.length || diff >= delta;
const order = useNewOrder ? sorted : updatedLast;

context.set('Test', { diff: diff, useneworder: useNewOrder });

return { activeAccu: order[0].id, mode: mode, order };
};

let lastFlow = flow.get('Last');
let last = (lastFlow && lastFlow.order) ? lastFlow.order : []; //vorige volgorde en actieve accu
last = getActiveBattery(batteries, charge_discharge, 10, last);
batteries = last.order;
flow.set('Last',last);

// verdelen beschikbaar vermogen over de accu's
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);

let j = battery.id; //vul power in juiste accu (powerPlan heeft normale volgeorde 0,1,2)
maxPossible = maxPossible;
powerPlan[j].power = maxPossible;
totalAvailable -= maxPossible;
}

// level1: zorgt ervoor dat vermogen 0W is (idle < 80% efficiency)
// Level2: Zorg dat elk vermogen minstens 300W is (XOM > 85/90% efficiency )
powerPlan = powerPlan.map(p => ({
battery: p.battery,
power: p.power != 0 && p.power < xomL2 ? (p.power < xomL1 ? 0 : xomL2) : p.power,
xom: p.power != 0 && p.power < xomL2 ? (p.power < xomL1 ? 'XOM0' : 'XOM'+xomL2) : p.xom,
soc: p.soc
);

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

//sorteer de accus op battery (=id) //waarschijnlijk niet nodig
powerPlan.sort((a, b) => a.battery - b.battery);

// 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};
}

[JanAllElectric]

hmm:

Het gaat meer over de gehanteerde strategie zie ik.

Mijn strategie is:
- zoveel mogelijk eigen PV opbrengst in de accu opslaan en als NOM gebruiken voor de rest van de dag.
- het laden van de EV buiten de accu te houden.
- bijkopen als PV opbrengst onvoldoende is en prijslevel laag.
- Verkopen doe ik in principe niet. Daar is 15kWh accucapaciteit voor mij te klein voor. Mijn verbruik tussen 18:00 en 10:00 is in de zomer ca 12-13kWh (sluipverbruik >500W) en in de winter >15 kWh (warmtepomp)

Ik heb NOM nog verbijzonderd met:
- NOM+: ontladen voor zelfgebruik blokkeren als prijs laag is -> Grid kopen is goedkoper
- NOM-: laden voor zelfgebruik blokkeren als prijs hoog is -> PV terugleveren levert meer op

Hoog is voor mij prijs >= 115% gemiddelde prijs
Laag is voor mij prijs <= 90% gemjddelde prijs
NB: ik heb ook wel met werkelijk marges gewerkt, maar deze vuistregel is veel eenvoudiger en werkt ook goed.

Bij een gemiddelde prijs van € 0,25 is dan de spread koop-verkoop minimaal € 0,06. Net voldoende om afschrijving en RTE-verlies te dekken. In de praktijk is de spread beter omdat je de prijs van PV op € 0,00 kan stellen.

Omdat mijn sluipverbruik hoog is blijkt in mei mijn RTE rondt 85% te liggen. Deels komt dat ook omdat ik de vraag (per accu) <100W op 0 stel en tussen 100W en 200W op 200W. Dat komt de efficiency te goede.

[ Voor 37% gewijzigd door JanAllElectric op 07-06-2025 13:25 ]

[SatScan]

JanAllElectric schreef op zaterdag 7 juni 2025 @ 12:52:
hmm:

Het gaat meer over de gehanteerde strategie zie ik.

Mijn strategie is:
- zoveel mogelijk eigen PV opbrengst in de accu opslaan en als NOM gebruiken voor de rest van de dag.
- het laden van de EV buiten de accu te houden.
- bijkopen als PV opbrengst onvoldoende is en prijslevel laag.
- Verkopen doe ik in principe niet. Daar is 15kWh accucapaciteit voor mij te klein voor. Mijn verbruik tussen 18:00 en 10:00 is in de zomer ca 12-13kWh (sluipverbruik >500W) en in de winter >15 kWh (warmtepomp)

Ik heb NOM nog verbijzonderd met:
- NOM+: ontladen voor zelfgebruik blokkeren als prijs laag is -> Grid kopen is goedkoper
- NOM-: laden voor zelfgebruik blokkeren als prijs hoog is -> PV terugleveren levert meer op

Hoog is voor mij prijs >= 115% gemiddelde prijs
Laag is voor mij prijs <= 90% gemjddelde prijs
NB: ik heb ook wel met werkelijk marges gewerkt, maar deze vuistregel is veel eenvoudiger en werkt ook goed.

Bij een gemiddelde prijs van € 0,25 is dan de spread koop-verkoop minimaal € 0,06. Net voldoende om afschrijving en RTE-verlies te dekken. In de praktijk is de spread beter omdat je de prijs van PV op € 0,00 kan stellen.

Omdat mijn sluipverbruik hoog is blijkt in mei mijn RTE rondt 85% te liggen. Deels komt dat ook omdat ik de vraag (per accu) <100W op 0 stel en tussen 100W en 200W op 200W. Dat komt de efficiency te goede.

Niet helemaal, het is een combinatie van Strategie en de Coding die je gebruikt!
Strategie is leerzaam om te lezen maar uiteindelijk gaat het om de achterliggende coding die de strategie effectueert. Keep going

Misschien weet iemand of we de coding ergens kunnen plaatsen en dan kunnen we daar naar verwijzen in de berichten. Dat helpt wel met de leesbaarheid.

[ Voor 4% gewijzigd door SatScan op 07-06-2025 13:41 ]

[JanAllElectric]

SatScan schreef op zaterdag 7 juni 2025 @ 13:37:
[...]


.....

Misschien weet iemand of we de coding ergens kunnen plaatsen en dan kunnen we daar naar verwijzen in de berichten. Dat helpt wel met de leesbaarheid.

en chatgpt even vragen de boel weer normaal leesbaar te maken Ik kom zelf nog uit het gewone if then else programmeertijdperk

chatgpt:
De stijl of notatie die je bedoelt heet meestal:

Arrow function → =>
Dit is de ES6 (ECMAScript 2015) "arrow function syntax".

Ternary operator → condition ? valueIfTrue : valueIfFalse
→ "ternaire operator", voor compacte if-else in één regel.

Optional chaining → ?.
→ voorkomt errors bij undefined objecten.

Nullish coalescing operator → ??
→ gebruik fallback-waarde als links null of undefined is.

De .map() functie is nog een belangrijk onderdeel.

👉 Array.prototype.map() is in JavaScript een standaard array-methode die je kunt gebruiken om elke waarde in een array te transformeren naar een nieuwe array.

👉 Het is een functionele programmeerstijl. Je geeft een functie op die op elk element wordt toegepast. De uitkomst is een nieuwe array (de originele array blijft ongewijzigd).

[ Voor 22% gewijzigd door JanAllElectric op 07-06-2025 14:00 ]

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

Ik heb het zo gedaan: https://community.homey.a...135927/24?u=roedi_de_lion

Is niet vanuit de batterij maar vanuit de HW socket. Misschien nog wel nauwkeuriger?

[ Voor 28% gewijzigd door Ellroe32 op 07-06-2025 21:47 ]

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

[Ellroe32]

Ik heb een dynamische contract, woon in NL, Shelly P1 simulator en heb 1 Marstek 5.12 kwh batterij.

Mijn strategie is in principe opladen op de twee goedkoopste uren en verkopen op de twee duurste uren. Indien mogelijk 2x per dag (nog niet voorgekomen).

Wanneer er voldoende zon is, sla ik de laadcyclus over. (niet voordelig, wel leuk). Bij deze variant stopt de batterij wel met NOM als de SOC onder 98% daalt. (Hij kijkt hier dus of er 4,56kwh-SOC meer zon s dan verbruik tot aan de ontlaadcyclus)

Waar houd ik rekening mee:

• Zonopwek via Solcast
• Eigen verbruik (houdt ik bij per uur, en wordt bijgewerkt)
• Wanneer het tweede laad-uur goedkoper is dan de eerste, laad ik het eerste uur met minder vermogen (ook bij ontladen)
• (Ont)Laadvermogen houdt ook rekening met de SOC van de batterij
• RTE (afhankelijk van vermogen, maar kiest eigenlijk altijd voor 2500W)

[ Voor 5% gewijzigd door Ellroe32 op 07-06-2025 22:10 ]

[Ellroe32]

JanAllElectric schreef op zaterdag 7 juni 2025 @ 12:52:
hmm:

Ik heb NOM nog verbijzonderd met:
- NOM+: ontladen voor zelfgebruik blokkeren als prijs laag is -> Grid kopen is goedkoper
- NOM-: laden voor zelfgebruik blokkeren als prijs hoog is -> PV terugleveren levert meer op

Hoog is voor mij prijs >= 115% gemiddelde prijs
Laag is voor mij prijs <= 90% gemjddelde prijs
NB: ik heb ook wel met werkelijk marges gewerkt, maar deze vuistregel is veel eenvoudiger en werkt ook goed.

Dit is nog wel interessant. Zelf had ik nog bedacht dat ik een berekening ga maken dat ik de kWh's in de batterij ga verdelen over de duurste uren, totaan de zonopwek mijn batterij weer gaat laden.

[badnews.nl]

Ellroe32 schreef op zaterdag 7 juni 2025 @ 21:49:
[...]


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

Klopt, echter geeft mijn Solis app dus de opgewekte energie niet goed door. Ik heb vanmorgen een virtual zonnepaneel aangemaakt die gevoed wordt door de Solis app, ik ga kijken of dat stuk dan beter klopt.
Ik denk zelfs dat de modbus precieser is dan de HW socket die jij gebruikt, aangezien alle in en outs op de accu gemeten worden. Er is altijd een paar procent onprecisie met een socket meter..
Ik ga eens kijken of het vandaag beter klopt, mistte de eerste paar honderd wh, omdat de zon al scheen toen ik wakker werd..

[Ellroe32]

badnews.nl schreef op zondag 8 juni 2025 @ 09:03:
[...]

Klopt, echter geeft mijn Solis app dus de opgewekte energie niet goed door. Ik heb vanmorgen een virtual zonnepaneel aangemaakt die gevoed wordt door de Solis app, ik ga kijken of dat stuk dan beter klopt.
Ik denk zelfs dat de modbus precieser is dan de HW socket die jij gebruikt, aangezien alle in en outs op de accu gemeten worden. Er is altijd een paar procent onprecisie met een socket meter..
Ik ga eens kijken of het vandaag beter klopt, mistte de eerste paar honderd wh, omdat de zon al scheen toen ik wakker werd..

Ik ben net zo aan het stoeien. Soms denk je dat je er bent…. En dan toch weer niet. 😀

[SatScan]

Ellroe32 schreef op zaterdag 7 juni 2025 @ 22:06:
Ik heb een dynamische contract, woon in NL, Shelly P1 simulator en heb 1 Marstek 5.12 kwh batterij.

Mijn strategie is in principe opladen op de twee goedkoopste uren en verkopen op de twee duurste uren. Indien mogelijk 2x per dag (nog niet voorgekomen).

Wanneer er voldoende zon is, sla ik de laadcyclus over. (niet voordelig, wel leuk). Bij deze variant stopt de batterij wel met NOM als de SOC onder 98% daalt. (Hij kijkt hier dus of er 4,56kwh-SOC meer zon s dan verbruik tot aan de ontlaadcyclus)

Waar houd ik rekening mee:

• Zonopwek via Solcast
• Eigen verbruik (houdt ik bij per uur, en wordt bijgewerkt)
• Wanneer het tweede laad-uur goedkoper is dan de eerste, laad ik het eerste uur met minder vermogen (ook bij ontladen)
• (Ont)Laadvermogen houdt ook rekening met de SOC van de batterij
• RTE (afhankelijk van vermogen, maar kiest eigenlijk altijd voor 2500W)

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

[ Voor 4% gewijzigd door SatScan op 09-06-2025 09:15 ]

[Ellroe32]

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.

hgr

Mijn ervaringen zijn echt heel goed. Heb ook eens forecast geprobeerd, maar die viel idd tegen. Ik gebruik zelf nu dit script en leg het vast in een variabale:

code:

// === CONFIG ===
const apiKey = '1234abc';
const rooftopResourceId = 'r761253';
const url = `https://api.solcast.com.au/rooftop_sites/${rooftopResourceId}/forecasts?format=json`;

// === SCRIPT START ===
async function haalZonVoorspellingEnBewaar() {
  try {
    const response = await fetch(url, {
      method: 'GET',
      headers: {
        'Authorization': `Bearer ${apiKey}`,
        'Accept': 'application/json'
      }
    });

    if (!response.ok) {
      throw new Error(`HTTP error! Status: ${response.status}`);
    }

    const data = await response.json();
    const forecasts = data.forecasts;
    const nu = new Date();

    let zonPerUur = {};

    forecasts.forEach(entry => {
      const tijd = new Date(entry.period_end);
      const lokaalTijdstip = new Date(tijd.getTime() + (new Date().getTimezoneOffset() * 60000));
      const key = lokaalTijdstip.toISOString().slice(0, 13); // bv. "2025-05-24T15"
      const kWh = entry.pv_estimate * 0.5; // elk blok is 30 minuten

      if (!zonPerUur[key]) zonPerUur[key] = 0;
      zonPerUur[key] += kWh;
    });

    const jsonString = JSON.stringify(zonPerUur);

    // 🔁 Logica variabelen ophalen en bijwerken
    const alleVariabelen = await Homey.logic.getVariables();
    let varObj = Object.values(alleVariabelen).find(v => v.name === 'zon_per_uur_json');

    if (!varObj) {
      varObj = await Homey.logic.createVariable({
        name: 'zon_per_uur_json',
        type: 'string',
        value: jsonString
      });
      console.log(`✅ Variabele aangemaakt: zon_per_uur_json`);
    } else {
      await Homey.logic.updateVariable({
        id: varObj.id,
        variable: { value: jsonString }
      });
      console.log(`✏️ zon_per_uur_json bijgewerkt (${Object.keys(zonPerUur).length} uren)`);
    }

    return zonPerUur;

  } catch (error) {
    console.error('❌ Fout bij ophalen of opslaan Solcast data:', error);
  }
}

// Start de functie
haalZonVoorspellingEnBewaar();

[ Voor 71% gewijzigd door Ellroe32 op 08-06-2025 15:53 ]

[JanAllElectric]

JanAllElectric schreef op zaterdag 7 juni 2025 @ 12:05:
Ik heb voor mijn 3 Marsteks (op 1 groep aangesloten) geprobeerd een verdeelfunctie te maken om het gewenste vermogen (TargetPower) te verdelen over de 3 accu's, rekening houdend met de ingestelde waarden max(ont)laden per accu.

Mocht iemand de verdeelfunctie willen gebruiken. Ik heb er nog een fout uitgehaald bij het verwerken van de reserveGridPower:

code:

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

    // Reserveer een deel van het netvermogen voor bv autoladen
    let adjustedTargetPower = gridPower - reserveGridPower;
    adjustedTargetPower = Math.min(targetPower,Math.max(0, adjustedTargetPower))
    targetPower = (mode === 'charge' ? targetPower : adjustedTargetPower);

    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, xom: 'power', soc: battery.soc }));

    //Sorteer de accu's op maximale SOC bij ontladen en minimale SOC bij laden als verschil 10% is 
    const getActiveBattery = (batteries, mode, delta, last) => {
        // Werk  SOC, maxCharge en MaxDischarge van vorige volgorde bij met actuele waarden.
        const updatedLast = last.map(b => {const fresh = batteries.find(c => c.id === b.id); return fresh ? { ...b, ...fresh } : b; });
        const sorted = [...batteries].sort((a, b) => mode === 'charge' ? a.soc - b.soc : b.soc - a.soc);
        const diff = Math.abs((updatedLast[0]?.soc ?? 0) - (updatedLast[1]?.soc ?? 0));
        const useNewOrder = !last.length || diff >= delta;
        const order = useNewOrder ? sorted : updatedLast;
        return { activeAccu: order[0].id, mode: mode, order };
    };

    let lastFlow = flow.get('Last');
    let last = (lastFlow && lastFlow.order) ? lastFlow.order : []; //vorige volgorde en actieve accu
    last = getActiveBattery(batteries, charge_discharge, 10, last);
    batteries = last.order;
    flow.set('Last',last);
    
    // verdelen beschikbaar vermogen over de accu's
    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);
        
        let j = battery.id;                         //vul power in juiste accu (powerPlan heeft normale volgeorde 0,1,2)
        powerPlan[j].power = maxPossible;
        totalAvailable -= maxPossible;
    }

    // level1: zorgt ervoor dat vermogen 0W is (idle < 80% efficiency)
    // Level2: Zorg dat elk vermogen bv minstens 200W is (XOM > 85/90% efficiency )
    powerPlan = powerPlan.map(p => ({
        battery: p.battery,
        power: p.power != 0 && p.power < xomL2 ? (p.power < xomL1 ? 0 : xomL2) : p.power,
        xom: p.power != 0 && p.power < xomL2 ? (p.power < xomL1 ? 'XOM0' : 'XOM'+xomL2) : p.xom,
        soc: p.soc
    }));
    
    for (let i = 0; i < batteries.length ; i++) {
        totalPower += powerPlan[i].power;
    }

    //sorteer de accus op battery (=id) //waarschijnlijk niet nodig
    powerPlan.sort((a, b) =>  a.battery - b.battery);
    
    // 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};
}

[ Voor 109% gewijzigd door JanAllElectric op 10-06-2025 12:26 ]

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

[superduper1969]

Richardoe schreef op dinsdag 10 juni 2025 @ 19:27:

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

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.

[ Voor 34% gewijzigd door superduper1969 op 10-06-2025 19:44 ]

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

[Ellroe32]

badnews.nl schreef op dinsdag 10 juni 2025 @ 12:41:
[Afbeelding]

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

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

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

[R-B]

Ik probeer mijn juiste tactiek te bepalen met een aflopend energiecontract, ik moet immers een contact kiezen. Mijn 2jr contract loopt af in oktober.

Uitgangspunten:

• 1 x MT 5.12 kWh wordt morgen geleverd.
• 8 panelen met 2.4 Wp
• ~ 2200 kWh opwekking
• ~ 1100 kWh zelf verbruik
• ~ 1100 kWh teruglevering.
• ~ 3700 kWh verbruik uit het net (na salderen)
• 300/400 m3 gasverbruik door tapwater en bij winter < 5°C snacht bijstoken.
• ~1300 kWh door Auto (plug-in hybrid, vergoed door de zaak.
• ~1400 kWh Verwarming met AC's.
• Home Assistant aanwezig mbt mogelijke "slimmigheid" te bouwen.

Dus ik moet oversluiten, wat doe ik;

• Dynamisch
• Vast

tot 1-1-2027 saldeer ik alles weg, heb geen overschot
Op nieuwe contract betaal ik wel terugleverkosten. echter door inzet van de MT wordt het aantal kWh vermindert.

In combinatie met de 1x MT 5.12 kan ik:

• Zomers opladen op panelen en NOM draaien
• Winters (nagenoeg niet opladen panelen) en vooral opladen uit net op moment "laagste tarief" om profijt te hebben.

Hamvraag is; is dynamisch tarief al interassant? of is vast (tot oktober 2026?) nog wijzer.. Ik kan het moeilijk beoordelen.

[Hometek]

R-B schreef op woensdag 11 juni 2025 @ 14:47:
Ik probeer mijn juiste tactiek te bepalen met een aflopend energiecontract, ik moet immers een contact kiezen. Mijn 2jr contract loopt af in oktober.

Ik zat in een soortgelijke situatie, mijn vaste contract loopt einde deze maand af.
In januari heb ik een Marstek Venus gekocht om een beetje te experimenteren. In mei heb ik besloten dat ik mijn contract niet ga verlengen en overstap op een dynamisch tarief.
Maar bij mij speelt mee dat ik het leuk vind om met deze apparaten te experimenteren en niet primair naar de kosten kijk.
Ik heb geen glazen bol, maar het is te verwachten dat batterijen tot eind 2026 goedkoper en beter worden. Als je twijfelt is het wellicht verstandig om nog 1 jaar een vast contract te nemen en pas einde 2026 een thuisbatterij aan te schaffen.

[Ellroe32]

Ik had dit nog gepost:

Ellroe32 in "Hame / Marstek / Duravolt 5,12kWh plug en play thuisaccu"

[R-B]

Hometek schreef op woensdag 11 juni 2025 @ 16:27:
[...]

Ik zat in een soortgelijke situatie, mijn vaste contract loopt einde deze maand af.
In januari heb ik een Marstek Venus gekocht om een beetje te experimenteren. In mei heb ik besloten dat ik mijn contract niet ga verlengen en overstap op een dynamisch tarief.a
Maar bij mij speelt mee dat ik het leuk vind om met deze apparaten te experimenteren en niet primair naar de kosten kijk.
Ik heb geen glazen bol, maar het is te verwachten dat batterijen tot eind 2026 goedkoper en beter worden. Als je twijfelt is het wellicht verstandig om nog 1 jaar een vast contract te nemen en pas einde 2026 een thuisbatterij aan te schaffen.

Het beetje ermee experimenteren is ook leuk, vandaar ook de aanschaf van de MT. Beetje geduwd door feit afgelopend contract en beperken teruglevering.

Ellroe32 schreef op woensdag 11 juni 2025 @ 17:03:
Ik had dit nog gepost:

Ellroe32 in "Hame / Marstek / Duravolt 5,12kWh plug en play thuisaccu"

Die had ik gezien, maar dat is maand Mei met veel zon. Heb je eerder zoiets gepost met een wintermaand?

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

[SatScan]

badnews.nl schreef op donderdag 12 juni 2025 @ 17:33:
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)
[Afbeelding]

[Afbeelding]

[Afbeelding]

[Afbeelding]

Anders even uitvraag doen in hoofdtopc Martek Venus.

Ziet er goed uit 🎉👍🍀

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

[Arjanski]

superduper1969 schreef op vrijdag 13 juni 2025 @ 00:13:
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.

[Afbeelding]

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.

Lache, dat wil ik ook

Sorry mensen ik was erg druk de laatste dagen, nog steeds eigenlijk. Ben in ieder geval blij dat dit topic is gestart. Al zou ik ook graag in de titel iets willen zien als "Leuke gadgets in Home Assistant als je een ModBus koppeling hebt.".
Ik zeg het helemaal verkeerd, maar ik zou graag zien dat dit topic wat ruimer zou zijn zeg maar. Het gaat hier om intergraties als je een ModBus koppeling hebt, toch?

Misschien dat ik een verzameltopic ga starten anders waarin de reacties komen welke een idee beschrijven en hoe je dat dan moet maken. Een soort multi koopboekje

[Arjanski]

superduper1969 schreef op vrijdag 13 juni 2025 @ 00:13:
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.

[Afbeelding]

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.

Je zegt dat een stukje afknippen niet nodig is. Heb je het dan over de ledstrip van een meter?
Is het ook mogelijk om bijvoorbeeld 2 meter te gebruiken? Met andere woorden, je stuurd denk bepaalde leds aan. Die kun je eenvoudig uitbreiden in de yaml?

Dit soort dingen, ik hou er van

Meteen maar bestellen die strip hahaha

[superduper1969]

Arjanski schreef op vrijdag 13 juni 2025 @ 09:37:
[...]

Je zegt dat een stukje afknippen niet nodig is. Heb je het dan over de ledstrip van een meter?
Is het ook mogelijk om bijvoorbeeld 2 meter te gebruiken? Met andere woorden, je stuurd denk bepaalde leds aan. Die kun je eenvoudig uitbreiden in de yaml?

Dit soort dingen, ik hou er van

Meteen maar bestellen die strip hahaha

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
Zal ook nog wel een foto van de binnenkant plaatsen vanavond.

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.

[Arjanski]

superduper1969 schreef op vrijdag 13 juni 2025 @ 11:26:
[...]

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
Zal ook nog wel een foto van de binnenkant plaatsen vanavond.

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.

Top, dan wacht ik nog even met bestellen Tnx!

[superduper1969]

Arjanski schreef op vrijdag 13 juni 2025 @ 11:55:
[...]

Top, dan wacht ik nog even met bestellen Tnx!

post aangepast

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

[S7ven]

Ik heb deze code nu een weekje draaien, het gebruikt een tibber "Intraday price ranking" waarde om te bepalen of er geladen of ontladen mag worden. Hoe lager deze waarde is hoe goedkoper de stroom, hoe hoger, hoe duurder de stroom (1-24). Werkt prima, is vast wel wat te optimaliseren hier en daar, bijv de 10min timer, veel plezier ermee

tibber + lilygo in home assistant supervised + marstek 5kw + laden/ontladen uitzetten als de auto start met laden

Automation:

code:

#MarstekProtectCharge
- alias: MarstekProtectCharge
  description: ''
  trigger:
    - platform: state
      entity_id: sensor.bluety_charging
      to: "charging"
  condition:
    - condition: template
      value_template: "{{ 'Charge' in states('sensor.lilygo_rs485_marstek_inverter_state') }}"
  action:
    - service: input_boolean.turn_off
      entity_id: input_boolean.marstek_charge_discharge
    - service: script.marstek_stop
      data: {}
    - service: notify.mobile_app_pixel_8_pro
      data:
        message: "MarstekProtectCharge - Tesla is charging, stop Marstek charging at {{ states('sensor.lilygo_rs485_marstek_battery_state_of_charge') }}% at {{ now().strftime('%H:%M %A %d %B %Y') }}"

#MarstekProtectDischarge
- alias: MarstekProtectDischarge
  description: ''
  trigger:
    - platform: state
      entity_id: sensor.bluety_charging
      to: "charging"
  condition:
    - condition: template
      value_template: "{{ 'Discharge' in states('sensor.lilygo_rs485_marstek_inverter_state') }}"
  action:
    - service: input_boolean.turn_off
      entity_id: input_boolean.marstek_charge_discharge
    - service: script.marstek_stop
      data: {}
    - service: notify.mobile_app_pixel_8_pro
      data:
        message: "MarstekProtectDischarge - Tesla is charging, stop Marstek discharging at {{ states('sensor.lilygo_rs485_marstek_battery_state_of_charge') }}% at {{ now().strftime('%H:%M %A %d %B %Y') }}"
        
#MarstekChargeDischarge
- alias: MarstekChargeDischarge
  description: ''
  trigger:
    - platform: time_pattern
      minutes: "/10"
  condition:
    - condition: state
      entity_id: input_boolean.marstek_charge_discharge
      state: 'on'
  action:
#Enable Charge
    - if:
        - condition: numeric_state
          entity_id: sensor.tibber_current_price_rank
          below: 4
        - condition: numeric_state
          entity_id: sensor.lilygo_rs485_marstek_battery_state_of_charge
          below: 100              
        - condition: template
          value_template: "{{ 'Standby' in states('sensor.lilygo_rs485_marstek_inverter_state') }}"
        - condition: numeric_state
          entity_id: sensor.laadpaal_amp_current
          below: 1          
      then:
        - service: script.marstek_startcharge
          data: {}
        - service: notify.mobile_app_pixel_8_pro
          data:
            message: "Start Marstek charging at {{ states('sensor.lilygo_rs485_marstek_battery_state_of_charge') }}% at {{ now().strftime('%H:%M %A %d %B %Y') }} because of price rank {{ states('sensor.tibber_current_price_rank') }}"         
#Disable Charge
    - if:
        - condition: numeric_state
          entity_id: sensor.tibber_current_price_rank
          above: 3       
        - condition: template
          value_template: "{{ 'Charge' in states('sensor.lilygo_rs485_marstek_inverter_state') }}"         
      then:
        - service: script.marstek_stop
          data: {}
        - service: notify.mobile_app_pixel_8_pro
          data:
            message: "Stop Marstek charging at {{ states('sensor.lilygo_rs485_marstek_battery_state_of_charge') }}% at {{ now().strftime('%H:%M %A %d %B %Y') }} because of price rank {{ states('sensor.tibber_current_price_rank') }}"              
#Enable Discharge
    - if:
        - condition: numeric_state
          entity_id: sensor.tibber_current_price_rank
          above: 19
        - condition: numeric_state
          entity_id: sensor.lilygo_rs485_marstek_battery_state_of_charge
          above: 12            
        - condition: template
          value_template: "{{ 'Standby' in states('sensor.lilygo_rs485_marstek_inverter_state') }}"
        - condition: numeric_state
          entity_id: sensor.laadpaal_amp_current
          below: 1          
      then:
        - service: script.marstek_startdischarge
          data: {}
        - service: notify.mobile_app_pixel_8_pro
          data:
            message: "Start Marstek discharging at {{ states('sensor.lilygo_rs485_marstek_battery_state_of_charge') }}% at {{ now().strftime('%H:%M %A %d %B %Y') }} because of price rank {{ states('sensor.tibber_current_price_rank') }}"      
#Disable Discharge
    - if:
        - condition: numeric_state
          entity_id: sensor.tibber_current_price_rank
          below: 20          
        - condition: template
          value_template: "{{ 'Discharge' in states('sensor.lilygo_rs485_marstek_inverter_state') }}"        
      then:
        - service: script.marstek_stop
          data: {}
        - service: notify.mobile_app_pixel_8_pro
          data:
            message: "Stop Marstek discharging at {{ states('sensor.lilygo_rs485_marstek_battery_state_of_charge') }}% at {{ now().strftime('%H:%M %A %d %B %Y') }} because of price rank {{ states('sensor.tibber_current_price_rank') }}"

Script:

code:

marstek_startcharge:
  sequence:
  - service: select.select_option
    target:
      entity_id: select.lilygo_rs485_marstek_forcible_charge_discharge
    data:
      option: 'charge'
  mode: single
  alias: marstek_startcharge
        
marstek_startdischarge:
  sequence:
  - service: select.select_option
    target:
      entity_id: select.lilygo_rs485_marstek_forcible_charge_discharge
    data:
      option: 'discharge'
  mode: single
  alias: marstek_startdischarge
  
marstek_stop:
  sequence:
  - service: select.select_option
    target:
      entity_id: select.lilygo_rs485_marstek_forcible_charge_discharge
    data:
      option: 'stop'
  mode: single
  alias: marstek_stop

Sensor:

code:

  - sensor:
      - name: tibber_current_price_rank
        unique_id: bccdc0cf-5ac3-15f9-v766-c327dd8vfc28
        state: "{{ state_attr('sensor.house_electricity_price', 'intraday_price_ranking') }}"
        unit_of_measurement: "#"

[Hometek]

Marstek Venus SOC drift

Actergrond info
De SOC van batterijen is een rekenkundige schatting van de capaciteit gebaseerd op de toestand van individuele cellen. De cellen in Lifepo4 batterijen laden en ontladen niet altijd precies even snel. Om te voorkomen dat individuele cellen te ver opgeladen of ontladen worden zorgt het BMS voor het ‘balanceren’ van de cellen. Bij de Mastek Venus gebeurt het balanceren vermoedelijk tijdens het opladen tussen SOC 99% en 100%.
Als de verschillen tussen individuele cellen groot worden kan dit tot grote afwijkingen van de berekende SOC tov de werkelijk capaciteit leiden, dit wordt ook wel SOC-drift genoemd

Mijn ervaringen
Ik heb veel batterij capaciteit tov mijn PV installatie en dagelijks verbruik. In het voorjaar waren er daarom vaak periodes van 1 a 2 weken dat de batterijen niet tot 100% opgeladen werden. In deze periode heb ik herhaaldelijk tekenen van SOC drift gezien:

• plotselinge daling bij lage SOC, bv van 25% naar 11% in enkele minuten (zonder zware belasting)
• zeer lange tijd blijven hangen op 99% bij opladen met 1150W (soms meer dan 1.5 uur)

Dit kunnen indicaties zijn van een defecte batterij zoals sommige tweakers ervaren hebben. Omdat ik het echter bij 2 batterijen heb gezien en de effecten verdwenen na enkele snelle en volledige laad/ontlaadcycli ga ik ervan uit dat het in mijn geval enkel SOC drift is.
Nu ik de batterijen via HA individueel kan aansturen, lijkt de SOC drift ook aanzienlijk kleiner.

HA
In mijn aansturing vanuit HA probeer ik rekening te houden met de volgende zaken die de SOC drift beperken en de batterijen hopelijk een lange levensduur geven:

• Zo vaak mogelijk opladen tot 100%
• Vanaf 99% altijd volledig opladen tot 100% (forced charge met 1200W)
• Batterijen niet lange tijd op 100% laten staan, maar ontladen tot ca. 80%
• Niet te ver ontladen (ik houd een ‘reserve’ aan van 30%)

SOC als trigger in HA
Als je de SOC als trigger in HA gebruikt houd er dan rekening mee dat de SOC soms meerdere procenten kan verspringen, bv in één stap van 22% naar 11%. Als je automatisering een trigger heeft voor SOC = 20% zal deze in dit voorbeeld niet werken. Je kunt beter iets als SOC <= 20% gebruiken, of andere redundantie inbouwen.

[JanAllElectric]

Hometek schreef op maandag 16 juni 2025 @ 12:44:
Marstek Venus SOC drift

Actergrond info
De SOC van batterijen is een rekenkundige schatting van de capaciteit gebaseerd op de toestand van individuele cellen. De cellen in Lifepo4 batterijen laden en ontladen niet altijd precies even snel. Om te voorkomen dat individuele cellen te ver opgeladen of ontladen worden zorgt het BMS voor het ‘balanceren’ van de cellen. Bij de Mastek Venus gebeurt het balanceren vermoedelijk tijdens het opladen tussen SOC 99% en 100%.
Als de verschillen tussen individuele cellen groot worden kan dit tot grote afwijkingen van de berekende SOC tov de werkelijk capaciteit leiden, dit wordt ook wel SOC-drift genoemd

Mijn ervaringen
Ik heb veel batterij capaciteit tov mijn PV installatie en dagelijks verbruik. In het voorjaar waren er daarom vaak periodes van 1 a 2 weken dat de batterijen niet tot 100% opgeladen werden. In deze periode heb ik herhaaldelijk tekenen van SOC drift gezien:

• plotselinge daling bij lage SOC, bv van 25% naar 11% in enkele minuten (zonder zware belasting)
• zeer lange tijd blijven hangen op 99% bij opladen met 1150W (soms meer dan 1.5 uur)

Dit kunnen indicaties zijn van een defecte batterij zoals sommige tweakers ervaren hebben. Omdat ik het echter bij 2 batterijen heb gezien en de effecten verdwenen na enkele snelle en volledige laad/ontlaadcycli ga ik ervan uit dat het in mijn geval enkel SOC drift is.
Nu ik de batterijen via HA individueel kan aansturen, lijkt de SOC drift ook aanzienlijk kleiner.

HA
In mijn aansturing vanuit HA probeer ik rekening te houden met de volgende zaken die de SOC drift beperken en de batterijen hopelijk een lange levensduur geven:

• Zo vaak mogelijk opladen tot 100%
• Vanaf 99% altijd volledig opladen tot 100% (forced charge met 1200W)
• Batterijen niet lange tijd op 100% laten staan, maar ontladen tot ca. 80%
• Niet te ver ontladen (ik houd een ‘reserve’ aan van 30%)

SOC als trigger in HA
Als je de SOC als trigger in HA gebruikt houd er dan rekening mee dat de SOC soms meerdere procenten kan verspringen, bv in één stap van 22% naar 11%. Als je automatisering een trigger heeft voor SOC = 20% zal deze in dit voorbeeld niet werken. Je kunt beter iets als SOC <= 20% gebruiken, of andere redundantie inbouwen.

Wat betreft SOC drift. Bij mijn 3 Marsteks zie ik eigenlijk alleen het "probleem" dat de SOC soms op 99% blijft staan. Daarom gebruik ik in mijn programma SOC niet direct, maar de verhouding gerapporteerd vulling (marstek_battery_remaining_capacit) / gerapporteerde inhoud (marstek_battery_total_energy) door de Marstek zelf..

Dat een van de Marsteks bij SOC 99% toch al "vol" zit kan je op de volgende wijze testen.

code:

        Marstek[i].inhoud = (Marstek[i].soc > 95 && planLasttime.mode == 'charge' && planLasttime.powerPlan[i].power != 0 && Marstek[i].inverter_state == "Standby" ? Marstek[i].vulgraad : Marstek[i].inhoud);

Vulgraad / inhoud levert dan altijd (alleen voor deze cyclus) 100% op. Loopt de rest van het programma netjes door.

NB: tussen gevraagde planLastTime[i].power en gerapporteerde Marstek[i].inverter_state zit bij mij 12 seconden.

Wel resetten bij de volgende discharge.

code:

        Marstek[i].inhoud = (planLasttime.mode == 'discharge' ? Marstek[i].inhoud : inhoud_vorig);

[ Voor 7% gewijzigd door JanAllElectric op 16-06-2025 15:03 ]

[Hometek]

JanAllElectric schreef op maandag 16 juni 2025 @ 14:46:
[...]
Wat betreft SOC drift. Bij mijn 3 Marsteks zie ik eigenlijk alleen het "probleem" dat de SOC soms op 99% blijft staan. Daarom gebruik ik in mijn programma SOC niet direct, maar de verhouding gerapporteerd vulling (marstek_battery_remaining_capacit) / gerapporteerde inhoud (marstek_battery_total_energy) door de Marstek zelf..

Dat een van de Marsteks bij SOC 99% toch al "vol" zit kan je op de volgende wijze testen.
...

Interessante aanpak. Maar is 'vol' hetzelfde als 'volledig gebalanceerd'?
Mijn redenering is dat de Marstek pas SOC 100% rapporteerd als het balanceren afgerond is. Zolang de SOC 99% is zijn er volgens mij nog cellen die afwijken.

Ik zie bij mijn systeem dat de tijd dat een batterij op 99% blijft hangen, gerelateerd is aan hoe lang de batterij niet meer op 100% is geweest. Ook langdurig met lage vermogens laden/ontladen lijkt de 99% tijd te verlengen.
Als ik cycli van 24 uur heb met redelijke laad en ontlaad vermogens blijft de batterij slechts enkele minuten op 99%.

[JanAllElectric]

Hometek schreef op maandag 16 juni 2025 @ 18:12:
[...]

Interessante aanpak. Maar is 'vol' hetzelfde als 'volledig gebalanceerd'?
Mijn redenering is dat de Marstek pas SOC 100% rapporteerd als het balanceren afgerond is. Zolang de SOC 99% is zijn er volgens mij nog cellen die afwijken.

Ik zie bij mijn systeem dat de tijd dat een batterij op 99% blijft hangen, gerelateerd is aan hoe lang de batterij niet meer op 100% is geweest. Ook langdurig met lage vermogens laden/ontladen lijkt de 99% tijd te verlengen.
Als ik cycli van 24 uur heb met redelijke laad en ontlaad vermogens blijft de batterij slechts enkele minuten op 99%.

Dat weet ik niet . Dat is iets wat het BMS zelf moet doen.

Maar het heeft bij SOC 99% geen zin om eindeloos te herhalen dat de software X chargepower vraagt en standby terug krijgt. Dat houdt alleen de software op om met de volgende Marstek verder te gaan (ik heb er 3).

Blijkbaar wordt door het BMS toch gebalanceerd, want meestal komt de volgende chargecyclus netjes op 100%.

edit: ik zou ook op het moment dat ik bij 99% overga op de volgende Marstek, het BMS van de vorige nog met het commando "Marstek Charge To SOC" = 100 kunnen stimuleren. Ik heb eigenlijk geen idee wat er dan gebeurt. (oncontroleerbare) Parallelle processen vermijd ik liever.

[ Voor 9% gewijzigd door JanAllElectric op 16-06-2025 19:02 ]

[Arjanski]

superduper1969 schreef op zaterdag 14 juni 2025 @ 09:29:
[...]

post aangepast

Thanks! (sorry was even flink ziek, te ziek voor tweakers, vandaar wat late reactie.

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