Marstek Venus / Duravolt PnP Thuisaccu Modbus koppeling

[stievo9997]

NoFate schreef op maandag 30 maart 2026 @ 21:53:
[...]

In de develop branch van de b2500 emulator kan je de ct003 emuleren, die werkt wel met meerdere batterijen en je kan zelfs bijsturen.... Heel veel extra opties... Maar de CT003 is een goed device , dat je verbinding wegvalt ligt wellicht niet aan de meter zelf. Ik zou je netwerk apparaat eens laten nakijken

Dat is wel een interessante optie om de ct003 te emuleren, ik heb nu namelijk 3 stuks marstek venus E, alleen mooi samenwerken qua laden / ontladen doen ze niet. Ik heb nu de Shelly Pro 3EM.

Ik heb nu deze branch: https://github.com/tomqui...rstek-managed-fake-device geïnstalleerd op HA. Alleen snap ik nog niet zo goed hoe ik dan deze CT003 kan laten gebruiken. Het deel "marstek_enable" ( Marstek cloud auto-registration) heb ik ingevoerd. En zou dus verwachten dat ik de geëmuleerde ct003 in de app zou terug moeten gaan zien? Wellicht iets foutief ingevoerd?

EDIT:
Opgelost: ik had de verkeerde branche gebruikt, dit is de juiste: https://github.com/tomquist/b2500-meter/tree/develop

[ Voor 4% gewijzigd door stievo9997 op 31-03-2026 14:07 ]

[jevin20]

djiedjee schreef op dinsdag 31 maart 2026 @ 11:34:
Ik mis, net zoals andere hier, een aantal waarden uit modbus, bijb. Daily Charging energy.

De accu draait op firmware 144 en zou versie 146 of hoger moeten hebben?
Via de app is er geen update mogelijk.

Is dat aan te vragen via mail of kan ik dat beter via "Ask Marstek" in de app aanvragen?

Ik krijg al een maand geen reactie op Ask Marstek, op geen van beide vragen...

[jevin20]

AUijtdehaag schreef op maandag 30 maart 2026 @ 18:23:
@jevin20
Ik wil niet flauw doen, maar dit topic is niet bedoeld voor HBC ondersteuning.
Daarvoor ga je hier naar toe: https://discord.com/invite/yeAGaE4kgy

Wat korte antwoorden:
Heb je nodered al eens "restart"?
Als je de yaml's NA de installatie van nodered geplaatst hebt, herkend nodered ze niet natuurlijk, na een restart vaak wel.
Powerbaas heeft een 4 poort splitter en ik heb nooit een CT003 gehad (dus ook niet nodig meer, tenzij je terug wilt naar marstek sturing)
Voor HW P1 wifi en 3-fase meter heb je maar 1 entity nodig in de template sensor en dat is de entity: sensor.p1_meter_power van HW

Toch bedankt voor de reacties. Ik ben uitgebreid vragen aan het stellen (sinds jouw bericht gisteren) op Discord, maar de (bruikbare.... sorry!) reacties zijn erg beperkt. Voor alsnog ben ik er niet veel opgeschoten helaas.
Er lijkt een hoop niet helemaal lekker te functioneren in HBC, of ik doe het verkeerd en kan het niet vinden, dat is uiteraard ook een optie.

[AUijtdehaag]

djiedjee schreef op dinsdag 31 maart 2026 @ 11:34:
Ik mis, net zoals andere hier, een aantal waarden uit modbus, bijb. Daily Charging energy.

De accu draait op firmware 144 en zou versie 146 of hoger moeten hebben?
Via de app is er geen update mogelijk.

Is dat aan te vragen via mail of kan ik dat beter via "Ask Marstek" in de app aanvragen?

Ja minimaal 146 inderdaad aanvragen via de feedback in de App

@jevin20
Ik heb geen glazen bol maar heb je alle entity-id's gecontroleerd? Staat daar marstek_m1 (of 2 of 3)in?

[igela3]

sygys schreef op maandag 30 maart 2026 @ 12:19:
Ik ben ook blij met alle info hoor maar het is als beginner echt heel goed zoeken.

Ik probeer nog uit te vinden welk apparaat precies de verdeling regelt van het vermogen die binnenkomt. Volgens mij doet de ct003 dat nu. Tenzij de accu's met elkaar communiceren om de verdeling te regelen. Ik heb zowel op fase 1 als fase 2 zonnepanelen die ook nog eens in wattage erg verschillen ik wil dus wel kunnen bepalen wat er max aan vermogen de 2 accu's in gaat. Gebaseerd op de vermogens die de zonnepanelen leveren. Nu probeert de accu (als hij werkt) de meter op nul te houden. Dus kijkt naar het verschil en levert of laadt naargelang het verschil. Met 2 accu's wordt het ingewikkelder omdat dan de accu's moeten laden en rekening moeten houden met elkaar. Ik vraag me af of de b2500 addon dat kan. Ik kan het in de documentatie niet goed terug vinden. Ook geeft marstek zelf aan dat geen. Enkele 3rd party meter dit kan behalve hun eigen ct002 en ct003 dus volgens mij zit het slimme deel in de meter en niet in de accu

Om een eerdere vraag van je te beantwoorden: Modbus hoef je bij een V3 niet aan te zetten. Je prikt die batterij gewoon met een ethernetkabel aan je router (via de ethernet poort, niet de RS485 poort), Idealiter maak je even een static IP in je router voor die batterij, dan is de kans dat er iets aan de IP adressen verandert en het niet meer werkt, geëlimineerd. Je router ziet Host name CH395, dat is je batterij.

Ik werk nu met deze integratie: https://github.com/ffunes/Marstek-Venus-Energy-Manager
Deze gast heeft er serieus werk van gemaakt: je hoeft niet moeilijk te doen met aanpassen van namen van entities, alles gaat vanzelf. Ik heb 2 stuks V3 die ik hiermee aanstuur.
Predictive charging kijkend naar solar forecast en dynamische kwartierprijzen van NordPool is geïntegreerd. Accu laadt op op goedkoop moment als de solar tekort gaat schieten, kijkt ook naar je verwachte verbruik voor de komende nacht (leert dit naar aanleiding van je eerder verbruiksgegeven). Minimaal en maximaal laadvermogen kun je instellen, minimale en maximale SOC ook. Enfin, kijk zelf maar wat je ervan vindt, bij mij draait dit nu prima en stabiel NOM met een CT003 van Marstek, maar je kunt ook een eenvoudige DSMR integratie gebruiken om je acutele verbruik te zien, als je een snelle (DSMR5.0) slimme meter hebt. Dit in tegenstelling tot de prut app van Marstek zelf.

[krijn1985]

krijn1985 schreef op zondag 22 maart 2026 @ 11:04:
Ik kon het niet vinden in dit topic maar kan zijn dat ik verkeerd gezocht heb. Is het mogelijk een Venus e V3.0 in gebruik te nemen met modbus zonder hem te "installeren" via de app? Of ga ik de app sowieso af en toe nodig hebben? Wil hem eigenlijk hooguit aan het geen internet iot wifi netwerk hangen maar vooral met modbus aansturen.

AUijtdehaag schreef op zondag 22 maart 2026 @ 12:00:
@krijn1985
Dat ligt er een beetje aan, met welke firmware de MT komt.
EMS 144 zou je willen updaten naar EMS 146 omdat je anders enkele modbus parameters mist.

Misschien een hotspot maken via je telefoon, die je dan naderhand niet meer gebruikt

Om even een update te geven, mijzelf en @AUijtdehaag gequote. Ik heb afgelopen week de batterij opgehaald en geinstalleerd. Hier stond uiteindelijk dus een te oude firmware op om gelijk met modbus te kunnen praten. Heb jammer genoeg nu nog steeds 144, heb dus om een update gevraagd. Maar op basis van mijn "ervaring" kan ik het volgende melden:
Batterij hoeft niet aan wifi om te updaten en niet aan het internet (hij hing aan een vlan zonder internet). Ik heb de batterij van lan verbinding voorzien maar kon met modbus dus niet verbinden. Toen de app geinstalleerd batterij toegevoegd en dan kan hij via bluetooth apparaat updaten. Duurt wel even dus sta je dan in je schuur.

Als ik thuis ben kan ik met de app prima verbinden met de batterij echter moet hij wel mijn locatie iedere keer weten, wat voor mij nogal onnodig voelt. Maarja zodra ik update naar 146 of 147 heb zodat in ieder geval een aantal relevante mod parameters ook tot mijn beschikking heb zal ik de app (voorlopig) niet echt meer nodig hebben.

Toch jammer dat je de app nodig hebt om de updates uit te voeren.

[savale]

4x Venus v3 firmware v147:
Ik gebruik de b2500 ct003 emulator van tomquist. Werkt fantastisch, maar als ik na onderhoud even down ben geweest dan komen de accu's soms in de "diagnosis failed" state. Ik moet dan in de app op "auto diagnoses" drukken om de accu's weer aan de gang te krijgen. Is er misschien een truukje (over modbus) om ze weer aan de gang te krijgen?

[dannyro]

savale schreef op donderdag 2 april 2026 @ 10:24:
4x Venus v3 firmware v147:
Ik gebruik de b2500 ct003 emulator van tomquist. Werkt fantastisch, maar als ik na onderhoud even down ben geweest dan komen de accu's soms in de "diagnosis failed" state. Ik moet dan in de app op "auto diagnoses" drukken om de accu's weer aan de gang te krijgen. Is er misschien een truukje (over modbus) om ze weer aan de gang te krijgen?

Wat bedoel je met "na onderhoud"?

[savale]

dannyro schreef op donderdag 2 april 2026 @ 11:50:
[...]

Wat bedoel je met "na onderhoud"?

Het draait in een LXC. Als ik die moet updaten / herstarten of als ik te lang bezig ben met configureren valt de CT003 emulator ook een paar minuten weg. Op de een of andere manier gaat ie dan in diagnose error.
Ik heb nu in mijn script staan dat hij eerst alle accu's naar manual zet bij een shutdown. Hopelijk gaat dat beter.

De b2500 emulator kan ik trouwens iedereen aanraden. Je kunt zelf de smoothing / balanceren tussen de accu's tweaken. Inmiddels is er in de develop branch ook een feature waarmee je kleine charge / discharge loads door 1 accu kunt laten doen in plaats van kleine loads verspreiden over alle accu's. Erg tof!

[ Voor 24% gewijzigd door savale op 02-04-2026 12:19 ]

[Fr3ggel]

@savale
Je kunt met de TomQuist b2500 emulator toch geen CT003 emuleren?
Volgen de readme op zijn zijn github zie ik enkel de volgende apparaten die geemuleerd kunnen worden.:

CT001
Shelly Pro 3EM
Shelly EM gen3
Shelly Pro EM50

met als voetnoot:
If your B2500 or Marstek storage system supports it, always prefer a Shelly device type over CT001 for better compatibility and reliability.

[dannyro]

Fr3ggel schreef op donderdag 2 april 2026 @ 12:44:
@savale
Je kunt met de TomQuist b2500 emulator toch geen CT003 emuleren?
Volgen de readme op zijn zijn github zie ik enkel de volgende apparaten die geemuleerd kunnen worden.:

CT001
Shelly Pro 3EM
Shelly EM gen3
Shelly Pro EM50

met als voetnoot:
If your B2500 or Marstek storage system supports it, always prefer a Shelly device type over CT001 for better compatibility and reliability.

https://github.com/tomqui...e#pre-release-builds-next

[Fr3ggel]

@dannyro

Oeps, sorry. Ik had alleen in de main branch gekeken.

En nog even een andere vraag.
Ik ben voornemen om een Shelly Pro 3EM aan te schaffen. Niet (alleen) voor de Marstek Batterijen, maar ook voor andere automations

Ik ben voornemens om in de aansturing van mijn Marstek batterijen in de toekomst door HA te laten aansturen.
Echter wil ik wel iets achter de hand hebben voor als mijn HA hapert.

Ik lees wel eens dat de HomeWizard P1 meter niet goed werkt i.c.m. meerdere Marstek batterijen. Weet iemand hoe dit zit met de Shelly Pro 3EM? Is die wel goed compatible met meerdere Marstek Venus batterijen (2x Venus E 3.0 en 1x Venus A) zonder tussenkomst van HA?

[SatScan]

Fr3ggel schreef op donderdag 2 april 2026 @ 12:56:
@dannyro

Oeps, sorry. Ik had alleen in de main branch gekeken.

En nog even een andere vraag.
Ik ben voornemen om een Shelly Pro 3EM aan te schaffen. Niet (alleen) voor de Marstek Batterijen, maar ook voor andere automations

Ik ben voornemens om in de aansturing van mijn Marstek batterijen in de toekomst door HA te laten aansturen.
Echter wil ik wel iets achter de hand hebben voor als mijn HA hapert.

Ik lees wel eens dat de HomeWizard P1 meter niet goed werkt i.c.m. meerdere Marstek batterijen. Weet iemand hoe dit zit met de Shelly Pro 3EM? Is die wel goed compatible met meerdere Marstek Venus batterijen (2x Venus E 3.0 en 1x Venus A) zonder tussenkomst van HA?

Niet om slim te laten samenwerken dan heb je toch echt een CT002 of CT003 nodig. Ik zou voor de CT003 kiezen als backup.

Succes!

[savale]

Iemand toevallig al een zinvollere SOC percentage berekening bedacht? Ik zit er aan te denken dat in de esphome kant te implementeren. De huidige SOC zit er soms 25% naast... Met name aan de bovenkant slaat het nergens op. Hij schiet gerust van 75% naar 100% omdat de berekening van marstek er naast zit.
Ik zit er zelf aan te denken om Coulomb Counting te gebruiken, aangezien we continu de DC power kunnen meten...

Update: nu een fraaie versie gemaakt die zelf lerend is, ingebakken in de esphome versie van fonske, maar ga die even uitgebreid testen voordat ik deze deel. Hopelijk een wat realistischere SOC.

[ Voor 142% gewijzigd door savale op 04-04-2026 23:59 ]

[jevin20]

Ik zat me gister te bedenken dat je de ‘backup’ = stopcontact functie handmatig aan moet zetten, en wanneer in huis alle stroom uitvalt het wel handig is als die aan staat. Alhoewel je waarschijnlijk via Bluetooth nog wel deze aan kan zetten.
Desalniettemin vroeg ik me af of iemand weet of het permanent aanhebben van het stopcontact stroom verbruikt?
Het gekke is, als de batterijen in stand-by staan, zie ik via de Homewizard power plugs alsnog zo’n 7W idle verbruik van het net, naast dat de SOC langzaam terugloopt (kan ook met cellen die balanceren te maken hebben wellicht).
Nu heb ik net het stopcontact aangezet bij 1 van onze batterijen en prompt gaat het net verbruik naar 0W.
Zit er nog meer hierachter verborgen? Iemand enig idee?

[SatScan]

savale schreef op zaterdag 4 april 2026 @ 18:44:
Iemand toevallig al een zinvollere SOC percentage berekening bedacht? Ik zit er aan te denken dat in de esphome kant te implementeren. De huidige SOC zit er soms 25% naast... Met name aan de bovenkant slaat het nergens op. Hij schiet gerust van 75% naar 100% omdat de berekening van marstek er naast zit.
Ik zit er zelf aan te denken om Coulomb Counting te gebruiken, aangezien we continu de DC power kunnen meten...

Update: nu een fraaie versie gemaakt die zelf lerend is, ingebakken in de esphome versie van fonske, maar ga die even uitgebreid testen voordat ik deze deel. Hopelijk een wat realistischere SOC.

Toeval bestaat niet ;-)

Wat ik nu sinds enkele dagen draaiend heb is best uitgebreid. Ik monitor het per batterij apart, dus voor de MT1 en de MT2 los van elkaar. Daarbij kijk ik naar het totale rendement over de hele periode, maar ook naar hoe ze het per dag doen. Wat het extra nauwkeurig maakt, is dat ik metingen doe op vaste SOC-punten zoals 10, 33, 50, 67 en 90 procent. Dat is veel beter dan alleen maar een simpel rekensommetje van totaal in en totaal uit, want ik pak nu de gemiddelden van meerdere meetpunten tijdens specifieke laad- en ontlaadmomenten. Dat geeft een veel realistischer beeld van wat er echt gebeurt.

In Home Assistant heb ik daar wat automatiseringen voor gebouwd die de RTE automatisch berekenen bij die specifieke SOC-waardes. Ik heb ook gezorgd dat de boel niet vastloopt als er een keer een teller reset in ESPHome of na een reboot, dus de cijfers blijven betrouwbaar. Voor het totale systeem heb ik een 'MTALL' waarde gemaakt. Dat is geen simpel gemiddelde van de twee, maar een gewogen berekening gebaseerd op de werkelijke energie. Op mijn dashboard zie ik nu in één oogopslag of het goed zit met kleurcodes: groen voor boven de 75 procent, oranje tussen de 60 en 75 en rood als het daaronder zakt. Ook heb ik een grafiekje dat de afgelopen zeven dagen laat zien.

De eerste cijfers zijn best interessant. Mijn MT1 zit rond de 72 tot 73 procent, terwijl de MT2 met 76 tot 77 procent duidelijk efficiënter is. Samen komt dat uit op ongeveer 74 procent. Dat verschil tussen die twee batterijen had ik zonder deze metingen nooit zo scherp gezien. Het belangrijkste inzicht tot nu toe is dat je eigenlijk twee soorten cijfers nodig hebt: een realtime getal per dag voor de snelle check en die SOC-metingen voor de echte nauwkeurigheid per cyclus. Samen geeft dat een compleet beeld. De volgende stap is om dit te gaan gebruiken voor het slim sturen van laden en ontladen op basis van de stroomprijs in combinatie met dat rendement. Het geeft in ieder geval een hoop inzicht dat je standaard in geen enkele app te zien krijgt.

[SatScan]

jevin20 schreef op zaterdag 4 april 2026 @ 22:40:
Ik zat me gister te bedenken dat je de ‘backup’ = stopcontact functie handmatig aan moet zetten, en wanneer in huis alle stroom uitvalt het wel handig is als die aan staat. Alhoewel je waarschijnlijk via Bluetooth nog wel deze aan kan zetten.
Desalniettemin vroeg ik me af of iemand weet of het permanent aanhebben van het stopcontact stroom verbruikt?
Het gekke is, als de batterijen in stand-by staan, zie ik via de Homewizard power plugs alsnog zo’n 7W idle verbruik van het net, naast dat de SOC langzaam terugloopt (kan ook met cellen die balanceren te maken hebben wellicht).
Nu heb ik net het stopcontact aangezet bij 1 van onze batterijen en prompt gaat het net verbruik naar 0W.
Zit er nog meer hierachter verborgen? Iemand enig idee?

Intern verbruik van de BMS etc.

[jevin20]

SatScan schreef op zondag 5 april 2026 @ 10:05:
[...]

Intern verbruik van de BMS etc.

Ja ik snap dat de batterij stroom verbruikt, dat is logisch, maar hoezo stopt hij daarmee als ik het backup stopcontact aan zet


Zie hier, hij is van 7W verbruik naar 0 gegaan, totdat hij begon met stroom leveren voor NOM.

[ Voor 43% gewijzigd door jevin20 op 05-04-2026 12:01 ]

[SatScan]

jevin20 schreef op zondag 5 april 2026 @ 11:58:
[...]

Ja ik snap dat de batterij stroom verbruikt, dat is logisch, maar hoezo stopt hij daarmee als ik het backup stopcontact aan zet
[Afbeelding]

Zie hier, hij is van 7W verbruik naar 0 gegaan, totdat hij begon met stroom leveren voor NOM.

Goede vraag, dat weet ik niet. Dit gedrag hebben we al vanaf het begin gezien... zoek eens in het topic misschien dat je een sluitend antwoord vindt?

[savale]

WIP, maar hier al volledig over van node red naar de b2500 emulator van tomquist aangezien deze inmiddels ook een hoop features heeft: smoothing en min_efficiency (zodat accu's pas bij schakelen voor beter efficiency)
https://github.com/tomquist/b2500-meter

Werkt hier met 4x een venus v3 (firmware v147).
Ik heb zelf de esphome firmware van Fonske / Superdude uitgebreid met wat nieuwe features:
https://github.com/kiss81/marstek_esphome

Work in Progress: based on the work of Fonske and Superduper1969:

added:

1. Calculated SOC. Based on cell voltage and Coulomb counting
2. charge and discharge cell voltage limits. By default: charge shutoff @ 3.50v and discharge shutoff @ 3.20v for better lifetime
3. charge slower for 3.40v to 3.50v: 500watt for better lifetime

edit: 6 april: did some updates for better SOC calculation + reduced default lilygo brightness 10%

[ Voor 8% gewijzigd door savale op 06-04-2026 21:39 ]

[RogerSch]

Vandaag de 3 Marstek Venus E 3.0 aangesloten via de LAN poort om de ModBus integratie mogelijk te maken. De overstap is goed gelukt. Voor de Home Assistant integratie maak ik gebruik van Marstek Venus Energy Manager die via HACS in Home Assistant wordt aangeboden (lekker easy). <LINK>.

In de app staat wel nog bij elke Marstek Accu een connectie met CT003. Ik vermoed dat dit een probleem opleverd icm aansturing vanuit Home Assistant. Wat kan ik het beste doen.

[LJU]

RogerSch schreef op zondag 5 april 2026 @ 22:01:
Vandaag de 3 Marstek Venus E 3.0 aangesloten via de LAN poort om de ModBus integratie mogelijk te maken. De overstap is goed gelukt. Voor de Home Assistant integratie maak ik gebruik van Marstek Venus Energy Manager die via HACS in Home Assistant wordt aangeboden (lekker easy). <LINK>.

In de app staat wel nog bij elke Marstek Accu een connectie met CT003. Ik vermoed dat dit een probleem opleverd icm aansturing vanuit Home Assistant. Wat kan ik het beste doen.

Maak zelf gebruik van Home Battery Control. Zodra de rs485 switch naar enabled gaat (of full control) dan zie ik in de app dat er geen modus is geselecteerd en de batterij dus ook niet meer stuurt op de waardes uit de ct003
Ik verwacht een soortgelijk iets bij deze integratie.

[RogerSch]

LJU schreef op maandag 6 april 2026 @ 01:03:
[...]

Maak zelf gebruik van Home Battery Control. Zodra de rs485 switch naar enabled gaat (of full control) dan zie ik in de app dat er geen modus is geselecteerd en de batterij dus ook niet meer stuurt op de waardes uit de ct003
Ik verwacht een soortgelijk iets bij deze integratie.

Dank voor de tip. Inderdaad in de Marstek app staat nu bij elke accu geen modus meer geselecteerd.

Dank. De CT003 kan ik nu dus verwijderen want in de Marstek Venus Energy Manager add-on heb ik de Home Wizard P1 meter geselecteerd.

[Alan969]

RogerSch schreef op maandag 6 april 2026 @ 01:30:
[...]

Dank voor de tip. Inderdaad in de Marstek app staat nu bij elke accu geen modus meer geselecteerd.

Dank. De CT003 kan ik nu dus verwijderen want in de Marstek Venus Energy Manager add-on heb ik de Home Wizard P1 meter geselecteerd.

Ja, maar als je ooit nog eens wenst te sturen via de app (vb. omdat je een probleem hebt met HA of Modbus), dan heb je de CT003 wel nog nodig. Je kan hem laten staan als backup.

[Witlof]

Ik gebruik de modbus-koppeling op mijn Marstek E V2 nog niet echt effectief om te sturen, maar vooral om te monitoren. Ik gebruik het samen met een HomeWizard P1 meter.
Nu ben ik aan het kijken naar wat mogelijkheden om effectief te gaan sturen. Ondertussen heb ik de Home Battery Control (v4.6.2) met de Node-Red configuratie draaien en dat lijkt allemaal goed te gaan. Zelfs de solar forecast functioneert volgens de dashboards.

Het enige wat nog niet goed gaat is het ophalen van de dynamische prijzen. Ik verwacht dat ik ergens een stap mis, maar weet niet goed wat.
Ik maak gebruik van de EnergyZero (core) integratie die ook geïnstalleerd staat en werkt. Ik zie de sensoren gevuld worden met informatie.
In HACS heb ik ook de Cheapest Energy Hours staan. Maar zoals ik gelezen heb, zie ik deze blueprint niet terug in de GUI, maar wel in custom_components.
Maar dan houdt het op voor mij. Moet ik nog ergens iets invullen/aanpassen/toevoegen om dit met elkaar te laten werken? Ik heb al van alles bekeken en gezocht, maar ik kom er niet meer aan uit. Ik verwacht nog ergens iets in YAML te moeten doen, maar geen idee wat. Iemand die mij een klein duwtje in de goede richting kan geven om de prijzen in HBC te krijgen?

[savale]

Heeft een lilygo toch net weer wat meerwaarde over de Modbus over LAN.

Enjoy de update:
https://github.com/kiss81/marstek_esphome

Work in Progress: based on the work of Fonske and Superduper1969:

added:

1. Calculated SOC. Initially based on cell voltage, then on Coulomb counting.
2. Self learning (netto) battery capacity for better SOC estimation + logging.
3. Charge and discharge cell voltage limits. By default: charge shutoff @ 3.50v and discharge shutoff @ 3.20v for better cell longevity.
4. Charge slower for 3.40v to 3.50v: 500watt for better cell longevity.
5. Default 10 days interval to bypass the voltage limits to allow recalibration of the Cells / Marstek SOC. (Direct overide available)

[ Voor 5% gewijzigd door savale op 07-04-2026 22:08 ]

[GoBieN-Be]

jevin20 schreef op zondag 5 april 2026 @ 11:58:
[...]

Ja ik snap dat de batterij stroom verbruikt, dat is logisch, maar hoezo stopt hij daarmee als ik het backup stopcontact aan zet
Zie hier, hij is van 7W verbruik naar 0 gegaan, totdat hij begon met stroom leveren voor NOM.

Met de back-up mode aan gebruikt hij de batterij voor zijn interne voeding i.p.v. het net.

[florism]

Hoi, mijn Marstek is nu ongeveer 1 jaar in gebruik en ik maak me wat zorgen over de celdrift.

Heb inmiddels een aantal cycli van 12 - 100% gedaan en op sommige dagen blijft de Marstek koppig op 99% hangen, vandaag bijvoorbeeld van 12 uur tot 17 uur 🤷🏻

Denken jullie dat er iets niet klopt? Ik lees uit via Modbus maar heb ook al Bluetooth geprobeerd, dat gaf bij 100%:
3.371V, 3.374V, 3.344V, 3.482V, 3.364V, 3.352V, 3.347V, 3.353V, 3.356V, 3.361V, 3.376V, 3.348V, 3.352V, 3.352V, 3.362V, 3.345V

Goed ziet er anders uit, denk ik.

Softwareversie V103
Firmwareversie V154
BMS-versie V216

Is er een nieuwere firmware die ik zou moeten proberen?

[savale]

@florism Tja balancing lijkt er niet of nauwelijks te zijn. Op mijn v3 van 2 maanden oud zie ik ook dit soort waardes op het moment dat je de accu oplaad.. Je zult wel zien dat als de accu leger is / de voltages even zijn gesettled dat de delta tussen de cellen weer kleiner is. Iets actievere balancing zou beter zijn imo, maar geen idee of de techniek aanwezig is in de accu's om dat te doen.

[florism]

@savale klopt, nu met 77% SOC ziet dit er beter uit maar ik had begrepen dat vooral aan de onder en bovenkant zichtbaar is hoe goed alles gebalanceerd is. Support ook geïnformeerd inclusief grafiek, ben benieuwd. Mijn gevoel zegt dat dit met de vorige firmware beduidend beter was maar daar heb ik niet echt goede data van 🥴

77% SOC

[savale]

florism schreef op woensdag 8 april 2026 @ 21:06:
@savale klopt, nu met 77% SOC ziet dit er beter uit maar ik had begrepen dat vooral aan de onder en bovenkant zichtbaar is hoe goed alles gebalanceerd is. Support ook geïnformeerd inclusief grafiek, ben benieuwd. Mijn gevoel zegt dat dit met de vorige firmware beduidend beter was maar daar heb ik niet echt goede data van 🥴

77% SOC
[Afbeelding]

Ben benieuwd wat support er van zegt!

[gmj2]

Even een vraagje over modbus en het aantal writes. Volgens mij was dat eens langs gekomen maar kan dat niet zo snel terug vinden. Ik schrijf elke dag 2x een waarde naar register 44003 (max discharge power), dus 730x per jaar. Om 10:00 uur "0" en om 17:00 weer de oude waarde zodat er geladen wordt bij PV overshot maar geen discharge overdag op goedkope uren. Is dit nou iets wat je niet moet doen ivm nvram slijtage, of zou het niet uimaken ten opzichte van de levensduur van de batterij? Wat denken jullie?

[Broodro0ster]

Wat zijn de polling rates op jullie Marsteks? Mijn V2 staat op 3 seconden en mijn V3 op 0.5 seconden. De V3 reageert een stuk sneller dan mijn V2, dus ik zou beiden graag op de dezelfde polling rate hebben.

Helaas lukt het mij niet om met deze tool de polling rate aan te passen op mijn V2: https://rweijnen.github.io/marstek-venus-monitor/

Is het bij iemand wel al gelukt?

[NoFate]

Broodro0ster schreef op donderdag 9 april 2026 @ 10:41:
Wat zijn de polling rates op jullie Marsteks? Mijn V2 staat op 3 seconden en mijn V3 op 0.5 seconden. De V3 reageert een stuk sneller dan mijn V2, dus ik zou beiden graag op de dezelfde polling rate hebben.

Helaas lukt het mij niet om met deze tool de polling rate aan te passen op mijn V2: https://rweijnen.github.io/marstek-venus-monitor/

Is het bij iemand wel al gelukt?

Polling rate BT commando is nog niet achterhaald. Ook niet via MQTT, dus helaas nog niet aanpasbaar, alleen marstek kan dit doen...
Ook idd via de BT tool werkt het niet , misschien heeft @bommel wel een update voor ons

[Broodro0ster]

NoFate schreef op donderdag 9 april 2026 @ 17:26:
[...]

Polling rate BT commando is nog niet achterhaald. Ook niet via MQTT, dus helaas nog niet aanpasbaar, alleen marstek kan dit doen...
Ook idd via de BT tool werkt het niet , misschien heeft @bommel wel een update voor ons

Jammer, ik ben wel benieuwd naar de snelste polling rate op de V2.
Ik zag dat jij ook Tom zijn Astrameter aan het testen bent. Doordat mijn V3 een 0.5s polling rate heeft, gaat die erg snel oscileren. Wellicht omdat die bij een volgende poll na 0.5s nog geen update krijgt van de meter en nog eens het vermogen verhoogd met bv 5W, waardoor je 5W overshoot hebt.

Door EMA op 0.3 te zetten, is hij veel rustiger, maar ik vrees dat ik dan mijn V3 onnodig traag maar. Ik zie dat de V3 veel sneller reageert op wisselende vermogens.

Idealiter zouden beiden batterijen een 1 seconde polling rate moeten hebben zodat ze in sync lopen met de digitale meter. Jammer dat die parameter nog niet zelf te zetten. En geen idee als 1 seconde mogelijk is en als Marstek op zo'n requests gaat reageren gezien ik met custom software bezig ben.

Als ik de V3 eventjes aan de HW P1 hang, dan oscilleert die wel niet, dus mogelijks gebruikt Marstek al intern iets van filters afhankelijk van het type meter dat er verbonden is.

[NoFate]

Broodro0ster schreef op vrijdag 10 april 2026 @ 10:36:
[...]

Jammer, ik ben wel benieuwd naar de snelste polling rate op de V2.
Ik zag dat jij ook Tom zijn Astrameter aan het testen bent. Doordat mijn V3 een 0.5s polling rate heeft, gaat die erg snel oscileren. Wellicht omdat die bij een volgende poll na 0.5s nog geen update krijgt van de meter en nog eens het vermogen verhoogd met bv 5W, waardoor je 5W overshoot hebt.

Door EMA op 0.3 te zetten, is hij veel rustiger, maar ik vrees dat ik dan mijn V3 onnodig traag maar. Ik zie dat de V3 veel sneller reageert op wisselende vermogens.

Idealiter zouden beiden batterijen een 1 seconde polling rate moeten hebben zodat ze in sync lopen met de digitale meter. Jammer dat die parameter nog niet zelf te zetten. En geen idee als 1 seconde mogelijk is en als Marstek op zo'n requests gaat reageren gezien ik met custom software bezig ben.

Als ik de V3 eventjes aan de HW P1 hang, dan oscilleert die wel niet, dus mogelijks gebruikt Marstek al intern iets van filters afhankelijk van het type meter dat er verbonden is.

Ik heb Tom mijn TCP dumps gegeven om het project te kunnen starten, anders hadden we de emulator niet... :-) eerste testen hebben we samen gedaan, maar ben erna moeten afhaken wegens tijds gebrek sinds de rotatie settings erbij zijn gekomen...
Maar je kan marstek vragen om de polling op high te zetten, mijn staan op high, geen idee wat de polling dan effectief is... Kan je dat zien in de emulator? Dan wil het het wel eens even testen als ik even tijd heb tussendoor. Ik heb alleen V1 en V2

[Broodro0ster]

NoFate schreef op vrijdag 10 april 2026 @ 10:54:
[...]

Ik heb Tom mijn TCP dumps gegeven om het project te kunnen starten, anders hadden we de emulator niet... :-) eerste testen hebben we samen gedaan, maar ben erna moeten afhaken wegens tijds gebrek sinds de rotatie settings erbij zijn gekomen...
Maar je kan marstek vragen om de polling op high te zetten, mijn staan op high, geen idee wat de polling dan effectief is... Kan je dat zien in de emulator? Dan wil het het wel eens even testen als ik even tijd heb tussendoor. Ik heb alleen V1 en V2

Yes, kan je zien in Home Assistant. Even de MQTT insights in de emulator configureren (ook nieuw) en dan krijg in je Home Assistant een paar leuke inzichten. Je kunt daar trouwens ook een batterij uitschakelen of een rotatie forceren. Mocht je het niet aan de praat krijgen, stuur maar een PB.

Ik benieuwd naar de polling rate van jouw V2 op high.

[NoFate]

Broodro0ster schreef op vrijdag 10 april 2026 @ 11:02:
[...]

Yes, kan je zien in Home Assistant. Even de MQTT insights in de emulator configureren (ook nieuw) en dan krijg in je Home Assistant een paar leuke inzichten. Je kunt daar trouwens ook een batterij uitschakelen of een rotatie forceren. Mocht je het niet aan de praat krijgen, stuur maar een PB.

Ik benieuwd naar de polling rate van jouw V2 op high.

ok, eens doen als ik tijd heb

[NoFate]

Broodro0ster schreef op vrijdag 10 april 2026 @ 11:02:
[...]

Yes, kan je zien in Home Assistant. Even de MQTT insights in de emulator configureren (ook nieuw) en dan krijg in je Home Assistant een paar leuke inzichten. Je kunt daar trouwens ook een batterij uitschakelen of een rotatie forceren. Mocht je het niet aan de praat krijgen, stuur maar een PB.

Ik benieuwd naar de polling rate van jouw V2 op high.

welke settings heb jij in de config? dan neem ik dezelfde over ...
moet je die mqtt insights ook apart enablen?

[ Voor 4% gewijzigd door NoFate op 10-04-2026 11:34 ]

[Broodro0ster]

NoFate schreef op vrijdag 10 april 2026 @ 11:24:
[...]

welke settings heb jij in de config? dan neem ik dezelfde over ...
moet je die mqtt insights ook apart enablen?

Ik heb een PB gestuurd met mijn settings. Is inderdaad iets wat je apart moet enablen in de config.

[SatScan]

florism schreef op woensdag 8 april 2026 @ 20:49:
Hoi, mijn Marstek is nu ongeveer 1 jaar in gebruik en ik maak me wat zorgen over de celdrift.

Heb inmiddels een aantal cycli van 12 - 100% gedaan en op sommige dagen blijft de Marstek koppig op 99% hangen, vandaag bijvoorbeeld van 12 uur tot 17 uur 🤷🏻

Denken jullie dat er iets niet klopt? Ik lees uit via Modbus maar heb ook al Bluetooth geprobeerd, dat gaf bij 100%:
3.371V, 3.374V, 3.344V, 3.482V, 3.364V, 3.352V, 3.347V, 3.353V, 3.356V, 3.361V, 3.376V, 3.348V, 3.352V, 3.352V, 3.362V, 3.345V

Goed ziet er anders uit, denk ik.

Softwareversie V103
Firmwareversie V154
BMS-versie V216

Is er een nieuwere firmware die ik zou moeten proberen?

[Afbeelding]

Laat eens de batterij op manueel laden staan voor 16u ofzo. Dus gewoon 100% laten staan manueel mode laden. Dan kalibreert de batterij. Misschien dat het dan beter wordt.

Naar mijn ervaring zit er en passieve celbalancing in.

[savale]

SatScan schreef op vrijdag 10 april 2026 @ 12:42:
[...]

Laat eens de batterij op manueel laden staan voor 16u ofzo. Dus gewoon 100% laten staan manueel mode laden. Dan kalibreert de batterij. Misschien dat het dan beter wordt.

Naar mijn ervaring zit er en passieve celbalancing in.

Hier trouwens o.a. bezig met een betere SOC implementatie:
https://github.com/kiss81/marstek_esphome

Is nog niet zo goed als ik zou willen, maar de komende tijd lekker aan t tweaken. Suggesties zijn natuurlijk ook welkom!

[gmj2]

savale schreef op donderdag 2 april 2026 @ 12:17:
[...]

De b2500 emulator kan ik trouwens iedereen aanraden. Je kunt zelf de smoothing / balanceren tussen de accu's tweaken. Inmiddels is er in de develop branch ook een feature waarmee je kleine charge / discharge loads door 1 accu kunt laten doen in plaats van kleine loads verspreiden over alle accu's. Erg tof!

Heb je voor mij de config die je gebruikt als voorbeeld? ik krijg namelijk de b2500/Astra-ct003 emulatie niet goed aan de praat met 2 MTs (v2 en een v3). Blijft oscilleren, de ene laadt de andere op en vice versa. Note: Ik heb nog een oude P1 meter met 10 sec. updates. Ook als ik de throttle op b.v. 11 seconde set blijft het instabiel. Wellicht dat ook de andere parameters aangepast moeten worden maar na wat testen blijft het bij mij niet lekker werken.

[savale]

gmj2 schreef op zaterdag 11 april 2026 @ 12:45:
[...]

Heb je voor mij de config die je gebruikt als voorbeeld? ik krijg namelijk de b2500/Astra-ct003 emulatie niet goed aan de praat met 2 MTs (v2 en een v3). Blijft oscilleren, de ene laadt de andere op en vice versa. Note: Ik heb nog een oude P1 meter met 10 sec. updates. Ook als ik de throttle op b.v. 11 seconde set blijft het instabiel. Wellicht dat ook de andere parameters aangepast moeten worden maar na wat testen blijft het bij mij niet lekker werken.

Ahh met 10 seconden is het heel lastig weet ik nog wel. Heb inmiddels 1 sec p1 updates (nieuwe meter). Dat maakt heel veel uit. Maar zet throttle eens op 1 en probeer dit eens:

code:

ACTIVE_CONTROL = True
SMOOTH_TARGET_ALPHA = 0.3
DEADBAND = 10
MAX_SMOOTH_STEP = 0
FAIR_DISTRIBUTION = True
BALANCE_GAIN = 0.2
BALANCE_DEADBAND = 10
MAX_CORRECTION_PER_STEP = 80
ERROR_BOOST_THRESHOLD = 150
ERROR_BOOST_MAX = 0.5
ERROR_REDUCE_THRESHOLD = 20
SATURATION_DETECTION = True
SATURATION_ALPHA = 0.15
MIN_TARGET_FOR_SATURATION = 20
MIN_EFFICIENT_POWER = 750

Tip: vraag bij stedin om een andere meter. (doen ze gratis als je aangeeft dat je thuisaccu dit nodig heeft)

[ Voor 4% gewijzigd door savale op 11-04-2026 18:50 ]

[jbbrans]

Hier een beginner met home assistant.

Ik wil mijn venus E V3 batterijen in de gaten houden en in de toekomst van modus laten wisselen d.m.v. home assistant.
In de gaten houden omdat de Marstek app op afstand niet alle batterijen altijd ziet en ik een meer geheel overzicht wil hebben dan per batterij switchen.
In de toekomst schakelen, omdat ik: 1. als het kan NOM wil gaan draaien. 2. volgend jaar met een dynamisch contract en bij geen/onvoldoende zon op de goedkope tijden wil laden en buiten die tijden NOM. En 3. volgend jaar tijdens vakanties en voldoende zon, het overschot 's ochtends wil verkopen.

Welke instellingen moet ik in de batterij instellen?
Welke addons/apps/integraties moet ik hebben hiervoor?

Zoals gezegd heb ik 3 venus e V3 batterijen elk op een eigen groep en fase (op dit moment draait 1 firmware v148 en de andere 2 v144), ook heb ik een CT003 p1 meter en een homewizard p1 meter. De CT003 en de splitter zijn gevoed via een usb voeding.
Home assistant draait op een Synology nas in een VM. Docker heb ik ook geprobeerd, maar VM ligt mij hierbij beter.

De gesprekken in dit topic en het algemene Marstek venus E topic worden mij soms te ingewikkeld.

Edit: vergeten te vermelden, de batterijen zijn via een bedraad lan aangesloten.

[ Voor 3% gewijzigd door jbbrans op 11-04-2026 17:35 ]

[RogerSch]

jbbrans schreef op zaterdag 11 april 2026 @ 15:16:
Hier een beginner met home assistant.

Ik wil mijn venus E V3 batterijen in de gaten houden en in de toekomst van modus laten wisselen d.m.v. home assistant.
In de gaten houden omdat de Marstek app op afstand niet alle batterijen altijd ziet en ik een meer geheel overzicht wil hebben dan per batterij switchen.
In de toekomst schakelen, omdat ik: 1. als het kan NOM wil gaan draaien. 2. volgend jaar met een dynamisch contract en bij geen/onvoldoende zon op de goedkope tijden wil laden en buiten die tijden NOM. En 3. volgend jaar tijdens vakanties en voldoende zon, het overschot 's ochtends wil verkopen.

Welke instellingen moet ik in de batterij instellen?
Welke addons/apps/integraties moet ik hebben hiervoor?

Zoals gezegd heb ik 3 venus e V3 batterijen elk op een eigen groep en fase (op dit moment draait 1 firmware v148 en de andere 2 v144), ook heb ik een CT003 p1 meter en een homewizard p1 meter. De CT003 en de splitter zijn gevoed via een usb voeding.
Home assistant draait op een Synology nas in een VM. Docker heb ik ook geprobeerd, maar VM ligt mij hierbij beter.

De gesprekken in dit topic en het algemene Marstek venus E topic worden mij soms te ingewikkeld.

In Home Assistant installeer eerst HACS. En selecteer daarna de volgende add-on: https://ffunes.github.io/Marstek-Venus-Energy-Manager/installation/

Let op: de Marstek moet via de lan poort op het netwerk zijn aangesloten

[sallander]

gmj2 schreef op donderdag 9 april 2026 @ 10:36:
Even een vraagje over modbus en het aantal writes. Volgens mij was dat eens langs gekomen maar kan dat niet zo snel terug vinden. Ik schrijf elke dag 2x een waarde naar register 44003 (max discharge power), dus 730x per jaar. Om 10:00 uur "0" en om 17:00 weer de oude waarde zodat er geladen wordt bij PV overshot maar geen discharge overdag op goedkope uren. Is dit nou iets wat je niet moet doen ivm nvram slijtage, of zou het niet uimaken ten opzichte van de levensduur van de batterij? Wat denken jullie?

Het lijkt me toch sterk dat je met nvram slijtage rekening moet houden. Een automation zoals Marstek Venus Energy Manager zal toch meerdere keren per minuut een modbus register update moeten uitvoeren. De Marstek AI en self-consumption modes zullen zich niet heel anders gedragen, vermoed it.

[savale]

gmj2 schreef op donderdag 9 april 2026 @ 10:36:
Even een vraagje over modbus en het aantal writes. Volgens mij was dat eens langs gekomen maar kan dat niet zo snel terug vinden. Ik schrijf elke dag 2x een waarde naar register 44003 (max discharge power), dus 730x per jaar. Om 10:00 uur "0" en om 17:00 weer de oude waarde zodat er geladen wordt bij PV overshot maar geen discharge overdag op goedkope uren. Is dit nou iets wat je niet moet doen ivm nvram slijtage, of zou het niet uimaken ten opzichte van de levensduur van de batterij? Wat denken jullie?

10k writes is echt wel het minimale dat goed moet gaan. Ik denk echter eerder dat 100k ook nog wel goed gaat. Met 2x per dag schrijven valt dat allemaal wel mee dus.

[appsec]

Toevallig dat deze vraag nu opkomt. Ik ben van plan een E V3 te kopen en ik ben nu aan het programmeren aan de aansturing. Ik weet nog niet precies hoe ik het aan wil pakken, maar een van de mogelijkheden is dat ik zelf NOM sturing + eigen logica wil doen i.p.v. het aan de batterij over te laten. Ik vraag me af hoe snel de batterij reageert op nieuwe setpoints die via modbus worden ingesteld. Zit daar verschil in t.o.v. hoe snel de batterij op veranderende P! metingen reageert?

[SatScan]

appsec schreef op zondag 12 april 2026 @ 22:04:
Toevallig dat deze vraag nu opkomt. Ik ben van plan een E V3 te kopen en ik ben nu aan het programmeren aan de aansturing. Ik weet nog niet precies hoe ik het aan wil pakken, maar een van de mogelijkheden is dat ik zelf NOM sturing + eigen logica wil doen i.p.v. het aan de batterij over te laten. Ik vraag me af hoe snel de batterij reageert op nieuwe setpoints die via modbus worden ingesteld. Zit daar verschil in t.o.v. hoe snel de batterij op veranderende P! metingen reageert?

Zoek eens op Home Batterij Control en lees de documentatie.
Met modbus is dit zeer snel, niet gemeten, maar ik vermoed onder een sec. De data uit je SM voor sturing komt niet sneller dan 1sec bij moderne meters, bij ouderen meters zelfs om de 5 of 10 sec.

Succes!

[sallander]

appsec schreef op zondag 12 april 2026 @ 22:04:
Toevallig dat deze vraag nu opkomt. Ik ben van plan een E V3 te kopen en ik ben nu aan het programmeren aan de aansturing. Ik weet nog niet precies hoe ik het aan wil pakken, maar een van de mogelijkheden is dat ik zelf NOM sturing + eigen logica wil doen i.p.v. het aan de batterij over te laten. Ik vraag me af hoe snel de batterij reageert op nieuwe setpoints die via modbus worden ingesteld. Zit daar verschil in t.o.v. hoe snel de batterij op veranderende P! metingen reageert?

Ik zit te kijken of het mogelijk is om de Self Consumption mode van de batterij te verbeteren m.b.v. de modbus verbinding, maar dan wel gebruik makend van de bestaande P1 integratie met batterij. Met verbeteren bedoel ik:

1. Self Consumption mode (de)activeren op geschikte tijden (die dagelijks kunnen veranderen)
2. Per tijdsblok alleen laden of alleen ontladen

Het eerste lijkt te kunnen door met modbus de User Work Mode te schakelen tussen Anti Feed en Manual.

Voor het tweede wil ik het volgende proberen:
- Alleen laden: Max Charge Power = 2500, Max Discharge Power = 0
- Alleen ontladen: Max Charge Power = 0, Max Discharge Power = 2500

Heeft iemand toevallig al ervaring met deze strategie? Dit jaar is deze strategie nog niet nodig, maar als dit werkt hoef ik niet verder te zoeken naar een oplossing voor als we niet meer kunnen salderen. Betere oplossingen zijn uiteraard ook welkom.

[Sarge_]

Vraagje, ik zie mijn temperatuur bij maximale belasting soms oplopen tot 57 graden. 3 flinke kacheltjes in de garage. Ik wil iets van AC Infinity fans erop plaatsen, aansluiten op backup stopcontact en dan via HomeAssistant een regel maken dat als de temp boven 45 graden komt het backup stopcontact aangaat en dan de fans voedt. Bij 40 graden weer uit, iets in die trant, maar zijn er bedenkingen, waardoor dit niet goed zou gaan? Ik krijg de data in HA via Modbus over Lan.

Per batterij dan 2 fans. https://www.amazon.nl/AC-...926&qid=1776068671&sr=8-2, Zal een druppel op de gloeiende plaat zijn denk ik. Zat ook al te denken aan de speedcocomfort, maar daarvan is de airflow heel minimaal.

[Tazzios]

sallander schreef op maandag 13 april 2026 @ 09:56:
[...]


Ik zit te kijken of het mogelijk is om de Self Consumption mode van de batterij te verbeteren m.b.v. de modbus verbinding, maar dan wel gebruik makend van de bestaande P1 integratie met batterij. Met verbeteren bedoel ik:

1. Self Consumption mode (de)activeren op geschikte tijden (die dagelijks kunnen veranderen)
2. Per tijdsblok alleen laden of alleen ontladen

Het eerste lijkt te kunnen door met modbus de User Work Mode te schakelen tussen Anti Feed en Manual.

Voor het tweede wil ik het volgende proberen:
- Alleen laden: Max Charge Power = 2500, Max Discharge Power = 0
- Alleen ontladen: Max Charge Power = 0, Max Discharge Power = 2500

Heeft iemand toevallig al ervaring met deze strategie? Dit jaar is deze strategie nog niet nodig, maar als dit werkt hoef ik niet verder te zoeken naar een oplossing voor als we niet meer kunnen salderen. Betere oplossingen zijn uiteraard ook welkom.

Wat voor ervaring zou je willen weten? Via modbus kun je laden en ontladen wat je zelf wilt, dat is niet heel
spannend.
Misschien wil je weten HOE je de modbus dan daadwerkelijk zo aanstuurt?
Ik gebruik zelf mijn eigen (wc-eend ) home assistant blueprint: https://github.com/Tazzios/ha-marstek/tree/main/blueprints
Hiermee heb ik meerdere automatiseringen aangemaakt met de volgende functies:
- Laden
- Ontladen
- NOM
- NOM alleen laden niet ontladen.

D.m.v. van een laatste automatisering schakel ik tussen deze.( voorbeeld ook op de git).

Indien je Home Assistant heb is dit een van de oplossingen maar er zijn er meer te vinden voor HA.

[sun62]

sallander schreef op maandag 13 april 2026 @ 09:56:
[...]


Ik zit te kijken of het mogelijk is om de Self Consumption mode van de batterij te verbeteren m.b.v. de modbus verbinding, maar dan wel gebruik makend van de bestaande P1 integratie met batterij. Met verbeteren bedoel ik:

1. Self Consumption mode (de)activeren op geschikte tijden (die dagelijks kunnen veranderen)
2. Per tijdsblok alleen laden of alleen ontladen

Het eerste lijkt te kunnen door met modbus de User Work Mode te schakelen tussen Anti Feed en Manual.

Voor het tweede wil ik het volgende proberen:
- Alleen laden: Max Charge Power = 2500, Max Discharge Power = 0
- Alleen ontladen: Max Charge Power = 0, Max Discharge Power = 2500

Heeft iemand toevallig al ervaring met deze strategie? Dit jaar is deze strategie nog niet nodig, maar als dit werkt hoef ik niet verder te zoeken naar een oplossing voor als we niet meer kunnen salderen. Betere oplossingen zijn uiteraard ook welkom.

Je zou mijn node-red script kunnen aanpassen zie link hieronder. Toevoegen van inject nodes zodat je tijd blokken kan instellen. En indien nodig enkele register nummers aanpassen die van venus A verschillen met venus E.

[Avenger 2.0]

Kan je die CT polling rate (via modbus of andere manier) zelf aanpassen (en verhogen). Al eens gevraagd aan support, maar na maand krijg ik antwoord terug dat ik al de laatste firmware heb Of als ik voor modbus sturing kies (ipv CT003), gaat die verandering dan sneller? Of is dat nog steeds die CT polling die snelheid van rate bepaald?

[sallander]

Tazzios schreef op maandag 13 april 2026 @ 10:33:
[...]
Ik gebruik zelf mijn eigen (wc-eend ) home assistant blueprint: https://github.com/Tazzios/ha-marstek/tree/main/blueprints
Hiermee heb ik meerdere automatiseringen aangemaakt met de volgende functies:
- Laden
- Ontladen
- NOM
- NOM alleen laden niet ontladen.

D.m.v. van een laatste automatisering schakel ik tussen deze.( voorbeeld ook op de git).

Ik heb naar je code gekeken, maar kon even niet vinden waar de automations "marstek_xom_laden" en "marstek_xom_ontladen" gedefinieerd zijn. Heb je nog een link misschien?

[sallander]

sun62 schreef op maandag 13 april 2026 @ 11:06:
[...]


Je zou mijn node-red script kunnen aanpassen zie link hieronder. Toevoegen van inject nodes zodat je tijd blokken kan instellen. En indien nodig enkele register nummers aanpassen die van venus A verschillen met venus E.

Dank, maar ik krijg altijd een beetje een ongemakelijk gevoel bij de hoeveelheid externe afhankelijkheden die je naar binnentrekt als je zoiets als node-red gaat gebruiken. Daarnaast vind ik het leuk om zelf de automations te ontwikkelen.

offtopic:
En dan bij voorkeur in een fatsoenlijke programmeertaal (C# ) met zo weinig mogelijk Python, yaml en Python-in-yaml.

[antonboonstra]

savale schreef op zondag 12 april 2026 @ 14:03:
[...]
10k writes is echt wel het minimale dat goed moet gaan. Ik denk echter eerder dat 100k ook nog wel goed gaat. Met 2x per dag schrijven valt dat allemaal wel mee dus.

Ik heb al ruim 160.000 sturingen gelogd, in werkelijkheid nog iets meer. Gaat nog steeds zonder problemen.

[Tazzios]

sallander schreef op maandag 13 april 2026 @ 11:37:
[...]


Ik heb naar je code gekeken, maar kon even niet vinden waar de automations "marstek_xom_laden" en "marstek_xom_ontladen" gedefinieerd zijn. Heb je nog een link misschien?

Die zijn gemaakt met de blueprint.
Voor de automation marstek_xom_laden heb ik een automations aangemaakt met de volgende blueprint instellingen:

• de batterij
• Grid entiteit
• target minimum 3000*
• target max 3000*

Voor ontladen variant: een minitje voor de targets.
Voor NOM laden:Maximum discharging 0 en/ of target minimum 0 en target max 3000*

Je kan natuurlijk denken wat omslachtig om vanaf het grid te redeneren maar het voordeel is dat je alle varianten kan maken met 1 blueprint en dat je je zekering niet kunt overbelasten.


* Kun je ook op 10.000 zetten als je zeker wilt weten dat hij max gaat laden, beetje afhankelijk van je huisverbruik/opwek, netaansluiting en de hoeveel accu`s.

edit:
Zoek anders even op hoe HA blueprints werken. Hier is de directe link om de blueprint toe te voegen aan je HA.

[ Voor 13% gewijzigd door Tazzios op 13-04-2026 13:55 ]

[sallander]

Tazzios schreef op maandag 13 april 2026 @ 12:18:
[...]
Die zijn gemaakt met de blueprint.

Nog steeds black magic voor mij, maar dat geeft niet. Dank voor je input!

[sallander]

Tazzios schreef op maandag 13 april 2026 @ 12:18:
[...]
edit:
Zoek anders even op hoe HA blueprints werken. Hier is de directe link om de blueprint toe te voegen aan je HA.

Ah, begrijp ik goed dat je de blueprint eerst in HA hebt geimporteerd, toen in HA de automations hebt gecreerd, en vervolgens de gegenereerde automations in GitHub hebt gecommit?

[Tazzios]

sallander schreef op maandag 13 april 2026 @ 14:11:
[...]
Ah, begrijp ik goed dat je de blueprint eerst in HA hebt geimporteerd, toen in HA de automations hebt gecreerd, en vervolgens de gegenereerde automations in GitHub hebt gecommit?

jeps, de automation "Marstek Controller" is ter voorbeeld hoe je de automations (xom_laden, nom etc) die op de blueprint zijn gebaseerd zou kunnen in en uitschakelen, er kan er tenslotte maar eentje tegelijk je accu aansturen.

[appsec]

sallander schreef op maandag 13 april 2026 @ 09:56:
[...]


Ik zit te kijken of het mogelijk is om de Self Consumption mode van de batterij te verbeteren m.b.v. de modbus verbinding, maar dan wel gebruik makend van de bestaande P1 integratie met batterij. Met verbeteren bedoel ik:

1. Self Consumption mode (de)activeren op geschikte tijden (die dagelijks kunnen veranderen)
2. Per tijdsblok alleen laden of alleen ontladen

Het eerste lijkt te kunnen door met modbus de User Work Mode te schakelen tussen Anti Feed en Manual.

Voor het tweede wil ik het volgende proberen:
- Alleen laden: Max Charge Power = 2500, Max Discharge Power = 0
- Alleen ontladen: Max Charge Power = 0, Max Discharge Power = 2500

Heeft iemand toevallig al ervaring met deze strategie? Dit jaar is deze strategie nog niet nodig, maar als dit werkt hoef ik niet verder te zoeken naar een oplossing voor als we niet meer kunnen salderen. Betere oplossingen zijn uiteraard ook welkom.

Ik had iets soortgelijks in gedachten, maar ik had nog een idee: ik heb gelezen dat de RTE erg slecht wordt bij lage vermogens dus ik denk dat het mogelijk optimaal is om een variant van NOM te maken die lage vermogens negeert en hogere vermogens door de batterij laat opvangen. De momenten waarop dit optimaal is wil ik bepalen met Mixed Integer Linear Programming. Voor deze NOM+ mode moet ik dan wel maximaal elke seconde een nieuw setpoint kunnen sturen.

[sallander]

appsec schreef op maandag 13 april 2026 @ 19:50:
[...]


Ik had iets soortgelijks in gedachten, maar ik had nog een idee: ik heb gelezen dat de RTE erg slecht wordt bij lage vermogens dus ik denk dat het mogelijk optimaal is om een variant van NOM te maken die lage vermogens negeert en hogere vermogens door de batterij laat opvangen. De momenten waarop dit optimaal is wil ik bepalen met Mixed Integer Linear Programming. Voor deze NOM+ mode moet ik dan wel maximaal elke seconde een nieuw setpoint kunnen sturen.

De RTE is zeker iets om in overweging te nemen. Ik vroeg me daarbij af hoe belangrijk de reactiesnelheid van het systeem eigenlijk is. Als je een dynamisch contract hebt waarbij je per 15 minuten wordt afgerekend heb je best lang de tijd om in dat tijdblok 0 op de meter te krijgen. Als je bijvoorbeeld elke minuut laadt/ontlaad wat er de vorige minuut geexporteerd/geimporteerd is kom je toch al een heel eind? Al doe je maar 1 update per minuut? Ik zit er zelf aan te denken om juist om deze reden een dynamisch contract te nemen waarbij je per uur wordt afgerekend, en dan maar 1 keer per 5 minuten een update te sturen. Of maak ik nu een denkfout?

[appsec]

sallander schreef op maandag 13 april 2026 @ 22:18:
[...]


De RTE is zeker iets om in overweging te nemen. Ik vroeg me daarbij af hoe belangrijk de reactiesnelheid van het systeem eigenlijk is. Als je een dynamisch contract hebt waarbij je per 15 minuten wordt afgerekend heb je best lang de tijd om in dat tijdblok 0 op de meter te krijgen. Als je bijvoorbeeld elke minuut laadt/ontlaad wat er de vorige minuut geexporteerd/geimporteerd is kom je toch al een heel eind? Al doe je maar 1 update per minuut? Ik zit er zelf aan te denken om juist om deze reden een dynamisch contract te nemen waarbij je per uur wordt afgerekend, en dan maar 1 keer per 5 minuten een update te sturen. Of maak ik nu een denkfout?

Bij Frank energie wordt je ook afgerekend op je afname en teruglevering binnen een uur. Ja kan dus niet binnen het uur salderen (nu nog wel natuurlijk maar volgens jaar niet meer). Ik heb nu nog uurprijzen maar ik ga er er vanuit dat het hetzelfde werkt met kwartierprijzen.

[ Voor 4% gewijzigd door appsec op 13-04-2026 23:02 ]

[Broodro0ster]

Vandaag firmware 148 op mijn Marstek V3 geïnstalleerd. Icm de Astrometer reageert die nu enorm snel op pieken.

Voor mijn V2 ook een update gekregen naar firmware 158. Helaas nog steeds 3s polling rate terwijl ik had gevraagd op het op max te zetten (0.5s) zoals mijn V3 en het verschil is zeer goed te zien op de grafiek dat mijn V2 een stuk trager reageert als de V3. Als ze even snel zouden reageren, dan moet NOM bijna haalbaar zijn incl. pieken

[Avenger 2.0]

Broodro0ster schreef op maandag 13 april 2026 @ 23:15:
Voor mijn V2 ook een update gekregen naar firmware 158. Helaas nog steeds 3s polling rate terwijl ik had gevraagd op het op max te zetten (0.5s) zoals mijn V3 en het verschil is zeer goed te zien op de grafiek dat mijn V2 een stuk trager reageert als de V3. Als ze even snel zouden reageren, dan moet NOM bijna haalbaar zijn incl. pieken

Kan de v2 dat aan die 0.5s? Hier ook gevraagd om polling rate te wijzigen, maar ze begrepen men vraag blijkbaar niet en ik had reeds de laatste firmware Maar als ik goed begrijp moet je dat vragen voor de batterij en niet voor de CT P1 meter? Dat heb ik misschien mis gedaan dan.

[adjego]

Broodro0ster schreef op maandag 13 april 2026 @ 23:15:
Vandaag firmware 148 op mijn Marstek V3 geïnstalleerd. Icm de Astrometer reageert die nu enorm snel op pieken.

Voor mijn V2 ook een update gekregen naar firmware 158. Helaas nog steeds 3s polling rate terwijl ik had gevraagd op het op max te zetten (0.5s) zoals mijn V3 en het verschil is zeer goed te zien op de grafiek dat mijn V2 een stuk trager reageert als de V3. Als ze even snel zouden reageren, dan moet NOM bijna haalbaar zijn incl. pieken

Snel vraagje tussendoor, maar moet je om gebruik te kunnen maken van de Astrometer nog steeds eerst echt een CT03 aangesloten hebben voordat dit werkt?

[Broodro0ster]

Avenger 2.0 schreef op dinsdag 14 april 2026 @ 07:29:
[...]

Kan de v2 dat aan die 0.5s? Hier ook gevraagd om polling rate te wijzigen, maar ze begrepen men vraag blijkbaar niet en ik had reeds de laatste firmware Maar als ik goed begrijp moet je dat vragen voor de batterij en niet voor de CT P1 meter? Dat heb ik misschien mis gedaan dan.

Het is inderdaad de batterij die polt. Bij mij hebben ze ook de vraag verkeerd begrepen en firmware 158 gepushed naar mijn V2.
@NoFate heeft voor zijn V2 de polling rate op 0.5 of 0.6s gekregen via de support. Dus hopelijk kan ik het ook bekomen. Ik heb opnieuw geantwoord op het ticket met de vraag als ze 0.5s polling willen enablen. Hopelijk willen ze het dan doen.

[Broodro0ster]

adjego schreef op dinsdag 14 april 2026 @ 09:10:
[...]


Snel vraagje tussendoor, maar moet je om gebruik te kunnen maken van de Astrometer nog steeds eerst echt een CT03 aangesloten hebben voordat dit werkt?

Nope, je kan een fake CT002 of CT003 registeren in jouw Marstek account. Hier werkt het prima en ik heb nog nooit een CT002/CT003 aangesloten gehad.

[adjego]

Broodro0ster schreef op dinsdag 14 april 2026 @ 12:03:
[...]

Nope, je kan een fake CT002 of CT003 registeren in jouw Marstek account. Hier werkt het prima en ik heb nog nooit een CT002/CT003 aangesloten gehad.

Kun je toevallig de config die je gebruikt eens delen?

[Chris96]

Voor de mensen die 2 Marstek V2's hebben staan. Wellicht een handig script voor load balancing!

🔋 Wat doet deze automatisering?

👉 Deze automatisering stuurt twee batterijen slim aan op basis van modus, SOC (laadniveau), verbruik, zonne-opbrengst en tijd.

In “Nul op de meter”:
kiest hij automatisch welke batterij actief is
balanceert hij bij verschil > 9%
wisselt hij bij 100% SOC
gebruikt bij ontladen de volste batterij
gebruikt bij laden de leegste batterij
pauzeert tussen 17:00–19:00 en doet een herverdeling om 19:00
Andere modi:
Standby → alles aan, geen geforceerde actie
Volledig opladen → beide batterijen laden met ingesteld vermogen
Volledig ontladen → beide batterijen ontladen met ingesteld vermogen

code:

alias: LilyGo Control Smart (Active Balance v11.1)
description: "V11.1: Geforceerde wissel bij 100% SOC tijdens laden - FIX Indentation"
triggers:
  - trigger: state
    id: mode_change
    entity_id: input_select.battery_mode
  - trigger: state
    id: soc_change
    entity_id:
      - sensor.lilygo_rs485_marstek_battery_state_of_charge
      - sensor.lilygo_rs485_ii_marstek_battery_state_of_charge
  - trigger: state
    entity_id: input_number.battery_override_power
  - trigger: time
    at: "17:00:00"
  - trigger: time
    id: evening_switch
    at: "19:00:00"
conditions: []
actions:
  - choose:
      - conditions:
          - condition: state
            entity_id: input_select.battery_mode
            state: Nul op de meter
        sequence:
          - alias: Force stop
            if:
              - condition: template
                value_template: |
                  {{ not (
                    is_state('select.lilygo_rs485_marstek_forcible_charge_discharge', 'stop') and
                    is_state('select.lilygo_rs485_ii_marstek_forcible_charge_discharge', 'stop')
                  ) }}
            then:
              - action: select.select_option
                target:
                  entity_id:
                    - select.lilygo_rs485_marstek_forcible_charge_discharge
                    - select.lilygo_rs485_ii_marstek_forcible_charge_discharge
                data:
                  option: stop
          - alias: Fallback bij mode change
            if:
              - condition: trigger
                id: mode_change
            then:
              - choose:
                  - conditions:
                      - condition: template
                        value_template: >
                          {{
                          states('sensor.lilygo_rs485_marstek_battery_state_of_charge')|float(0)
                             > states('sensor.lilygo_rs485_ii_marstek_battery_state_of_charge')|float(0) }}
                    sequence:
                      - action: select.select_option
                        target:
                          entity_id: select.lilygo_rs485_marstek_rs485_control_mode
                        data:
                          option: disable
                      - action: select.select_option
                        target:
                          entity_id: select.lilygo_rs485_ii_marstek_rs485_control_mode
                        data:
                          option: enable
                default:
                  - action: select.select_option
                    target:
                      entity_id: select.lilygo_rs485_marstek_rs485_control_mode
                    data:
                      option: enable
                  - action: select.select_option
                    target:
                      entity_id: select.lilygo_rs485_ii_marstek_rs485_control_mode
                    data:
                      option: disable
              - stop: Fallback uitgevoerd
          - alias: Tijdregel actief (17-19u)
            if:
              - condition: template
                value_template: "{{ 17 <= now().hour < 19 }}"
            then:
              - action: select.select_option
                target:
                  entity_id:
                    - select.lilygo_rs485_marstek_rs485_control_mode
                    - select.lilygo_rs485_ii_marstek_rs485_control_mode
                data:
                  option: disable
              - stop: Tijdregel actief
          - alias: Avond switch triggers
            if:
              - condition: template
                value_template: "{{ trigger.id == 'evening_switch' }}"
            then:
              - choose:
                  - conditions:
                      - condition: template
                        value_template: >
                          {{
                          states('sensor.lilygo_rs485_marstek_battery_state_of_charge')|float(0)
                             > states('sensor.lilygo_rs485_ii_marstek_battery_state_of_charge')|float(0) }}
                    sequence:
                      - action: select.select_option
                        target:
                          entity_id: select.lilygo_rs485_marstek_rs485_control_mode
                        data:
                          option: disable
                      - action: select.select_option
                        target:
                          entity_id: select.lilygo_rs485_ii_marstek_rs485_control_mode
                        data:
                          option: enable
                default:
                  - action: select.select_option
                    target:
                      entity_id: select.lilygo_rs485_marstek_rs485_control_mode
                    data:
                      option: enable
                  - action: select.select_option
                    target:
                      entity_id: select.lilygo_rs485_ii_marstek_rs485_control_mode
                    data:
                      option: disable
          - alias: Hoofdlogica (Laden/Ontladen)
            choose:
              - conditions:
                  - condition: template
                    value_template: >-
                      {{ states('sensor.batterij_vermogen_totaal') | float(0) <
                      0 }}
                sequence:
                  - if:
                      - condition: template
                        value_template: >
                          {{
                          (states('sensor.lilygo_rs485_marstek_battery_state_of_charge')|float(0)
                          - 
                              states('sensor.lilygo_rs485_ii_marstek_battery_state_of_charge')|float(0)) | abs > 9 }}
                    then:
                      - choose:
                          - conditions:
                              - condition: template
                                value_template: >
                                  {{
                                  states('sensor.lilygo_rs485_marstek_battery_state_of_charge')|float(0)
                                  > 
                                     states('sensor.lilygo_rs485_ii_marstek_battery_state_of_charge')|float(0) }}
                            sequence:
                              - action: select.select_option
                                target:
                                  entity_id: >-
                                    select.lilygo_rs485_ii_marstek_rs485_control_mode
                                data:
                                  option: enable
                              - action: select.select_option
                                target:
                                  entity_id: >-
                                    select.lilygo_rs485_marstek_rs485_control_mode
                                data:
                                  option: disable
                          - conditions:
                              - condition: template
                                value_template: >
                                  {{
                                  states('sensor.lilygo_rs485_ii_marstek_battery_state_of_charge')|float(0)
                                  > 
                                     states('sensor.lilygo_rs485_marstek_battery_state_of_charge')|float(0) }}
                            sequence:
                              - action: select.select_option
                                target:
                                  entity_id: >-
                                    select.lilygo_rs485_marstek_rs485_control_mode
                                data:
                                  option: enable
                              - action: select.select_option
                                target:
                                  entity_id: >-
                                    select.lilygo_rs485_ii_marstek_rs485_control_mode
                                data:
                                  option: disable
              - conditions:
                  - condition: or
                    conditions:
                      - condition: template
                        value_template: >-
                          {{ states('sensor.batterij_vermogen_totaal') |
                          float(0) > 0 }}
                      - condition: numeric_state
                        entity_id: sensor.solar_power
                        above: 250
                sequence:
                  - if:
                      - condition: or
                        conditions:
                          - condition: template
                            value_template: >
                              {{
                              (states('sensor.lilygo_rs485_marstek_battery_state_of_charge')|float(0)
                              - 
                                  states('sensor.lilygo_rs485_ii_marstek_battery_state_of_charge')|float(0)) | abs > 9 }}
                          - condition: numeric_state
                            entity_id: >-
                              sensor.lilygo_rs485_marstek_battery_state_of_charge
                            above: 99
                          - condition: numeric_state
                            entity_id: >-
                              sensor.lilygo_rs485_ii_marstek_battery_state_of_charge
                            above: 99
                    then:
                      - choose:
                          - conditions:
                              - condition: template
                                value_template: >
                                  {{
                                  states('sensor.lilygo_rs485_marstek_battery_state_of_charge')|float(0)
                                  < 
                                     states('sensor.lilygo_rs485_ii_marstek_battery_state_of_charge')|float(0) 
                                     or states('sensor.lilygo_rs485_ii_marstek_battery_state_of_charge')|float(0) >= 99 }}
                            sequence:
                              - action: select.select_option
                                target:
                                  entity_id: >-
                                    select.lilygo_rs485_marstek_rs485_control_mode
                                data:
                                  option: disable
                              - action: select.select_option
                                target:
                                  entity_id: >-
                                    select.lilygo_rs485_ii_marstek_rs485_control_mode
                                data:
                                  option: enable
                        default:
                          - action: select.select_option
                            target:
                              entity_id: >-
                                select.lilygo_rs485_ii_marstek_rs485_control_mode
                            data:
                              option: disable
                          - action: select.select_option
                            target:
                              entity_id: select.lilygo_rs485_marstek_rs485_control_mode
                            data:
                              option: enable
      - conditions:
          - condition: state
            entity_id: input_select.battery_mode
            state: Standby
        sequence:
          - action: select.select_option
            target:
              entity_id:
                - select.lilygo_rs485_marstek_rs485_control_mode
                - select.lilygo_rs485_ii_marstek_rs485_control_mode
            data:
              option: enable
          - action: select.select_option
            target:
              entity_id:
                - select.lilygo_rs485_marstek_forcible_charge_discharge
                - select.lilygo_rs485_ii_marstek_forcible_charge_discharge
            data:
              option: stop
      - conditions:
          - condition: state
            entity_id: input_select.battery_mode
            state: Volledig opladen
        sequence:
          - action: select.select_option
            target:
              entity_id:
                - select.lilygo_rs485_marstek_rs485_control_mode
                - select.lilygo_rs485_ii_marstek_rs485_control_mode
            data:
              option: enable
          - action: select.select_option
            target:
              entity_id:
                - select.lilygo_rs485_marstek_forcible_charge_discharge
                - select.lilygo_rs485_ii_marstek_forcible_charge_discharge
            data:
              option: charge
          - action: number.set_value
            target:
              entity_id:
                - number.lilygo_rs485_marstek_forcible_charge_power
                - number.lilygo_rs485_ii_marstek_forcible_charge_power
            data:
              value: "{{ states('input_number.battery_override_power') | float }}"
      - conditions:
          - condition: state
            entity_id: input_select.battery_mode
            state: Volledig ontladen
        sequence:
          - action: select.select_option
            target:
              entity_id:
                - select.lilygo_rs485_marstek_rs485_control_mode
                - select.lilygo_rs485_ii_marstek_rs485_control_mode
            data:
              option: enable
          - action: select.select_option
            target:
              entity_id:
                - select.lilygo_rs485_marstek_forcible_charge_discharge
                - select.lilygo_rs485_ii_marstek_forcible_charge_discharge
            data:
              option: discharge
          - action: number.set_value
            target:
              entity_id:
                - number.lilygo_rs485_marstek_forcible_discharge_power
                - number.lilygo_rs485_ii_marstek_forcible_discharge_power
            data:
              value: "{{ states('input_number.battery_override_power') | float }}"
mode: single

[SatScan]

Chris96 schreef op dinsdag 14 april 2026 @ 16:44:
Voor de mensen die 2 Marstek V2's hebben staan. Wellicht een handig script voor load balancing!

🔋 Wat doet deze automatisering?

👉 Deze automatisering stuurt twee batterijen slim aan op basis van modus, SOC (laadniveau), verbruik, zonne-opbrengst en tijd.

In “Nul op de meter”:
kiest hij automatisch welke batterij actief is
balanceert hij bij verschil > 9%
wisselt hij bij 100% SOC
gebruikt bij ontladen de volste batterij
gebruikt bij laden de leegste batterij
pauzeert tussen 17:00–19:00 en doet een herverdeling om 19:00
Andere modi:
Standby → alles aan, geen geforceerde actie
Volledig opladen → beide batterijen laden met ingesteld vermogen
Volledig ontladen → beide batterijen ontladen met ingesteld vermogen

code:

umber.battery_override_power') | float }}"
mode: single

Als je naast code ook nog quote gebruikt dan is de code ingeklapt en beter leesbaar volgbaar in het topic!

[User9]

Ik heb het dashboard van Home battery control nu geïnstalleerd, alleen is de naamgeving van Bob's code net anders dan voor mijn configuratie. Ik heb superdupers yaml op de Lilygo staan en niet die van Fonske. Ik kan in de yaml van Bob ook de naamgeving niet zo snel vinden. Weet iemand waar dit staat en waar ik dit kan veranderen zodat superdupers naam wordt gevonden voor de Marstek in Home battery control Dashboard? Of kan ik de naam ook veranderen via ESPhome voor de lilygo zodat deze hetzelfde is als die van Fonske? Bovenin de code staat friendly name en name voor de lilygo.

[Tazzios]

@User9 de yaml van fonske in de lily zetten lijkt mij beter dan alle entiteitnamen zelf gaan vervangen in de yaml.(zeker gezien je vraagt hoe dat moet)

[ Voor 13% gewijzigd door Tazzios op 15-04-2026 13:28 ]

[marsian]

User9 schreef op woensdag 15 april 2026 @ 11:15:
Ik heb het dashboard van Home battery control nu geïnstalleerd, alleen is de naamgeving van Bob's code net anders dan voor mijn configuratie. Ik heb superdupers yaml op de Lilygo staan en niet die van Fonske. Ik kan in de yaml van Bob ook de naamgeving niet zo snel vinden. Weet iemand waar dit staat en waar ik dit kan veranderen zodat superdupers naam wordt gevonden voor de Marstek in Home battery control Dashboard? Of kan ik de naam ook veranderen via ESPhome voor de lilygo zodat deze hetzelfde is als die van Fonske? Bovenin de code staat friendly name en name voor de lilygo.

ik liep tegen hetzelfde aan, en aangezien het hernoemen van alle entiteiten niet te doen is ben ik maar weer opnieuw begonnen met een fonske. De oude implementatie uit gezet. Het is het wel waard, wat werkt dat HBC mooi! Loopt tot nu toe veel stabieler dan via de app.

[visie]

Ik ga een Marstek Venus E3 batterij kopen en had een vraagje hierover.
Ik gebruik voor mijn P1 meter een USB-kabel naar mijn home assistent pc. Kan ik deze gegevens gebruiken via de Modbus koppeling?
Of heb ik een HW P1 of CT003 meter nodig?
En zo ja, welke van de 2 heeft de voorkeur?
Tnx alvast voor de reacties!

[CyberEspresso]

visie schreef op donderdag 16 april 2026 @ 07:40:
Ik gebruik voor mijn P1 meter een USB-kabel naar mijn home assistent pc. Kan ik deze gegevens gebruiken via de Modbus koppeling?

Dat werkt uitstekend met b2500-meter / Astrameter. Zo gebruik ik het zelf ook. Als ik de ervaringen hier zo lees is dat zelfs nog stabieler dan met een losse CT003 meter.

[NoFate]

CyberEspresso schreef op donderdag 16 april 2026 @ 09:39:
[...]

Dat werkt uitstekend met b2500-meter / Astrameter. Zo gebruik ik het zelf ook. Als ik de ervaringen hier zo lees is dat zelfs nog stabieler dan met een losse CT003 meter.

Klopt. En het gaat alleen nog maar beter worden. Hij is nog volop bezig, zit nog in develop branch!! Maar het ziet er echt goed uit. Vooral bij meerdere batterijen. Nu kunnen we ze gaan sturen ook om beter nom te werken en met een charge/discharge rotatie en max vermogen settings, komt idd een leuk project aan!!!

[Broodro0ster]

adjego schreef op dinsdag 14 april 2026 @ 12:36:
[...]


Kun je toevallig de config die je gebruikt eens delen?

Dit is mijn config. Dit stukje is enkel voor als je meerdere batterijen hebt en ze wil laten roteren bij lage loads om zo de omvormer iets meer te belasten en hogere efficientie te halen. Zo krijg je makkelijk op een nacht 1kWh meer uit de batterijen.

Bij 1 batterij gooi je gewoon dit stuk er uit.

MIN_EFFICIENT_POWER = 600
EFFICIENCY_ROTATION_INTERVAL = 900
EFFICIENCY_SATURATION_THRESHOLD = 0.65
SATURATION_ALPHA = 0.07
EFFICIENCY_FADE_ALPHA = 0.3

code:

[GENERAL]
DEVICE_TYPE = ct003
THROTTLE_INTERVAL = 0

[CT003]
CT_MAC =
UDP_PORT = 12345
DEDUPE_TIME_WINDOW = 1
ACTIVE_CONTROL = True
SMOOTH_TARGET_ALPHA = 0.9
DEADBAND = 3
BALANCE_DEADBAND = 50

MIN_EFFICIENT_POWER = 600
EFFICIENCY_ROTATION_INTERVAL = 900
EFFICIENCY_SATURATION_THRESHOLD = 0.65
SATURATION_ALPHA = 0.07 
EFFICIENCY_FADE_ALPHA = 0.3

[HOMEWIZARD]
IP = 192.168.1.xx
# Token must be obtained once via POST /api/user while pressing the device button or press the button once before making the call
# curl -k -X POST https://192.168.1.55/api/user -H "X-Api-Version: 2" -H "Content-Type: application/json" -d '{"name": "local/my-app"}'
# curl -k -H "Authorization: Bearer xxxxxxx" -H "X-Api-Version: 2" https://192.168.1.55/api
TOKEN = xxxxxxxx
SERIAL = xxxxxxxxx
POWER_OFFSET = 3

[MARSTEK]
# Optional: auto-register managed fake CT devices in Marstek cloud on startup.
ENABLE = False
BASE_URL = https://eu.hamedata.com
MAILBOX = xxxxxxxxx
PASSWORD = xxxxxxxxx
## Prefix is fixed to 02b250 (locally administered MAC space) for managed fake devices.
## Used for add-device request
TIMEZONE = Europe/Berlin

[MQTT_INSIGHTS]
BROKER = 192.168.1.x
PORT = 1883
USERNAME = b2500
PASSWORD = xxxxxxxxxxxxxx

[savale]

Draai hier nu ook een paar weken de astrameter ct003 in combinatie met lilygo's modbus op 4 venus v3's. Werkt fantastisch! Ik ben blij dat de accu's dan gewoon de marstek NOM gebruiken.

Mocht je al een lilygo modbus setup hebben dan is dit nog wel leuk: Ik heb In de esphome firmware van Fonske wat extra features toegevoegd om de cellen wat te ontzien:

1. Stoppen met laden bij (bijvoorbeeld) 3.50v cell voltage
2. Stoppen met onladen bij (bijvoorbeeld) 3.20v cell voltage (In feite voltage versie van DOD percentage)
3. Vanaf 3.40v cell voltage laden met lager vermogen
4. Eens per x dagen een volledige 100% laadbeurt (reset de SOC van marstek / balancing?)
5. Zelf berekende SOC. (want die van marstek springt soms als je niet altijd 100% laad)
6. Zelf lerende batterij capaciteit (tussen de ingestelde voltage limits)

https://github.com/kiss81/marstek_esphome

[pindamaster]

Hey zijn er mensen die op een venus A de lifetime PV production al hebben weten uit te lezen? Ik heb hier een venus A staan met 2 PV panelen aangesloten. met de "venus A" versie van de modbus/tcp config kan ik wel de mppt power en voltages uitlezen. Maar helaas laat de app meer nummers zien dan de modbus integratie.

[dannyro]

Vandaag een half uurtje het internet uitgevallen. Daarna alles, zonder zelf iets te doen, keurig terug verbonden zoals voorheen. Wat mij wel opviel was dat in HA de RS485 modbus controller op enable stond en Max Charge en discharge op 0 stonden. Zodus de Marstek stond feitelijk in standby. Alles terug normaal gezet en in orde. Goed om te weten natuurlijk. Wat daar de reden voor is weet ik ook niet.

[savale]

dannyro schreef op zaterdag 18 april 2026 @ 20:18:
Vandaag een half uurtje het internet uitgevallen. Daarna alles, zonder zelf iets te doen, keurig terug verbonden zoals voorheen. Wat mij wel opviel was dat in HA de RS485 modbus controller op enable stond en Max Charge en discharge op 0 stonden. Zodus de Marstek stond feitelijk in standby. Alles terug normaal gezet en in orde. Goed om te weten natuurlijk. Wat daar de reden voor is weet ik ook niet.

Welke en wie zijn versie van de esphome firmware config draai je?

[dannyro]

savale schreef op zondag 19 april 2026 @ 09:37:
[...]


Welke en wie zijn versie van de esphome firmware config draai je?

ESP FW 2026.4.0. En ik draai daar de yaml van @AUijtdehaag op. Zelf wel veel automatisaties gemaakt in HA. Bedoel je dit?

[savale]

dannyro schreef op zondag 19 april 2026 @ 09:44:
[...]

ESP FW 2026.4.0. En ik draai daar de yaml van @AUijtdehaag op. Zelf wel veel automatisaties gemaakt in HA. Bedoel je dit?

Hier heb ik ook wat geks met 1 van mijn 4 accu's. Soms reageert hij niet meer. Herstart gedaan en dan zie ik ook de max discharge op 0 staan... (venus v3 firmware v148)

[dannyro]

savale schreef op maandag 20 april 2026 @ 00:11:
[...]


Hier heb ik ook wat geks met 1 van mijn 4 accu's. Soms reageert hij niet meer. Herstart gedaan en dan zie ik ook de max discharge op 0 staan... (venus v3 firmware v148)

Hier geen problemen met de Marstek. Ik gaf dat maar mee omdat het interessant is om weten, als je met modbus werkt, en de Marstek blijft in stand-by staan even naar de instellingen in HA moet gekeken worden. Wat de reden van dit issue is weet ik niet. De eerste keer op bijna 1 jaar tijd dat ik dit zie.

[savale]

dannyro schreef op maandag 20 april 2026 @ 08:36:
[...]

Hier geen problemen met de Marstek. Ik gaf dat maar mee omdat het interessant is om weten, als je met modbus werkt, en de Marstek blijft in stand-by staan even naar de instellingen in HA moet gekeken worden. Wat de reden van dit issue is weet ik niet. De eerste keer op bijna 1 jaar tijd dat ik dit zie.

Dus met modbus naar een zinvolle waarde gezet en hij werkte weer? Ik heb dan denk ik (ook) een ander issue met deze accu. Ga hem binnenkort eens helemaal resetten en tijdje uitzetten.

[dannyro]

savale schreef op maandag 20 april 2026 @ 08:54:
[...]


Dus met modbus naar een zinvolle waarde gezet en hij werkte weer? Ik heb dan denk ik (ook) een ander issue met deze accu. Ga hem binnenkort eens helemaal resetten en tijdje uitzetten.

Inderdaad. De charge en discharge terug op hun normale waarde gezet en control mode terug op disable. En alles werkte weer normaal. Belangrijk voor mij is ook wel dat je bv op vakantie bent je dit ook allemaal kan uitvoeren.

[User9]

Bij het configureren van de Battery Control dashboard krijg ik een error in de configuration.yaml


Ik wil de packages in de config zetten zoals in de Github staat, maar ik krijg een patternwarning.
Het is precies dezelfde code als de github.
Hoe kan ik dit oplossen?
In de folder packages heb ik nog niks staan nu.

[dannyro]

User9 schreef op maandag 20 april 2026 @ 11:49:
Bij het configureren van de Battery Control dashboard krijg ik een error in de configuration.yaml
[Afbeelding]

Ik wil de packages in de config zetten zoals in de Github staat, maar ik krijg een patternwarning.
Het is precies dezelfde code als de github.
Hoe kan ik dit oplossen?
In de folder packages heb ik nog niks staan nu.

Er staat teveel in. Dit moet er staan nadat je de folder packages hebt aangemaakt.

homeassistant:
packages: !include_dir_named packages

[ Voor 3% gewijzigd door dannyro op 20-04-2026 13:43 ]

[User9]

dannyro schreef op maandag 20 april 2026 @ 13:40:
[...]

Er staat teveel in. Dit moet er staan nadat je de folder packages hebt aangemaakt.

homeassistant:
packages: !include_dir_named packages

Dat is exact hetzelfde als in mijn config toch?

[dannyro]

User9 schreef op maandag 20 april 2026 @ 13:46:
[...]

Dat is exact hetzelfde als in mijn config toch?

Juist, ik had niet goed gekeken...
Gebruik jij Studio Code Server?
En voor wat het waard is, deze waarschuwing kan je normaal negeren.

[User9]

dannyro schreef op maandag 20 april 2026 @ 14:12:
[...]

Juist, ik had niet goed gekeken...
Gebruik jij Studio Code Server?
En voor wat het waard is, deze waarschuwing kan je normaal negeren.

Klopt Studio Code Server.

Oke dan laad ik de error staan

Nu kom ik weer op een ander probleem uit.
Ik heb de Lilygo toen ik hem net had geflashed met SuperDuper's yaml.
Maar de naamgeving komt dan niet overeen met die voor Battery Control van Bob.
Nu heb ik fonske yaml op de Lilygo gezet. https://github.com/fonske...blob/main/lilygo_mt1.yaml
Alleen de sensorentiteiten hebben alsnog een andere naam nu.
In Home Battery Control dashboard zoekt het dashboard naar

code:

sensor.marstek_m1_ac_power

Mijn entiteiten heten:

code:

sensor.marstek_m1_marstek_ac_power

Dus met een extra marstek in de benaming.
Ik heb alles al herladen. In ESPhome het board een andere naam gegeven namelijk marstek_m1.
HA paar keer opnieuw opgestart, maar de entiteiten blijven zo heten.
Als ik in het dashboard handmatig naar de sensoren zoek, kom ik ze wel tegen.
Maar dan zou ik bij elke update dit allemaal handmatig moeten aanpassen, niet handig..

[ Voor 4% gewijzigd door User9 op 20-04-2026 14:27 ]

[dannyro]

User9 schreef op maandag 20 april 2026 @ 14:24:
[...]

Klopt Studio Code Server.

Oke dan laad ik de error staan

Nu kom ik weer op een ander probleem uit.
Ik heb de Lilygo toen ik hem net had geflashed met SuperDuper's yaml.
Maar de naamgeving komt dan niet overeen met die voor Battery Control van Bob.
Nu heb ik fonske yaml op de Lilygo gezet. https://github.com/fonske...blob/main/lilygo_mt1.yaml
Alleen de sensorentiteiten hebben alsnog een andere naam nu.
In Home Battery Control dashboard zoekt het dashboard naar

code:

sensor.marstek_m1_ac_power

Mijn entiteiten heten:

code:

sensor.marstek_m1_marstek_ac_power

Dus met een extra marstek in de benaming.
Ik heb alles al herladen. In ESPhome het board een andere naam gegeven namelijk marstek_m1.
HA paar keer opnieuw opgestart, maar de entiteiten blijven zo heten.
Als ik in het dashboard handmatig naar de sensoren zoek, kom ik ze wel tegen.
Maar dan zou ik bij elke update dit allemaal handmatig moeten aanpassen, niet handig..

Studio Code Server updaten kan deze warning misschien oplossen. Voor de rest van Uw vragen zal @AUijtdehaag wel kunnen antwoorden.

[jbbrans]

Ik heb 3x venus V3 en 1x homewizard p1. Deze wil ik via Home Assistant aansturen, hiervoor heb ik nodered, Fonske marstekvenusv3-modbus-tcp-ip en homebatterycontrol geinstalleerd. Ook heb ik een aantal standaard flows van node red gedownload (self consumption, full stop, charge enz.).
De Batterijen en de p1 meter zie ik in HA en heb een dashboard Marstek battery control, waar ik de hoeveelheid batterijen kan instellen en de keuze heb voor de control mode.
De batterijen zijn via de lan aansluiting, bekabeld aangesloten en de p1 meter hangt op 20cm van de router en geeft een goed signaal. Local-API staat uit.

Probleem 1, als ik de keuze op full control-self consumption zet, wordt er maar 1 batterij gebruikt (de 2e in de rij). Als deze vol is gaat de rest van de energie het net in. Ook ontladen gebeurd alleen met deze batterij. Wat opvalt, RS485 control mode is op deze batterij dan disabled, de rest is enabled. Zet ik het op Marstek control, dan gaan alle batterijen op rs485 disable en gaat er weer gewoon NOM geregeld worden.

Probleem 2, maar weet niet of dit een geheel ander probleem is. Node Red werkte de afgelopen paar dagen goed, vandaag wou ik het bekijken en het lijkt alsof het steeds opnieuw wordt opgestart, de flows worden steeds geladen en geladen en geladen.... en node red krijg ik niet langer dan een seconde te zien. De log geeft geen foutmelding of een melding van het herstarten.

s6-rc: info: service s6rc-oneshot-runner: starting
s6-rc: info: service s6rc-oneshot-runner successfully started
s6-rc: info: service base-addon-banner: starting
-----------------------------------------------------------
App: Node-RED
Flow-based programming for the Internet of Things
-----------------------------------------------------------
App version: 21.0.7
You are running the latest version of this app.
System: Home Assistant OS 17.2 (amd64 / qemux86-64)
Home Assistant Core: 2026.4.3
Home Assistant Supervisor: 2026.04.0
-----------------------------------------------------------
Please, share the above information when looking for help
or support in, e.g., GitHub, forums or the Discord chat.
-----------------------------------------------------------
s6-rc: info: service base-addon-banner successfully started
s6-rc: info: service fix-attrs: starting
s6-rc: info: service base-addon-log-level: starting
s6-rc: info: service fix-attrs successfully started
s6-rc: info: service base-addon-log-level successfully started
s6-rc: info: service legacy-cont-init: starting
s6-rc: info: service legacy-cont-init successfully started
s6-rc: info: service init-nginx: starting
s6-rc: info: service init-customizations: starting
s6-rc: info: service init-customizations successfully started
s6-rc: info: service init-nodered: starting
s6-rc: info: service init-nginx successfully started
up to date, audited 1 package in 868ms
found 0 vulnerabilities
s6-rc: info: service init-nodered successfully started
s6-rc: info: service nodered: starting
s6-rc: info: service nodered successfully started
s6-rc: info: service nginx: starting
s6-rc: info: service nginx successfully started
s6-rc: info: service legacy-services: starting
[14:24:41] INFO: Starting Node-RED...
s6-rc: info: service legacy-services successfully started
> start
> node $NODE_OPTIONS node_modules/node-red/red.js --settings /etc/node-red/config.js
20 Apr 14:24:42 - [info]
Welcome to Node-RED
===================
20 Apr 14:24:42 - [info] Node-RED version: v4.1.8
20 Apr 14:24:42 - [info] Node.js version: v24.14.1
20 Apr 14:24:42 - [info] Linux 6.12.77-haos x64 LE
20 Apr 14:24:42 - [info] Loading palette nodes
20 Apr 14:24:43 - [info] Node-RED Contrib Theme Collection version: v4.1.1
20 Apr 14:24:45 - [info] Dashboard version 3.6.6 started at /endpoint/ui
20 Apr 14:24:45 - [info] node-red-contrib-home-assistant-websocket v0.80.3 nodes initialized
20 Apr 14:24:45 - [info] Settings file : /etc/node-red/config.js
20 Apr 14:24:45 - [info] Context store : 'default' [module=memory]
20 Apr 14:24:45 - [info] User directory : /config/
20 Apr 14:24:45 - [warn] Projects disabled : editorTheme.projects.enabled=false
20 Apr 14:24:45 - [info] Flows file : /config/flows.json
20 Apr 14:24:45 - [info] Server now running at http://127.0.0.1:46836/
20 Apr 14:24:45 - [warn]
---------------------------------------------------------------------
Your flow credentials file is encrypted using a system-generated key.
If the system-generated key is lost for any reason, your credentials
file will not be recoverable, you will have to delete it and re-enter
your credentials.
You should set your own key using the 'credentialSecret' option in
your settings file. Node-RED will then re-encrypt your credentials
file using your chosen key the next time you deploy a change.
---------------------------------------------------------------------
20 Apr 14:24:45 - [info] Starting flows
[14:24:46] INFO: Starting NGinx...
20 Apr 14:24:46 - [info] Started flows
20 Apr 14:24:46 - [info] [server:Home Assistant] Connecting to http://supervisor/core
20 Apr 14:24:46 - [info] [server:Home Assistant] Connected to http://supervisor/core
20 Apr 14:24:50 - [info] [server:Home Assistant] Connecting to http://supervisor/core
20 Apr 14:24:50 - [info] [server:Home Assistant] Connected to http://supervisor/core
s6-rc: info: service legacy-services: stopping
s6-rc: info: service legacy-services successfully stopped
s6-rc: info: service nginx: stopping
[14:25:22] INFO: Service NGINX exited with code 0 (by signal 0)
s6-rc: info: service nginx successfully stopped
s6-rc: info: service init-nginx: stopping
s6-rc: info: service nodered: stopping
s6-rc: info: service init-nginx successfully stopped
20 Apr 14:25:22 - [info] Stopping flows
20 Apr 14:25:22 - [info] [server:Home Assistant] Closing connection to http://supervisor/core
20 Apr 14:25:22 - [info] [server:Home Assistant] Closing connection to http://supervisor/core
20 Apr 14:25:22 - [info] Stopped flows
[14:25:22] INFO: Service Node-RED exited with code 0 (by signal 0)
s6-rc: info: service nodered successfully stopped
s6-rc: info: service init-nodered: stopping
s6-rc: info: service init-nodered successfully stopped
s6-rc: info: service init-customizations: stopping
s6-rc: info: service init-customizations successfully stopped
s6-rc: info: service legacy-cont-init: stopping
s6-rc: info: service legacy-cont-init successfully stopped
s6-rc: info: service fix-attrs: stopping
s6-rc: info: service base-addon-log-level: stopping
s6-rc: info: service base-addon-log-level successfully stopped
s6-rc: info: service fix-attrs successfully stopped
s6-rc: info: service base-addon-banner: stopping
s6-rc: info: service base-addon-banner successfully stopped
s6-rc: warning: service s6rc-oneshot-runner is marked as essential, not stopping it

Ik ben een beginner met HA en moet dus stap voor stap leren wat waar staat.
Voor nu voldoed de Marstek app NOM regeling, maar ik wil in de toekomst (lees 2027) mijn overbodige energie op duurdere momenten verkopen en dan weer via PV opladen en in de winter op goedkope tijden volladen en de rest van de dag NOM.

Edit: de node red uninstalled, daarna weer geinstalleerd en gestart, die krijg ik nu weer te zien.
Probleem 1 blijft staan.

[AUijtdehaag]

User9 schreef op maandag 20 april 2026 @ 14:24:
[...]

Klopt Studio Code Server.

Oke dan laad ik de error staan

Nu kom ik weer op een ander probleem uit.
Ik heb de Lilygo toen ik hem net had geflashed met SuperDuper's yaml.
Maar de naamgeving komt dan niet overeen met die voor Battery Control van Bob.
Nu heb ik fonske yaml op de Lilygo gezet. https://github.com/fonske...blob/main/lilygo_mt1.yaml
Alleen de sensorentiteiten hebben alsnog een andere naam nu.
In Home Battery Control dashboard zoekt het dashboard naar

code:

sensor.marstek_m1_ac_power

Mijn entiteiten heten:

code:

sensor.marstek_m1_marstek_ac_power

Dus met een extra marstek in de benaming.
Ik heb alles al herladen. In ESPhome het board een andere naam gegeven namelijk marstek_m1.
HA paar keer opnieuw opgestart, maar de entiteiten blijven zo heten.
Als ik in het dashboard handmatig naar de sensoren zoek, kom ik ze wel tegen.
Maar dan zou ik bij elke update dit allemaal handmatig moeten aanpassen, niet handig..

Het is hier geen HBC helpdesk...
Daar is de discord server voor.

Maar....
Er zit een bugje in HA, in de entiteits ID benamingen, die maakt die niet opnieuw aan, dat moet je even handmatig doen. Maar dat kan met de hele rits tegelijk.
Zie



Opgelost?

[ Voor 4% gewijzigd door AUijtdehaag op 20-04-2026 18:06 ]

[AUijtdehaag]

@jbbrans
Heb je voor elke marstek een opvolgende yaml gebruikt?

Kun je niet handmatig de modbus even op enable zetten?
Op marstek control gaan ze natuurlijk van modbus af... je gaat naar marstek control duh.
Full control zou de modbus weer op enable moeten zetten

(uit mijn hoofd, ik werk ook 36 uur pw ergens anders)

[ Voor 22% gewijzigd door AUijtdehaag op 20-04-2026 18:05 ]

[User9]

AUijtdehaag schreef op maandag 20 april 2026 @ 18:01:
[...]

Het is hier geen HBC helpdesk...
Daar is de discord server voor.

Maar....
Er zit een bugje in HA, in de entiteits ID benamingen, die maakt die niet opnieuw aan, dat moet je even handmatig doen. Maar dat kan met de hele rits tegelijk.
Zie
[Afbeelding]

[Afbeelding]
Opgelost?

Nope, dat had ik al geprobeerd.
Helaas blijven de entititeiten met dubbele marstek benaming.
Ik ga het via Discord verder vragen.

[AUijtdehaag]

@User9
Ik zou esphome builder eens proberen (ipv studio code server?)