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

[antoinevromen]

Situatie:
Batterij: Marstek Venus E 2.0 5.12 kWh
P1-dongle: HomeWizard P1
Slimme-meter: Iskra ME382-D1A52-P1 bouwjaar 2012

Installatie is zojuist gelukt;

Ervaring tijdens de installatie:
Na het installeren van de batterij zelf en hem manual laten laden heb ik geprobeerd de reeds werkende HomeWizard P1 eraan te koppelen.
Lukte op geen manier (hij blijft via bluetooth zoeken naar een CT). Uiteindelijk de bijgeleverde CT003 erin gestoken die uiteindelijk wel werd
herkend via bluetooth, maar waar ik steeds foutmeldingen bij bleef krijgen wanneer hij de configuratie "in the cloud" wilde opslaan.
Tenslotte weer de HomeWizard P1 aan de slimme meter gekoppeld en middels wijzigen CT werd die toen wel meteen herkend op IP-adres (locale api stond al die tijd al aan !!)
Het lijkt erop dat je eerst de originele CT003 moet proberen te koppelen via bluetooth om later de HomeWizard P1 te kunnen koppelen via IP-adres (zonder eerst de CT003 te proberen lukte de HomeWizard P1 niet).

Vraag:
Nu heb ik een goed lopende batterij met daaraan gekoppeld een HomeWizard P1 dongle, die ook via NOM goed draait.
In het overzicht apparaatbeheer blijf ik echter de niet werkende CT003 nog steeds zien.
Hoe kun je die CT003 verwijderen uit je overzicht apparaatbeheer en is dat verstandig aangezien het nu loopt?

Zijn er mensen die geen CT003 meer in hun apparaatbeheer hebben en toch goed kunnen draaien met hun HomeWizard P1?

[matramurena]

antoinevromen schreef op maandag 21 juli 2025 @ 17:46:
Dank je voor de uitleg (inderdaad is het zo dat als je de HW P1 rechtstreeks wilt koppelen dan gaat hij met bluetooth aan de slag; gelukkig slaat hij die stap over als je wilt wisselen van CT003 naar HW P1). Het werkt allemaal nu prima en even na het verwijderen van de CT003 kreeg ik een foutmelding van kan CT niet meer vinden, maar even daarna nam de HW P1 over en draait alles zonder de niet werkende CT003 (die merkwaardig genoeg alleen in apparaatbeheer stond, maar niet meer aan de slimme meter zat of gepowered was).

Ik ben vergeten te noteren hoe ik het precies deed, want ik kreeg de Marstek met HW P1 in één keer aan de praat.
Volgens mij deed ik het zo: Eerst via Bluetooth de Marstek koppelen met de app op de telefoon, daarna WiFi netwerk configureren, vervolgens CT of P1 meter kiezen, P1 gekozen en de HW P1 laten zoeken op WiFi. Eigenlijk volgde ik wat de app me vroeg. Ergens zit ook een stap met een check op de laatste firmware, maar die stond er bij mij al op.
Wat ik van tevoren wel heb gedaan, is van alle HW devices behalve de P1 de local API uitgeschakeld. Niet dat het denk ik echt nodig was, maar een YouTuber die de Marstek demonstreerde (Kris Tech Review) zei dat hij alle HW devices er fysiek had uitgetrokken. Dat leek me een beetje overbodig, als de local API uitstaat zie je ze niet meer op het netwerk.
Benieuwd hoe het straks gaat als ik de HW P1 ga vervangen door een CT-002.

Ik heb net het rendement over het afgelopen etmaal berekend:
6,6kWh in
5,2kWh uit
RTE = 5,2/6,6 = 78,8%
tussentijds is er wat ontladen (met name tijdens het koken) en weer bijgeladen. In hoeverre deze metingen kloppen weet ik niet, er zit in ieder geval wat verschil in wat de HW Energy Socket aangeeft en wat de Marstek aangeeft.
Maximaal opladen:
Marstek 2491W, HW 2543W
Maximaal ontladen:
Marstek 2492W, HW 2486W

[ Voor 0% gewijzigd door matramurena op 22-07-2025 07:37 . Reden: Typefout ]

[antoinevromen]

iorses schreef op donderdag 11 september 2025 @ 19:33:
[...]

https://we.tl/t-GDvoMlN4t2
Link werkt maar een paar dagen helaas, maar ze hebben hem mij toegestuurd bij het activeren van de API.

Hallo @iorses
Heb je die EM.GetStatus zelf al eens gedraaid via de local-api?
Zo ja moet je die ook tegen het ip-adres van de batterij draaien of tegen het ip-adres van de CT?

Ik krijg een parse-error ofschoon de syntax volgens het document vrijwel identiek is aan die van ES.GetStatus (die bij mij wel werkt). Maar EM.GetStatus doet het niet (maar dat zou dus kunnen omdat ik geen CT002/CT003 heb)

[iorses]

antoinevromen schreef op donderdag 11 september 2025 @ 20:05:
[...]

Hallo @iorses
Heb je die EM.GetStatus zelf al eens gedraaid via de local-api?
Zo ja moet je die ook tegen het ip-adres van de batterij draaien of tegen het ip-adres van de CT?

Ik krijg een parse-error ofschoon de syntax volgens het document vrijwel identiek is aan die van ES.GetStatus (die bij mij wel werkt). Maar EM.GetStatus doet het niet (maar dat zou dus kunnen omdat ik geen CT002/CT003 heb)

Zoals ik toenstraks vermeldde gebruik ik het zelf om CT status uit te lezen maar merkte ik connectie verlies op van de CT sinds ik dit doe.
Ik heb bijv 4 batterijen dus pak het van de 4 IP adressen van de batterijen en heb 4 sensoren in Home Assistant.

Dit is de output die je krijgt:

code:

 {
    "id":   1,
    "src":  "VenusE-xxx",
    "result":   {
        "id":   0,
        "ct_state": 1,
        "a_power":  -353,
        "b_power":  269,
        "c_power":  69,
        "total_power":  -19
    }
}

Best kans dat het niet werkt zonder CT002/CT003.
Ik denk dat bij bijv HW P1 de data niet opgehaald wordt via UDP.
Dat is ook gelijk een reden waarom andere meters niet werken bij meerdere batterijen, ik vermoed dat elke batterij dan individueel data opvraagt.

[ Voor 11% gewijzigd door iorses op 11-09-2025 20:22 ]

[gmj2]

trojaanspaard schreef op vrijdag 12 september 2025 @ 22:27:
[...]

Yes, de local api staat aan. Die is inderdaad ook nodig om de P1 in HA te integreren. De P1 wordt herkend in de mt app, is online, het CT ledje op de MT zelf is aan, alleen de data wordt niet uitgelezen, en de diagnose wordt nooit afgerond. Ik heb een 3fase aansluiting, maar wisselen tussen 3 of 1 fase in de app maakt ook geen verschil

[Afbeelding]

Iets soortgelijks had ik ook met de HW P1. Ik kan me niet helemaal herinneren wat ik heb gedaan om dat goed te krijgen, maar ben tijdje terug alweer overgestapt naar de CT003. Belangrijk is in ieder geval dat je een simpel en plat netwerk hebt (geen IoT, vlans, of iets anders dat verschil maakt in onderlinge toegang lokaal en naar internet, geen DNS director etc.). Je kan proberen om eerst de CT uit je configuratie te wissen in de App (en wacht minimaal 5 minuten), weer toevoegen als nieuwe CT (zonder een nieuwe naam te geven) en de MT te laten koppelen met de CT en vervolgens weer met de HW P1 koppelen. Ook moet je deze stappen niet te snel achter elkaar doen, er kan nog wat left-overs op de Marstek cloud servers staan, wat niet meteen weg is wat ook problemen kan geven. Eventueel kan je proberen om de HA integratie met de HW P1 even uit te zetten (als ook alle HW apps op je mobiel die de HW P1 meter uitlezen en/of andere HW apparaten die iets doen met de HW P1) zodat de P1 meter alleen maar de http API calls van de MT batterij voor zijn kiezen krijgt tijdens die diagnose fase. HW P1 is simpel ding, en kan niet al te veel tegelijk doen...

[Druppeltje_]

dannyro schreef op vrijdag 26 september 2025 @ 18:19:
[...]

Ik zou je wel aanraden om met modbus sturing te werken. Veel betrouwbaarder. Hame Relay (mqtt) is te gevoelig voor fw updates. Als je uren tijd besteed aan programma’s maken wil je wel dat dit blijft werken.@AUijtdehaag kan je hiermee helpen👍

Begrijp ik, topic heb ik ook volledig nagelezen (ik doe mijn huiswerk ) Via mqtt was nu voor bekend te worden met het HA gebeuren het makkelijkst. Op een paar minuutjes staat dat in HA en werkt dat. API was ook een piste maar hoewel beiden batterijen de local API hebben aanstaan, krijg ik maar van 1 van beiden info door + de verbinding met de CT003 reageert hier op. Zeer opvallend. Op dik 4 maanden tijd heb ik welgeteld 1x een uitval gehad van de CT003. Met de API open elke 10minuten. API terug uit -> geen enkele uitval meer. Laatste argument dat ik heb is dat ik hier heb zien voorbij komen dat Marstek de Modbus ondersteuning gaat stopzetten.

[dannyro]

Druppeltje_ schreef op vrijdag 26 september 2025 @ 19:17:
[...]


Begrijp ik, topic heb ik ook volledig nagelezen (ik doe mijn huiswerk ) Via mqtt was nu voor bekend te worden met het HA gebeuren het makkelijkst. Op een paar minuutjes staat dat in HA en werkt dat. API was ook een piste maar hoewel beiden batterijen de local API hebben aanstaan, krijg ik maar van 1 van beiden info door + de verbinding met de CT003 reageert hier op. Zeer opvallend. Op dik 4 maanden tijd heb ik welgeteld 1x een uitval gehad van de CT003. Met de API open elke 10minuten. API terug uit -> geen enkele uitval meer. Laatste argument dat ik heb is dat ik hier heb zien voorbij komen dat Marstek de Modbus ondersteuning gaat stopzetten.

Tot wat ik nu begrepen heb, is de api te beperkt Je mag altijd eens melden wat je allemaal kan uitlezen. Over het stoppen van de modbus ondersteuning, ja heb ik ook zien voorbijkomen. Maar ja, je ziet zoveel voorbijkomen he😉

[antoinevromen]

SatScan schreef op zondag 28 september 2025 @ 20:26:
[...]


Als je de API gebruikt dan verliest de batt connectie met de CT003 op dit moment... API is nog in beta fase.
Dus geen set and forget optie voor nu

@SatScan Oke. Dat zou misschien een verklaring kunnen zijn waarom ik geen problemen heb met de local-api of de CT (ik heb namelijk een HW-P1).

[Joarie]

pannekoek schreef op woensdag 1 oktober 2025 @ 10:55:
[...]

Alles acuteel (HW en MT firmware), local api staat aan. Ik heb alleen mijn enphase envoy in de HW app nog staan, verder geen HW producten. Locatie is toegestaan bij gebruik app.

EDIT: hoort het CT icoontje niet bij voorbaat al groen te zijn? Of is dat alleen als je een CT hebt gekoppeld al

Bij mij is het icoontje gewoon grijs in de app (al een tijdje niet meer groen gezien). Maar als ik er op druk dan springt hij meteen naar de (gekoppelde) CT003 meter en laat hij actuele waardes zien.

[djdj105]

WargamingPlayer schreef op zaterdag 4 oktober 2025 @ 11:42:
[...]

Afgelopen nacht werd ik wakker doordat mijn ingestelde trigger af ging dat de CT003 niet meer gekoppeld was.
[......]

Ik ben nu geheel gestopt met de CT003, na vanmorgen nog enkele pogingen te doen. Zoals nogmaals het juiste WIFI netwerk selecteren in zowel CT003 als Venus. Daarna koppeling maken alles "groen" maar na enkele minuten toch weer "CT offline". Ook zonder local API in gebruik, daar dit ook nadelig leek op de stabiliteit. Ben er ff helemaal klaar mee.

Nu met de B2500 / Shelly EM emulatie in HA, CT koppeling constant OK.
Echter merk ik met deze wisselvallige PV output (wolken/zon steeds korte periodes) dat hij het totaal niet kan volgen ook al doet hij z'n best maar steeds enorme overschoots heeft waardoor NOM complete puinhoop is.

[Hans C]

djdj105 schreef op zaterdag 4 oktober 2025 @ 12:17:
[...]


Ik ben nu geheel gestopt met de CT003, na vanmorgen nog enkele pogingen te doen. Zoals nogmaals het juiste WIFI netwerk selecteren in zowel CT003 als Venus. Daarna koppeling maken alles "groen" maar na enkele minuten toch weer "CT offline". Ook zonder local API in gebruik, daar dit ook nadelig leek op de stabiliteit. Ben er ff helemaal klaar mee.

Nu met de B2500 / Shelly EM emulatie in HA, CT koppeling constant OK.
Echter merk ik met deze wisselvallige PV output (wolken/zon steeds korte periodes) dat hij het totaal niet kan volgen ook al doet hij z'n best maar steeds enorme overschoots heeft waardoor NOM complete puinhoop is.
[Afbeelding]

Ik had ook een zeer traag reagerende CT003. 1 van de batterijen was niet meer bereikbaar en kreeg ik niet meer gekoppeld. Die batterij heb ik vervolgens teruggezet naar fabrieksinstellingen met behoud van data en daarna werkt het stukken beter.

[Preaper]

PNARI schreef op dinsdag 7 oktober 2025 @ 11:22:
[...]

Ik heb MT gevraagd om de API aan te zetten maar kreeg antwoord dat ze dat niet konden doen .[Afbeelding]

Ergens verbaasd me dit ook niet. Ik heb (op v153) alleen nog maar instabiliteit ondervonden sinds het inschakelen van de Local API (en het actief pollen via https://github.com/jaapp/ha-marstek ).
De Marstek raakt zijn verbinding met de CT003 kwijt, lijkt soms niet meer te reageren op de app. Local API knalt er ook op willekeurige momenten uit en dan is een systeem reboot van de Marstek batterij nodig. Veel informatieverzoeken op de API geven willekeurig geen of wel response.

Los daarvan lijken belangrijke sensoren (zoals geimporterde / exporteerde energie) geen goede waardes terug te geven en reageert de batterij ook nog niet goed op commando's!

Hier moet nog hoop werk worden verzet door Marstek...

[ Voor 3% gewijzigd door Preaper op 07-10-2025 12:33 ]

[S2S]

Preaper schreef op dinsdag 7 oktober 2025 @ 12:32:
[...]


Ergens verbaasd me dit ook niet. Ik heb (op v153) alleen nog maar instabiliteit ondervonden sinds het inschakelen van de Local API (en het actief pollen via https://github.com/jaapp/ha-marstek ).
De Marstek raakt zijn verbinding met de CT003 kwijt, lijkt soms niet meer te reageren op de app. Local API knalt er ook op willekeurige momenten uit en dan is een systeem reboot van de Marstek batterij nodig. Veel informatieverzoeken op de API geven willekeurig geen of wel response.

Los daarvan lijken belangrijke sensoren (zoals geimporterde / exporteerde energie) geen goede waardes terug te geven en reageert de batterij ook nog niet goed op commando's!

Hier moet nog hoop werk worden verzet door Marstek...

Is allemaal veel werk, bouw zelf dagelijks aan endpoints. Niet voor Marsteks .

[pascallj]

Preaper schreef op dinsdag 7 oktober 2025 @ 12:32:
[...]


Ergens verbaasd me dit ook niet. Ik heb (op v153) alleen nog maar instabiliteit ondervonden sinds het inschakelen van de Local API (en het actief pollen via https://github.com/jaapp/ha-marstek ).
De Marstek raakt zijn verbinding met de CT003 kwijt, lijkt soms niet meer te reageren op de app. Local API knalt er ook op willekeurige momenten uit en dan is een systeem reboot van de Marstek batterij nodig. Veel informatieverzoeken op de API geven willekeurig geen of wel response.

Los daarvan lijken belangrijke sensoren (zoals geimporterde / exporteerde energie) geen goede waardes terug te geven en reageert de batterij ook nog niet goed op commando's!

Hier moet nog hoop werk worden verzet door Marstek...

Is er nog een andere HA integratie beschikbaar voor de API? Ik heb blijkbaar de boot gemist ondertussen. Mag heel hard mijn best gaan doen merk ik

[Magicw00b]

Preaper schreef op dinsdag 7 oktober 2025 @ 12:32:
[...]


Ergens verbaasd me dit ook niet. Ik heb (op v153) alleen nog maar instabiliteit ondervonden sinds het inschakelen van de Local API (en het actief pollen via https://github.com/jaapp/ha-marstek ).
De Marstek raakt zijn verbinding met de CT003 kwijt, lijkt soms niet meer te reageren op de app. Local API knalt er ook op willekeurige momenten uit en dan is een systeem reboot van de Marstek batterij nodig. Veel informatieverzoeken op de API geven willekeurig geen of wel response.

Los daarvan lijken belangrijke sensoren (zoals geimporterde / exporteerde energie) geen goede waardes terug te geven en reageert de batterij ook nog niet goed op commando's!

Hier moet nog hoop werk worden verzet door Marstek...

Welke het pullen naar de API bij jou wel, bij mij op alle 3 de batterijen alleen de initiële setup en daarna niks meer:


in de logs wel deze gevonden:
Deze fout is ontstaan door een aangepaste integratie.

Logger: custom_components.marstek_local_api.api
Bron: custom_components/marstek_local_api/api.py:257
integratie: Marstek Local API (documentatie, problemen)
Eerst voorgekomen: 14:33:38 (64 gebeurtenissen)
Laatst gelogd: 14:43:22

Command ES.GetStatus timed out after 15s (host=10.0.1.75, transport=True, connected=True)
Command EM.GetStatus timed out after 15s (host=10.0.1.75, transport=True, connected=True)
Command EM.GetStatus timed out after 15s (host=10.0.1.77, transport=True, connected=True)
Command Bat.GetStatus timed out after 15s (host=10.0.1.77, transport=True, connected=True)
Command Bat.GetStatus timed out after 15s (host=10.0.1.30, transport=True, connected=True)

lijkt er dus op dat de api niet reageert. Nu zit ik op firmware V114, waar zit jij op?

[antoinevromen]

Preaper schreef op dinsdag 7 oktober 2025 @ 12:32:
[...]


Ergens verbaasd me dit ook niet. Ik heb (op v153) alleen nog maar instabiliteit ondervonden sinds het inschakelen van de Local API (en het actief pollen via https://github.com/jaapp/ha-marstek ).
De Marstek raakt zijn verbinding met de CT003 kwijt, lijkt soms niet meer te reageren op de app. Local API knalt er ook op willekeurige momenten uit en dan is een systeem reboot van de Marstek batterij nodig. Veel informatieverzoeken op de API geven willekeurig geen of wel response.

Los daarvan lijken belangrijke sensoren (zoals geimporterde / exporteerde energie) geen goede waardes terug te geven en reageert de batterij ook nog niet goed op commando's!

Hier moet nog hoop werk worden verzet door Marstek...

Dat heeft te maken met hoe je aan de HA kant de integratie richting de local-API geprogrammeerd hebt/is. Als je daar zonder voldoende rekening te houden met het asynchrone aspect van UDP en de hoge frequenties van Home Assistant berichten mee gaat afvuren naar de batterij (local-api), dan krijg je dit soort zaken. Ik draai al maanden met de local-api vanuit een power-shell-script heel stabiel (elke 15 minuten een programma-call met al dan niet een mogelijke mode-switch op basis van de business-logica. Het kan dus wel en mijn ervaring uit mijn werkzame verleden (met aysnchrone software MQ-series) leert mij dat dit heel iets anders is dan een synchrone-rpc/webservice-call uitvoeren..

[Preaper]

antoinevromen schreef op dinsdag 7 oktober 2025 @ 15:19:\

Dat heeft te maken met hoe je aan de HA kant de integratie richting de local-API geprogrammeerd hebt/is. Als je daar zonder voldoende rekening te houden met het asynchrone aspect van UDP en de hoge frequenties van Home Assistant berichten mee gaat afvuren naar de batterij (local-api), dan krijg je dit soort zaken. Ik draai al maanden met de local-api vanuit een power-shell-script heel stabiel (elke 15 minuten een programma-call met al dan niet een mogelijke mode-switch op basis van de business-logica. Het kan dus wel en mijn ervaring uit mijn werkzame verleden (met aysnchrone software MQ-series) leert mij dat dit heel iets anders is dan een synchrone-rpc/webservice-call uitvoeren..

De integratie houdt daar al rekening mee door niet alle data continu op te vragen. Maar er valt ongetwijfeld nog het een en ander te verbeteren - ik sta open voor feedback.

Los daarvan: als je elke 15 minuten een call doet, heb je waarschijnlijk weinig problemen. Dan verwacht je ook niet veel van de API. Zodra je echter realtime data nodig hebt om de batterij dynamisch aan te sturen, wordt het een ander verhaal. Dan blijkt al snel dat de local API gewoon niet stabiel is.

Dat gezegd hebbende: het blijft natuurlijk onacceptabel dat de Marstek zelf instabiel wordt, de CT003-verbinding kwijtraakt of zelfs een reboot nodig heeft. Een batterijcontroller hoort robuust te blijven. Dit is niet alleen slecht design - het is potentieel gevaarlijk bij een batterij.

[antoinevromen]

Preaper schreef op dinsdag 7 oktober 2025 @ 15:34:
[...]


De integratie houdt daar al rekening mee door niet alle data continu op te vragen. Maar er valt ongetwijfeld nog het een en ander te verbeteren - ik sta open voor feedback.

Los daarvan: als je elke 15 minuten een call doet, heb je waarschijnlijk weinig problemen. Dan verwacht je ook niet veel van de API. Zodra je echter realtime data nodig hebt om de batterij dynamisch aan te sturen, wordt het een ander verhaal. Dan blijkt al snel dat de local API gewoon niet stabiel is.

Dat gezegd hebbende: het blijft natuurlijk onacceptabel dat de Marstek zelf instabiel wordt, de CT003-verbinding kwijtraakt of zelfs een reboot nodig heeft. Een batterijcontroller hoort robuust te blijven. Dit is niet alleen slecht design - het is potentieel gevaarlijk bij een batterij.

@Preaper Belangrijke aspecten bij de local-api-calls zijn retrys/wait-times/inter-call-times/error-handling/vooraf-en-achteraf drainen van late-packages en beperken van de hoeveelheid berichten.
Het is zeker niet het mechanisme om real-time sturing in de zin van bij NOM-houden mee uit te voeren. Maar 1 x per kwartier kijken of je de modus van AI, NOM, MANUAL, PASSIVE zou moeten aanpassen werkt voor mij prima en valt gewoon onder dynamisch sturen (alleen niet op micro-nivo). Ik zie als ik aan het programmeren ben en tussen de geplande geautomatiseerde call's van de task-scheduler door ook zelf nog berichten afvuur ook wel eens dat er verschillende nagekomen antwoorden nog in de interne queues van UDP zitten (die ik eerst weglees). (als je dat niet doet lijkt het alsof je geen goed antwoord krijgt en dan krijg je timeouts en lijkt de local-api niet op je vragen te reageren). Eigenlijk ben je dan de queues aan het verstoppen. Zoals ik al schreef heeft alles te maken met frequentie en handling van de berichten. Voorbeelden van mijn power-shell-scripts vind je in het forum Marstek PIB Domotica integratie en je Energierekening (is al een oudere versie, maar de basiszaken zit daar in). Anders kun je me nog een PB sturen en deel ik daar mijn laatste versie. Als je echt realtime-sturing zeg per 5 of 10seconden wilt gaan doen (ik kan niet direct nu een use-case daarvoor bedenken, dus verbaas me maar), kun je beter met modbus gaan werken lijkt mij. @pascallj Klopt dit laatste van modbus bij de wens voor real-time-schakeling?

[Preaper]

antoinevromen schreef op dinsdag 7 oktober 2025 @ 15:50:
[...]

@Preaper Belangrijke aspecten bij de local-api-calls zijn retrys/wait-times/inter-call-times/error-handling/vooraf-en-achteraf drainen van late-packages en beperken van de hoeveelheid berichten.
Het is zeker niet het mechanisme om real-time sturing in de zin van bij NOM-houden mee uit te voeren. Maar 1 x per kwartier kijken of je de modus van AI, NOM, MANUAL, PASSIVE zou moeten aanpassen werkt voor mij prima en valt gewoon onder dynamisch sturen (alleen niet op micro-nivo). Ik zie als ik aan het programmeren ben en tussen de geplande geautomatiseerde call's van de task-scheduler door ook zelf nog berichten afvuur ook wel eens dat er verschillende nagekomen antwoorden nog in de interne queues van UDP zitten (die ik eerst weglees). (als je dat niet doet lijkt het alsof je geen goed antwoord krijgt en dan krijg je timeouts en lijkt de local-api niet op je vragen te reageren). Eigenlijk ben je dan de queues aan het verstoppen. Zoals ik al schreef heeft alles te maken met frequentie en handling van de berichten. Voorbeelden van mijn power-shell-scripts vind je in het forum Marstek PIB Domotica integratie en je Energierekening (is al een oudere versie, maar de basiszaken zit daar in). Anders kun je me nog een PB sturen en deel ik daar mijn laatste versie. Als je echt realtime-sturing zeg per 5 of 10seconden wilt gaan doen (ik kan niet direct nu een use-case daarvoor bedenken, dus verbaas me maar), kun je beter met modbus gaan werken lijkt mij. @pascallj Klopt dit laatste van modbus bij de wens voor real-time-schakeling?

Je zet me aan het denken - dat waardeer ik. Er valt vast nog wat te verbeteren in hoe ik de data inlees. Het verschil zit denk ik vooral in wat we van het apparaat verwachten. Ik bekijk het als consument en verwacht dat het systeem stabiel blijft, niet zijn CT003-verbinding verliest en niet stopt met reageren op API-calls op de frequentie waarmee ik hem nu bevraag. Dat lijkt me geen onredelijke verwachting.

Ter vergelijking: mijn BLE-gateway ( https://github.com/jaapp/marstek-ble-gateway ) leest elke 10 seconden BMS-waardes uit en dat werkt probleemloos. Dat vormt voor mij de basis van de verwachting dat de Local API ook kortcyclische updates moet kunnen leveren.

Maar, ik zal mijn verwachtingen bijstellen - ik zal wel moeten. Maar het blijft dat de Local API nog flink aan verbetering toe is.

[antoinevromen]

Preaper schreef op dinsdag 7 oktober 2025 @ 17:35:
[...]


Je zet me aan het denken - dat waardeer ik. Er valt vast nog wat te verbeteren in hoe ik de data inlees. Het verschil zit denk ik vooral in wat we van het apparaat verwachten. Ik bekijk het als consument en verwacht dat het systeem stabiel blijft, niet zijn CT003-verbinding verliest en niet stopt met reageren op API-calls op de frequentie waarmee ik hem nu bevraag. Dat lijkt me geen onredelijke verwachting.

Ter vergelijking: mijn BLE-gateway ( https://github.com/jaapp/marstek-ble-gateway ) leest elke 10 seconden BMS-waardes uit en dat werkt probleemloos. Dat vormt voor mij de basis van de verwachting dat de Local API ook kortcyclische updates moet kunnen leveren.

Maar, ik zal mijn verwachtingen bijstellen - ik zal wel moeten. Maar het blijft dat de Local API nog flink aan verbetering toe is.

@Preaper . En wat zal er nou voor processor-/netwerk-hardware in een batterij zitten. De grootste supercomputers kun je middels een ddos-aanval plat leggen.
Ik ben bang dat door de ingeslagen weg door Marstek van UDP als communicate en niet TCP/IP dit gedrag niet zal gaan veranderen. Wat niet wegneemt dat je waarschijnlijk bij een synchrone variant net zo goed tegen de limieten van de processor-hardware zou aanlopen. Onze applicaties kunnen gewoon niet goed omgaan met berichten die in verschillende (niet volgtijdelijke) volgorde retour komen.

Toch ben ik nog steeds gewoon benieuwd welke sturingswens je vanuit HA hebt waarvoor je zo vaak de batterij wilt bevragen?

Ja je krijgt bij dit soort systemen die op basis van queueing werken als snel wachtrij-problematiek.
Dan lijkt iets niet meer te werken, maar dan is het systeem nog bezig met berichten die vooraf aan jouw bericht in de queue staan. Maakt niet uit. Ik ben mij namelijk niet zeker of of zo'n BLE-gateway (ik neem aan hetzelfde als de rweijnen-tool op basis van bluetooth zal werken met de batterij. Volgens mij is bluetooth een synchrone connectie). Ook die kun je natuurlijk overvoeren, maar die bufferen geen nieuwe requests meer als ze overvoert worden (die surplus-verzoeken gaan gewoon allemaal down-the-drain) Zie het als een soort DDos-aanval, die wordt op een gegeven moment ook gewoon geblocked en niet meer verder geprocessed;

Wij (mensen) hebben de gewoonte om bij een vraag ook per ommegaande een antwoord te krijgen. En daar zijn asynchrone systemen juist niet voor bedoeld. In een asynchroon systeem stel je een vraag en ergens in de tijd komt er een antwoord. De volgorde van die antwoorden is dan ook vaak niet eens vooraf te voorspellen. Alleen als je aan de luisterende kant gewoon alle antwoorden weer separaat verwerkt alsof het ook weer een los bericht is, waar je als ontvanger op gaat acteren heb je van al die asynchroniteit geen last.

[djdj105]

Sorry dat ik het moet zeggen UDP heeft geen queues. Maar:

Misschien heeft de Marstek EME intern een queue om ontvangen commando's in te bewaren, of de antwoorden daarop, maar als die na een minuut nog niet leeg zijn, ga ik er van uit dat ze nooit leeg zullen raken. Wat valt er dan nog leeg te maken ?

Alleen al het feit dat local API aangezet is, zonder er iets naar toe te sturen gaf bij mij al instabiliteit van de verbinding met de CT003. Voor mij onbruikbaar en dus maar alles weer uitgezet en bij een volgende firmware update nog maar eens testen.

[antoinevromen]

djdj105 schreef op dinsdag 7 oktober 2025 @ 19:07:
Sorry dat ik het moet zeggen UDP heeft geen queues. Maar:

Misschien heeft de Marstek EME intern een queue om ontvangen commando's in te bewaren, of de antwoorden daarop, maar als die na een minuut nog niet leeg zijn, ga ik er van uit dat ze nooit leeg zullen raken. Wat valt er dan nog leeg te maken ?

Alleen al het feit dat local API aangezet is, zonder er iets naar toe te sturen gaf bij mij al instabiliteit van de verbinding met de CT003. Voor mij onbruikbaar en dus maar alles weer uitgezet en bij een volgende firmware update nog maar eens testen.

@djdj105 Ja dat bedoel ik natuurlijk ook met queues dat er intern een vorm van vasthouden van binnenkomende requests is (ik noem dat queueing, waardoor je soms geen antwoord krijgt omdat de batterij nog een vorig verzoek aan het processen is). Ik tref soms meerdere nagekomen antwoorden nog terug bij een udp.Receive (dus er kunnen wel degelijk nog berichten zijn die je vooraf aan je programmalogica kan weglezen om te bevorderen dat het eerstvolgende bericht dat retour komt ook behoort bij jouw laatste request; Dus dan valt er wel degelijk iets leeg te maken !!).
Ik heb zelf de Home Wizard P1-dongle, dus kan niet spreken over de CT003 qua stabiliteit (om de simpele reden dat die bij niet niet eens functioneert). Misschien heeft het wel eerder met dat productonderdeel te maken omdat die CT003 niet in staat was om met mijn digitale meter te werken, waar de HW P1 dat prima doet. Over verbindingsperikelen rondom de CT003 staat het forum vol, maar het staat natuurlijk iedereen vrij zijn eigen keuzes te maken.
Een winstpakker hebben we gelukkig al: jij zult nu na het uitzetten van de local-api geen meldingen meer hoeven te maken van instabiliteit rondom de CT003.

Maar ik kan mij niet vinden in de stelling dat alleen het aanzetten van een Local-API zonder berichten te zenden de CT003 instalbiel maakt. Waar komt dan al die instalbiliteit bij alle andere mensen in het forum vandaan die geen Local-Api open hebben staan?

[Druppeltje_]

antoinevromen schreef op dinsdag 7 oktober 2025 @ 19:59:
[...]

.... Maar ik kan mij niet vinden in de stelling dat alleen het aanzetten van een Local-API zonder berichten te zenden de CT003 instalbiel maakt. Waar komt dan al die instalbiliteit bij alle andere mensen in het forum vandaan die geen Local-Api open hebben staan?

Ik praat alleen over mezelf als ik zeg dat mijn 2 Marsteks vanaf halverwege mei draaien met de CT003. Dat was een echte set and forget. Ik heb niet 1 keer een uitval gehad. Liep als een trein. Ik heb een kleine maand geleden op vrijdagavond de API aan gezet. 's ochtends: verbinding weg. Terug gekoppeld. Uur later: verbinding weg. Dit heb ik 6 of 7 keer moeten herhalen op zaterdag. Sommige keren ging het koppelen door gewoon terug de CT003 toe te voegen. Andere keren was dat 20min klooien om hem terug gekoppeld te krijgen. Ik wist opeens hoe de frustraties van uitval van sommigen hier voelden. Ik heb toen 's namiddags de API terug uitgeschakeld. Nu 4 weken verder: geen enkele uitval meer gehad. Ik ben er (in mijn geval alleszins) voor 99,99% zeker dat het die zaterdag voormiddag aan de ingeschakelde API lag.

[djdj105]

Druppeltje_ schreef op dinsdag 7 oktober 2025 @ 20:41:
[...]


Ik heb toen 's namiddags de API terug uitgeschakeld. Nu 4 weken verder: geen enkele uitval meer gehad. Ik ben er (in mijn geval alleszins) voor 99,99% zeker dat het die zaterdag voormiddag aan de ingeschakelde API lag.

Blij dat ik niet de enige ben die de relatie tussen Venus- CT003 instabiliteit en local-api enabled heeft gemerkt.
Maar of het probleem nou aan de Venus kant, of aan de CT003 kant zit, ben ik nog niet zeker van.

[ Voor 9% gewijzigd door djdj105 op 07-10-2025 20:46 ]

[djdj105]

antoinevromen schreef op dinsdag 7 oktober 2025 @ 19:59:
[...]

@djdj105\Een winstpakker hebben we gelukkig al: jij zult nu na het uitzetten van de local-api geen meldingen meer hoeven te maken van instabiliteit rondom de CT003.

@antoinevromen Antoine, ik heb natuurlijk een vraag gesteld aan Marstek support hierover, maar zolang er geen nieuwe/verbeterde firmware voor een van beide apparaten uitkomt, ga ik hier geen tijd meer in steken.

Ik heb je een PB gestuurd

[DSSW]

djdj105 schreef op dinsdag 7 oktober 2025 @ 20:44:
[...]


Blij dat ik niet de enige ben die de relatie tussen Venus- CT003 instabiliteit en local-api enabled heeft gemerkt.
Maar of het probleem nou aan de Venus kant, of aan de CT003 kant zit, ben ik nog niet zeker van.

Hier identiek, api staat terug uit, ik ga het opvolgen of de CT003 nu terug stabiel blijft zoals de 6 maanden voor activeren van de api.

[antoinevromen]

djdj105 schreef op dinsdag 7 oktober 2025 @ 20:44:
[...]


Blij dat ik niet de enige ben die de relatie tussen Venus- CT003 instabiliteit en local-api enabled heeft gemerkt.
Maar of het probleem nou aan de Venus kant, of aan de CT003 kant zit, ben ik nog niet zeker van.

@Druppeltje_ Naast jou schreef nog iemand dat hij vermoedt dat de local-api de ct003 verstoord heeft. Dan zit er toch serieus iets mis bij de koppeling tussen de batterij en een ct003. Ik heb hier met de hw p1 geen ervaring mee en draai al maanden mijn scripts tegen de local api. Misschien nu ik dit schrijf zou het kunnen dat in tegenstelling tot de hw p1 een ct003 zelf gaat communiceren richting de batterijen vanwege de sturing die daar in zit om meerdere batterijen te kunnen beheren. @pascallj zou dat misschien kunnen? Ik heb geen idee of de batterij of de ct003 het initiatief heeft bij sturing vanuit de ct. Terwijl een hw p1 die geen weet heeft van een marstek batterij enkel communiceert met de batterij als de batterij iets vraagt aan de hw p1

[Druppeltje_]

antoinevromen schreef op dinsdag 7 oktober 2025 @ 21:57:
[...]

@Druppeltje_ Naast jou schreef nog iemand dat hij vermoedt dat de local-api de ct003 verstoord heeft. Dan zit er toch serieus iets mis bij de koppeling tussen de batterij en een ct003. Ik heb hier met de hw p1 geen ervaring mee en draai al maanden mijn scripts tegen de local api. Misschien nu ik dit schrijf zou het kunnen dat in tegenstelling tot de hw p1 een ct003 zelf gaat communiceren richting de batterijen vanwege de sturing die daar in zit om meerdere batterijen te kunnen beheren. @pascallj zou dat misschien kunnen? Ik heb geen idee of de batterij of de ct003 het initiatief heeft bij sturing vanuit de ct. Terwijl een hw p1 die geen weet heeft van een marstek batterij enkel communiceert met de batterij als de batterij iets vraagt aan de hw p1

Ik heb er geen idee van. Mijn technische kennis op dat vlak is te beperkt. Ik kan hier enkel meedelen hetgeen ik merk en waar ik zeker van ben. Aan placebo-effecten, aannames of vermoedens doe ik nooit mee. Door het probleem te benoemen komt er hopelijk misschien een oplossing uit de bus. Mijn MT's hebben een zeer belabberde verbinding met de router. Die staan er 15m vanaf in een niet-gebruikte betonnen kelder. Verder dan 1 wifistreepje in de app kom ik bijvoorbeeld niet. Toch heb ik nooit last van verbindingsverlies tot die ene dag met de API aan. Los van dit alles, en zeker als je dit topic al lange tijd volgt zoals ik, heeft het hele Marstek gebeuren gewoon 1 grote zwakke plek. En dat zijn de verbindingsproblemen (ook buiten de ingeschakelde API) Het is enkel te hopen dat dat ooit opgelost geraakt, en ik kan enkel heel, héél blij zijn dat ik daar in het dagelijks gebruik werkelijk nooit last van heb.

[Preaper]

antoinevromen schreef op vrijdag 10 oktober 2025 @ 19:48:
[...]

In combinatie met mijn HW P1 heb ik in elk geval geen probleem met de local-api.
Zover ik uit een post van @Preaper van gisteren? heb begrepen heeft hij de software onder de Home Assistant - local-api add-on aangepast en kan hij nu zonder uitval van de CT draaien met een iets minder hoge frequentie.

Afgelopen 24u heeft het heel stabiel gedraaid. Waarmee ik bedoel dat de verbinding met de CT003 niet is verdwenen en de software van de Marstek ook niet de nek om is gedraaid.

Maar er is wel 2,3kWh aan stroom het net op geëxporteerd dus de batterij lijkt niet zo snel meer te reageren. Maar ik heb het idee dat dit de CT003 is, die werkt niet zo geweldig.
Toen ik mijn Slimmelezer een Shelly Pro 3 EM liet emuleren ( https://github.com/jaapp/slimmelezer-shelly-emulator ) werkte het nog allemaal als een zonnetje...

[antoinevromen]

AUijtdehaag schreef op zaterdag 11 oktober 2025 @ 18:39:
@antoinevromen
Bij mijn weten werkt dat niet lekker?
De Homewizard p1 wifi heeft niet de slimmigheid om 2 batterijen aan te sturen zoals de CT003 heeft.

Ik gebruik hem wel, maar dan in de nodered flow.

Hallo AUijtdehaag, ik stuur beide batterijen straks aan met mijn powershell-script (sturing via local-api). Daarbij zal er altijd maar 1 batterij op Auto staan en de ander Passive totdat nr1 leeg is en dan switched hij naar nr 2. Dus ik denk dat het ontbreken van de slimmigheid van de CT003 hiermee wel is getackled.
Ging mij er meer om of iemand dat al heeft draaien en of iemand zou weten of ik bij de installatie van de 2e batterij in de app de eerste beter even down kan brengen om geen interferentie te krijgen.

[bloek]

harrr schreef op dinsdag 14 oktober 2025 @ 19:20:
[...]


Zo lang de energiebelasting nog te salderen is, kun je net zo goed uit de grid de accu vol laden en juist meer terugleveren. Dat kan meer opleveren. Waarom van 12:00-16:00 opladen als je tussen 15:00 en 16:00 een betere prijs krijgt voor je stroom en goedkoper de accu kunt laden met extra grid capaciteit voor een lager tarief.

Tot de saldering van energiebelasting weg valt, laad ik de accu dus gewoon vol op de 2 goedkoopste uren van de eerste 12 uur van de dag en de 2 goedkoopste uren van de 12 uur erna. In de middag betekend dit vaak solar + grid laden. In de nacht volledig uit de grid. Na het volladen nog wat terugleveren van de extra zon opbrengst. Tussen het laden door draai ik NOM.

Dit inmiddels geautomatiseerd en het lijkt voor nu best een goede strategie. Wanneer de salderingsregeling vervalt wordt het idd interessant om rekening te houden met de mogelijke zo opbrengst. Ik denk dat ik dan niet ga sturen op de zon maar op de SOC rond het middaguur en daarmee bepaal of ik ga bijladen op het laagste middag tarief.

Hi Harr,
Ik denk hetzelfde over de laadstrategie die jij beschrijft. Hoe heb jij dit geautomatiseerd? Ik ben aan het testen met Homey Pro, de app voor Homey: Marstek Battery Connector en mijn 3x Venus e V2 met local API enabled. Ik gebruik flows om te laden in de nacht en middag (manual mode) en bij 95% van de batterij gaat de batterij naar NOM. Dit alles over wifi en geen modbus.

Loopt nog niet vlekkeloos, wifi verbindingen zijn stabiel maar ik verdenk de CT003 van disconnecten met de 2 batterijen die door de flows worden aangestuurd ( wellicht door local api enablement). De 3e batterij houdt een goede connectie (geen local api enabled) en draait in de AI modus, met andere uitdagingen…

Ik ben benieuwd hoe jij de automatiseringen hebt gedaan.

[harrr]

bloek schreef op dinsdag 14 oktober 2025 @ 21:23:
[...]

Hi Harr,
Ik denk hetzelfde over de laadstrategie die jij beschrijft. Hoe heb jij dit geautomatiseerd? Ik ben aan het testen met Homey Pro, de app voor Homey: Marstek Battery Connector en mijn 3x Venus e V2 met local API enabled. Ik gebruik flows om te laden in de nacht en middag (manual mode) en bij 95% van de batterij gaat de batterij naar NOM. Dit alles over wifi en geen modbus.

Loopt nog niet vlekkeloos, wifi verbindingen zijn stabiel maar ik verdenk de CT003 van disconnecten met de 2 batterijen die door de flows worden aangestuurd ( wellicht door local api enablement). De 3e batterij houdt een goede connectie (geen local api enabled) en draait in de AI modus, met andere uitdagingen…

Ik ben benieuwd hoe jij de automatiseringen hebt gedaan.

De API is ongelofelijk gevoelig. Een call te veel of te snel achter de vorige en de EMS loopt vast en verliest zijn CT, dat hebben meer mensen ervaren. Ik heb zelf een script geschreven dat de API aanstuurt, uiteindelijk heb ik heel veel uit mijn script gesloopt om het stabiel te krijgen. Zo vraag ik elk kwartier nog even de SoC (1 call) op en daarna zet ik de Marstek in Passive (laden, 2 calls) of Auto (zelf consumptie, 1 call).

Tussen de calls door houdt ik 45 seconden rust in de EMS de tijd te geven alles te verwerken. Sinds 2 dagen is alles stabiel hiervoor viel het met de API om de +/-6 uur uit.

[Avenger 2.0]

RF1000 schreef op dinsdag 21 oktober 2025 @ 17:26:
Even een noob vraag. Is het mogelijk om met een Homey pro 2 Marsteks aan te sturen zonder dat je aan de slag moet met Lilygo's etc? (Proberen in te verdiepen maar daar haak ik vrij snel af)

Het gaat dan via de marstek cloud (daar ben je dan wel afhankelijk van natuurlijk) of via en lokale api die je kan aanzetten?

Staat in Homey een App van iemand die met local API werkt. Bij gebruik local API kan de CT002/CT003 wel instabiel worden en connectie verliezen. Hier voorlopig terug uitgeschakeld tot Marstek nieuwe firmware heeft waar dit stabieler werkt.

[Druppeltje_]

Avenger 2.0 schreef op dinsdag 21 oktober 2025 @ 19:51:
[...]

Staat in Homey een App van iemand die met local API werkt. Bij gebruik local API kan de CT002/CT003 wel instabiel worden en connectie verliezen. Hier voorlopig terug uitgeschakeld tot Marstek nieuwe firmware heeft waar dit stabieler werkt.

Idem hier. Met local API ingeschakeld is het een en al treurnis en ellende. Heb de integratie van @Preaper geprobeerd maar even snel alweer weg gedaan. Voor de duidelijkheid: dat ligt aan Marstek niet aan de integratie op zich. Ik heb hier uitval van zodra de API aanstaat, zelfs zonder polling of integratie. Screenshot 1 is 3 minuten nadat de API aanstaat, integratie zelfs nog niet ingevoegd. Voor de volledigheid: ik behoor tot de groep die nooit problemen heeft gehad met verbindingsuitval tijdens het gewone gebruik (6maanden nu)
Screenshot 2 is vlak nadat ik API terug uitzet.

[ Voor 4% gewijzigd door Druppeltje_ op 21-10-2025 20:32 ]

[RF1000]

Avenger 2.0 schreef op dinsdag 21 oktober 2025 @ 19:51:
[...]

Staat in Homey een App van iemand die met local API werkt. Bij gebruik local API kan de CT002/CT003 wel instabiel worden en connectie verliezen. Hier voorlopig terug uitgeschakeld tot Marstek nieuwe firmware heeft waar dit stabieler werkt.

Oke. Ik kijk het nog even aan. Ook gezien de ervaring van @druppeltje. Nu maar hopen dat het de komende periode de goede kant op gaat.

[Richh]

Misschien dan ook leuk om uit te schrijven hoe ik de Marstek tegenwoordig aanstuur

Mijn Marstek is met Home Assistant verbonden door middel van de addons Hame Relay, hm2mqtt voor het uitlezen van de accu. Al weet ik dat ik die laatste twee wellicht ooit naar https://github.com/jaapp/ha-marstek-local-api kan ombouwen

De Marstek is niet verbonden met een CT003 of iets dergelijks.
Ik heb zelf een P1-naar-USB kabel gekocht en deze op mijn Raspberry Pi met Home Assistant aangesloten. Door middel van de B2500 Meter addon, emuleer ik een Shelly Pro 3EM, welke de Marstek dan weer kan uitlezen. Dat biedt best wat voordelen, want deze input wordt elke paar seconden verwerkt (ik gok 5?) en is een Marstek default, dus niet afhankelijk van alle instabiliteit rondom de API's.

Ik heb in Home Assistant een helper entity gemaakt, welke rekent met de P1 waardes die ik ontvang. In feite kan ik daardoor precies de Marstek laten ontladen op de snelheid die ik wil, zonder LilyGo, binnen enkele seconden.

Door middel van een sensor template kan je dan behoorlijk simpel logica maken "als de auto laadt, doe dan niks" -> gezien mijn auto met Tibber dynamisch laadt, is dat zeker nu we in de 'koude maanden' zijn beland, erg inefficient.

Een snippet voor het idee:

code:

{% set laadpaal_status = states('binary_sensor.auto_laadpaal_contactor_closed') %}

{% if laadpaal_status == "on" %}
  0
{% else %}
  {% set consumption = states('sensor.power_consumption') | float(0) %}
  {% set production = states('sensor.power_production') | float(0) %}
  {% set soc = states('sensor.hame_energy_hmg_50_xxxxxxxxxx_battery_state_of_charge') | int %}
  {% set total = (consumption - production) * 1000 %}

  {# Voor levensduur accu, boven 95% beperken laadsnelheid #}
  {% if soc > 95 %}
    {% min(total, -500) | int %}
  {% else %}
    {{{ total | int }}
  {% endif %}
{% endif %}

Binnenkort maar eens met de Northpool integratie aan de knutsel.
Een simpel algoritme dat gaat verkopen bij forse prijspieken en ook gaat opladen bij kleine prijsdips is natuurlijk wel leuk Maar, zeker tot 1 januari 2027, is het ook waardevol om bij een <30% prijsdifferentiatie, gewoon de accu idle te laten.

[antoinevromen]

Cryptoleek schreef op vrijdag 24 oktober 2025 @ 10:34:
[...]


Hij schrijft dat hij Homewizard (accus) gebruikt om 0 op de meter te komen.
Dus zijn Marstek kan dan niet op automatisch

Maar dan kan hij toch nog steeds via de HW-P1 en local-api zijn 3 Marsteks met local-api besturen (whatever that may be; ofwel wat hij dan aanvullend met die 3 accus wil doen als de homewizard-accus al voor de NOM zorgen. Volgens mij is mijn voorstel een prima oplossing voor een mij nog onbekend probleem. Wat is dan het eigenlijke probleem? (Ct003 met 3 accus?)

[antoinevromen]

wolv schreef op dinsdag 28 oktober 2025 @ 14:00:
Bedankt alvast voor al de raad en tips.
Nog wat extra vragen:
- Momenteel hebben we een 'variabel' electriciteitscontract; dus vanaf dat ik de batterij heb best overschakelen naar een dynamisch?
- Mag ik de batterij(en) in de kelder plaatsen? (onder de elec kast die op gelijkvloers in de hal staat). Ik kan een netwerkkabel van de modem naar de kelder trekken, op hetzelfde netwerk zetten als de HW P1 (modem staat in dezelfde kast in de hal)

Over financiele zaken zijn zoveel meningen als mensen hier op het forum, dus daar waag ik mij niet aan (zeker niet al Nederlander over een Belgische situatie), maar volgens mij kan de batterij rustig in de kelder als het daar maar niet vriest (dus onder 0 geraakt) of zo vochtig is dat hij in het water staat.
Ik lees nu dat je het hebt over batterij(en); Let wel met de HW-P1 kun je slechts 1 batterij besturen. Zodra je over gaat naar meerdere batterijen moet je (zoals ik zelf sturing via local-api gaan aanbrengen) of met een CT003 dongle gaan werken om te voorkomen dat de batterijen elkaar gaan laden/ontladen.
Dus bij 1 batterij HW-P1 prima. Bij 2 batterijen of meer zou je naar CT003 of eigen sturing moeten gaan.

[maxdisteli]

Preaper schreef op maandag 20 oktober 2025 @ 15:44:
Na een paar weken vrolijk proefkonijn spelen bij meerdere installaties is de Marstek Local API‑integratie voor Home Assistant zover: de kinderziektes zijn eruit en hij draait hier inmiddels heel betrouwbaar. Geen cloud meer nodig voor de Venus C/D/E’s; alles loopt lokaal via de officiële API, inclusief multi-battery support en een virtuele “Marstek System” device voor aggregate statistieken.

Wie hem wil proberen kan terecht op GitHub: https://github.com/jaapp/ha-marstek-local-api. Feedback blijft welkom, maar voorlopig draait hij hier stabiel genoeg voor “daily use”.

@pascallj misschien iets om op te nemen op de startpost?

Thanks voor deze Integration! Ik zie wel dat als ik de Local API aanzet op mijn beide Marsteks (V155), dat ze beide connectie verliezen met de CT003.. Is dat een bekend gevolg? Ik wilde ze uitlezen via Local API, maar nog wel de NoM etc door de Marsteks + CT zelf laten doen.

[pascallj]

maxdisteli schreef op woensdag 29 oktober 2025 @ 11:28:
[...]


Thanks voor deze Integration! Ik zie wel dat als ik de Local API aanzet op mijn beide Marsteks (V155), dat ze beide connectie verliezen met de CT003.. Is dat een bekend gevolg? Ik wilde ze uitlezen via Local API, maar nog wel de NoM etc door de Marsteks + CT zelf laten doen.

Zeker: Zoek naar "local api" ct003

[NoFate]

maxdisteli schreef op woensdag 29 oktober 2025 @ 11:28:
[...]


Thanks voor deze Integration! Ik zie wel dat als ik de Local API aanzet op mijn beide Marsteks (V155), dat ze beide connectie verliezen met de CT003.. Is dat een bekend gevolg? Ik wilde ze uitlezen via Local API, maar nog wel de NoM etc door de Marsteks + CT zelf laten doen.

Idd, is een issue , dus de local API NIET gebruiken