Marstek Venus / Duravolt PnP Thuisaccu Modbus koppeling

[RefleXion]

pascallj schreef op woensdag 3 december 2025 @ 21:01:
[...]


Petje af voor Gemini! Ik waarschuw hier ook elke keer voor, maar ben een van de weinigen die zich daarover zorgen maakt volgens mij. We weten er niets over want Modbus is niet officieel ondersteund.

Wat je je af moet vragen is of de waarde wordt opgeslagen in Flash of RAM. Aangezien de batterij niet helemaal uit kan (of anders gezegd, we kunnen niet bewijzen dat hij helemaal uit is geweest) is het lastig om te testen. Ik heb al wel vaker aangetoond dat zelfs bij een complete reboot (dus inclusief stekker eruit), de Modbus waarde opgeslagen blijft. Het 'actie'-register staat wel altijd op stop ongeacht wat de actie was waarmee hij werd afgesloten. Dat zegt natuurlijk niet alles, kan ook gewoon betekenen dat hij het nog net overschrijft voor het afsluiten.

Sturen via de B2500 emulator, lijkt mij een veiligere keuze als je zelf een NOM sturing wilt schrijven.

Zo lang er niets duidelijk is ga ik voor de veilig optie. NOM via de P1 meter van Marstek en uitlezen via modbus voor home assistant. Bedankt!

[savale]

@pascallj
@RefleXion
Zelf niet eens over nagedacht nog (met een programmeur petje op), maar het lijkt me stug dat als je in manual mode zit dat die geforceerde laad / ontlaad waardes naar het eeprom worden geschreven: je (marstek) wil toch niet dat dat na een reboot onthouden zou worden? De maximale ontlaad / laad limieten moet je wellicht wel een beetje mee oppassen: die lijken me nog enigzins logisch om op de slaan.
Weet niet of iemand hier al NOM stuurt via modbus? Zo ja hoe lang al?
Ligt er natuurlijk aan wat er in zit, maar zeg dat een EEPROM 100k writes mee gaat. Met een gemiddelde update iedere 5 seconden zit je na 12 uur bijvoorbeeld al op meer dan 8000 writes. Dat betekend dat je met 12 dagen je EEPROM al zou kunnen slopen.... Als hier dus al iemand dit een paar maanden heeft draaien dan weet je vrij zeker dat het wel goed zit. Anders wellicht wel een goede vraag voor marstek?

[ Voor 39% gewijzigd door savale op 03-12-2025 21:25 ]

[AUijtdehaag]

@savale
Ik stuur het al sinds april dit jaar op een V1 en een paar maanden later ook op een V2 aan via modbus.
Geen centje pijn.

[ Voor 8% gewijzigd door AUijtdehaag op 03-12-2025 21:36 ]

[savale]

AUijtdehaag schreef op woensdag 3 december 2025 @ 21:36:
@savale
Ik stuur het al sinds april dit jaar op een V1 en een paar maanden later ook op een V2 aan via modbus.
Geen centje pijn.

Thanks! Welke update rate? Als je het al zo een lange periode hebt draaien kunnen we denk ik met heel wat zekerheid zeggen dat het niet naar het EEPROM wordt geschreven...

Nog een ander ding: als ik de accu uit zet en vervolgens weer aan start de home assistant integratie hier altijd zo op (esphome modbus brdige met viper implementatie):



alles op nul zeg maar. Lijkt dus helemaal niks naar EEPROM geschreven te worden... Enige dat ik niet zeker weet of deze waardes ook echt worden uitgelezen? Of dat dit enkel de waardes zijn die je er zelf in zet, want dan zegt dit nog niks. Maar dat weet @superduper1969 wel denk ik?

[ Voor 49% gewijzigd door savale op 03-12-2025 21:59 ]

[pascallj]

savale schreef op woensdag 3 december 2025 @ 21:44:
[...]


Thanks! Welke update rate? Als je het al zo een lange periode hebt draaien kunnen we denk ik met heel wat zekerheid zeggen dat het niet naar het EEPROM wordt geschreven...

Nog een ander ding: als ik de accu uit zet en vervolgens weer aan start de home assistant integratie hier altijd zo op (esphome modbus brdige met viper implementatie):

[Afbeelding]

alles op nul zeg maar. Lijkt dus helemaal niks naar EEPROM geschreven te worden... Enige dat ik niet zeker weet of deze waardes ook echt worden uitgelezen? Of dat dit enkel de waardes zijn die je er zelf in zet, want dan zegt dit nog niks. Maar dat weet @superduper1969 wel denk ik?

Echt veel zegt dat niet natuurlijk, de levensduur kan heel erg variëren.

Maar zoals ik zei, ik kan het ook niet uitsluiten want je kan het apparaat niet uitzetten. Aan de andere kant is de Modbus volgens mij ook gemaakt voor externe sturing met speciale kastjes oid, dus misschien is het er wel voor gemaakt. Maar we weten het gewoon niet.

Dat alles op 0 staat ligt waarschijnlijk aan je integratie, want dat heb ik hier met de ESPHome niet. Alles wordt netjes opgeslagen en uitgelezen na een complete herstart. Alleen "Charge to SOC" staat op 0 als je die niet gebruikt hebt.

Overigens gaat Marstek hier ook geen antwoord op geven (aan ons) omdat er geen officiële ondersteuning voor Modbus is. Alle Modbus vragen worden beantwoord met de melding dat er geen support voor is.

[ Voor 7% gewijzigd door pascallj op 03-12-2025 23:31 ]

[savale]

pascallj schreef op woensdag 3 december 2025 @ 23:19:
[...]


Echt veel zegt dat niet natuurlijk, de levensduur kan heel erg variëren.

Maar zoals ik zei, ik kan het ook niet uitsluiten want je kan het apparaat niet uitzetten. Aan de andere kant is de Modbus volgens mij ook gemaakt voor externe sturing met speciale kastjes oid, dus misschien is het er wel voor gemaakt. Maar we weten het gewoon niet.

Dat alles op 0 staat ligt waarschijnlijk aan je integratie, want dat heb ik hier met de ESPHome niet. Alles wordt netjes opgeslagen en uitgelezen na een complete herstart. Alleen "Charge to SOC" staat op 0 als je die niet gebruikt hebt.

Overigens gaat Marstek hier ook geen antwoord op geven (aan ons) omdat er geen officiële ondersteuning voor Modbus is. Alle Modbus vragen worden beantwoord met de melding dat er geen support voor is.

Dank je voor de info: kwestie van uitproberen om het gedrag van eventueel EEPROM uit te vogelen. Ik kan me ook voorstellen dat er periodiek wat wordt opgeslagen. Je gebruikt de mqtt integratie van @superduper1969 ? Ik zal eens proberen uit te vogelen of de marstek dit opslaat of esphome zelf... Het belangrijkste is het geforceerde laad / ontlaad wattage, want die pas je continu aan.

[pascallj]

savale schreef op donderdag 4 december 2025 @ 08:14:
[...]


Dank je voor de info: kwestie van uitproberen om het gedrag van eventueel EEPROM uit te vogelen. Ik kan me ook voorstellen dat er periodiek wat wordt opgeslagen. Je gebruikt de mqtt integratie van @superduper1969 ? Ik zal eens proberen uit te vogelen of de marstek dit opslaat of esphome zelf... Het belangrijkste is het geforceerde laad / ontlaad wattage, want die pas je continu aan.

Nee ik gebruik gewoon een configuratie van ESPHome. Welke maakt niet zoveel uit. Maar het is niet ESPHome die dat bewaart, het is echt de batterij. Mijn ESP leest alles elke 5 seconde opnieuw uit. Maar zoals ik al zei kan het ook gewoon zijn dat hij met een herstart de laatste waarde opslaat, dus er is bijna niet achter te komen.

[savale]

pascallj schreef op donderdag 4 december 2025 @ 09:00:
[...]


Nee ik gebruik gewoon een configuratie van ESPHome. Welke maakt niet zoveel uit. Maar het is niet ESPHome die dat bewaart, het is echt de batterij. Mijn ESP leest alles elke 5 seconde opnieuw uit. Maar zoals ik al zei kan het ook gewoon zijn dat hij met een herstart de laatste waarde opslaat, dus er is bijna niet achter te komen.

Ja zou periodiek kunnen zijn of bij een shutdown inderdaad. Kom je inderdaad niet achter zonder inside info van marstek. Ik ga er toch eens een support vraag aan wagen.
Aan de andere kant heeft @AUijtdehaag het dus al ruim een half jaar draaien. Ik denk dat je dan wel (bijna) kunt uitsluiten dat het een EEPROM write is na iedere modbus update want dat zouden echt wel al meer dan 1.000.000 EEPROM writes zijn. Implementatie technisch lijkt het me ook niet heel logisch).

Voor NOM ga ik misschien wel voor de zekerheid een backup plannetje maken, maar heb me totaal nog niet verdiept in hoe Marstek het zelf regelt en of dat uberhaupt wel werkt met 4 accu's...

Zit ook nog te denken aan een soort hybride oplossing: 1 accu laat ik gedurende de nacht geforceerd ontladen op mijn idle verbruikt (zeg 400 watt). En dan zet ik 1 accu op Marstek NOM die dan de "pieken" opvangt. Moet ik nog wel even op zoek naar een p1 splitter en even checken welke p1 dongle het beste werkt voor marstek NOM.

[RefleXion]

savale schreef op donderdag 4 december 2025 @ 09:20:
[...]
Voor NOM ga ik misschien wel voor de zekerheid een backup plannetje maken, maar heb me totaal nog niet verdiept in hoe Marstek het zelf regelt en of dat uberhaupt wel werkt met 4 accu's...

Heb het hier met 9 accu's getest, en dat werkt prima. Als ik op de P1 meter van HomeWizzard kijk zie ik echter nog wel kleine piekjes omhoog en omlaag, maar hij kan natuurlijk niet alles voorspellen, benieuwd of het met modbus aansturing nog preciezer is (mijn slimme meter rapporteert elke seconde).

[savale]

RefleXion schreef op donderdag 4 december 2025 @ 10:14:
[...]


Heb het hier met 9 accu's getest, en dat werkt prima. Als ik op de P1 meter van HomeWizzard kijk zie ik echter nog wel kleine piekjes omhoog en omlaag, maar hij kan natuurlijk niet alles voorspellen, benieuwd of het met modbus aansturing nog preciezer is (mijn slimme meter rapporteert elke seconde).

Mijn meter wordt nog vervangen voor 1 seconde updates via P1. Welke dongle (en splitter?) gebruik je in combinatie met die 9 accu's?

[RefleXion]

savale schreef op donderdag 4 december 2025 @ 10:19:
[...]
Mijn meter wordt nog vervangen voor 1 seconde updates via P1. Welke dongle (en splitter?) gebruik je in combinatie met die 9 accu's?

Ik heb een HomeWizzard actieve splitter met de HomeWizzard P1 meter en de Marstek P1 meter (CT003) aan mijn slimme meter hangen. De accu's staan ingesteld op NOM met de Marstek meter als CT. Ze gaan elkaar niet opladen en lijken de meter aardig rond de nul te houden. Wat de individuele accu's doen is lastig te zien (app update niet erg snel). Vanmiddag komt de hardware binnen voor de modbus aansluiting, misschien dat ik er dan iets meer over kan vertellen.

[RefleXion]

Met dit soort losse stekkertjes kun je heel mooie professionele aansluitkabels maken (zonder zichtbare gekleurde draadjes). Deze kabel indeling werkt bij mij op Marstek Venus E V3.

[savale]

Ziet er nejtes uit, maar waar sluit je die dan weer op aan @RefleXion ?

[RefleXion]

savale schreef op donderdag 4 december 2025 @ 17:58:
Ziet er nejtes uit, maar waar sluit je die dan weer op aan @RefleXion ?

Elfin 11A en dan op RS485 poort van accu.

Werkt perfect met ViperRNMC/marstek_venus_modbus.



Hangt nu wel nog allemaal los, morgen even wat dubbelzijdige tape aanschaffen!

[corsat]

Ik probeer weer een poging te wagen om mijn 2 marstek accus aan te sturen vanuit HA.
Ik volg de instructies om m.b.t node red de accu' s aan te gaan sturen maar ik loop vast op mijn p1 meter. Ik heb een youless en ik heb een shelly pro 3em. Als ik deze meters probeer toe te voegen aan het config bestand gebeurt er niets. Als ik vervolgens begin te rommelen in dat bestand door het bovenste deel weg te halen omdat ik een 3 fasen meter heb krijg ik allerlei error meldingen. De vraag is welke meter ik hier kan gebruiken en waarom de config file dit niet pakt of moet ik echt de b2500 emulatie installeren voordat ik dit kan instellen?

[AUijtdehaag]

@corsat Ik gebruik gewoon mijn HW p1 wifi in de nodered flow

YAML:

# This file contains config for Home Assistant unique to your installation and should not be overwritten with each update of House Battery Control
# It should be included in the main configuration.yaml file as a `package` via `!include_dir_named` https://www.home-assistant.io/docs/configuration/packages/.
# Use the values below as a `template` for your specific needs

template:
  - sensor:
      # Example: sensor for single-phase power meter
#      - name: "L1 Meter Power"
#        unique_id: "l1_meter_power"
#        unit_of_measurement: "W"
#        device_class: "power"
#        state_class: "measurement"
#        state: >
#          {% set consumption = states('sensor.electricity_meter_power_consumption_phase_l1') | float(0) %}
#          {% set production = states('sensor.electricity_meter_power_production_phase_l1') | float(0) %}
#          {{ (consumption - production) | round(2) }}

      # House battery control | Grid power
      # Your P1 meter indicates the power drawn or returned to grid.
      # This "P1 meter power" sensor acts as an alias for you power sensing configuration and is used throughout the node-RED scripts.
      - name: "p1 meter power"
        unique_id: "p1_meter_power"
        state: "{{ states('sensor.p1_meter_active_power') }}" # << SET YOUR GRID POWER SENSOR HERE
        unit_of_measurement: "W"
        device_class: "power"
        state_class: "measurement"

[RefleXion]

Heb inmiddels alles draaien.



Met wat vibe coding ook een mooi kaartje gemaakt per accu (DM voor kopie).

In de automatische stand lijkt het vrij willekeurig welke accu's er ontladen, ik kan er in ieder geval geen patroon in ontdekken.

[corsat]

AUijtdehaag schreef op donderdag 4 december 2025 @ 20:41:
@corsat Ik gebruik gewoon mijn HW p1 wifi in de nodered flow

YAML:

# This file contains config for Home Assistant unique to your installation and should not be overwritten with each update of House Battery Control
# It should be included in the main configuration.yaml file as a `package` via `!include_dir_named` https://www.home-assistant.io/docs/configuration/packages/.
# Use the values below as a `template` for your specific needs

template:
  - sensor:
      # Example: sensor for single-phase power meter
#      - name: "L1 Meter Power"
#        unique_id: "l1_meter_power"
#        unit_of_measurement: "W"
#        device_class: "power"
#        state_class: "measurement"
#        state: >
#          {% set consumption = states('sensor.electricity_meter_power_consumption_phase_l1') | float(0) %}
#          {% set production = states('sensor.electricity_meter_power_production_phase_l1') | float(0) %}
#          {{ (consumption - production) | round(2) }}

      # House battery control | Grid power
      # Your P1 meter indicates the power drawn or returned to grid.
      # This "P1 meter power" sensor acts as an alias for you power sensing configuration and is used throughout the node-RED scripts.
      - name: "p1 meter power"
        unique_id: "p1_meter_power"
        state: "{{ states('sensor.p1_meter_active_power') }}" # << SET YOUR GRID POWER SENSOR HERE
        unit_of_measurement: "W"
        device_class: "power"
        state_class: "measurement"

Ik heb geen hw p1 meter maar ik heb mijn youless p1 meter en ik heb die entiteit ingevuld in dit script maar hij start niet en dat geldt ook voor mijn Shelly pro 3em. Waarom dat bij mij niet werkt kom ik dus niet uit.

[WargamingPlayer]

Inmiddels Versie 2025.12.1 van mijn Packages gepost. De oude ware breaking voor HA Core 2025.12.0.

[cthings]

Ik gebruik al een tijdje met veel plezier de lilygo RS485 met de spullies van Superduper1969 gekoppeld aan mijn HA. Het valt me wel op dat wanneer ik een automation gebruik, of bijv via de HA Rest API settings van de Marstek verander, het zo'n 15 sec duurt voordat de Marstek de wijziging oppakt. Is dat alleen bij mij zo?
Zijn er manieren om de responsetijd omhoog te krijgen? Ik heb ook een Sessy en daarbij is de reactie enkele seconden. Ik heb dan ook het idee dat het niet aan de HA ligt, maar weet niet zo goed waar ik het wel moet zoeken.

[Maxwp]

RefleXion schreef op donderdag 4 december 2025 @ 18:30:
[...]


[Afbeelding]

Elfin 11A en dan op RS485 poort van accu.

Werkt perfect met ViperRNMC/marstek_venus_modbus.

[Afbeelding]

Hangt nu wel nog allemaal los, morgen even wat dubbelzijdige tape aanschaffen!

Mijn god 45kwh.

Even pronken zeg pfff

[WargamingPlayer]

Maxwp schreef op vrijdag 5 december 2025 @ 00:12:
[...]

Mijn god 45kwh.

Even pronken zeg pfff

45kWH voor minder dan € 12K.
Dat is geen gekke deal eigenlijk.

[AUijtdehaag]

corsat schreef op donderdag 4 december 2025 @ 21:57:
[...]

Ik heb geen hw p1 meter maar ik heb mijn youless p1 meter en ik heb die entiteit ingevuld in dit script maar hij start niet en dat geldt ook voor mijn Shelly pro 3em. Waarom dat bij mij niet werkt kom ik dus niet uit.

En de youless geeft 1 p1 waarde zowel
positief als negatief of 2 getallen?

Ik heb geen glazen bol he?

Dat is het verschil tussen bovenste gedeelte vd code en onderste
De bovenste doet een berekening tussen twee waarden

[ Voor 11% gewijzigd door AUijtdehaag op 05-12-2025 06:06 ]

[RefleXion]

WargamingPlayer schreef op vrijdag 5 december 2025 @ 02:45:
[...]

45kWH voor minder dan € 12K.
Dat is geen gekke deal eigenlijk.

Zelfs maar 11,3K € (bulk korting) inclusief CT003. Terugverdiend in 4 jr bij nul op de meterstand. En 46 kWh klinkt als veel, maar zonder gas met een elektrische warmtepomp is het zo weg.

Maar beetje off topic hier.

Ik kan de accu's nu grotendeels via modbus aansturen en uitlezen, maar weet iemand of het ook mogelijk is de CT instellingen van de accu via modbus aan te passen? Ik zie het in de integratie in ieder geval niet terug.

[ Voor 7% gewijzigd door RefleXion op 05-12-2025 08:13 ]

[savale]

RefleXion schreef op vrijdag 5 december 2025 @ 08:08:
[...]


Zelfs maar 11,3K € (bulk korting) inclusief CT003. Terugverdiend in 4 jr bij nul op de meterstand. En 46 kWh klinkt als veel, maar zonder gas met een elektrische warmtepomp is het zo weg.

Maar beetje off topic hier.

Ik kan de accu's nu grotendeels via modbus aansturen en uitlezen, maar weet iemand of het ook mogelijk is de CT instellingen van de accu via modbus aan te passen? Ik zie het in de integratie in ieder geval niet terug.

Wel een te gekke opstelling heb je hoor!
CT aanpassen via modbus heb ik ook niet gezien in de viper implementatie... Heb NOM werkend met de b2500 shellpro3em emulator. (haalt info uit home assistant).
Enige wat ik niet helemaal voor elkaar krijg: stel ik forceer laden / ontladen via modbus en ik wil dan weer naar marstek NOM mode: kan dat? Hier gaat met anti-feed dan met de max discharge limit ontladen...

[RefleXion]

savale schreef op vrijdag 5 december 2025 @ 09:20:
[...]


Wel een te gekke opstelling heb je hoor!
CT aanpassen via modbus heb ik ook niet gezien in de viper implementatie... Heb NOM werkend met de b2500 shellpro3em emulator. (haalt info uit home assistant).
Enige wat ik niet helemaal voor elkaar krijg: stel ik forceer laden / ontladen via modbus en ik wil dan weer naar marstek NOM mode: kan dat? Hier gaat met anti-feed dan met de max discharge limit ontladen...

Dankje!

Ja, dat kan! In home assistant "gebruikers modus optie" op anti_feed zetten. Je gebruikt niet toevallig de maximale levering op dat moment? Ik merk wel dat hij even nodig heeft om het juiste vermogen te vinden. Schommelt een paar keer en schakelt verschillende accus in en uit, maar uiteindelijk NOM.

[cold]

savale schreef op vrijdag 5 december 2025 @ 09:20:
[...]


Wel een te gekke opstelling heb je hoor!
CT aanpassen via modbus heb ik ook niet gezien in de viper implementatie... Heb NOM werkend met de b2500 shellpro3em emulator. (haalt info uit home assistant).
Enige wat ik niet helemaal voor elkaar krijg: stel ik forceer laden / ontladen via modbus en ik wil dan weer naar marstek NOM mode: kan dat? Hier gaat met anti-feed dan met de max discharge limit ontladen...

mijn default mode is de NOM, deze is dus ingeschakeld als de RS458 control mode uit staat.
als ik geen NOM wil omdat er bv geen teruglevering is en de accu heeft de minimale lading waar ik hem op wil houden
dan zet ik de RS458 control mode op Aan en de Force mode staat dan standaard op Standby.
Als de Force mode op charge of discharge staat gaat die (in RS845 control mode aan) laden of ontladen met de ingestelde max waarde.
Als de RS458 control mode dan weer uit gaat gaat de accu terug in NOM

[comfix]

Weet iemand hoe het aan te pakken om via modbus 2 batterijen uit te lezen?
Ik heb de nieuwe er ook op aangesloten, ik zie dat de data telkens swappen en dus moet ik op een of andere manier de nieuwe batterij een ander slave ID geven. Ik las dat iemand dat heeft kunnen doen, maar ik heb dit niet gevonden hoe.

[pascallj]

cthings schreef op donderdag 4 december 2025 @ 23:09:
Ik gebruik al een tijdje met veel plezier de lilygo RS485 met de spullies van Superduper1969 gekoppeld aan mijn HA. Het valt me wel op dat wanneer ik een automation gebruik, of bijv via de HA Rest API settings van de Marstek verander, het zo'n 15 sec duurt voordat de Marstek de wijziging oppakt. Is dat alleen bij mij zo?
Zijn er manieren om de responsetijd omhoog te krijgen? Ik heb ook een Sessy en daarbij is de reactie enkele seconden. Ik heb dan ook het idee dat het niet aan de HA ligt, maar weet niet zo goed waar ik het wel moet zoeken.

De batterij zelf kan snel genoeg reageren, het is alleen de API die te instabiel om snel te kunnen reageren. Ik denk eerlijk gezegd dat je al blij mag zijn als je stabiel en betrouwbaar de 15 seconde kan halen.

Als je bijvoorbeeld stuurt via Modbus, zie je dat de wijzigingen direct zijn.

[pascallj]

RefleXion schreef op vrijdag 5 december 2025 @ 08:08:
[...]

Ik kan de accu's nu grotendeels via modbus aansturen en uitlezen, maar weet iemand of het ook mogelijk is de CT instellingen van de accu via modbus aan te passen? Ik zie het in de integratie in ieder geval niet terug.

Nee dat zit er helaas niet in.

[pascallj]

comfix schreef op vrijdag 5 december 2025 @ 10:18:
Weet iemand hoe het aan te pakken om via modbus 2 batterijen uit te lezen?
Ik heb de nieuwe er ook op aangesloten, ik zie dat de data telkens swappen en dus moet ik op een of andere manier de nieuwe batterij een ander slave ID geven. Ik las dat iemand dat heeft kunnen doen, maar ik heb dit niet gevonden hoe.

Via Modbus adres 41100 (op de V1&2, weet niet waar het zit op de V3) kan je het slave id wijzigen. Dit zal je moeten doen als er slechts die ene batterij is aangesloten. Daarna zal je in die configuratie alles moeten dupliceren (en dus ook de naam/is veranderen), maar dan met uitvragen op adres 2.

[savale]

Nu trouwens de @superduper1969 integratie gepakt voor mijn v3 firmware v139 (lilygo-rs485-3.yaml)

Die werkt wel heel fijn zeg! Net even wat betere response / overzichtelijker dan de Viper versie voor mij.
Nu is de auto even aan het opladen, maar daarna nog even een keer de NOM testen met de b2500 emulator.

[ Voor 198% gewijzigd door savale op 05-12-2025 15:25 ]

[corsat]

AUijtdehaag schreef op vrijdag 5 december 2025 @ 06:02:
[...]

En de youless geeft 1 p1 waarde zowel
positief als negatief of 2 getallen?

Ik heb geen glazen bol he?

Dat is het verschil tussen bovenste gedeelte vd code en onderste
De bovenste doet een berekening tussen twee waarden

De youless power geeft zowel positief als negatieve waarde. Als ik het bovenste deel weghaal krijg ik gelijk 8 error meldingen in de yaml.

[pascallj]

savale schreef op vrijdag 5 december 2025 @ 14:08:
Nu trouwens de @superduper1969 integratie gepakt voor mijn v3 firmware v139 (lilygo-rs485-3.yaml)

Die werkt wel heel fijn zeg! Net even wat betere response / overzichtelijker dan de Viper versie voor mij.
Nu is de auto even aan het opladen, maar daarna nog even een keer de NOM testen met de b2500 emulator.

Die '3' is niet speciaal bedoeld voor de V3, maar is eigenlijk een versie voor de V1&2 maar dan voor batterij nummer 3. Tenzij dat ondertussen anders is... Dus niet alle waardes zitten er waarschijnlijk in.

[AUijtdehaag]

@savale
Ik zou deze v3 nemen
https://github.com/fonske...b/main/lilygo_mt1_v3.yaml

en daarna met deze aan de gang
https://github.com/gitcodebob/marstek-venus-rs485-node-red

[ Voor 29% gewijzigd door AUijtdehaag op 05-12-2025 15:37 ]

[AUijtdehaag]

corsat schreef op vrijdag 5 december 2025 @ 15:24:
[...]

De youless power geeft zowel positief als negatieve waarde. Als ik het bovenste deel weghaal krijg ik gelijk 8 error meldingen in de yaml.

En welke entitties zijn dat? Dan pas ik de code "eenmalig" even aan

[MchlLyn]

Bedankt @[RNMC] Viper voor https://github.com/ViperRNMC/marstek_venus_modbus
Werkt helemaal top! Wilde je alleen pingen om dankjewel te zeggen, hoop tot dat OK is 😊. De HA integratie werkte direct.

Ik heb overigens de Elfin EE11 gekozen, de bedrade variant, en die werkt helemaal prima met de config zoals beschreven voor de EW11! (Ik prefereer altijd bedraad). Bij Ali gekocht:
https://nl.aliexpress.com...2e13&gatewayAdapt=glo2nld

[ro3lie]

Ik loop tegen het volgende, alles correct aangesloten maar geen spanning.
Iemand een idee?

[jj85]

Even een dikke voor dit topic en @AUijtdehaag z'n beschrijving, in een klein half uurtje een M5stack RS485 base + Atom S3 lite draaiende op m'n Venus 3. Dank!

[pascallj]

ro3lie schreef op vrijdag 5 december 2025 @ 16:58:
Ik loop tegen het volgende, alles correct aangesloten maar geen spanning.
Iemand een idee?

[Afbeelding]

Je hebt hem wel in de Modbus aansluiting en niet in de Ethernet aansluiting gedaan?

[jj85]

ro3lie schreef op vrijdag 5 december 2025 @ 16:58:
Ik loop tegen het volgende, alles correct aangesloten maar geen spanning.
Iemand een idee?

[Afbeelding]

Wel in de goede poort gedrukt? Ik moest 3x goed kijken wat nou de ethernet en modbus poort was.
Meet je ook geen spanning op de + en -. Of kun je de bovensteconnector losgekoppeld doormeten?

[ro3lie]

De netwerkkabel zit al in de netwerkpoort met actieve verbinding.
Deze kabel in de MODBUS poort gezet, echter gaat die niet aan.
Multimeter toont wel 5V op de +/- van de Lilygo, dus daar ligt het ook niet aan.

Zou het nog iets in de configuratie kunnen zitten van de Marstek of Lily?

[pascallj]

ro3lie schreef op vrijdag 5 december 2025 @ 17:30:
De netwerkkabel zit al in de netwerkpoort met actieve verbinding.
Deze kabel in de MODBUS poort gezet, echter gaat die niet aan.
Multimeter toont wel 5V op de +/- van de Lilygo, dus daar ligt het ook niet aan.

Zou het nog iets in de configuratie kunnen zitten van de Marstek of Lily?

Dan heb je dus wel spanning? Zitten er geen lampjes op dat apparaat om aan te geven dat die aanstaat? De configuratie doet niets met de stroomvoorziening.

[AUijtdehaag]

Is die al wel geflashed?
Anders misschien ook geen lampjes

[ro3lie]

pascallj schreef op vrijdag 5 december 2025 @ 17:32:
[...]

Dan heb je dus wel spanning? Zitten er geen lampjes op dat apparaat om aan te geven dat die aanstaat? De configuratie doet niets met de stroomvoorziening.

Ik zie de Lilygo niet aangaan qua LEDs of online komen in het netwerk.

Wat ik bedoel met configuratie is bijvoorbeeld:

# Set pins required for LilyGo T-CAN485 board
output:
- platform: gpio
id: ENABLE_5V_PIN # Enable 5V pin for RS485 chip
pin:
number: GPIO16
inverted: true

AUijtdehaag schreef op vrijdag 5 december 2025 @ 17:33:
Is die al wel geflashed?
Anders misschien ook geen lampjes

Ja, conform de stappen in de post + https://github.com/fonske...b/main/lilygo_mt1_v3.yaml

Komt ook keurig online in HomeAssistant als deze aan USB-C hangt.

[ Voor 23% gewijzigd door ro3lie op 05-12-2025 17:34 ]

[pascallj]

ro3lie schreef op vrijdag 5 december 2025 @ 17:33:
[...]


Ik zie de Lilygo niet aangaan qua LEDs of online komen in het netwerk.

Wat ik bedoel met configuratie is bijvoorbeeld:

# Set pins required for LilyGo T-CAN485 board
output:
- platform: gpio
id: ENABLE_5V_PIN # Enable 5V pin for RS485 chip
pin:
number: GPIO16
inverted: true


[...]


Ja, conform de stappen in de post + https://github.com/fonske...b/main/lilygo_mt1_v3.yaml

Komt ook keurig online in HomeAssistant als deze aan USB-C hangt.

En spanning klopt ook en is niet toevallig omgedraaid?

Dat gedeelte van die RS485 chip slaat alleen op de RS485 chip. Als hij via USB wel in HA komt, en nu niet, zit het probleem dus ergens anders.

[ Voor 9% gewijzigd door pascallj op 05-12-2025 17:38 ]

[AUijtdehaag]

@ro3lie
Toevallig niet dit issue?
savale in "Marstek Venus / Duravolt PnP Thuisaccu Modbus koppeling"

[ro3lie]

Omgedraaid ook geen effect, heb 2 batterijen en op beide pakt die hem niet (zowel batterij aan als herstarten). Ondanks dat ik spanning krijg op de kabel ga ik deze nu toch vervangen..

Edit.
Kabel vervangen, geen verschil. Lilygo gaat niet aan op de modbus poort met beide batterijen (V3 - v144)

[ Voor 80% gewijzigd door ro3lie op 05-12-2025 18:06 ]

[pascallj]

ro3lie schreef op vrijdag 5 december 2025 @ 17:53:
Omgedraaid ook geen effect, heb 2 batterijen en op beide pakt die hem niet (zowel batterij aan als herstarten). Ondanks dat ik spanning krijg op de kabel ga ik deze nu toch vervangen..

Edit.
Kabel vervangen, geen verschil. Lilygo gaat niet aan op de modbus poort met beide batterijen (V3 - v144)

[Afbeelding]

[Afbeelding]

En wat nu als je eens een externe 5V USB voeding probeert op die +/- aansluiting?

[ro3lie]

pascallj schreef op vrijdag 5 december 2025 @ 18:10:
[...]


En wat nu als je eens een externe 5V USB voeding probeert op die +/- aansluiting?

Zojuist met USB-C erbij en dan gaat die aan.


Ik heb nog een 2e Lilygo, die maak ik morgen klaar. Kijken of die het wel doet zonder externe voeding.

[pascallj]

ro3lie schreef op vrijdag 5 december 2025 @ 18:39:
[...]


Zojuist met USB-C erbij en dan gaat die aan.
[Afbeelding]

Ik heb nog een 2e Lilygo, die maak ik morgen klaar. Kijken of die het wel doet zonder externe voeding.

Dat snap ik, ik bedoelde even een andere voeding van 5V die niet uit de batterij komt op de + en - aansluiten. Dus niet voeden van de USB en ook niet uit de batterij. Puur om te kijken of het aan de batterij ligt, of dat gedeelte van het PCB van de LilyGo.

Je kan bv even een oude USB kabel doorknippen, draden strippen, aansluiten op een powerbank, even meten welke draden + en - zijn. Dan heb je een alternatieve 5V voeding.

[pascallj]

Zojuist nog een kleine ontdekking gedaan met een niche usecase die sommigen misschien toch interessant vinden.

Na wat testen blijkt dat zelfs met de stekker in het stopcontact, als je de batterij uitzet, er toch wat functies in slaapstand gaan. De WiFi blijft gek genoeg verbonden, maar de lampjes en Bluetooth gaan uit en het is duidelijk meetbaar dat de batterij bijna niet leeg loopt (zie ook deze post: pascallj in "Hame / Marstek / Duravolt 5,12kWh plug en play thuisaccu").

Normaal betekent het dat als je de Modbus hebt aangesloten, de batterij vanzelf weer aangaat (mits je deze voedt met een externe voeding, anders valt ook je ESP/Modbus apparaat uit). Maar dit is dus alleen als je pakketten uitvraagt op het adres van de batterij. Als je stopt met berichten sturen naar de batterij, zal hij uitblijven totdat je een request doet naar specifiek dat adres. Andere berichten op het Modbus netwerk naar andere adressen zullen ook genegeerd worden.

Ik heb nu dus een schakelaar gemaakt in ESPHome die het uitvragen van de Marstek pauzeert (door de controller component te pauzeren), hierna kan je met de hand de batterij uitschakelen met de drukknop aan de zijkant (kost soms een paar pogingen om te zorgen dat die echt uit blijft, timing is heel precies). De batterij blijft nu in slaapstand, totdat je de schakelaar in ESPHome weer aan zet waarna de batterij vanzelf weer aanschiet. Helaas is er geen mogelijkheid dat wij weten om via Modbus de batterij in slaapstand te zetten.

YAML:

switch:
  - platform: template
    name: "${device_name}Enable device"
    optimistic: true
    restore_mode: ALWAYS_ON
    turn_off_action:
      - component.suspend: marstek_modbus_controller
    turn_on_action:
      - component.resume: marstek_modbus_controller

Ja kan het natuurlijk ook anders noemen, bijvoorbeeld 'Pause Requests' en de acties omdraaien.

Als je bijvoorbeeld de batterij gebruikt om te handelen kan het een functie hebben om de batterij uit te schakelen als er toch weinig gebeurt in de prijzen, maar kan je de batterij wel vanaf afstand weer aanzetten.

[ro3lie]

Morgen test ik het met een externe voeding op de Lilygo. Mogelijk heeft bovenstaand ook hier betrekking op de situatie, de accu is al een tijdje volledig leeg.

[SatScan]

ro3lie schreef op vrijdag 5 december 2025 @ 18:51:
Morgen test ik het met een externe voeding op de Lilygo. Mogelijk heeft bovenstaand ook hier betrekking op de situatie, de accu is al een tijdje volledig leeg.

Zoek eens in het topic en zijn schijnbaar ook lilygo exemplaren die net te weinig spanning generen/omzetten om zonder externe voeding te werken. Ik weet het fijne er niet van maar las hier zoiets aantal maanden geleden.

[Michiel95]

V3 vandaag binnengekregen en meteen aan de slag gegaan

1) LilyGo geclasht met volgende config --> https://github.com/fonske...b/main/lilygo_mt1_v3.yaml
2) Aangesloten via UTP zoals aangegeven op de foto in de topicstarter
3) ESPHome discovery in HA toegevoegd
4) Volgende package aangepast naargelang mijn entiteitsnaam in HA en geüpload in HomeAssistant zoals omschreven in topicstarter --> https://github.com/fonske...enus_battery_control.yaml

---------

Alles werkt en ik kan de juiste entiteiten toevoegen aan het Energie dashboard in HomeAssistant.

Maar... ik wil nu de LilyGo/Marstek toevoegen in EVCC maar krijg volgende error:

dial tcp 192.168.0.88:502: connect: connection refused

Volgens ChatGPT (en ook een eerder bericht hier op het forum) wellicht iets te maken met een 'Bridge'/Andere registers. Echter... ik ben niet meer goed mee wat ik nu precies moet doen. Iemand die mij wat kan bijstaan in wat ik nu precies moet doen om het zowel in HomeAssistant (Feitelijk enkel nood aan de discharging/charging entities voor het energie dashboard) alsook EVCC (Vermijden dat de EV stroom gaat trekken uit de batterij) werkende te krijgen?

Alvast bedankt!

[pascallj]

Michiel95 schreef op vrijdag 5 december 2025 @ 22:19:
V3 vandaag binnengekregen en meteen aan de slag gegaan

1) LilyGo geclasht met volgende config --> https://github.com/fonske...b/main/lilygo_mt1_v3.yaml
2) Aangesloten via UTP zoals aangegeven op de foto in de topicstarter
3) ESPHome discovery in HA toegevoegd
4) Volgende package aangepast naargelang mijn entiteitsnaam in HA en geüpload in HomeAssistant zoals omschreven in topicstarter --> https://github.com/fonske...enus_battery_control.yaml

---------

Alles werkt en ik kan de juiste entiteiten toevoegen aan het Energie dashboard in HomeAssistant.

Maar... ik wil nu de LilyGo/Marstek toevoegen in EVCC maar krijg volgende error:

dial tcp 192.168.0.88:502: connect: connection refused

Volgens ChatGPT (en ook een eerder bericht hier op het forum) wellicht iets te maken met een 'Bridge'/Andere registers. Echter... ik ben niet meer goed mee wat ik nu precies moet doen. Iemand die mij wat kan bijstaan in wat ik nu precies moet doen om het zowel in HomeAssistant (Feitelijk enkel nood aan de discharging/charging entities voor het energie dashboard) alsook EVCC (Vermijden dat de EV stroom gaat trekken uit de batterij) werkende te krijgen?

Alvast bedankt!

Zoals in mijn vorige bericht: pascallj in "Marstek Venus / Duravolt PnP Thuisaccu Modbus koppeling"

Je kunt een 'standaard' ESPHome configuratie niet toevoegen binnen EVCC. Dit werkt alleen binnen HA want het praat een heel ander protocol specifiek gemaakt voor HA.

Als je de LilyGo binnen EVCC wil gebruiken zal je hem moeten flashen als Modbus TCP bridge. Want binnen EVCC schijnt er ondersteuning te zijn voor de Marstek via Modbus TCP. Maar de Marstek praat zelf geen Modbus TCP dus kan je je LilyGo inzetten als Modbus TCP naar Modbus RTU adapter.

Ik heb het zelf nog nooit gebruikt, maar in de TS staat deze configuratie:

https://github.com/fonske...5_tcp_ip_bridge_only.yaml

Deze voegt een custom component toe aan ESPHome waardoor je ESPHome kan laten werken als Modbus TCP bridge.

Maar ik heb geen idee of dat zo klaar is voor gebruik of dat er dingen aangepast moeten worden.

[savale]

ahh bedankt voor de tips @pascallj @AUijtdehaag. Die van Fonske kan ik ook zonder node red gebruiken? (in eerste instantie)
Hier nog wat geks met de "self consumption" mode / "anti-feed". De accu wil somehow niet naar NOM, maar blijft op "max discharge" terugleveren. Iemand enig idee?

[pascallj]

savale schreef op vrijdag 5 december 2025 @ 22:36:
ahh bedankt voor de tips @pascallj @AUijtdehaag. Die van Fonske kan ik ook zonder node red gebruiken? (in eerste instantie)
Hier nog wat geks met de "self consumption" mode / "anti-feed". De accu wil somehow niet naar NOM, maar blijft op "max discharge" terugleveren. Iemand enig idee?

[Afbeelding]

Weet je zeker dat die modus aanstaat? En zo ja, hoe is je verbinding met de CT? Niet toevallig nog RS485 Control aan?

[savale]

ro3lie schreef op vrijdag 5 december 2025 @ 17:33:
[...]


Ik zie de Lilygo niet aangaan qua LEDs of online komen in het netwerk.

Wat ik bedoel met configuratie is bijvoorbeeld:

# Set pins required for LilyGo T-CAN485 board
output:
- platform: gpio
id: ENABLE_5V_PIN # Enable 5V pin for RS485 chip
pin:
number: GPIO16
inverted: true


[...]


Ja, conform de stappen in de post + https://github.com/fonske...b/main/lilygo_mt1_v3.yaml

Komt ook keurig online in HomeAssistant als deze aan USB-C hangt.

Hier wil dat ook niet lekker. Probleem is toch de stroom piekjes van WiFi vermoed ik. Bij mij helpt het om ook de wit/bruin erbij te pakken en de wit/blauw. Op die manier heb je minder spanningsval en werkt het hier wel. Verder zet ik ook de TX power van de Wifi wat lager in esphome en ook de CPU clock naar 80MHz....

[savale]

pascallj schreef op vrijdag 5 december 2025 @ 22:43:
[...]


Weet je zeker dat die modus aanstaat? En zo ja, hoe is je verbinding met de CT? Niet toevallig nog RS485 Control aan?

modbus control staat uit in home assistant. In de app staat ie zo:


CT is een shelly pro 3 em emulatie (b2500). Die komt wel netjes binnen lijkt het... Maar wellicht toch nog iets mis?

[ Voor 8% gewijzigd door savale op 05-12-2025 23:21 ]

[AUijtdehaag]

@Michiel95
Ipv evcc kun je ook de nodered flow gebruiken
Daar zit ook de functie voor het blokkeren van marstek ontladen bij laden EV dmv een HA entity helper “EV laden”

https://github.com/gitcod...main/RELEASE_NOTES.md#310

Sinds enkele dagen draait hier ook het opladen op zonneplan dynamisch van de marstek batterijen dmv cheapest hours code van TheFes

[ Voor 20% gewijzigd door AUijtdehaag op 06-12-2025 08:51 ]

[AUijtdehaag]

Ik heb de m5stack en de lilygo esphome code voor de v3 geupdate.
Er miste nog 2 entities:
https://github.com/fonske...rs485_v3.yaml#L1483-L1517
https://github.com/fonske...o_mt1_v3.yaml#L1463-L1497

En een beetje beter geordend in de code.
Mocht je nog iets tegenkomen dan hoor ik het graag.

[ Voor 7% gewijzigd door AUijtdehaag op 06-12-2025 14:23 ]

[Michiel95]

AUijtdehaag schreef op zaterdag 6 december 2025 @ 08:32:
@Michiel95
Ipv evcc kun je ook de nodered flow gebruiken
Daar zit ook de functie voor het blokkeren van marstek ontladen bij laden EV dmv een HA entity helper “EV laden”

https://github.com/gitcod...main/RELEASE_NOTES.md#310

Sinds enkele dagen draait hier ook het opladen op zonneplan dynamisch van de marstek batterijen dmv cheapest hours code van TheFes

Dankje voor de feedback, al zou ik het toch liefst in EVCC hebben zodoende ik maar 1 platform heb. Vanochtend al wat liggen klooien met een bridge yaml maar voorlopig helaas weinig succes, heb de niet-bridge config teruggezet en wacht wel even tot er iemand anders met meer kennis van ook hetzelfde wilt bereiken

[AUijtdehaag]

@Michiel95
Je kan de m5stack modbus tcp bridge code die @pascallj linkte niet klakkeloos op de lilygo zetten
die is enkel voor de m5stack gemaakt.
M5stack is een esp32s3 en lilygo een esp32.
Je dient dan het (esphome) hardware gedeelte te kopieeren uit de andere lilygo voorbeelden.

[Michiel95]

AUijtdehaag schreef op zaterdag 6 december 2025 @ 14:33:
@Michiel95
Je kan de m5stack modbus tcp bridge code die @pascallj linkte niet klakkeloos op de lilygo zetten
die is enkel voor de m5stack gemaakt.
M5stack is een esp32s3 en lilygo een esp32.
Je dient dan het (esphome) hardware gedeelte te kopieeren uit de andere lilygo voorbeelden.

Klopt, had ik ook gedaan, alsook de GPIO pinnetjes aangepast, maar EVCC kon er niet mee verbinden. Vanavond nog eens verder proberen, maar kan me moeilijk inbeelden dat ik de enigste ben met een lilygo die er een bridge van wilt maken?

[AUijtdehaag]

@Michiel95
Klopt de evcc.yaml ?
zie ook https://github.com/fonske...oeging-in-de-esphome-code

[ Voor 42% gewijzigd door AUijtdehaag op 06-12-2025 14:44 ]

[ro3lie]

savale schreef op vrijdag 5 december 2025 @ 22:46:
[...]

Hier wil dat ook niet lekker. Probleem is toch de stroom piekjes van WiFi vermoed ik. Bij mij helpt het om ook de wit/bruin erbij te pakken en de wit/blauw. Op die manier heb je minder spanningsval en werkt het hier wel. Verder zet ik ook de TX power van de Wifi wat lager in esphome en ook de CPU clock naar 80MHz....

HELD

Wit/bruin + wit/blauw gecombineerd en de CPU naar 80MHz en beide Lilygo's draaien nu!
Geen idee of het ook werkt zonder de 80MHz, dat is voor later..

Zojuist beide Lilygo's toegevoegd en hierin zie ik het volgende (Diagnostics)


Klopt het dat o.a. de volgende velden niet opgehaald kunnen worden met de V3 batterij?

Controls:
- Max. Charge Power
- Max. Discharge Power

Check: Klopt het dat ik deze zelf in moet stellen op 2500W? Kortom dit neemt die niet over uit de app?

Diagnostics:
- Firmware version - unknown
- Software version - unknown

Check: Kan hij deze niet uit lezen met de Marstek v3.yaml?

Control Mode: Anti-feed
Deze staat in de app op 'AI', als ik deze via HA op 'AI' zet schiet deze terug..

[savale]

pascallj schreef op vrijdag 5 december 2025 @ 22:43:
[...]


Weet je zeker dat die modus aanstaat? En zo ja, hoe is je verbinding met de CT? Niet toevallig nog RS485 Control aan?

Probleem zo ongeveer opgelost: de shelly emulator deed nog niks met de production waardes. Nu werkt dat wel. Je ziet dat de marstek reageert op de phase C waardes in dit geval. De marstek NOM bakt er echter nog niks van, maar dat komt waarschijnlijk door mijn trage p1 updates. (10 seconden) Dat wordt binnenkort verholpen door een andere meter. Nu heb ik dit:

[Michiel95]

AUijtdehaag schreef op zaterdag 6 december 2025 @ 14:43:
@Michiel95
Klopt de evcc.yaml ?
zie ook https://github.com/fonske...oeging-in-de-esphome-code

Het is uiteindelijk gelukt! Ik heb deze YAML van Fonske door ChatGPT laten herschrijven voor een ESP32 en hij heeft er wat van gemaakt wat lijkt te werken!

Vervolgens deze integratie van ViperRNMC gebruikt om ook terug marstek entiteiten in HomeAssistant te hebben voor het 'Energie' dashboard mooi aan te vullen.

[ro3lie]

Michiel95 schreef op zaterdag 6 december 2025 @ 19:49:
[...]


Het is uiteindelijk gelukt! Ik heb deze YAML van Fonske door ChatGPT laten herschrijven voor een ESP32 en hij heeft er wat van gemaakt wat lijkt te werken!

Vervolgens deze integratie van ViperRNMC gebruikt om ook terug marstek entiteiten in HomeAssistant te hebben voor het 'Energie' dashboard mooi aan te vullen.

Dus jouw yaml werkt in HA en EVCC?

[AUijtdehaag]

@ro3lie
Welke registers voor de v3 niet werken staat hier
https://github.com/ViperR...le#-modbus-registers-used

Ik heb dit ook in de esphome lilygo code reeds verwerkt

Voor de nodered flow van @GAEvakYD en zijn collega bob zijn 2 registers belangrijk die (nu?) niet uitgelezen kunnen worden voor de v3:
charging_cutoff_capacity
discharging_cutoff_capacity

Echter kunnen die ook wel door HA helpers vervangen worden. (zijn entities die eenmaal worden ingesteld)

evcc.io heb ik uitgeprobeerd maar voor mij veel te beperkt. Terwijl de nodered flow wel doet wat ik wil
Dynamisch jontrakt en diverse strategien om uit te kiezen

[ Voor 73% gewijzigd door AUijtdehaag op 06-12-2025 23:02 ]

[savale]

@AUijtdehaag draai nu deze van jou:
https://github.com/fonske...b/main/lilygo_mt1_v3.yaml
Lijkt wel helemaal perfect / compleet voor de venus 3 v139. Bedankt!

[corsat]

AUijtdehaag schreef op vrijdag 5 december 2025 @ 15:40:
[...]

En welke entitties zijn dat? Dan pas ik de code "eenmalig" even aan

Ik heb nu onderstaande ingevoerd maar dat werkt niet. De entiteit is mijn youless sensor die owel positief als negatief meet. Ik zie nu geen foutmeldingen meer staan maar krijg het niet werkend.

# It should be included in the main configuration.yaml file as a `package` via `!include_dir_named` https://www.home-assistant.io/docs/configuration/packages/.
# Use the values below as a `template` for your specific needs
# This file contains config for Home Assistant unique to your installation and should not be overwritten with each update of House Battery Control

template:
- sensor:
# Example: sensor for single-phase power meter

# House battery control | Grid power
# Your P1 meter indicates the power drawn or returned to grid.
# This "P1 meter power" sensor acts as an alias for you power sensing configuration and is used throughout the node-RED scripts.
- name: "Grid Power"
unique_id: "p1_meter_power"
state: "{{ states('sensor.energiemeter_huidig_stroomverbruik_2') }}" # << SET YOUR GRID POWER SENSOR HERE
unit_of_measurement: "W"
device_class: "power"
state_class: "measurement"

[AUijtdehaag]

@corsat
Voor de juiste waarde met de youless:
Bij 1 entity (voor zowel positief als negatief) deze gebruiken:

YAML:

template:
  - sensor:
      # House battery control | Grid power
      # Your P1 meter indicates the power drawn or returned to grid.
      # This "P1 meter power" sensor acts as an alias for you power sensing configuration and is used throughout the node-RED scripts.
      - name: "p1 meter power"
        unique_id: "p1_meter_power"
        state: "{{ states('sensor.energiemeter_huidig_stroomverbruik_2') }}" # << SET YOUR GRID POWER SENSOR HERE
        unit_of_measurement: "W"
        device_class: "power"
        state_class: "measurement"

Bij 2 entities (positief en negatief) deze gebruiken

YAML:

template:
  - sensor:
      # Example: sensor for P1 power meter with separate consumption and production sensor
      - name: "p1 meter power"
        unique_id: "p1_meter_power"
        unit_of_measurement: "W"
        device_class: "power"
        state_class: "measurement"
        state: >
          {% set consumption = states('sensor.energiemeter_huidig_stroomverbruik_2') | float(0) %}
          {% set production = states('sensor.energiemeter_huidig_stroomopwek_2') | float(0) %}
          {{ (consumption - production) | round(2) }}

En home assistant volledig herstarten

[BjornVanc]

Is er iemand die de CT-003 in HA kan inlezen?

[pascallj]

AUijtdehaag schreef op zaterdag 6 december 2025 @ 22:56:
@ro3lie
Welke registers voor de v3 niet werken staat hier
https://github.com/ViperR...le#-modbus-registers-used

Ik heb dit ook in de esphome lilygo code reeds verwerkt

Voor de nodered flow van @GAEvakYD en zijn collega bob zijn 2 registers belangrijk die (nu?) niet uitgelezen kunnen worden voor de v3:
charging_cutoff_capacity
discharging_cutoff_capacity

Echter kunnen die ook wel door HA helpers vervangen worden. (zijn entities die eenmaal worden ingesteld)

evcc.io heb ik uitgeprobeerd maar voor mij veel te beperkt. Terwijl de nodered flow wel doet wat ik wil
Dynamisch jontrakt en diverse strategien om uit te kiezen

Die cutoff registers voor de V3 heb jij toch laatst toegevoegd aan je configuratie?

[AUijtdehaag]

@pascallj
Klopt. Maar ze geven modbus errors op de v3 en werken niet. (Heb terugkoppeling gehad)
Zie ook tabel van viper enkele posts terug
(44000 en 44001)

Er staat weer een nieuwe video online.
Mijn batterijen laden en ontladen nu dynamisch mede dankzij de integratie cheapest energy hours van @TheFes

Bedankt voor het vele werk @GAEvakYD en natuurlijk zijn collega Bob.

[ Voor 62% gewijzigd door AUijtdehaag op 07-12-2025 19:23 ]

[corsat]

AUijtdehaag schreef op zondag 7 december 2025 @ 10:24:
@corsat
Voor de juiste waarde met de youless:
Bij 1 entity (voor zowel positief als negatief) deze gebruiken:

YAML:

template:
  - sensor:
      # House battery control | Grid power
      # Your P1 meter indicates the power drawn or returned to grid.
      # This "P1 meter power" sensor acts as an alias for you power sensing configuration and is used throughout the node-RED scripts.
      - name: "p1 meter power"
        unique_id: "p1_meter_power"
        state: "{{ states('sensor.energiemeter_huidig_stroomverbruik_2') }}" # << SET YOUR GRID POWER SENSOR HERE
        unit_of_measurement: "W"
        device_class: "power"
        state_class: "measurement"

Bij 2 entities (positief en negatief) deze gebruiken

YAML:

template:
  - sensor:
      # Example: sensor for P1 power meter with separate consumption and production sensor
      - name: "p1 meter power"
        unique_id: "p1_meter_power"
        unit_of_measurement: "W"
        device_class: "power"
        state_class: "measurement"
        state: >
          {% set consumption = states('sensor.energiemeter_huidig_stroomverbruik_2') | float(0) %}
          {% set production = states('sensor.energiemeter_huidig_stroomopwek_2') | float(0) %}
          {{ (consumption - production) | round(2) }}

En home assistant volledig herstarten

Ik heb 1 meter die zowel positief als negatief aanwijs, bovenstaande code ingevoerd maar helaas mijn HA voor de marstek batterijen start niet op met deze power meter. Heb uiteraard HA opnieuw opgestart. Heb ook ipv mijn youless mijn Shelly 3 fasen meter ingevoerd maar hetzelfde issue, ik krijg geen groen licht in mijn dashboard voor mijn marstek batterijen. Mijn entiteit is power en staat ook al in Watt.

[comfix]

pascallj schreef op vrijdag 5 december 2025 @ 12:20:
[...]


Via Modbus adres 41100 (op de V1&2, weet niet waar het zit op de V3) kan je het slave id wijzigen. Dit zal je moeten doen als er slechts die ene batterij is aangesloten. Daarna zal je in die configuratie alles moeten dupliceren (en dus ook de naam/is veranderen), maar dan met uitvragen op adres 2.

Het is ondertussen gelukt om via Home Assistant - Modbus, een write te doen naar de 2de batterij (enkel deze aangesloten op de modbus) en dus het slave adres naar 2 te veranderen.

[edsub]

edsub schreef op donderdag 20 november 2025 @ 08:57:
[...]

Dat is inderdaad een optie. Ik heb al gekeken of ik de power-waardes uit mn P1 in een modbus register kan zetten, maar die optie is er volgens mij niet (ook Marstek support gevraagd, maar benieuwd of daar wat anders vandaan komt.
Dan blijft inderdaad zelf NOM regelen over modbus over. Zal ook eens zoeke of iemand anders dat ook al heeft gerealiseerd.

Ik heb inmiddels een werkend NOM script in Python3. (Zal dat eerdaags op Github zetten).
*MAAR*
Ik heb twee Marstek Venus E v1 op verschillende lokaties. 1 thuis met firmware v1.56 (vorige week ge-update vanaf v1.53) en 1 remote met firmware v1.53.
Het probleem met de disconnected wifi heb ik met die remote accu (firmware update voorlopig dus uitgesloten daar).
Het scriptvheb ik gebouwd tegen/getest met de Marstek thuis.
Toen ik aan t script begon hadden beide accus nog v1.53 en zag ik dat mijn script de huidige ac power waarde niet kon lezen. Nu moet ik erbij zeggen dat ik naast dit NOM script ook een script heb lopen dat iedere 5 sec de Marstek status registers naar Domoticz stuurt. Het leek erop dat er geen concurrent toegang tot de modbus registers mogelijk was.
Dit weekend (firmware v1.56) had ik dat probleem niet meer en kon ik het NOM script afmaken.
Gisteren het NOM script getest tegen de remote Marstek (v1.53). En wéér dat concurrency probleem.
Bij uitschakelen van mijn Domoticz updateproces bleef het NOM proces lopen zolang slechts 1 thread (lezen huidige ac power) de Marstek benadert. Zodra de 2e thread ook toegang wil (schrijven registers) of als ik mijn Domoticz updateproces weer start klapt het NOM proces eruit met melding dat hij een register niet kan lezen of schrijven (ja ik weet dat ik rs485 controlmode moet aanzetten)

Verschil tussen beide Marsteks is dus de firmware (v1.56 vs v1.53). Ook is er een klein (?) firmware verschil russen de Modbus RTU-TCP converter die ik gebruik (USR-DR134). Heb n vraag bij USR uitgezet.

Iemand ook gemerkt dat concurrent toegang (door twee separate processen of threads dus) tot Modbus met firmware v1.53 een probleem is en bij v1.56 niet meer?

[ Voor 3% gewijzigd door edsub op 08-12-2025 07:17 ]

[superduper1969]

BjornVanc schreef op zondag 7 december 2025 @ 15:29:
Is er iemand die de CT-003 in HA kan inlezen?

Staat in de TS

HA integratie voor CT002/CT003:
https://github.com/d-shmt/hass_marstek-smart-meter
Dan kun je ook over langere tijd de Wifi Signaalsterkte monitoren.

[Tazzios]

Nieuwe versie van Marstek X Range OM Blueprint voor lilygo met ESPhome code van Superduper1969

Version: 1.6
Improved: less modbus updates
fix: Rewrite, keep SOC`s within 10% of each other
New: Debugging shown in trace

Ik kwam er vorige maand achter dat de fork van @AUijtdehaag ook vrijveel gebruikt lijkt te worden. Of die ook werkt met deze blueprint heb ik nog niet getest. Indien de gebruikte entiteiten in de blueprint dezelfde naam hebben zou het moeten werken.
Is er veel verschillen tussen/ wat is het verschil? In de github omschrijving staat geen uitleg. Alleen lilygo_mt1_v3.yaml lijkt nieuw te zijn?

[ Voor 30% gewijzigd door Tazzios op 08-12-2025 15:09 ]

[superduper1969]

Tazzios schreef op maandag 8 december 2025 @ 15:09:
Nieuwe versie van Marstek X Range OM Blueprint voor lilygo met ESPhome code van Superduper1969

Version: 1.6
Improved: less modbus updates
fix: Rewrite, keep SOC`s within 10% of each other
New: Debugging shown in trace

Ik kwam er vorige maand achter dat de fork van @AUijtdehaag ook vrijveel gebruikt lijkt te worden. Of die ook werkt met deze blueprint heb ik nog niet getest. Indien de gebruikte entiteiten in de blueprint dezelfde naam hebben zou het moeten werken.
Is er veel verschillen tussen/ wat is het verschil? In de github omschrijving staat geen uitleg. Alleen lilygo_mt1_v3.yaml lijkt nieuw te zijn?

Ik gebruik altijd https://kdiff3.sourceforge.net/ maar iedere AI kan je waarschijnlijk ook de verschillen vertellen als je ze upload.

[AUijtdehaag]

@Tazzios
Die MT1 - V3 code voor de lilygo is een afgeleide van de MT1- V3 code voor de M5stack.
(zie mijn andere github repository)

Omdat de entities in die benaming gebruikt wordt voor deze nodered flow kunnen mensen met een lilygo die ook gebruiken daarvoor
https://github.com/gitcodebob/marstek-venus-rs485-node-red

[ Voor 11% gewijzigd door AUijtdehaag op 08-12-2025 16:20 ]

[Tazzios]

Degene die ik in mijn blueprint gebruik zijn deze:
_rs485_control_mode
_forcible_charge_discharge
_ac_power
_forcible_charge_power
_forcible_discharge_power
_state_of_charge

Waarschijnlijk kan ik met een regex search op meerdere entities zoeken en ze zo beide tegelijk ondersteunen.

[edsub]

cthings schreef op donderdag 4 december 2025 @ 23:09:
Ik gebruik al een tijdje met veel plezier de lilygo RS485 met de spullies van Superduper1969 gekoppeld aan mijn HA. Het valt me wel op dat wanneer ik een automation gebruik, of bijv via de HA Rest API settings van de Marstek verander, het zo'n 15 sec duurt voordat de Marstek de wijziging oppakt. Is dat alleen bij mij zo?
Zijn er manieren om de responsetijd omhoog te krijgen? Ik heb ook een Sessy en daarbij is de reactie enkele seconden. Ik heb dan ook het idee dat het niet aan de HA ligt, maar weet niet zo goed waar ik het wel moet zoeken.

Bedoel je een register uitlezing of aanpassing via Modbus-RTU?
Dat gaat bij mij 'in no time'.
MAAR: Zodra je concurrent zaken wil doen (meerdere acties door elkaar hen vanuit verschillende processen of threads) zie ik ook enorm lange wachttijden en uiteindelijk crashes door (ik denk) time-outs. Welke firmware draai je op welke Marstek?
Dit probleem heb ik met firmware v1.53 maar niet met v1.56

Zie ook mijn post van vanochtend.

[pascallj]

edsub schreef op maandag 8 december 2025 @ 21:56:
[...]

Bedoel je een register uitlezing of aanpassing via Modbus-RTU?
Dat gaat bij mij 'in no time'.
MAAR: Zodra je concurrent zaken wil doen (meerdere acties door elkaar hen vanuit verschillende processen of threads) zie ik ook enorm lange wachttijden en uiteindelijk crashes door (ik denk) time-outs. Welke firmware draai je op welke Marstek?
Dit probleem heb ik met firmware v1.53 maar niet met v1.56

Zie ook mijn post van vanochtend.

Die post ging over de API en niet over Modbus.

Bij Modbus RTU is er normaal ook geen sprake van meerdere clients en doen de problemen zich niet voor. De Marstek is rap genoeg om het uitvragen te beantwoorden. De enige reden dat jij meerdere clients kan hebben, is vanwege de Modbus TCP bridge. Aangezien Modbus RTU normaal geen meerdere clients heeft en Modbus TCP wel, is het aan de bridge om daar een invulling aan te geven. Blijkbaar doet hij dat niet op manier wat jij verwacht. Ik zou eerst een proberen om de bridges om te draaien, want verwacht niet dat dit aan de firmware ligt.

Een robuustere manier zou zijn om gewoon alles 1 keer uit te vragen en op basis van die data meerdere automatiseringen of scripts aan te sturen ipv in elk script de data opnieuw uit te vragen.

[edsub]

pascallj schreef op maandag 8 december 2025 @ 22:17:
[...]


Die post ging over de API en niet over Modbus.

Bij Modbus RTU is er normaal ook geen sprake van meerdere clients en doen de problemen zich niet voor. De Marstek is rap genoeg om het uitvragen te beantwoorden. De enige reden dat jij meerdere clients kan hebben, is vanwege de Modbus TCP bridge. Aangezien Modbus RTU normaal geen meerdere clients heeft en Modbus TCP wel, is het aan de bridge om daar een invulling aan te geven. Blijkbaar doet hij dat niet op manier wat jij verwacht. Ik zou eerst een proberen om de bridges om te draaien, want verwacht niet dat dit aan de firmware ligt.

Een robuustere manier zou zijn om gewoon alles 1 keer uit te vragen en op basis van die data meerdere automatiseringen of scripts aan te sturen ipv in elk script de data opnieuw uit te vragen.

Mijn scripts zijn nu in de vorm van onafhankelijk lopende processen of threads.
Maar daarmee heb ik dus wel de situatie dat de requests van 2 processen tegelijk op de modbus kunnen komen.
Alles in 1 script zou kunnen, maar ik ben absoluut geen fan van dat soort monolieten.
Ik heb iig 1 USR-DR34 die eea voldoende afhandelt, ik ga dat eerst eens onderzoeken.

[lemuba]

Maybe someone in the Benelux region would like to test whether their Venus V3 is accessible via Modbus using the original LAN interface (not RS485). It’s possible that firmware version 144 is required. Source: Photovoltaik Forum.

Misschien wil iemand in de Benelux eens testen of zijn Venus V3 via Modbus bereikbaar is met de originele LAN-interface (dus niet via RS485). Mogelijk is hiervoor firmwareversie 144 nodig. Bron: Photovoltaik-forum.

https://www.photovoltaikf...v-modbus-tcp-aufgetaucht/

[cold]

lemuba schreef op dinsdag 9 december 2025 @ 07:32:
Maybe someone in the Benelux region would like to test whether their Venus V3 is accessible via Modbus using the original LAN interface (not RS485). It’s possible that firmware version 144 is required. Source: Photovoltaik Forum.

Misschien wil iemand in de Benelux eens testen of zijn Venus V3 via Modbus bereikbaar is met de originele LAN-interface (dus niet via RS485). Mogelijk is hiervoor firmwareversie 144 nodig. Bron: Photovoltaik-forum.

https://www.photovoltaikf...v-modbus-tcp-aufgetaucht/

Het werkt! bovenste is via de ElfinEW11 de ondersta via de normale bekabelde netwerk poort via de wifi zal ik zo ook even testen op de Wifi staat de poort 502 dicht en heb ik helaas geen modbus connectie

[ Voor 6% gewijzigd door cold op 09-12-2025 09:46 ]

[savale]

cold schreef op dinsdag 9 december 2025 @ 09:37:
[...]


Het werkt! bovenste is via de ElfinEW11 de ondersta via de normale bekabelde netwerk poort via de wifi zal ik zo ook even testen op de Wifi staat de poort 502 dicht en heb ik helaas geen modbus connectie
[Afbeelding]

Ok dat is ook wel een mooie ontwikkeling. Wordt dit dan wel ondersteund door Marstek? Werkt trouwens de modbus via rs485 ook nog goed? Dan ga ik ook v144 eens aanvragen.

[belio]

Modbus over TCP/LAN werkt hier ook, maar slechts eventjes
De data komt binnen, maar na een minuutje ofzo blokkeert de poort.

Geen problemen met Modbus over RS485.

Venus E V3/v144

[cold]

savale schreef op dinsdag 9 december 2025 @ 11:42:
[...]


Ok dat is ook wel een mooie ontwikkeling. Wordt dit dan wel ondersteund door Marstek? Werkt trouwens de modbus via rs485 ook nog goed? Dan ga ik ook v144 eens aanvragen.

Modbus via de RS485 poort werkt nog prima. Draai nu sinds een uur of tien op de modbus via de netwerk poort. Voor alsnog werkt het prima / net zo goed als via de elfin EW11

[cold]

belio schreef op dinsdag 9 december 2025 @ 11:50:
Modbus over TCP/LAN werkt hier ook, maar slechts eventjes
De data komt binnen, maar na een minuutje ofzo blokkeert de poort.

Geen problemen met Modbus over RS485.

Venus E V3/v144

Bij mij werkt het nu sinds een uur of tien heel stabiel.

[lemuba]

I was now also able to connect my Venus ‘D’ simultaneously to HA and evcc. Since the Venus D only allows one Modbus connection, I solved this using the evcc Modbus proxy.

Ik kon mijn Venus ‘D’ nu ook gelijktijdig aansluiten op HA en evcc. Omdat de Venus D slechts één Modbus-verbinding toestaat, heb ik dit opgelost via de evcc-Modbus-proxy.

https://www.photovoltaikf...ostID=4564763#post4564763

[edsub]

edsub schreef op maandag 8 december 2025 @ 22:47:
[...]


Mijn scripts zijn nu in de vorm van onafhankelijk lopende processen of threads.
Maar daarmee heb ik dus wel de situatie dat de requests van 2 processen tegelijk op de modbus kunnen komen.
Alles in 1 script zou kunnen, maar ik ben absoluut geen fan van dat soort monolieten.
Ik heb iig 1 USR-DR34 die eea voldoende afhandelt, ik ga dat eerst eens onderzoeken.

UPDATE: Hoe mijn scripts (die concurrent) de marstek via modbus benaderen reageren (b)lijkt erg situatie afhankelijk en heeft wss ook te maken welk script 'eerst' is en mss ook wel of dat script de control-mode heeft geactiveerd.
Getest met twee USR-DR134 converters (firmware V4301 en V4304). De V4304 lijkt er grotere moeite mee te hebben, maar het probleem treedt ook op bij de V4301.
Een relatie met de firmware van de Marstek lijkt er dus niet te zijn (en dat is goed nieuws omdat ik dat niet direct kan beïnvloeden)

Enig mogelijk werkbare oplossing is dus zorgen dat ALLE modbus bewerkingen op de Marstek in 1 proces/thread zitten en zo concurrent toegang tot de modbus voorkomen. Ben ik niet blij mee en ben ook benieuwd in hoeverre ik vooral mijn NOM script responsief genoeg hou (zoveel mogelijk registers in 1 read?), maar dat gaan we zien.
Werk aan de winkel dus weer.

[superduper1969]

edsub schreef op dinsdag 9 december 2025 @ 22:46:
[...]


UPDATE: Hoe mijn scripts (die concurrent) de marstek via modbus benaderen reageren (b)lijkt erg situatie afhankelijk en heeft wss ook te maken welk script 'eerst' is en mss ook wel of dat script de control-mode heeft geactiveerd.
Getest met twee USR-DR134 converters (firmware V4301 en V4304). De V4304 lijkt er grotere moeite mee te hebben, maar het probleem treedt ook op bij de V4301.
Een relatie met de firmware van de Marstek lijkt er dus niet te zijn (en dat is goed nieuws omdat ik dat niet direct kan beïnvloeden)

Enig mogelijk werkbare oplossing is dus zorgen dat ALLE modbus bewerkingen op de Marstek in 1 proces/thread zitten en zo concurrent toegang tot de modbus voorkomen. Ben ik niet blij mee en ben ook benieuwd in hoeverre ik vooral mijn NOM script responsief genoeg hou (zoveel mogelijk registers in 1 read?), maar dat gaan we zien.
Werk aan de winkel dus weer.

Een van de verschillen tussen de ESP-home implementatie van Modbus en andere modbus oplossingen is dat ESP-Home een sequential read kan doen waarbij opvolgende registers veel sneller worden uitgelezen dan met oplossingen met Modbus>IP converter.
In mijn Github heb ik in mijn ESP home code ook genoteerd welke sensoren niet binnen een bepaalde tijd reageren, ik heb deze gemarkeerd met "Slow Sensor", dit was wel met Firmware van een paar maanden terug maar ik denk niet dat dit veel verschil maakt.
https://github.com/Superd...ob/main/lilygo-rs485.yaml

Geen idee of de nieuwe MT v3 ingebouwde Modbus over IP anders reageert want dat is net nieuw.

[Rednas1977]

Hallo,

Ik heb op dit moment 3 Marstek Venus E batterijen (2x V2 en 1x V3). Ik wil de overstap maken naar een SmartHome platform zodat ik de batterijen beter kan aansturen. Hierbij wil ik ook de oplaad/ontlaad vermogens zelf kunnen bepalen. Ik heb een dynamisch contract. Ik ben erg aan het twijfelen tussen Homey en Home Assistant. Ik heb geen programmeer ervaring maar met wat tutorials en filmpjes kom ik vaak een heel eind. Ik weet dat ik dan 3 Lilygo's of 3 Elwin Ew11's nodig heb. Wat raden jullie mij aan?

[pascallj]

superduper1969 schreef op woensdag 10 december 2025 @ 10:20:
[...]

Een van de verschillen tussen de ESP-home implementatie van Modbus en andere modbus oplossingen is dat ESP-Home een sequential read kan doen waarbij opvolgende registers veel sneller worden uitgelezen dan met oplossingen met Modbus>IP converter.
In mijn Github heb ik in mijn ESP home code ook genoteerd welke sensoren niet binnen een bepaalde tijd reageren, ik heb deze gemarkeerd met "Slow Sensor", dit was wel met Firmware van een paar maanden terug maar ik denk niet dat dit veel verschil maakt.
https://github.com/Superd...ob/main/lilygo-rs485.yaml

Geen idee of de nieuwe MT v3 ingebouwde Modbus over IP anders reageert want dat is net nieuw.

Dat kan je zelf echter ook implementeren via Modbus TCP alleen zal je zelf het splitsen en parsen van de data moeten doen.

Daarbij heb ik nog nooit last gehad van 'slow sensor' ik lees alle registers al vanaf het begin uit binnen enkele ms. Als je doelt op logs die ESPHome maakt dat er niet snel gereageerd wordt, dat komt door logging wat aan staat. Als je het loglevel verlaagt en UART logging uit zet, krijg je die meldingen niet meer en is ook het Modbus component binnen 20 ms klaar.

[CoNsPiRaCyBE]

Tazzios schreef op zaterdag 15 november 2025 @ 13:48:
@timvanloon
script hernoemt naar automation voor de duidelijkheid. In de derde zin vermeld ik dat er een voorbeeld op github staat. Daar staat ook dat dit voor de lilygo is. Ik had er graag eentje voor de local API gemaakt maar die is nog niet echt betrouwbaar. Indien de local API af is maak ik er waarschijnlijk ook wel een blueprint voor, dan kan de Lilygo er mooi tussen uit.

Zojuist een 'import in HA' knop er bijgezet voor de blueprint. Voor een automation is dat niet mogelijk maar ik verwacht wel wat basiskennis indien je met HA werkt (je kan de yaml code kopiëren en plakken). Op basis van welke triggers de Marstek iets wil laten doen is persoonlijk en afhankelijk van je HA installatie.

Ben je van de modbus oplossing via LilyGo nu overgeschakeld op de Local API oplossing? Tevreden?
Voordelen/Nadelen ten opzichte van via modbus?
Is het deze integratie dat je gebruikt? https://github.com/jaapp/ha-marstek-local-api/