Marstek Venus / Duravolt PnP Thuisaccu Modbus koppeling

[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?)

[User9]

AUijtdehaag schreef op maandag 20 april 2026 @ 19:25:
@User9
Ik zou esphome builder eens proberen (ipv studio code server?)

ik ga de lilygo even opnieuw flashen en dan de yaml van fonske vanaf scrap er op laden.
De andere entiteiten ziet die wel in HBC.
Zoals de naam en wifi van de batterij, alleen de sensoren die daadwerkelijk iets uitlezen van de batterij kloppen niet.

[jbbrans]

AUijtdehaag schreef op maandag 20 april 2026 @ 18:05:
@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)

Ik heb inderdaad voor alle 3 de Marsteks een eigen, opvolgende yaml gebruikt.

Maar na een avondje proberen, ben ik er achter dat mijn PID regelaar presets niet kloppen.
Welke preset ik ook instel, mijn waardes blijven 0. Pas bij een handmatig ingestelde KP, beginnen de andere batterijen iets te doen.

Hierbij wil Marstek M2 de leidende blijven. Deze geeft nu in de avond een basis hoeveelheid af en degene welke geselecteerd is in de cycle mag de verschillen opvangen. Alsof deze nog ergens anders door gestuurd wordt.
Morgen maar een harde reset doen op M2.

[onlinaius]

superduper1969 schreef op vrijdag 27 maart 2026 @ 14:17:
[...]

Homeplug Powerline Adapter kitje is ook niet duur.

Die gebruik ik er zelf ook voor, omdat Marstek mijn problemen met mijn Venus A bleef scharen onder 'slecht wifibereik'.

De ellende daarmee is dat je de batterij alleen via de app kunt benaderen als je bluetooth verbinding hebt met de batterij, daarna kun je via LAN de gegevens uitlezen / instellingen aanpassen.

Toen ik de boel nog op wifi had zitten kon ik ook op afstand contact maken met de batterij als ik niet thuis was, dat gaat nu helaas niet meer. (waarom dat is heb ik werkelijk geen idee van).

[rb1213]

hallo allemaal , de laatste tijd verliezen m'n V2 batterijen vaak de phase en gaat naar UNKNOWN ipv phase A. de CT003 blijft wel verbonden weet er iemand of je hier een info van kan opvragen via modbus ?

[AUijtdehaag]

Schakelt iedereen zijn zonnepanelen morgen uit bij negatieve uurprijzen?
https://github.com/fonske...restore_tariff_3_sma.yaml
icm HBC

Hier ook (vandaag) de blueprint mee getest met 3 SMA's

[ Voor 71% gewijzigd door AUijtdehaag op 25-04-2026 14:09 ]

[Kenwood960]

AUijtdehaag schreef op vrijdag 24 april 2026 @ 20:36:
Schakelt iedereen zijn zonnepanelen morgen uit bij negatieve uurprijzen?
https://github.com/hprax/ha-hbc-blueprints
icm HBC

Er is altijd wel een verbruiker bij ons 😁

Eerst de marstek, daarna begint de auto op te laden, en als die vol is en het is de nacht erop vrij koud, begint de warmtepomp reeds de vloer voor te verwarmen.

Als die zaken voldaan zijn is er nog de boiler en de jacuzzi.


Zie net dat de prijs -20c is.... Er zullen een paar zaken parallel moeten draaien 🤣

[ Voor 8% gewijzigd door Kenwood960 op 24-04-2026 23:44 ]

[onlinaius]

AUijtdehaag schreef op vrijdag 24 april 2026 @ 20:36:
Schakelt iedereen zijn zonnepanelen morgen uit bij negatieve uurprijzen?
https://github.com/hprax/ha-hbc-blueprints
icm HBC

Ja, automatisch via HA (en zojuist ook ingesteld dat dit altijd gaat gebeuren bij zulke negatieve prijzen, dat de warmtepomp op maximaal vermogen gaat, en dat de batterij van het net gaat laden).

[GoBieN-Be]

Ik heb (nog) geen dynamisch tarief, dus geen nut.

[florism]

Zoals ik eerder al meldde loopt cel 4 bij mij structureel ver uit de pas — terwijl de andere 15 cellen binnen 20-33mV bij elkaar blijven, zit cel 4 er 80-150mV bovenuit. Gaat om Venus E V2.

Ik denk inmiddels de oorzaak te weten en het is mijn eigen schuld: ik laadde soms met pieken tot 2500W (bijna 0,9C), veel te hoog voor een passieve balancer. Die heeft dan geen schijn van kans als één cel er al tussenuit sprint. Na best wat cycli stapelt dat gewoon op.

Inmiddels laadvermogen begrensd op 1000W, en boven 95% SOC nog maar 50W zodat de balancer rustig zijn werk kan doen. Marstek support heb ik ingeschakeld maar die reageert vooralsnog niet. 😓

Hoe doen jullie dat eigenlijk — begrenzen jullie het laadvermogen actief? En laden jullie altijd naar 100% voor de topbalans of stoppen jullie eerder?

[GoBieN-Be]

Op NOM zonder oplaad limieten, dus tot 2500W en tot 100%, (waarbij MT automatisch met minder vermogen laadt voor de laatste x percent). Mijn cellen zijn keurig dicht bij mekaar.

[ Voor 60% gewijzigd door GoBieN-Be op 26-04-2026 23:42 ]

[florism]

Klopt, laatste x percent gaan met minder. Hoeveel cycli heb je GoBieN-Be? Probleem ontstond hier recentelijk sinds dit seizoen, eerder was alles prima. Het is mij opgevallen met >220 cycli

[SatScan]

Home Battery Controller (HBC)

Integratie met custom Marstek-sensoren
Oplossing via alias/wrapper-laag in Home Assistant

Samenvatting: Pas Home Assistant aan op HBC, niet HBC op Home Assistant. Een alias-laag vertaalt de vaste namen die HBC verwacht naar jouw eigen entity-namen, zonder iets aan de Node-RED flows te hoeven veranderen.

1. Wat is het probleem?

De standaard HBC (Home Battery Controller) Node-RED flows verwachten vaste entity-namen, zoals:
sensor.marstek_m1_*
sensor.marstek_m2_*

In veel Home Assistant-installaties (zoals bij Marstek + Venus + RS485) zien de echte entities er anders uit:
sensor.venus_5_12kwh_zolder_marstek_*
sensor.lilygo_rs485_2_marstek_*

Dit leidt tot foutmeldingen zoals:
Entity could not be found in cache for entityId: select.marstek_m1_rs485_control_mode

2. De oplossing: alias-laag

In plaats van de Node-RED flows aan te passen of entities te hernoemen, maken we een alias-laag via HA templates. Deze laag vertaalt de namen die HBC verwacht naar jouw echte hardware-entities.

Voordelen

Voordeel	Toelichting
HBC blijft standaard	Je hoeft flows nooit aan te passen bij een update
Geen hernoemen nodig	Jouw echte entities blijven intact
Centrale mapping	Alles staat op een plek, makkelijk te onderhouden
Update-proof	HBC en HA kunnen los van elkaar updaten

Hoe werkt het? (architectuur)

HBC (Node-RED)
   v
marstek_m1_* / marstek_m2_*   (virtuele namen)
   v
HA template alias  <-- jouw bestand
   v
echte entities (venus / lilygo / marstek)

3. Implementatie

Bestandslocatie

/config/templates/hbc/hbc_marstek_alias.yaml

Belangrijkste regels

• Alles staat onder één  - sensor:  blok
• Gebruik ook  select:  (voor modes) en  number:  (voor instelbare waarden)
• Geen nieuwe unique_id's aanmaken
• Bestaande entities zijn altijd de bron van waarheid

4. Voorbeelden

4.1 – Sensor alias (batterijstand)

Leest de echte sensor en geeft 'unknown' terug als de waarde niet beschikbaar is:

- sensor:
  - name: marstek_m1_battery_state_of_charge
    state: >
      {% set v = states('sensor.venus_5_12kwh_veranda_marstek_battery_state_of_charge') %}
      {{ v if v not in ['unknown','unavailable','none',''] else 'unknown' }}

4.2 – Select alias (besturingsmode)

Koppelt de HBC-keuzelijst door naar de echte entity, inclusief opties en het doorzenden van de gekozen waarde:

  select:
    - name: marstek_m1_rs485_control_mode
      state: >
        {{ states('select.venus_5_12kwh_veranda_marstek_rs485_control_mode') }}
      options: >
        {{ state_attr('select.venus_5_12kwh_veranda_marstek_rs485_control_mode','options') }}

      select_option:
        service: select.select_option
        target:
          entity_id: select.venus_5_12kwh_veranda_marstek_rs485_control_mode
        data:
          option: "{{ option }}"

4.3 – Number alias (max. laadvermogen)

Cruciaal voor HBC: leest de ingestelde waarde en stuurt nieuwe waarden door naar de echte entity:

  number:
    - name: marstek_m1_max_charge_power
      state: >
        {{ states('number.venus_5_12kwh_veranda_marstek_max_charge_power') | float(0) }}

      set_value:
        service: number.set_value
        target:
          entity_id: number.venus_5_12kwh_veranda_marstek_max_charge_power
        data:
          value: "{{ value }}"

5. Welke entities moet je mappen?

Dit zijn de minimale entities die HBC nodig heeft:

Type	Entity (alias naam)
Besturing M1	select.marstek_m1_rs485_control_mode
Besturing M2	select.marstek_m2_rs485_control_mode
Max. laadvermogen M1	number.marstek_m1_max_charge_power
Max. ontlaadvermogen M1	number.marstek_m1_max_discharge_power
Max. laadvermogen M2	number.marstek_m2_max_charge_power
Max. ontlaadvermogen M2	number.marstek_m2_max_discharge_power
Batterijstand M1	sensor.marstek_m1_battery_state_of_charge
Huidig vermogen M1	sensor.marstek_m1_power

6. Veelgemaakte fouten

Fout 1 – Verkeerde YAML-structuur

Meerdere losse blokken werken niet:

- sensor:
- select:   <-- FOUT

Alles moet genest staan onder één blok:
- sensor:
  ...

  select:
  ...

  number:
  ...

Fout 2 – Entities bestaan niet

HBC verwacht names als  marstek_m1_* , maar die zijn er niet. Zolang er geen alias is, blijven de foutmeldingen komen. De alias-laag lost dit op.

Fout 3 – Vergeten te herstarten

Na elke wijziging: herstart in de juiste volgorde.

1. Home Assistant herstarten
2. Node-RED herstarten
3. Node-RED flows deployen

Let op: Als Node-RED start voordat HA klaar is, zie je een  NoConnectionError . Wacht altijd tot HA volledig is opgestart.

7. Controleren of het werkt

Gebruik de Developer Tools in Home Assistant (Ontwikkelhulpmiddelen > Sjabloon) om te testen of de aliases actief zijn:

{% set bad = ['unknown','unavailable','none',''] %}

{% for e in [
'select.marstek_m1_rs485_control_mode',
'number.marstek_m1_max_charge_power'
] %}
{% set v = states(e) %}
- {{ e }}
status: {% if v in bad %}❌{% else %}✅{% endif %}
value: {{ v }}
{% endfor %}

Als de waarden worden getoond (en niet 'unknown'), is de alias actief.

8. Extra: PV-forecast bug (optioneel)

Gebruik je HBC met PV-forecasting? Let er dan op dat dagopbrengst-sensoren geen lifetime-totaalwaarden doorgeven.

Voeg deze controle toe om spikes van duizenden kWh te voorkomen:
{% set pv = pv if pv < 200 else this.state | float(0) %}

Tip: Dagopbrengst zit zelden boven de 200 kWh. Deze controle vangt vrijwel alle gevallen af.

9. Resultaat

Wat je bereikt	Status
HBC werkt met elke Marstek-setup	Opgelost
Geen entity-fouten meer	Opgelost
Stabiele batterijsturing	Opgelost
Update-proof (zowel HBC als HA)	Opgelost
Centrale, overzichtelijke mapping	Opgelost

Tip: Deze aanpak werkt ook voor andere batterijsystemen, EV-integraties en elke HA-setup met eigen entity-namen. De alias-laag is een universeel patroon.

[AUijtdehaag]

@SatScan
Is het niet eenvoudiger de github fonske codes te gebruiken?
Die hebben al de juiste namen
Heb trouwens mijn v3 nu ook op m5stack modbus rtu aangesloten
Modbus tcp connectie verbrak soms in HA, om onduidelijke reden, waardoor HBC hem niet meer zag
Nu weer retestabiel dankzij esphome

[ Voor 49% gewijzigd door AUijtdehaag op 27-04-2026 15:07 ]

[SatScan]

AUijtdehaag schreef op maandag 27 april 2026 @ 14:32:
@SatScan
Is het niet eenvoudiger de github fonske codes te gebruiken?
Die hebben al de juiste namen

Zeker als je nieuw begint! Maar iemand zoals ik die al een fikse HA config heeft draaien en dan HBC wil gebruiken werkt dit sneller en met minder kans op fouten.
m2c

[WargamingPlayer]

AUijtdehaag schreef op vrijdag 24 april 2026 @ 20:36:
Schakelt iedereen zijn zonnepanelen morgen uit bij negatieve uurprijzen?
https://github.com/fonske...restore_tariff_3_sma.yaml
icm HBC

Hier ook (vandaag) de blueprint mee getest met 3 SMA's

[Afbeelding]

Nee, dump mijn accu’s leeg in de ochtend op hoogste periode en laad accu’s vol vanaf 13:00. Gaat niks naar het net.

[AUijtdehaag]

@WargamingPlayer
Dan laad je de batterijen ook op met zonnestroom?
Dat is toch zonde als je voor verbruik juist betaald krijgt?

[WargamingPlayer]

AUijtdehaag schreef op maandag 27 april 2026 @ 19:42:
@WargamingPlayer
Dan laad je de batterijen ook op met zonnestroom?
Dat is toch zonde als je voor verbruik juist betaald krijgt?

Ja, want ik lever op piek ongeveer 3200-3400 watt op, ik pomp dan gedurende 2,5 - 3 uur ongeveer 4000W mijn 2 accu’s in (want die zijn leeg). Ik buffer dus mijn PV opbrengst weg op het moment dat de prijs onder 0 gaat.

[GoBieN-Be]

florism schreef op zondag 26 april 2026 @ 23:57:
Klopt, laatste x percent gaan met minder. Hoeveel cycli heb je GoBieN-Be? Probleem ontstond hier recentelijk sinds dit seizoen, eerder was alles prima. Het is mij opgevallen met >220 cycli

Ik heb de batterij sinds halverwege augustus 2025 en heeft op een 3-tal dagen na iedere dag gewerkt. Maar hoeveel volledige cycli, heb ik geen idee van. Zie je dat in de App misschien? In de modbus sensoren staat het niet zo te zien.

[djiedjee]

WargamingPlayer schreef op maandag 27 april 2026 @ 20:42:
[...]

Ja, want ik lever op piek ongeveer 3200-3400 watt op, ik pomp dan gedurende 2,5 - 3 uur ongeveer 4000W mijn 2 accu’s in (want die zijn leeg). Ik buffer dus mijn PV opbrengst weg op het moment dat de prijs onder 0 gaat.

Misschien snap ik hem niet helemaal.

Jouw PV opbrengst de accu in: 0 cent
OF
PV uit en laden van het net naar de accu: x cent voor wargamingPlayer

Waarom zou je je panelen niet uitzetten?

[savale]

We hebben nog niet de "force balancing" knop gevonden ben ik bang?
savale in "Hame / Marstek 5,12kWh plug en play thuisaccu"
Hier mijn "Daily Charging Energy" van 12% -> 100% per accu: (ze waren helemaal leeg vanmorgen)

1. 2.03 kWh
2. 2.2 kWh maar nog aan het laden.
3. 2.51 kWh
4. 2.96 kWh

Behoorlijk dramatisch (net als de cell voltage delta)


Echt slijtage van de cellen kan dit nog niet zijn, maar lijkt me echt de enorme cell voltage delta. Ben wel benieuwd wat jullie er in krijgen? Te zien aan de "Daily Charging Energy". Wel opletten dat je tussendoor weer niet ontladen hebt en weer opgeladen, anders klopt dit uiteraard niet.

[ Voor 9% gewijzigd door savale op 28-04-2026 15:10 ]

[RamonMaas]

Hallo Allemaal,

Sinds een maand heb ik een dynamisch energiecontract en wil ik mijn Marstek V2 meer benutten.
Ik ben op zoek naar een kant en klare LilyGo om de batterij via Homey mee aan te kunnen sturen. Het in verbinden van kabels en flashen van hardware lijkt mij te complex. Is er een mogelijkheid om een kant en klare LilyGo aan te schaffen?

[dannyro]

savale schreef op dinsdag 28 april 2026 @ 15:08:
We hebben nog niet de "force balancing" knop gevonden ben ik bang?
savale in "Hame / Marstek 5,12kWh plug en play thuisaccu"
Hier mijn "Daily Charging Energy" van 12% -> 100% per accu: (ze waren helemaal leeg vanmorgen)

1. 2.03 kWh
2. 2.2 kWh maar nog aan het laden.
3. 2.51 kWh
4. 2.96 kWh

Behoorlijk dramatisch (net als de cell voltage delta)
[Afbeelding]

Echt slijtage van de cellen kan dit nog niet zijn, maar lijkt me echt de enorme cell voltage delta. Ben wel benieuwd wat jullie er in krijgen? Te zien aan de "Daily Charging Energy". Wel opletten dat je tussendoor weer niet ontladen hebt en weer opgeladen, anders klopt dit uiteraard niet.

Dat ziet er inderdaad niet goed uit. Daily Charging is moeilijk. Wij zijn een hele dag thuis. Hier een afbeelding van mijn V2.

[Avenger 2.0]

Een gezonde E v2 kan je ongeveer ~4kWh uithalen (met HW plug gemeten). Delta van cellen is inderdaad een ramp, vooral bij één cel is het verschil (~80mV) groot bij ontladen (11%) hier. Bij 100% geladen zijn de waarden 'all over the place' Zullen moeten zien hoe lang het mee gaat. Maar als je significant minder dan ~4kWh kan uithalen zou ik toch vragen voor een vervanging. Heb dat uiteindelijk met men Venus C ook gedaan, kreeg daar maar ~1,5kWh uit terwijl men vervanging ~2,2kWh uit haal.

[ Voor 34% gewijzigd door Avenger 2.0 op 28-04-2026 17:26 ]

[Marve79]

Hoe forceren jullie self consumption via HA/Modbus?

Ik zet work mode op antifeed, force mode op stop (0) maar dan schiet hij in bypass mode. Doe ik discharge dan gaat hij volle bak injecteren op de grid (sell electricity)

Ik gebruik de modbus integratie in HA. Die van vyper.

[AUijtdehaag]

@Marve79
Kun je niet beter meteen overstappen op de nodered code van Bob en github fonske yaml?

Heb je een V2 of V3 marstek venus?

[Marve79]

AUijtdehaag schreef op dinsdag 28 april 2026 @ 19:00:
@Marve79
Kun je niet beter meteen overstappen op de nodered code van Bob en github fonske yaml?

Heb je een V2 of V3 marstek venus?

V3, ik heb er 2. Ik zal het eens bekijken.

[AUijtdehaag]

@Marve79
Verwijder dan eerst de integratie van Viper anders botst dat met entity namen.
Discord voor specifieke vragen

[ Voor 29% gewijzigd door AUijtdehaag op 28-04-2026 19:19 ]

[onlinaius]

Marve79 schreef op dinsdag 28 april 2026 @ 18:53:
Hoe forceren jullie self consumption via HA/Modbus?

Ik zet work mode op antifeed, force mode op stop (0) maar dan schiet hij in bypass mode. Doe ik discharge dan gaat hij volle bak injecteren op de grid (sell electricity)

Ik gebruik de modbus integratie in HA. Die van vyper.

Ik gebruik de integratie van Fonske, en daarmee zet ik RS485 aansturing op disabled en de aansturing op antifeed, daarmee is de 'normale' self consumption modus weer geactiveerd.

[Marve79]

onlinaius schreef op dinsdag 28 april 2026 @ 19:23:
[...]

Ik gebruik de integratie van Fonske, en daarmee zet ik RS485 aansturing op disabled en de aansturing op antifeed, daarmee is de 'normale' self consumption modus weer geactiveerd.

Ja dat zei iemand mij net ook, de app staat dan wel op self consumption maar hij laat zien: Sell electricity en begint het net op te duwen maximaal.

Edit: Hij zegt sell electricity maar hij doet toch enkel self consumption. Die label is gewoon verkeerd.

[ Voor 10% gewijzigd door Marve79 op 28-04-2026 19:53 ]

[rb1213]

-DRINGENDE VRAAG -

ik stuur ook m'n marstek batterij v2 aan via HA modbus, (vooral voor piek shaving wat de Marstek app niet biedt)
maar ...schrijven we naar RAM of naar EEPROM (Flash) ?
want als het naar flash is dan schrijven we die snel kapot niet? en doen we dat beter niet !
gewoon op NOM zetten en vergeten dan

[Marve79]

AUijtdehaag schreef op dinsdag 28 april 2026 @ 19:17:
@Marve79
Verwijder dan eerst de integratie van Viper anders botst dat met entity namen.
Discord voor specifieke vragen

Dank. Ik heb alles gefactory reset en verwijderd en ik ga hiermee opnieuw beginnen

[Tazzios]

@rb1213 en waar wordt de aansturing van NOM data dan in weggeschreven?

[AUijtdehaag]

De vraag is niet zo dringend.
Gaat al een jaar goed met >120 k x schrijven en lezen.
Ik zou wel eens een bewijs willen zien van deze bewering? Zijn er al defecten gemeld?

[ Voor 36% gewijzigd door AUijtdehaag op 28-04-2026 22:49 ]

[Marve79]

Inmiddels node red draaien. Ik heb Claude heel de flow naar mijn wensen laten bouwen en nu werkt alles perfect.

De modbus integratie via yaml is ook een stuk simpeler dan de haca module.

[rb1213]

AUijtdehaag schreef op dinsdag 28 april 2026 @ 22:46:
De vraag is niet zo dringend.
Gaat al een jaar goed met >120 k x schrijven en lezen.
Ik zou wel eens een bewijs willen zien van deze bewering? Zijn er al defecten gemeld?

nee het was een vraag ! geen bewering
het is dus geen probleem …oef want ik stuur die ontlaad limiet soms elke 10sec aan! (en nom instellen niet)

[ Voor 4% gewijzigd door rb1213 op 29-04-2026 10:21 ]

[florism]

Voor het balanceren / SOC kalibrieren heb ik misschien wel iets gevonden - ik had een enorme drift vanaf 95% SOC - ik heb een V2 en upgrade aangevraagd op V156 met BMS V21, ik heb het gevoel dat na firmware upgrade ergens een flag wordt gezet voor SOC kalibratie/balancing want dit gaat nu wel echt goed!



Ben nu met 100W heel voorzichtig bezig, eens kijken of dat zo blijft. Zou er iets in de firmware procedure zitten wat we voor balancing/kalibratie kunnen misbruiken? 🙈

[Tazzios]

AUijtdehaag schreef op dinsdag 28 april 2026 @ 19:00:
@Marve79
Kun je niet beter meteen overstappen op de nodered code van Bob en github fonske yaml?

Heb je een V2 of V3 marstek venus?

Maar je zelf verwijzen in derde persoon?

[AUijtdehaag]

Tazzios schreef op woensdag 29 april 2026 @ 16:18:
[...]

Naar je zelf verwijzen in derde persoon?

Scheelt een hoop vragen…

[onlinaius]

AUijtdehaag schreef op woensdag 29 april 2026 @ 16:33:
[...]

Scheelt een hoop vragen…

Thank you for your service!

Nu ik je hier toch tref: ik zie wat afwijkende waardes in de SoC van mijn Venus A zoals gemeld via je integratie, en zoals gemeld in de app. Qua verloop bij het laden en ontladen gok ik toch dat de app SoC klopt.

Is dit een bekend probleem?

Op dit moment scheelt het vrij weinig, maar ik heb ook regelmatig gezien dat er meer dan 10% verschil tussen de Marstek app en de integratie zit.

[AUijtdehaag]

@onlinaius
Ik heb geen venus A om mee te testen
Probeer anders de code van @savale eens uit
savale in "Marstek Venus / Duravolt PnP Thuisaccu Modbus koppeling"

[Avenger 2.0]

florism schreef op woensdag 29 april 2026 @ 12:00:
Voor het balanceren / SOC kalibrieren heb ik misschien wel iets gevonden - ik had een enorme drift vanaf 95% SOC - ik heb een V2 en upgrade aangevraagd op V156 met BMS V21, ik heb het gevoel dat na firmware upgrade ergens een flag wordt gezet voor SOC kalibratie/balancing want dit gaat nu wel echt goed!

Welke BMS heb je nu juist gekregen? Want BMS is hier v216 en firmware v158 sinds enkele maanden. Merk hier niet direct beterschap of moet je nog iets speciaals voor doen?

[tinamar]

florism schreef op woensdag 29 april 2026 @ 12:00:
Voor het balanceren / SOC kalibrieren heb ik misschien wel iets gevonden - ik had een enorme drift vanaf 95% SOC - ik heb een V2 en upgrade aangevraagd op V156 met BMS V21, ik heb het gevoel dat na firmware upgrade ergens een flag wordt gezet voor SOC kalibratie/balancing want dit gaat nu wel echt goed!

[Afbeelding]

Ben nu met 100W heel voorzichtig bezig, eens kijken of dat zo blijft. Zou er iets in de firmware procedure zitten wat we voor balancing/kalibratie kunnen misbruiken? 🙈

Mijn V2 na de laatste 2 weken vrijwel dagelijks van 11 naar 100% met het mooie weer toch weer de volle capaciteit gekregen na heel de winter met NOM en nooit tot vol geladen.

Vanmorgen in 1 keer volgeladen zonder grote verbruikers

[Marve79]

Vandaag eerste keer laden/ontladen met dubbele marstek v3. Heb nog geen zonnepanelen dus het is nog puur prijssturing. Weinig ervaring met node red en beetje gesukkel met de automations waardoor ik iets te laat begon te laden bij de negatieve prijzen vandaag maar voor een eerste poging meer dan tevreden.