Marstek Venus / Duravolt PnP Thuisaccu Modbus koppeling

[pascallj]

comfix schreef op maandag 13 oktober 2025 @ 21:44:
[...]


Klopt.. kunnen we ergens een kb maken? GitHub ofzo? Want wat zijn nu de juiste kleuren?
Hoe snel reageert Marstek trouwens?

Dat ligt eraan hoe je kabel bedraad is. Niet elke Ethernet kabel is hetzelfde. Zoals ik al zei zit het RS485 paar altijd op pin 1&2. Dit is meestal oranje-wit en oranje, maar kan ook groen-wit en groen zijn. Zie ook mijn post die ik specifiek aan jou gericht had.

Gelukkig hebben ze de pin-out zo gemaakt dat je het veilig kan proberen.

Kan even duren voordat ze reageren. Soms binnen een dag, soms een week, soms 2. Ze hebben net feestdagen achter de rug daar, dus zou er niet op wachten.

[superduper1969]

pascallj schreef op maandag 13 oktober 2025 @ 21:28:
[...]


Oja sorry het RS485 paar is hetzelfde gebleven, alleen de 5V en GND kloppen niet.

@superduper1969, kan je die pin-out van thuisbatterij uit de TS halen? Iedereen pakt die als eerst en heeft al voor veel verwarring gezorgd. Zie de post hierboven waar ook de 5V als GND gebruikt is. Of duidelijk vermelden dat de labels niet kloppen oid.

Plaatje verwijderd, is de tekst wel goed?

[amvolleb]

superduper1969 schreef op maandag 13 oktober 2025 @ 22:22:
[...]

Plaatje verwijderd, is de tekst wel goed?

ik heb sinds vorige week ook een V3 batterij erbij en heb deze (van de TS) gebruikt:
RS485 A : Oranje-wit
+ 5V : Blauw en/of Blauw-wit (ik heb de blauwe gebruikt)
- GND : Bruin en/of Bruin-Wit (ik heb de bruine gebruikt)
RS485 B : Oranje

Dat werkte prima

[ Voor 6% gewijzigd door amvolleb op 13-10-2025 22:26 ]

[amvolleb]

pascallj schreef op maandag 13 oktober 2025 @ 21:14:
[...]


Register 37004 zou je alvast kunnen testen. Die scheen voor de update ook te kunnen werken.

Klopt, die werkt ook voor de update (V114), om de rest te kunnen uitlezen heb je V139 nodig. Het meeste werkt dan behalve BMS versie, en de max/min celtemperaturen zijn een factor 10 te hoog maar dat kan je zelf aanpassen in de yaml

[comfix]

pascallj schreef op maandag 13 oktober 2025 @ 21:52:
[...]


Dat ligt eraan hoe je kabel bedraad is. Niet elke Ethernet kabel is hetzelfde. Zoals ik al zei zit het RS485 paar altijd op pin 1&2. Dit is meestal oranje-wit en oranje, maar kan ook groen-wit en groen zijn. Zie ook mijn post die ik specifiek aan jou gericht had.

Gelukkig hebben ze de pin-out zo gemaakt dat je het veilig kan proberen.

Kan even duren voordat ze reageren. Soms binnen een dag, soms een week, soms 2. Ze hebben net feestdagen achter de rug daar, dus zou er niet op wachten.

Net de pinnen uitgemeten met een multimeter:
- pin 1: Oranje-wit
- pin 2: oranje

De GND heb ik afgekoppeld gelaten.

Ik heb de standaard config verwijderd uit HA en enkel de 37004 erin gezet als test.
HA logs:

Logger: pymodbus.logging
Bron: components/modbus/modbus.py:388
Eerst voorgekomen: 22:24:30 (1 gebeurtenis)
Laatst gelogd: 22:24:30

No response received after 3 retries, continue with next request >>>>> send: 0x0 0x1 0x0 0x0 0x0 0x6 0x1 0x3 0x90 0x8c 0x0 0x1 >>>>> Repeating.... >>>>> send: 0x0 0x1 0x0 0x0 0x0 0x6 0x1 0x3 0x90 0x8c 0x0 0x1 >>>>> send: 0x0 0x1 0x0 0x0 0x0 0x6 0x1 0x3 0x90 0x8c 0x0 0x1

Logger: homeassistant.components.modbus
Bron: components/modbus/modbus.py:310
integratie: Modbus (documentatie, problemen)
Eerst voorgekomen: 22:24:30 (1 gebeurtenis)
Laatst gelogd: 22:24:30

Pymodbus: MarstekVenus3: Error: device: 1 address: 37004 -> Modbus Error: [Input/Output] No response received after 3 retries, continue with next request

Een modpoll:

Protocol configuration: MODBUS/TCP, FC3
Slave configuration...: address = 1, start reference = 37004 (PDU), count = 15
Communication.........: 192.168.0.130, port 502, t/o 1.00 s, poll rate 1000 ms
Data type.............: 16-bit register, holding register table

-- Polling slave...
Reply time-out!

[amvolleb]

comfix schreef op maandag 13 oktober 2025 @ 22:52:
[...]


Net de pinnen uitgemeten met een multimeter:
- pin 1: Oranje-wit
- pin 2: oranje

De GND heb ik afgekoppeld gelaten.

Ik heb de standaard config verwijderd uit HA en enkel de 37004 erin gezet als test.
HA logs:

Logger: pymodbus.logging
Bron: components/modbus/modbus.py:388
Eerst voorgekomen: 22:24:30 (1 gebeurtenis)
Laatst gelogd: 22:24:30

No response received after 3 retries, continue with next request >>>>> send: 0x0 0x1 0x0 0x0 0x0 0x6 0x1 0x3 0x90 0x8c 0x0 0x1 >>>>> Repeating.... >>>>> send: 0x0 0x1 0x0 0x0 0x0 0x6 0x1 0x3 0x90 0x8c 0x0 0x1 >>>>> send: 0x0 0x1 0x0 0x0 0x0 0x6 0x1 0x3 0x90 0x8c 0x0 0x1

Logger: homeassistant.components.modbus
Bron: components/modbus/modbus.py:310
integratie: Modbus (documentatie, problemen)
Eerst voorgekomen: 22:24:30 (1 gebeurtenis)
Laatst gelogd: 22:24:30

Pymodbus: MarstekVenus3: Error: device: 1 address: 37004 -> Modbus Error: [Input/Output] No response received after 3 retries, continue with next request

Een modpoll:

Protocol configuration: MODBUS/TCP, FC3
Slave configuration...: address = 1, start reference = 37004 (PDU), count = 15
Communication.........: 192.168.0.130, port 502, t/o 1.00 s, poll rate 1000 ms
Data type.............: 16-bit register, holding register table

-- Polling slave...
Reply time-out!

Bedenk mij dat het ook wel eens kan zijn dat het registers 37007 en/of 37008 zijn die het doen met V114

[comfix]

amvolleb schreef op maandag 13 oktober 2025 @ 23:07:
[...]

Bedenk mij dat het ook wel eens kan zijn dat het registers 37007 en/of 37008 zijn die het doen met V114

Ik blijf time-outs hebben, draden als eens omgewisseld. Of de modbus staat toe of de Waveshare is stuk.

[pascallj]

comfix schreef op dinsdag 14 oktober 2025 @ 00:14:
[...]


Ik blijf time-outs hebben, draden als eens omgewisseld. Of de modbus staat toe of de Waveshare is stuk.

Misschien gekke vraag, maar geef je hem wel genoeg spanning?

[comfix]

pascallj schreef op dinsdag 14 oktober 2025 @ 00:19:
[...]


Misschien gekke vraag, maar geef je hem wel genoeg spanning?

Krijgt deze via een POE injector die ik nog over had: https://www.omadanetworks...-poe-adapter/tl-poe4824g/

Veronderstel dat die voldoende voeding geeft, maar... deze had ik gekocht voor een AP en die gaf niet genoeg en terwijl wel zou moeten echt bizar.
Ik heb nog een din DC voeding die voldoende moet zijn, zal deze eens testen.

Ondertussen de update doorgekregen en alles is up to date.
Hun feedback geeft wel iets minder goed nieuws ivm RS485:

[Avenger 2.0]

comfix schreef op dinsdag 14 oktober 2025 @ 12:20:
[...]
Hun feedback geeft wel iets minder goed nieuws ivm RS485:

Volgens mij wil dit gewoon zeggen dat ze geen support geven ivm RS485 aan eindgebruikers, niet dat ze de RS485 interface blokkeren of uit schakelen.

[LodeBo]

pascallj schreef op maandag 13 oktober 2025 @ 20:53:
[...]


Ja meerdere. Er zijn mensen die zeggen dat het mogelijk in BMS 216 verbeterd is. Waarschijnlijk krijg je die gepusht als je melding maakt van dit probleem. Kan je even proberen.

Vandaag al antwoord.

[Hemmik]

Chris96 schreef op maandag 13 oktober 2025 @ 15:05:
[...]


https://github.com/mampfes/ha_epex_spot

Zit standaard in HACS, en dan gebaseerd op EPEX Spot Web Scraper. Dit kan zonder API Sleutel.
Echter werkt deze nog op uurbasis. Ik heb zelf de code aangepast naar 15min. Simpel door het stukje self duration van 60 naar 15 te veranderen.

Waar heb je dit precies aangepast? lukt hier nog niet helemaal

[pascallj]

LodeBo schreef op dinsdag 14 oktober 2025 @ 14:18:
[...]


Vandaag al antwoord.
[Afbeelding]

Hetzelfde verhaal als altijd. Op zich is het wel goed om een volledige cyclus te doen na een firmware update, maar ik heb het idee dat op alle vragen nu het standaard antwoord is: doe een volledige cyclus, dat fixt alles. En daarbij krijg je ook gewoon de nieuwste firmware ongeacht of het toegespitst is op je probleem.

Ze kunnen het beter omdraaien: "We hebben een nieuwe firmware voor je die het probleem zou moeten oplossen. Na elke update raden wij aan om eerst een volledige cyclus te maken."

Overigens zou ik na de update wel even testen hoeveel capaciteit je hebt. Er was vanmorgen een melding dat ze nu gewoon eerder stoppen met ontladen en je daardoor capaciteit misloopt. Als dat inderdaad zo is, is dat geen oplossing, maar een ontwijking.

[denbeire]

[How-to] Marstek V3 thuisbatterij in Home Assistant via USR-EW11A (RS485→TCP)

Na wat puzzelen heb ik mijn Marstek V3 batterij netjes zichtbaar in Home Assistant via een USR-EW11A (RS485→TCP). Hieronder mijn werkende setup, registers, YAML en valkuilen — hopelijk heeft iemand er wat aan. 🙂

Hardware & uitgangspunt

BMS: Marstek V3 (firmware v139 bij mij)

Adapter: USR-EW11A (RS485 → TCP)

Home Assistant: Core + YAML “Packages”

Geen ESPHome in dit traject (alleen Modbus)

EW11A instellingen

Mode: TCP Server

Port: 502

Serial: 115200 8N1 ← dit is belangrijk; oudere posts noemen 9600, maar V2/V3 praten vaak 115200

Eén client tegelijk! Sluit Modbus Poll en de EW11 webpagina tijdens gebruik door HA, anders wordt de poort geblokkeerd.

Home Assistant: Packages activeren
In je configuration.yaml:

code:

homeassistant:
packages: !include_dir_named Packages

Plaats je package-bestand in: ./Packages/marstek_venus_battery_control.yaml.

Werkende registers (Marstek V3/v139 – bij mij)

SOC → holding 37005 (uint16, 0–100 %)

Spanning → holding 37006 (uint16, scale 0.1 V) → 208 ⇒ 20,8 V

Stroom → holding 37007 (int16, scale 0.01 A) → 3207 ⇒ 32,07 A

Vermogen: geen bruikbare 32-bit waarde gevonden in 37001..37004, dus berekend als V × A (prima voor dashboard/Energy).
(Op v139 zouden meer registers beschikbaar zijn; aanvullingen welkom!)

Volledige, minimale package (YAML)

code:

/homeassistant/Packages/marstek_venus_battery_control.yaml
Marstek V3 via USR-EW11A (RS485→TCP) – basis sensoren + Energy integratie

modbus:

name: Marstek
type: tcp
host: 192.168.0.149 # IP van de EW11A (pas aan)
port: 502
delay: 1
timeout: 5
sensors:

SOC (0–100 %)

name: "MSK Battery SOC"
address: 37005
slave: 1
input_type: holding
data_type: uint16
unit_of_measurement: "%"
device_class: battery
state_class: measurement

Spanning (V) – r37006 ×0.1

name: "MSK Battery Voltage"
address: 37006
slave: 1
input_type: holding
data_type: uint16
unit_of_measurement: "V"
device_class: voltage
state_class: measurement
scale: 0.1
precision: 1

Stroom (A) – r37007 ×0.01 (signed)

name: "MSK Battery Current"
address: 37007
slave: 1
input_type: holding
data_type: int16
unit_of_measurement: "A"
device_class: current
state_class: measurement
scale: 0.01
precision: 2

Om polariteit om te draaien (laden/ontladen): scale: -0.01
Templates: berekend vermogen + splitsing laden/ontladen + status

template:

sensor:

name: "MSK Battery Power"
unique_id: msk_battery_power_calc
unit_of_measurement: "W"
device_class: power
state_class: measurement
state: >
{% set v = states('sensor.msk_battery_voltage')|float(0) %}
{% set a = states('sensor.msk_battery_current')|float(0) %}
{{ (v * a) | round(0) }}
availability: "{{ has_value('sensor.msk_battery_voltage') and has_value('sensor.msk_battery_current') }}"

name: "MSK Battery Charging Power" # W, >=0
unique_id: msk_batt_charging_power
unit_of_measurement: "W"
device_class: power
state_class: measurement
state: >
{% set p = states('sensor.msk_battery_power')|float(0) %}
{{ max(p, 0) }}

name: "MSK Battery Discharging Power" # W, >=0
unique_id: msk_batt_discharging_power
unit_of_measurement: "W"
device_class: power
state_class: measurement
state: >
{% set p = states('sensor.msk_battery_power')|float(0) %}
{{ max(-p, 0) }}

(optioneel) Statuslabel: Laden / Ontladen / Idle

name: "MSK Battery Flow"
unique_id: msk_batt_flow
state: >
{% set ch = states('sensor.msk_battery_charging_power')|float(0) %}
{% set dis = states('sensor.msk_battery_discharging_power')|float(0) %}
{% set p = states('sensor.msk_battery_power')|float(0) %}
{% set i = states('sensor.msk_battery_current')|float(0) %}
{% set P_T = 200 %} {# vermogen-deadband in W #}
{% set I_T = 0.5 %} {# stroom-deadband in A #}
{% if (p|abs) < P_T or (i|abs) < I_T %}
Idle
{% elif ch >= dis %}
Laden
{% else %}
Ontladen
{% endif %}
icon: >
{% set p = states('sensor.msk_battery_power')|float(0) %}
{% set i = states('sensor.msk_battery_current')|float(0) %}
{% set P_T = 200 %}
{% set I_T = 0.5 %}
{% if (p|abs) < P_T or (i|abs) < I_T %}
mdi:battery-outline
{% elif p > 0 %}
mdi:battery-charging-high
{% else %}
mdi:battery-arrow-down
{% endif %}

binary_sensor:

name: "MSK Battery Charging"
unique_id: msk_batt_charging_bool
device_class: battery_charging
state: >
{% set ch = states('sensor.msk_battery_charging_power')|float(0) %}
{{ ch > 200 }} {# zelfde drempel P_T #}

Integratie naar kWh voor Energy-dashboard

sensor:

platform: integration
source: sensor.msk_battery_charging_power
name: My Battery Charging in KWh
unique_id: my_battery_charging_in_kwh
unit_prefix: k
round: 3
method: trapezoidal

platform: integration
source: sensor.msk_battery_discharging_power
name: My Battery Discharging in KWh
unique_id: my_battery_discharging_in_kwh
unit_prefix: k
round: 3
method: trapezoidal

Energy-pagina (Battery)
Instellingen → Energy → Batterijsystemen:

Charging energy → sensor.my_battery_charging_in_kwh

Discharging energy → sensor.my_battery_discharging_in_kwh
NB: “Statistics not defined” verdwijnt zodra de sensoren een paar minuten echte data hebben (laden/ontladen).

Dashboard-kaart (optioneel)

code:

type: vertical-stack
cards:

type: heading
heading: Marstek (accu)

type: gauge
name: Batterij SOC
entity: sensor.msk_battery_soc
min: 0
max: 100
needle: true
severity: {green: 50, yellow: 30, red: 15}

type: entities
title: Marstek (Modbus)
entities:

entity: sensor.msk_battery_soc
name: SOC

entity: sensor.msk_battery_voltage
name: Spanning

entity: sensor.msk_battery_current
name: Stroom

entity: sensor.msk_battery_power
name: Vermogen (berekend)

entity: sensor.msk_battery_flow
name: Accu status

Troubleshooting (mijn valkuilen)

Unavailables? Check of Packages geactiveerd is en dat je maar één modbus: hub voor de EW11A hebt.

Poort bezet: sluit Modbus Poll en de EW11 web UI; EW11 laat doorgaans maar één TCP-client toe.

Template errors: gebruik één template: blok (meerdere mag ook, maar let op indenting).

HomeKit 150-devicelimiet: filter Modbus weg:

code:

homekit:

filter:
exclude_entity_globs:
- sensor.msk_*

Power-teken: wil je laden + en ontladen −? Zet bij “Current” scale: -0.01.

Energy toont nog niets: er moet daadwerkelijk geladen/ontladen zijn sinds de sensoren bestaan; anders blijft het 0.

Opmerkingen v139
Met firmware v139 lijken er meer registers bruikbaar te zijn dan bovenstaande basis. Ik heb voor nu SOC/Volt/Ampère stabiel; aanvullende mapping (o.a. temperaturen/totalen) is welkom. Deel vooral je werkende adressen & schalen; ik werk de YAML graag bij.

Succes! 👋

[ Voor 23% gewijzigd door denbeire op 15-10-2025 08:36 ]

[pascallj]

denbeire schreef op dinsdag 14 oktober 2025 @ 14:55:
[How-to] Marstek V3 thuisbatterij in Home Assistant via USR-EW11A (RS485→TCP)

Na wat puzzelen heb ik mijn Marstek V3 batterij netjes zichtbaar in Home Assistant via een USR-EW11A (RS485→TCP). Hieronder mijn werkende setup, registers, YAML en valkuilen—hopelijk heeft iemand er wat aan. 🙂

Hardware & uitgangspunt

BMS: Marstek V3

Adapter: USR-EW11A (RS485 → TCP)

Home Assistant: Core + YAML “Packages”

Geen ESPHome in dit traject (alleen Modbus)

EW11A instellingen

Mode: TCP Server

Port: 502

Serial: 9600 8N1 (past bij mijn BMS; zet hier wat je BMS verwacht)

Eén client tegelijk! Sluit Modbus Poll en de EW11 webpagina tijdens gebruik door HA, anders wordt de poort geblokkeerd.

Home Assistant: Packages activeren

In configuration.yaml:

homeassistant:
packages: !include_dir_named Packages


Plaats je package-bestand in ./Packages/marstek_venus_battery_control.yaml.

Werkende registers (Marstek V3)

SOC → holding 37005 (uint16, 0–100 %)

Spanning → holding 37006 (uint16, scale 0.1 V) → 208 ⇒ 20,8 V

Stroom → holding 37007 (int16, scale 0.01 A) → 3207 ⇒ 32,07 A

Vermogen: bij mij geen bruikbare 32-bit waarde gevonden in 37001..37004, dus berekend als V × A (werkt prima voor dashboard/Energy).

Volledige, minimale package (YAML)
# /homeassistant/Packages/marstek_venus_battery_control.yaml
# Marstek V3 via USR-EW11A (RS485→TCP) – basis sensoren + Energy integratie

modbus:
- name: Marstek
type: tcp
host: 192.168.0.149 # IP van de EW11A
port: 502
delay: 1
timeout: 5
sensors:
# SOC (0–100 %)
- name: "MSK Battery SOC"
address: 37005
slave: 1
input_type: holding
data_type: uint16
unit_of_measurement: "%"
device_class: battery
state_class: measurement

# Spanning (V) – r37006 ×0.1
- name: "MSK Battery Voltage"
address: 37006
slave: 1
input_type: holding
data_type: uint16
unit_of_measurement: "V"
device_class: voltage
state_class: measurement
scale: 0.1
precision: 1

# Stroom (A) – r37007 ×0.01 (signed)
- name: "MSK Battery Current"
address: 37007
slave: 1
input_type: holding
data_type: int16
unit_of_measurement: "A"
device_class: current
state_class: measurement
scale: 0.01
precision: 2
# Om polariteit om te draaien (laden/ontladen): scale: -0.01

# Templates: berekend vermogen + splitsing laden/ontladen
template:
- sensor:
- name: "MSK Battery Power"
unique_id: msk_battery_power_calc
unit_of_measurement: "W"
device_class: power
state_class: measurement
state: >
{% set v = states('sensor.msk_battery_voltage')|float(0) %}
{% set a = states('sensor.msk_battery_current')|float(0) %}
{{ (v * a) | round(0) }}
availability: "{{ has_value('sensor.msk_battery_voltage') and has_value('sensor.msk_battery_current') }}"

- name: "MSK Battery Charging Power" # W, >=0
unique_id: msk_batt_charging_power
unit_of_measurement: "W"
device_class: power
state_class: measurement
state: >
{% set p = states('sensor.msk_battery_power')|float(0) %}
{{ max(p, 0) }}

- name: "MSK Battery Discharging Power" # W, >=0
unique_id: msk_batt_discharging_power
unit_of_measurement: "W"
device_class: power
state_class: measurement
state: >
{% set p = states('sensor.msk_battery_power')|float(0) %}
{{ max(-p, 0) }}

# Integratie naar kWh voor Energy-dashboard
sensor:
- platform: integration
source: sensor.msk_battery_charging_power
name: My Battery Charging in KWh
unique_id: my_battery_charging_in_kwh
unit_prefix: k
round: 3
method: trapezoidal

- platform: integration
source: sensor.msk_battery_discharging_power
name: My Battery Discharging in KWh
unique_id: my_battery_discharging_in_kwh
unit_prefix: k
round: 3
method: trapezoidal


Let op: afhankelijk van je HA-versie gebruik je slave: (zoals hier) i.p.v. unit:. Bij mij was slave: 1 vereist.

Energy-pagina (Battery)

In Instellingen → Energy → Batterijsystemen:

Charging energy → sensor.my_battery_charging_in_kwh

Discharging energy → sensor.my_battery_discharging_in_kwh

NB: “Statistics not defined” verdwijnt zodra de sensoren een paar minuten echte data hebben (laden/ontladen).

Dashboard-kaart (optioneel)
- type: vertical-stack
cards:
- type: heading
heading: Marstek (accu)
- type: gauge
name: Batterij SOC
entity: sensor.msk_battery_soc
min: 0
max: 100
severity: {green: 50, yellow: 30, red: 15}
- type: entities
title: Marstek (Modbus)
entities:
- entity: sensor.msk_battery_soc
name: SOC
- entity: sensor.msk_battery_voltage
name: Spanning
- entity: sensor.msk_battery_current
name: Stroom
- entity: sensor.msk_battery_power
name: Vermogen (berekend)

Troubleshooting (mijn valkuilen)

Unavailables? Check of Packages wel is geactiveerd en dat je maar één modbus: hub voor de EW11A hebt.

Poort bezet: Sluit Modbus Poll en de EW11 web UI; EW11 laat doorgaans maar één TCP-client toe.

Template errors: Gebruik één template: blok; meerdere blokken mag, maar let op indenting.

HomeKit 150-device limit: filter Modbus weg:

homekit:
- filter:
exclude_entity_globs:
- sensor.msk_*


Power teken: wil je laden + en ontladen −? Zet bij “Current” scale: -0.01.

Energy toont nog niets: er moet daadwerkelijk geladen/ontladen zijn sinds de sensoren bestaan; anders blijft het 0.

Dat was ’m. Met deze setup heb ik SOC, spanning, stroom, (berekend) vermogen en nette kWh-tellers op de Energy-pagina. Succes!

Je kunt alles wat met configuraties, code en bestanden te maken heeft, beter tussen [code][/code] tags zetten. Dan is het een stuk beter leesbaar.

Weet je zeker dat de baudrate correct is? De Marstek V2 en eerder hebben altijd op 115200 baud gecommuniceerd.

Daarbij zijn dit alleen de registers die werken voor de update zeker? Volgens mij werken er ondertussen veel meer met v139.

[comfix]

pascallj schreef op dinsdag 14 oktober 2025 @ 00:19:
[...]


Misschien gekke vraag, maar geef je hem wel genoeg spanning?

Heb het aan de praat gekregen, hangt aan een aparte din voeding. Ik gebruikte eerst een POE injector en ik denk dat deze niet stabiel is... nu ik weet dat alles werkt ga ik de injector nog eens testen... als niet goed is dan gaat die terug.
Ook de kablering was niet goed, nu als volgt:
- Oranje-wit is A -- PIN1 op de RJ45
- Oranje is B -- PIN2 op de RJ45
- GND toch wel nodig (bij Waveshare): blauw-wit -- PIN5 op de RJ45

[ Voor 5% gewijzigd door comfix op 14-10-2025 16:29 . Reden: pin volgorde aangepast ]

[pascallj]

comfix schreef op dinsdag 14 oktober 2025 @ 16:21:
[...]


Heb het aan de praat gekregen, hangt aan een aparte din voeding. Ik gebruikte eerst een POE injector en ik denk dat deze niet stabiel is... nu ik weet dat alles werkt ga ik de injector nog eens testen... als niet goed is dan gaat die terug.
Ook de kablering was niet goed, nu als volgt:
- Oranje-wit is A -- PIN1 op de RJ45
- Oranje is B -- PIN2 op de RJ45
- GND toch wel nodig (bij Waveshare): blauw-wit -- PIN5 op de RJ45

[Afbeelding]

Het was dus toch niet zo'n hele gekke vraag .

Maar blauw-wit is +5V en niet de GND. Dus het is toeval dat dat werkt, maar zeker niet de bedoeling. Je RS485 signalen worden dan veel te klein. Als je al een GND wilt gebruiken, is dat bruin of bruin-wit.

[amvolleb]

pascallj schreef op dinsdag 14 oktober 2025 @ 14:59:
[...]

Weet je zeker dat de baudrate correct is? De Marstek V2 en eerder hebben altijd op 115200 baud gecommuniceerd.

Ik heb mijn V3 op 115200 baud

Daarbij zijn dit alleen de registers die werken voor de update zeker? Volgens mij werken er ondertussen veel meer met v139.

Zoals eerder gezegd: bij mij werkt met V139 alles behalve BMS version, die geeft een unknown terug.

[AUijtdehaag]

Voor mensen met een lilygo die de nodered willen proberen heb ik het omgezet. (naar de benamingen in de code van m5stack atom)
https://github.com/fonske...ain/lilygo_mt1.yaml#L2-L3
Discord linkje

Voor marstek_m1 en MT1 de code veranderen naar marstek_m2 en MT2 voor de 2e batterij
(zelf niet getest dus probeer even uit of de code werkt)

[ Voor 6% gewijzigd door AUijtdehaag op 14-10-2025 20:33 ]

[denbeire]

pascallj schreef op dinsdag 14 oktober 2025 @ 14:59:
[...]


Je kunt alles wat met configuraties, code en bestanden te maken heeft, beter tussen [code][/code] tags zetten. Dan is het een stuk beter leesbaar.

Weet je zeker dat de baudrate correct is? De Marstek V2 en eerder hebben altijd op 115200 baud gecommuniceerd.

Daarbij zijn dit alleen de registers die werken voor de update zeker? Volgens mij werken er ondertussen veel meer met v139.

Klopt idd, foutje van mij, is idd 115200, ik heb het bericht aangepast

[comfix]

Nog een update vanuit Marstek:

Regarding issues with the RS485 interface, we have encountered instances where its use has caused device malfunctions. Such problems typically cannot be resolved remotely and necessitate returning the unit for repair, which proves inconvenient for both parties. Consequently, we advise against utilising the RS485 interface. Support for this feature may be reinstated once our technical team has addressed the associated issues. At present, we offer API access to our customers. Many clients opt for this API integration for home automation purposes.

[AUijtdehaag]

@comfix Gaat hier sinds voorjaar prima op de V1 en V2, via modbus
10 jaar garantie dus we gaan het zien.

De nodered flow die ik gebruik kijkt wel of de volgende aan te sturen power waarde wel nodig is om zo commandos te skippen

[ Voor 37% gewijzigd door AUijtdehaag op 15-10-2025 18:11 ]

[slagtree]

comfix schreef op woensdag 15 oktober 2025 @ 16:47:
Nog een update vanuit Marstek:

[...]

Ik ben beniewd hoe je de marstek venus v3 via api in HA kan inlezen.

[GoBieN-Be]

Eerst moet je de API aanzetten, dat kan pas na een aanvraag via Feedback voor het inschakelen van de "Advanced settings" in de app, waar je die API dan kan aanzetten en poort configureren.

Er is een custom integratie voor HA beschikbaar die sensoren via de API uitleest.

Waarschuwing: de API lijkt nog niet volledig stabiel. Enkele gebruikers zeggen ook dat wanneer je de API te vaak raadpleegt het de werking van de CT en batterij koppeling verstoort.

[slagtree]

Ik heb de modbus converte ew11 binnen en gekoppeld aan de marstek venus versie 3. Na het nameten van de bedrading lees hij de gegevens in HA. (Er zijn verschillende cat kabel).

Maar bij het bedienen van een schakelaar deed de batterij raar.
De volgende script heb ik gebruikt
https://github.com/Superduper1969/MarstekVenus-ElfinEW11

Ik zag in de readme tekstbestanden dat de scripts alleen geschikt is voor de venus E.
Welke yaml script is geschikt voor de marstek venus versie 3 om in de folder packages te plaatsen.

[Avenger 2.0]

AUijtdehaag schreef op woensdag 15 oktober 2025 @ 18:10:
@comfix Gaat hier sinds voorjaar prima op de V1 en V2, via modbus
10 jaar garantie dus we gaan het zien.

Zullen vooral mensen zijn die random modbus commando's uitproberen en zo hun Venus bricken
Anyway, vraag mij af of nog veel tweakers hun Venus v1/v2 binnen 10 jaar nog gebruiken.
Hebben we die dan al niet massaal tweedehands verkocht voor een nieuw speeltje?

[pascallj]

Avenger 2.0 schreef op donderdag 16 oktober 2025 @ 08:39:
[...]

Zullen vooral mensen zijn die random modbus commando's uitproberen en zo hun Venus bricken
Anyway, vraag mij af of nog veel tweakers hun Venus v1/v2 binnen 10 jaar nog gebruiken.
Hebben we die dan al niet massaal tweedehands verkocht voor een nieuw speeltje?

Blijft een slecht excuus, dan moet je die commando's er gewoon niet instoppen. Overigens zitten die er ook niet in, want ik heb een volledige scan gemaakt van het hele Modbus universum en alles geprobeerd

[Avenger 2.0]

pascallj schreef op donderdag 16 oktober 2025 @ 08:41:
[...]
Blijft een slecht excuus, dan moet je die commando's er gewoon niet instoppen. Overigens zitten die er ook niet in, want ik heb een volledige scan gemaakt van het hele Modbus universum en alles geprobeerd

Volgens mij zijn ze gewoon niet blij dat DuraVolt destijds de modbus commando's gelekt heeft en dit te veel details en mogelijkheden voor de eindgebruiker geeft (wat ze niet graag hebben bij Marstek).

[pascallj]

Avenger 2.0 schreef op donderdag 16 oktober 2025 @ 08:44:
[...]

Volgens mij zijn ze gewoon niet blij dat DuraVolt destijds de modbus commando's gelekt heeft en dit te veel details en mogelijkheden voor de eindgebruiker geeft (wat ze niet graag hebben bij Marstek).

Tsja zonder Modbus had ik de batterij nooit gekocht. Het levert je dus ook weer klanten op. Nu er eenmaal genoeg bekend was durfde ik het aan en alles wat er later nog extra is gevonden en verbeterd van het document is mooi meegenomen. En daarbij, bij de V3 adverteren ze weer opnieuw met Modbus. Je kan niet een functie adverteren en dan zeggen we willen niet dat je het gebruikt.

Ik denk dat ze niet willen dat we teveel data zien zoals cel min/max. Krijgen teveel inzicht in de tekortkomingen denk ik.

Aan de andere kant hebben ze wel weer alle registers teruggestopt die eerst afwezig waren op de V3. Dat zou dan ook weer niet in de lijn liggen.

[Avenger 2.0]

pascallj schreef op donderdag 16 oktober 2025 @ 08:50:
[...]
Ik denk dat ze niet willen dat we teveel data zien zoals cel min/max. Krijgen teveel inzicht in de tekortkomingen denk ik.

Aan de andere kant hebben ze wel weer alle registers teruggestopt die eerst afwezig waren op de V3. Dat zou dan ook weer niet in de lijn liggen.

Inderdaad. Denk dat dit komt omdat er firma's die dit voor hun EMS systeem gebruiken (bv Innovoltus met hun Jullix EMS in BE) geklaagd hebben over de missende registers.

[Marco_64]

amvolleb schreef op dinsdag 14 oktober 2025 @ 19:42:


Zoals eerder gezegd: bij mij werkt met V139 alles behalve BMS version, die geeft een unknown terug.

Zou het ontbreken van dit register in de V3 niet komen doordat EMS en BMS nu allemaal op 1 PCB zitten en misschien zelfs samengevoegd zijn in één firmware?

[superduper1969]

slagtree schreef op woensdag 15 oktober 2025 @ 23:26:
Ik heb de modbus converte ew11 binnen en gekoppeld aan de marstek venus versie 3. Na het nameten van de bedrading lees hij de gegevens in HA. (Er zijn verschillende cat kabel).

Maar bij het bedienen van een schakelaar deed de batterij raar.
De volgende script heb ik gebruikt
https://github.com/Superduper1969/MarstekVenus-ElfinEW11

Ik zag in de readme tekstbestanden dat de scripts alleen geschikt is voor de venus E.
Welke yaml script is geschikt voor de marstek venus versie 3 om in de folder packages te plaatsen.

Ik onderhoud deze niet actief vanwege de andere HA integraties die werken met de EW11 (Zie TS).
Overigens is de V3 Modbus commandoset al een paar keer uitgebreid en gelijkgetrokken met de V1/V2.

[sponsjeee]

Ik heb wederom een vraagje.

Marstek RS485 Control Mode, deze gaat de heletijd uit(disable) en ik kan niet vinden waardoor dit gebeurd. is er een manier dat ik deze geforceerd aan kan krijgen?

Ik gebruik de Lily go icm de Superduper1969 software op de marstek v2.

Ik ben nu in HA een oplossing aan het maken, maar het blijft lastig.

Gaat om de V2 met de laatste firmware.

[pascallj]

sponsjeee schreef op donderdag 16 oktober 2025 @ 15:38:
Ik heb wederom een vraagje.

Marstek RS485 Control Mode, deze gaat de heletijd uit(disable) en ik kan niet vinden waardoor dit gebeurd. is er een manier dat ik deze geforceerd aan kan krijgen?

Ik gebruik de Lily go icm de Superduper1969 software op de marstek v2.

Ik ben nu in HA een oplossing aan het maken, maar het blijft lastig.

Gaat om de V2 met de laatste firmware.

De RS485 Control is eigenlijk een vierde modus. Dus als je die aanzet, gaat de batterij van AI/NOM/Manual af en in die vierde modus. Als je dus de modus weer verandert naar 1 van die 3, gaat RS485 Control uit. Ik heb zo'n vermoeden dat dat is wat hier aan de hand is. Uit zichzelf heb ik hem nog nooit uit zien gaan.

[sponsjeee]

pascallj schreef op donderdag 16 oktober 2025 @ 15:40:
[...]


De RS485 Control is eigenlijk een vierde modus. Dus als je die aanzet, gaat de batterij van AI/NOM/Manual af en in die vierde modus. Als je dus de modus weer verandert naar 1 van die 3, gaat RS485 Control uit. Ik heb zo'n vermoeden dat dat is wat hier aan de hand is. Uit zichzelf heb ik hem nog nooit uit zien gaan.

Ik dacht dat die aan moest staan om de batterij te kunnen sturen via HA. Goede tip, ik ga testen! Bedankt.

[pascallj]

sponsjeee schreef op donderdag 16 oktober 2025 @ 15:50:
[...]


Ik dacht dat die aan moest staan om de batterij te kunnen sturen via HA. Goede tip, ik ga testen! Bedankt.

Voor elke andere sturing dan het wijzigen van het programma moet dat inderdaad. Je kunt niet laden/ontladen via Modbus en NOM draaien tegelijk; dat zou tegenstrijdig zijn.

[sponsjeee]

Duidelijk, RS485 enkel voor het laden en waardes in te stellen.
Andere modus voor de rest.
Ik moet RS485 dus zoals je zegt als een extra modus zien om handmatig iets in te stellen.

Het werkt nu ook zoals ik wil in mijn HA automation, bedankt voor de info!

[Eagle0]

pascallj schreef op woensdag 8 oktober 2025 @ 12:41:
[...]
Op basis van dit project (althans daar ga ik vanuit) is er ondertussen ook al een Bluetooth gateway gemaakt die de data kan ophalen: https://github.com/jaapp/marstek-ble-gateway gemaakt door mede-Tweaker @Preaper. Dus het is inderdaad mogelijk om dit ook via BT te doen.

Modbus via RS485 blijft altijd de stabielste manier om data op te halen. Maar mogelijk kan je, als je een ESP32
als Modbus apparaat gebruikt, deze ook gebruiken om via Bluetooth de rest van data te laten ophalen.

Geweldig! Ik heb vorige week het stukje yaml van jaapp/Preaper toegevoegd aan een bestaande esp32 in esphome die dicht genoeg bij de Venus ligt en het werkte direct. Geen gedoe, gewoon direct werken.
Ik snap nog niet precies hoe ik vanuit deze implementatie de CT polling rate kan aanpassen, maar dat doe ik dan wel met het browser gebaseerde marstek-venus-monitor project van rweijnen.

Ik kijk evt. bij een latere firmware versie wel weer naar de API.

[pascallj]

Eagle0 schreef op donderdag 16 oktober 2025 @ 17:06:
[...]


Geweldig! Ik heb vorige week het stukje yaml van jaapp/Preaper toegevoegd aan een bestaande esp32 in esphome die dicht genoeg bij de Venus ligt en het werkte direct. Geen gedoe, gewoon direct werken.
Ik snap nog niet precies hoe ik vanuit deze implementatie de CT polling rate kan aanpassen, maar dat doe ik dan wel met het browser gebaseerde marstek-venus-monitor project van rweijnen.

Ik kijk evt. bij een latere firmware versie wel weer naar de API.

Ja dat is mooi werk van de community weer inderdaad! Ik heb er nu een losse ESP32 voor bij gelegd, maar hoop dat ik het uiteindelijk ook samen kan voegen met mijn bestaande Modbus ESP32. Echter heeft die het met 351 Modbus registers al wel redelijk zwaar momenteel

[gho]

leejoow schreef op dinsdag 30 september 2025 @ 11:13:
[...]


Deze melding geeft aan dat na het compileren van de YAML naar een ESP32 binary dat deze niet via de WiFi kan worden geüpload omdat hij de module niet kan vinden. Dit kan komen omdat hij inderdaad niet gevonden wordt. Kan je ergens zien welke DHCP leases je hebt (en of de module dus inderdaad geen IP heeft)?

Verder geheel eens met @pascallj, sluit de LilyGo met een kabel aan op je laptop en installeer de module bedraad een eerste keer.


En nog een vraagje: zie je een netwerk met de naam Lilygo-Rs485 Fallback Hotspot als je zoekt naar netwerken met je telefoon?

Sorry voor de late na-reactie; had dit gemist vandaar,
In eerste instantie zag het erna uit dat de batterij ter ziele was, nadat ik een travel router bedraad koppelde aan e TP Link Deco X20 kreeg ik de batterij alsnog aan de praat, waarbij overigens Bluetooth wel koppelde doch de Bluetooth led Niet brandde, ra ra.
Duidelijk is me dat de Deco 20 wellicht onvoldoende wifi contact maakt, hoewel beiden op 2mtr afstand zitten
Bij dit contact liet de LilyGo nu wel info zien en ook op de PC Lilygo-Rs485 Fallback Hotspot.
Heb inmiddels Deco's met groter bereik aangeschaft die ik het weekend ga installeren en zal de TravelRouter en vast aankoppelen.
Hopelijk kom ik dan verder en constateer dat er een nieuw script voor EspHomeBuilder is en daarna komt begrijp ik eerdaags ook API om de hoek kijken.
Afijn bedankt voor de reactie...

[AUijtdehaag]

Eagle0 schreef op donderdag 16 oktober 2025 @ 17:06:
[...]


Geweldig! Ik heb vorige week het stukje yaml van jaapp/Preaper toegevoegd aan een bestaande esp32 in esphome die dicht genoeg bij de Venus ligt en het werkte direct. Geen gedoe, gewoon direct werken.
Ik snap nog niet precies hoe ik vanuit deze implementatie de CT polling rate kan aanpassen, maar dat doe ik dan wel met het browser gebaseerde marstek-venus-monitor project van rweijnen.

Ik kijk evt. bij een latere firmware versie wel weer naar de API.

Kun je dan nog iets met de app doen als hij bezet is door bluetooth?
Zoals firmware updates?

[pascallj]

AUijtdehaag schreef op donderdag 16 oktober 2025 @ 17:48:
[...]

Kun je dan nog iets met de app doen als hij bezet is door bluetooth?
Zoals firmware updates?

Alleen via WiFi (Cloud) en dan geen firmware updates inderdaad, maar je kan wel kijken of ze er zijn. Ik heb daar zelf een switch voor ingebouwd waarmee ik via HA de verbinding van de ESP kan laten verbreken.

[slagtree]

superduper1969 schreef op donderdag 16 oktober 2025 @ 11:47:
[...]

Ik onderhoud deze niet actief vanwege de andere HA integraties die werken met de EW11 (Zie TS).
Overigens is de V3 Modbus commandoset al een paar keer uitgebreid en gelijkgetrokken met de V1/V2.

Hoi, Ik vroeg me af welke HA integraties adviseer je me om te gebruiken voor de venus V3?
Ik heb geprobeerd optie A in de TS maar in de HACS is de repository niet beschikbaar.
Optie C wordt omschreven als een oude originele code

[GoBieN-Be]

Opties voor gebruik met HomeAssistant.

Lezen/sturen via Modus

Voor V3 zijn er nog een paar registers die anders zijn dan V1/V2 vermoedelijk.

1. LilyGO met ESPHome
   Werkt betrouwbaar en goed met de opgegeven code.
2. Elfin met TCP/Modbus bridge
   Code voorhanden die ook door velen gebruikt wordt hier.

Lezen/sturen via Local API (netwerk)

De API is nog niet echt stabiel. Te snel de API aanspreken zorgt voor verloren verbinding tussen batterij en CT meter.

1. HA Integratie, manueel toevoegen aan HACS.
   https://github.com/jaapp/ha-marstek
2. Scripting zoals met Powershell of python

Lezen via Bluetooth

1. ESPHome die via Bluetooth de batterij uitleest
   https://github.com/jaapp/marstek-ble-gateway

Lezen/sturen via MQTT Hame relay

1. HA Integraties en addon (beide nodig) van TomQuist
   github.com/tomquist/hame-relay
   github.com/tomquist/hm2mqtt
   Bij firmware updates breekt deze soms tot er een update komt

Cloud API van Hame/marstek

• Ik heb geen informatie over deze methode, en of dat het zelfs nog werkt of niet.

De b2500-addon gebruiken als CT

• Je kan in de addon templating gebruiken waarmee je effectief aangepaste stuurgegevens doorgeeft aan de batterij.
  Bijvoorbeeld, de batterij draait dus NOM of AI, en het echte actief vermogen dat je afneemt van het net is 3000W maar de b2500 addon zegt aan de batterij dat het 1000W is. De batterij zal dus slechts 1000W terugleveren. Het doel daarvan is peak-shaving (Belgisch CAPTAR tarief) en de lading van de batterij langer doen meegaan. Je draait dus Nul-op-de-Meter, maar jij bepaalt zelf het nulpunt, dat je bijvoorbeeld dynamisch aanpast n.a.v. de resterende batterijcapaciteit.

[ Voor 103% gewijzigd door GoBieN-Be op 18-10-2025 21:28 ]

[Arko0321]

Kan iemand mij helpen? Ik krijg mijn V3 niet in Homey.
Mijn V2 staat wel in homey en ik heb 2 EW11's.

Ik heb ze zelf al eens gewisseld om te vermijden dat het aan de configuratie ligt van de EW11 maar neen. Het moet dus echt aan mijn aansluiting liggen.

Kan iemand mij helpen?

[pascallj]

Arko0321 schreef op zaterdag 18 oktober 2025 @ 00:47:
Kan iemand mij helpen? Ik krijg mijn V3 niet in Homey.
Mijn V2 staat wel in homey en ik heb 2 EW11's.

Ik heb ze zelf al eens gewisseld om te vermijden dat het aan de configuratie ligt van de EW11 maar neen. Het moet dus echt aan mijn aansluiting liggen.

Kan iemand mij helpen?[Afbeelding]

[Afbeelding]

Ik heb geen ervaring met Homey en wij weten ook niet hoe en wat je precies via Homey uitvraagt. Maar ik heb zo'n vermoeden dat je nog op firmware 114 zit. Bij firmware 139 zijn er veel registers toegevoegd en zullen configuraties van de V2 1-op-1 werken (op enkele registers na geloof ik).

[ Voor 59% gewijzigd door pascallj op 18-10-2025 06:53 ]

[slagtree]

Arko0321 schreef op zaterdag 18 oktober 2025 @ 00:47:
Kan iemand mij helpen? Ik krijg mijn V3 niet in Homey.
Mijn V2 staat wel in homey en ik heb 2 EW11's.

Ik heb ze zelf al eens gewisseld om te vermijden dat het aan de configuratie ligt van de EW11 maar neen. Het moet dus echt aan mijn aansluiting liggen.

Kan iemand mij helpen?[Afbeelding]

[Afbeelding]

Mooie groene verloopkabel van RJ45 naar klemmen Ik ben benieuwd waar je die vandaan haalt. Ik voed de EW11 uit de marstek. Eerst meten met een multimeter op mijn ftp kabel stond op de groene 5V ipv de blauwe.

[Tazzios]

@slagtree https://www.allekabels.nl...j45-naar-klemmenblok.html

[GoBieN-Be]

Wij weten niet in welke volgorde de aders zitten op die klemmenstrook.
Ik stel voor dat je eerst probeert met een gewone straight netwerkkabel die je doorknipt en dan de aders aansluit zoals in de TS staat.

[brechtvhb]

AUijtdehaag schreef op zondag 12 oktober 2025 @ 16:18:
@Chris96
De laatste nieuwe versie van esphome 2025.9.3 is de boosdoener.
Als je deze aan repositories (drie puntjes) toevoegd aan de addons kun je een oudere versie van esphome ernaast installeren
https://github.com/khenderick/esphome-legacy-addons

Iemand die weet of dit probleem zich nog steeds voor doet met esphome 2025.10.x?

[AUijtdehaag]

@brechtvhb
Compileert hier weer prima.

[crabe919]

GoBieN-Be schreef op vrijdag 17 oktober 2025 @ 23:07:
Opties voor gebruik met HomeAssistant.

Lezen/sturen via Modus

Voor V3 zijn er nog een paar registers die anders zijn dan V1/V2 vermoedelijk.

1. LilyGO met ESPHome
   Werkt betrouwbaar en goed met de opgegeven code.
2. Elfin met TCP/Modbus bridge
   Code voorhanden die ook door velen gebruikt wordt hier.

Lezen/sturen via Local API (netwerk)

De API is nog niet echt stabiel. Te snel de API aanspreken zorgt voor verloren verbinding tussen batterij en CT meter.

1. HA Integratie, manueel toevoegen aan HACS.
   https://github.com/jaapp/ha-marstek
2. Scripting zoals met Powershell of python

Lezen via Bluetooth

1. ESPHome die via Bluetooth de batterij uitleest
   https://github.com/jaapp/marstek-ble-gateway

Lezen/sturen via MQTT Hame relay

1. HA Integraties en addon (beide nodig) van TomQuist
   github.com/tomquist/hame-relay
   github.com/tomquist/hm2mqtt
   Bij firmware updates breekt deze soms tot er een update komt

Cloud API van Hame/marstek

• Ik heb geen informatie over deze methode, en of dat het zelfs nog werkt of niet.

De b2500-addon gebruiken als CT

• Je kan in de addon templating gebruiken waarmee je effectief aangepaste stuurgegevens doorgeeft aan de batterij.
  Bijvoorbeeld, de batterij draait dus NOM of AI, en het echte actief vermogen dat je afneemt van het net is 3000W maar de b2500 addon zegt aan de batterij dat het 1000W is. De batterij zal dus slechts 1000W terugleveren. Het doel daarvan is peak-shaving (Belgisch CAPTAR tarief) en de lading van de batterij langer doen meegaan. Je draait dus Nul-op-de-Meter, maar jij bepaalt zelf het nulpunt, dat je bijvoorbeeld dynamisch aanpast n.a.v. de resterende batterijcapaciteit.

Dank voor het overzicht! reeds een tijdje op zoek naar wat momenteel de beste weg is om de V3 aan te sturen vanuit HA.
Denk dat ik voorlopig de modbusweg in zal slaan en de api nog even links laat liggen.

[Maxwp]

GoBieN-Be schreef op maandag 13 oktober 2025 @ 00:27:
[...]


Ik lees nu ook via Bluetooth uit op een bestaand ESP32 bordje.
Ik ga testen als ik dat gewoon op de LilyGO kan integreren zonder conflict.

dat is een goede
de lilygo esp 32 bleutooth gebruiken om naast de modbus ook via die weg te connecten
is dat al gelukt?
gewoon deze data toevoegen?
kun je de mac adressen gebruiken om er voor te zorgen dat de zelfde esp steeds met de zelfde marstek connect?

--

code:

# your-device.yaml
esphome:
  name: my-marstek-gateway
  friendly_name: My Marstek Gateway

esp32:
  board: esp32-s3-devkitc-1
  variant: esp32s3
  framework:
    type: esp-idf

logger:
  level: INFO

api:
  encryption:
    key: "YOUR_32_BYTE_BASE64_ENCRYPTION_KEY_HERE"

ota:
  - platform: esphome
    password: "YOUR_OTA_PASSWORD_HERE"

wifi:
  ssid: !secret wifi_ssid
  password: !secret wifi_password

# Time component - REQUIRED
time:
  - platform: homeassistant
    id: ha_time

# Import the Marstek BLE Gateway package
packages:
  marstek_ble: github://jaapp/marstek-ble-gateway/marstek-ble-gateway.yaml@main

[Animal]

Ik merk in home assistant dat mijn Marstek User Work Mode entity niet synchroon loopt met de user work mode in de Marstek app zelf. Ook kan ik de user work mode niet wijzigen (de helper zelf) naar bijvoorbeeld AI>>Anti-feed. Iemand een oplossing?
Marstek v2 via Lillygo

[ Voor 4% gewijzigd door Animal op 21-10-2025 14:02 ]

[pascallj]

Animal schreef op dinsdag 21 oktober 2025 @ 13:59:
Ik merk in home assistant dat mijn Marstek User Work Mode entity niet synchroon loopt met de user work mode in de Marstek app zelf. Ook kan ik de user work mode niet wijzigen (de helper zelf) naar bijvoorbeeld AI>>Anti-feed. Iemand een oplossing?
Marstek v2 via Lillygo

Er zit een bug in de Modbus dat als je Modus wijzigt naar AI dat hij vanzelf terugschiet naar Anti-Feed. De modus wordt echter wel ingesteld. Dit kan je controleren met de App. Ook als je RS485 Control aanzet, zal de Work Mode Anti-Feed weergeven. Wil je dus wijzigen van AI naar Anti-Feed, zal je hem eerst van Anti-Feed weergave (AI) af moeten halen (naar bv Manual) en dan weer terug naar Anti-Feed anders wordt de wijziging niet doorgevoerd.

Is dat misschien waar je last van hebt?

[Animal]

pascallj schreef op dinsdag 21 oktober 2025 @ 14:12:
[...]


Er zit een bug in de Modbus dat als je Modus wijzigt naar AI dat hij vanzelf terugschiet naar Anti-Feed. De modus wordt echter wel ingesteld. Dit kan je controleren met de App. Ook als je RS485 Control aanzet, zal de Work Mode Anti-Feed weergeven. Wil je dus wijzigen van AI naar Anti-Feed, zal je hem eerst van Anti-Feed weergave (AI) af moeten halen (naar bv Manual) en dan weer terug naar Anti-Feed anders wordt de wijziging niet doorgevoerd.

Is dat misschien waar je last van hebt?

Ja! Dankjewel. Deze bug is wellicht te omzeilen of automatiseren? Misschien zelfs in de ESPhome firmware? We kunnen het gedrag precies voorspellen?

[pascallj]

Animal schreef op dinsdag 21 oktober 2025 @ 14:16:
[...]

Ja! Dankjewel. Deze bug is wellicht te omzeilen of automatiseren? Misschien zelfs in de ESPhome firmware? We kunnen het gedrag precies voorspellen?

Het is een bug in de firmware van de batterij dus dat kunnen we zelf niet oplossen. Marstek geeft geen support op Modbus, dus daar hoef je ook niet te veel van te verwachten.

Zoals je opmerkt, kan je wel zelf de status bij gaan houden, alleen dit werkt alleen als je geen andere aansturing gebruikt (zoals de App) omdat anders de verwachte status niet correct kan zijn als iets anders de status heeft gewijzigd. Ook zal je rekening moeten houden met randvoorwaarden zoals welke status de batterij zich in bevindt na een herstart bijvoorbeeld. Het lijkt me daarom niet eenvoudig om dit in een integratie te verwerken omdat je geen rekening kan houden met alle gebruiksscenario's van alle gebruikers.

Als je zelf zeker weet dat niets anders de status zal wijzigen, lijkt het mij eenvoudiger dat je binnen je eigen omgeving zelf bijhoudt wat de daadwerkelijke status moet zijn (als je dat belangrijk vindt om te weten) of dat je bij het wijzigen van de modus altijd eerst een andere modus forceert, zodat de verwachte modus klopt. Of allebei.

[Kammika]

pascallj schreef op dinsdag 21 oktober 2025 @ 14:23:
[...]
Het is een bug in de firmware van de batterij dus dat kunnen we zelf niet oplossen. Marstek geeft geen support op Modbus, dus daar hoef je ook niet te veel van te verwachten.

Dat is toch wel gek. Heb het apparaat gekocht o.a. omdat er een modbus aansluiting op zat, dan verwacht je toch ook dat dat het doet en zo niet, dat ze dat dan fixen?

[pascallj]

Kammika schreef op dinsdag 21 oktober 2025 @ 14:25:
[...]

Dat is toch wel gek. Heb het apparaat gekocht o.a. omdat er een modbus aansluiting op zat, dan verwacht je toch ook dat dat het doet en zo niet, dat ze dat dan fixen?

Tsja, die discussie hebben we ook vaker gevoerd en als de Modbus helemaal niet gewerkt had, had mijn batterij terug gegaan. Maar het werkt voor 95 procent goed nu. We hebben zelf veel werk verricht om registers goed te krijgen en dat is prima zo. Zolang ze er nu vanaf blijven, vind ik het best.

Bij de V3 hadden we ook weer onze bedenkingen want er zat bijna geen Modbus ondersteuning in, en dat is nu blijkbaar op bijna hetzelfde niveau als de V2. Dus mogen we ook niet klagen denk ik.

Volgens mij is dit de enige of 1 van de weinige bugs in de Modbus en zo'n ramp is het ook weer niet. Er is prima zelf omheen te programmeren als je het echt wil. Het zou netjes zijn als ze het oplossen, maar aan de andere kant heb je dit soort merkwaardigheden met heel veel apparatuur als je op een wat lager niveau gaat aansturen.

Ik heb wel eens wat geprogrammeerd voor de Linux Kernel en je moest eens weten wat voor gekke trucs er uitgehaald moeten worden om bijvoorbeeld een PWM controller voor een display of een USB controller werkend te krijgen omdat er bugs inzitten. Om nog maar te zwijgen over bugs in WiFi en Ethernet chipsets. Dat is weliswaar in de hardware en dus lastiger op te lossen, maar toch.

[dannyro]

pascallj schreef op dinsdag 21 oktober 2025 @ 14:12:
[...]


Er zit een bug in de Modbus dat als je Modus wijzigt naar AI dat hij vanzelf terugschiet naar Anti-Feed. De modus wordt echter wel ingesteld. Dit kan je controleren met de App. Ook als je RS485 Control aanzet, zal de Work Mode Anti-Feed weergeven. Wil je dus wijzigen van AI naar Anti-Feed, zal je hem eerst van Anti-Feed weergave (AI) af moeten halen (naar bv Manual) en dan weer terug naar Anti-Feed anders wordt de wijziging niet doorgevoerd.

Is dat misschien waar je last van hebt?

Als je RS485 Control aanzet wat nut heeft de modus dan nog? Ik stuur de batterij aan via de RS485 Control, laden en ontladen. En dat werkt prima.

[pascallj]

dannyro schreef op dinsdag 21 oktober 2025 @ 14:40:
[...]


Als je RS485 Control aanzet wat nut heeft de modus dan nog? Ik stuur de batterij aan via de RS485 Control, laden en ontladen. En dat werkt prima.

Niets, die doet niks. Alleen als je nu een beslisboom wilt maken voor een automatisering, kan je dus niet alleen uitgaan van wat de huidige status zegt. Je zal nu ook moeten kijken of RS485 Control aan staat. Het had een stap gescheeld als er een vierde modus in had gezeten genaamd RS485 control (die zit er ook in alleen wordt niet goed doorgegeven via het Modbus register) en je dan alleen de modus hoeft te wijzigen om in de gewenste situatie te komen.

[dannyro]

pascallj schreef op dinsdag 21 oktober 2025 @ 14:43:
[...]


Niets, die doet niks. Alleen als je nu een beslisboom wilt maken voor een automatisering, kan je dus niet alleen uitgaan van wat de huidige status zegt. Je zal nu ook moeten kijken of RS485 Control aan staat. Het had een stap gescheeld als er een vierde modus in had gezeten genaamd RS485 control (die zit er ook in alleen wordt niet goed doorgegeven via het Modbus register) en je dan alleen de modus hoeft te wijzigen om in de gewenste situatie te komen.

Dat begrijp ik. Ik wilde alleen maar aantonen dat er via automatisaties alleen gewerkt kan worden met de RS458 Control. Aan de modus verander ik niets. Dit werk hier dan ook feilloos. Ik dacht dat er misschien voorbeelden zijn waar de modus verandering via Modbus belangrijk kan zijn.

[Goosmeister]

Arko0321 schreef op zaterdag 18 oktober 2025 @ 00:47:
Kan iemand mij helpen? Ik krijg mijn V3 niet in Homey.
Mijn V2 staat wel in homey en ik heb 2 EW11's.

Ik heb ze zelf al eens gewisseld om te vermijden dat het aan de configuratie ligt van de EW11 maar neen. Het moet dus echt aan mijn aansluiting liggen.

Kan iemand mij helpen?[Afbeelding]

[Afbeelding]

Mijn EW11 wordt ook direct gevoed door de RJ45/modbus, het schema van de 1e pagina gebuikt en dat werkt goed. De HA integratie van wargaming player gebuikt (wel even de yaml files geschikt maken voor de v3).

[XChallenge]

Ik heb 2 batterijen Marstek Venus E 2.0 en die zijn gekoppeld aan mijn Homey via elk een Elfin EW11A.
Ik gebruik enkel "geforceerd laden" en "geforceerd ontladen". Nu is mijn vraag: Wat is de kortste interval om het laadvermogen of ontlaadvermogen aan te passen zodat alles kan volgen en waar zit het knelpunt ? Met andere woorden, wat kan er het moeilijkst volgen ? Is het de Homey, de Elfin AW11A's of zijn het de Marsteks ? Ik gebruik nu een flow die om de 3 seconden een nieuw laadvermogen (of ontlaadvermogen) doorgeeft aan de batterijen en blijkbaar is dit zowat het kortst mogelijke interval. Of zit er ergens een probleem ?

[crabe919]

Goosmeister schreef op dinsdag 21 oktober 2025 @ 19:04:
[...]


Mijn EW11 wordt ook direct gevoed door de RJ45/modbus, het schema van de 1e pagina gebuikt en dat werkt goed. De HA integratie van wargaming player gebuikt (wel even de yaml files geschikt maken voor de v3).

Zou je een linkje hebben naar de Yaml files voor de V3, ikzelf ben niet genoeg thuis in het herprogrammeren van zon'n dingen..;

Dank!

[crabe919]

Ik ben intussen al een stapje verder, adapter gemaakt volgens V3 schema, elfin geconfigureerd en modbusinstellingen gedaan.

Voor de configuratie heb ik de github van WargamingPlayer gevolgd.
De packages folder aangemaakt en de nodige yaml files opgeladen in HA. Ip adres ingevuld in de yaml file.
Bij het heropstarten vind ik de modbus integratie maar die blijft leeg, als ik in de yaml file de code voor enkel V3 actief maak, en heropstart, verdwijnt de de modbus integratie terug.

onderstaande haal ik uit de HA logs:

code:

Invalid config for 'modbus' at packages/marstek_venus_battery_1_control.yaml, line 111: Marstek 1 COM Module version: `structure` missing, demanded with `data_type: custom` 'modbus->0->sensors->5', got {'name': 'Marstek 1 COM Module version', 'unique_id': 'marstek_1_com_module_version', 'address': 30350, 'slave': 1, 'scan_interval': 300, 'input_type': 'holding', 'data_type': 'custom', 'count': 6}, please check the docs at https://www.home-assistant.io/integrations/modbus

Kan iemand me in de juiste richting wijzeen om dit werkend te krijgen?

Mijn installatie: Marstek Venus E V3, Firmware V139.

[ Voor 30% gewijzigd door crabe919 op 23-10-2025 11:10 ]

[superduper1969]

crabe919 schreef op donderdag 23 oktober 2025 @ 05:29:
Ik ben intussen al een stapje verder, adapter gemaakt volgens V3 schema, elfin geconfigureerd en modbusinstellingen gedaan.

Voor de configuratie heb ik de github van WargamingPlayer gevolgd.
De packages folder aangemaakt en de nodige yaml files opgeladen in HA. Ip adres ingevuld in de yaml file.
Bij het heropstarten vind ik de modbus integratie maar die blijft leeg, als ik in de yaml file de code voor enkel V3 actief maak, en heropstart, verdwijnt de de modbus integratie terug.

onderstaande haal ik uit de HA logs:

code:

Invalid config for 'modbus' at packages/marstek_venus_battery_1_control.yaml, line 111: Marstek 1 COM Module version: `structure` missing, demanded with `data_type: custom` 'modbus->0->sensors->5', got {'name': 'Marstek 1 COM Module version', 'unique_id': 'marstek_1_com_module_version', 'address': 30350, 'slave': 1, 'scan_interval': 300, 'input_type': 'holding', 'data_type': 'custom', 'count': 6}, please check the docs at https://www.home-assistant.io/integrations/modbus

Kan iemand me in de juiste richting wijzeen om dit werkend te krijgen?

Mijn installatie: Marstek Venus E V3, Firmware V139.

Zonder dat ik weet wat de broncode is, ik kon gewoon de foutmelding in Copilot kopieren en die kwam met een plausibel antwoord.
Natuurlijk kun je ook met een andere AI aan de slag, de meeste leggen ook uit wat ze "Vreemd" vinden, maken een "Actieplan" hoe ze het denken op te lossen en geven voorbeelden waarvan hun denken wat het zou moeten zijn.

Gisteravond samen met Youtube en Copilot een automatisering gemaakt voor HA die via Google Maps-Locatie delen de batteij-status van de telefoon van mijn vader ophaalt en bij een batterij percentage van 5% een melding in zijn kalender zet die altijd op zijn in vaste opstelling geplaatste tablet wordt gepresenteerd. "Telefoon Opladen" (Als 81 jarige vergeet je wel eens wat)

[Kammika]

Hemmik schreef op dinsdag 14 oktober 2025 @ 14:23:
[...]

Waar heb je dit precies aangepast? lukt hier nog niet helemaal

Mij is tie iig gelukt, door deze regel:

self._duration = 60

in EPEXSpot/EPEXSpotWeb/__init__.py

aan te passen naar:

self._duration = 15

[pierrick]

Hi all,
I will post in English but I'm French. If someone can help me...
I have a Venus E v3 and had installed the lilygo-rs485-3.yaml on a lilygo device to controle the battery.
I can get many information in the ESPhome web module (and also Home assistant) but it seems that some adresses are not correct, and I don't find the correct and complete register for the v3 model.
I don't understand Dustch and it's difficultfor me to go through all the posts... Can someone summarize and tell me if if it's possible to work with the v3 model and modbus?
For the moment, the problems in my logs


[16:52:04.854][D][modbus:157]: Modbus error function code: 0x83 exception: 2
[16:52:04.857][E][modbus_controller:094]: Modbus error function code: 0x3 exception: 2
[16:52:04.861][E][modbus_controller:098]: Modbus error - last command: function code=0x3 register address = 0xABE0 registers count=4 payload size=0

16:57:24.289][D][modbus:157]: Modbus error function code: 0x83 exception: 2
[16:57:24.293][E][modbus_controller:094]: Modbus error function code: 0x3 exception: 2
[16:57:24.296][E][modbus_controller:098]: Modbus error - last command: function code=0x3 register address = 0x797C registers count=3 payload size=0

[16:57:26.591][D][modbus:157]: Modbus error function code: 0x83 exception: 2
[16:57:26.594][E][modbus_controller:094]: Modbus error function code: 0x3 exception: 2
[16:57:26.598][E][modbus_controller:098]: Modbus error - last command: function code=0x3 register address = 0xA032 registers count=1 payload size=0

Thank you for your help

[pascallj]

pierrick schreef op donderdag 23 oktober 2025 @ 17:05:
Hi all,
I will post in English but I'm French. If someone can help me...
I have a Venus E v3 and had installed the lilygo-rs485-3.yaml on a lilygo device to controle the battery.
I can get many information in the ESPhome web module (and also Home assistant) but it seems that some adresses are not correct, and I don't find the correct and complete register for the v3 model.
I don't understand Dustch and it's difficultfor me to go through all the posts... Can someone summarize and tell me if if it's possible to work with the v3 model and modbus?
For the moment, the problems in my logs


[16:52:04.854][D][modbus:157]: Modbus error function code: 0x83 exception: 2
[16:52:04.857][E][modbus_controller:094]: Modbus error function code: 0x3 exception: 2
[16:52:04.861][E][modbus_controller:098]: Modbus error - last command: function code=0x3 register address = 0xABE0 registers count=4 payload size=0

16:57:24.289][D][modbus:157]: Modbus error function code: 0x83 exception: 2
[16:57:24.293][E][modbus_controller:094]: Modbus error function code: 0x3 exception: 2
[16:57:24.296][E][modbus_controller:098]: Modbus error - last command: function code=0x3 register address = 0x797C registers count=3 payload size=0

[16:57:26.591][D][modbus:157]: Modbus error function code: 0x83 exception: 2
[16:57:26.594][E][modbus_controller:094]: Modbus error function code: 0x3 exception: 2
[16:57:26.598][E][modbus_controller:098]: Modbus error - last command: function code=0x3 register address = 0xA032 registers count=1 payload size=0

Thank you for your help

The '3' in 'lilygo-rs485-3.yaml' stands for the third battery in your system in case you have more. So you don't need to use that one, you can use 'lilygo-rs485.yaml' just as well, but is doesn't really matter. The only things that are changed between the files, are the names of the devices.

However the v3 only got a proper Modbus implementation in firmware version v139. You are probably still on an older version like v114. You have to request an update to firmware v139.

[pierrick]

pascallj schreef op donderdag 23 oktober 2025 @ 17:12:
[...]


The '3' in 'lilygo-rs485-3.yaml' stands for the third battery in your system in case you have more. So you don't need to use that one, you can use 'lilygo-rs485.yaml' just as well, but is doesn't really matter. The only things that are changed between the files, are the names of the devices.

However the v3 only got a proper Modbus implementation in firmware version v139. You are probably still on an older version like v114. You have to request an update to firmware v139.

Thank you for your help.
I changed to the 'lilygo-rs485.yaml' but I'm already in firmware v139

And always bad modbus address:

[17:26:21.537][D][modbus:157]: Modbus error function code: 0x83 exception: 2
[17:26:21.541][E][modbus_controller:094]: Modbus error function code: 0x3 exception: 2
[17:26:21.546][E][modbus_controller:098]: Modbus error - last command: function code=0x3 register address = 0xA032 registers count=1 payload size=0

[17:26:21.790][D][modbus:157]: Modbus error function code: 0x83 exception: 2
[17:26:21.796][E][modbus_controller:094]: Modbus error function code: 0x3 exception: 2
[17:26:21.799][E][modbus_controller:098]: Modbus error - last command: function code=0x3 register address = 0xABE0 registers count=4 payload size=0

[pascallj]

pierrick schreef op donderdag 23 oktober 2025 @ 17:27:
[...]

Thank you for your help.
I changed to the 'lilygo-rs485.yaml' but I'm already in firmware v139

And always bad modbus address:

[17:26:21.537][D][modbus:157]: Modbus error function code: 0x83 exception: 2
[17:26:21.541][E][modbus_controller:094]: Modbus error function code: 0x3 exception: 2
[17:26:21.546][E][modbus_controller:098]: Modbus error - last command: function code=0x3 register address = 0xA032 registers count=1 payload size=0

[17:26:21.790][D][modbus:157]: Modbus error function code: 0x83 exception: 2
[17:26:21.796][E][modbus_controller:094]: Modbus error function code: 0x3 exception: 2
[17:26:21.799][E][modbus_controller:098]: Modbus error - last command: function code=0x3 register address = 0xABE0 registers count=4 payload size=0

Does the rest of the commands work? Or none at all? Not every command of v2 is implemented in v3.

[pierrick]

Some commands work but I have to learn how each command acts over the battery.
I will try to command charge and discharge manually from the RS485 command and set the value.
I will post the results.
But the logs show error for 0xA032 and 0xABE0

[dbra]

pierrick schreef op donderdag 23 oktober 2025 @ 17:27:
[...]

Thank you for your help.
I changed to the 'lilygo-rs485.yaml' but I'm already in firmware v139

And always bad modbus address:

[17:26:21.537][D][modbus:157]: Modbus error function code: 0x83 exception: 2
[17:26:21.541][E][modbus_controller:094]: Modbus error function code: 0x3 exception: 2
[17:26:21.546][E][modbus_controller:098]: Modbus error - last command: function code=0x3 register address = 0xA032 registers count=1 payload size=0

[17:26:21.790][D][modbus:157]: Modbus error function code: 0x83 exception: 2
[17:26:21.796][E][modbus_controller:094]: Modbus error function code: 0x3 exception: 2
[17:26:21.799][E][modbus_controller:098]: Modbus error - last command: function code=0x3 register address = 0xABE0 registers count=4 payload size=0

Address 0xA032 (decimal 44000) is lilygo_rs485_marstek_charging_cutoff_capacity
Address 0xABE0 (decimal 41010) is power_restriction_discharge

Both these registers are not supported on my Venus C v3 with software version 139 (or this information is at a different but currently unknown register address). I get error messages as well for these registers.

I commented the sections out for registers 44000 and 41010 in the YAML, as I wanted to get rid of the error codes.

If you can read most of the other registers, you're all set.

My hypothesis is that in future software version, these registers will be supported.

I hope this helps.

[Goosmeister]

crabe919 schreef op woensdag 22 oktober 2025 @ 18:09:
[...]


Zou je een linkje hebben naar de Yaml files voor de V3, ikzelf ben niet genoeg thuis in het herprogrammeren van zon'n dingen..;

Dank!

Deze heb ik gebruikt en in de instructies staan de yaml files en waar deze moeten komen te staan.
https://github.com/WargamingPlayer/HA-Marstek-Venus-E-Modbus
In deze yaml moet je in de secties voor V1/2 een # zetten om deze uit te schakelen en de # weghalen bij de V3 om deze te activeren.

Een dingetje: ik kan de accu wel goed uitlezen maar nog niet alles aansturen om te laden/ontladen. Alleen de standaard selecties: trade / manual / anti feed zijn in te stellen

[Goosmeister]

Ik gebruik een Marstek Venus V3 (firmware 139) samen met een Elfin TCP/IP RS485-adapter..
De Home Assistant-integratie van WargamingPlayer werkt over het algemeen prima — ik kan de waardes uitlezen, het vermogen aanpassen en de verschillende modi gebruiken (handmatig, zelf geïnitieerd en AI-optimalisatie).

Wat me echter niet lukt, is het geforceerd laden of ontladen, en het inschakelen van RS485 control.
Heeft iemand dit al eens werkend gekregen? En zo ja, hoe is dat gedaan? Ik loop hier namelijk een beetje op vast.

[ Voor 14% gewijzigd door Goosmeister op 24-10-2025 01:19 ]

[crabe919]

Goosmeister schreef op donderdag 23 oktober 2025 @ 22:50:
[...]


Deze heb ik gebruikt en in de instructies staan de yaml files en waar deze moeten komen te staan.
https://github.com/WargamingPlayer/HA-Marstek-Venus-E-Modbus
In deze yaml moet je in de secties voor V1/2 een # zetten om deze uit te schakelen en de # weghalen bij de V3 om deze te activeren.

Een dingetje: ik kan de accu wel goed uitlezen maar nog niet alles aansturen om te laden/ontladen. Alleen de standaard selecties: trade / manual / anti feed zijn in te stellen

Thanks!

[crabe919]

superduper1969 schreef op donderdag 23 oktober 2025 @ 13:09:
[...]

Zonder dat ik weet wat de broncode is, ik kon gewoon de foutmelding in Copilot kopieren en die kwam met een plausibel antwoord.
Natuurlijk kun je ook met een andere AI aan de slag, de meeste leggen ook uit wat ze "Vreemd" vinden, maken een "Actieplan" hoe ze het denken op te lossen en geven voorbeelden waarvan hun denken wat het zou moeten zijn.

Gisteravond samen met Youtube en Copilot een automatisering gemaakt voor HA die via Google Maps-Locatie delen de batteij-status van de telefoon van mijn vader ophaalt en bij een batterij percentage van 5% een melding in zijn kalender zet die altijd op zijn in vaste opstelling geplaatste tablet wordt gepresenteerd. "Telefoon Opladen" (Als 81 jarige vergeet je wel eens wat)

Dank voor de reactie!
Op heden eigenlijk geen ervaring met AI, maar heb deze ingezet en het probleem opgelost.
Terug iets bijgeleerd!

Goosmeister schreef op donderdag 23 oktober 2025 @ 22:50:
[...]

Een dingetje: ik kan de accu wel goed uitlezen maar nog niet alles aansturen om te laden/ontladen. Alleen de standaard selecties: trade / manual / anti feed zijn in te stellen

Zijn dit voorlopig de enige opties in V139 V3?

[RF1000]

Goosmeister schreef op donderdag 23 oktober 2025 @ 22:50:
[...]


Deze heb ik gebruikt en in de instructies staan de yaml files en waar deze moeten komen te staan.
https://github.com/WargamingPlayer/HA-Marstek-Venus-E-Modbus
In deze yaml moet je in de secties voor V1/2 een # zetten om deze uit te schakelen en de # weghalen bij de V3 om deze te activeren.

...

Noob vraag; deze yaml files (en werkwijze) kunnen ook gebruikt worden voor een lilygo?

[_ferry_]

Goosmeister schreef op vrijdag 24 oktober 2025 @ 00:51:
Ik gebruik een Marstek Venus V3 (firmware 139) samen met een Elfin TCP/IP RS485-adapter..
De Home Assistant-integratie van WargamingPlayer werkt over het algemeen prima — ik kan de waardes uitlezen, het vermogen aanpassen en de verschillende modi gebruiken (handmatig, zelf geïnitieerd en AI-optimalisatie).

Wat me echter niet lukt, is het geforceerd laden of ontladen, en het inschakelen van RS485 control.
Heeft iemand dit al eens werkend gekregen? En zo ja, hoe is dat gedaan? Ik loop hier namelijk een beetje op vast.
[Afbeelding]

Daarvoor moet je eerst de control mode aan zetten. Of zijn ze beide greyed out/niet beschikbaar?

[denbeire]

Heeft iemand met de V3 (FW v139) de Cycle Count succesvol uitgelezen, en zo ja, welk exact startadres en datatype (en eventueel swap) is hiervoor nodig?

[WargamingPlayer]

Goosmeister schreef op vrijdag 24 oktober 2025 @ 00:51:
Ik gebruik een Marstek Venus V3 (firmware 139) samen met een Elfin TCP/IP RS485-adapter..
De Home Assistant-integratie van WargamingPlayer werkt over het algemeen prima — ik kan de waardes uitlezen, het vermogen aanpassen en de verschillende modi gebruiken (handmatig, zelf geïnitieerd en AI-optimalisatie).

Wat me echter niet lukt, is het geforceerd laden of ontladen, en het inschakelen van RS485 control.
Heeft iemand dit al eens werkend gekregen? En zo ja, hoe is dat gedaan? Ik loop hier namelijk een beetje op vast.
[Afbeelding]

Helaas geen V3 om dit te testen.

[pascallj]

denbeire schreef op vrijdag 24 oktober 2025 @ 09:31:
Heeft iemand met de V3 (FW v139) de Cycle Count succesvol uitgelezen, en zo ja, welk exact startadres en datatype (en eventueel swap) is hiervoor nodig?

Dit was op de V2 ook niet aanwezig dus lijkt me sterk dat het in de V3 wel zit. Heb je een aanleiding om aan te nemen dat het bestaat?

[denbeire]

pascallj schreef op vrijdag 24 oktober 2025 @ 10:05:
[...]


Dit was op de V2 ook niet aanwezig dus lijkt me sterk dat het in de V3 wel zit. Heb je een aanleiding om aan te nemen dat het bestaat?

neen, ik ging er gewoon vanuit dat deze er wel zou inzitten

[superduper1969]

RF1000 schreef op vrijdag 24 oktober 2025 @ 08:47:
[...]


Noob vraag; deze yaml files (en werkwijze) kunnen ook gebruikt worden voor een lilygo?

In de startpost staat hoe je een Lilygo kunt laten werken als een Elfin.
- https://github.com/rosenrot00/esphome_modbus_bridge Maak van de Lilygo een Elfin.

[Landon]

Ik heb een Marstek V2 perfect draaien met Lilygo in Home Assistant en heb zojuist een Marstek V3 besteld, kan ik deze ook dmv Lilygo aansluiten, of wordt iets anders aangeraden?

[HotSpot79]

Goedemiddag, ik heb de v2 aangesloten icm een Growatt APX systeem en een conpleet PV systeem. Nu is het zo dat de Growatt APX systeem de p1 meter rond de 0 houdt. Netjes en ook de bedoeling.

Echter, met de Marstek erbij gaat deze dan opladen uit mijn APX accu, omdat deze denkt dat er overschot is.

Ik zou dus graag willen dat de Marstek gaat laden als er echt een solar overschot is (groter dan -200 W), want het is jiet echt handig dat de ene batterij de andere leeg trekt.

Hoe zou ik zoiets kunnen realiseren. Ik heb de Marstek aan de LiliGo PRO hangen.

Ik gebruik ook HA.

[dbra]

Landon schreef op vrijdag 24 oktober 2025 @ 14:53:
Ik heb een Marstek V2 perfect draaien met Lilygo in Home Assistant en heb zojuist een Marstek V3 besteld, kan ik deze ook dmv Lilygo aansluiten, of wordt iets anders aangeraden?

Als eerste moet je software versie 139 vragen van de Marstek helpdesk. Daarna kun je de Lilygo met dezelfde YAML gebruiken als de V2, alleen zul je merken dat sommige registers nog niet zijn geïmplementeerd, en dat je een aantal waarden door 100 moet delen. De belangrijke dingen werken gewoon.

Zie ook mijn eerdere post:

dbra in "Marstek Venus / Duravolt PnP Thuisaccu Modbus koppeling"

[dbra]

HotSpot79 schreef op vrijdag 24 oktober 2025 @ 17:28:
Goedemiddag, ik heb de v2 aangesloten icm een Growatt APX systeem en een conpleet PV systeem. Nu is het zo dat de Growatt APX systeem de p1 meter rond de 0 houdt. Netjes en ook de bedoeling.

Echter, met de Marstek erbij gaat deze dan opladen uit mijn APX accu, omdat deze denkt dat er overschot is.

Ik zou dus graag willen dat de Marstek gaat laden als er echt een solar overschot is (groter dan -200 W), want het is jiet echt handig dat de ene batterij de andere leeg trekt.

Hoe zou ik zoiets kunnen realiseren. Ik heb de Marstek aan de LiliGo PRO hangen.

Ik gebruik ook HA.

Ik vermoed dat dit te implementeren moet zijn via Home Assistant. Je kunt de Marstek via zijn RS485 poort aan HA koppelen met een Lilygo; er is eerder beschreven in dit topic hoe dat moet. Daarna moet je ook zorgen dat je in HA het vermogen van je slimme meter kunt uitlezen. Vervolgens kun je via een automation in HA de Marstek van Manual (zolang er geen stroomoverschot is) in anti-feed zetten zodra er stroomoverschot is.

Zodra de zon onder is, moet je nadenken over hoe je APX en de Marstek wil aansturen (de Marstek in anti-feed mode zodra de APX leeg is?).

[pascallj]

dbra schreef op vrijdag 24 oktober 2025 @ 18:40:
[...]


Ik vermoed dat dit te implementeren moet zijn via Home Assistant. Je kunt de Marstek via zijn RS485 poort aan HA koppelen met een Lilygo; er is eerder beschreven in dit topic hoe dat moet. Daarna moet je ook zorgen dat je in HA het vermogen van je slimme meter kunt uitlezen. Vervolgens kun je via een automation in HA de Marstek van Manual (zolang er geen stroomoverschot is) in anti-feed zetten zodra er stroomoverschot is.

Zodra de zon onder is, moet je nadenken over hoe je APX en de Marstek wil aansturen (de Marstek in anti-feed mode zodra de APX leeg is?).

Ik zou niet aanraden om Anti-Feed überhaupt nog te gebruiken. Je hebt dan twee batterijen die allebei naar de P1 meter kijken en blijven compenseren. Bij stabiele zonneschijn kan het goed gaan, maar bij een klein wolkje is het systeem uit balans en is het afhankelijk van de reactietijden wie wie gaat opladen. Als dat eenmaal gestabiliseerd is blijft dat doorgaan en kan je het (aan de hand van de P1 meter) niet meer detecteren.

Heb je communicatie met het Growatt systeem om die parameters uit te lezen? Dat zou het makkelijkst zijn en kan je op basis daarvan gaan programmeren. Anders zal je een combinatie moeten maken van de data uit je zonnepanelen + slimme meter. Je hebt in elk geval meer data nodig om dit goed te laten gaan. Wat wel nog kan is zelf een implementatie schrijven die significant trager is dan je Growatt systeem en een grote hysterese heeft, die wel gebruik maakt van alleen de P1 meter maar echt alleen bij grote overschotten die een lange tijd aanhouden gaat laden. Gaan moeten 'programmeren' zal je sowieso.

[WargamingPlayer]

denbeire schreef op vrijdag 24 oktober 2025 @ 09:31:
Heeft iemand met de V3 (FW v139) de Cycle Count succesvol uitgelezen, en zo ja, welk exact startadres en datatype (en eventueel swap) is hiervoor nodig?

Cycle count is niet uit te lezen. Ook niet door Hame (Fabrikant) in China. Ik heb bewijs voor deze uitspraak indien mensen dat willen.

Members only:

Alleen zichtbaar voor ingelogde gebruikers. Inloggen

[dbra]

pascallj schreef op vrijdag 24 oktober 2025 @ 18:53:
[...]


Ik zou niet aanraden om Anti-Feed überhaupt nog te gebruiken. Je hebt dan twee batterijen die allebei naar de P1 meter kijken en blijven compenseren. Bij stabiele zonneschijn kan het goed gaan, maar bij een klein wolkje is het systeem uit balans en is het afhankelijk van de reactietijden wie wie gaat opladen. Als dat eenmaal gestabiliseerd is blijft dat doorgaan en kan je het (aan de hand van de P1 meter) niet meer detecteren.

Heb je communicatie met het Growatt systeem om die parameters uit te lezen? Dat zou het makkelijkst zijn en kan je op basis daarvan gaan programmeren. Anders zal je een combinatie moeten maken van de data uit je zonnepanelen + slimme meter. Je hebt in elk geval meer data nodig om dit goed te laten gaan. Wat wel nog kan is zelf een implementatie schrijven die significant trager is dan je Growatt systeem en een grote hysterese heeft, die wel gebruik maakt van alleen de P1 meter maar echt alleen bij grote overschotten die een lange tijd aanhouden gaat laden. Gaan moeten 'programmeren' zal je sowieso.

Ik denk dat je een punt hebt qua anti-feed. Als je het Growatt systeem ook vanuit HA kunt uitlezen en besturen, zou je de anti-feed tussen de twee accu systemen kunnen schakelen, dus eerst de ene accu laden en dan de andere. Bij ontladen idem.

[Goosmeister]

_ferry_ schreef op vrijdag 24 oktober 2025 @ 08:52:
[...]

Daarvoor moet je eerst de control mode aan zetten. Of zijn ze beide greyed out/niet beschikbaar?

Beide helaas grayed out.

[Goosmeister]

dbra schreef op vrijdag 24 oktober 2025 @ 18:31:
[...]


Als eerste moet je software versie 139 vragen van de Marstek helpdesk. Daarna kun je de Lilygo met dezelfde YAML gebruiken als de V2, alleen zul je merken dat sommige registers nog niet zijn geïmplementeerd, en dat je een aantal waarden door 100 moet delen. De belangrijke dingen werken gewoon.

Zie ook mijn eerdere post:

dbra in "Marstek Venus / Duravolt PnP Thuisaccu Modbus koppeling"

Zover ben ik ook. Heb je misschien ook het laden en ontladen vanuit HA aan de praat?

[Goosmeister]

WargamingPlayer schreef op vrijdag 24 oktober 2025 @ 09:41:
[...]

Helaas geen V3 om dit te testen.

Dank je voor je integratie en die komt een heel eind met de v3, echt heel blij mee!😀

[dbra]

Goosmeister schreef op vrijdag 24 oktober 2025 @ 22:50:
[...]


Zover ben ik ook. Heb je misschien ook het laden en ontladen vanuit HA aan de praat?

Ja dat werkt met de V3. Ik heb het onderstaande dashboardje gebouwd (YAML onderaan). Eerst zet je de Mode op Manual, Daarna Manual Mode op Enable, je stelt b.v. Discharge Power in op 500 Watt en vervolgens Set mode op Discharge. Daarna gaat hij met 500 Watt ontladen. Mijn huisverbruik was op dat moment ca. 80 watt, dus exporteer ik 419 Watt.





type: entities
entities:
- entity: select.esphome_web_a85944_marstek_user_work_mode
name: Mode
- entity: select.esphome_web_a85944_marstek_rs485_control_mode
name: Manual Mode (be carefull)
- entity: select.esphome_web_a85944_marstek_forcible_charge_discharge
name: Set Mode
secondary_info: none
- entity: select.esphome_web_a85944_marstek_backup_function
name: Enable Backup Socket
- entity: number.esphome_web_a85944_marstek_forcible_charge_power
name: Charge Power Setting
- entity: number.esphome_web_a85944_marstek_forcible_discharge_power
name: Discharge Power Setting
- entity: number.esphome_web_a85944_marstek_charge_to_soc
name: Desired State of Charge

[AUijtdehaag]

Voor de nodered gebruikers van de code van @GAEvakYD en zijn collega is er weer een video geplaatst.

[pierrick]

dbra schreef op donderdag 23 oktober 2025 @ 20:39:
[...]


Address 0xA032 (decimal 44000) is lilygo_rs485_marstek_charging_cutoff_capacity
Address 0xABE0 (decimal 41010) is power_restriction_discharge

Both these registers are not supported on my Venus C v3 with software version 139 (or this information is at a different but currently unknown register address). I get error messages as well for these registers.

I commented the sections out for registers 44000 and 41010 in the YAML, as I wanted to get rid of the error codes.

If you can read most of the other registers, you're all set.

My hypothesis is that in future software version, these registers will be supported.

I hope this helps.

You made an inversion:
Address 0xABE0 (decimal 41010) is lilygo_rs485_marstek_charging_cutoff_capacity
Address 0xA032 (decimal 44000) is power_restriction_discharge

I must also comment 44001, 44002 et 44003 to avoid same errors
Now, I haven't errors in logs but I must check If I can control charge and discharge and set power value.

Some questions... Is the system responsive wit RS485? Can I avoid anti-feed mode and command myself the power charge and discharge?
I find that anti-feed mode is not very responsive and it very often oscillates around 0...
Indeed, I would like to creat y own anti-feed system by controling the charge and discharge

[dbra]

pierrick schreef op zaterdag 25 oktober 2025 @ 11:52:
[...]

You made an inversion:
Address 0xABE0 (decimal 41010) is lilygo_rs485_marstek_charging_cutoff_capacity
Address 0xA032 (decimal 44000) is power_restriction_discharge

I must also comment 44001, 44002 et 44003 to avoid same errors
Now, I haven't errors in logs but I must check If I can control charge and discharge and set power value.

Some questions... Is the system responsive wit RS485? Can I avoid anti-feed mode and command myself the power charge and discharge?
I find that anti-feed mode is not very responsive and it very often oscillates around 0...
Indeed, I would like to creat y own anti-feed system by controling the charge and discharge

Hi, on commanding charge and discharge; see two posts back. I even added some YAML code. Let me know if you have further questions.

On the power tracking of the battery in anti-feed mode; I am experimenting with both power meters from Marstek, the CT-0002 and CT-003. I will post the results here once I gathered some more data. The CT-002 is inductively coupled to the three phase feed, the CT-003 is a dongle that connects to your smartmeter's P1 port.

My initial conclusions are that the CT-002 may be a bit quicker to track big changes in power consumption, as it doesn't need to wait for the power numbers to be published on the smartmeter's P1 port. But it seems less accurate; with the CT-002 I often keep importing about 10 watt from the net even when the house consumes a stable load at night. It is also always off by a few watt compared to my smartmeter P1 reading. I deem 10 watt a lot, since my baseload at night was 28 watt only before I bought this battery. With the CT-003, the battery seems to be able to reduce import to low single digit numbers.

There also seems to be a CT polling rate parameter, which can be set using the BLE tool, but I didn't notice a difference.

I also found the CT-003 very difficult to install in my panel; the inductive pickups are very big and there is a bunch of wire between the pickups and the CT-003. Also, the CT-003 tripped my RCD device on L1 so I had to attach it to the L1 phase of my hob. So far I would advice against it. Perhaps a software update will change my opinion in the future....

I hope this helps.

[dbra]

pierrick schreef op zaterdag 25 oktober 2025 @ 11:52:
[...]

You made an inversion:
Address 0xABE0 (decimal 41010) is lilygo_rs485_marstek_charging_cutoff_capacity
Address 0xA032 (decimal 44000) is power_restriction_discharge

I must also comment 44001, 44002 et 44003 to avoid same errors
Now, I haven't errors in logs but I must check If I can control charge and discharge and set power value.

Some questions... Is the system responsive wit RS485? Can I avoid anti-feed mode and command myself the power charge and discharge?
I find that anti-feed mode is not very responsive and it very often oscillates around 0...
Indeed, I would like to creat y own anti-feed system by controling the charge and discharge

I haven't tested responsiveness. See also my post above about Martek's power meters.

I also disabled 44001, but not 44002 and 44003. Not sure if the latter are working.

I get one more error, but that is in a row of ten registers that is being red in one go, I could not bother to address so far.

If you want to write your own anti-feed routines, think about whether you want to remove or modify the skip_updates: statements in your YAML, since these reduce the frequency at which some parameters are polled from the battery.