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

[timvanloon]

mvhest schreef op dinsdag 23 september 2025 @ 19:05:
[...]

Idem bij mij, V114 zou de laatste firmware zijn.

Je kan de v139 zelf via de feedback aanvragen

[mvhest]

timvanloon schreef op dinsdag 23 september 2025 @ 19:19:
[...]


Je kan de v139 zelf via de feedback aanvragen

Net gedaan :-)

[Hans M]

hermlek schreef op dinsdag 23 september 2025 @ 05:38:
[...]

Ik denk dat de ISKRA AM550-P1 een betere refresh heeft dan de Kaifa - alleszins veel minder als 3-5 seconden.

Heb je dan die ISKRA ingesteld in de CT003?

[Alan969]

PNARI schreef op dinsdag 23 september 2025 @ 07:44:
[...]

Als je BT verbinding maakt zie je de batterij en CT003 in realtime.

dat deed ik ook: "zo zie ik dat op de CT003"

[Jumper2110]

Mijn Venus-E begon daarnet uit zichzelf te laden aan 1000W, terwijl hij hier al een maand netjes wacht met laden tot er een overschot aan zonnestroom is. Ik heb de app zonet geüpdatet naar de laatste versie, voor de rest is er niets veranderd..🤔 Hij staat al vanaf het begin op 'zelf geïnitieerd consumptiemodel'..

[S2S]

Jumper2110 schreef op dinsdag 23 september 2025 @ 22:51:
Mijn Venus-E begon daarnet uit zichzelf te laden aan 1000W, terwijl hij hier al een maand netjes wacht met laden tot er een overschot aan zonnestroom is. Ik heb de app zonet geüpdatet naar de laatste versie, voor de rest is er niets veranderd..🤔 Hij staat al vanaf het begin op 'zelf geïnitieerd consumptiemodel'..

Als de batterij te ver leegloopt gaan de batterij vanzelf bijladen . Om schade te voorkomen .

[Jumper2110]

S2S schreef op dinsdag 23 september 2025 @ 23:04:
[...]

Als de batterij te ver leegloopt gaan de batterij vanzelf bijladen . Om schade te voorkomen .

Hij stopte voorheen gewoon op 11% dacht ik, maar ok, dat zou wel kunnen dan!

[Hans C]

Mijn batterijen doen toch vreemd. Ik heb er 3. Als ik er 1 aansluit op AI via de CT003 dan krijg ik dit bij het aan en uitdoen van een licht:


Dit is het gedrag dat ik verwacht. Als ik de 2e batterij aansluit met hetzelfde lichtknopje, dan krijg ik dit:


Nog steeds prima. Licht aan. Wachten. Licht uit en dan terug naar net iets boven 0. Ik hoop dan 0, het is 8, maar je kan niet alles hebben. Vervolgens sluit ik batterij 3 aan.



Dit is maar 1 keer het lichtknopje. Vervolgens zijn de uitslagen veel groter en blijft dit voor lange tijd jojo-en. Wat dus niet gebeurt bij 1 of 2 batterijen. Iemand hier ervaring mee?

[Druppeltje_]

Hans C schreef op dinsdag 23 september 2025 @ 23:30:
Mijn batterijen doen toch vreemd. Ik heb er 3. Als ik er 1 aansluit op AI via de CT003 dan krijg ik dit bij het aan en uitdoen van een licht:
[Afbeelding]

Dit is het gedrag dat ik verwacht. Als ik de 2e batterij aansluit met hetzelfde lichtknopje, dan krijg ik dit:
[Afbeelding]

Nog steeds prima. Licht aan. Wachten. Licht uit en dan terug naar net iets boven 0. Ik hoop dan 0, het is 8, maar je kan niet alles hebben. Vervolgens sluit ik batterij 3 aan.

[Afbeelding]

Dit is maar 1 keer het lichtknopje. Vervolgens zijn de uitslagen veel groter en blijft dit voor lange tijd jojo-en. Wat dus niet gebeurt bij 1 of 2 batterijen. Iemand hier ervaring mee?

Eerlijk? Geen idee.
Ik ben gestopt met zo dicht met mijn neus op de meter te zitten. In het begin uit nieuwsgierigheid en nu soms nog ''gewoon omdat het kan''. Soms doen die inderdaad een gekke sprong maken, andere keren dan weer niet. Als de vrouw met het strijkijzer in de weer is word je ongeveer zeeziek van die grafiek in de HW app. Ik heb dat hier al heel vaak gezegd en ik blijf daar eigenlijk ook bij: bekijk de werking van je batterijen en je verbruik over 24u. Laadt hij mooi op, ontlaadt hij vanzelf en is je netverbruik minimaal? Gewoon laten draaien. Ik betrap mezelf er laatste tijd vaker op dat ik soms dagen niet in die app of de app van de MT heb gekeken. Kijk ik dan wel nog eens naar het netverbruik dan is dat 3,9kWh op 7 dagen tijd. (Met toch niet zo'n fantastisch weer)

[hermlek]

Hans M schreef op dinsdag 23 september 2025 @ 19:45:
[...]


Heb je dan die ISKRA ingesteld in de CT003?

ja sinds gisteren. Reageert nu sneller lijkt me toch.

[Sonero]

Hans C schreef op dinsdag 23 september 2025 @ 23:30:
Mijn batterijen doen toch vreemd. Ik heb er 3. Als ik er 1 aansluit op AI via de CT003 dan krijg ik dit bij het aan en uitdoen van een licht:
[Afbeelding]

Dit is het gedrag dat ik verwacht. Als ik de 2e batterij aansluit met hetzelfde lichtknopje, dan krijg ik dit:
[Afbeelding]

Nog steeds prima. Licht aan. Wachten. Licht uit en dan terug naar net iets boven 0. Ik hoop dan 0, het is 8, maar je kan niet alles hebben. Vervolgens sluit ik batterij 3 aan.

[Afbeelding]

Dit is maar 1 keer het lichtknopje. Vervolgens zijn de uitslagen veel groter en blijft dit voor lange tijd jojo-en. Wat dus niet gebeurt bij 1 of 2 batterijen. Iemand hier ervaring mee?

Klassiek voorbeeld van een té snelle regellus.

Dat 1 batterij probeert het verbruik zo snel mogelijk naar NOM op de meter te krijgen is wenselijk gedrag en met de huidige software prima te doen op 1 fase.
Wanneer 3 batterijen dat allemaal tegelijk proberen te doen (die dan ook nog eens allemaal op een verschillende fase zitten?) is het niet verbazingwekkend dat je oscillaties krijgt.

In het verleden hebben we zelfs gezien dat de ene batterij de andere begon op te laden. Op de een of andere manier zullen de batterijen van elkaars aanwezigheid op de hoogste gebracht moeten worden. Als ik het goed begrepen heb, kan dat alleen wannneer je de P1-meter van Marstek zelf gebruikt.

Is het mogelijk voor je om van P1-meter te wisselen?

[Druppeltje_]

Sonero schreef op woensdag 24 september 2025 @ 06:58:
[...]


Klassiek voorbeeld van een té snelle regellus.

Dat 1 batterij probeert het verbruik zo snel mogelijk naar NOM op de meter te krijgen is wenselijk gedrag en met de huidige software prima te doen op 1 fase.
Wanneer 3 batterijen dat allemaal tegelijk proberen te doen (die dan ook nog eens allemaal op een verschillende fase zitten?) is het niet verbazingwekkend dat je oscillaties krijgt.

In het verleden hebben we zelfs gezien dat de ene batterij de andere begon op te laden. Op de een of andere manier zullen de batterijen van elkaars aanwezigheid op de hoogste gebracht moeten worden. Als ik het goed begrepen heb, kan dat alleen wannneer je de P1-meter van Marstek zelf gebruikt.

Is het mogelijk voor je om van P1-meter te wisselen?

Meerdere batterijen in gebruik is altijd met de CT002 of 003. Ik ga er van uit dat de vraagsteller deze al in gebruik heeft. Met een andere meter dan deze 2 ga je het nooit goed krijgen met meerdere batterijen, maar denk niet dat dat het probleem was.

[PNARI]

Alan969 schreef op dinsdag 23 september 2025 @ 21:10:
[...]

dat deed ik ook: "zo zie ik dat op de CT003"

Batterij regelt gewoon door als internetverbinding weg is, zowel met Shelly, HWP1 als CT003, heb ik alle drie getest. Zal met CT002 ook wel zo zijn.

[d3x]

Jumper2110 schreef op dinsdag 23 september 2025 @ 23:07:
[...]


Hij stopte voorheen gewoon op 11% dacht ik, maar ok, dat zou wel kunnen dan!

dat heeft met soc drift te maken en hercallibratie. ik heb nu exact hetzelfde deze ochtend. battrij om 4h deze nacht gestopt met ontladen, ik kijk nu in de app en de batterij is maar 8% en aan het laden tegen een 600w terwijl er geen PV opbrengst genoeg is.

[d3x]

Hans C schreef op dinsdag 23 september 2025 @ 23:30:
Mijn batterijen doen toch vreemd. Ik heb er 3. Als ik er 1 aansluit op AI via de CT003 dan krijg ik dit bij het aan en uitdoen van een licht:
[Afbeelding]

Dit is het gedrag dat ik verwacht. Als ik de 2e batterij aansluit met hetzelfde lichtknopje, dan krijg ik dit:
[Afbeelding]

Nog steeds prima. Licht aan. Wachten. Licht uit en dan terug naar net iets boven 0. Ik hoop dan 0, het is 8, maar je kan niet alles hebben. Vervolgens sluit ik batterij 3 aan.

[Afbeelding]

Dit is maar 1 keer het lichtknopje. Vervolgens zijn de uitslagen veel groter en blijft dit voor lange tijd jojo-en. Wat dus niet gebeurt bij 1 of 2 batterijen. Iemand hier ervaring mee?

je ct03 staat op som van de fases en heb je auto diagnose gedaan bij elke batterij in de CT selectie?
je gebruikt overal dezelfde CT als je van de ene naar de andere MT gaat als test?
de wifi is zeker en vast ok op alle3? het antwoord ja ze staan naast elkaar is niet voldoende.....

[ Voor 4% gewijzigd door d3x op 24-09-2025 08:18 ]

[Nu7s]

Druppeltje_ schreef op woensdag 24 september 2025 @ 07:33:
[...]
Meerdere batterijen in gebruik is altijd met de CT002 of 003. Ik ga er van uit dat de vraagsteller deze al in gebruik heeft. Met een andere meter dan deze 2 ga je het nooit goed krijgen met meerdere batterijen, maar denk niet dat dat het probleem was.

Hier 3 batterijen, elk op hun eigen fase in combinatie met een Shelly, geen CT002 of 003. 2 batterijen kijken enkel naar hun eigen fase, de derde kijkt naar de som van de drie zodat die overneemt als een andere batterij leeg of vol is. Werkt perfect.

[NoFate]

Ben hier al een paar keer tegengekomen, dat je de CT op auto Discover kan zetten, zodat die zelf de meter selection gaat doen... Maar waar staat dat? Ik kan alleen maar een meter handmatig selecteren?

[d3x]

NoFate schreef op woensdag 24 september 2025 @ 08:23:
Ben hier al een paar keer tegengekomen, dat je de CT op auto Discover kan zetten, zodat die zelf de meter selection gaat doen... Maar waar staat dat? Ik kan alleen maar een meter handmatig selecteren?

als je een ct003 hebt moet je de meter zelf aanduiden in de app. Alhoewel ik al bij installaties recent gezien heb dat hij er zelf een kiest en die werkt perfect vanaf de start.
de auto diagnostic is bij elke batterij zelf als je de CT selectie doet.

[Erik1805]

Ik heb een vraag over de NOM mode. Deze laadt alleen de batterij met zonnestroom en niet uit het net toch? Dan moet je AI selecteren begrijp ik?

[AUijtdehaag]

@Erik1805
Ai is voor dynamisch kontrakt
Zelf consumptie is NOM

[Hans C]

Druppeltje_ schreef op woensdag 24 september 2025 @ 07:33:
[...]


Meerdere batterijen in gebruik is altijd met de CT002 of 003. Ik ga er van uit dat de vraagsteller deze al in gebruik heeft. Met een andere meter dan deze 2 ga je het nooit goed krijgen met meerdere batterijen, maar denk niet dat dat het probleem was.

Klopt. Is met de CT003. De HWp1 gebruik ik alleen om naar te kijken. Geeft veel betere informatie.

[Hans C]

d3x schreef op woensdag 24 september 2025 @ 08:17:
[...]


je ct03 staat op som van de fases en heb je auto diagnose gedaan bij elke batterij in de CT selectie?
je gebruikt overal dezelfde CT als je van de ene naar de andere MT gaat als test?
de wifi is zeker en vast ok op alle3? het antwoord ja ze staan naast elkaar is niet voldoende.....

Autodiagnose doet hij standaard bij iedere batterij die je koppelt aan de CT003. Ik gebruik bij alle drie de enige CT die ik heb. De wifi is ruim voldoende, ik heb geen disconnects en de db hoeveelheid is ruim. En hij staat op Three phase sum.

[antoinevromen]

AUijtdehaag schreef op woensdag 24 september 2025 @ 09:04:
@Erik1805
Ai is voor dynamisch kontrakt
Zelf consumptie is NOM

Eigenlijk is AI bijna hetzelfde als Eigenconsumpie (Nom) met de enige uitzondering dat bij de modus AI de batterij van het net tot 100% bijlaadt op de 2 goedkoopste uren. Als je geen dynamisch contract hebt laadt hij dus ook 1 x per dag tot 100% (als hij ervoor al met zonnestroom via de Eigenconsumptie die in AI zit al vol is geraakt, zal de batterij in de goedkoopste uren niets doen (dus ook niet ontladen !!! op die goedkoopste uren.
Dus AI is qua gedrag identiek met eigenconsumptie met uitzondering van de 2 goedkoopste uren op een dag volgens het dynamisch prijzenschema.

[vifra]

antoinevromen schreef op woensdag 24 september 2025 @ 09:29:
[...]

Eigenlijk is AI bijna hetzelfde als Eigenconsumpie (Nom) met de enige uitzondering dat bij de modus AI de batterij van het net tot 100% bijlaadt op de 2 goedkoopste uren. Als je geen dynamisch contract hebt laadt hij dus ook 1 x per dag tot 100% (als hij ervoor al met zonnestroom via de Eigenconsumptie die in AI zit al vol is geraakt, zal de batterij in de goedkoopste uren niets doen (dus ook niet ontladen !!! op die goedkoopste uren.
Dus AI is qua gedrag identiek met eigenconsumptie met uitzondering van de 2 goedkoopste uren op een dag volgens het dynamisch prijzenschema.

Je kan het niet beter verwoorden - kort samengevat een AI met een IQ van 10 ...


Een goede AI zou snappen:
- wat uw verbruikpatroon is over een dag / week ...
- als je die hebt - uw ZP profiel en verwachte opbrengst per uur (dus weersverwachting)
- wanneer het goed is om te verkopen en wanneer het goed is om te laden
- de batterij optimaal schakelen tussen laden / injecteren en dit rekening houdend met uw profiel, uw ZP en met de dynamische markt

En dit best door eerst een leerperiode ( pak een week) om profiel op te maken en dan bijsturen volgens effectief gebruik ...

[ Voor 24% gewijzigd door vifra op 24-09-2025 09:37 ]

[Erik1805]

antoinevromen schreef op woensdag 24 september 2025 @ 09:29:
[...]

Eigenlijk is AI bijna hetzelfde als Eigenconsumpie (Nom) met de enige uitzondering dat bij de modus AI de batterij van het net tot 100% bijlaadt op de 2 goedkoopste uren. Als je geen dynamisch contract hebt laadt hij dus ook 1 x per dag tot 100% (als hij ervoor al met zonnestroom via de Eigenconsumptie die in AI zit al vol is geraakt, zal de batterij in de goedkoopste uren niets doen (dus ook niet ontladen !!! op die goedkoopste uren.
Dus AI is qua gedrag identiek met eigenconsumptie met uitzondering van de 2 goedkoopste uren op een dag volgens het dynamisch prijzenschema.

Ik heb ook een dynamische contract. Ik zal hem op AI laten staan met periodes van weinig zon.

[Druppeltje_]

Nu7s schreef op woensdag 24 september 2025 @ 08:21:
[...]


Hier 3 batterijen, elk op hun eigen fase in combinatie met een Shelly, geen CT002 of 003. 2 batterijen kijken enkel naar hun eigen fase, de derde kijkt naar de som van de drie zodat die overneemt als een andere batterij leeg of vol is. Werkt perfect.

Ja klopt, ik had moeten verduidelijken dat ik bedoelde indien de hele installatie op nom stond.

[meesje]

vifra schreef op woensdag 24 september 2025 @ 09:32:
[...]

Je kan het niet beter verwoorden - kort samengevat een AI met een IQ van 10 ...


Een goede AI zou snappen:
- wat uw verbruikpatroon is over een dag / week ...
- als je die hebt - uw ZP profiel en verwachte opbrengst per uur (dus weersverwachting)
- wanneer het goed is om te verkopen en wanneer het goed is om te laden
- de batterij optimaal schakelen tussen laden / injecteren en dit rekening houdend met uw profiel, uw ZP en met de dynamische markt

En dit best door eerst een leerperiode ( pak een week) om profiel op te maken en dan bijsturen volgens effectief gebruik ...

En dan wil je ook nog dat er rekening wordt gehouden met de afschrijving per cycle. Al met al lijkt het me redelijk complex om dit te bouwen. Noem het dan in ieder geval geen AI.

[ Voor 5% gewijzigd door meesje op 24-09-2025 09:46 ]

[E.T.O.]

2xdehelft schreef op dinsdag 23 september 2025 @ 08:16:
Heeft iemand hier de API al werkend? Die op UDP poort 30000? Ik heb de optie beschikbaar op beide Venus E accus maar ik krijg nog geen response als ik probeer met deze poort te communiceren...

Ik heb communicatie voor elkaar gekregen; ik heb er zelfs een Homey App voor gebouwd . Helaas stopt de communicatie wel sporadisch. Enkel een reset van de battery brengt de boel weer tot leven.

De Local API met port 30000 kan je via de BLE Test Tool gemakkelijk zelf open zetten.

[vifra]

meesje schreef op woensdag 24 september 2025 @ 09:44:
[...]

En dan wil je ook nog dat er rekening wordt gehouden met de afschrijving per cycle. Al met al lijkt het me redelijk complex om dit te bouwen. Noem het dan in ieder geval geen AI.

Het verschil tussen laadkost en ontlaadopbrengst dient > 20% te zijn (inverter verliezen AC/DC ... ) en dan de afschrijvingswaarde ... dus pak er moet minstens 8 cent verschil zijn per kWh alvorens het interessant is ...

[AUijtdehaag]

Erik1805 schreef op woensdag 24 september 2025 @ 09:40:
[...]

Ik heb ook een dynamische contract. Ik zal hem op AI laten staan met periodes van weinig zon.

Ik ook. Maar met 2 batterijen vind ik het leuk om ze leeg te dumpen bij 60 ct (incl btw) tot 40% soc
En geen van beide functies hebben dat. Eigen sturing via modbus.

[AUijtdehaag]

E.T.O. schreef op woensdag 24 september 2025 @ 09:48:
[...]


Ik heb communicatie voor elkaar gekregen; ik heb er zelfs een Homey App voor gebouwd . Helaas stopt de communicatie wel sporadisch. Enkel een reset van de battery brengt de boel weer tot leven.

De Local API met port 30000 kan je via de BLE Test Tool gemakkelijk zelf open zetten.

Reset met die tool ook?

Ik vroeg me ook al af waarom de boel niet meer reageerde op api calls

[E.T.O.]

AUijtdehaag schreef op woensdag 24 september 2025 @ 10:03:
[...]

Reset met die tool ook?

Ik vroeg me ook al af waarom de boel niet meer reageerde op api calls

Ik reset de batterij inderdaad met de BLE tool, als de local API server niet meer reageert. Dat brengt 'm altijd weer tot leven. Het is de 'System Reset' van de BLE Tool v2 onder kopje 'Advanced'. Let wel; de batterij levert dan even geen stroom meer. Het duurt minder dan een minuut voordat de boel weer tot leven komt.

[antoinevromen]

Erik1805 schreef op woensdag 24 september 2025 @ 09:40:
[...]

Ik heb ook een dynamische contract. Ik zal hem op AI laten staan met periodes van weinig zon.

Hallo @Erik1805 ,
Ik wil de pret niet helemaal bederven voor je, maar het laden op het goedkoopste moment wil niet altijd zeggen dat je goedkoper uit bent dan dat je gewoon van het net zou gebruik maken op het dure moment (althans hier in NL). (In België met dat speciale boetetarief bij te hoog verbruik in een kwartier is dat wellicht een ander verhaal).

Een rekenvoorbeeld voor de financiele die-hards:
Voorbeeld: Stel op het duurste moment is de stroomprijs incl. alle belasting 29 cent (dat is een kale inkoopprijs van 12 cent); Stel het laagste tarief op die dag is kaal 5,5 ct. Als je daar opslag leverancier 2,33 en energiebelasting bijtelt 10,15 en daarover 21% erbij telt kom je op een prijs van 21,75 ct. Echter als je die stroom in de batterij laadt en daarna weer eruit haalt op het duurste uur verlies je zo'n 25% als gevolg van omvormerverliezen. Die stroom kost je dus eigenlijk 21,75 / 0,75 = 29 cent ; Je hebt dus geen voordeel gehad ofschoon het verschil tussen minimum en maximum 29 - 21,75 = 7,25 cent bedraagt.

Bij het maken van mijn powershell-scripts ben ik mij steeds meer bewust geworden van deze tegennatuurlijke invloeden. Zo laad je ook niet alleen voor het duurste uur, maar eigenlijk laad je voor het duurste uur en alle tussenliggende uren vanaf het moment van laden (minimumuur) tot en met het duurste uur. Dat betekent dat je eigenlijk die RTE-verhoogde minimumprijs van hierboven niet moet vergelijken met alleen de prijs van het duurste uur, maar met de gemiddelde prijs van al die uren tussen het moment van laden en het hoogste tariefuur. Dat betekent dat in bovenstaande situatie het laagste tarief nog significant lager moet zijn omdat de gemiddele prijs van de tussenliggende uren per definitie lager is dan de maximumprijs

[toktokcity]

AUijtdehaag schreef op woensdag 24 september 2025 @ 09:04:
@Erik1805
Ai is voor dynamisch kontrakt
Zelf consumptie is NOM

Wellicht al besproken, maar klopt mijn waarneming, dat als de accu's op AI staan en deze al vol zitten, maar het AI laad window actief is, de batterijen niets terugleveren?

[pascallj]

toktokcity schreef op woensdag 24 september 2025 @ 10:40:
[...]

Wellicht al besproken, maar klopt mijn waarneming, dat als de accu's op AI staan en deze al vol zitten, maar het AI laad window actief is, de batterijen niets terugleveren?

Dat klopt. Staat ook beschreven in het TS.

[toktokcity]

pascallj schreef op woensdag 24 september 2025 @ 10:41:
[...]


Dat klopt. Staat ook beschreven in het TS.

Wilde mijn bericht al verwijderen. AI kunnen tunen in de app, zou wel een fijne optie zijn!

[antoinevromen]

E.T.O. schreef op woensdag 24 september 2025 @ 09:48:
[...]


Ik heb communicatie voor elkaar gekregen; ik heb er zelfs een Homey App voor gebouwd . Helaas stopt de communicatie wel sporadisch. Enkel een reset van de battery brengt de boel weer tot leven.

De Local API met port 30000 kan je via de BLE Test Tool gemakkelijk zelf open zetten.

Daar heb ik geen last van met de powershell-scripts, maar die draaien dan ook maar 1 keer per kwartier.
Misschien moet je meer/hogere wachttijd/retries inbouwen of ervoor zorgen dat Homey (home assistant heeft daar ook last van) veel te vaak de batterij bevragen en dan heeft die niet genoeg rekenkracht om zijn communicatie naar de api en de dongle in stand te houden.

@pascallj @bommel Kunnen jullie misschien iets zinnigs zeggen over de frequentie waarmee de batterij via de local-api bevraagd kan worden, want ik heb de indruk dat nu meer mensen die local-api via Homey en HA gaan bevragen dit soort producten veel te frequent de batterij aanroepen? Ik weet te weinig van die producten af, maar ik neem toch aan dat daar ook een instelling in zit om de verversingsfrequentie te regelen.

[ Voor 21% gewijzigd door antoinevromen op 24-09-2025 10:52 ]

[modelstudent]

pascallj schreef op dinsdag 23 september 2025 @ 15:43:
[...]


Heb je ook al eens je normale netwerk ipv gastennetwerk geprobeerd? Normaal raad ik gastennetwerken af omdat die vaak geen communicatie tussen clients toestaat, al zal als het soms wel werkt hier niet het geval zijn. Zijn beide apparaten ook daadwerkelijk met die router verbonden of je heb je andere AP's met dezelfde naam?

Ook al geprobeerd; ubiquiti, fritzbox en gast. Overal zelfde probleem. Marstek support zei stroom er even af te halen en reset bij batterijen, maar geen verschil

[E.T.O.]

antoinevromen schreef op woensdag 24 september 2025 @ 10:43:
[...]

Daar heb ik geen last van met de powershell-scripts, maar die draaien dan ook maar 1 keer per kwartier.
Misschien moet je meer/hogere wachttijd/retries inbouwen of ervoor zorgen dat Homey (home assistant heeft daar ook last van) veel te vaak de batterij bevragen en dan heeft die niet genoeg rekenkracht om zijn communicatie naar de api en de dongle in stand te houden.

@pascallj @bommel Kunnen jullie misschien iets zinnigs zeggen over de frequentie waarmee de batterij via de local-api bevraagd kan worden, want ik heb de indruk dat nu meer mensen die local-api via Homey en HA gaan bevragen dit soort producten veel te frequent de batterij aanroepen? Ik weet te weinig van die producten af, maar ik neem toch aan dat daar ook een instelling in zit om de verversingsfrequentie te regelen.

Ik heb een aantal 24u tests gedaan met wisselende resultaten. Het is me gelukt om 24u lang elke seconde een bericht te versturen, waarvan 80% een antwoord gaf. Een andere test met elke 10 minuten (ook met ongeveer 80% response rate) gaf de batterij na middernacht helemaal geen enkel antwoord meer...

Ik ben benieuwd of er inderdaad iets zinnigs te zeggen is over min/max. Want als ik kijk naar de Marstek App zelf, dan doen halen ze regelmatig details van de accu, elke paar seconden. Kennelijk kan de rekenkracht dat wel gewoon aan, zonder dat deze stopt.

[pascallj]

antoinevromen schreef op woensdag 24 september 2025 @ 10:43:
[...]

Daar heb ik geen last van met de powershell-scripts, maar die draaien dan ook maar 1 keer per kwartier.
Misschien moet je meer/hogere wachttijd/retries inbouwen of ervoor zorgen dat Homey (home assistant heeft daar ook last van) veel te vaak de batterij bevragen en dan heeft die niet genoeg rekenkracht om zijn communicatie naar de api en de dongle in stand te houden.

@pascallj @bommel Kunnen jullie misschien iets zinnigs zeggen over de frequentie waarmee de batterij via de local-api bevraagd kan worden, want ik heb de indruk dat nu meer mensen die local-api via Homey en HA gaan bevragen dit soort producten veel te frequent de batterij aanroepen? Ik weet te weinig van die producten af, maar ik neem toch aan dat daar ook een instelling in zit om de verversingsfrequentie te regelen.

In HA is het aan de integratie om te bepalen hoe vaak een apparaat wordt uitgevraagd. Niet vaker dan elke 5 seconde volgens mij.

In de testen die ik tot nu toe gedaan hebt ligt het niet per se aan de hoeveelheid aanvragen, maar is het gewoon instabiel. De eerste aanvraag van de dag wordt soms ook al gemist. De tweede keer komt het wel binnen. Het ligt er denk ik aan wat de Marstek op dat moment aan het doen is, of de aanvraag op tijd verwerkt kan worden.

[Erik1805]

antoinevromen schreef op woensdag 24 september 2025 @ 10:38:
[...]

Hallo @Erik1805 ,
Ik wil de pret niet helemaal bederven voor je, maar het laden op het goedkoopste moment wil niet altijd zeggen dat je goedkoper uit bent dan dat je gewoon van het net zou gebruik maken op het dure moment (althans hier in NL). (In België met dat speciale boetetarief bij te hoog verbruik in een kwartier is dat wellicht een ander verhaal).

Een rekenvoorbeeld voor de financiele die-hards:
Voorbeeld: Stel op het duurste moment is de stroomprijs incl. alle belasting 29 cent (dat is een kale inkoopprijs van 12 cent); Stel het laagste tarief op die dag is kaal 5,5 ct. Als je daar opslag leverancier 2,33 en energiebelasting bijtelt 10,15 en daarover 21% erbij telt kom je op een prijs van 21,75 ct. Echter als je die stroom in de batterij laadt en daarna weer eruit haalt op het duurste uur verlies je zo'n 25% als gevolg van omvormerverliezen. Die stroom kost je dus eigenlijk 21,75 / 0,75 = 29 cent ; Je hebt dus geen voordeel gehad ofschoon het verschil tussen minimum en maximum 29 - 21,75 = 7,25 cent bedraagt.

Bij het maken van mijn powershell-scripts ben ik mij steeds meer bewust geworden van deze tegennatuurlijke invloeden. Zo laad je ook niet alleen voor het duurste uur, maar eigenlijk laad je voor het duurste uur en alle tussenliggende uren vanaf het moment van laden (minimumuur) tot en met het duurste uur. Dat betekent dat je eigenlijk die RTE-verhoogde minimumprijs van hierboven niet moet vergelijken met alleen de prijs van het duurste uur, maar met de gemiddelde prijs van al die uren tussen het moment van laden en het hoogste tariefuur. Dat betekent dat in bovenstaande situatie het laagste tarief nog significant lager moet zijn omdat de gemiddele prijs van de tussenliggende uren per definitie lager is dan de maximumprijs

Duidelijk, probleem is dat de batterij niet vol wordt als er weinig zon is. Je zal dus moeten laden tijdens de "goedkope" uren.

[pascallj]

Erik1805 schreef op woensdag 24 september 2025 @ 11:13:
[...]

Duidelijk, probleem is dat de batterij niet vol wordt als er weinig zon is. Je zal dus moeten laden tijdens de "goedkope" uren.

Waarom moet dat? Zoals ~antoinevromen terecht opmerkt, moet het verschil wel groot genoeg zijn. Anders kan je net zo goed alles wat je mist gewoon uit het net halen: makkelijker en zonder verliezen.

[olympusdenk]

antoinevromen schreef op woensdag 24 september 2025 @ 10:38:
[...] Een rekenvoorbeeld voor de financiele die-hards:
Voorbeeld: Stel op het duurste moment is de stroomprijs incl. alle belasting 29 cent (dat is een kale inkoopprijs van 12 cent); Stel het laagste tarief op die dag is kaal 5,5 ct. Als je daar opslag leverancier 2,33 en energiebelasting bijtelt 10,15 en daarover 21% erbij telt kom je op een prijs van 21,75 ct. Echter als je die stroom in de batterij laadt en daarna weer eruit haalt op het duurste uur verlies je zo'n 25% als gevolg van omvormerverliezen. Die stroom kost je dus eigenlijk 21,75 / 0,75 = 29 cent ; Je hebt dus geen voordeel gehad ofschoon het verschil tussen minimum en maximum 29 - 21,75 = 7,25 cent bedraagt. [...]

Ik probeer het te volgen, maar volgens mij zit er een denkfout in je rekenvoorbeeld. Als je gewoon stroom uit het net zou nemen op het dure moment, betaal je ook die 29 cent inclusief alle belastingen. Je "verkoop" aan jezelf is dus ook 29 cent waard.

Misschien is het simpeler om gewoon een vaste drempel aan te houden voor of je goedkoopste uren laad - zelf gebruik ik 12 cent verschil dat is rekenend vanuit 80% RTE (mijn MT haalt meestal rond die RTE op 2 / 2,5 kW), tot eind 2026 wanneer de saldering verdwijnt.

[ Voor 5% gewijzigd door olympusdenk op 24-09-2025 11:23 ]

[antoinevromen]

pascallj schreef op woensdag 24 september 2025 @ 11:03:
[...]


In HA is het aan de integratie om te bepalen hoe vaak een apparaat wordt uitgevraagd. Niet vaker dan elke 5 seconde volgens mij.

In de testen die ik tot nu toe gedaan hebt ligt het niet per se aan de hoeveelheid aanvragen, maar is het gewoon instabiel. De eerste aanvraag van de dag wordt soms ook al gemist. De tweede keer komt het wel binnen. Het ligt er denk ik aan wat de Marstek op dat moment aan het doen is, of de aanvraag op tijd verwerkt kan worden.

Toch raar; Ik draai het powershell-script nu al dagen achter elkaar (elk kwartier) geen uitval; En als ik de logica van het sturen aan het aanpassen/debuggen ben nog veel vaker ;-) . Wel zit in dat script een eerste "dummy" call naar Marstek.GetDevice (is nog van @bommel ) om de batterij "op te warmen". Daarnaast heeft @bommel ook een aantal retries (3x) ingebouwd wanneer er geen antwoord komt om dan een nieuwe call te doen; tenslotte (misschien is dat ook wel belangrijk zit er aan het einde van het script een soort weglezen van "te laat gekomen berichten", waardoor de antwoord-queue aan berichten weer leeg raakt aan het einde van het script.

[antoinevromen]

Erik1805 schreef op woensdag 24 september 2025 @ 11:13:
[...]

Duidelijk, probleem is dat de batterij niet vol wordt als er weinig zon is. Je zal dus moeten laden tijdens de "goedkope" uren.

Hallo @Erik1805 , Als het financieel (rekening houdend met RTE-verlies) niet rendabel is om bij te laden, dan moet er niets (behalve voor de Belgen natuurlijk die captar willen vermijden). Ik heb zo ook gevonden dat "niets" doen (ofwel de batterij een paar uur passive zetten, zodat hij wel stroom heeft voor het dure uur) ook een optie is die je kunt overwegen.

[Erik1805]

antoinevromen schreef op woensdag 24 september 2025 @ 11:32:
[...]

Hallo @Erik1805 , Als het financieel (rekening houdend met RTE-verlies) niet rendabel is om bij te laden, dan moet er niets (behalve voor de Belgen natuurlijk die captar willen vermijden). Ik heb zo ook gevonden dat "niets" doen (ofwel de batterij een paar uur passive zetten, zodat hij wel stroom heeft voor het dure uur) ook een optie is die je kunt overwegen.

Als je vandaag kijkt (ik zit bij Tibber) dan is de stroom op de goedkope uren 14,8ct en in de avond 28,9ct. Lijkt mij voldoende verschil. Of mis ik ergens iets? Dan lijkt het mij voordelig te laden en in de avond/nacht te gebruiken.

[pascallj]

antoinevromen schreef op woensdag 24 september 2025 @ 11:29:
[...]

Toch raar; Ik draai het powershell-script nu al dagen achter elkaar (elk kwartier) geen uitval; En als ik de logica van het sturen aan het aanpassen/debuggen ben nog veel vaker ;-) . Wel zit in dat script een eerste "dummy" call naar Marstek.GetDevice (is nog van @bommel ) om de batterij "op te warmen". Daarnaast heeft @bommel ook een aantal retries (3x) ingebouwd wanneer er geen antwoord komt om dan een nieuwe call te doen; tenslotte (misschien is dat ook wel belangrijk zit er aan het einde van het script een soort weglezen van "te laat gekomen berichten", waardoor de antwoord-queue aan berichten weer leeg raakt aan het einde van het script.

Het gaat te ver om hier alle ins en outs te bespreken, maar met 'retries' krijg ik het ook stabiel genoeg binnen en mis ik bijna niets, alleen het feit dat je die nodig hebt, wil dus zeggen dat de er iets niet stabiel is. Bij het laden van Tweakers hoef ik ook niet 3 keer op F5 te drukken voordat de pagina binnenkomt.

Het is goed voor iedereen die de API zelf wil gaan implementeren dat dit blijkbaar nodig is, maar ik stel voor dat als het nodig is om de implementatie details te gaan bespreken, dat we dit verhuizen naar een Github (gist)/PB o.i.d.

[antoinevromen]

olympusdenk schreef op woensdag 24 september 2025 @ 11:19:
[...]

Ik probeer het te volgen, maar volgens mij zit er een denkfout in je rekenvoorbeeld. Als je gewoon stroom uit het net zou nemen op het dure moment, betaal je ook die 29 cent inclusief alle belastingen. Je "verkoop" aan jezelf is dus ook 29 cent waard.

Misschien is het simpeler om gewoon een vaste drempel aan te houden voor of je goedkoopste uren laad - zelf gebruik ik 12 cent verschil dat is rekenend vanuit 80% RTE (mijn MT haalt meestal rond die RTE op 2 / 2,5 kW), tot eind 2026 wanneer de saldering verdwijnt.

@olympusdenk ; Snap ik; Daarom was het slechts een rekenvoorbeeld. Maar je kunt niet stellen dat je een fixed bedrag van 12 cent verschil kan nemen vanuit 80% RTE gerekend omdat afhankelijk van de stroomprijs die je door 0,8 deelt in jouw geval het verschil in de hogere regionen ook groter wordt.
Voorbeeld:
Situatie 1: basisprijs incl. alle belastingen etc. = 15cent (0cent kale prijs); als je dit met rte omrekent kom je op 18,75 cent ; 12 cent meer dan 15 cent is 27 cent; 18,75 cent is 8,25 cent goedkoper dan 27 cent
Situatie 2: basisprijs incl alle belastingen etc. = 35cent (12cent kale prijs); als je dit met rte omrekent kom je op 43,75 ; 12 cent meer dan 35 is 47 cent; 43,75 is nog maar 3,25 cent goedkoper dan 47.

Het scheelt dat jij met 80% rekent (bij 75% ziet het er al anders uit; misschien moet ik mij parameter van RTE ook maar naar 80% zetten, want dat haal ik zelf ook over de grote aantallen dagen heen, maar er zijn hier ook mensen die een lagere RTE posten omdat ze maar met kleine Wattages ontladen !!).
Maar goed als je het in een computerprogramma zoals ik hebt zitten is het niet zo'n issue om steeds exact te rekenen, maar jouw rule-of-thumb van 12 cent verschil tussen de incl. prijzen is wel binnen een bepaald spectrum goed te hanteren . Ik wilde vooral aangeven dat een ogenschijnlijke goedkopere prijs om te laden effectief tot dezelfde prijs als de maximumprijs kan leiden.

[S2S]

Erik1805 schreef op woensdag 24 september 2025 @ 11:33:
[...]

Als je vandaag kijkt (ik zit bij Tibber) dan is de stroom op de goedkope uren 14,8ct en in de avond 28,9ct. Lijkt mij voldoende verschil. Of mis ik ergens iets? Dan lijkt het mij voordelig te laden en in de avond/nacht te gebruiken.

Ja is prima, vanaf 14 cent verschil. Staat bij mij altijd op AI, is vaak centen werk. Je moet meer naar het grotere plaatje kijken . Is een plug and play, persoonlijk ga ik er zelf geen automation aanhangen. En dan verdien ik er nog zat mee , met zon opvangen en goedkopere momenten laden .

[ Voor 19% gewijzigd door S2S op 24-09-2025 11:55 ]

[antoinevromen]

Erik1805 schreef op woensdag 24 september 2025 @ 11:33:
[...]

Als je vandaag kijkt (ik zit bij Tibber) dan is de stroom op de goedkope uren 14,8ct en in de avond 28,9ct. Lijkt mij voldoende verschil. Of mis ik ergens iets? Dan lijkt het mij voordelig te laden en in de avond/nacht te gebruiken.

@Erik1805 Jazeker volkomen correct. Ook al zoals hierboven @olympusdenk schreef kun je als je je niet suf wilt rekenen uitgaan van 12 cent verschil dat er minimaal moet zijn tussen minimum-prijs en maximum-prijs. Dus vandaag is een prima dag om bij te laden.

De economische mierenneuker-stem in mij zegt natuurlijk dat als je meer bijlaadt dan je in dat dure-uur gaat verbruiken, dan moet je eigenlijk ook 12 cent verschil hebben met de uren die na dat duurste uur komen, want die heb je ook aan 80% RTE-verlies geladen ;-)

[antoinevromen]

pascallj schreef op woensdag 24 september 2025 @ 11:37:
[...]
Bij het laden van Tweakers hoef ik ook niet 3 keer op F5 te drukken voordat de pagina binnenkomt.

Slecht voorbeeld (paar dagen geleden lag tweakers er een tijdje uit ; Toen hielp 3x F5 ook niet ;-)

[ Voor 4% gewijzigd door antoinevromen op 24-09-2025 12:01 ]

[olympusdenk]

antoinevromen schreef op woensdag 24 september 2025 @ 11:58:
[...] als je meer bijlaadt dan je in dat dure-uur gaat verbruiken, dan moet je eigenlijk ook 12 cent verschil hebben met de uren die na dat duurste uur komen, want die heb je ook aan 80% RTE-verlies geladen ;-)

Wat jij specifiek zegt of je het nou zelf gebruikt of de kWh het net op ontlaad klopt wel inderdaad.

Als je ..
- dynamisch contract
- zolang saldering nog actief is (31-12-2026)
- en zoals bij Zonneplan dat je opslag ook mag salderen dus terugkrijgt
.. en de MT 'teruglevert' moet je goed opletten dat het verschil inderdaad wel groter zijn dan 12 cent (of 14 cent wat je wil)

Dat is eigenlijk ook de reden dat ik hier met mijn dynamische energiecontract de komende 14,5 maanden de MT de 2 á 3 goedkoopste uren laat laden en de 1 á 3 duurste uren laat terugleveren (en alleen als het prijsverschil tussen hoogste en laagste uur dus inderdaad hoog genoeg is).

---

Wel leuk om alvast mede te delen, is nog in een vroeg stadium maar ik ben nu bezig met een Home Assistant plugin die automatisch de schema's hiervoor instelt tussen 0:00 - 12:00 en tussen 12:00 - 23:59 en beheert wanneer de MT op manuele modus moet staan. Deze schema's die schrijf ik via de entities die HameRelay HA plugin weggeschreven naar de MT.

Voor natuurlijk de Tweakers hier om alvast een beetje een idee te geven, hier een stukje van HA yaml config die door de data van cheapest-energy-hours Jinja door goedkope en dure uren heenloopt, de MT op manuele modus zet en manuele (ont)laad schema vult:

[ Voor 8% gewijzigd door olympusdenk op 24-09-2025 14:38 . Reden: Even Mac adres van MT uit de screenshot ]

[vifra]

raar gedrag sinds 10 uur vanaag ... mijn CT003 leest de meter nog mooi uit, is geconnecteerd aan de venus E - maar dde venus E ontvangt de updates niet ... netwerk top, niets verandert, ....

Al alles herstart en zelfde problematiek ...

iemand idee ?

[antoinevromen]

olympusdenk schreef op woensdag 24 september 2025 @ 12:45:
[...]

Wat jij specifiek zegt of je het nou zelf gebruikt of de kWh het net op ontlaad klopt wel inderdaad.

Als je ..
- dynamisch contract
- zolang saldering nog actief is (31-12-2026)
- en zoals bij Zonneplan dat je opslag ook mag salderen dus terugkrijgt
.. en de MT 'teruglevert' moet je goed opletten dat het verschil inderdaad wel groter zijn dan 12 cent (of 14 cent wat je wil)

Dat is eigenlijk ook de reden dat ik hier met mijn dynamische energiecontract de komende 14,5 maanden de MT de 2 á 3 goedkoopste uren laat laden en de 1 á 3 duurste uren laat terugleveren (en alleen als het prijsverschil tussen hoogste en laagste uur dus inderdaad hoog genoeg is).

---

Wel leuk om alvast mede te delen, is nog in een vroeg stadium maar ik ben nu bezig met een Home Assistant plugin die automatisch de schema's hiervoor instelt tussen 0:00 - 12:00 en tussen 12:00 - 23:59 en beheert wanneer de MT op manuele modus moet staan. Deze schema's die schrijf ik via de entities die HameRelay HA plugin weggeschreven naar de MT.

Voor natuurlijk de Tweakers hier om alvast een beetje een idee te geven, hier een stukje van HA yaml config die door de data van cheapest-energy-hours Jinja door goedkope en dure uren heenloopt, de MT op manuele modus zet en manuele (ont)laad schema vult:

[Afbeelding]

@olympusdenk ; Knap dat je datzelfde ook in Home Assistant bent aan het "programmeren". Home Assistant is voor mij een te stijle leercurve om me hierin te verdiepen, maar ik zie wel de parallellen die je trekt met hetgeen ik doe met scripts. De dag verdelen in 0-12 en 12-24 waarin dan bij beiden een min en een max valt.
Heb je ook al logica overwogen om bijv. wanneer je op moment x een bepaalde soc hebt die voldoende zou moeten zijn om de dure uren door te komen, maar niet genoeg is om vanaf moment x tot aan de dure uren te geraken EN het loont niet om op het minimum-uur op te laden dat je de batterij dan in Passive zet?
Zo ben ik op nog meer strategien gestuit die ik heb ingebouwd. Kunnen we van gedachten over wisselen hier op het forum (maar misschien is dat meer voor het forum Marstek PIB Domotica integratie en je Energierekening )

[ Voor 5% gewijzigd door antoinevromen op 24-09-2025 13:16 ]

[Hemmik]

vifra schreef op woensdag 24 september 2025 @ 12:58:
raar gedrag sinds 10 uur vanaag ... mijn CT003 leest de meter nog mooi uit, is geconnecteerd aan de venus E - maar dde venus E ontvangt de updates niet ... netwerk top, niets verandert, ....

Al alles herstart en zelfde problematiek ...

iemand idee ?

hen ik hier ook sinds vorige week, nu maar weer verbonden de HomeWizard. Kan in de app de CT03 gewoon zien, werkt prima, maar als ik heb probeer te verbinden met de Venus staat hij op offline. Heeft half jaar prima gewerkt, niets veranderd maar werkt niet meer.

[antoinevromen]

Hemmik schreef op woensdag 24 september 2025 @ 13:18:
[...]

hen ik hier ook sinds vorige week, nu maar weer verbonden de HomeWizard. Kan in de app de CT03 gewoon zien, werkt prima, maar als ik heb probeer te verbinden met de Venus staat hij op offline. Heeft half jaar prima gewerkt, niets veranderd maar werkt niet meer.

Hallo @vifra @Hemmik ,
Misschien handig als jullie je signature (o.a. versies van softwarecomponenten en hardware) zouden invullen. Misschien is er een parallel te zien in de versies van de EM/BM/comm ; Nu is er weinig van te zeggen hier op het forum.

[PNARI]

olympusdenk schreef op woensdag 24 september 2025 @ 12:45:
[...]

Wat jij specifiek zegt of je het nou zelf gebruikt of de kWh het net op ontlaad klopt wel inderdaad.

Als je ..
- dynamisch contract
- zolang saldering nog actief is (31-12-2026)
- en zoals bij Zonneplan dat je opslag ook mag salderen dus terugkrijgt
.. en de MT 'teruglevert' moet je goed opletten dat het verschil inderdaad wel groter zijn dan 12 cent (of 14 cent wat je wil)

Dat is eigenlijk ook de reden dat ik hier met mijn dynamische energiecontract de komende 14,5 maanden de MT de 2 á 3 goedkoopste uren laat laden en de 1 á 3 duurste uren laat terugleveren (en alleen als het prijsverschil tussen hoogste en laagste uur dus inderdaad hoog genoeg is).

---

Wel leuk om alvast mede te delen, is nog in een vroeg stadium maar ik ben nu bezig met een Home Assistant plugin die automatisch de schema's hiervoor instelt tussen 0:00 - 12:00 en tussen 12:00 - 23:59 en beheert wanneer de MT op manuele modus moet staan. Deze schema's die schrijf ik via de entities die HameRelay HA plugin weggeschreven naar de MT.

Voor natuurlijk de Tweakers hier om alvast een beetje een idee te geven, hier een stukje van HA yaml config die door de data van cheapest-energy-hours Jinja door goedkope en dure uren heenloopt, de MT op manuele modus zet en manuele (ont)laad schema vult:

[Afbeelding]

Het gemiddelde prijsverschil in 2024 tussen min en max uurprijs is +/- 10cte in België dus eigenlijk niet rendabel om batterij daarmee te verslijten effe los van captar maar twee batterijen die gelijktijdig laden veroorzaken ook een piek.

[vifra]

vifra schreef op woensdag 24 september 2025 @ 12:58:
raar gedrag sinds 10 uur vanaag ... mijn CT003 leest de meter nog mooi uit, is geconnecteerd aan de venus E - maar dde venus E ontvangt de updates niet ... netwerk top, niets verandert, ....

Al alles herstart en zelfde problematiek ...

iemand idee ?

ondertussen terug aan de praat ... strange behaviour ...

[S-ven]

Voor hen die een V3+CT003 hebben en de info willen rapporteren in Home Assistant via de lokale API op poort 30000, ik heb een python script geschreven dat je kan downloaden hier https://gist.github.com/s...7b81104ae441b217a669e55d7

Dit copieer je naar HA in /root/config/scripts (directory moet je eerst aanmaken) en pas het IP adres aan naar dat van jouw batterij.
DEFAULT_IP = "xxx.xxx.xxx.xxx"

Je kan het eerst manueel testen om te controleren dat alles goed werkt:

code:

python3 /root/config/scripts/marstek_udp_client_all_v3.py --no-pretty --timeout 3 --retries 2 es-mode                  
{"id":1,"src":"VenusE 3.0-60323b7536fd","result":{"id":0,"mode":"Auto","ongrid_power":-450,"offgrid_power":0,"bat_soc":68}}

In het script kan je alle API methods callen zoals wifi-status, bat-status, ... Ik ben enkel geïnteresseerd in SoC, charging/discharging Power en daarvoor is de method es-mode meer dan genoeg (ook merk ik dat de andere minder stabiel zijn)

In configuration.yaml heb ik toegevoegd:

code:

# COMMAND LINE
command_line:
  sensor:
    name: Marstek ES Raw      
    command: "python3 /config/scripts/marstek_udp_client_all_v3.py --no-pretty --timeout 3 --retries 2 es-mode"
    command_timeout: 20                    
    scan_interval: 30
    value_template: >-
      {{ (value_json.result.state if value_json is defined and value_json.result is defined and 'state' in value_json.result else 'ok') }}
    json_attributes:
      - result  

template:
  - sensor:
      - name: "Marstek Mode"
        state: >
          {% set r = state_attr('sensor.marstek_es_raw','result') %}
          {{ r.mode if r else none }}

      - name: "Marstek Mode Battery SOC"
        unit_of_measurement: "%"
        device_class: battery
        state_class: measurement
        state: >
          {% set r = state_attr('sensor.marstek_es_raw','result') %}
          {{ r.bat_soc if r else none }}

      - name: "Marstek On-grid Power"
        unit_of_measurement: "W"
        device_class: power
        state_class: measurement
        state: >
          {% set r = state_attr('sensor.marstek_es_raw','result') %}
          {{ (r.ongrid_power | abs) if r else none }}

      - name: "Marstek Off-grid Power"
        unit_of_measurement: "W"
        device_class: power
        state_class: measurement
        state: >
          {% set r = state_attr('sensor.marstek_es_raw','result') %}
          {{ (r.offgrid_power | abs) if r else none }}

Ik gebruik "abs" omdat ik de waardes graag positief zie in mijn grafiek (charge discharge onderscheidt ik door kleuren groen/rood)

Dan HA restart en in developer tools verschijnen de nieuwe sensors


Wat mini-graph-cards aanmaken:

SoC:

code:

type: custom:mini-graph-card
name: Battery Charge
entities:
  - sensor.marstek_mode_battery_soc
hours_to_show: 24
points_per_hour: 12
line_width: 2
height: 100
color_thresholds:
  - value: 0
    color: "#ff0000"
  - value: 20
    color: "#ff8400"
  - value: 40
    color: "#ffdd00"
  - value: 60
    color: e5ff00
  - value: 80
    color: 2bff00

Charge/Discharge

code:

type: custom:mini-graph-card
name: Battery Power
entities:
  - entity: sensor.marstek_on_grid_power
    name: Charging
    color: green
    show_state: true
    align_state: center
    show_indicator: true
  - entity: sensor.marstek_off_grid_power
    name: Discharging
    color: red
    show_state: true
    align_state: center
    show_indicator: true
hours_to_show: 24
points_per_hour: 12
line_width: 2
height: 100

en dan zie ik op mijn dashboard


I heb gemerkt dat dit véél correcter is dan de Marstek app. Die geeft soms foutieve info (slechte verbinding naar cloud?).

PS: Ook wil ik even meegeven dat ik vaak in de app precies geen communicatie heb tussen de batterij en de CT003, maar als ik naar deze waardes kijk en vooral naar de totale import/export op P1 (ik heb ook nog een andere P1 lezer) dat het perfect werkt in de achtergrond. Volgens mij is de App buggy, niet de communicatie tussen de batterij en de CT003

[ Voor 5% gewijzigd door S-ven op 24-09-2025 15:31 ]

[3DWim]

S-ven schreef op woensdag 24 september 2025 @ 15:27:
Voor hen die een V3+CT003 hebben en de info willen rapporteren in Home Assistant via de lokale API op poort 30000, ik heb een python script geschreven dat je kan downloaden hier https://gist.github.com/s...7b81104ae441b217a669e55d7

Top hoewel ik geen V3 heb lees ik dit soort berichten graag.
Ik vind het een mooie ontwikkeling.
Wat ik bij de V2 mis is een RTE optie. Die heb ik ondertussen wel via @dannyro maar wellicht ook voor deze toepassing interessant.
Indien gewenst eventueel met die van HW op basis van P1 info ook er bij als vergelijk.

[JB70]

Ik moet nog 60 pagina's doorakkeren omdat ik vakantie heb gehad, dus als dit al voorbij is gekomen dan alvast sorry (en haal ik mijn vraag weer weg).
Maar alle schermafdrukken van de app die ik voorbij zie komen zie ik (nog) bij niemand dat gele schildje rechtsboven. "Uw garantie is geactiveerd".
Overigens heb ik de Marstek V1 al zeker een half jaar, heb dat vinkje nooit eerder gehad.
Had hem wel netjes geregistreerd, maar moest blijkbaar (na het klikken van het vinkje) nog mijn aankoopbewijs uploaden. Beetje laat, maar toch maar gedaan (als het niet al te laat is :-))

[3DWim]

@JB70 Zit hem in die laatste 60 pagina's ;-)
Het is de laatste zichtbare aanpassing van de app. En het is hier al wel breeduit besproken. Vooral het feit wel/niet uploaden.
Bij nwe registraties wordt de ingestuurde info wel bekeken, althans dat wordt gesuggereerd. Bij iedereen die al lang een accu heeft maakt het niets uit wat je upload.

[tweeek]

JB70 schreef op woensdag 24 september 2025 @ 16:14:
Ik moet nog 60 pagina's doorakkeren omdat ik vakantie heb gehad, dus als dit al voorbij is gekomen dan alvast sorry (en haal ik mijn vraag weer weg).
Maar alle schermafdrukken van de app die ik voorbij zie komen zie ik (nog) bij niemand dat gele schildje rechtsboven. "Uw garantie is geactiveerd".
Overigens heb ik de Marstek V1 al zeker een half jaar, heb dat vinkje nooit eerder gehad.
Had hem wel netjes geregistreerd, maar moest blijkbaar (na het klikken van het vinkje) nog mijn aankoopbewijs uploaden. Beetje laat, maar toch maar gedaan (als het niet al te laat is :-))

[Afbeelding]

Een eerdere registratie gaf in ieder geval "gouden"/"gele"schildje, in hoeverre aankoopbewijs uploaden noodzakelijk is mij niet helemaal duidelijk. (aanpassing van paar weken geleden)

[Yargo]

Hier al een tijdje 2 Martek's Venus v2 in gebruik. Vandaag heb ik toch iets bizar voor.

Terwijl 1 batterij net niet volledig vol is geladen (enkel dmv zonnepanelen), staat de andere nogmaar op 54 procent. Dit terwijl ze normaal gezien ongeveer samen opladen.

Ook op de grafieken van HW zie je dat de tweede batterij merkbaar minder energie toegewezen kreeg.

Hebben jullie dit al voorgehad?

[ Voor 4% gewijzigd door Yargo op 24-09-2025 16:28 ]

[Stef CB]

Maandag de Marstek V2 besteld via solarnrg.nl en vandaag (woensdag) om 15u netjes geleverd aan de voordeur.

Zelf alleen de batterij naar boven gedragen, trap per trap. Eens boven de wieltjes gemonteerd en geïnstalleerd + update uitgevoerd. Alles samen in 10min gepiept en nog even de laatste zon van de dag kunnen meepakken.

Benieuwd hoe het verloopt.

[ Voor 4% gewijzigd door Stef CB op 24-09-2025 17:40 ]

[Stef CB]

S-ven schreef op woensdag 24 september 2025 @ 15:27:
Voor hen die een V3+CT003 hebben en de info willen rapporteren in Home Assistant via de lokale API op poort 30000, ik heb een python script geschreven dat je kan downloaden hier https://gist.github.com/s...7b81104ae441b217a669e55d7

Dit copieer je naar HA in /root/config/scripts (directory moet je eerst aanmaken) en pas het IP adres aan naar dat van jouw batterij.
DEFAULT_IP = "xxx.xxx.xxx.xxx"

Je kan het eerst manueel testen om te controleren dat alles goed werkt:

code:

python3 /root/config/scripts/marstek_udp_client_all_v3.py --no-pretty --timeout 3 --retries 2 es-mode                  
{"id":1,"src":"VenusE 3.0-60323b7536fd","result":{"id":0,"mode":"Auto","ongrid_power":-450,"offgrid_power":0,"bat_soc":68}}

In het script kan je alle API methods callen zoals wifi-status, bat-status, ... Ik ben enkel geïnteresseerd in SoC, charging/discharging Power en daarvoor is de method es-mode meer dan genoeg (ook merk ik dat de andere minder stabiel zijn)

In configuration.yaml heb ik toegevoegd:

code:

# COMMAND LINE
command_line:
  sensor:
    name: Marstek ES Raw      
    command: "python3 /config/scripts/marstek_udp_client_all_v3.py --no-pretty --timeout 3 --retries 2 es-mode"
    command_timeout: 20                    
    scan_interval: 30
    value_template: >-
      {{ (value_json.result.state if value_json is defined and value_json.result is defined and 'state' in value_json.result else 'ok') }}
    json_attributes:
      - result  

template:
  - sensor:
      - name: "Marstek Mode"
        state: >
          {% set r = state_attr('sensor.marstek_es_raw','result') %}
          {{ r.mode if r else none }}

      - name: "Marstek Mode Battery SOC"
        unit_of_measurement: "%"
        device_class: battery
        state_class: measurement
        state: >
          {% set r = state_attr('sensor.marstek_es_raw','result') %}
          {{ r.bat_soc if r else none }}

      - name: "Marstek On-grid Power"
        unit_of_measurement: "W"
        device_class: power
        state_class: measurement
        state: >
          {% set r = state_attr('sensor.marstek_es_raw','result') %}
          {{ (r.ongrid_power | abs) if r else none }}

      - name: "Marstek Off-grid Power"
        unit_of_measurement: "W"
        device_class: power
        state_class: measurement
        state: >
          {% set r = state_attr('sensor.marstek_es_raw','result') %}
          {{ (r.offgrid_power | abs) if r else none }}

Ik gebruik "abs" omdat ik de waardes graag positief zie in mijn grafiek (charge discharge onderscheidt ik door kleuren groen/rood)

Dan HA restart en in developer tools verschijnen de nieuwe sensors
[Afbeelding]

Wat mini-graph-cards aanmaken:

SoC:

code:

type: custom:mini-graph-card
name: Battery Charge
entities:
  - sensor.marstek_mode_battery_soc
hours_to_show: 24
points_per_hour: 12
line_width: 2
height: 100
color_thresholds:
  - value: 0
    color: "#ff0000"
  - value: 20
    color: "#ff8400"
  - value: 40
    color: "#ffdd00"
  - value: 60
    color: e5ff00
  - value: 80
    color: 2bff00

Charge/Discharge

code:

type: custom:mini-graph-card
name: Battery Power
entities:
  - entity: sensor.marstek_on_grid_power
    name: Charging
    color: green
    show_state: true
    align_state: center
    show_indicator: true
  - entity: sensor.marstek_off_grid_power
    name: Discharging
    color: red
    show_state: true
    align_state: center
    show_indicator: true
hours_to_show: 24
points_per_hour: 12
line_width: 2
height: 100

en dan zie ik op mijn dashboard
[Afbeelding]

I heb gemerkt dat dit véél correcter is dan de Marstek app. Die geeft soms foutieve info (slechte verbinding naar cloud?).

PS: Ook wil ik even meegeven dat ik vaak in de app precies geen communicatie heb tussen de batterij en de CT003, maar als ik naar deze waardes kijk en vooral naar de totale import/export op P1 (ik heb ook nog een andere P1 lezer) dat het perfect werkt in de achtergrond. Volgens mij is de App buggy, niet de communicatie tussen de batterij en de CT003

Ik heb HA maar ben geen professional zeg maar. Is het mogelijk dat je dit in HACS toevoegt of dergelijke?

[Druppeltje_]

Yargo schreef op woensdag 24 september 2025 @ 16:27:
Hier al een tijdje 2 Martek's Venus v2 in gebruik. Vandaag heb ik toch iets bizar voor.

Terwijl 1 batterij net niet volledig vol is geladen (enkel dmv zonnepanelen), staat de andere nogmaar op 54 procent. Dit terwijl ze normaal gezien ongeveer samen opladen.

Ook op de grafieken van HW zie je dat de tweede batterij merkbaar minder energie toegewezen kreeg.

Hebben jullie dit al voorgehad?

[Afbeelding]

[Afbeelding]

Dagelijks eigenlijk..
De ene dag is het mooi verdeeld tussen de 2MT's, de andere dag kan daar behoorlijk veel verschil inzitten. Met ontladen is dat idem. Deze nacht was er eentje aan het terugleveren aan 500W, de andere stond in standby. Wat resulteerde in eentje die vanmorgen op 11% stond, en de andere op 42%.
Toen ik ze net had heb ik hier lang een ''denkwijze'' proberen achter te zoeken. Heb die niet gevonden. Morgen kan het zomaar evenredig verdeeld zijn, overmorgen net weer andersom. Geen flauw idee hoe die verdeelsleutel softwarematig is opgesteld. Het is hier eigenlijk maar zelden dat ze mooi 50/50 verdeeld werken.

[AUijtdehaag]

Stef CB schreef op woensdag 24 september 2025 @ 17:43:
[...]

Ik heb HA maar ben geen professional zeg maar. Is het mogelijk dat je dit in HACS toevoegt of dergelijke?

Is voor de V3 staat er.

M5stack Atom modbus "plug en play" eraan hangen?

[antoinevromen]

Druppeltje_ schreef op woensdag 24 september 2025 @ 17:51:
[...]


Dagelijks eigenlijk..
De ene dag is het mooi verdeeld tussen de 2MT's, de andere dag kan daar behoorlijk veel verschil inzitten. Met ontladen is dat idem. Deze nacht was er eentje aan het terugleveren aan 500W, de andere stond in standby. Wat resulteerde in eentje die vanmorgen op 11% stond, en de andere op 42%.
Toen ik ze net had heb ik hier lang een ''denkwijze'' proberen achter te zoeken. Heb die niet gevonden. Morgen kan het zomaar evenredig verdeeld zijn, overmorgen net weer andersom. Geen flauw idee hoe die verdeelsleutel softwarematig is opgesteld. Het is hier eigenlijk maar zelden dat ze mooi 50/50 verdeeld werken.

Misschien is het zo juist "as designed" om te voorkomen dat beiden een laag vermogen moeten leveren en het beter is om 1 leeg te trekken als er niet voldoende vraag is?

[tweeek]

Druppeltje_ schreef op woensdag 24 september 2025 @ 17:51:
[...]


Dagelijks eigenlijk..
De ene dag is het mooi verdeeld tussen de 2MT's, de andere dag kan daar behoorlijk veel verschil inzitten. Met ontladen is dat idem. Deze nacht was er eentje aan het terugleveren aan 500W, de andere stond in standby. Wat resulteerde in eentje die vanmorgen op 11% stond, en de andere op 42%.
Toen ik ze net had heb ik hier lang een ''denkwijze'' proberen achter te zoeken. Heb die niet gevonden. Morgen kan het zomaar evenredig verdeeld zijn, overmorgen net weer andersom. Geen flauw idee hoe die verdeelsleutel softwarematig is opgesteld. Het is hier eigenlijk maar zelden dat ze mooi 50/50 verdeeld werken.

Is samenwerken als in elkaar niet tegenwerken (laden van de ene naar de andere) en dat het synchroon lopen mooie droom is?

[dannyro]

AUijtdehaag schreef op woensdag 24 september 2025 @ 18:17:
[...]

Is voor de V3 staat er.

M5stack Atom modbus "plug en play" eraan hangen?

En dan pas begint de fun😂

[tdolder]

tweeek schreef op woensdag 24 september 2025 @ 18:35:
[...]

Is samenwerken als in elkaar niet tegenwerken (laden van de ene naar de andere) en dat het synchroon lopen mooie droom is?

Bij mij lopen ze mooi cynchroon :-)

[Druppeltje_]

antoinevromen schreef op woensdag 24 september 2025 @ 18:24:
[...]

Misschien is het zo juist "as designed" om te voorkomen dat beiden een laag vermogen moeten leveren en het beter is om 1 leeg te trekken als er niet voldoende vraag is?

Heb ik ook een tijd gedacht. Maar op het moment dat je dat denkt, dan lopen ze 5 dagen achter elkaar synchroon, ook bij lage vraag
Ik lig er alleszins niet wakker van. Ik ben nog elke dag blij en dik tevreden met de batterijtjes.

[Druppeltje_]

tweeek schreef op woensdag 24 september 2025 @ 18:35:
[...]

Is samenwerken als in elkaar niet tegenwerken (laden van de ene naar de andere) en dat het synchroon lopen mooie droom is?

Tegenwerken heb ik hier nog geen enkele keer voor gehad.
Synchroon lopen of niet, mij maakt dat echt helemaal niet uit. Ze moeten mijn verbruik op 0 houden, of indien dat niet lukt toch zo veel mogelijk minimaliseren. En dat doen ze perfect.

[tweeek]

Druppeltje_ schreef op woensdag 24 september 2025 @ 19:02:
[...]


Tegenwerken heb ik hier nog geen enkele keer voor gehad.
Synchroon lopen of niet, mij maakt dat echt helemaal niet uit. Ze moeten mijn verbruik op 0 houden, of indien dat niet lukt toch zo veel mogelijk minimaliseren. En dat doen ze perfect.

Het tegenwerken komt soms wel eens voorbij, 0 haal ik niet tot nog toe rond 1 kw per dag, en dat vind ik ook prima, en ben zeker ook tevreden met de ene die ik heb.

[Druppeltje_]

tweeek schreef op woensdag 24 september 2025 @ 19:06:
[...]

Het tegenwerken komt soms wel eens voorbij, 0 haal ik niet tot nog toe rond 1 kw per dag, en dat vind ik ook prima, en ben zeker ook tevreden met de ene die ik heb.

Ah je bedoeld echt letterlijk 0? Neen 0 haal ik ook niet. Niemand haalt dat bij de gewone NOM instelling denk ik. Maar zoals ik, met een dagelijks verbruik tussen de 10 en 15kWh per dag, terugvallen naar 0,8kWh.. dan kan ik concluderen dat ze hun werk goed doen.

[tweeek]

Druppeltje_ schreef op woensdag 24 september 2025 @ 19:15:
[...]

Ah je bedoeld echt letterlijk 0? Neen 0 haal ik ook niet. Niemand haalt dat bij de gewone NOM instelling denk ik. Maar zoals ik, met een dagelijks verbruik tussen de 10 en 15kWh per dag, terugvallen naar 0,8kWh.. dan kan ik concluderen dat ze hun werk goed doen.

Lager is bij mij met de standaard NOM instelling niet te halen, met jou verbruik is dat helemaal prima als je dat kan terugbrengen naar 0.8, hier van een 4kwh naar 1 in zomerse situatie die snel aan het veranderen is
Doel van effectief gebruik maken van zonnestroom en minimaliseren van terugleverkosten is bereikt met de marstek venus.

[DSSW]

Yargo schreef op woensdag 24 september 2025 @ 16:27:
Hier al een tijdje 2 Martek's Venus v2 in gebruik. Vandaag heb ik toch iets bizar voor.

Terwijl 1 batterij net niet volledig vol is geladen (enkel dmv zonnepanelen), staat de andere nogmaar op 54 procent. Dit terwijl ze normaal gezien ongeveer samen opladen.

Ook op de grafieken van HW zie je dat de tweede batterij merkbaar minder energie toegewezen kreeg.

Hebben jullie dit al voorgehad?

[Afbeelding]

[Afbeelding]

Ik heb dat alle dagen voor met mijn 3 batterijen maar ik lig daar niet wakker van. De ene dag is het de ene batterij de andere dag een andere.

[djdj105]

pascallj schreef op woensdag 24 september 2025 @ 11:37:
[...]

Het gaat te ver om hier alle ins en outs te bespreken, maar met 'retries' krijg ik het ook stabiel genoeg binnen en mis ik bijna niets, alleen het feit dat je die nodig hebt, wil dus zeggen dat de er iets niet stabiel is. Bij het laden van Tweakers hoef ik ook niet 3 keer op F5 te drukken voordat de pagina binnenkomt.

Het protocol loopt over UDP, dus geen enkele garantie dat de pakketjes (heen of terug) ook werkelijk worden afgeleverd. Het inbouwen van retries is denk ik daarom onvermijdelijk

[Chris96]

Weet niet of deze video al geplaatst was maar hierbij een review van de marstek venus V3 waarbij de marstek ook open gaat:

YouTube: Marstek Venus E 3.0 - AC gekoppelter Speicher zur Erweiterung deiner...

[Taro]

Chris96 schreef op woensdag 24 september 2025 @ 21:15:
Weet niet of deze video al geplaatst was maar hierbij een review van de marstek venus V3 waarbij de marstek ook open gaat:

YouTube: Marstek Venus E 3.0 - AC gekoppelter Speicher zur Erweiterung deiner...

Heb zojuist in het Venus A / D topic ook de binnenkant van de Venus D gepost, zelfde IP65 smurrie:

[Taro]

Heb het Venus A & D topic aan de topicwaarschuwing toegevoegd: Hame Marstek Venus A & D - plug and play solar batterij.

[DSSW]

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


Vandaag wat heen en weer gemaild met de ontwikkelaar. Met de laatste versie is dit mogelijk:

[Afbeelding]

Hoe krijg ik dat in HA?

[3DWim]

Druppeltje_ schreef op woensdag 24 september 2025 @ 19:15:
[...]
Ah je bedoeld echt letterlijk 0? Neen 0 haal ik ook niet. Niemand haalt dat bij de gewone NOM instelling denk ik.

Nu dacht ik meteen: waar staat de stand bij mij op:



Totaal volgens HW P1.
Niet helemaal eerlijk maar schommelt nu rond +/-5W, MT levert nu een kleine 300W.

[Druppeltje_]

3DWim schreef op woensdag 24 september 2025 @ 23:48:
[...]

Nu dacht ik meten waar staat e stand bij mij op:

[Afbeelding]

Totaal volgens HW P1.
Niet helemaal eerlijk maar schommelt nu rond +/-5W, MT levert nu een kleine 300W.

Ik had het over dagverbruik
De meter houdt hij hier zeer goed op 0.
Het kleine dagverbruik dat er is komt telkens van de reactietijden van de MT's/CT003.
Ik kom hier niet boven de 1kWh/dag daarmee... Als de batterijen volgeladen zijn tenminste. Met het ellendige weer van vandaag zijn de 2MT's op dit eigenste moment allebei leeg.

[hermlek]

Druppeltje_ schreef op woensdag 24 september 2025 @ 17:51:
[...]


Dagelijks eigenlijk..
De ene dag is het mooi verdeeld tussen de 2MT's, de andere dag kan daar behoorlijk veel verschil inzitten. Met ontladen is dat idem. Deze nacht was er eentje aan het terugleveren aan 500W, de andere stond in standby. Wat resulteerde in eentje die vanmorgen op 11% stond, en de andere op 42%.
Toen ik ze net had heb ik hier lang een ''denkwijze'' proberen achter te zoeken. Heb die niet gevonden. Morgen kan het zomaar evenredig verdeeld zijn, overmorgen net weer andersom. Geen flauw idee hoe die verdeelsleutel softwarematig is opgesteld. Het is hier eigenlijk maar zelden dat ze mooi 50/50 verdeeld werken.

Er is iets mis met de sturing van het gebruik met 2 v2 Marstek. Heb sinds een 2 tal weken, schat ik, een verbruik van de batterij die niet in verhouding staat. 2 marstek volgeladen - normaal gezien hou ik dan nog bijna 1 geladen Marstek in totaal over en nu is dat een pak minder echt een opvallend verschil. Ook heb ik aan de hand gehad dat op 1 batterij het ontladen doorgezakt is naar 4% van de batterij. En ik ben niet alleen. Mijn broer die heeft slechts 1 batterij en die heeft het doorzakken al 2 keer op 1 week tijd meegemaakt. Was al aan het denken dat tijdens het ontladen de verbinding met de ct003 is weggevallen maar ik verwacht toch dat in dergelijk geval het ontladen/laden stopgezet wordt.

[Sonero]

tdolder schreef op woensdag 24 september 2025 @ 18:57:
[...]

Bij mij lopen ze mooi cynchroon :-)

[Afbeelding]

Da’s een mooi dashboard.
Het batterij-deel hiervan, zelf gemaakt of is dit een standaard integratie?

[Druppeltje_]

hermlek schreef op donderdag 25 september 2025 @ 03:59:
[...]

Er is iets mis met de sturing van het gebruik met 2 v2 Marstek. Heb sinds een 2 tal weken, schat ik, een verbruik van de batterij die niet in verhouding staat. 2 marstek volgeladen - normaal gezien hou ik dan nog bijna 1 geladen Marstek in totaal over en nu is dat een pak minder echt een opvallend verschil. Ook heb ik aan de hand gehad dat op 1 batterij het ontladen doorgezakt is naar 4% van de batterij. En ik ben niet alleen. Mijn broer die heeft slechts 1 batterij en die heeft het doorzakken al 2 keer op 1 week tijd meegemaakt. Was al aan het denken dat tijdens het ontladen de verbinding met de ct003 is weggevallen maar ik verwacht toch dat in dergelijk geval het ontladen/laden stopgezet wordt.

Heb ik hier nog niet gemerkt. In normale omstandigheden gaat de batterij per direct in standby als hij de verbinding met de CT verliest. Wat bedoel je precies met ''het ontladen is doorgezakt naar 4%'' ? Hij ontlaadt verder dan 11% ?

[skyrip]

ik heb nu enkele dagen een V2 batterij thuis staan. Ik zie echter dat de accu heel vaak plots vanaf 40-30% ineens terugschiet naar 11%. Gisteren stond de accu zelfs met 53% in standby en na een beetje manueel ontladen schoot die binnen 2 minuten naar de 11%.
ook als ik kijk naar hoeveel energie de accu zegt te laden om van 11% naar 100% te gaan blijkt dit ook maar 3.5kwh te zijn.
ik zou verwachten dat het ongeveer 4.5 tot 5 kwh zou moeten kosten om volledig te laden.
Komt dit vaker voor of is mijn accu gewoon heel laag in capaciteit?

[olympusdenk]

skyrip schreef op donderdag 25 september 2025 @ 07:11:
ik heb nu enkele dagen een V2 batterij thuis staan. Ik zie echter dat de accu heel vaak plots vanaf 40-30% ineens terugschiet naar 11%. Gisteren stond de accu zelfs met 53% in standby en na een beetje manueel ontladen schoot die binnen 2 minuten naar de 11%.
ook als ik kijk naar hoeveel energie de accu zegt te laden om van 11% naar 100% te gaan blijkt dit ook maar 3.5kwh te zijn.
ik zou verwachten dat het ongeveer 4.5 tot 5 kwh zou moeten kosten om volledig te laden.
Komt dit vaker voor of is mijn accu gewoon heel laag in capaciteit?

Als eerste vraag, heb je hem simpelweg al wel eens één keer volledig volgeladen want de SoC % is niet meer dan een inschatting waarbij het periodiek volladen ervoor zorgt dat de MT betrouwbaar weet wat 100% is.

Grote kans dat dat het dus oplost, hier laad ik minstens elke week de MT volledig vol en de batterij SoC is eigenlijk altijd volledig betrouwbaar.

[skyrip]

ja de accu is de afgelopen week al meerdere keren volledig vol geladen, dit was namelijk ook de eerste gedachte die ik zelf ook had.

[vifra]

Chris96 schreef op woensdag 24 september 2025 @ 21:15:
Weet niet of deze video al geplaatst was maar hierbij een review van de marstek venus V3 waarbij de marstek ook open gaat:

YouTube: Marstek Venus E 3.0 - AC gekoppelter Speicher zur Erweiterung deiner...

dus als er iets deffect is dan is het sowieso een vervanging van het geheel ... (praktisch herstelbaar is dit niet). En dan maar hopen dat we 10 jaar (en meer) geen problemen hebben / als er problemen zijn marstek niet lastig doet ...

[tdolder]

Sonero schreef op donderdag 25 september 2025 @ 05:36:
[...]


Da’s een mooi dashboard.
Het batterij-deel hiervan, zelf gemaakt of is dit een standaard integratie?

Dank :-)
Dashboard heb ik zelf gemaakt met de entiteiten die door de integratie worden aangemaakt. Ik heb ook nog 2 dashboards gemaakt voor alleen de accu's. Daarnaast diverse automations voor laden en ontladen via modbus. Accu op standby als de auto gaat laden enz.

[johan_L]

Is het iemand gelukt om zijn Marstek accu aan te melden op energieleveren.nl? Bij mij lukt het niet omdat ik ook omvormer-gegevens moet invullen, die zijn er natuurlijk niet (of niet los te achterhalen)

[hermlek]

Druppeltje_ schreef op donderdag 25 september 2025 @ 06:07:
[...]


Heb ik hier nog niet gemerkt. In normale omstandigheden gaat de batterij per direct in standby als hij de verbinding met de CT verliest. Wat bedoel je precies met ''het ontladen is doorgezakt naar 4%'' ? Hij ontlaadt verder dan 11% ?

Klopt en dit is geen natuurlijke standby ontlading maar een bewuste ontlading door de stuursoftware. Idem bij mijn broer. Die heeft het al 2 keer aan de hand gehad. Er is duidelijk de laatste 3 weken iets veranderd. Batterij lijkt me ook niet zo efficient meer - het restant na de nacht bij 100 % lading zat vroeger rond de 45 % en dit voor elke batterij en nu kom ik rond de 25 % restant in elke batterij.

[hermlek]

johan_L schreef op donderdag 25 september 2025 @ 08:59:
Is het iemand gelukt om zijn Marstek accu aan te melden op energieleveren.nl? Bij mij lukt het niet omdat ik ook omvormer-gegevens moet invullen, die zijn er natuurlijk niet (of niet los te achterhalen)

zelfde gegevens invullen zoals het type van toestel. Er is geen aparte codering voor de Marstek omvormer omdat die geïntegreerd is in het toestel.

[S2S]

hermlek schreef op donderdag 25 september 2025 @ 09:02:
[...]

Klopt en dit is geen natuurlijke standby ontlading maar een bewuste ontlading door de stuursoftware. Idem bij mijn broer. Die heeft het al 2 keer aan de hand gehad. Er is duidelijk de laatste 3 weken iets veranderd. Batterij lijkt me ook niet zo efficient meer - het restant na de nacht bij 100 % lading zat vroeger rond de 45 % en dit voor elke batterij en nu kom ik rond de 25 % restant in elke batterij.

Ik merk hier geen verschil . Draait zoals de afgelopen 6 maanden (2 Marsteks) niet minder efficiënt geworden. Het kan ook aan je apparaten thuis liggen , is daar iets veranderd. Een warmtepomp bijvoorbeeld kan meer of minder wattage verbruiken naar hoe de buiten temperatuur is. (Voorbeeld )

[ Voor 11% gewijzigd door S2S op 25-09-2025 09:08 ]

[hermlek]

S2S schreef op donderdag 25 september 2025 @ 09:06:
[...]

Ik merk hier geen verschil . Draait zoals de afgelopen 6 maanden (2 Marsteks) niet minder efficiënt geworden.

welke sturing gebruik je - ik gebruik de zelfcomsumptie via ct003 van marstek want ik zie dat je ook een shelly hebt (heb ik ook maar enkel gebruikt om te testen)
Ik heb daar rekening mee gehouden door de warmtepompboiler in het tijdsbestek tussen 8 en 17 uur te zetten en mijn warmtepompdroogkast gebruik ik zelfs niet meer - terug ouderwets buiten op de droogmolen - werkt ook) En mijn verwarming staat niet op en is een pelletkachel dus als die opgestart is is het verbruik zeer laag.
Ik heb wel een stopcontact in de garage bijgezet zodat iedere batterij nu in 1 kamer geplaatst is zodat elke batterij wifi gebruikt op hetzelfde accespoint. (was in het verleden soms wel een probleem) Nu staan de batterijen elk op hun eigen fase en kring en de zonnepanelen staan op de laatste "vrije" fase"

[ Voor 46% gewijzigd door hermlek op 25-09-2025 09:19 ]

[d3x]

hermlek schreef op donderdag 25 september 2025 @ 09:02:
[...]

Klopt en dit is geen natuurlijke standby ontlading maar een bewuste ontlading door de stuursoftware. Idem bij mijn broer. Die heeft het al 2 keer aan de hand gehad. Er is duidelijk de laatste 3 weken iets veranderd. Batterij lijkt me ook niet zo efficient meer - het restant na de nacht bij 100 % lading zat vroeger rond de 45 % en dit voor elke batterij en nu kom ik rond de 25 % restant in elke batterij.

soc drift, komt aggresiever voor sinds de laatste BMS update, hebben we allemaal wel meer nu.
we gaan naar periode waar er minder zon zal zijn en dus ook die laatste % opladen niet altijd zal plaats vinden, dat heeft grote gevolgen voor het visuele rendement van je batterij. ik zet er visueel bij, want dat is het ook, je denkt via app dat hij 70-80% is maar dat is maar een perceptie. Enkel bij 100% geladen weet je dat hij echt vol is en idem voor de 11%, bij hercalibratie staat die dan ineens op maar 5-6-7-8%.

niet te veel naar kijken is mijn mening, het brengt niet op. Is er opladen - ontladen met een redelijke NOM, ok klaar. De echte batterij probleem gevallen zijn er vooral bij start, hier al enkele voorgekomen.

[bommel]

antoinevromen schreef op woensdag 24 september 2025 @ 11:29:
[...]

Toch raar; Ik draai het powershell-script nu al dagen achter elkaar (elk kwartier) geen uitval; En als ik de logica van het sturen aan het aanpassen/debuggen ben nog veel vaker ;-) . Wel zit in dat script een eerste "dummy" call naar Marstek.GetDevice (is nog van @bommel ) om de batterij "op te warmen". Daarnaast heeft @bommel ook een aantal retries (3x) ingebouwd wanneer er geen antwoord komt om dan een nieuwe call te doen; tenslotte (misschien is dat ook wel belangrijk zit er aan het einde van het script een soort weglezen van "te laat gekomen berichten", waardoor de antwoord-queue aan berichten weer leeg raakt aan het einde van het script.

Het blijft natuurlijk UDP, je verstuurt iets zonder wachten of garantie op antwoord. Lijkt er wel op dat de api draait op een thread met lage prioriteit of dat alle communicatie single threaded is oid.