Marstek Venus / Duravolt PnP Thuisaccu Modbus koppeling

[drosophila]

Ik probeer mijn Marstek Venus aan te sturen vanuit Home Assistant met de lilygo.
Als ik de Workmode verander lijkt het alsof de codes niet kloppen.
Work mode option "manuel" (0) is ok
option "ai" (2) in Marstek leidt tot "ant-feed" in HA
option "ant-feed"(1) in Marstek leidt tot "unknown" in HA

Wie heeft dit ook opgemerkt en last van?

Originele script: in Yaml
name: "Marstek User Work Mode"
icon: mdi:auto-mode
platform: modbus_controller
modbus_controller_id: mt
address: 43000
value_type: U_WORD
optionsmap:
"manual": 0
"anti-feed": 1
"ai": 2
skip_updates: 2 # 10 seconds

[pascallj]

drosophila schreef op zondag 3 augustus 2025 @ 13:32:
Ik probeer mijn Marstek Venus aan te sturen vanuit Home Assistant met de lilygo.
Als ik de Workmode verander lijkt het alsof de codes niet kloppen.
Work mode option "manuel" (0) is ok
option "ai" (2) in Marstek leidt tot "ant-feed" in HA
option "ant-feed"(1) in Marstek leidt tot "unknown" in HA

Wie heeft dit ook opgemerkt en last van?

Originele script: in Yaml
name: "Marstek User Work Mode"
icon: mdi:auto-mode
platform: modbus_controller
modbus_controller_id: mt
address: 43000
value_type: U_WORD
optionsmap:
"manual": 0
"anti-feed": 1
"ai": 2
skip_updates: 2 # 10 seconds

Ja dat klopt inderdaad. Echter andersom werkt het wel goed: als je modi via HA instelt, worden wel die waarde ingesteld op de Marstek. Echter als je AI instelt, verandert deze daarna naar Anti-Feed, maar het zal wel goed worden ingesteld. Daarbij is er ook nog het fenomeen, dat wanneer je RS485 Control Mode aanzet, de modus ook verandert naar Anti-Feed, wat ook nergens op slaat.

Die Unknown is interessant, dat zou betekenen dat er nog een andere onbekende waarde is, zelf krijg ik deze niet.

Ik zal eens gaan experimenteren of dit register tegenwoordig andere of meer waardes accepteert.

[pascallj]

pascallj schreef op zondag 3 augustus 2025 @ 13:38:
[...]


Ja dat klopt inderdaad. Echter andersom werkt het wel goed: als je modi via HA instelt, worden wel die waarde ingesteld op de Marstek. Echter als je AI instelt, verandert deze daarna naar Anti-Feed, maar het zal wel goed worden ingesteld. Daarbij is er ook nog het fenomeen, dat wanneer je RS485 Control Mode aanzet, de modus ook verandert naar Anti-Feed, wat ook nergens op slaat.

Die Unknown is interessant, dat zou betekenen dat er nog een andere onbekende waarde is, zelf krijg ik deze niet.

Ik zal eens gaan experimenteren of dit register tegenwoordig andere of meer waardes accepteert.

Net even wat testjes gedaan, maar kan geen ander gedrag ontdekken dan zoals hierboven beschreven. Bij het uitlezen krijg ik met geen mogelijkheid andere waarde dan 0 of 1 en bij het schrijven worden alle waardes boven de 2 niet geaccepteerd.

[ Voor 60% gewijzigd door pascallj op 04-08-2025 16:10 ]

[Klausn]

does anyone have this:

[SatScan]

Klausn schreef op dinsdag 5 augustus 2025 @ 13:22:
does anyone have this:
[Afbeelding]

What sensor are you using?

[Klausn]

it is from:
Github: https://github.com/Superduper1969/MarstekVenus-LilygoRS485

File:marstek_venus_battery_control.yaml

Line 30

But it is not wrong ... first you have a value for discharging since midnight until the morning and the sun raises. Then the charging value raises until the battery is fully charged. .. so you have never a stable efficiency value ... its alwas in movement

[ Voor 53% gewijzigd door Klausn op 05-08-2025 14:07 ]

[superduper1969]

Klausn schreef op dinsdag 5 augustus 2025 @ 13:40:
it is from:
Github: https://github.com/Superduper1969/MarstekVenus-LilygoRS485

File:marstek_venus_battery_control.yaml

Line 30

But it is not wrong ... first you have a value for discharging since midnight until the morning and the sun raises. Then the charging value raises until the battery is fully charged. .. so you have never a stable efficiency value ... its alwas in movement

Thats is why I use a weekly graph, that evens out a bit.

[Klausn]

maybe it make sence to use the Marstek Total Charging Energy and Marstek Total Discharging Energy Sensors ... then we have an effeciency over the whole time ...

[tinamar]

superduper1969 schreef op dinsdag 5 augustus 2025 @ 14:26:
[...]

Thats is why I use a weekly graph, that evens out a bit.

Er was ergens een yaml voor 7 weken RTE graph maar kan die niet terugvinden, iemand hier nog een link voor?

[wrak]

ik heb daar een helper voor aangemaakt in homeassistant. Overigens niet blij met het resultaat nl. ~70% na een totale discharge van 249 kWh

code:

{% set charging = states('sensor.marstek_total_charging_energy') | float(0)%}
{% set discharging = states('sensor.marstek_total_discharging_energy' ) | float(0) %}
{{ ((discharging / charging) * 100) | float(0) | round(1) }}

[ Voor 12% gewijzigd door wrak op 05-08-2025 17:34 ]

[rb1213]

vrienden, ik slaag er maar niet in om via home assistent de mode van de battery aan te passen, ik kan het enkel uitlezen via modbus
(AI, manueel of zelfverbruik) is dat mogelijk? zoja , via welk commando?

[wrak]

Eerst je keuze maken dan control_mode op enable. Deze automatisering werkt.

code:

alias: BatterijAlsBackUp 20%
description: leeg tot 20%
triggers:
  - trigger: numeric_state
    entity_id:
      - sensor.marstek_battery_state_of_charge
    below: 21
actions:
  - sequence:
      - action: select.select_option
        target:
          entity_id: select.marstek_forcible_charge_discharge
        data:
          option: stop
      - action: select.select_option
        target:
          entity_id: select.marstek_rs485_control_mode
        data:
          option: enable
mode: single

[pascallj]

rb1213 schreef op dinsdag 5 augustus 2025 @ 18:08:
vrienden, ik slaag er maar niet in om via home assistent de mode van de battery aan te passen, ik kan het enkel uitlezen via modbus
(AI, manueel of zelfverbruik) is dat mogelijk? zoja , via welk commando?

0x0000, 0x0001 of 0x0002 sturen via functie code 6 op register 43000. Maar zie ook dit: pascallj in "Marstek Venus / Duravolt PnP Thuisaccu Modbus koppeling".

[tinamar]

Heb vandaag wat in HA logboek rondgekeken en het staat vol met Lilygo ip wijzigen.
Ik heb hier geen verstand van en ook geen last, maar is dit normaal of ligt het aan mijn router?

[Witlof]

Is een wijziging in IPv4 en IPv6 lijkt het. Als je geen IPv6 gebruikt, gewoon uitschakelen en de meldingen verdwijnen waarschijnlijk.

[JanAllElectric]

Ik heb 3 lilygo's sinds 1 mei werkend met de yaml van @superduper1969 .

Sinds enige tijd (ik draai met ESPhome 2025.7.4) bemerk ik dat soms de integratie met ESPhome in Home Assistant met 1 van de Marsteks status 'unavailable' krijgt. Reload (handmatig) van de ESPhome integratie in Home Assistant lost dat weer op.

Waar ligt dat aan en hoe los ik dat op.

NB: Wifi signaalsterkte lilygo's is ca -40dB
NB: ik zie in de log ook veel IPv4/IPv6 wisselingen. Ik gebruik IPv6 niet. Hoe/waar schakel ik dat uit?

[ Voor 11% gewijzigd door JanAllElectric op 06-08-2025 09:10 ]

[dannyro]

JanAllElectric schreef op woensdag 6 augustus 2025 @ 09:08:
Ik heb 3 lilygo's sinds 1 mei werkend met de yaml van @superduper1969 .

Sinds enige tijd (ik draai met ESPhome 2025.7.4) bemerk ik dat soms de integratie met ESPhome in Home Assistant met 1 van de Marsteks status 'unavailable' krijgt. Reload (handmatig) van de ESPhome integratie in Home Assistant lost dat weer op.

Waar ligt dat aan en hoe los ik dat op.

NB: Wifi signaalsterkte lilygo's is ca -40dB
NB: ik zie in de log ook veel IPv4/IPv6 wisselingen. Ik gebruik IPv6 niet. Hoe/waar schakel ik dat uit?

Ik heb dat uitgeschakeld in mijn Mac zelf.

[superduper1969]

tinamar schreef op woensdag 6 augustus 2025 @ 08:29:
Heb vandaag wat in HA logboek rondgekeken en het staat vol met Lilygo ip wijzigen.
Ik heb hier geen verstand van en ook geen last, maar is dit normaal of ligt het aan mijn router?[Afbeelding]

@JanAllElectric
@tinamar
Hi, mischien is dit een effect van een nieuwere versie van ESP-Home-Builder

Je kunt dit uitschakelen met enable_ipv6: false
Voor meer info: https://esphome.io/components/network.html

Je kunt hier alvast mee testen en feedback geven.
Ik ga het ook vanavond thuis testen en in de code verwerken.

[ Voor 5% gewijzigd door superduper1969 op 06-08-2025 10:08 ]

[superduper1969]

JanAllElectric schreef op woensdag 6 augustus 2025 @ 09:08:
Ik heb 3 lilygo's sinds 1 mei werkend met de yaml van @superduper1969 .

Sinds enige tijd (ik draai met ESPhome 2025.7.4) bemerk ik dat soms de integratie met ESPhome in Home Assistant met 1 van de Marsteks status 'unavailable' krijgt. Reload (handmatig) van de ESPhome integratie in Home Assistant lost dat weer op.

Waar ligt dat aan en hoe los ik dat op.

NB: Wifi signaalsterkte lilygo's is ca -40dB
NB: ik zie in de log ook veel IPv4/IPv6 wisselingen. Ik gebruik IPv6 niet. Hoe/waar schakel ik dat uit?

Check effe je wifi router of je daar IPv6 uit/aan kan zetten.
Het hoeft niet met je router te maken te hebben.
IPv6 kent 2 modes:
Statefull = een soort DHCP waarbij de DHCP server van de router je IPv6 adres bepaalt
Stateless = een soort APIPA waarbij het device het IPv6 adres bepaald.

Zie de andere post hoe je mogelijk IPv6 op de Lilygo zelf kan aanpassen.

[pascallj]

Dit heeft allemaal niets te maken met ipv6, maar met het feit dat je het 'wifi_platform' hebt toegevoegd in een van de laatste commits.

De vraag is alleen waarom hij dezelfde status dubbel laat zien in het logboek. Dat zou niet moeten.

[superduper1969]

pascallj schreef op woensdag 6 augustus 2025 @ 10:26:
Dit heeft allemaal niets te maken met ipv6, maar met het feit dat je het 'wifi_platform' hebt toegevoegd in een van de laatste commits.

De vraag is alleen waarom hij dezelfde status dubbel laat zien in het logboek. Dat zou niet moeten.

Dat is dan waarschijnlijk meegekomen met de code van @AUijtdehaag want dat was een flinke update. Hij heeft daar vast heel wat uurtjes ingestoken!
https://github.com/fonske...e/atom_s3_lite_rs485.yaml
Bedoel je: platform: wifi_info ?
Zoals ik het las is dit om ook informatie over de Wifi van de Lilygo zelf te ontstuiten in een sensor.

Ik zal vanavond ook eens op mijn router thuis kijken of ik IPv6 aan heb staan op de router.

[pascallj]

superduper1969 schreef op woensdag 6 augustus 2025 @ 11:50:
[...]

Dat is dan waarschijnlijk meegekomen met de code van @AUijtdehaag want dat was een flinke update. Hij heeft daar vast heel wat uurtjes ingestoken!
https://github.com/fonske...e/atom_s3_lite_rs485.yaml
Bedoel je: platform: wifi_info ?
Zoals ik het las is dit om ook informatie over de Wifi van de Lilygo zelf te ontstuiten in een sensor.

Ik zal vanavond ook eens op mijn router thuis kijken of ik IPv6 aan heb staan op de router.

Klopt, komt inderdaad uit die commit. En daar is het inderdaad voor bedoelt. Normaal zou een sensor met identieke waarde niet moeten worden opgeslagen in HA, dus waarom dat is zou je even moeten bekijken als het bij meerderen en vaker zich voordoet.

~AUijtdehaag heeft al langer ervaring met ESPHome als je GOT doorkijkt, dus dat gaat misschien iets makkelijker af

[Mattie112]

Ter aanvulling:
Mijn S3 Atom van AUijtdehaag logged dat niet continue. Alleen bij een disconnect lijkt het (unavailable -> 1.2.3.4)

[superduper1969]

Bij mij werd ook IP V6 weergegeven, ik zag dat IPv6 support al een tijd in ESPHome zit. (2023)
Kan geen kwaad maar misschien heeft het weglaten van IPv6 nog een positieve invloed, in ieder geval een schoner log.

Ik heb als test 2 regels code toegevoegd als test (dus nog niet op Github)

code:

network:
  enable_ipv6: false

Ik heb bij mijn andere 2 ESP devices ook de code bijgeplaatst om te zien wat daar gebeurt.

code:

text_sensor:
  - platform: wifi_info
    ip_address:
      name: ESP IP
      icon: mdi:ip
    ssid:
      name: ESP SSID
      icon: mdi:wifi

Die geven nu ook netjes hun IP en gekoppelde SSID weer.
Weer wat geleerd!

[ Voor 15% gewijzigd door superduper1969 op 06-08-2025 23:00 ]

[Tom Jansen]

Goedenavond, na de laatste updates valt het mij op dat de LilyGo praktisch continue 100 watt meer stroom zegt te leveren aan het "huis" dan wat de Marstek in de app aangeeft?
Het viel mij plots op na het installeren van een tablet aan de muur.
Ik heb nog niets in de yaml kunnen vinden of er in de laatste updates iets is gewijzigd wat dit zou kunnen veroorzaken.

Iemand een idee, of hebben meer hier last van?

[pascallj]

Tom Jansen schreef op woensdag 6 augustus 2025 @ 23:00:
Goedenavond, na de laatste updates valt het mij op dat de LilyGo praktisch continue 100 watt meer stroom zegt te leveren aan het "huis" dan wat de Marstek in de app aangeeft?
Het viel mij plots op na het installeren van een tablet aan de muur.
Ik heb nog niets in de yaml kunnen vinden of er in de laatste updates iets is gewijzigd wat dit zou kunnen veroorzaken.

Iemand een idee, of hebben meer hier last van?

Je kijkt niet toevallig naar de waarde van 'Battery Power' ipv 'AC Power'? Dit is namelijk het vermogen wat uit de batterij komt, maar door het verlies van de omvormer, krijg je de waarde van AC Power slechts in het stopcontact (en andersom).

[superduper1969]

Tom Jansen schreef op woensdag 6 augustus 2025 @ 23:00:
Goedenavond, na de laatste updates valt het mij op dat de LilyGo praktisch continue 100 watt meer stroom zegt te leveren aan het "huis" dan wat de Marstek in de app aangeeft?
Het viel mij plots op na het installeren van een tablet aan de muur.
Ik heb nog niets in de yaml kunnen vinden of er in de laatste updates iets is gewijzigd wat dit zou kunnen veroorzaken.

Iemand een idee, of hebben meer hier last van?

AC Power = Aan het Net, dit is ook wat er in de App Staat, en die komt bij mij overeen.
Battery Power = Aan de inverter, bij lagere wattages gaat hier nog flink wat verlies af.
Als er wijzigingen zijn geweest in FW dan is het vaak dat de comma verplaatst.

[superduper1969]

@pascallj Jij typt met 10 vingers..... Maar hetzelfde antwoord in ieder geval!

[pascallj]

superduper1969 schreef op woensdag 6 augustus 2025 @ 23:10:
@pascallj Jij typt met 10 vingers..... Maar hetzelfde antwoord in ieder geval!

Haha in dit geval waren het slechts twee duimen .

[Tom Jansen]

superduper1969 schreef op woensdag 6 augustus 2025 @ 23:06:
[...]

AC Power = Aan het Net, dit is ook wat er in de App Staat, en die komt bij mij overeen.
Battery Power = Aan de inverter, bij lagere wattages gaat hier nog flink wat verlies af.
Als er wijzigingen zijn geweest in FW dan is het vaak dat de comma verplaatst.

Hmmm... Het was nl. altijd gelijk, dacht ik🫣. Ik heb in het verleden nooit gezien dat er 100watt verschil in zat... Maar het is de battery power entity in HA. 100 watt meer als de app.

[ Voor 6% gewijzigd door Tom Jansen op 07-08-2025 00:03 ]

[tinamar]

superduper1969 schreef op woensdag 6 augustus 2025 @ 22:49:

Ik heb als test 2 regels code toegevoegd als test (dus nog niet op Github)

code:

network:
  enable_ipv6: false

Net getest en nu geen ip meldingen meer, zal morgen nog een kijken

[Witlof]

Ik heb vandaag ook maar de knoop doorgehakt en er 1 besteld. Ben wel benieuwd naar dit nieuwe speelgoed.

FWD heeft de Marstek ook gereviewd zag ik na de bestelling pas: https://fwd.nl/smarthome/...-energieopslag-op-wielen/

[tinamar]

tinamar schreef op donderdag 7 augustus 2025 @ 00:59:
[...]

Net getest en nu geen ip meldingen meer, zal morgen nog een kijken

Update, nog enkele IPv6 wijzegingen in de log maar veel verminderd.

[superduper1969]

Ook net gekeken naar mijn logs:

code:

network:
  enable_ipv6: false

Doet niets merkbaars, maar dat is voor de uiteindelijke werking dus ook niet van invloed.

[rb1213]

wrak schreef op dinsdag 5 augustus 2025 @ 18:11:
Eerst je keuze maken dan control_mode op enable. Deze automatisering werkt.

code:

alias: BatterijAlsBackUp 20%
description: leeg tot 20%
triggers:
  - trigger: numeric_state
    entity_id:
      - sensor.marstek_battery_state_of_charge
    below: 21
actions:
  - sequence:
      - action: select.select_option
        target:
          entity_id: select.marstek_forcible_charge_discharge
        data:
          option: stop
      - action: select.select_option
        target:
          entity_id: select.marstek_rs485_control_mode
        data:
          option: enable
mode: single

zodra ik de RS485 enable functie stuur dan gaat in de app status naar 'leeg' en batt naar bypass en kan ik niks meer doen...raar


switches:
- name: "Marstek Enable RS485 Control Mode"
unique_id: my_battery_enable_rs485_control_mode
address: 42000
slave: 1
command_on: 21930 # 0x55AA in decimal
command_off: 21947 # 0x55BB in decimal
write_type: holding

[pascallj]

rb1213 schreef op donderdag 7 augustus 2025 @ 12:24:
[...]


zodra ik de RS485 enable functie stuur dan gaat in de app status naar 'leeg' en batt naar bypass en kan ik niks meer doen...raar


switches:
- name: "Marstek Enable RS485 Control Mode"
unique_id: my_battery_enable_rs485_control_mode
address: 42000
slave: 1
command_on: 21930 # 0x55AA in decimal
command_off: 21947 # 0x55BB in decimal
write_type: holding

Dat was volgens mij ook geen antwoord op jou, want de RS485 control heeft niets te maken met het instellen van de User Work Mode. Hoe je dat moest doen, heb ik je al verteld aangezien je je eigen implementatie aan het maken bent en niet de implementatie van dit topic gebruikt.

Als je RS485 Control Mode inschakelt, zal je alleen nog maar via Modbus kunnen sturen. Je maakt dan dus geen gebruik meer van de Marstek modi (NOM, AI, of Manual). Dat de status in jouw geval naar Bypass gaat, komt omdat je het backup-stopcontact aan hebt staan. Zodra je RS485 Control Mode aanzet en geen andere actie stuurt, gaat de batterij in stand-by, maar in jouw geval met het stopcontact aan, dus naar Bypass.

[rb1213]

pascallj schreef op donderdag 7 augustus 2025 @ 14:13:
[...]


Dat was volgens mij ook geen antwoord op jou, want de RS485 control heeft niets te maken met het instellen van de User Work Mode. Hoe je dat moest doen, heb ik je al verteld aangezien je je eigen implementatie aan het maken bent en niet de implementatie van dit topic gebruikt.

Als je RS485 Control Mode inschakelt, zal je alleen nog maar via Modbus kunnen sturen. Je maakt dan dus geen gebruik meer van de Marstek modi (NOM, AI, of Manual). Dat de status in jouw geval naar Bypass gaat, komt omdat je het backup-stopcontact aan hebt staan. Zodra je RS485 Control Mode aanzet en geen andere actie stuurt, gaat de batterij in stand-by, maar in jouw geval met het stopcontact aan, dus naar Bypass.

thanks, ik ben (nog) geen HA specialist .
ik heb die RS485 dus helemaal niet nodig dus ,
enkel op 43000 de waarde 0,1 of 2 sturen dus ...

ik probeer dat eens.
bestaat er in Home Assitant een control schakelaar met 3 standen? want ik vind enkel switch: (on/off)

[pascallj]

rb1213 schreef op donderdag 7 augustus 2025 @ 16:36:
[...]


thanks, ik ben (nog) geen HA specialist .
ik heb die RS485 dus helemaal niet nodig dus ,
enkel op 43000 de waarde 0,1 of 2 sturen dus ...

ik probeer dat eens.
bestaat er in Home Assitant een control schakelaar met 3 standen? want ik vind enkel switch: (on/off)

Ja klopt! Maar zie ook de post die ik gelinkt had over hoe het register reageert: het is wat bijzonder.

Dan heb je eigenlijk een 'select' nodig: https://www.home-assistant.io/integrations/select/. Eigenlijk gewoon een menu met meerdere opties.

[rb1213]

pascallj schreef op donderdag 7 augustus 2025 @ 16:39:
[...]


Ja klopt! Maar zie ook de post die ik gelinkt had over hoe het register reageert: het is wat bijzonder.

Dan heb je eigenlijk een 'select' nodig: https://www.home-assistant.io/integrations/select/. Eigenlijk gewoon een menu met meerdere opties.

thanks!! nu werkt alles … mn hub naam stond gewoon nog verkeerd in de automations !! 🙄🙄

[Eddie_]

Hartelijk dank aan allen die dit mogelijk hebben gemaakt. Ik heb het nog niet werkend maar werk in uitvoering.

[ Voor 86% gewijzigd door Eddie_ op 08-08-2025 17:14 ]

[Klausn]

Updated today from v212 to v215.

Now i have the following:




do you have that too on your Venus E 5,12 kwh?

[pascallj]

Klausn schreef op vrijdag 8 augustus 2025 @ 21:27:
Updated today from v212 to v215.

Now i have the following:
[Afbeelding]


[Afbeelding]
do you have that too on your Venus E 5,12 kwh?

See pascallj in "Marstek Venus / Duravolt PnP Thuisaccu Modbus koppeling" and https://github.com/Superd...nus-LilygoRS485/issues/13

[Klausn]

perfect -- than i remove the filter part
Thanks

[fx500]

Al heel veel meegelezen in dit topic. Wat geweldig alle kennis hier die door mede-Tweakers gedeeld word.

Pas net gezien in de Marstek app dat er een update was. Niet direct release notes kunnen vinden... dus vuur.
Na de update spontaan van 99%SoC naa 55% SoC. ik las een aantal posts met soort gelijke info.
Is dit normaal?

Misschien heb ik het gemist (nou zie hier boven. Zover was ik nog niet met lezen), maar de sensor voor de cell temp. aangepast naar

code:

- name: "Marstek Max. Cell Temperature"
    id: "lilygo_rs485_marstek_max_cell_temperature"
    icon: mdi:thermometer
    platform: modbus_controller
    modbus_controller_id: mt
    register_type: holding
    address: 35010
    value_type: S_WORD
    unit_of_measurement: "°C"
    device_class: temperature
    state_class: measurement
    accuracy_decimals: 1
    skip_updates: 60 # 5 minutes
    filters:
      - multiply: 1.0
    web_server:
      sorting_group_id: Info
      sorting_weight: 22
    
  - name: "Marstek Min. Cell Temperature"
    id: "lilygo_rs485_marstek_min_cell_temperature"
    icon: mdi:thermometer
    platform: modbus_controller
    modbus_controller_id: mt
    register_type: holding
    address: 35011
    value_type: S_WORD
    unit_of_measurement: "°C"
    device_class: temperature
    state_class: measurement
    accuracy_decimals: 1
    filters:
      - multiply: 1.0
    web_server:
      sorting_group_id: Info
      sorting_weight: 23

Doet die weer normaal mee in HA.

Heel veel kudo's naar @superduper1969!!

[pascallj]

fx500 schreef op vrijdag 8 augustus 2025 @ 21:40:
Al heel veel meegelezen in dit topic. Wat geweldig alle kennis hier die door mede-Tweakers gedeeld word.

Pas net gezien in de Marstek app dat er een update was. Niet direct release notes kunnen vinden... dus vuur.
Na de update spontaan van 99%SoC naa 55% SoC. ik las een aantal posts met soort gelijke info.
Is dit normaal?

Misschien heb ik het gemist, maar de sensor voor de cell temp. aangepast naar

code:

- name: "Marstek Max. Cell Temperature"
    id: "lilygo_rs485_marstek_max_cell_temperature"
    icon: mdi:thermometer
    platform: modbus_controller
    modbus_controller_id: mt
    register_type: holding
    address: 35010
    value_type: S_WORD
    unit_of_measurement: "°C"
    device_class: temperature
    state_class: measurement
    accuracy_decimals: 1
    skip_updates: 60 # 5 minutes
    filters:
      - multiply: 1.0
    web_server:
      sorting_group_id: Info
      sorting_weight: 22
    
  - name: "Marstek Min. Cell Temperature"
    id: "lilygo_rs485_marstek_min_cell_temperature"
    icon: mdi:thermometer
    platform: modbus_controller
    modbus_controller_id: mt
    register_type: holding
    address: 35011
    value_type: S_WORD
    unit_of_measurement: "°C"
    device_class: temperature
    state_class: measurement
    accuracy_decimals: 1
    filters:
      - multiply: 1.0
    web_server:
      sorting_group_id: Info
      sorting_weight: 23

Doet die weer normaal mee in HA. Veel kudo's naar @superduper1969!!

Ja dat is normaal na updates van het BMS. Er zijn waarschijnlijk wat instellingen gewijzigd, waardoor de SoC opnieuw moet 'kalibreren'. Geen paniek.

Zie hier voor de changelog: pascallj in "Hame / Marstek / Duravolt 5,12kWh plug en play thuisaccu"

De post hierboven ging ook over de cell temp, mocht je dat gemist hebben.

[fx500]

pascallj schreef op vrijdag 8 augustus 2025 @ 21:43:
[...]


Ja dat is normaal na updates van het BMS. Er zijn waarschijnlijk wat instellingen gewijzigd, waardoor de SoC opnieuw moet 'kalibreren'. Geen paniek.

Zie hier voor de changelog: pascallj in "Hame / Marstek / Duravolt 5,12kWh plug en play thuisaccu"

De post hierboven ging ook over de cell temp, mocht je dat gemist hebben.

Ah thanks! Valt dat weer mee. Ik had 'm inmiddels gevonden.

En ja ik zag het net te laat. Voor wie het toevallig leest en copy > paste...

[superduper1969]

Startpost aangepast:
- 9-8-2025 Lilygo Github BMS V2.15 Cell temp scale @TDSgame

[wrak]

Ook de update gedaan en nu is de batterij helemaal van slag. Hij schiet steeds in de standby en dan valt het backup stopcontact ook uit. Een paar keer alle stekkers eruit gehaald. opnieuw gestart. Dan werkt het weer even maar brengt geen verbetering. Herkent hier iemand dat? Of is er een manier om deze laatste update ongedaan te maken?

[ Voor 5% gewijzigd door wrak op 09-08-2025 20:47 ]

[NoFate]

Heeft iemand de instructies om firmware te flashen over modbus?

[leejoow]

Modbus kan geen firmware over geflashed worden

nvm, had gemist dat hier toch mogelijkheden voor waren als laatste optie. Excuus voor de verwarring

[ Voor 55% gewijzigd door leejoow op 10-08-2025 07:14 ]

[superduper1969]

wrak schreef op zaterdag 9 augustus 2025 @ 20:44:
Ook de update gedaan en nu is de batterij helemaal van slag. Hij schiet steeds in de standby en dan valt het backup stopcontact ook uit. Een paar keer alle stekkers eruit gehaald. opnieuw gestart. Dan werkt het weer even maar brengt geen verbetering. Herkent hier iemand dat? Of is er een manier om deze laatste update ongedaan te maken?

Heb je ook de volledige reset procedure gedaan zoals compleet bescreven in de Topic Start?

[wrak]

superduper1969 schreef op zaterdag 9 augustus 2025 @ 21:54:
[...]

Heb je ook de volledige reset procedure gedaan zoals compleet bescreven in de Topic Start?

Ik heb nu een fabrieks instellingen reset gedaan. Ik heb nog niet de stekker er voor langere tijd uit gehad. De batterij blijft nu wel werken en schiet niet meer na belasting van de quooker in de standby. De batterij heeft er wel veel moeite mee om de netbelasting op nul te houden. Morgenochtend zal ik alles loskoppelen en hem een uurtje rust geven.

ter vergelijk nu en gisterenavond onder vergelijkbare omstandigheden:

[ Voor 13% gewijzigd door wrak op 09-08-2025 22:28 ]

[pascallj]

NoFate schreef op zaterdag 9 augustus 2025 @ 21:16:
Heeft iemand de instructies om firmware te flashen over modbus?

Op de Github van ~bommel, kan je de instructies terugvinden zoals die toen gegeven zijn aan die ene persoon: https://github.com/rweijnen/marstek-venus-e-firmware-notes

Maar dit vereist wel wat Modbus/seriële kennis en apparatuur en zou hier eigenlijk zelf niet aan beginnen zonder dat je de opdracht van Marstek hebt gekregen. Is echt het laatste redmiddel.

leejoow schreef op zaterdag 9 augustus 2025 @ 21:38:
Modbus kan geen firmware over geflashed worden

Het kan wel en is als eens eerder succesvol gedaan door een mede-tweaker, maar zou er niet aan beginnen. De Modbus dient dan als seriële poort.

[pascallj]

wrak schreef op zaterdag 9 augustus 2025 @ 20:44:
Ook de update gedaan en nu is de batterij helemaal van slag. Hij schiet steeds in de standby en dan valt het backup stopcontact ook uit. Een paar keer alle stekkers eruit gehaald. opnieuw gestart. Dan werkt het weer even maar brengt geen verbetering. Herkent hier iemand dat? Of is er een manier om deze laatste update ongedaan te maken?

De SoC kan van slag raken door de update en als gevold dus ook het stopcontact etc. Ik zou eens helemaal handmatig volladen zodat je dat kan uitsluiten.

[Maxwp]

Edit
Oeps verkeerde topic
------


Geen idee of dit the next new problem is

Maar na updaten naar 513 en 213 blijft hij terug komem met de vraag om 214 te updaten ook al na meerdere keren succesvol deze update te hebben gedaan
Natuurlij weigert hij nu alle diensten dus staat constant in standby
Heb hem van de strook gehaald en uitgezet nu nog eens 15 min wachten

Dit was trowuens nadat ik bericht kreeg al enige tijd terug datver een update was deze heb ik genegeerd en nu zomaar ineens is hij gestopt met werken.
Toen dan maar die update uitgevoerd met dit probleem nu.

[ Voor 3% gewijzigd door Maxwp op 10-08-2025 09:51 ]

[bobloblaw]

Hallo,

Heb de Marstek intussen in gebruik en verbonden met een Loxone Modbus extensie. Lijkt best OK te werken, althans voor lezen. Data schrijven en de batterij effectief aansturen moet ik nog even verder uitzoeken.



Ik had nog een vraag over de baud rate. Die staat nu op 115200 en dat werkt. Ik wil echter nog een modbus stroomtellertje toevoegen, maar die kan volgens de docs enkel deze baud rates aan:
Baud rate: 1200, 2400, 4800, 9600

Kan ik die baud rate verlagen naar 9600 zodat ik zowel de Marstek als de meter op 1 modbus extensie kan houden of werkt het zo niet?

[pascallj]

bobloblaw schreef op zondag 10 augustus 2025 @ 19:37:
Hallo,

Heb de Marstek intussen in gebruik en verbonden met een Loxone Modbus extensie. Lijkt best OK te werken, althans voor lezen. Data schrijven en de batterij effectief aansturen moet ik nog even verder uitzoeken.

[Afbeelding]

Ik had nog een vraag over de baud rate. Die staat nu op 115200 en dat werkt. Ik wil echter nog een modbus stroomtellertje toevoegen, maar die kan volgens de docs enkel deze baud rates aan:
Baud rate: 1200, 2400, 4800, 9600

Kan ik die baud rate verlagen naar 9600 zodat ik zowel de Marstek als de meter op 1 modbus extensie kan houden of werkt het zo niet?

Voor zover ik weet is de baudrate helaas niet aan te passen. Ik weet niet precies hoe je Loxone systeem werkt, hoe je Modbus omzet en opvraagt etc. maar ik heb bijvoorbeeld een ESP32 met 2 Modbus converters eraan voor verschillende baudrates. Dat werkt prima.

[Mattie112]

Weet iemand waar de "MT CT connection abnormal" op reageert? Vanuit de modbus (https://github.com/fonske...m_s3_lite_rs485.yaml#L409).

Het lijkt er op dat mijn 2e accu het niet echt doet atm. Ik zie alleen nog maar accu 1 opladen. Laatst gerapporteerde (14 hours ago) wifi strength is 100%. Vannacht heeft ie het ook gewoon goed gedaan.

Nou ben ik niet thuis om het te verifiëren maar zou leuk zijn om mijn HA een alert te laten sturen wanneer de accu de CT verbinding kwijt it. Not sure of er nu echt iets is of dat hij liever eerst de andere accu gaat opladen.

[pascallj]

Mattie112 schreef op maandag 11 augustus 2025 @ 10:56:
Weet iemand waar de "MT CT connection abnormal" op reageert? Vanuit de modbus (https://github.com/fonske...m_s3_lite_rs485.yaml#L409).

Het lijkt er op dat mijn 2e accu het niet echt doet atm. Ik zie alleen nog maar accu 1 opladen. Laatst gerapporteerde (14 hours ago) wifi strength is 100%. Vannacht heeft ie het ook gewoon goed gedaan.

Nou ben ik niet thuis om het te verifiëren maar zou leuk zijn om mijn HA een alert te laten sturen wanneer de accu de CT verbinding kwijt it. Not sure of er nu echt iets is of dat hij liever eerst de andere accu gaat opladen.

Alle error / fault registers werken momenteel niet naar behoren, dus daar kan je eigenlijk geen waarde aan hechten momenteel.

Beter gezegd moet ik eigenlijk zeggen dat we niet precies weten hoe ze werken. De registers werken misschien wel naar behoren, alleen de documentatie komt niet overeen.

[ Voor 9% gewijzigd door pascallj op 11-08-2025 10:59 ]

[Mattie112]

pascallj schreef op maandag 11 augustus 2025 @ 10:58:
[...]


Alle error / fault registers werken momenteel niet naar behoren, dus daar kan je eigenlijk geen waarde aan hechten momenteel.

Beter gezegd moet ik eigenlijk zeggen dat we niet precies weten hoe ze werken. De registers werken misschien wel naar behoren, alleen de documentatie komt niet overeen.

Check, ik zie nu wel "Wifi Status": Disconnected staan (al is de signal strength 100%). En ook cloud status is 'disconnected'. Maar geen warnings bij de CT.

Alleen nu is het bij accu 1 ipv accu 2. Ah well zolang 1 van de accus maar de zon op slurpt is het goed

[pascallj]

Mattie112 schreef op maandag 11 augustus 2025 @ 13:18:
[...]


Check, ik zie nu wel "Wifi Status": Disconnected staan (al is de signal strength 100%). En ook cloud status is 'disconnected'. Maar geen warnings bij de CT.

Alleen nu is het bij accu 1 ipv accu 2. Ah well zolang 1 van de accus maar de zon op slurpt is het goed

De Wifi Status, Cloud status en Marstek Signal Strength in dBm kloppen wel, die heb ik laatst gevonden en geverifieerd. De signal strength in procenten is een berekening en komt niet rechtstreeks uit de batterij, dus hoe en of dat correct is durf ik niet te zeggen. Maar het is dus logisch dat je geen warnings ziet bij de CT, want ook van die registers weten we niet hoe het werkt. Sterker nog, ik heb toen getest en er is op de hele Modbus range geen 1 waarde die verandert wanneer er wel of geen CT verbonden is, dus waarschijnlijk is die hele status niet beschikbaar.

[Mattie112]

Check, er staat niet ergens een lijst toch met wat er wel/niet klopt? Anders voorlopig maar kijken naar wifi/cloud status dat zou een aardige indicatie moeten geven dan.

De ene accu is inmiddels al weer een uur op "disconnected" en de 2e is vrolijk aan het laden dus mijn accesspoint zou toch echt wel up moeten zijn

[pascallj]

Mattie112 schreef op maandag 11 augustus 2025 @ 14:12:
Check, er staat niet ergens een lijst toch met wat er wel/niet klopt? Anders voorlopig maar kijken naar wifi/cloud status dat zou een aardige indicatie moeten geven dan.

De ene accu is inmiddels al weer een uur op "disconnected" en de 2e is vrolijk aan het laden dus mijn accesspoint zou toch echt wel up moeten zijn

Alles is correct, behalve de fout/alarm registers. Mocht je details willen, kan je mijn onofficiële Modbus documentatie raadplegen die gelinkt staat in de TS van dit topic.

[Mattie112]

Ok, duidelijk! En thx daar ga ik eens doorheen!

[Mattie112]

Misschien nog wel een aardige om te kijken of 41000 A028 'device restart' werkt. Met hoeveel problemen mensen ook wel eens hebben met een restart na een update etc.

Kan wel als ik thuis ben kijken of ik dat voor elkaar krijg met de esphome yaml

[pascallj]

Mattie112 schreef op maandag 11 augustus 2025 @ 15:42:
Misschien nog wel een aardige om te kijken of 41000 A028 'device restart' werkt. Met hoeveel problemen mensen ook wel eens hebben met een restart na een update etc.

Kan wel als ik thuis ben kijken of ik dat voor elkaar krijg met de esphome yaml

Ja hoor werkt gewoon, daarom staat hij ook in mijn documentatie. Alles wat daarin staat is getest.

[Mattie112]

Dan snap ik niet op welke term ik net zocht Ik dacht naar "41000" maar blijkbaar niet. Ah well!

[PvdSman]

Ik heb vandaag wat gestoeid met hard- en software om de modbus koppeling aan de praat te krijgen. Dat had wat voeten in de aarde omdat ik meer een hardware dan een software aanleg heb.Desalniettemin allemaal erg bedankt want zonder dit forum was ik helemaal nergens gekomen.
Ik heb nu twee batterijen op een enkele phase en een van de batterijen gekoppeld aan een lilygo. Later wil ik naar 3 batterijen, met een batterij per phase voor meer opslag capaciteit en meer vermogen on een warmtepomp aan te kunnen sturen (maar dan moet ik eerst de lokatie en de bedrading in orde brengen). Maar ik heb wat vragen:
1) Kan ik alle batterijen op een enkele modbus aansluiten? Heeft iemand dat al eens gedaan? Ik kan me zo voorstellen dat dit problemen kan geven i.v.m. isolatie. Ook de belasting van de bus kan een probleem vormen.
Alvast bedankt

[pascallj]

PvdSman schreef op maandag 11 augustus 2025 @ 19:08:
Ik heb vandaag wat gestoeid met hard- en software om de modbus koppeling aan de praat te krijgen. Dat had wat voeten in de aarde omdat ik meer een hardware dan een software aanleg heb.Desalniettemin allemaal erg bedankt want zonder dit forum was ik helemaal nergens gekomen.
Ik heb nu twee batterijen op een enkele phase en een van de batterijen gekoppeld aan een lilygo. Later wil ik naar 3 batterijen, met een batterij per phase voor meer opslag capaciteit en meer vermogen on een warmtepomp aan te kunnen sturen (maar dan moet ik eerst de lokatie en de bedrading in orde brengen). Maar ik heb wat vragen:
1) Kan ik alle batterijen op een enkele modbus aansluiten? Heeft iemand dat al eens gedaan? Ik kan me zo voorstellen dat dit problemen kan geven i.v.m. isolatie. Ook de belasting van de bus kan een probleem vormen.
Alvast bedankt

De drukte op de bus is geen probleem, ik heb momenteel een ESP32 die meer dan 400 registers verspreid over 3 apparaten elke 5 seconde uitvraagt en dat gaat prima.

Het kan inderdaad op 1 LilyGo maar dan moet je 1 batterij aansluiten, het adres veranderen via Modbus, en ze dan allebei aansluiten en zelf een configuratie maken. Het kan wel, maar is niet makkelijk uit te leggen. Vandaar dat veel gewoon kiezen voor 2 LilyGo, dat is makkelijker werkend te krijgen.

[PvdSman]

Bedankt voor de feedback. Gezien mijn achtergrond ga ik dan ook maar voor de eenvoudige route 😉

[Animal]

Is er een reden dat de instelling niet op 11 procent kan maar minimaal 12 procent?

[pascallj]

Animal schreef op dinsdag 12 augustus 2025 @ 10:00:
Is er een reden dat de instelling niet op 11 procent kan maar minimaal 12 procent?

Ik neem aan dat je de instelling bedoelt voor wanneer het ontladen moet stoppen. Deze stopt op percentage - 1. Dus 12 wordt stoppen op 11 (standaard) en 100 wordt 99 (je kan niet stoppen met ontladen op 100).

[JSTAL]

There is a warning message when compiling the lilygo-rs485.yaml code.

#warning "The legacy RMT driver is deprecated, please use driver/rmt_tx.h and/or driver/rmt_rx.h"



This is due to the usage of the LED - neopixelbus.

You can solve this by changing the code as follows:

light:
# - platform: neopixelbus
# type: GRB
# variant: WS2812

- platform: esp32_rmt_led_strip
rgb_order: GRB
chipset: WS2812

[fRiEtJeSaTe]

Ik sta aan de rand mee te gluren nog zonder de diepte in te gaan. Ik draai EVCC en wil graag een Marstek Venus E 5,12kwh toevoegen. Lees over meerdere versies accu.

Als ik de laatste versie aanschaf (de E?) en de boel aansluit met een LilyGo wifi T-CAN485. Heb ik dan een stabiel draaiende oplossing die ik los kan laten? Of zitten we nog in het stadium lekker pielen?

[ Voor 3% gewijzigd door fRiEtJeSaTe op 12-08-2025 18:17 ]

[SatScan]

fRiEtJeSaTe schreef op dinsdag 12 augustus 2025 @ 18:16:
Ik sta aan de rand mee te gluren nog zonder de diepte in te gaan. Ik draai EVCC en wil graag een Marstek Venus E 5,12kwh toevoegen. Lees over meerdere versies accu.

Als ik de laatste versie aanschaf (de E?) en de boel aansluit met een LilyGo wifi T-CAN485. Heb ik dan een stabiel draaiende oplossing die ik los kan laten? Of zitten we nog in het stadium lekker pielen?

Je heb pech het stadium van pielen is voorbij... alles steady met en zonder modbus

PS en in BE nu ook officieel toegelaten!

[ Voor 3% gewijzigd door SatScan op 12-08-2025 19:21 ]

[pascallj]

fRiEtJeSaTe schreef op dinsdag 12 augustus 2025 @ 18:16:
Ik sta aan de rand mee te gluren nog zonder de diepte in te gaan. Ik draai EVCC en wil graag een Marstek Venus E 5,12kwh toevoegen. Lees over meerdere versies accu.

Als ik de laatste versie aanschaf (de E?) en de boel aansluit met een LilyGo wifi T-CAN485. Heb ik dan een stabiel draaiende oplossing die ik los kan laten? Of zitten we nog in het stadium lekker pielen?

Voor verschillen tussen de versies kan je het beste het hoofdtopic doorlezen. Maakt verder voor de werking niets uit: er is alleen van de buitenkant wat gewijzigd. De C vs E benaming slaat alleen op 2,56 kWh van 5,12 kWh, maar de interesse voor de tweede was zoveel groter dat C volgens mij nauwelijks meer verkrijgbaar is.

De aansturing via Modbus is onwijs stabiel daar is niets over te klagen, maar of het goed werkt EVCC durf ik niet te zeggen. Zijn maar een paar gebruikers hier die het daarover gehad hebben. Dat zal grotendeels afhangen van de integratie daar.

[superduper1969]

JSTAL schreef op dinsdag 12 augustus 2025 @ 17:32:
There is a warning message when compiling the lilygo-rs485.yaml code.

#warning "The legacy RMT driver is deprecated, please use driver/rmt_tx.h and/or driver/rmt_rx.h"

[Afbeelding]

This is due to the usage of the LED - neopixelbus.

You can solve this by changing the code as follows:

light:
# - platform: neopixelbus
# type: GRB
# variant: WS2812

- platform: esp32_rmt_led_strip
rgb_order: GRB
chipset: WS2812

Ja dat was me al opgevallen, maar ik had er nog geen tijd voor gehad.

Heb je het zelf al getest?

[JanAllElectric]

superduper1969 schreef op dinsdag 12 augustus 2025 @ 19:46:
[...]

Ja dat was me al opgevallen, maar ik had er nog geen tijd voor gehad.

Heb je het zelf al getest?

Aanpassing LED code toegepast op mijn 3 lilygo's. Werkt zonder foutmeldingen_/-\o_

[ Voor 3% gewijzigd door JanAllElectric op 12-08-2025 22:32 ]

[JSTAL]

superduper1969 schreef op dinsdag 12 augustus 2025 @ 19:46:
[...]

Ja dat was me al opgevallen, maar ik had er nog geen tijd voor gehad.

Heb je het zelf al getest?

ik heb de info hiervoor gehaald uit het Home Assistant forum

en ja, getest - geen compilatie warning en LED werkt .

(en sorry voor het gebruik van Engelse taal in mijn vorige post - had er niet opgelet)

[[RNMC] Viper]

fRiEtJeSaTe schreef op dinsdag 12 augustus 2025 @ 18:16:
Ik sta aan de rand mee te gluren nog zonder de diepte in te gaan. Ik draai EVCC en wil graag een Marstek Venus E 5,12kwh toevoegen. Lees over meerdere versies accu.

Als ik de laatste versie aanschaf (de E?) en de boel aansluit met een LilyGo wifi T-CAN485. Heb ik dan een stabiel draaiende oplossing die ik los kan laten? Of zitten we nog in het stadium lekker pielen?

Ik draai nu enige tijd een E met evcc en Home Assistant via modbus proxy en een EW11, dit werkt stabiel.

[SatScan]

superduper1969 schreef op dinsdag 12 augustus 2025 @ 19:46:
[...]

Ja dat was me al opgevallen, maar ik had er nog geen tijd voor gehad.

Heb je het zelf al getest?

Getest en het werkt!

[Marco_64]

superduper1969 schreef op dinsdag 12 augustus 2025 @ 19:46:
[...]

Ja dat was me al opgevallen, maar ik had er nog geen tijd voor gehad.

Heb je het zelf al getest?

Heb het net ook doorgevoerd en getest.

Een suggestie als je toch de code gaat aanpassen. Waarom niet werken met een include-file voor de sensoren en andere 'common' settings zodat je slechts op 1 plaats dient aan te passen ipv 3?

Ik heb je code in die zin aangepast:

code:

# Change the naming below, they will be the names used in Home Assistant
#
substitutions:
  device_name: energycube2
  friendly_name: EnergyCube2
  device_ip: 192.168.1.78
  
esphome:
  name: ${device_name}
  friendly_name: ${friendly_name}
  min_version: 2024.11.0
  name_add_mac_suffix: false

esp32:
  board: esp32dev
  framework:
    type: arduino

# Include common sections for wifi and others
<<: !include includes/common.yaml

# Include Sensor declarations
<<: !include includes/marstek_sensors.yaml

In de subdiretory includes heb je dan de files met wifi settings e.d. en de file met sensor declaraties.
Met de substitutions sectie kan je dan de specifieke waarden per batterij doorgeven zoals naam en ip-adres.

common.yaml wordt dan:

code:

# Enable logging
logger:
  level: INFO
#  level: VERY_VERBOSE

# Enable Home Assistant API
api:

# Allow Over-The-Air updates
ota:
  - platform: esphome
    password: !secret ota_password

wifi:
  ssid: !secret wifi_ssid
  password: !secret wifi_password
  manual_ip:
    static_ip: $device_ip  # Het gewenste IP-adres
    gateway: 192.168.1.1   # Het IP-adres van je router
    subnet: 255.255.255.0  # Meestal 255.255.255.0
    dns1: 192.168.1.1      # Optioneel: IP-adres van je DNS server (vaak je router)
    dns2: 8.8.8.8          # Optioneel: Google's publieke DNS server
  # Enable fallback hotspot (captive portal) in case wifi connection fails
  ap:
    ssid: $friendly_name
    password: !secret ota_password

captive_portal:

web_server:
  port: 80
  version: 3
  include_internal: False
#  ota: False
  local: True
  sorting_groups:
    - id: Info
      name: "Info"
      sorting_weight: -40
    - id: Control
      name: "Control"
      sorting_weight: -30
    - id: Status
      name: "Status"
      sorting_weight: -20
    - id: Diagnostic
      name: "Diagnostic"
      sorting_weight: -10

# Set pins required for LilyGo T-CAN485 board
output:
  - platform: gpio
    id: ENABLE_PIN # Enable the chip
    pin:
      number: GPIO19
      inverted: true

  - platform: gpio
    id: SE_PIN # Enable autodirection
    pin:
      number: GPIO17
      inverted: true

  - platform: gpio
    id: ENABLE_5V_PIN # Enable 5V pin for RS485 chip
    pin:
      number: GPIO16
      inverted: true

# Configure UART
uart:
  - id: mod_bus
    rx_pin: GPIO21
    tx_pin: GPIO22
    baud_rate: 115200
    data_bits: 8
    stop_bits: 1
    parity: NONE

modbus:
  - uart_id: mod_bus
    id: modbus1
    send_wait_time: 30ms

modbus_controller:
  - id: mt
    address: 0x1
    modbus_id: modbus1
    command_throttle: 30ms
    update_interval: 5s

Idem voor de sensoren, die staan dan in een gemeenschappelijke include file : marstek_sensors.yaml

Enfin, het is maar een suggestie die werkt voor mij.

[Mirabis]

pascallj schreef op dinsdag 12 augustus 2025 @ 19:21:
[...]


Voor verschillen tussen de versies kan je het beste het hoofdtopic doorlezen. Maakt verder voor de werking niets uit: er is alleen van de buitenkant wat gewijzigd. De C vs E benaming slaat alleen op 2,56 kWh van 5,12 kWh, maar de interesse voor de tweede was zoveel groter dat C volgens mij nauwelijks meer verkrijgbaar is.

De aansturing via Modbus is onwijs stabiel daar is niets over te klagen, maar of het goed werkt EVCC durf ik niet te zeggen. Zijn maar een paar gebruikers hier die het daarover gehad hebben. Dat zal grotendeels afhangen van de integratie daar.

Zelf heb ik EVCC -> HomeAssistant -> LilyGo (modbus) -> Marstek. Op die manier cached HA de calls van EVCC als de waardes nog niet veranderd zijn en is er minder modbus verkeer.

Werkt prima maar heb EVCC tijdelijk uitgeschakeld om weer gebruik te maken van Tibber Grid Rewards.

[WargamingPlayer]

Animal schreef op dinsdag 12 augustus 2025 @ 10:00:
Is er een reden dat de instelling niet op 11 procent kan maar minimaal 12 procent?

Intern trekt de Marstek er 1 van af. De register waarde 120is eigenlijk 11% in de App.

Stiekem denk ik echter dat het 12% is maar dat ze 11% weergeven om de verliezen wat te verbergen 🙈

[WargamingPlayer]

Inmiddels net een App update gehad en een firmware update. Helaas niet thuis om de firmware update te testen. Maar ik kan nu wel in de App weer Noordpool gebruiken, echter werkt dit niet tot mijn Firmware is bijgewerkt.

Ik ben nu benieuwd of dit dus ook in de Modbus waarde is terug te vinden.

[pascallj]

WargamingPlayer schreef op woensdag 13 augustus 2025 @ 12:31:
Inmiddels net een App update gehad en een firmware update. Helaas niet thuis om de firmware update te testen. Maar ik kan nu wel in de App weer Noordpool gebruiken, echter werkt dit niet tot mijn Firmware is bijgewerkt.

Ik ben nu benieuwd of dit dus ook in de Modbus waarde is terug te vinden.

De AI functionaliteit is niet afhankelijk van de firmware update. Het werkte voorheen ook, toen na een server wijziging niet meer, en nu weer wel. Het heeft met de laatste app namelijk zowel wel als niet gewerkt. Het werkt nu zonder wijziging aan firmware of app ook weer direct. Althans het instellen van het land. Of het op de achtergrond ook daadwerkelijk wat doet, heb ik niet getest.

Welke Modbus waarde hoop je te vinden?

[WargamingPlayer]

pascallj schreef op woensdag 13 augustus 2025 @ 12:36:
[...]


De AI functionaliteit is niet afhankelijk van de firmware update. Het werkte voorheen ook, toen na een server wijziging niet meer, en nu weer wel. Het heeft met de laatste app namelijk zowel wel als niet gewerkt. Het werkt nu zonder wijziging aan firmware of app ook weer direct. Althans het instellen van het land. Of het op de achtergrond ook daadwerkelijk wat doet, heb ik niet getest.

Welke Modbus waarde hoop je te vinden?

De waardes 0, 1, 2 of die nu wel goed staan. Wanneer ik 2 doe (AI/Trade) dan geeft uitlezen altijd 1 aan (NOM).

[pascallj]

WargamingPlayer schreef op woensdag 13 augustus 2025 @ 13:06:
[...]

De waardes 0, 1, 2 of die nu wel goed staan. Wanneer ik 2 doe (AI/Trade) dan geeft uitlezen altijd 1 aan (NOM).

Oh zo, ja dat klopt inderdaad. Daarvoor zou er een EMS update moeten komen en die heb ik nog niet gezien. Alhoewel sommigen al firmware 154 voorbij hebben zien komen. Maar aangezien Modbus geen prioriteit heeft bij Marstek, verwacht ik op dat vlak weinig updates.

[superduper1969]

Marco_64 schreef op woensdag 13 augustus 2025 @ 11:25:
[...]

Heb het net ook doorgevoerd en getest.

Een suggestie als je toch de code gaat aanpassen. Waarom niet werken met een include-file voor de sensoren en andere 'common' settings zodat je slechts op 1 plaats dient aan te passen ipv 3?

Ik heb je code in die zin aangepast:

code:

# Change the naming below, they will be the names used in Home Assistant
#
substitutions:
  device_name: energycube2
  friendly_name: EnergyCube2
  device_ip: 192.168.1.78
  
esphome:
  name: ${device_name}
  friendly_name: ${friendly_name}
  min_version: 2024.11.0
  name_add_mac_suffix: false

esp32:
  board: esp32dev
  framework:
    type: arduino

# Include common sections for wifi and others
<<: !include includes/common.yaml

# Include Sensor declarations
<<: !include includes/marstek_sensors.yaml

In de subdiretory includes heb je dan de files met wifi settings e.d. en de file met sensor declaraties.
Met de substitutions sectie kan je dan de specifieke waarden per batterij doorgeven zoals naam en ip-adres.

common.yaml wordt dan:

code:

# Enable logging
logger:
  level: INFO
#  level: VERY_VERBOSE

# Enable Home Assistant API
api:

# Allow Over-The-Air updates
ota:
  - platform: esphome
    password: !secret ota_password

wifi:
  ssid: !secret wifi_ssid
  password: !secret wifi_password
  manual_ip:
    static_ip: $device_ip  # Het gewenste IP-adres
    gateway: 192.168.1.1   # Het IP-adres van je router
    subnet: 255.255.255.0  # Meestal 255.255.255.0
    dns1: 192.168.1.1      # Optioneel: IP-adres van je DNS server (vaak je router)
    dns2: 8.8.8.8          # Optioneel: Google's publieke DNS server
  # Enable fallback hotspot (captive portal) in case wifi connection fails
  ap:
    ssid: $friendly_name
    password: !secret ota_password

captive_portal:

web_server:
  port: 80
  version: 3
  include_internal: False
#  ota: False
  local: True
  sorting_groups:
    - id: Info
      name: "Info"
      sorting_weight: -40
    - id: Control
      name: "Control"
      sorting_weight: -30
    - id: Status
      name: "Status"
      sorting_weight: -20
    - id: Diagnostic
      name: "Diagnostic"
      sorting_weight: -10

# Set pins required for LilyGo T-CAN485 board
output:
  - platform: gpio
    id: ENABLE_PIN # Enable the chip
    pin:
      number: GPIO19
      inverted: true

  - platform: gpio
    id: SE_PIN # Enable autodirection
    pin:
      number: GPIO17
      inverted: true

  - platform: gpio
    id: ENABLE_5V_PIN # Enable 5V pin for RS485 chip
    pin:
      number: GPIO16
      inverted: true

# Configure UART
uart:
  - id: mod_bus
    rx_pin: GPIO21
    tx_pin: GPIO22
    baud_rate: 115200
    data_bits: 8
    stop_bits: 1
    parity: NONE

modbus:
  - uart_id: mod_bus
    id: modbus1
    send_wait_time: 30ms

modbus_controller:
  - id: mt
    address: 0x1
    modbus_id: modbus1
    command_throttle: 30ms
    update_interval: 5s

Idem voor de sensoren, die staan dan in een gemeenschappelijke include file : marstek_sensors.yaml

Enfin, het is maar een suggestie die werkt voor mij.

Klinkt als een goed idee, ik zal er eens naar kijken.

Ik ben er in December ingerold en ben er in kennis er veel op vooruit gegaan maar voor nieuwe ideeen volledig afhankelijk van tips uit het forum.

[WargamingPlayer]

pascallj schreef op woensdag 13 augustus 2025 @ 13:08:
[...]


Oh zo, ja dat klopt inderdaad. Daarvoor zou er een EMS update moeten komen en die heb ik nog niet gezien. Alhoewel sommigen al firmware 154 voorbij hebben zien komen. Maar aangezien Modbus geen prioriteit heeft bij Marstek, verwacht ik op dat vlak weinig updates.

Ik heb dus vandaag de update van 151/215 naar 154/215 gekregen. En de eerste keer dat de update zo vlekkeloos ging. Ik drukte op update en na de herstart, zonder manuele interventie, was hij bijgewerkt. Zelfs de Modbus koppeling met mijn EW11 hoefde niet los.

[superduper1969]

Topicstart aangepast:
-13-8-2025 Lilygo Github neopixelbus > esp32_rmt_led_strip @TDSgame

[nheinemans]

Sinds maandag een MT hier in huis. Deze vervangt de Home Wizard PiB (te klein en relatief duur tov de MT). Aangezien de MT de enige thuisbatterij is, staat deze ingesteld op NoM.

Meteen een Elvin EW11 erop aangesloten, met de modbus integratie in HA. Werkt perfect, kan de MT mooi in de gaten houden.

Nu heb ik de MT aangesloten op een eigen alamat, die een bestaande leiding naar de meterkast deelt met de PV omvormer (die ook een eigen alamat heeft). Aangezien deze leiding is afgezekerd op 16A, wil ik afhankelijk van het vermogen van de PV omvormer de MT discharge kunnen beperken. Als ik de MT op 2500W instel, is het namelijk mogelijk dat het totale vermogen van de MT en PV hoger wordt dan 3680W.

Bijvoorbeeld door om te wisselen tussen 800W en 2500W, maar nog beter door de limiet aan te passen (ID 44003?). Dit lukt me echter niet vanuit HA. Mist deze functionaliteit in de modbus yaml van @superduper1969 ? Of is dit niet mogelijk om aan te passen via de modbus?

[superduper1969]

nheinemans schreef op woensdag 13 augustus 2025 @ 20:04:
Sinds maandag een MT hier in huis. Deze vervangt de Home Wizard PiB (te klein en relatief duur tov de MT). Aangezien de MT de enige thuisbatterij is, staat deze ingesteld op NoM.

Meteen een Elvin EW11 erop aangesloten, met de modbus integratie in HA. Werkt perfect, kan de MT mooi in de gaten houden.

Nu heb ik de MT aangesloten op een eigen alamat, die een bestaande leiding naar de meterkast deelt met de PV omvormer (die ook een eigen alamat heeft). Aangezien deze leiding is afgezekerd op 16A, wil ik afhankelijk van het vermogen van de PV omvormer de MT discharge kunnen beperken. Als ik de MT op 2500W instel, is het namelijk mogelijk dat het totale vermogen van de MT en PV hoger wordt dan 3680W.

Bijvoorbeeld door om te wisselen tussen 800W en 2500W, maar nog beter door de limiet aan te passen (ID 44003?). Dit lukt me echter niet vanuit HA. Mist deze functionaliteit in de modbus yaml van @superduper1969 ? Of is dit niet mogelijk om aan te passen via de modbus?

Samen met de PV omvormer = niet op een aparte groep = 800w
Normaliter zou al je PV veel opwekt dit direct in de accu komen of het net op gaan.
Maar als je een NOG grotere verbruiker hebt Auto/kookplaat kom je inderdaad in gevaar!

Op dit moment is de switch van 800W naar 2500W alleen in de app en dat lijkt me ook veiliger i.v.m. de verplichtte veiligheid melding.
Als hij daarop staat kun je met de huidige parameters sturen maar dat moet je volledige NOM automatisering vanuit HA worden gedaan.
Als je hem per ongeluk in de app of via HA op NOM of AI zet heb je geen enkele controle dus dit lijkt mij geen goed plan.

[superduper1969]

Marco_64 schreef op woensdag 13 augustus 2025 @ 11:25:
[...]

Heb het net ook doorgevoerd en getest.

Een suggestie als je toch de code gaat aanpassen. Waarom niet werken met een include-file voor de sensoren en andere 'common' settings zodat je slechts op 1 plaats dient aan te passen ipv 3?

Ik heb je code in die zin aangepast:

code:

# Change the naming below, they will be the names used in Home Assistant
#
substitutions:
  device_name: energycube2
  friendly_name: EnergyCube2
  device_ip: 192.168.1.78
  
esphome:
  name: ${device_name}
  friendly_name: ${friendly_name}
  min_version: 2024.11.0
  name_add_mac_suffix: false

esp32:
  board: esp32dev
  framework:
    type: arduino

# Include common sections for wifi and others
<<: !include includes/common.yaml

# Include Sensor declarations
<<: !include includes/marstek_sensors.yaml

In de subdiretory includes heb je dan de files met wifi settings e.d. en de file met sensor declaraties.
Met de substitutions sectie kan je dan de specifieke waarden per batterij doorgeven zoals naam en ip-adres.

common.yaml wordt dan:

code:

# Enable logging
logger:
  level: INFO
#  level: VERY_VERBOSE

# Enable Home Assistant API
api:

# Allow Over-The-Air updates
ota:
  - platform: esphome
    password: !secret ota_password

wifi:
  ssid: !secret wifi_ssid
  password: !secret wifi_password
  manual_ip:
    static_ip: $device_ip  # Het gewenste IP-adres
    gateway: 192.168.1.1   # Het IP-adres van je router
    subnet: 255.255.255.0  # Meestal 255.255.255.0
    dns1: 192.168.1.1      # Optioneel: IP-adres van je DNS server (vaak je router)
    dns2: 8.8.8.8          # Optioneel: Google's publieke DNS server
  # Enable fallback hotspot (captive portal) in case wifi connection fails
  ap:
    ssid: $friendly_name
    password: !secret ota_password

captive_portal:

web_server:
  port: 80
  version: 3
  include_internal: False
#  ota: False
  local: True
  sorting_groups:
    - id: Info
      name: "Info"
      sorting_weight: -40
    - id: Control
      name: "Control"
      sorting_weight: -30
    - id: Status
      name: "Status"
      sorting_weight: -20
    - id: Diagnostic
      name: "Diagnostic"
      sorting_weight: -10

# Set pins required for LilyGo T-CAN485 board
output:
  - platform: gpio
    id: ENABLE_PIN # Enable the chip
    pin:
      number: GPIO19
      inverted: true

  - platform: gpio
    id: SE_PIN # Enable autodirection
    pin:
      number: GPIO17
      inverted: true

  - platform: gpio
    id: ENABLE_5V_PIN # Enable 5V pin for RS485 chip
    pin:
      number: GPIO16
      inverted: true

# Configure UART
uart:
  - id: mod_bus
    rx_pin: GPIO21
    tx_pin: GPIO22
    baud_rate: 115200
    data_bits: 8
    stop_bits: 1
    parity: NONE

modbus:
  - uart_id: mod_bus
    id: modbus1
    send_wait_time: 30ms

modbus_controller:
  - id: mt
    address: 0x1
    modbus_id: modbus1
    command_throttle: 30ms
    update_interval: 5s

Idem voor de sensoren, die staan dan in een gemeenschappelijke include file : marstek_sensors.yaml

Enfin, het is maar een suggestie die werkt voor mij.

Ik heb een plekje op Github gereserveerd om eraan te werken:https://github.com/Superd...85/tree/main/LilygoWifiV2
Had je toevallig al een opzetje voor marstek_sensors.yaml?

[nheinemans]

superduper1969 schreef op woensdag 13 augustus 2025 @ 20:26:
[...]

Samen met de PV omvormer = niet op een aparte groep = 800w
Normaliter zou al je PV veel opwekt dit direct in de accu komen of het net op gaan.
Maar als je een NOG grotere verbruiker hebt Auto/kookplaat kom je inderdaad in gevaar!

Op dit moment is de switch van 800W naar 2500W alleen in de app en dat lijkt me ook veiliger i.v.m. de verplichtte veiligheid melding.
Als hij daarop staat kun je met de huidige parameters sturen maar dat moet je volledige NOM automatisering vanuit HA worden gedaan.
Als je hem per ongeluk in de app of via HA op NOM of AI zet heb je geen enkele controle dus dit lijkt mij geen goed plan.

Bedankt, daar was ik al bang voor. Ik laat 'm voorlopig op 800W staan en ga eens op zoek naar een andere plek in huis waar ik een volledige eigen groep voor de MT kan aanleggen.

[pascallj]

superduper1969 schreef op woensdag 13 augustus 2025 @ 20:26:
[...]

Samen met de PV omvormer = niet op een aparte groep = 800w
Normaliter zou al je PV veel opwekt dit direct in de accu komen of het net op gaan.
Maar als je een NOG grotere verbruiker hebt Auto/kookplaat kom je inderdaad in gevaar!

Op dit moment is de switch van 800W naar 2500W alleen in de app en dat lijkt me ook veiliger i.v.m. de verplichtte veiligheid melding.
Als hij daarop staat kun je met de huidige parameters sturen maar dat moet je volledige NOM automatisering vanuit HA worden gedaan.
Als je hem per ongeluk in de app of via HA op NOM of AI zet heb je geen enkele controle dus dit lijkt mij geen goed plan.

Als er op die leiding een PV verdeler is aangesloten waarbij zowel de leiding is afgezekerd op 16 A, als ook de PV zelf en het stopcontact van de verdeler, is er op zich geen risico. Je hebt alleen kans dat je zekeringen afslaan, maar dan is het wel veilig.

[nheinemans]

pascallj schreef op woensdag 13 augustus 2025 @ 20:52:
[...]


Als er op die leiding een PV verdeler is aangesloten waarbij zowel de leiding is afgezekerd op 16 A, als ook de PV zelf en het stopcontact van de verdeler, is er op zich geen risico. Je hebt alleen kans dat je zekeringen afslaan, maar dan is het wel veilig.

Dat is bij mij inderdaad het geval, maar ik zie liever geen zekeringen afslaan. Daarom wilde ik de MT discharge beperken als de zonnepanelen maximaal produceren. Ik had gehoopt dat dit mogelijk zou zijn via de modbus, maar als ik het goed begrijp alleen in manuele modus, dus als ik de MT vanuit HA aanstuur.

[pascallj]

nheinemans schreef op woensdag 13 augustus 2025 @ 23:00:
[...]

Dat is bij mij inderdaad het geval, maar ik zie liever geen zekeringen afslaan. Daarom wilde ik de MT discharge beperken als de zonnepanelen maximaal produceren. Ik had gehoopt dat dit mogelijk zou zijn via de modbus, maar als ik het goed begrijp alleen in manuele modus, dus als ik de MT vanuit HA aanstuur.

Dat dacht ik al. Dat is prima mogelijk hoor. Dat kan inderdaad met het register wat jij noemde. Je zal hem eerst moeten unlocken via de App (kan ook wel via Modbus, maar dat heeft volgens mij nog niemand geïmplementeerd), en dan kan je het ontlaadvermogen verder beperken. Dit geldt voor het hele apparaat, dus voor alle modi.

Ik onthield mij alleen van een antwoord omdat ik geen idee wat er wel en niet in de Elfin configuratie verwerkt is. De LilyGo configuratie wordt onderhouden, de Elfin configuratie volgens mij niet meer.

[GoBieN-Be]

Dank voor het vele werk. Ik heb een LilyGO up & running sinds deze avond.

Kunnen we de RTE waarde niet berekenen en toevoegen als sensor op de ESP?
Dit werkt voor mij:

code:

  - platform: template
    name: "Marstek RTE Total"
    id: "marstek_rte_total"
    unit_of_measurement: "%"
    icon: mdi:percent
    accuracy_decimals: 1
    update_interval: 5min
    lambda: |-
      float totalcharging = id(lilygo_rs485_marstek_total_charging_energy).state;
      float totaldischarging = id(lilygo_rs485_marstek_total_discharging_energy).state;
      if (totalcharging > 0) {
        return (totaldischarging / totalcharging) * 100.0;
      } else {
        return NAN;
      }

  - platform: template
    name: "Marstek RTE Daily"
    id: "marstek_rte_daily"
    unit_of_measurement: "%"
    icon: mdi:percent
    accuracy_decimals: 1
    update_interval: 5min
    lambda: |-
      float dailycharging = id(lilygo_rs485_marstek_daily_charging_energy).state;
      float dailydischarging = id(lilygo_rs485_marstek_daily_discharging_energy).state;
      if (dailycharging > 0) {
        return (dailydischarging / dailycharging) * 100.0;
      } else {
        return NAN;
      }

[GoBieN-Be]

De daily waarde reset zichzelf wel om middernacht natuurlijk.
Dus wellicht voor sommigen vertekend beeld op de daily waarde.