Marstek Venus / Duravolt PnP Thuisaccu Modbus koppeling

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

[jj85]

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


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.

Wat @afnay schrijft werkt hier ook. Heel vaak drukken en opeens is updaten mogelijk

[pascallj]

jj85 schreef op woensdag 17 december 2025 @ 23:06:
[...]

Wat @afnay schrijft werkt hier ook. Heel vaak drukken en opeens is updaten mogelijk

Op een V3 ook?

[jj85]

pascallj schreef op woensdag 17 december 2025 @ 23:06:
[...]


Op een V3 ook?

Yes

[comfix]

Gisteren de batterijen v3 geupdated naar fw v145 en nu is de DOD instelling beschikbaar. Deze staat nu op 12% ipv de 11% voordien. Ik vraag me af hoe het zit met de garantie en hoe diep je mag ontladen, dat is me niet duidelijk.

Zijn er al die deze instelling via modbus kunnen aanspreken? Zo ja welk register?
Op de Duravolt website https://duravolt.nl/wp-co...lug-in-Battery-Modbus.pdf staat deze op de pdf; discharging cutoff capacity op regiser 44001.

update:
Dus dit adres geeft geen return en is dus niet gebruikt. Jammer..

[ Voor 7% gewijzigd door comfix op 18-12-2025 16:34 ]

[savale]

pascallj schreef op woensdag 17 december 2025 @ 23:06:
[...]


Op een V3 ook?

Ik was skeptisch, maar zojuist geprobeerd: en ja hoor van v139 naar v145 kunnen updaten. De ene accu ging al na 2 a 3x klikken. De andere pas na 30x, maar alles is over naar v145.
Mooie ontdekking @afnay

[ Voor 4% gewijzigd door savale op 18-12-2025 10:05 ]

[lvelve]

savale schreef op donderdag 18 december 2025 @ 10:04:
[...]


Ik was skeptisch, maar zojuist geprobeerd: en ja hoor van v139 naar v145 kunnen updaten. De ene accu ging al na 2 a 3x klikken. De andere pas na 30x, maar alles is over naar v145.
Mooie ontdekking @afnay

Haha, mooi. Ik had vorige week gevraagd om een upgrade en kreeg v144. Vanmorgen een keer of 10 geklikt op upgrade. Nu staat er een upgrade klaar. Vanavond thuis eens proberen....

Mooie ontdekking inderdaad!

[Tazzios]

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.

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

Geniaal, mag in de TS vermeld worden. Begin deze week een upgrade gevraagd van 139 naar 144 zojuist de truc ook geprobeerd en heb nu 145.

Zal flink wat support vragen schelen bij Marstek.

[pascallj]

Aangezien er nu ook berichten zijn van mensen waar het updaten vanzelf is gegaan, heb ik meer het idee dat het gefaseerd wordt uitgerold en je door vaak op de knop te drukken dat je kans gereset wordt dat je de update krijgt oid.

[comfix]

pascallj schreef op donderdag 18 december 2025 @ 11:28:
Aangezien er nu ook berichten zijn van mensen waar het updaten vanzelf is gegaan, heb ik meer het idee dat het gefaseerd wordt uitgerold en je door vaak op de knop te drukken dat je kans gereset wordt dat je de update krijgt oid.

Ik heb via support gevraagd om de laatste stabiele update te pushen, deze is de v145.

[BjornVH]

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.

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

Haha! Ik heb net ook geramd op de versie en krijg ook de nieuwe aangeboden op deze manier. Nice find.

[Hometek]

Vanochtend is één van mijn Marstek batterijen plotseling onder de 11% gezakt, oorzaak vermodelijk SOC drift, te lang niet naar 100% opgeladen. De EMS/BMS heeft correct gereageerd door onmiddelijk met 600W op te laden tot SOC 12%.
Ik gebruik in mijn HA opzet echter tellers die de SOC veranderingen bijhouden per bron en actuele prijs (zie ook deze post). Deze tellers kijken naar de 'Control Mode' entiteit, als deze enabled is wordt er van het net opgeladen (manual), bij disabled komt de stroom van de PV (NOM) en wordt er een andere teller en prijs gebruikt.
Het opladen door de EMS/BMS vandaag is als PV opwek door mijn tellers geregistreerd omdat de EMS de 'Control Mode' niet activeert.

Heeft iemand een idee naar welke data in HA ik kan kijken om op een makkelijke manier te zien of de batterij op dat moment zelfstandig, dus niet manual of NOM, aan het laden is?

[pascallj]

Hometek schreef op maandag 22 december 2025 @ 15:44:
Vanochtend is één van mijn Marstek batterijen plotseling onder de 11% gezakt, oorzaak vermodelijk SOC drift, te lang niet naar 100% opgeladen. De EMS/BMS heeft correct gereageerd door onmiddelijk met 600W op te laden tot SOC 12%.
Ik gebruik in mijn HA opzet echter tellers die de SOC veranderingen bijhouden per bron en actuele prijs (zie ook deze post). Deze tellers kijken naar de 'Control Mode' entiteit, als deze enabled is wordt er van het net opgeladen (manual), bij disabled komt de stroom van de PV (NOM) en wordt er een andere teller en prijs gebruikt.
Het opladen door de EMS/BMS vandaag is als PV opwek door mijn tellers geregistreerd omdat de EMS de 'Control Mode' niet activeert.

Heeft iemand een idee naar welke data in HA ik kan kijken om op een makkelijke manier te zien of de batterij op dat moment zelfstandig, dus niet manual of NOM, aan het laden is?

Bij de V1&2 weet ik dat er op dat moment 1 van de error codes is die afgaat. Het is alleen in mijn geval te lang geleden om te zien welke dat was. Zo lang hou ik geen HA historie bij.

Ik geloof dat het 'Low Battery SOC Warning' welke ik momenteel op adres 36100 met bitmask 0x10 gemapt heb.

Dit was alleen wel bij BMS versie 215 die dus meteen gaat bijladen zodra je onder de 11 procent komt. Hoe dat zit bij nieuwere BMS versies die je lager laten gaan, weet ik niet. Kan zijn dat dan de error afgaat nog voordat er geladen wordt.

[Hometek]

pascallj schreef op maandag 22 december 2025 @ 15:49:
[...]
Bij de V1&2 weet ik dat er op dat moment 1 van de error codes is die afgaat. Het is alleen in mijn geval te lang geleden om te zien welke dat was. Zo lang hou ik geen HA historie bij.

Ik geloof dat het 'Low Battery SOC Warning' welke ik momenteel op adres 36100 met bitmask 0x10 gemapt heb.

Dit was alleen wel bij BMS versie 215 die dus meteen gaat bijladen zodra je onder de 11 procent komt. Hoe dat zit bij nieuwere BMS versies die je lager laten gaan, weet ik niet. Kan zijn dat dan de error afgaat nog voordat er geladen wordt.

Bedankt voor de tip. Ik zal de error codes eens bekijken.

[dbra]

Ik kreeg vandaag ook het bericht dat ik de softwre versie van mijn V3 kon updaten, maar ook als ik naast het apparaat staat lukt het niet omdat de app geen Bluetooth verbinding krijgt met mijn accu. In de app zie ik ook alleen het groene lan icoontje (ik gebruikl geen Wifi, alleen de LAN kabel) en niet meer het groene Bluetooth icoontje. Ik kan in het bluetooth scherm van mijn telefoon de batterij wel zien. Als ik probeer te koppelen, dan gaat het BT lampje branden op mijn batterij, maar mijn telefoon maakt nooit verbinding en timed op een gegeven moment out. Fabrieksreset van de batterij helpt niet.

Heeft iemand een suggestie?

[pascallj]

dbra schreef op dinsdag 23 december 2025 @ 19:32:
Ik kreeg vandaag ook het bericht dat ik de softwre versie van mijn V3 kon updaten, maar ook als ik naast het apparaat staat lukt het niet omdat de app geen Bluetooth verbinding krijgt met mijn accu. In de app zie ik ook alleen het groene lan icoontje (ik gebruikl geen Wifi, alleen de LAN kabel) en niet meer het groene Bluetooth icoontje. Ik kan in het bluetooth scherm van mijn telefoon de batterij wel zien. Als ik probeer te koppelen, dan gaat het BT lampje branden op mijn batterij, maar mijn telefoon maakt nooit verbinding en timed op een gegeven moment out. Fabrieksreset van de batterij helpt niet.

Heeft iemand een suggestie?

Verbinden via het BT menu hoef je nooit te doen, want de batterij maakt verbinding via BLE en hoeft daarvoor niet te pairen. Maar dat geeft dus wel aan dat je niet de Bluetooth lock aan hebt staan (als jouw versie die überhaupt al had gehad).

Op Android even controleren of de app nog de rechten heeft tot locatietoegang en toegang om te "Verbinden met apparaten in de buurt". Dit is nodig om via BLE apparaten te vinden.

[dbra]

[quote]pascallj schreef op dinsdag 23 december 2025 @ 19:58:
[...]


OK, ik heb de oplossng en post maar even hier voor als iemand er ook last van heeft. Ik heb de app opnieuw geinstalleerd, en toen deed hij het opeens. Locatie en apparaten in de buurt waren toegestaan, dus dat was het niet,.

[ Voor 51% gewijzigd door dbra op 23-12-2025 20:39 ]

[pascallj]

dbra schreef op dinsdag 23 december 2025 @ 20:11:
[...]


"Apparaten in de buurt voor deze app" staat op toegestaan.

Andere suggesties zijn welkom.

En locatie?

[adjego]

Sinds gisteren de Marstek Venus E V3 binnen en natuurlijk voor zover geinstalleerd. Kan hem al aansturen via Home Assistant ism de rs485 module van @AUijtdehaag

Nu valt me alleen op dat de waardes die betrekking hebben tot de kWh niet ophogen. Dit blijft allemaal op 0 staan. Via RS485, maar ook in de app, dus het lijkt een probleem te zijn aan de kant van de Marstek. Hier meerdere mensen die dit al gezien hebben, en eventueel ook een manier hebben gevonden hoe dit is op te lossen?

[pascallj]

adjego schreef op woensdag 24 december 2025 @ 13:13:
Sinds gisteren de Marstek Venus E V3 binnen en natuurlijk voor zover geinstalleerd. Kan hem al aansturen via Home Assistant ism de rs485 module van @AUijtdehaag

Nu valt me alleen op dat de waardes die betrekking hebben tot de kWh niet ophogen. Dit blijft allemaal op 0 staan. Via RS485, maar ook in de app, dus het lijkt een probleem te zijn aan de kant van de Marstek. Hier meerdere mensen die dit al gezien hebben, en eventueel ook een manier hebben gevonden hoe dit is op te lossen?

We hebben dit laatst ook al eens gezien in het andere topic bij een nieuwe batterij. Heb je de meest recente firmware geïnstalleerd? Probeer ook eens een factory reset zonder behoud van gegevens.

[dbra]

adjego schreef op woensdag 24 december 2025 @ 13:13:
Sinds gisteren de Marstek Venus E V3 binnen en natuurlijk voor zover geinstalleerd. Kan hem al aansturen via Home Assistant ism de rs485 module van @AUijtdehaag

Nu valt me alleen op dat de waardes die betrekking hebben tot de kWh niet ophogen. Dit blijft allemaal op 0 staan. Via RS485, maar ook in de app, dus het lijkt een probleem te zijn aan de kant van de Marstek. Hier meerdere mensen die dit al gezien hebben, en eventueel ook een manier hebben gevonden hoe dit is op te lossen?

Als je niet ten minste versie 139 van de software hebt, komen veel van de waarden niet door. En zelfs met versie 139 missen er nog waarden.

Je kunt een software upgrade aanvragen via de app.

[eassinck]

Goedemiddag,

Situatie:
- Marstek Venus E V3
- UTP 568A kabel (aan 1 zijde gestript)
- Waveshare RS232/485 to Wifi ETH
- Wifi en kabel verbinding tot stand gebracht
- Home assistant

Ik krijg de data verbinding tussen de waveshare en mijn pc / home assistant niet voor elkaar. Dat wil zeggen, als ik de tool Bodbus Poll gebruik dan krijg ik alleen maar 'insufficien bytes received' meldingen. (er lijkt dus wel verbinding te zijn)

De Marstek en Waveshare heb ik met elkaar verbonden via een UTP kabel, ene zijde gewoon in de RS485 poort van de Marstek en de andere zijde gestript. Volgens eerder opgave in dit forum ben ik uitgekomen op de 2 oranje kabels. Oranje in A en Wit-Oranje in B levert bij mij een groen RXD lampje op. Dat zeggende ga ik er vanuit dat de accu goed is gekoppeld aan de waveshare.

Daarna heb ik de waveshare gekoppeld aan mijn thuisnetwerk. Dit heb ik gedaan door de waveshare via zijn eigen wifi te verbinden aan de laptop. Daar kon ik via het ip adres 10.10.1.254 de instellingen van de waveshare aanpassen. Zo gedaan en nu kan ik binnen mijn thuisnetwerk verbinden met de Waveshare op een eigen vast ip adres. Ik kan dus ook in mijn thuisnetwerk nu de instellingen van de waveshare aanpassen.

In de waveshare heb ik een aantal zaken nagelopen of aangepast op basis van wat ik in dit forum en andere hulp paginas kon vinden:
- modus opo Modbus TCP gezet
- Baudrate op verschillende standen gehad zonder resultaat (9600, 19200,115200)
- Data Bits op 8
- parity op none
- Stop op 1

Netwerk A setting op TCP server, poort 502.

Dan is er ook nog een socket B setting.
Die setting kun je aan of uit zetten en vervolgens kiezen voor TCP of UDP, een poort invullen en een server ip adres. Ik heb alleen geen idee wat ik daar moet invullen.

Ik heb vanalles opgezocht en geprobeert, maar er is zo weinig online te vinden. Ben ik helemaal verkeerd bezig? Kan dit helemaal niet met een Waveshare op de Venus E V3?
Als ik chatGPT om hulp vraag kom ik vast in een loop waarin hij telkens dezelfde zaken wil aanpassen (baudrate of bekabeling aanpassen).

Is er iemand die even met mij mee kan denken?

[Tazzios]

@eassinck welke firmware versie draait je Marstek? In de nieuwere 144 is modbus api direct via de netwerkkabel beschikbaar. De Waveshare heb ik hier verder nog nooit voorbij zien komen.

[eassinck]

Tazzios schreef op zondag 28 december 2025 @ 14:55:
@eassinck welke firmware versie draait je Marstek? In de nieuwere 144 is modbus api direct via de netwerkkabel beschikbaar. De Waveshare heb ik hier verder nog nooit voorbij zien komen.

Dag Tazzios, bedankt voor je reactie.

Ik heb versie V144 inderdaad. Ik had inderdaad ook al iets gelezen over een directe modbus verbinding middels ethernet. Ik heb daar ook wel naar gekeken en ook de Marstek Venus Modbus integratie in Home Assistant al geinstalleerd en via de standaard netwerk verbindiong verbonden met de marstek, maar wat ik daarvan zag lijkt het erg veel op de standaard Marstek Local Api integratie waarmee je veel kan uitlezen, maar niet zoveel kan aansturen.

Bijna 41 entiteiten staan op niet beschikbaar, onder andere de geforceerde modus en RS485 modus.. Ik weet het niet zeker, maar ik vermoed dat ik die nodig heb om zelf de accu aan te sturen. Of heb ik deze Marstek Venus Modbus integratie via ethernet nog niet goed genoeg bekeken?

Wat ik graag wil is zelf de accu aansturen op basis van mijn huis situatie. Ik merk dat de AI instelling van Marstek niet aan mijn wensen voldoet.

[pascallj]

eassinck schreef op zondag 28 december 2025 @ 13:46:
Goedemiddag,

Situatie:
- Marstek Venus E V3
- UTP 568A kabel (aan 1 zijde gestript)
- Waveshare RS232/485 to Wifi ETH
- Wifi en kabel verbinding tot stand gebracht
- Home assistant

Ik krijg de data verbinding tussen de waveshare en mijn pc / home assistant niet voor elkaar. Dat wil zeggen, als ik de tool Bodbus Poll gebruik dan krijg ik alleen maar 'insufficien bytes received' meldingen. (er lijkt dus wel verbinding te zijn)

De Marstek en Waveshare heb ik met elkaar verbonden via een UTP kabel, ene zijde gewoon in de RS485 poort van de Marstek en de andere zijde gestript. Volgens eerder opgave in dit forum ben ik uitgekomen op de 2 oranje kabels. Oranje in A en Wit-Oranje in B levert bij mij een groen RXD lampje op. Dat zeggende ga ik er vanuit dat de accu goed is gekoppeld aan de waveshare.

Daarna heb ik de waveshare gekoppeld aan mijn thuisnetwerk. Dit heb ik gedaan door de waveshare via zijn eigen wifi te verbinden aan de laptop. Daar kon ik via het ip adres 10.10.1.254 de instellingen van de waveshare aanpassen. Zo gedaan en nu kan ik binnen mijn thuisnetwerk verbinden met de Waveshare op een eigen vast ip adres. Ik kan dus ook in mijn thuisnetwerk nu de instellingen van de waveshare aanpassen.

In de waveshare heb ik een aantal zaken nagelopen of aangepast op basis van wat ik in dit forum en andere hulp paginas kon vinden:
- modus opo Modbus TCP gezet
- Baudrate op verschillende standen gehad zonder resultaat (9600, 19200,115200)
- Data Bits op 8
- parity op none
- Stop op 1

Netwerk A setting op TCP server, poort 502.

Dan is er ook nog een socket B setting.
Die setting kun je aan of uit zetten en vervolgens kiezen voor TCP of UDP, een poort invullen en een server ip adres. Ik heb alleen geen idee wat ik daar moet invullen.

Ik heb vanalles opgezocht en geprobeert, maar er is zo weinig online te vinden. Ben ik helemaal verkeerd bezig? Kan dit helemaal niet met een Waveshare op de Venus E V3?
Als ik chatGPT om hulp vraag kom ik vast in een loop waarin hij telkens dezelfde zaken wil aanpassen (baudrate of bekabeling aanpassen).

Is er iemand die even met mij mee kan denken?

Aan alleen dat lampje kan je niet zo veel zien denk ik. Het is lastig om een Modbus bus waar geen verkeer overheen gaat te detecteren. Hier staat overal wit oranje in in A en oranje in B dus ik denk dat je ze omgedraaid hebt.

De baudrate is 115200, 8N1 en standaard adres is 1. Van de rest van de Waveshare instellingen heb ik geen kaas gegeten, dat zal je zelf even moeten uitvogelen.

[Tazzios]

@eassinck de gene die uitstaan kun je aanzetten.

[eassinck]

pascallj schreef op zondag 28 december 2025 @ 21:43:
[...]

Bedankt voor het meedenken Pascallj,

Aan alleen dat lampje kan je niet zo veel zien denk ik. Het is lastig om een Modbus bus waar geen verkeer overheen gaat te detecteren. Hier staat overal wit oranje in in A en oranje in B dus ik denk dat je ze omgedraaid hebt.

De baudrate is 115200, 8N1 en standaard adres is 1. Van de rest van de Waveshare instellingen heb ik geen kaas gegeten, dat zal je zelf even moeten uitvogelen.

Oke, dan is dat toch het proberen waard. Ik ging er eigenlijk vanuit dat ik een combinatie van draden moest gebruiken waarbij ik een rxd signaal zou gaan zien (groen lampje). Dat was alleen in de combinatie zoals ik ze had aangesloten.

Ik had ook al gezocht naar het verschil tussen een 568A en 568B utp kabel. Want in het begin van dit forum hebben ze het over een 568B kabel en ik heb een 568A kabel. Daar is de pinout blijkbaar net iets anders.
Dat zou kunnen betekenen dat ik ook de groene draden ook een kans zou moeten geven.

Die gaven geen signaal (tenminste dat dacht ik) dus die heb ik niet echt getest met de modbus poll.

[eassinck]

Tazzios schreef op zondag 28 december 2025 @ 21:48:
@eassinck de gene die uitstaan kun je aanzetten.

Bedankt Taazzios,

Kun je me verder helpen om deze toch beschikbaar te maken over standaard netwerk?
Onderstaande entiteiten zijn niet beschikbaar.

[ Voor 43% gewijzigd door eassinck op 28-12-2025 23:59 ]

[sheriff]

eassinck schreef op zondag 28 december 2025 @ 23:55:
[...]

Bedankt Taazzios,

Kun je me verder helpen om deze toch beschikbaar te maken over standaard netwerk?
Onderstaande entiteiten zijn niet beschikbaar.

Ja, dat kan gemakkelijk, je kunt die simpel in de integratie inschakelen:

Instellingen, Apparaten en diensten, Marstek Venus Modbus, klik op entiteiten (bv bovenaan in beeld), Zoek de entiteit, klik die aan, en kies knop inschakelen.

[eassinck]

sheriff schreef op maandag 29 december 2025 @ 08:37:
[...]


Ja, dat kan gemakkelijk, je kunt die simpel in de integratie inschakelen:

Instellingen, Apparaten en diensten, Marstek Venus Modbus, klik op entiteiten (bv bovenaan in beeld), Zoek de entiteit, klik die aan, en kies knop inschakelen.

Bedankt voor je reactie.
Zo simpel, dat had ik eigenlijk zelf moeten vinden.

[Tom Jansen]

Hoi, vraag: Mijn marstek V2 heeft zojuist voor de tweede x plotseling nog maar 1%. De vorige x was weken terug. Hij gaat nu zelf aan het laden met zo'n 650w. Normaal gaat hij niet lager dan de normale 11%. Is dit een bekend iets? En zo ja, wat kan ik hieraan doen?
Vast bedankt voor de moeite.....🥴

[pascallj]

Tom Jansen schreef op zaterdag 3 januari 2026 @ 00:17:
Hoi, vraag: Mijn marstek V2 heeft zojuist voor de tweede x plotseling nog maar 1%. De vorige x was weken terug. Hij gaat nu zelf aan het laden met zo'n 650w. Normaal gaat hij niet lager dan de normale 11%. Is dit een bekend iets? En zo ja, wat kan ik hieraan doen?
Vast bedankt voor de moeite.....🥴

Staat hij al lang stil? Als de batterij lang stil staat loopt hij vanzelf leeg. Op een gegeven moment zal er dan bijgeladen moeten worden. In BMS v215 en eerder ging dat al automatisch vanaf 10 procent. Vanaf BMS v216 (niet publiekelijk uitgegeven) gaat dat pas later.

[Tom Jansen]

pascallj schreef op zaterdag 3 januari 2026 @ 00:20:
[...]


Staat hij al lang stil? Als de batterij lang stil staat loopt hij vanzelf leeg. Op een gegeven moment zal er dan bijgeladen moeten worden. In BMS v215 en eerder ging dat al automatisch vanaf 10 procent. Vanaf BMS v216 (niet publiekelijk uitgegeven) gaat dat pas later.

Nee, staat niet stil. Wordt continu gebruikt. 1x per 24 uur naar 100%. Het is een V2. Modbus werkt normaal probleemloos. ....

[pascallj]

Tom Jansen schreef op zaterdag 3 januari 2026 @ 00:26:
[...]

Nee, staat niet stil. Wordt continu gebruikt. 1x per 24 uur naar 100%. Het is een V2. Modbus werkt normaal probleemloos. ....

Hmm bijzonder. Dat hij ging bijladen vanaf 10 procent hebben we steeds vaker gezien naarmate de wintermaanden kwamen en er vaker niet helemaal volgeladen werd. Daarom hebben ze toen v216 gemaakt die wat minder aggressief dat deed. Maar 1 procent + elke 24 uur naar honderd procent, klinkt wel als iets anders.

Je kan nog steeds vragen om v216 voor het BMS voor de zekerheid. Werkt de batterij verder wel naar behoren (capaciteit/vermogen)?

[Tom Jansen]

pascallj schreef op zaterdag 3 januari 2026 @ 00:29:
[...]


Hmm bijzonder. Dat hij ging bijladen vanaf 10 procent hebben we steeds vaker gezien naarmate de wintermaanden kwamen en er vaker niet helemaal volgeladen werd. Daarom hebben ze toen v216 gemaakt die wat minder aggressief dat deed. Maar 1 procent + elke 24 uur naar honderd procent, klinkt wel als iets anders.

Je kan nog steeds vragen om v216 voor het BMS voor de zekerheid. Werkt de batterij verder wel naar behoren (capaciteit/vermogen)?

Ja, werkt perfect. Bijna 1 jaar nu.! Het is overigens na de update van de Lilygo.... Morgen maar eens checken of dat er iets mee te maken heeft. Bij heeft het wel koud in de garage nu.🥶 Geen idee of dat nog invloed heeft op dit vreemde gedrag🧐

[dannyro]

Dit gedrag had ik ook voor, gemeld bij Marstek, update gekregen naar BMS216 en FW V155. Dat was op 15/11, en ik heb dat gedrag niet meer gezien. Ondertussen V156 aangevraagd, en erop gezet. Volgens testen die er gebeurd zijn door anderen zou deze V156 efficiënter zijn voor NOM regeling. Ik zie geen verschil, maar daar is het ook geen weer voor. Mijn Marstek werkt anders voortreffelijk.

[Tom Jansen]

dannyro schreef op zaterdag 3 januari 2026 @ 10:15:
Dit gedrag had ik ook voor, gemeld bij Marstek, update gekregen naar BMS216 en FW V155. Dat was op 15/11, en ik heb dat gedrag niet meer gezien. Ondertussen V156 aangevraagd, en erop gezet. Volgens testen die er gebeurd zijn door anderen zou deze V156 efficiënter zijn voor NOM regeling. Ik zie geen verschil, maar daar is het ook geen weer voor. Mijn Marstek werkt anders voortreffelijk.

Thanks. Verzoek uitgezet bij marstek. Ik kreeg in ieder geval geen updates .... Zijn er met de 216 en v156 geen problemen met de Lilygo te verwachten? Waar halen jullie de BMS versie vandaan? Kan in de app niets vinden 🫣

[ Voor 5% gewijzigd door Tom Jansen op 03-01-2026 10:44 ]

[pascallj]

Tom Jansen schreef op zaterdag 3 januari 2026 @ 10:36:
[...]

Thanks. Verzoek uitgezet bij marstek. Ik kreeg in ieder geval geen updates .... Zijn er met de 216 en v156 geen problemen met de Lilygo te verwachten? Waar halen jullie de BMS versie vandaan? Kan in de app niets vinden 🫣

De update van de LilyGo heeft hier hoogstwaarschijnlijk niets mee te maken. De BMS versie is via Modbus beschikbaar, of kan je zien als je een update aangeboden krijgt.

[Tom Jansen]

pascallj schreef op zaterdag 3 januari 2026 @ 10:53:
[...]


De update van de LilyGo heeft hier hoogstwaarschijnlijk niets mee te maken. De BMS versie is via Modbus beschikbaar, of kan je zien als je een update aangeboden krijgt.

Thanks👊🏻

[eymey]

Tom Jansen schreef op zaterdag 3 januari 2026 @ 00:43:
[...]

Ja, werkt perfect. Bijna 1 jaar nu.! Het is overigens na de update van de Lilygo.... Morgen maar eens checken of dat er iets mee te maken heeft. Bij heeft het wel koud in de garage nu.🥶 Geen idee of dat nog invloed heeft op dit vreemde gedrag🧐

Hier staat de V2 in een cederhouten schuurtje in de tuin. Heb dit gedrag nog niet opgemerkt (hangt hier ook aan een Lilygo).

Ik wacht eigenlijk nog wel op het moment dat het in de schuur zo koud wordt dat hij een keer zegt "Ik laad niet meer"

Afgelopen nacht heb ik de Venus handmatig tot 100% laten laden om nog een keer gecontroleerd te testen wat de efficientie hier nu is.

Het was 2,2 graad in de schuur. Tijdens het laden werd het 4,5 .

Mosfet temperaturen gingen van 5,5 naar 35 graden en na het laden weer terug.

Celtemperaturen van 4 naar 21.

[Tazzios]

Home assistant blueprint weer bijgewerkt.

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: Smoothing factor above delta x
• New: Smoothing factor when passing zero

Marstek X Range OM Blueprint

Verder werk ik aan support voor Marstek venus modbus van ViperRNMC maar dat is nog wat werk omdat entiteitnamen vertaald worden en sommige entiteiten net wat anders werken dan bij Esphome van Lilygo en M5stack.

[AUijtdehaag]

De afgelopen dagen druk bezig geweest om een modbus tcp HA yaml te maken voor venus V3.
https://github.com/fonske/MarstekVenusV3-modbus-TCP-IP

Deze gaat nu meedraaien met 2x esphome modbus modules (V1 en V2) en 1x V3 op modbus tcp/ip via HA
Zodat deze (ook) met de nodered flow van Bob (en zijn collega @GAEvakYD )overweg kan.
https://github.com/gitcodebob/marstek-venus-rs485-node-red

Fouten voorbehouden ;-) Draait hier afgelopen nacht en ochtend prima.

Edit: mocht je de v3 al hebben draaien via esphome modbus module, verwijder dan eerst deze via configuratie - apparaten en diensten - esphome - desbetreffende module
Anders heb je straks entities die eindigen met _2
En dat kost nogal wat werk om deze weer te verwijderen allemaal.

[ Voor 33% gewijzigd door AUijtdehaag op 04-01-2026 10:11 ]

[leejoow]

Voor de mensen die nog LilyGo behuizingen willen bestellen.
Ik heb het product nu op een ander adres staan:

https://www.laserandlayer...houder-marstek-thuisaccu/