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

[Driehoek]

Vraagje ivm de combinatie met het smart/solar laden van een wagen:

Er is meestal een EV ingeplugd met de oplader in solar mode. Van zodra er opbrengst is gaat de wagen beginnen laden en zorgt de lader voor NOM. Momenteel staat de Marstek ook ingesteld op NOM. Deze twee regelingen beinvloeden elkaar (uiteraard) en de regelingen beginnen bokkensprongen te maken omdat deze elkaar beinvloeden.
Is er aan de zijde van de Marstek iets mogelijk qua instellingen om dit gedrag tegen te gaan of moet ik de oplossing bij de EV lader zoeken?

Twee bijkomende issues:
1. Wanneer de Marstek volgeladen is met zonnestroom en stopt met laden gaat de EV weer voor NOM. De batterij "ziet" dat er verbruik is rond het nulpunt en langzaamaan begint de wagen meer en meer stroom te vragen en loopt de batterij helemaal leeg.
2. Wanneer de zonnepanelen niets opwekken probeert de Marstek NOM te regelen. De lader van de wagen ziet dit en begint te laden omdat deze vanaf 0A begint te laden met de minimale stroom.
Deze twee issues hoop ik opgelost te hebben door het laden van de wagen pas vanaf 3A te laten starten.


Is er een mogelijkheid om een capaciteitstarief te programmeren?

[mjvdzwet]

Driehoek schreef op zondag 25 januari 2026 @ 09:18:
Vraagje ivm de combinatie met het smart/solar laden van een wagen:

Er is meestal een EV ingeplugd met de oplader in solar mode. Van zodra er opbrengst is gaat de wagen beginnen laden en zorgt de lader voor NOM. Momenteel staat de Marstek ook ingesteld op NOM. Deze twee regelingen beinvloeden elkaar (uiteraard) en de regelingen beginnen bokkensprongen te maken omdat deze elkaar beinvloeden.
Is er aan de zijde van de Marstek iets mogelijk qua instellingen om dit gedrag tegen te gaan of moet ik de oplossing bij de EV lader zoeken?

Twee bijkomende issues:
1. Wanneer de Marstek volgeladen is met zonnestroom en stopt met laden gaat de EV weer voor NOM. De batterij "ziet" dat er verbruik is rond het nulpunt en langzaamaan begint de wagen meer en meer stroom te vragen en loopt de batterij helemaal leeg.
2. Wanneer de zonnepanelen niets opwekken probeert de Marstek NOM te regelen. De lader van de wagen ziet dit en begint te laden omdat deze vanaf 0A begint te laden met de minimale stroom.
Deze twee issues hoop ik opgelost te hebben door het laden van de wagen pas vanaf 3A te laten starten.


Is er een mogelijkheid om een capaciteitstarief te programmeren?

Ik gebruik zelf de SmartEVSE en een Marstek.
De auto krijgt via een eigen software implementatie voorrang op de Marstek. Als de auto onder een bepaald % lading zit mag deze opladen. Echter is er een drempel stroom ingesteld van 7A. Dus zolang de Marstek met minder dan 7A laad en niet vol is dan blijft de SmartEVSE in off stand. Zodra er meer wordt opgewekt zet ik de Marstek via Modbus op standby en de SmartEVSE aan. Totdat de auto vol is of de SmartEVSE stopt met laden omdat er onvoldoende zonnestroom is.

Het is een hele regeling. De auto laden uit de Marstek is door conversie verliezen zinloos voor mij.
En de auto is belangrijker dan de Marstek, voor mij.

[AUijtdehaag]

@Driehoek
Ik heb een soortgelijk iets, maar dan met een Aton power to heat element die gaat buffervat laden vanaf een ingestelde teruglevering op de meter.
Ik heb de waarden uit elkaar getrokken

Marstek heeft voorrang met 0 op de meter (instelling dus 0 watt)
Aton gaat pas vanaf -100 watt buffervat laden, dan botst dat niet.
Wat resulteert in eerst de batterij volladen en daarna pas het buffervat verwarmen bij overschot van de zon.

Maar daarbij komt dan het volgende probleem. Als ik dynamisch ga terugleveren met de batterijen omdat de dynamische prijs hoog is, gaat de Aton power to heat de buffer verwarmen want die ziet teruglevering. Ik verlaag dan maar handmatig de gewenste temperatuur zodat hij niet aan gaat. Niet ideaal (voor nu)

Ik heb de nodered code van Bob draaien.
Daar is met EV sturing (blokkeert de batterij) en capaciteitstarief (BE) al heel veel mogelijk.
Enige verdere wensen kunnen besproken worden op de discord server.
https://discord.gg/z9EzkjbApb

[pascallj]

Driehoek schreef op zondag 25 januari 2026 @ 09:18:
Vraagje ivm de combinatie met het smart/solar laden van een wagen:

Er is meestal een EV ingeplugd met de oplader in solar mode. Van zodra er opbrengst is gaat de wagen beginnen laden en zorgt de lader voor NOM. Momenteel staat de Marstek ook ingesteld op NOM. Deze twee regelingen beinvloeden elkaar (uiteraard) en de regelingen beginnen bokkensprongen te maken omdat deze elkaar beinvloeden.
Is er aan de zijde van de Marstek iets mogelijk qua instellingen om dit gedrag tegen te gaan of moet ik de oplossing bij de EV lader zoeken?

Twee bijkomende issues:
1. Wanneer de Marstek volgeladen is met zonnestroom en stopt met laden gaat de EV weer voor NOM. De batterij "ziet" dat er verbruik is rond het nulpunt en langzaamaan begint de wagen meer en meer stroom te vragen en loopt de batterij helemaal leeg.
2. Wanneer de zonnepanelen niets opwekken probeert de Marstek NOM te regelen. De lader van de wagen ziet dit en begint te laden omdat deze vanaf 0A begint te laden met de minimale stroom.
Deze twee issues hoop ik opgelost te hebben door het laden van de wagen pas vanaf 3A te laten starten.


Is er een mogelijkheid om een capaciteitstarief te programmeren?

Zonder koppeling tussen beide systemen is het technisch onmogelijk voor de Marstek om hier wat aan te doen. De batterij vertroebelt namelijk het onderscheid tussen batterijstroom en zonnestroom. Door bijvoorbeeld de laadpaal heel traag te laten reageren, kan je er wel voor zorgen dat het iets beter wordt, maar daarvoor zal je laadpaal zulke instellingen moeten hebben. Maar daar los je het schommelen als de batterij vol is niet mee op.

Zoals gezegd zal je daar slimmere koppelingen voor nodig hebben.

[Druppeltje_]

Driehoek schreef op zondag 25 januari 2026 @ 09:18:
Vraagje ivm de combinatie met het smart/solar laden van een wagen:

Er is meestal een EV ingeplugd met de oplader in solar mode. Van zodra er opbrengst is gaat de wagen beginnen laden en zorgt de lader voor NOM. Momenteel staat de Marstek ook ingesteld op NOM. Deze twee regelingen beinvloeden elkaar (uiteraard) en de regelingen beginnen bokkensprongen te maken omdat deze elkaar beinvloeden.
Is er aan de zijde van de Marstek iets mogelijk qua instellingen om dit gedrag tegen te gaan of moet ik de oplossing bij de EV lader zoeken?

Twee bijkomende issues:
1. Wanneer de Marstek volgeladen is met zonnestroom en stopt met laden gaat de EV weer voor NOM. De batterij "ziet" dat er verbruik is rond het nulpunt en langzaamaan begint de wagen meer en meer stroom te vragen en loopt de batterij helemaal leeg.
2. Wanneer de zonnepanelen niets opwekken probeert de Marstek NOM te regelen. De lader van de wagen ziet dit en begint te laden omdat deze vanaf 0A begint te laden met de minimale stroom.
Deze twee issues hoop ik opgelost te hebben door het laden van de wagen pas vanaf 3A te laten starten.


Is er een mogelijkheid om een capaciteitstarief te programmeren?

Herkenbaar probleem.
Ik heb dit opgelost door er in de winterperiode voor te zorgen dat MT en EV lader gewoon gescheiden zijn. Er is dan toch niet genoeg PV stroom om wat mee te doen. De MT's mogen het kleine beetje dat er is overdag opslaan en gebruiken. In de nacht word de wagen dan opgeladen en gaan de MT's gewoon in standby.
In de periodes dat de PV wel voldoende opbrengen stond de EV hier voorheen altijd op solarladen. Mijn lader start pas bij x aantal minuten minimaal 6A. Dit liep behoorlijk goed omdat de MT sneller reageerden dan de lader maar zo nu en dan kwamen die toch in elkaars vaarwater te zitten. Uiteindelijk voor een definitieve oplossing gekozen en via HA een eigen oplossing gemaakt. Het overschot van PV bereken ik nu zelf aan de hand van de PV stroom en hetgeen de MT's ermee doen. Wat hier van over is word er naar de wagen gestuurd. Of als er urgentie is om de wagen te laden met PV, zet ik 1 switch om en dan gaan de MT's in standby en mag de EV lader alle overschot nemen. Loopt hier sedert half september als een trein.

[toktokcity]

Ik heb het met HA zo geregeld dat de Marsteks op Manual springen zodra de laadpaal van de auto geactiveerd wordt. Die Zaptec triggert ook op beschikbaarheid van zon. In de praktijk beginnen overdag eerst de Marsteks te laden. Zodra er voldoende overschot is, of de Marsteks vol en daarmee meer overschot, wordt het laden van de auto getriggerd. De manual mode helpt hierbij prima om niet met Marstek accu's (2*) de auto accu te laden.

En als ik zelf het autoladen trigger, dan gaan de Marsteks ook op Manual.

[ Voor 10% gewijzigd door toktokcity op 25-01-2026 13:23 ]

[Druppeltje_]

toktokcity schreef op zondag 25 januari 2026 @ 13:10:
Ik heb het met HA zo geregeld dat de Marsteks op Manual springen zodra de laadpaal van de auto geactiveerd wordt. Die Zaptec triggert op beschikbaar van zon. In de praktijk beginnen overdag eerst de Marsteks te laden. Zodra er voldoende overschot is, of de Marsteks vol en daarmee overschot, wordt het laden van de auto getriggerd. De manual mode helpt hierbij prima om niet met Marstek accu de auto accu te laden.

Heb ik ook een tijdje op die manier gedaan, maar uiteindelijk toch zelf een regeling gemaakt die een bepaald amperage berekent op overschot en dit naar de dynamische limiet van de EV lader stuurt. Ik had het probleem dat ik met jouw manier in een loop terechtkwam. MT gaf volop stroom terug op bijvoorbeeld fase 1 om het verbruik van het wasmachine op fase 3 te compenseren. Dan was er 2300W injectie op fase 1, terwijl er op fase 3 2300W verbruik was. De laadpaal zag deze 2300W als overschot en ging starten met laden -> MT's uit -> weg overschot -> laadpaal ook terug uit. Dit heeft natuurlijk wel te maken dat Easee het overschot per fase bekijkt en niet over de 3 fases heen. Hetgeen ik nooit begrepen heb, maar wel standaard nog steeds zo gebeurd. Auto gaat dan gewoon 1 fasig laden op de fase met overschot, zonder te kijken wat er op f2 en f3 gebeurd. Met mijn eigen regeling nu verplicht ik de laadpaal over de 3 fases heen te laten kijken en bijkomend laat kijken wat de PV overschot is, en wat de MT's op dat moment doen.

[ Voor 5% gewijzigd door Druppeltje_ op 25-01-2026 13:24 ]

[toktokcity]

Druppeltje_ schreef op zondag 25 januari 2026 @ 13:22:
[...]


Heb ik ook een tijdje op die manier gedaan, maar uiteindelijk toch zelf een regeling gemaakt die een bepaald amperage berekent op overschot en dit naar de dynamische limiet van de EV lader stuurt. Ik had het probleem dat ik met jouw manier in een loop terechtkwam. MT gaf volop stroom terug op bijvoorbeeld fase 1 om het verbruik van het wasmachine op fase 3 te compenseren. Dan was er 2300W injectie op fase 1, terwijl er op fase 3 2300W verbruik was. De laadpaal zag deze 2300W als overschot en ging starten met laden -> MT's uit -> weg overschot -> laadpaal ook terug uit. Dit heeft natuurlijk wel te maken dat Easee het overschot per fase bekijkt en niet over de 3 fases heen. Hetgeen ik nooit begrepen heb, maar wel standaard nog steeds zo gebeurd. Auto gaat dan gewoon 1 fasig laden op de fase met overschot, zonder te kijken wat er op f2 en f3 gebeurd. Met mijn eigen regeling nu verplicht ik de laadpaal over de 3 fases heen te laten kijken en bijkomend laat kijken wat de PV overschot is, en wat de MT's op dat moment doen.

Ik accepteer dat bij autoladen de Marsteks helemaal niets doen. Dat gaat in de winter voorlopig prima, zolang de CT-verbinding live blijft. Dat was de grootste uitdaging met HA.

[Druppeltje_]

toktokcity schreef op zondag 25 januari 2026 @ 13:27:
[...]

Ik accepteer dat bij autoladen de Marsteks helemaal niets doen. Dat gaat in de winter voorlopig prima, zolang de CT-verbinding live blijft. Dat was de grootste uitdaging met HA.

De CT-verbinding staat toch los van HA? Of gebruik je de API?

[b4gg3r1]

AUijtdehaag schreef op zondag 4 januari 2026 @ 12:56:
[...]

Die heb je niet meer nodig met V144 en hoger.

Met de local API integratie in HA kan ik niet zoveel als met een elfin aan de modbus.
Ik wil met EVCC (in home assistant) uiteindelijk slimme dingen regelen betreffende de combi: EV lader, accu, zonnepanelen.

Maar v146 lijkt het probleem verholpen te hebben

[Lucant]

Na een 12 tal dagen de Marstek venus e 3 in gebruik te hebben even een stand van zaken. Aangenaam verrast door het rendement van deze batterij. In het begin wat kleine probleempjes gehad. Deels door eigen stomiteiten, deels door het regelmatig wegvallen van de ct verbinding. De "stomiteiten" kunnen verhelpen door hulp op dit forum, waarvoor dank. De ct verbinding ook kunnen oplossen. De eerste dagen stond de wifi repeater een viertal meter van de batterij en de P1 meter waardoor ik regelmatig de ct verbinding verloor. Nu staat deze op 20cm van de P1 meters en op 30cm van de batterij. Voorlopig lukt dit al gedurende enkele dagen perfect. Ik heb de P1 meters van HW en de 003 van marstek getest en voor mij is deze van HW de meest accurate. Reageerd naar mijn inziens sneller en houd de waardes dichter bij de 0 verbruik. Hier enkele voorbeelden van het verbruik van de laatste 39 uren. 500 watt op deze uren verbruik is redelijk goed , denk ik zo....

[3DWim]

Lucant schreef op zondag 25 januari 2026 @ 14:54:
De eerste dagen stond de wifi repeater een viertal meter van de batterij en de P1 meter waardoor ik regelmatig de ct verbinding verloor. Nu staat deze op 20cm van de P1 meters en op 30cm van de batterij.

Ik blijf dat toch wel apart vinden.
Is de ontvangst, bereik vd CT002/3 echt zo slecht ?

[DukeBox]

Lucant schreef op zondag 25 januari 2026 @ 14:54:
.. 500 watt op deze uren verbruik is redelijk goed , denk ik zo....

500 Wh

Maar ja, dit is idd het best haalbare, zeker voor deze maand. Hoeveel PV heb je liggen?

Heb zelf heb de beste resultaten met de CT002 maar dat komt denk ik met name omdat mijn meter op de P1 poort maar per 10 sec. een waarde doorgeeft (ondanks dat het een dsmr 5 meter is). Bijkomend voordeel is dat door een weerstand in serie op te nemen je een kleine offset kan creëren zodat ik nooit teveel terug lever.

[ Voor 38% gewijzigd door DukeBox op 25-01-2026 15:19 ]

[Lucant]

3DWim schreef op zondag 25 januari 2026 @ 15:05:
[...]

Ik blijf dat toch wel apart vinden.
Is de ontvangst, bereik vd CT002/3 echt zo slecht ?

Ik heb met de P1 meter van marstek meer pieken die iets hoger zijn dan deze van de P1 van HW. Ik bedoel hier mee tijdens de nacht, als bv de diepvriezer of ijskast opslaat heeft de marstek meer tijd nodig om in te springen dan de HW. Dit gaat over kleine verschillen maar ik zie ze in de grafieken.

[Lucant]

DukeBox schreef op zondag 25 januari 2026 @ 15:06:
[...]

500 Wh

Maar ja, dit is idd het best haalbare, zeker voor deze maand. Hoeveel PV heb je liggen?

Heb 26 panelen liggen maar het gaat mij nu om de tijd dat de zon niet meer schijnt en de batterij gedurende een aanzienlijke tijd alles op 0 houd.

[3DWim]

Lucant schreef op zondag 25 januari 2026 @ 15:11:
[...]
Ik heb met de P1 meter van marstek meer pieken die iets hoger zijn dan deze van de P1 van HW. Ik bedoel hier mee tijdens de nacht, als bv de diepvriezer of ijskast opslaat heeft de marstek meer tijd nodig om in te springen dan de HW. Dit gaat over kleine verschillen maar ik zie ze in de grafieken.

Gaat mij niet om de pieken dat zal afhankelijk zijn van de combinatie ping van de meter en ping van de P1 of CT.
Waar ik op doel is de ontvangst/bereik van de CT.
Nu heb ik alles op 1m van elkaar hangen dus ik kan niet vergelijken maar normaal moet een wifi signaal toch wel een paar meter kunnen overbruggen.

[Lucant]

3DWim schreef op zondag 25 januari 2026 @ 15:16:
[...]

Gaat mij niet om de pieken dat zal afhankelijk zijn van de combinatie ping van de meter en ping van de P1 of CT.
Waar ik op doel is de ontvangst/bereik van de CT.
Nu heb ik alles op 1m van elkaar hangen dus ik kan niet vergelijken maar normaal moet een wifi signaal toch wel een paar meter kunnen overbruggen.

Vanaf ik de wifi repeater dichter bij de P1 meters hangen heb blijft zowel de ct van de HW als deze van marstek even stabiel. Ik vind alleen dat deze van HW sneller reageerd op veranderingen in stroomverbruik. Normaal zou ik ook denken dat die vier meter verschil weinig verschil zouden maken maar voorlopig is het hier wel duidelijk dat het nu wel werkt en daarvoor minder.

[ Voor 11% gewijzigd door Lucant op 25-01-2026 15:29 ]

[thezahir]

Even een vraag, ik heb 20 panelen die nu vandaag, een fraaie zonnige januaridag, maar met weinig zonkracht, al teveel vermogen leveren om twee Venus 2's te laden, want die laden immers met 800 watt (samen dus 1600) terwijl mijn panelen 2100 watt leverden vanmiddag op hoogtepunt. Dan verdwijnt dus alsnog een 500 w in het net. Zonde natuurlijk, want daarover betaal ik alsnog terugleverkosten. Is daar nog iets aan te doen, want als dit nu in januari al zo is, dan gaat het in de lente en zomer al helemaal een issue zijn.
(ontladen kan wel op 2500 W ingesteld worden)
(ja ik kan natuurlijk wasjes draaien en vaatwasser aan, etc maar dan moet dat wel nodig zijn op zo'n moment en ik heb geen smart vaatwasser of smart wasmachine)

[Druppeltje_]

thezahir schreef op zondag 25 januari 2026 @ 16:07:
Even een vraag, ik heb 20 panelen die nu vandaag, een fraaie zonnige januaridag, maar met weinig zonkracht, al teveel vermogen leveren om twee Venus 2's te laden, want die laden immers met 800 watt (samen dus 1600) terwijl mijn panelen 2100 watt leverden vanmiddag op hoogtepunt. Dan verdwijnt dus alsnog een 500 w in het net. Zonde natuurlijk, want daarover betaal ik alsnog terugleverkosten. Is daar nog iets aan te doen, want als dit nu in januari al zo is, dan gaat het in de lente en zomer al helemaal een issue zijn.
(ontladen kan wel op 2500 W ingesteld worden)
(ja ik kan natuurlijk wasjes draaien en vaatwasser aan, etc maar dan moet dat wel nodig zijn op zo'n moment en ik heb geen smart vaatwasser of smart wasmachine)

Is toch andersom? Laden is altijd op 2500W (tenzij modbus regeling). Ontladen kan je kiezen 800W of 2500W. Als je batterijen maar met 800W laden en je stuurt 500W terug dan loopt er iets niet zoals het hoort. Laden doen ze gewoon aan 2500W/MT

[ Voor 6% gewijzigd door Druppeltje_ op 25-01-2026 16:12 ]

[3DWim]

thezahir schreef op zondag 25 januari 2026 @ 16:07:
Even een vraag, ik heb 20 panelen die nu vandaag, een fraaie zonnige januaridag, maar met weinig zonkracht, al teveel vermogen leveren om twee Venus 2's te laden, want die laden immers met 800 watt

Heb je de accus nog niet ?
Want een Marstek Venus E (ver2) laad standaard met 2500W

[Lucant]

thezahir schreef op zondag 25 januari 2026 @ 16:07:
Even een vraag, ik heb 20 panelen die nu vandaag, een fraaie zonnige januaridag, maar met weinig zonkracht, al teveel vermogen leveren om twee Venus 2's te laden, want die laden immers met 800 watt (samen dus 1600) terwijl mijn panelen 2100 watt leverden vanmiddag op hoogtepunt. Dan verdwijnt dus alsnog een 500 w in het net. Zonde natuurlijk, want daarover betaal ik alsnog terugleverkosten. Is daar nog iets aan te doen, want als dit nu in januari al zo is, dan gaat het in de lente en zomer al helemaal een issue zijn.
(ontladen kan wel op 2500 W ingesteld worden)
(ja ik kan natuurlijk wasjes draaien en vaatwasser aan, etc maar dan moet dat wel nodig zijn op zo'n moment en ik heb geen smart vaatwasser of smart wasmachine)

De marstek laad aan 2500 watt, en ontlaad aan 800 watt, dit laatste is in de app instelbaar tot ontladen aan 2500 watt. Met deze opmerking dat dan de batterij op een aparte kring moet staan.

[DukeBox]

Lucant schreef op zondag 25 januari 2026 @ 16:12:
Met deze opmerking dat dan de batterij op een aparte eigen kring moet staan.

[tweeek]

thezahir schreef op zondag 25 januari 2026 @ 16:07:
Even een vraag, ik heb 20 panelen die nu vandaag, een fraaie zonnige januaridag, maar met weinig zonkracht, al teveel vermogen leveren om twee Venus 2's te laden, want die laden immers met 800 watt (samen dus 1600) terwijl mijn panelen 2100 watt leverden vanmiddag op hoogtepunt. Dan verdwijnt dus alsnog een 500 w in het net. Zonde natuurlijk, want daarover betaal ik alsnog terugleverkosten. Is daar nog iets aan te doen, want als dit nu in januari al zo is, dan gaat het in de lente en zomer al helemaal een issue zijn.
(ontladen kan wel op 2500 W ingesteld worden)
(ja ik kan natuurlijk wasjes draaien en vaatwasser aan, etc maar dan moet dat wel nodig zijn op zo'n moment en ik heb geen smart vaatwasser of smart wasmachine)

Als je geen teruglevering wil hebben moet je of naar een groter / ander systeem van batterij opslag en of alles gaan uitpluizen en je apparatuur in huis gaan veranderen zodat je volop je zonnestroom kan gebruiken, maar dit lijkt MIJ in een standaard situatie onmogelijk.

[GORby]

KingFox schreef op zaterdag 24 januari 2026 @ 12:14:
[...]

Venus E 3.0, v146. Maar het zou niet mogen uitmaken, als ik zie dat Marstek zowel hardwarefouten maakt (slechte contacten in stekkers etc) als slechte software levert op een product dat al een half jaar uit is, dat zou gewoon niet mogen. Enerzijds gaat het ten koste van de betrouwbaarheid en veiligheid van de batterij, anderzijds gebruiksgemak. Ik moet elke keer als de zon schijnt in m’n app kijken of de batterij wel werkt:

• Soms zijn de batterijen niet te benaderen over internet
• Batterij verliest verbinding met P1-meter, maar geeft nergens een melding oid. Voor mij is dat niet 'probleemloos werken', aangezien je zelf maar telkens de app moet openen om de verbinding te herstellen
• Wanneer de verbinding tóch in orde lijkt te zijn, doet de batterij soms nog steeds niets en moet je de batterij resetten, in de hoop dat alles dan toch werkt

Hun update cycle is ook veel te langzaam voor deze aard van kritieke issues. Ik heb toch vooral het gevoel dat ik een kat in een zak heb gekocht, gevalletje goedkoop duurkoop. Betwijfel dat deze het effectief 10 jaar gaat volhouden.

Vervelend dat dat jouw ervaring is met de software. De enige problemen die ik hier had, waren toen ik de API geactiveerd had. Nu ik die af heb staan op mijn Venus E v3, en die gewoon NOM laat draaien (eentje via de CT003, eentje via een virtuele B2500 meter in HA, die ik een eigen waarde doorgeef), en het laad- en ontlaadvermogen stuur via modbus over TCP, heb ik eigenlijk nergens meer last van.
De batterijen draaien stabiel, en doen gewoon wat ze moeten doen, en als er eens iets niet loopt zoals ik het wil, dan ligt dat aan mijn sturing, en moet ik die even aanpassen, maar ook dat werkt nu stilaan zonder dat ik ernaar om moet kijken.

[berrieberrie]

toktokcity schreef op zondag 25 januari 2026 @ 13:10:
Ik heb het met HA zo geregeld dat de Marsteks op Manual springen zodra de laadpaal van de auto geactiveerd wordt. Die Zaptec triggert ook op beschikbaarheid van zon. In de praktijk beginnen overdag eerst de Marsteks te laden. Zodra er voldoende overschot is, of de Marsteks vol en daarmee meer overschot, wordt het laden van de auto getriggerd. De manual mode helpt hierbij prima om niet met Marstek accu's (2*) de auto accu te laden.

En als ik zelf het autoladen trigger, dan gaan de Marsteks ook op Manual.

Op hoeveel watt of ampère heb je die trigger dan ingesteld? En hoeveel watt mag de auto dan maximaal gebruiken van de zonnestroom? ( Want bij te snel laden van auto gaat er bij een reeks van goede zonnedagen er ook meer het net op omdat de auto al vol is.)

[GORby]

berrieberrie schreef op zondag 25 januari 2026 @ 16:46:
[...]


Op hoeveel watt of ampère heb je die trigger dan ingesteld? En hoeveel watt mag de auto dan maximaal gebruiken van de zonnestroom? ( Want bij te snel laden van auto gaat er bij een reeks van goede zonnedagen er ook meer het net op omdat de auto al vol is.)

Wat ik dan zou doen is de modbus integratie gebruiken om het maximum ontlaadvermogen van de batterijen op 0W te zetten wanneer de auto aan het laden is en je niet wil dat die van de batterijen gaat laden. Wanneer de auto dan vol is, gaat de batterij gewoon vrolijk verder met laden.
Als je wat meer controle wil hebben over het vermogen dat er overblijft om de auto op te laden, kan je altijd ook het max laadvermogen begrenzen en die begrenzing periodiek aanpassen.

[thezahir]

Lucant schreef op zondag 25 januari 2026 @ 16:12:
[...]

De marstek laad aan 2500 watt, en ontlaad aan 800 watt, dit laatste is in de app instelbaar tot ontladen aan 2500 watt. Met deze opmerking dat dan de batterij op een aparte kring moet staan.

Je hebt gelijk, ze kunnen inderdaad met max 2500 watt laden.
Dit is mijn situatie vanmiddag.
Ik heb twee omvormers die zoals je ziet 1400+950=2350 watt genereren omstreeks 14.30. En mijn p1 meter detecteert dat ik op dat moment een kleine 500 watt teruglever aan het net. Maar de 2 accu's worden op dat moment met zo'n 1200-1400 watt opgeladen. Dat is toch gek? Want waarom aan het net terugleveren terwijl de accu's niet op vol vermogen aan het laden zijn?

[DukeBox]

thezahir schreef op zondag 25 januari 2026 @ 16:50:
En mijn p1 meter detecteert dat ik op dat moment een kleine 500 watt teruglever aan het net.

Welke P1 meter en wat is de sample tijd? Er zit hoe dan ook al 15 min tijdverschil tussen HW en de MT app.

[ Voor 11% gewijzigd door DukeBox op 25-01-2026 17:00 ]

[3DWim]

@thezahir : zet in je onderschrift effe wat je aan installatie hebt, dat voorkomt giswerk.
Je schrijft over P1 maar wat bedoel je de P1 van HW of de CT van marstek?
Bij die van HW gaan 2 accu's niet werken. Ook zullen de accu's niet 2500W laden als ze al bijna vol zijn dus vulgraad opgeven is ook handig.

[thezahir]

3DWim schreef op zondag 25 januari 2026 @ 16:59:
@thezahir : zet in je onderschrift effe wat je aan installatie hebt, dat voorkomt giswerk.
Je schrijft over P1 maar wat bedoel je de P1 van HW of de CT van marstek?
Bij die van HW gaan 2 accu's niet werken. Ook zullen de accu's niet 2500W laden als ze al bijna vol zijn dus vulgraad opgeven is ook handig.

Sorry, ja, ik heb zowel een HW P1 als een marstek CT003. Op die laatste zijn de accu's aangesloten. Maar de Marstek app geeft daarvan een zeer beperkte inzicht qua grafieken.

[3DWim]

thezahir schreef op zondag 25 januari 2026 @ 17:04:
[...]
Sorry, ja, ik heb zowel een HW P1 als een marstek CT003. Op die laatste zijn de accu's aangesloten. Maar de Marstek app geeft daarvan een zeer beperkte inzicht qua grafieken.

Er zijn meerdere opties mogelijk:
1) de CT staat verkeert ingesteld en ziet niet 2 accu's.
2) er is een piekverbruik die de CT niet zo snel kan bijhouden en het net springt bij. Dat is dus wat ik zie in je garfiekje netverbruik. Niet per se terugleveren.
3) er is een andere combi aan het werk.

NOM zou gewoon moeten werken. Mijn EV laad dan via accu max 800w de rest komt uit het net. Wanneer? Dat zoekt de wagen zelf maar uit.

[tweeek]

thezahir schreef op zondag 25 januari 2026 @ 16:50:
[...]


Je hebt gelijk, ze kunnen inderdaad met max 2500 watt laden.
Dit is mijn situatie vanmiddag.
Ik heb twee omvormers die zoals je ziet 1400+950=2350 watt genereren omstreeks 14.30. En mijn p1 meter detecteert dat ik op dat moment een kleine 500 watt teruglever aan het net. Maar de 2 accu's worden op dat moment met zo'n 1200-1400 watt opgeladen. Dat is toch gek? Want waarom aan het net terugleveren terwijl de accu's niet op vol vermogen aan het laden zijn?

[Afbeelding]

[Afbeelding]

[Afbeelding]

[Afbeelding]

[Afbeelding]

Een moment opname van een maximaal piekje van 486 watt ...... zou het ook nog geen teruglevering durven te noemen.
De marsteks lijken prima te doen wat ze moeten doen.

[PredatorBE]

De voorbije twee dagen was er eindelijk eens veel zon sinds mijn twee batterijen begin deze maand zijn aangesloten. Ik had ze nog niet manueel tot 100% geladen, en gisteren sprongen ze plots van 74% naar 100% na een herstart van de app, terwijl die 74% nog maar enkele minuten werd weergegeven.
Vandaag opnieuw opgevolgd: dit keer ging de status van 90% naar 100%. (deze keer maar voor 1 van de 2 batterijen)

Daarna heb ik even mijn EV laten laden en de MT laten ontladen aan 2500 W. Volgens de energiemeter werd er slechts 2,8 kWh ontladen om van 100% naar 20% te gaan. Aangezien er aan maximaal vermogen werd ontladen, had ik toch 200 tot 400 kWh meer verwacht.

Zijn er anderen die dit gedrag al hebben opgemerkt? Is mijn BMS misschien nog bezig met kalibreren?

[DukeBox]

PredatorBE schreef op zondag 25 januari 2026 @ 17:40:
Ik had ze nog niet manueel tot 100% geladen..
[..]
Zijn er anderen die dit gedrag al hebben opgemerkt? Is mijn BMS misschien nog bezig met kalibreren?

Als ze nog nooit tot 100% zijn geweest dan is dit (in ieder geval de V3) niet iets bijzonders. Veelal gaan ze in het begin zelfs uit het niets maximaal laden omdat ze onder de 12% komen ondanks dat dat niet wordt aangegeven in de app.

[Beekforel]

Aangezien hier een stuk meer ervaringsdeskundige zitten en de Venus A qua software toch wel veel lijkt op de E: hoe gedraagt de backup poort zich bij jullie wanneer grid weg en weer terug komt?

Met de A ervaar ik dat hij uitschakelt als grid weer terug komt.

[Druppeltje_]

berrieberrie schreef op zondag 25 januari 2026 @ 16:46:
[...]


Op hoeveel watt of ampère heb je die trigger dan ingesteld? En hoeveel watt mag de auto dan maximaal gebruiken van de zonnestroom? ( Want bij te snel laden van auto gaat er bij een reeks van goede zonnedagen er ook meer het net op omdat de auto al vol is.)

Dat is exact de reden waarom ik op zonnige dagen de EV lader en batterijen langs elkaar laat werken. Ik heb ervoor gekozen om de batterijen voorrang te geven op de EV lader. Dus alles wat de batterijen niet geladen krijgen, of wanneer deze vol zijn gaat naar de auto. Maar dit kan je ook perfect omdraaien en de auto voorrang geven op de batterijen. Ik heb in de zomermaanden eigenlijk 0 teruggave naar het net. De enige momenten dat ik teruggave heb is wanneer de batterijen vol zijn en ik met de wagen weg ben.

[GoBieN-Be]

toktokcity schreef op zondag 25 januari 2026 @ 13:10:
Ik heb het met HA zo geregeld dat de Marsteks op Manual springen zodra de laadpaal van de auto geactiveerd wordt. ...

Afhankelijk van hoeveel vermogen je autolader gebruikt is onderstaande oplossing van GORby een beter voorstel.

GORby schreef op zondag 25 januari 2026 @ 16:50:
[...]
Wat ik dan zou doen is de modbus integratie gebruiken om het maximum ontlaadvermogen van de batterijen op 0W te zetten wanneer de auto aan het laden is en je niet wil dat die van de batterijen gaat laden. ...

Ik heb een 230V 12A EV charger (ook granny charger genoemd). Dat gaat dus traag laden met maximaal 2700W. Ik heb een Marstek E V2 en +/-5000Wp aan zonnepanelen. Ik stuur de Marstek aan met modbus via de LillyGO. Ik heb de granny charger op een Shelly Gen3 smartplug aangesloten.

Gisteren was een mooie zonnige dag dus ik heb 's namiddags zelf de test gedaan.
De granny charger aangesloten en de Marstek op max discharge 0W gezet maar modus blijft NOM (anti-feed, a.k.a. zelfconsumptie).
De Marstek heeft mooi opgeladen met al het overtollige vermogen die van de zonnepanelen kwam en niet opgebruikt werd. Wanneer de zonnepanelen even minder opleverden dan stopt de Marstek met laden en nooit werd er door de Marstek ontladen (max 0 instelling). Ik heb een paar uurtjes getest en zo'n 6kWh in de EV geladen. Daarna test gestopt, en de max discharge instelling weer op 2500W gezet.

Ik ga dus gewoon een HA automatisatie maken die:
1) Triggert op vermogen boven 10W voor 10sec van de smartplug van de granny charger
2) Vervolgens de max. discharge van Marstek op 0W zet
3) Wacht tot de granny charger langer dan 5min geen vermogen boven de 10W opneemt
4) De max. discharge van Marstek weer op 2500W zet

Misschien ook nog een extra automatisatie als failsafe die mij een push notificatie geeft als de Marstek ontlaadt en de granny charger tegelijk ook oplaadt.

[sheriff]

thezahir schreef op zondag 25 januari 2026 @ 16:50:
[...]
Maar de 2 accu's worden op dat moment met zo'n 1200-1400 watt opgeladen. Dat is toch gek? Want waarom aan het net terugleveren terwijl de accu's niet op vol vermogen aan het laden zijn?

Dat komt denk ik omdat de temperatuur waar de accu staat te laag is om volle snelheid te laden, heb je hem in de schuur of buiten staan misschien, met deze koude dagen gaat die van mij ook maar maximaal laden met ongeveer 550 Watt.
Als de buitentemperatuur hoger is gaat de laadsnelheid ook omhoog, de batterij regelt dat zelf.

[NoFate]

Ik heb een 3de batterij aangesloten, maar mij nom waarde was echt niet goed. Blijkbaar had de auto diagnose deze op een verkeerde fase gedetecteerd... Dus let goed op. Als je op de CT003 klikt, dan zie je icoontjes op welke fase de batterijen staan.... Een paar keer toch de diagnose opnieuw moeten doen , en toen was het goed...

[AUijtdehaag]

b4gg3r1 schreef op zondag 25 januari 2026 @ 14:08:
[...]


Met de local API integratie in HA kan ik niet zoveel als met een elfin aan de modbus.
Ik wil met EVCC (in home assistant) uiteindelijk slimme dingen regelen betreffende de combi: EV lader, accu, zonnepanelen.

Maar v146 lijkt het probleem verholpen te hebben

De Marstek Venus E V3 praat al modbus via het netwerk doelde ik ermee te zeggen.
De Elfin is dus feitelijk overbodig geworden met HA

[DSSW]

thezahir schreef op zondag 25 januari 2026 @ 16:50:
[...]


Je hebt gelijk, ze kunnen inderdaad met max 2500 watt laden.
Dit is mijn situatie vanmiddag.
Ik heb twee omvormers die zoals je ziet 1400+950=2350 watt genereren omstreeks 14.30. En mijn p1 meter detecteert dat ik op dat moment een kleine 500 watt teruglever aan het net. Maar de 2 accu's worden op dat moment met zo'n 1200-1400 watt opgeladen. Dat is toch gek? Want waarom aan het net terugleveren terwijl de accu's niet op vol vermogen aan het laden zijn?

[Afbeelding]

[Afbeelding]

[Afbeelding]

[Afbeelding]

[Afbeelding]

Je mag je niet focussen op een momentopnames.

Bekijk het eens op 24h en kijk hoeveel je dan uit het net getrokken/teruggeleverd hebt. Als je voldoende opslag/Pv productie hebt om het verbruik op te vangen en voldoende vermogen om de pieken te counteren dan zal je merken dat je op 24h niet boven de 1kWh verbruik zal komen.
Werkt hier zo al bijna 12 maanden ( met soms eens een CT dropje waar ik geen oorzaak aan kan toewijzen). Blijf dus nog altijd positief over de Venus E's.
De Venus A ben ik op dit ogenblik minder positief over, daar zitten nog kinderziektes in waar ze nog aan moeten werken.

[DSSW]

PredatorBE schreef op zondag 25 januari 2026 @ 17:40:
De voorbije twee dagen was er eindelijk eens veel zon sinds mijn twee batterijen begin deze maand zijn aangesloten. Ik had ze nog niet manueel tot 100% geladen, en gisteren sprongen ze plots van 74% naar 100% na een herstart van de app, terwijl die 74% nog maar enkele minuten werd weergegeven.
Vandaag opnieuw opgevolgd: dit keer ging de status van 90% naar 100%. (deze keer maar voor 1 van de 2 batterijen)

Daarna heb ik even mijn EV laten laden en de MT laten ontladen aan 2500 W. Volgens de energiemeter werd er slechts 2,8 kWh ontladen om van 100% naar 20% te gaan. Aangezien er aan maximaal vermogen werd ontladen, had ik toch 200 tot 400 kWh meer verwacht.

Zijn er anderen die dit gedrag al hebben opgemerkt? Is mijn BMS misschien nog bezig met kalibreren?

Ben niet mee. Wat bedoel je met 200 tot 400 kWh?

[pascallj]

PredatorBE schreef op zondag 25 januari 2026 @ 17:40:
De voorbije twee dagen was er eindelijk eens veel zon sinds mijn twee batterijen begin deze maand zijn aangesloten. Ik had ze nog niet manueel tot 100% geladen, en gisteren sprongen ze plots van 74% naar 100% na een herstart van de app, terwijl die 74% nog maar enkele minuten werd weergegeven.
Vandaag opnieuw opgevolgd: dit keer ging de status van 90% naar 100%. (deze keer maar voor 1 van de 2 batterijen)

Daarna heb ik even mijn EV laten laden en de MT laten ontladen aan 2500 W. Volgens de energiemeter werd er slechts 2,8 kWh ontladen om van 100% naar 20% te gaan. Aangezien er aan maximaal vermogen werd ontladen, had ik toch 200 tot 400 kWh meer verwacht.

Zijn er anderen die dit gedrag al hebben opgemerkt? Is mijn BMS misschien nog bezig met kalibreren?

Alleen van 11 naar 100 en van 100 naar 11 op een beetje redelijk vermogen is een goede indicatie voor de capaciteit. De SoC indicator is sowieso niet echt nauwkeurig namelijk dus de batterij moet helemaal vol, en helemaal leeg. Als je een paar cycli hebt gemaakt tussen 11 en 100 in, zeker als dat op kleine vermogens is geweest, is die sowieso al van slag.

Ik snap die 200 tot 400 kWh niet echt? 200 tot 400 Wh meer, lijkt mij te weinig en 2 tot 4 kWh meer lijkt mij een te grote range, dus weet niet wat je daar bedoelde. Je moet je richten op grofweg 5 kWh laden en 4 kWh ontladen.

[pascallj]

Ik zie de afgelopen dagen ook de discussie weer voorbij komen met ingewikkelde strategieën om de EV te combineren met de batterij en de batterij niet te ontladen wanneer de EV gaat laden.

Let wel dat dit dus alleen zin heeft als je de EV laadt op een moment met goedkope stroom. Laad je de batterij exclusief met zonnestroom en krijg je voor die zonnestroom minder terug dan wat het zou kosten om het zelf in te kopen, is het ondanks dat je heel veel omzetverliezen hebt, nog steeds voordeliger voor de portemonnee om eerst de batterij te laden en het alsnog in de auto stoppen op een later moment. Het voelt alleen onlogisch.

Denk hierbij aan situaties waarbij de auto overdag niet aan de lader kan hangen. De auto direct met zonnestroom laden is natuurlijk altijd beter, maar als je over de gehele dag een vaste prijs hebt voor de stroom, is er geen reden om de batterij te gebruiken voor je huis en de auto direct te laten laden bijvoorbeeld.

Uitzonderingen natuurlijk als de baas de lading van de laadpaal betaald etc.

[Cpt.Chaos]

Met de 25% subsidie nu in Flevoland zit ik ook te kijken naar een batterij. Dit zou dan een venus e 3 worden, want die heeft geen aansluiting voor zonnepanelen (toch?) wat de prijs drukt.
Ik zie alleen nergens op de website hoe het gaat als ik 15kWh aanschaf, krijg ik er dan drie die op 3 stopcontacten moeten, of worden ze onderling verbonden met maar 1 stekker in het stopcontact?
Ik neem aan dat ze niet op de wasmachine groep kunnen want dan loopt er te veel stroom als ze aan het laden zijn en de wasmachine draait. Hoe zit het eigenlijk met de laadsnelheid als ze in een stopcontact zitten, je kan op dezelfde groep dan toch geen grootverbruikers aanzetten (frituur oid)?

[pascallj]

Cpt.Chaos schreef op zondag 25 januari 2026 @ 22:16:
Met de 25% subsidie nu in Flevoland zit ik ook te kijken naar een batterij. Dit zou dan een venus e 3 worden, want die heeft geen aansluiting voor zonnepanelen (toch?) wat de prijs drukt.
Ik zie alleen nergens op de website hoe het gaat als ik 15kWh aanschaf, krijg ik er dan drie die op 3 stopcontacten moeten, of worden ze onderling verbonden met maar 1 stekker in het stopcontact?
Ik neem aan dat ze niet op de wasmachine groep kunnen want dan loopt er te veel stroom als ze aan het laden zijn en de wasmachine draait. Hoe zit het eigenlijk met de laadsnelheid als ze in een stopcontact zitten, je kan op dezelfde groep dan toch geen grootverbruikers aanzetten (frituur oid)?

Er bestaat alleen maar een 5 kWh met een eigen stekker. Als een dealer bundels aanbiedt die groter zijn, zijn het er gewoon meerdere. De uitbreidbare variant is de Marstek Venus A/D (zie quick reply).

Elke batterij moet op een andere groep staan. Elke batterij kan met 2500 W laden en 800 W ontladen. Wil je 2500 W ontladen ontgrendelen moet de batterij zijn compleet eigen groep hebben zonder andere apparatuur.

Als hij met 2500 W aan het laden is kan je best kortstondig een grootverbruiker erbij hebben, maar niet lang inderdaad. Dus ik zou de frituur vermijden. Wasmachine gaat misschien als je alleen maar 30 graden wasjes doet, maar zou ik ook gelijktijdig vermijden.

Lees ook even de TS door voor meer informatie.

[Igor4]

Vraagje; weet iemand of de marstek local api ook de jupiter c+ accu ondersteund?

Ik ben tot nu toe wel positief over de api koppeling en integratie van de venus in m'n HA setup. De aanschaf van een Jupiter systeem lijkt me mooie aanvulling icm wat extra PV op tuinhuisje en hogere RTE. Maar dan moet het wel goed samen kunnen werken met de Venus..

[tjberkhof]

Hoihoi,

Heeft iemand meer informatie hoe de Ai-optimalisatie precies werkt?

Wat ik in de documentatie vind is dat hij in de goedkoopste uren oplaad en de duurste uren teruglevert op basis van de dynamische prijzen.

Maar.... Houd het systeem rekening met verliezen zoals RTE, afschrijving en winst optimalisatie?

Als bijvoorbeeld op een dag laag 0.25euro en hoog 0.27 euro is, gaat het systeem dan in NOM mode en negeert hij "slim laden" (aangezien op dergelijke dag laden /ontladen onzettend dom zou zijn - het kost je alleen maar geld).

Het liefst zou ik NOM willen en alleen op dagen waar het verschil tussen hoog /laag meer dan 20 cent is handelen.

Is dit mogelijk met dergelijk apparaat of moet ik dan mijn eigen stukje software gaan schrijven?

[pascallj]

tjberkhof schreef op zondag 25 januari 2026 @ 23:17:
Hoihoi,

Heeft iemand meer informatie hoe de Ai-optimalisatie precies werkt?

Wat ik in de documentatie vind is dat hij in de goedkoopste uren oplaad en de duurste uren teruglevert op basis van de dynamische prijzen.

Maar.... Houd het systeem rekening met verliezen zoals RTE, afschrijving en winst optimalisatie?

Als bijvoorbeeld op een dag laag 0.25euro en hoog 0.27 euro is, gaat het systeem dan in NOM mode en negeert hij "slim laden" (aangezien op dergelijke dag laden /ontladen onzettend dom zou zijn - het kost je alleen maar geld).

Het liefst zou ik NOM willen en alleen op dagen waar het verschil tussen hoog /laag meer dan 20 cent is handelen.

Is dit mogelijk met dergelijk apparaat of moet ik dan mijn eigen stukje software gaan schrijven?

Welke documentatie heb je gelezen? AI heeft nog nooit teruggeleverd in de duurste uren en handelen is ook nooit het doel geweest.

Er zijn momenteel twee versies van AI in omloop. Er is de oude, die gewoon laadt op de twee of drie goedkoopste uren van de dag en elk ander moment NOM draait.
Dan is er de 'echte' nieuwe AI die een soort rekening probeert te houden met een patroon en probeert te zorgen dat hij in de goedkoopste uren daarvoor opgeladen heeft. Maar dat is alleen waar het op lijkt. Wat het precies doet weet niemand. En nog spannender, welke AI je krijgt is ook maar de vraag.

Verder houdt die AI nergens rekening mee, niet met RTE en ook niet met prijsverschillen. Domme AI dus.

[tjberkhof]

pascallj schreef op zondag 25 januari 2026 @ 23:22:
[...]


Welke documentatie heb je gelezen? AI heeft nog nooit teruggeleverd in de duurste uren en handelen is ook nooit het doel geweest.

Er zijn momenteel twee versies van AI in omloop. Er is de oude, die gewoon laadt op de twee of drie goedkoopste uren van de dag en elk ander moment NOM draait.
Dan is er de 'echte' nieuwe AI die een soort rekening probeert te houden met een patroon en probeert te zorgen dat hij in de goedkoopste uren daarvoor opgeladen heeft. Maar dat is alleen waar het op lijkt. Wat het precies doet weet niemand. En nog spannender, welke AI je krijgt is ook maar de vraag.

Verder houdt die AI nergens rekening mee, niet met RTE en ook niet met prijsverschillen. Domme AI dus.

Ha, je hebt me. Chatgpt heeft in de documentatie gelezen, maar blijkbaar ook niet al te goed.

Erg jammer dat AI eigenlijk gewoon een super simpel scriptje is. Lijkt me toch een main selling point om te laden op de goedkope momenten maar alleen als verschil laag/hoog meer dan x (user instelbaar) is. En daarnaast dus standaard laden als prijzen negatief zijn.

Nouja - ik heb al gelezen dat je via modbus + HA redelijk wat zelf kan controleren, dus dan word het die weg.

Maar moet zeggen dat het me echt irriteert. Dergelijke functies zouden standaard moeten zijn op een thuisbatterij en kost echt niet heel veel werk om te coderen. Zoals marstek het nu verkoopt is gewoon geld weggooien met AI standaard geselecteerd, zowel vanwege RTE als afschrijving, maar dat hij dus ook gewoon op NOM gaat na bijladen (en dus geen rekening houd met eventueel latere pieken) is wat mij betreft echt een hoofdzonde.

[3DWim]

tjberkhof schreef op zondag 25 januari 2026 @ 23:35:
[...]
Zoals marstek het nu verkoopt is gewoon geld weggooien met AI standaard geselecteerd, ..

Hoe kom je daar op ?
Hier staat ie gewoon (standaard) op NOM. En zo kwam ie ook uit de doos, zeg maar.
Dat kan ook haast niet anders want je moet je leverancier (voor de laagste prijs) opgeven.

[tjberkhof]

3DWim schreef op zondag 25 januari 2026 @ 23:52:
[...]

Hoe kom je daar op ?
Hier staat ie gewoon (standaard) op NOM. En zo kwam ie ook uit de doos, zeg maar.
Dat kan ook haast niet anders want je moet je leverancier (voor de laagste prijs) opgeven.

Ik denk dat wij de betekenis van het woord "standaard" anders gebruiken.

Jij: standaard zoals de modus origineel uit de doos.
Ik: de standaard modus die iemand heeft geselecteerd.

[Remar65]

Sinds een paar dagen heb ik naast de Venus V2 een Venus V3 staan. Installeren was een fluitje van een cent zogezegd en ik heb ook meteen de update voor de V3 gevraagd en gekregen.

Wat mij nu opvalt is dat, wanneer ik de app open, beide batterijen niet de juiste status aangeven. Ook niet na het verversen (dus het omlaag trekken van het beeld…)
Pas na het openen van de betreffende batterijpagina komt de juiste status tevoorschijn.

Verder is het opmerkelijk dat bij het bekijken van de V2 in de app het CT icoontje groen is en dat deze bij de V3 in eerste instantie grijs is en pas na een seconde of vijf/zes groen wordt.

Zijn er meer mensen met dit “probleem” ?

Als voorbeeld even wat schermafbeeldingen, achtereenvolgens de hoofdpagina, de V2, direct daarna de V3 en als laatste de V3 na een vijftal seconden.

Ben benieuwd waar dat in kan zitten, vooral omdat ik dit niet had voor de installatie van de V3…

[elgringo]

Alan969 schreef op zaterdag 24 januari 2026 @ 11:48:
[...]

Ik zou de MT eens plaatsen op een stopcontact dat achter de 30mA staat (vb. in de badkamer). Als deze niet uitschakelt, dan mag je ervan uitgaan dat alles in orde is.

Niet echt; een aardlek meet het verschil tussen fase en 0 als deze meer dan 30ma is klapt ie eruit.
Wat er door je aarddraad gaat aan stroom is irrelevent.

Als een een apparaat het met bijv een transformator en de transformator (secundair) sluit je kort naar de aarde gaat je aardlek er niet uit. de primaire spoel heeft geen kortsluitiong, de secundaire wel.
Dus een aardlek schakelaar is geen garantie dat het goed is.

[RF1000]

pascallj schreef op zondag 25 januari 2026 @ 21:28:
...

...en krijg je voor die zonnestroom minder terug dan wat het zou kosten om het zelf in te kopen, ...

Kleine toevoeging; als je meer als 25% minder terugkrijgt.

Zat met hetzelfde dilemma. Nu bij Tibber en daar lever je slechts 2,48ct /kWh in ipv 12ct bij mn vorige (vaste) contact.

[DSSW]

Remar65 schreef op maandag 26 januari 2026 @ 06:03:
Sinds een paar dagen heb ik naast de Venus V2 een Venus V3 staan. Installeren was een fluitje van een cent zogezegd en ik heb ook meteen de update voor de V3 gevraagd en gekregen.

Wat mij nu opvalt is dat, wanneer ik de app open, beide batterijen niet de juiste status aangeven. Ook niet na het verversen (dus het omlaag trekken van het beeld…)
Pas na het openen van de betreffende batterijpagina komt de juiste status tevoorschijn.

Verder is het opmerkelijk dat bij het bekijken van de V2 in de app het CT icoontje groen is en dat deze bij de V3 in eerste instantie grijs is en pas na een seconde of vijf/zes groen wordt.

Zijn er meer mensen met dit “probleem” ?

Als voorbeeld even wat schermafbeeldingen, achtereenvolgens de hoofdpagina, de V2, direct daarna de V3 en als laatste de V3 na een vijftal seconden.

Ben benieuwd waar dat in kan zitten, vooral omdat ik dit niet had voor de installatie van de V3…


[Afbeelding]

[Afbeelding]

[Afbeelding]

[Afbeelding]

Hier identiek hetzelfde probleem maar dan met combinatie 2 x Venus V1, 1 x Venus V2 en de Venus A. Heb het ook al gemeld via de feedback (2 keer de gemeld de laatste week) maar tot op heden geen reactie vanuit China.

[GORby]

Driehoek schreef op zondag 25 januari 2026 @ 09:18:
Vraagje ivm de combinatie met het smart/solar laden van een wagen:
Is er aan de zijde van de Marstek iets mogelijk qua instellingen om dit gedrag tegen te gaan of moet ik de oplossing bij de EV lader zoeken?

Twee bijkomende issues:
1. Wanneer de Marstek volgeladen is met zonnestroom en stopt met laden gaat de EV weer voor NOM. De batterij "ziet" dat er verbruik is rond het nulpunt en langzaamaan begint de wagen meer en meer stroom te vragen en loopt de batterij helemaal leeg.
2. Wanneer de zonnepanelen niets opwekken probeert de Marstek NOM te regelen. De lader van de wagen ziet dit en begint te laden omdat deze vanaf 0A begint te laden met de minimale stroom.
Deze twee issues hoop ik opgelost te hebben door het laden van de wagen pas vanaf 3A te laten starten.


Is er een mogelijkheid om een capaciteitstarief te programmeren?

Je wil blijkbaar de Marstek batterijen voorrang geven op het laden van de wagen, aangezien je deze nu pas bij 3A teruglevering mag starten.
Zoals ik eerder vermeld had kan je - wanneer de auto aan het laden is - de modbus integratie van de Marsteks gebruiken om het maximale ontlaadvermogen op 0W te zetten, zodat de batterijen wel nog de overproductie die niet door de auto gebruikt wordt gaan gebruiken, maar wanneer er even meer vraag is niet direct je batterij gaat leegtrekken.

Deze sturing gebruik ik thuis ook in combinatie met een EV (die met een EVSE laadt), maar dan specifiek gericht op:

• capaciteitstarief beperken met een batterij die NOM draait met een virtuele P1 meter (met een offset)
• productie-overschot opslaan in een tweede batterij die gewoon NOM draait met (variabel) beperkt terugleververmogen.

Specifiek voor het capaciteitstarief heb ik een ander topic: "Capaciteitstarief beperken met Marstek batterij(en)."
-

[Chris.nl]

Remar65 schreef op maandag 26 januari 2026 @ 06:03:
Sinds een paar dagen heb ik naast de Venus V2 een Venus V3 staan. Installeren was een fluitje van een cent zogezegd en ik heb ook meteen de update voor de V3 gevraagd en gekregen.

Wat mij nu opvalt is dat, wanneer ik de app open, beide batterijen niet de juiste status aangeven. Ook niet na het verversen (dus het omlaag trekken van het beeld…)
Pas na het openen van de betreffende batterijpagina komt de juiste status tevoorschijn.

Ik gebruik de v3 sinds eind december en weet niet beter dan dat de status van de batterij, direct na het openen van de app kan afwijken.

Dit overzicht krijg ik ook te zien in vliegtuigstand dus wordt imo lokaal geladen ipv online. Verversen van het startscherm, wist niet dat dit kon, maar werkt hier nu ook niet. 't Is ververst na doorklikken.

'k Had niet kunnen vermoeden dat de app anders/beter werkt bij anderen.

Verder is het opmerkelijk dat bij het bekijken van de V2 in de app het CT icoontje groen is en dat deze bij de V3 in eerste instantie grijs is en pas na een seconde of vijf/zes groen wordt.

Zijn er meer mensen met dit “probleem” ?

Ja, ik hield rekening met een eventuele vertragingen ivm moeten syncen. Soms laat ie direct CT zien, soms seconden later. Voor mij normaal gedrag, wist niet dat ik een probleem had.

[Driehoek]

GORby schreef op maandag 26 januari 2026 @ 09:24:
[...]

Je wil blijkbaar de Marstek batterijen voorrang geven op het laden van de wagen, aangezien je deze nu pas bij 3A teruglevering mag starten.
Zoals ik eerder vermeld had kan je - wanneer de auto aan het laden is - de modbus integratie van de Marsteks gebruiken om het maximale ontlaadvermogen op 0W te zetten, zodat de batterijen wel nog de overproductie die niet door de auto gebruikt wordt gaan gebruiken, maar wanneer er even meer vraag is niet direct je batterij gaat leegtrekken.

Deze sturing gebruik ik thuis ook in combinatie met een EV (die met een EVSE laadt), maar dan specifiek gericht op:

• capaciteitstarief beperken met een batterij die NOM draait met een virtuele P1 meter (met een offset)
• productie-overschot opslaan in een tweede batterij die gewoon NOM draait met (variabel) beperkt terugleververmogen.

Specifiek voor het capaciteitstarief heb ik een ander topic: SatScan in "Capaciteitstarief beperken met Marstek batterij(en)."
-

Bedankt voor het linkje!
Met de link van @AUijtdehaag probeer ik nu een slimme regeling op te zetten maar ben hier in alle eerlijkheid niet heel erg sterk in dus gaat wel even duren. Tot ik alles in home assistant heb draaien doe ik alles manueel.

[blubbers]

Ik wil even mijn bevindingen delen ivm de HomeWizard Splitter en de CT003 en HomeWizard P1 er op aangesloten aangezien hier wel wat wordt gesproken dat de gekozen poort wel van belang is en ik moet dat nu ook bevestigen.
Ik heb telkens de splitter en de CT003 apart voeding gegeven maar als de CT003 op de 1e uitsturende poort zit wordt er geen data meer gelezen en de batterij reageert niet meer. Kies ik 2e of 3e poort dan werkt het perfect. Waar de HomeWizard P1 steekt maakt niet uit, ook zonder de P aangesloten geeft 1e poort niets door naar de Marstek; Toch apart.

[De Senaat]

blubbers schreef op maandag 26 januari 2026 @ 10:43:
Ik wil even mijn bevindingen delen ivm de HomeWizard Splitter en de CT003 en HomeWizard P1 er op aangesloten aangezien hier wel wat wordt gesproken dat de gekozen poort wel van belang is en ik moet dat nu ook bevestigen.
Ik heb telkens de splitter en de CT003 apart voeding gegeven maar als de CT003 op de 1e uitsturende poort zit wordt er geen data meer gelezen en de batterij reageert niet meer. Kies ik 2e of 3e poort dan werkt het perfect. Waar de HomeWizard P1 steekt maakt niet uit, ook zonder de P aangesloten geeft 1e poort niets door naar de Marstek; Toch apart.

Poort 1 van de splitter is voor P1 inkomend toch? Staat er ook bij, maar is heel slecht leesbaar.

[GORby]

Driehoek schreef op maandag 26 januari 2026 @ 10:41:
[...]


Bedankt voor het linkje!
Met de link van @AUijtdehaag probeer ik nu een slimme regeling op te zetten maar ben hier in alle eerlijkheid niet heel erg sterk in dus gaat wel even duren. Tot ik alles in home assistant heb draaien doe ik alles manueel.

Dat zijn echt dingen die je automatisch wil sturen, of je het nu via HA, Node-Red, EVCC of wat dan ook doet. De inspanning om dat op te zetten heb je vrij snel terugverdiend, als je gebruik maakt van wat anderen al gebouwd hebben.

Ik heb redelijk veel zelf uitgezocht, vooral omdat ik weinig vond om met een Marstek het capaciteitstarief te beperken, en doe een combinatie van beperking capaciteitstarief + anti-feed via Home Assistant, en spreiding van verbruikers in Node-Red.

[taurgis]

In afwachting van de 'officiële plugin' die maar niet doorkomt (en uiteindelijk maar goed ook), heb ik hun broncode uitgecheckt en ben ik begonnen aan een betere versie; een hybride tussen de officiële en custom code.

Ben hier tegen rare code gestoten waardoor mijn device met hun plugin niet gevonden werd, verkeerde waarden werden gemapped, etc... Dus er zijn wijzigingen gebeurd. Ik heb dit nog niet op mijn echte instance gezet, ben nu gewoon aan het werken via de Docker met "simulated batteries".

Ik ben hier wel tot de vaststelling gekomen dat de timeouts ook voorkomen in mijn testsetup. Dit zijn gewoon Docker-containers (1 HA instance en 3 'mock' Marsteks), maar de communicatie duurt lang en krijgt veel timeouts. Het kan mogelijk aan mijn config liggen, maar het lijkt me eerder aan onbetrouwbare UDP-communicatie te wijten.

https://github.com/taurgis/has-marstek-local-api

[pascallj]

taurgis schreef op maandag 26 januari 2026 @ 11:48:
In afwachting van de 'officiële plugin' die maar niet doorkomt (en uiteindelijk maar goed ook), heb ik hun broncode uitgecheckt en ben ik begonnen aan een betere versie; een hybride tussen de officiële en custom code.

Ben hier tegen rare code gestoten waardoor mijn device met hun plugin niet gevonden werd, verkeerde waarden werden gemapped, etc... Dus er zijn wijzigingen gebeurd. Ik heb dit nog niet op mijn echte instance gezet, ben nu gewoon aan het werken via de Docker met "simulated batteries".

Ik ben hier wel tot de vaststelling gekomen dat de timeouts ook voorkomen in mijn testsetup. Dit zijn gewoon Docker-containers (1 HA instance en 3 'mock' Marsteks), maar de communicatie duurt lang en krijgt veel timeouts. Het kan mogelijk aan mijn config liggen, maar het lijkt me eerder aan onbetrouwbare UDP-communicatie te wijten.

https://github.com/taurgis/has-marstek-local-api

Dat klopt. Al sinds het begin van het uitkomen is bekend dat deze instabiel is, veel heraanvragen vereist en dus ook zorgt voor een onstabiele communicatie tussen de batterij en de CT. Ik had zelf ook al een integratie klaarliggen voordat Marstek er een had, maar ben vanwege deze instabiliteit ook gestopt en heb het nooit uitgebracht.

Dit is echt iets dat waarschijnlijk met firmware opgelost moet worden. Zonde dat je het niet eerder hier had bekeken, had een hoop tijd kunnen besparen

Of lees ik het verkeerd en claim je dat het komt door de aard van UDP? Dat dat onbetrouwbaar is? Dat lijkt mij sterk, want UDP over een lokaal netwerk is vrij stabiel, daar raken pakketten eigenlijk niet verloren (behalve door slechte WiFi bijvoorbeeld). Als ze lokaal communiceren tussen docker containers raken er sowieso geen pakketten verloren.

[ Voor 9% gewijzigd door pascallj op 26-01-2026 12:04 ]

[taurgis]

pascallj schreef op maandag 26 januari 2026 @ 11:53:
[...]


Dat klopt. Al sinds het begin van het uitkomen is bekend dat deze instabiel is, veel heraanvragen vereist en dus ook zorgt voor een onstabiele communicatie tussen de batterij en de CT. Ik had zelf ook al een integratie klaarliggen voordat Marstek er een had, maar ben vanwege deze instabiliteit ook gestopt en heb het nooit uitgebracht.

Dit is echt iets dat waarschijnlijk met firmware opgelost moet worden. Zonde dat je het niet eerder hier had bekeken, had een hoop tijd kunnen besparen

Of lees ik het verkeerd en claim je dat het komt door de aard van UDP? Dat dat onbetrouwbaar is? Dat lijkt mij sterk, want UDP over een lokaal netwerk is vrij stabiel, daar raken pakketten eigenlijk niet verloren (behalve door slechte WiFi bijvoorbeeld). Als ze lokaal communiceren tussen docker containers raken er sowieso geen pakketten verloren.

Ik heb het ook voor op mijn demo setup, wat gewoon een python scriptje is. Dus dat moet ik nog even bekijken dan.

https://github.com/taurgi...ee/main/tools/mock_device

De onstabiele connectie in realiteit wist ik

[ Voor 5% gewijzigd door taurgis op 26-01-2026 12:07 ]

[Luke the Duke]

Even over de LAN/Ethernet poort.
Ik heb een Marstek Venus E V3 versie V147 met communicatiemodule versie 202506241541, met CT003 versie V122 met communicatiemodule 202506141125.
In de Marstek app zie ik van de Venus het icoontje dat de ethernetpoort verbonden zou zijn (in plaats van het Wifi icoontje) maar in mijn router zie ik van de Venus nog steeds dezelfde hostnaam "wlan0" alsook het zelfde MAC adres als van de wifi.

Kloppen de versienummers van de communicatie modules met wat jullie zien en wat zien jullie als hostnaam als de Venus via ethernet (kabel) is aangesloten? En zien jullie ook een ander MAC adres als van Wifi?

[pascallj]

Luke the Duke schreef op maandag 26 januari 2026 @ 13:59:
Even over de LAN/Ethernet poort.
Ik heb een Marstek Venus E V3 versie V147 met communicatiemodule versie 202506241541, met CT003 versie V122 met communicatiemodule 202506141125.
In de Marstek app zie ik van de Venus het icoontje dat de ethernetpoort verbonden zou zijn (in plaats van het Wifi icoontje) maar in mijn router zie ik van de Venus nog steeds dezelfde hostnaam "wlan0" alsook het zelfde MAC adres als van de wifi.

Kloppen de versienummers van de communicatie modules met wat jullie zien en wat zien jullie als hostnaam als de Venus via ethernet (kabel) is aangesloten? En zien jullie ook een ander MAC adres als van Wifi?

Ik denk dat je nu zowel via WiFi als via LAN verbonden bent. Via LAN is de hostname namelijk 'CH395'. MAC zou ik niet weten, maar dat zou eigenlijk een andere moeten zijn.

Ik zou even proberen om de WiFi geforceerd niet meer verbonden te laten zijn. Dit kan je doen door een niet bestaand SSID en wachtwoord op te geven, door te gaan en dan snel geforceerd de app te laten afsluiten. Hij zal dan het WiFi netwerk vergeten. Kan een paar pogingen kosten. Mocht dat niet werken kan je altijd met de telefoon tijdelijk een WiFi hotspot maken met je telefoon, de Marstek ermee verbinden en vervolgens de hotspot met die naam nooit meer gebruiken.

[toktokcity]

berrieberrie schreef op zondag 25 januari 2026 @ 16:46:
[...]


Op hoeveel watt of ampère heb je die trigger dan ingesteld? En hoeveel watt mag de auto dan maximaal gebruiken van de zonnestroom? ( Want bij te snel laden van auto gaat er bij een reeks van goede zonnedagen er ook meer het net op omdat de auto al vol is.)

De automatisering reageert op de status van de Zaptec, dus als die actief laadt, dan gaan de Marsteks op Manual. We hebben hier een zon-installatie met 9600Wp, dus in theorie zou dat via de Zaptec in de auto kunnen worden geduwd, de Zaptec moduleert nav beschikbaarheid, al is dat nog niet zo soepel als de Marsteks dat doen via de P1. Terugleveren naar het net zal blijven, want idd, als de zon 's ochtends schijnt, de accu's al vol zitten en de auto niet thuis, dan zijn we voor de middag al aan de teruglevering. Maar goed, we hebben dynamisch contract, dus daar vallen de negatieve terugleverkosten voorlopig nog mee.

[blubbers]

De Senaat schreef op maandag 26 januari 2026 @ 10:53:
[...]

Poort 1 van de splitter is voor P1 inkomend toch? Staat er ook bij, maar is heel slecht leesbaar.

Vandaar dat ik ook zei 1e uitgaande poort. Dus de 2e als je ze puur telt.

[jj85]

Luke the Duke schreef op maandag 26 januari 2026 @ 13:59:
Even over de LAN/Ethernet poort.
Ik heb een Marstek Venus E V3 versie V147 met communicatiemodule versie 202506241541, met CT003 versie V122 met communicatiemodule 202506141125.
In de Marstek app zie ik van de Venus het icoontje dat de ethernetpoort verbonden zou zijn (in plaats van het Wifi icoontje) maar in mijn router zie ik van de Venus nog steeds dezelfde hostnaam "wlan0" alsook het zelfde MAC adres als van de wifi.

Kloppen de versienummers van de communicatie modules met wat jullie zien en wat zien jullie als hostnaam als de Venus via ethernet (kabel) is aangesloten? En zien jullie ook een ander MAC adres als van Wifi?

Kijk even of je WIFI lampje op de batterij brand. Deze gaat uit als hij geen verbinding via wifi heeft.

MAC adres is idd anders dan WiFi-MAC
Via Lan krijg ik
Mac: dc:32:62:xx:xx:xx
Mac: e4:66:e5:xx:xx:xx

Beiden behoren toe aan
Nanjing Qinheng Microelectronics Co., Ltd.

Via Wifi krijg ik
Mac: 18:CE:DF:xx:xx:xx
Behoort bij Quectel Wireless Solutions Co.,Ltd.

M'n com module zit wel op een veel oudere fw 202409090159
Venus v3 (V146)

CT003 zit ook nog op V116.

Is er bekend wat de verschillen zijn met de nieuwe comm modules fw en tussen V116/V122 van de CT003?

[ Voor 4% gewijzigd door jj85 op 26-01-2026 15:03 ]

[pascallj]

Beekforel schreef op zondag 25 januari 2026 @ 18:01:
Aangezien hier een stuk meer ervaringsdeskundige zitten en de Venus A qua software toch wel veel lijkt op de E: hoe gedraagt de backup poort zich bij jullie wanneer grid weg en weer terug komt?

Met de A ervaar ik dat hij uitschakelt als grid weer terug komt.

Het zal vast al vaak genoeg getest zijn, maar bij het uitblijven van een reactie, bij deze zelf getest. Dit is het gedrag van het back-upstopcontact wanneer de grid voor 10 seconde wegvalt.



Van boven naar beneden:

• Inverter status
• Backup stopcontact status
• High Voltage Bus Undervoltage Error
• Grafiek paars: AC Voltage
• Grafiek blauw: AC Off-grid Voltage

Het backup-stopcontact blijft gewoon aan en het duurt een klein minuutje voordat hij weer terug schakelt naar het net.

[Beekforel]

@pascallj thanks, ik zal ook nog wat tests gaan doen dan.

[KeRsTmAnNeKe]

Mijn HA/HACS installatie wil geen data meer ophalen via de local API van mijn V1 Venus. Enig idee hoe ik dat weer aan de gang kan krijgen?
Heb het via de app al een keer uitgezet en daarna weer aangezet, maar dat doet weinig.

[Pharos1985]

pascallj schreef op vrijdag 23 januari 2026 @ 11:29:
[...]


Dat de lokale API zichzelf uitschakelt, klinkt meer dat de batterij uit zichzelf een factory reset doet. We hebben dat vaker gezien. Ik geef steeds het advies doe zelf eerst handmatig een factory reset (zonder behoud van gegevens) en vraag ook via feedback om de nieuwste firmware. Volgens heeft alleen niemand teruggekoppeld of dat daadwerkelijk geholpen heeft.

Verder is er nog het feit dat de CT instabiel wordt (vooral bij gebruik van CT002/3) bij gebruik van de lokale API. Dat is al sinds het begin van de introductie van de API zo. Ik weet niet of dat hier ook van toepassing is, of dat er gewoon steeds gereset wordt.

Bedankt. De batterij 10 minuten zonder stroom gezet (grid afgesloten), factory reset gedaan (beide 2x met telkens reversed volgorde). Echter: zelfde probleem: CT disconnected na +/- 24u en de "distributierules" staan terug op handmatig met niets ingesteld.
Zal maar eens kijken of ik support kan krijgen via de app. Goede batterij qua prijs/kwh maar dit is echt wel sh*t: basis functionaliteit. Gelukkig kan je het snel terug rechtzetten in de app, maar tegen dat het overproductieseizoen begint, hoop ik toch dat dat opgelost raakt.

[pascallj]

Pharos1985 schreef op maandag 26 januari 2026 @ 21:48:
[...]


Bedankt. De batterij 10 minuten zonder stroom gezet (grid afgesloten), factory reset gedaan (beide 2x met telkens reversed volgorde). Echter: zelfde probleem: CT disconnected na +/- 24u en de "distributierules" staan terug op handmatig met niets ingesteld.
Zal maar eens kijken of ik support kan krijgen via de app. Goede batterij qua prijs/kwh maar dit is echt wel sh*t: basis functionaliteit. Gelukkig kan je het snel terug rechtzetten in de app, maar tegen dat het overproductieseizoen begint, hoop ik toch dat dat opgelost raakt.

Bedankt voor de terugkoppeling. Voor de duidelijkheid, ook uitgezet voor of nadat je de batterij zonder stroom hebt gezet? Alleen dan start hij echt opnieuw op.

[GORby]

Pharos1985 schreef op maandag 26 januari 2026 @ 21:48:
[...]


Bedankt. De batterij 10 minuten zonder stroom gezet (grid afgesloten), factory reset gedaan (beide 2x met telkens reversed volgorde). Echter: zelfde probleem: CT disconnected na +/- 24u en de "distributierules" staan terug op handmatig met niets ingesteld.
Zal maar eens kijken of ik support kan krijgen via de app. Goede batterij qua prijs/kwh maar dit is echt wel sh*t: basis functionaliteit. Gelukkig kan je het snel terug rechtzetten in de app, maar tegen dat het overproductieseizoen begint, hoop ik toch dat dat opgelost raakt.

Heb je na die factory reset de API ook terug geactiveerd? Ik heb ook een paar keer zo'n reset gehad, maar sinds ik de API niet meer gebruik (en deze ook uitgeschakeld heb), heb ik geen enkele reset meer gehad, en ook geen verbindingsproblemen met de CT. Misschien kan je het eens proberen zonder de API te activeren, want ik vermoed dat de instabiliteit daar vandaan komt.

[Pharos1985]

Ik heractiveer altijd onmiddellijk de local API, dat klopt. Ook de complete reset heb ik blijkbaar niet gedaan, want heb hem niet manuel uitgeschakeld.

Ik ga dat nu doen (en API uitgeschakeld laten) en wat evalueren volgende dagen.

Bedankt!

[Luke the Duke]

jj85 schreef op maandag 26 januari 2026 @ 15:03:
[...]

Via Lan krijg ik
Mac: dc:32:62:xx:xx:xx
Mac: e4:66:e5:xx:xx:xx

Via Wifi krijg ik
Mac: 18:CE:DF:xx:xx:xx

Is er bekend wat de verschillen zijn met de nieuwe comm modules fw en tussen V116/V122 van de CT003?

Nee helaas, Marstek kan wel updates pushen als je klaagt, maar release info ho maar...
Jammer dat de netwerk stack zo onduidelijk is, dat helpt niet. Twee MAC adressen op LAN snap ik ook niet.

[Luke the Duke]

pascallj schreef op maandag 26 januari 2026 @ 14:04:
[...]

Via LAN is de hostname namelijk 'CH395'.

Dat is interessant, ga ik nakijken. Kunnen meer mensen dit bevestigen wellicht?

[DukeBox]

Luke the Duke schreef op dinsdag 27 januari 2026 @ 10:28:
Dat is interessant, ga ik nakijken. Kunnen meer mensen dit bevestigen wellicht?

V3 WLAN: wlan0
V3 LAN: CH395
CT002: wlan0
En maar 1 MAC per interface.

[pascallj]

Luke the Duke schreef op dinsdag 27 januari 2026 @ 10:28:
[...]


Dat is interessant, ga ik nakijken. Kunnen meer mensen dit bevestigen wellicht?

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

[Luke the Duke]

pascallj schreef op dinsdag 27 januari 2026 @ 10:37:
[...]


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

Oeps, dat had ik kunnen vinden, sorry. Wel een tegenvaller dat de app zo ondoordacht is, o.a. als het gaat om de weergave van de netwerk gegevens. Lijkt me zo eenvoudig te doen. Zal wel een kwestie van prioriteiten zijn.

[DukeBox]

Zag per toeval in mijn logs dat de CT002 iedere 24uur herstart (alleen de wifi?) vanaf het moment dat deze de verbinding heeft opgezet. Dat kan er dan ook voor zorgen dat wanneer iemand meerdere AP's heeft, deze wisselt en evt problemen met verbinding met de MT geeft. Ik zelf heb geen problemen maar mogelijk heeft iemand wat aan de info.

Luke the Duke schreef op dinsdag 27 januari 2026 @ 10:52:
Wel een tegenvaller dat de app zo ondoordacht is, o.a. als het gaat om de weergave van de netwerk gegevens.

Wat is er dan ondoordacht aan? Hij geeft toch duidelijk aan hoe er verbinding wordt gemaakt met het icoontje bovenaan.

[ Voor 33% gewijzigd door DukeBox op 27-01-2026 10:54 ]

[pascallj]

DukeBox schreef op dinsdag 27 januari 2026 @ 10:53:
Zag per toeval in mijn logs dat de CT002 iedere 24uur herstart (alleen de wifi?) vanaf het moment dat deze de verbinding heeft opgezet. Dat kan er dan ook voor zorgen dat wanneer iemand meerdere AP's heeft, deze wisselt en evt problemen met verbinding met de MT geeft. Ik zelf heb geen problemen maar mogelijk heeft iemand wat aan de info.

In welke logs zag je dat? Is het niet gewoon de DHCP lease die vernieuwt na 24 uur?

[DukeBox]

pascallj schreef op dinsdag 27 januari 2026 @ 10:54:
In welke logs zag je dat?

In de logs van mijn AP.

Is het niet gewoon de DHCP lease die vernieuwt na 24 uur?

Nee want dat zorgt niet voor een WiFi disconnect en mijn lease is ook niet 24 uur.

[Luke the Duke]

DukeBox schreef op dinsdag 27 januari 2026 @ 10:53:
Wat is er dan ondoordacht aan?

Zo even uit de losse pols,wat je minimaal wilt:

Venus E:
Weergave eigen IP
Weergave MAC adressen van Ethernet, Wifi en BT
Weergave IP van verbonden P1 meter
Wifi aan en uit kunnen zetten

CT003:
Weergave eigen IP
Weergave MAC adres Wifi en evt. BT
Weergave IP van verbonden Venus E.

Is wat mij betreft allemaal basic.

[DukeBox]

Luke the Duke schreef op dinsdag 27 januari 2026 @ 11:10:
Is wat mij betreft allemaal basic.

Het zou handig zijn maar ik heb heel wat meer apparaten waar je die info niet direct kan zien dus blijkbaar is het minder basic. Als ik bij de homewizard app bij de accu en p1 kijk zie ik die info ook niet.
De meeste mensen zegt het toch niets en diegenen die wat meer kennis hebben halen die info toch vrij eenvoudig uit de router/ap of gewoon je arp table bekijken na een broadcast.

De CH395 is een losse spi module, vermoedelijk hebben ze voor WiFi ook zoiets gedaan en misschien BT ook. Dus ze moeten al die functionaliteit in de MT inbouwen en ik vraag mij af of daar wel genoeg opslag/cpu in zit om dat allemaal goed aan te sturen.

[ Voor 25% gewijzigd door DukeBox op 27-01-2026 11:27 ]

[jj85]

Luke the Duke schreef op dinsdag 27 januari 2026 @ 10:25:
[...]
Twee MAC adressen op LAN snap ik ook niet.

Mijn fout, het zijn twee V3 batterijen, met elk een andere prefix van het mac-adres.
Dus gewoon één MAC per batterij.
Idd met de namen zoals hieronder ook al genoemd.

[dannyro]

DukeBox schreef op dinsdag 27 januari 2026 @ 11:21:
[...]

Het zou handig zijn maar ik heb heel wat meer apparaten waar je die info niet direct kan zien dus blijkbaar is het minder basic. Als ik bij de homewizard app bij de accu en p1 kijk zie ik die info ook niet.
De meeste mensen zegt het toch niets en diegenen die wat meer kennis hebben halen die info toch vrij eenvoudig uit de router/ap of gewoon je arp table bekijken na een broadcast.

De CH395 is een losse spi module, vermoedelijk hebben ze voor WiFi ook zoiets gedaan en misschien BT ook. Dus ze moeten al die functionaliteit in de MT inbouwen en ik vraag mij af of daar wel genoeg opslag/cpu in zit om dat allemaal goed aan te sturen.

In de HW app zie je dat wel hoor, bij apparaten en dan het gewenste apparaat aanklikken en daar staat dit.

[DukeBox]

dannyro schreef op dinsdag 27 januari 2026 @ 12:29:
In de HW app zie je dat wel hoor, bij apparaten en dan het gewenste apparaat aanklikken en daar staat dit.

ID is dan zeker het mac address(?), verder staat daar geen IP/hostname. Ik zie idd wel onder Lokale API het IP staan maar niet op de plek waar ik het verwachtte onder apparaat info.

Maar goed, neemt niet weg dat het wel fijn zou zijn, al het al dan niet ergens onder een weggestopte menu optie, om de info in de MT App te hebben maar echt een ramp vind ik het niet.

[taurgis]

taurgis schreef op maandag 26 januari 2026 @ 12:05:
[...]


Ik heb het ook voor op mijn demo setup, wat gewoon een python scriptje is. Dus dat moet ik nog even bekijken dan.

https://github.com/taurgi...ee/main/tools/mock_device

De onstabiele connectie in realiteit wist ik

Issue zat in mijn UDP connectie die meerdere wou opstarten, code gewijzigd naar een shared UDP client en de mocks werken nu zoals verwacht.

De API is in realiteit instabiel, maar ik blijf nog even optimistisch.

[toktokcity]

Druppeltje_ schreef op zondag 25 januari 2026 @ 14:01:
[...]


De CT-verbinding staat toch los van HA? Of gebruik je de API?

Ik heb het idee dat als HA teveel informatie vraagt aan de Marsteks, de communicatie met CT verstoord raakt. Loopt idd via API.

[De Senaat]

taurgis schreef op dinsdag 27 januari 2026 @ 15:51:
[...]
De API is in realiteit instabiel, maar ik blijf nog even optimistisch.

Mijn ervaring van de afgelopen 2 weken met de API is toch dat de stabiliteit enorm veel verbeterd is.
Voorwaarde is wel dat de MT via LAN aan het netwerk hangt en je je aan de voorgeschreven commando's houdt. Ik werk nu uitsluitend via de API waarmee ik zowel via Windows-PC, ESP32 en android altijd onmiddellijk response heb.
Alleen als ik tussendoor ook nog iets met modbus wil experimenteren zie ik het regelmatig fout gaan zoals CT verbinding die wegvalt, de MT opeens op volle kracht gaat ontladen etc.
Dus dat doe ik niet meer.

[florijn11]

Hallo

Welke slimme meters werken met MT P1 meter

[pascallj]

florijn11 schreef op dinsdag 27 januari 2026 @ 16:50:
Hallo

Welke slimme meters werken met MT P1 meter

In principe allemaal. Kan soms alleen even zoeken zijn welke je moet instellen. Kan zijn dat een andere meter kiezen dan welke je daadwerkelijk hebt, betere resultaten oplevert.

DSMR 5 meters werken beter voor aansturing van batterijen aangezien ze vaker updates geven dan DSMR 4 meters.

[DukeBox]

pascallj schreef op dinsdag 27 januari 2026 @ 16:58:
DSMR 5 meters werken beter voor aansturing van batterijen aangezien ze vaker updates geven dan DSMR 4 meters.

Er zijn heel wat DSMR 5 meters die via de P1 maar om de 10 sec. een update sturen (zoals DSMR 4).

[Nico-G]

Bij handmatige instelling zonder tijdsprogramma gaat mijn MT v2 als een dolle laden met 2500 W in plaats van op stand-by te gaan. Ik heb FW v157 aangevraagd, ben benieuwd...

[pascallj]

DukeBox schreef op dinsdag 27 januari 2026 @ 17:04:
[...]

Er zijn heel wat DSMR 5 meters die via de P1 maar om de 10 sec. een update sturen (zoals DSMR 4).

Technisch gezien sturen ze wel elke seconde een update (dat is verplicht volgens de standaard), alleen hoeft de data niet per se nieuw te zijn. Maar oke, over het algemeen kan DSMR 5 beter werken.

[pascallj]

Nico-G schreef op dinsdag 27 januari 2026 @ 17:12:
Bij handmatige instelling zonder tijdsprogramma gaat mijn MT v2 als een dolle laden met 2500 W in plaats van op stand-by te gaan. Ik heb FW v157 aangevraagd, ben benieuwd...

Probeer eens te switchen tussen UPS en handmatig. Aangezien de UPS modus ook een schema is, kan het zijn dat er iets fout gegaan is bij het uitzetten van dat schema met het switchen.

[DukeBox]

pascallj schreef op dinsdag 27 januari 2026 @ 17:14:
Technisch gezien sturen ze wel elke seconde een update (dat is verplicht volgens de standaard)

Nee, een DSMR 5 meter moet iedere seconde registreren, de P1 poort hoeft niet per seconde te zijn.
Heb er heel wat uitzoekwerk inzitten gezien ik zelf (helaas) zo'n meter heb, vandaar dat ik naar de CT002 ben overgestapt.