Marstek Venus / Duravolt PnP Thuisaccu Modbus koppeling

[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/

[Tazzios]

CoNsPiRaCyBE schreef op woensdag 10 december 2025 @ 21:49:
[...]


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/

Nee ik gebruik nog de modbus. Met local API kun je alleen de mode wijzigen en is zelf sturen zoals met de modbus niet mogelijk.
De blueprint die ik gebruik voor de aansturing via modbus heb ik zojuist weer bijgewerkt. Nu met support voor de esphome configs van fonske(@AUijtdehaag).

Marstek X Range OM Blueprint Versie 1.7
New: Support for fonske M5stack and fonske Lilygo
Fix: variable name in battery ac power calculation #4

Door #4 werd het geleverde vermogen van de batterij niet meegenomen in de setpoint. Dit veroorzaakte mogelijk veel wisselingen.

[monty_burns_007]

Modbus TCP met Viper's Modbus TCP Home Assistant Addon werkt idd perfect op mijn Venus E V3 (FW145) LAN poort.
Maar ik kan niet gelijktijdig meerdere Modbus Clients laten connecteren met de Marstek Modbus TCP.
Is dit bij iemand van jullie wel gelukt ?
Ik vermoed dat de Viper Modbus TCP HA addon continu poort 502 open houdt en dat dan andere clients (bv. test tool Modbus Poll) niet geconnecteerd geraakt ?

[Mirabis]

monty_burns_007 schreef op donderdag 11 december 2025 @ 14:25:
Modbus TCP met Viper's Modbus TCP Home Assistant Addon werkt idd perfect op mijn Venus E V3 (FW145) LAN poort.
Maar ik kan niet gelijktijdig meerdere Modbus Clients laten connecteren met de Marstek Modbus TCP.
Is dit bij iemand van jullie wel gelukt ?
Ik vermoed dat de Viper Modbus TCP HA addon continu poort 502 open houdt en dat dan andere clients (bv. test tool Modbus Poll) niet geconnecteerd geraakt ?

Enkele devices staan maar een gelimiteerd aantal (gelijktijdige) Modbus TCP clients toe. In het slechtste geval is er maar één connectie toegestaan. Vaak kan je dan wel een 'modbusproxy' toepassen.

[monty_burns_007]

heb deze modbus proxy getest: https://github.com/Akulatraxas/ha-modbusproxy
Viper modbus addon maakt connectie, maar parallel met bv. Modbus Poll tool registers lezen lukt nog niet.

[AUijtdehaag]

Rednas1977 schreef op woensdag 10 december 2025 @ 11:09:
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?

Heb al een paar mensen geholpen met:
- 1x odroid C4 (indien nog geen home assistant) met 32 of 64 gb emmc
- 3x M5stack RS485 Atom S3 bordjes voor V2 en V3
- Nodered installeren als addon in home assistant en deze erop knallen met als p1 meter een homewizard p1 wifi
Klaar

[lemuba]

monty_burns_007 schreef op donderdag 11 december 2025 @ 17:29:
heb deze modbus proxy getest: https://github.com/Akulatraxas/ha-modbusproxy
Viper modbus addon maakt connectie, maar parallel met bv. Modbus Poll tool registers lezen lukt nog niet.

Í´m using also Viperś Modbus Integration for my Venus E V2 and my Venus D. Both integrated to evcc, the Venus D via the easy to set up evcc Modbus Proxy via the evcc UI - it works perfect for both Home Assistant/Viper and evcc - Some screen shots posted in the German PV Forum:

https://www.photovoltaikf...ostID=4566917#post4566917

[[RNMC] Viper]

monty_burns_007 schreef op donderdag 11 december 2025 @ 14:25:
Modbus TCP met Viper's Modbus TCP Home Assistant Addon werkt idd perfect op mijn Venus E V3 (FW145) LAN poort.
Maar ik kan niet gelijktijdig meerdere Modbus Clients laten connecteren met de Marstek Modbus TCP.
Is dit bij iemand van jullie wel gelukt ?
Ik vermoed dat de Viper Modbus TCP HA addon continu poort 502 open houdt en dat dan andere clients (bv. test tool Modbus Poll) niet geconnecteerd geraakt ?

ik gebruik zelf icm met deze modbusproxy, zodat Home Assistant als evcc direct uit kan lezen
https://github.com/TCzerny/ha-modbusproxy

[ Voor 4% gewijzigd door [RNMC] Viper op 11-12-2025 22:37 ]

[monty_burns_007]

[RNMC] Viper schreef op donderdag 11 december 2025 @ 22:36:
[...]
ik gebruik zelf icm met deze modbusproxy, zodat Home Assistant als evcc direct uit kan lezen
https://github.com/TCzerny/ha-modbusproxy

cool ik had de originele HA proxy van jou gebruikt, maar de Fork die jij geeft staat blijkbaar verder qua opties en mogelijkheden.
Tevens heb ik mij vergist in de Modbus Adressering.

32200 32200 AC Voltage uint16 2 0.1 V sensor Battery AC voltage

ik ging ervan uit dat dit input registers waren (uitlezen met modbus FC04), dus ik was in voorbeeld boven altijd maar aan het proberen op register 2200 in de veronderstelling dat de eerste 3 de modbus input register code was. Maar blijkbaar zijn dit dan allemaal holding registers (4xxxxx) en voorbeeld boven moet je dan uitlezen met modbus FC03 op adres 32200 (of Modbus holding register 432201). Nu werkt het wel bij me. bedankt Viper ! top Modbus TCP integratie die je hebt gemaakt trouwens. Werkt op de venus E V3 op LAN poort.

[AUijtdehaag]

Nieuw filmpje van @GAEvakYD zijn collega Bob.
Uitleg over de dynamische strategie (tot nu toe) van de nodered flow.

Edit: op mijn github esphome voor lilygo en m5stack, lifetime RTE toegevoegd en een Uart logging switch, zodat logging standaard uit staat. (webserver en via esphome logging)

[ Voor 23% gewijzigd door AUijtdehaag op 14-12-2025 11:07 ]

[Jando]

Hallo,
Heeft iemand een idee wat ik fout doe?
Ik heb een automatisering in Home Assistant gemaakt voor het laden en ontladen (dynamisch) van mijn marstek venus 2. De laadautomatisering werkt goed, de ontlaadautomatisering krijg ik niet aan de praat. Misschien dat iemand ziet wat ik fout doe. Hieronder de code voor het laden en ontladen. Het ontladen is dus het probleem.

code:

- id: laad_batterij_goedkoopste_uren
  alias: Marstek laden tijdens goedkope uren
  triggers:
  - minutes: '0'
    trigger: time_pattern
  conditions:
  - condition: state
    entity_id: select.lilygo_rs485_marstek_485_master_control_switch
    state: RS485 Ingeschakeld
  actions:
  - variables:
      beheer_uren_list: '{{ states(''input_text.goedkoopste_laaduren'').split('','')
        | map(''int'', default=0) | list }}'
      current_hour: '{{ now().hour }}'
      soc: '{{ states(''sensor.modemrouter_marstek_battery_state_of_charge'') | int
        }}'
  - choose:
    - conditions:
      - condition: template
        value_template: '{{ current_hour in beheer_uren_list and soc < 100 }}'
      sequence:
      - target:
          entity_id: number.lilygo_rs485_marstek_forcible_charge_power
        data:
          value: 2500
        action: number.set_value
      - target:
          entity_id: select.lilygo_rs485_marstek_forcible_charge_discharge
        data:
          option: charge
        action: input_select.select_option
    default:
    - target:
        entity_id: select.lilygo_rs485_marstek_forcible_charge_discharge
      data:
        option: stop
      action: input_select.select_option
  mode: single
  
- id: ontlaad_batterij_dynamisch
  alias: marstek dynamisch ontladen op basis van huisvraag
  mode: restart
  trigger:
    - seconds: /10
      platform: time_pattern
  conditions:
    # Deze condities blijven hetzelfde
    - condition: time
      after: 09:00:00
      before: '21:00:00'
    - condition: state
      entity_id: select.lilygo_rs485_marstek_485_master_control_switch
      state: RS485 Ingeschakeld
    - condition: numeric_state
      entity_id: sensor.modemrouter_marstek_battery_state_of_charge
      above: 0.56
    # De conditie voor de goedkoopste uren (om laden te respecteren)
    - condition: template
      value_template: >
        {% set raw_input = states('input_text.goedkoopste_laaduren') | default('') %}
        {% if raw_input | trim == '' or raw_input == 'geen_uren_gevonden' %}
          {% set beheer_uren_list = [] %}
        {% else %}
          {% set beheer_uren_list = raw_input.split(',') | map('int', default=0) | list %}
        {% endif %}
        {% set current_hour = now().hour %}
        {{ current_hour not in beheer_uren_list }}

  actions:
    # Variabelen
    - variables:
        house_demand_w: '{{ states(''sensor.p1_meter_vermogen'') | int(0) }}'
        min_discharge_threshold: 50
        max_discharge_limit: 2500
        soc: '{{ states(''sensor.modemrouter_marstek_battery_state_of_charge'') | float(0) }}'
        target_power_w: >
          {% if house_demand_w >= min_discharge_threshold %}
            {{ [house_demand_w | int(0), max_discharge_limit] | min | max(0) }}
          {% else %}
            0
          {% endif %}

    # Bepaal nu of we op 'discharge' of 'stop' moeten zetten
    - choose:
        - conditions:
            - condition: template
              value_template: '{{ target_power_w > 0 }}'
          sequence:
            - service: select.select_option
              target:
                entity_id: select.lilygo_rs485_marstek_forcible_charge_discharge
              data:
                option: discharge
            - service: input_number.set_value
              target:
                entity_id: number.lilygo_rs485_marstek_forcible_discharge_power
              data:
                value: '{{ target_power_w }}'
      default:
        - service: select.select_option
          target:
            entity_id: select.lilygo_rs485_marstek_forcible_charge_discharge
          data:
            option: stop
        - service: input_number.set_value
          target:
            entity_id: number.lilygo_rs485_marstek_forcible_discharge_power
          data:
            value: 0

[AUijtdehaag]

@Jando
Gooi de vraag even door https://chatgpt.com/
Dan wordt er al wat duidelijker zag ik (0.56 ipv 56)

[ Voor 7% gewijzigd door AUijtdehaag op 14-12-2025 18:29 ]

[Tazzios]

@Jando
Via de opbouw die je nu gebruikt heb je kans (bij een foutje) dat meerdere scripts tegelijk je Marstek aan gaan aansturen. Nu heb je er nog 2, maar mogelijk kom je met de tijd op nog wat verschillende aansturingen.

Ik heb zelf een blueprint gemaakt die vrijwel alles kan (laden,ontladen,xom, overschot laden etc.). Met de blueprint heb ik meerdere automations(laden,ontladen, netsafe) gemaakt en 1 controller automation die er voor zorgt dat er maar 1 blueprint automation tegelijk draait (voorbeeld). Op deze wijze is de business logica en aansturingslogica ook wat meer gescheiden waardoor de automatisering overzichtelijk blijft.

[savale]

@Jando inderdaad wellicht slim om de blueprint van @Tazzios te gebruiken. Zodra mijn slimme meter geupgrade is ga ik daar ook mee aan de gang. Zal dan ook even kijken of ik de blueprint van @Tazzios kan uitbreiden met een optie om NOM via marstek te laten regelen. Verder lijkt het voor mijn eigen situatie al aardig compleet. Er is ook nog een node red oplossing: die heeft een PID aan boord en is wellicht het handigst als niet marstek NOM wilt gebruiken.

@Tazzios zie al dat je iets van smoothing gebruikt, maar wellicht tof om dit te integreren?
https://github.com/bvweerd/simple_pid_controller/

[ Voor 14% gewijzigd door savale op 14-12-2025 20:35 ]

[Jando]

Tazzios schreef op zondag 14 december 2025 @ 20:18:
@Jando
Via de opbouw die je nu gebruikt heb je kans (bij een foutje) dat meerdere scripts tegelijk je Marstek aan gaan aansturen. Nu heb je er nog 2, maar mogelijk kom je met de tijd op nog wat verschillende aansturingen.

Ik heb zelf een blueprint gemaakt die vrijwel alles kan (laden,ontladen,xom, overschot laden etc.). Met de blueprint heb ik meerdere automations(laden,ontladen, netsafe) gemaakt en 1 controller automation die er voor zorgt dat er maar 1 blueprint automation tegelijk draait (voorbeeld). Op deze wijze is de business logica en aansturingslogica ook wat meer gescheiden waardoor de automatisering overzichtelijk blijft.

Bedankt voor je reactie. Ga ik zeker eens naar kijken en voor zitten. Maar ik wil eerst mijn automatisering aan de praat hebben, anders weet ik niet wat er fout is en blijft dat mij misschien achtervolgen. Wellicht zie jij waar mijn ontlaadcode de fout in gaat?

[Tazzios]

@Jando
Voor debugging moet je vooral even naar je conditie kijken, bij "tracering weergeven" kun je zien waarom hij welke route neemt.
@AUijtdehaag heeft denk al een probleem aangekaart. Verder vind ik onderstaande sensor wat raar

code:

sensor.modemrouter_marstek_battery_state_of_charge

Ik zou lilygo_rs485_marstek_state_of_charge verwachten.

Welke esphome code gebruik je? Onderstaande entiteit komt namelijk niet voor bij Fonske of superduper1969 ( en werkt daardoor niet met mijn blueprint als je die zou willen gebruiken)
"lilygo_rs485_marstek_485_master_control_switch" versus "rs485_control_mode"

savale schreef op zondag 14 december 2025 @ 20:31:
@Jando inderdaad wellicht slim om de blueprint van @Tazzios te gebruiken. Zodra mijn slimme meter geupgrade is ga ik daar ook mee aan de gang. Zal dan ook even kijken of ik de blueprint van @Tazzios kan uitbreiden met een optie om NOM via marstek te laten regelen. Verder lijkt het voor mijn eigen situatie al aardig compleet. Er is ook nog een node red oplossing: die heeft een PID aan boord en is wellicht het handigst als niet marstek NOM wilt gebruiken.

Indien je Marstek zelf NOM wil laten doen zou dat vanuit de controller automation moeten. Dus een te kiezen optie toevoegen met de gewenste condities wanneer hij in Marsteks NOM moet. ik vermoed dat select.lilygo_rs485_marstek_rs485_control_mode op disable zetten voldoende is.

@Tazzios zie al dat je iets van smoothing gebruikt, maar wellicht tof om dit te integreren?
https://github.com/bvweerd/simple_pid_controller/

Ik had voor smoothing nog op de lijst een minimum delta ingedachte, de huidige is een maximum. Beide werken met absolute waardes. PID ziet er inderdaad ook aardig uit om toe te voegen.
Zoiets wordt het dan denk met instelbare alpha.

code:

  {% set alpha = 0.5 %}
  {% set current = 100 | float %}
  {% set prev = 150 | float(current) %}
  {{ (alpha * current + (1 - alpha) * prev) | round(2) }}

Resultaat 50% van verschil meenemen=125

Wat je eigenlijk ook zou willen is dat hij een zwaardere weging heeft rond de 0 om zo vooral het wisselen tussen laden en ontladen probeert te voorkomen.
Asymmetrische smoothing bij nuldoorgang en/of instelbare deadband ±50–100 W

[Hemmik]

AUijtdehaag schreef op zondag 14 december 2025 @ 09:26:
Nieuw filmpje van @GAEvakYD zijn collega Bob.
Uitleg over de dynamische strategie (tot nu toe) van de nodered flow.

[YouTube: Goedkope dynamische energie met een thuis accu door Home Assistant en Home Battery Control | HowTo]

Edit: op mijn github esphome voor lilygo en m5stack, lifetime RTE toegevoegd en een Uart logging switch, zodat logging standaard uit staat. (webserver en via esphome logging)

edit: nu toch zichtbaar ineens

[ Voor 20% gewijzigd door Hemmik op 15-12-2025 15:43 ]

[savale]

Goede ideeën omtrend PID / omschakelen laden / ontladen! @Tazzios.
Ja Marstek NOM is inderdaad kwesie van rs485 control uit en zorgen dat ie in anti-feed staat, dus niet echt iets voor de blueprint dan.

[AUijtdehaag]

Hemmik schreef op maandag 15 december 2025 @ 15:15:
[...]

edit: nu toch zichtbaar ineens

Welke esphome code draai je?

[Hemmik]

AUijtdehaag schreef op maandag 15 december 2025 @ 15:49:
[...]

Welke esphome code draai je?

Bedoel je lilygo-rs485.yaml? Ik gebruik een wat oudere configuratie van een aantal maanden geleden. Moest ook wat aanpassen aan dashboard.yaml om het aan de praat te krijgen. Misschien moet ik de code op de ESP32 ook maar eens updaten.. Is het aan te raden om lilygo_mt1.yaml te gebruiken?

[ Voor 6% gewijzigd door Hemmik op 15-12-2025 15:56 ]

[AUijtdehaag]

@Hemmik
Je zal er mijn code op moeten zetten anders worden de entiteiten niet herkend
lilygo_mt1_v3.yaml voor V3
of lilygo_mt1.yaml voor V1/V2
https://github.com/fonske/MarstekVenus-LilygoRS485

Zijn de laatste versies

[ Voor 6% gewijzigd door AUijtdehaag op 15-12-2025 15:57 ]

[Hemmik]

AUijtdehaag schreef op maandag 15 december 2025 @ 15:56:
@Hemmik
Je zal er mijn code op moeten zetten anders worden de entiteiten niet herkend
lilygo_mt1_v3.yaml voor V3
of lilygo_mt1.yaml voor V1/V2
https://github.com/fonske/MarstekVenus-LilygoRS485

Ik was hem net aan het editten toen je dit stuurde. Dank, dan ga ik dat doen!

[Hemmik]

AUijtdehaag schreef op maandag 15 december 2025 @ 15:56:
@Hemmik
Je zal er mijn code op moeten zetten anders worden de entiteiten niet herkend
lilygo_mt1_v3.yaml voor V3
of lilygo_mt1.yaml voor V1/V2
https://github.com/fonske/MarstekVenus-LilygoRS485

Zijn de laatste versies

Heb het inmiddels grotendeels aan de praat, dank! Wat echter niet lijkt te werken is het stukje met kosten onderaan. De cheapest hours integration lijkt wel te werken maar de prijzen blijven leeg. Ik gebruik de core integration van Tibber. Als ik hem op Tibber (custom) zet zie ik wel prijzen (al kloppen ze niet), maar kloppen de tijden niet. Enig idee?

[AUijtdehaag]

@Hemmik even op de discord server vragen?

[Hemmik]

AUijtdehaag schreef op dinsdag 16 december 2025 @ 14:58:
@Hemmik even op de discord server vragen?

Doe ik, dank!

[Tazzios]

savale schreef op maandag 15 december 2025 @ 15:34:
Goede ideeën omtrend PID / omschakelen laden / ontladen! @Tazzios.
...

Nog niet gemerged omdat het testen van de functies wat lastiger is, maar iedereen mag alvast meetesten/kijken natuurlijk.
Marstek X range on the Meter v1.8 Let's go smooth!

• Breaking: smoothing is renamed to smoothing_max_watts
• New: minimum different in setpoint change
• New: Zero deadband
• New: Smoothing factor
• New: Smoothing factor when passing zero

maar onderstaande afbeelding is misschien wat duidelijker:


hier te vinden https://github.com/Tazzio...ree/V1.8-Let's-go-smooth!en hopelijk binnenkort ook gewoon in de main branch.

[sheriff]

Hmm, zit ik heel de middag al te wachten op postnl voor de levering van mijn EW11 voor de modbus koppeling, alvast bekabeling gemaakt met rj45 connectors voor naar mijn Venus E V3.0 met v144.

Nu kom ik erachter dat de je die EW11 helemaal niet nodig hebt, je kunt de Viper software gewoon naar je Lan bekabelde Venus E V3.0 laten verwijzen op de aangegeven poort 502, en de koppeling naar HA werkt gewoon, helemaal geen EW11 nodig, of mis ik zonder EW11 functionaliteiten?

[Atomic2005]

Ik zou graag een Marstek willen met en zorgen dat deze van 2 fysiek gescheiden 3x25A aansluitingen gebruik maakt. ( Geen SAP, maar echt 2 fysiek gescheiden 3x 25A aansluitingen)

Eén om te laden, en de ander voor het ontladen.
Op beide aansluitingen zijn pv aanwezig.

In theorie zou ik een 1P+N motorized (ats BBM ) schakeling moeten hebben met een Shelly aansturing.
Met bijv een CHINT NXZ1-32 M-1P+N

Hebben meer mensen deze opstelling, kan de Marstek daar icm Home Assistant mee omgaan?

[ Voor 15% gewijzigd door Atomic2005 op 17-12-2025 00:35 ]

[pascallj]

Atomic2005 schreef op dinsdag 16 december 2025 @ 21:05:
Ik zou graag een Marstek willen met en zorgen dat deze van 2 fysiek gescheiden 3x25A aansluitingen gebruik maakt.

Eén om te laden, en de ander voor het ontladen.

In theorie zou ik een 1P+N motorized (ats BBM ) schakeling moeten hebben met een Shelly aansturing.

Hebben meer mensen deze opstelling, kan de Marstek daar icm Home Assistant mee omgaan?

Is de reden dat je dit wilt doen dat je een SAP hebt? Heb je wel eens doorgerekend of dat echt wel zin heeft? Ik denk dat je al een tijd bezig bent om al je apparatuur terug te verdienen...

In theorie zie ik geen problemen, als je maar zorgt dat de batterij in stand-by staat voordat je gaat schakelen. Schakelen bij belasting is niet goed voor de levensduur. Ik denk ook dat je ATS niet te snel moet zijn zodat de Marstek tijd heeft om echt te detecteren dat het net wegvalt en weer terugkomt ipv dat het een storing is.

[GoBieN-Be]

sheriff schreef op dinsdag 16 december 2025 @ 17:35:
Hmm, zit ik heel de middag al te wachten op postnl voor de levering van mijn EW11 voor de modbus koppeling, alvast bekabeling gemaakt met rj45 connectors voor naar mijn Venus E V3.0 met v144.

Nu kom ik erachter dat de je die EW11 helemaal niet nodig hebt, je kunt de Viper software gewoon naar je Lan bekabelde Venus E V3.0 laten verwijzen op de aangegeven poort 502, en de koppeling naar HA werkt gewoon, helemaal geen EW11 nodig, of mis ik zonder EW11 functionaliteiten?

Dat is inderdaad een recente ontdekking op de V3. Was nog niet helemaal duidelijk als het enkel vanaf een bepaalde firmware was. Hier V2 dus kan niet testen.

[sheriff]

Ik kan overigens maar vanaf 1 HomeAssistant tegelijk verbinding maken, als op de ene server de integratie actief is kan ik op de ander niet verbinden, en andersom ook.
Is dat met hardware zoals EW11 of Lilygo ook zo, of is daar misschien geen beperking ?

[GoBieN-Be]

Hangt er vanaf welke implementatie.

Bij een bridge config spreek je modbus TCP met de EW11 en die weer modbus RTU met de Marstek. De sensoren zitten dan in een HA integratie.

Met de standaard ESPhome implementatie op de LilyGO spreekt die modbus RTU met de Marstek en leest HA gewoon de sensoren uit via de ESPhome API. Wellicht kunnen meerdere gebruikers die ESPhome API tegelijk uitlezen.

[ Voor 6% gewijzigd door GoBieN-Be op 17-12-2025 00:24 ]

[afnay]

GoBieN-Be schreef op dinsdag 16 december 2025 @ 23:55:
[...]

Dat is inderdaad een recente ontdekking op de V3. Was nog niet helemaal duidelijk als het enkel vanaf een bepaalde firmware was. Hier V2 dus kan niet testen.

Ik heb een verse, Venus E 3.01, vorige week geleverd met een oudere firmware : v135
Vandaag wat zitten rammen in de app op het lijntje "device v135",
eerst kreeg ik nog je hebt de laatste versie,
maar na jaren net zoals bij android om "Developer Mode" te krijgen wat blijven rammen op de versie en plots kreeg ik v145 aangeboden. Toeval ? Misschien kan iemand het eens proberen ?

Na de upgrade kon ik alvast met telnet connectie maken op port 502.

Snel even via HACS de custom repo https://github.com/ViperRNMC/marstek_venus_modbus bijgevoegd en het werkt ! Over de LAN met v145

[ Voor 60% gewijzigd door afnay op 17-12-2025 22:09 ]

[pascallj]

afnay schreef op woensdag 17 december 2025 @ 21:50:
[...]


Ik heb een verse, Venus E 3.01, vorige week geleverd met een oudere firmware : v135
Vandaag wat zitten rammen in de app op het lijntje "device v135",
eerst kreeg ik nog je hebt de laatste versie,
maar na jaren net zoals bij android om "Developer Mode" te krijgen wat blijven rammen op de versie en plots kreeg ik v145 aangeboden. Toeval ? Misschien kan iemand het eens proberen ?

Na de upgrade kon ik alvast met telnet connectie maken op port 502.

Haha dat van die developer mode herken ik maar al te goed

Niet toevallig ondertussen via Feedback om een andere versie gevraagd?

[afnay]

pascallj schreef op woensdag 17 december 2025 @ 22:01:
[...]


Haha dat van die developer mode herken ik maar al te goed

Niet toevallig ondertussen via Feedback om een andere versie gevraagd?

Nee, ik heb de feedback button nog niet tegengekomen.
Werd er deze middag net v145 uitgerold ? Gemakkelijk te testen als iemand een nieuwe versie snel wil proberen te pakken te krijgen.

[pascallj]

afnay schreef op woensdag 17 december 2025 @ 22:05:
[...]


Nee, ik heb de feedback button nog niet tegengekomen.
Werd er deze middag net v145 uitgerold ? Gemakkelijk te testen als iemand een nieuwe versie snel wil proberen te pakken te krijgen.

v145 voor de V3 is in de afgelopen dagen al vaker uitgerold voor mensen die daar om vroegen (zie hoofdtopic), maar heb nog geen meldingen gezien dat het vanzelf is gegaan zonder erom te vragen. Zien al maanden geen automatische updates zonder feedback meer eigenlijk.

Ik heb jouw methode geprobeerd bij mijn V1, maar na 20 keer drukken is er nog geen update. Ik zit nog op v153 en de nieuwste versie daarvoor is al v156.

Overigens zit de feedback knop onder 'Hulp en Feedback' in het menu.