Marstek Venus / Duravolt PnP Thuisaccu Modbus koppeling

[pascallj]

WargamingPlayer schreef op donderdag 9 oktober 2025 @ 11:14:
[...]

Modbus is eigenlijk best wel goede oplossing gebleken. Vandaag ziet mijn App dat de CT003 niet verbonden is met MT2. Echter Modbus verteld een heel ander verhaal en ik zie dat hij netjes werkt, ondanks dat de App hem niet kan vinden. Modbus + HA = Geweldig.

@dannyro had het er gisteren ook al over, maar welk register gebruik je dan voor de status van de CT? Want zoals ik gisteren ook al zei, die status is volgens mij helemaal niet opvraagbaar via Modbus.

[WargamingPlayer]

dannyro schreef op donderdag 9 oktober 2025 @ 11:19:
[...]

Alarm van HA naar je Telefoon laten sturen bij uitval CT
edit: ik bedenk mij juist dat dit tot hiertoe alleen gaan met CT uitlezing via Hame Relay. Dit gebruik ik ook.

Dat gebeurd al

Ik wilde vanmorgen kijken in de MT App of alles geod ging nu de zon er was. En toen zag ik dat 1 van de Marsteks geen verbinding had met de CT terwijl de ander dat wel had. Normaal is dat de MT1 die dit gedrag vertoond, maar nu was het opeens de MT2. Echter heeft de andere wel verbinding en de CT rapporteert ook netjes twee verbonden accu's. Echter blijkt dus de tweede Marstek niet met de App/Cloud te communiceren. Maar hij staat we (is in HA te zien via Modbus) netjes te laden

Ga overigens mijn Deco's na tips in het forum voor Netwerk anders neerzetten waardoor de Marsteks ook een line of sight hebben met de derde Deco. Ze staan gewoon te dicht bij elkaar maar te ver van de Marsteks.

[WargamingPlayer]

pascallj schreef op donderdag 9 oktober 2025 @ 11:21:
[...]


@dannyro had het er gisteren ook al over, maar welk register gebruik je dan voor de status van de CT? Want zoals ik gisteren ook al zei, die status is volgens mij helemaal niet opvraagbaar via Modbus.

Ik kan gewoon zien met Mobus dat hij staat te laden, dan weet ik dat de CT is verbonden.

[pascallj]

WargamingPlayer schreef op donderdag 9 oktober 2025 @ 11:25:
[...]

Ik kan gewoon zien met Mobus dat hij staat te laden, dan weet ik dat de CT is verbonden.

Aah ja dat werkt natuurlijk ook

[dannyro]

WargamingPlayer schreef op donderdag 9 oktober 2025 @ 11:25:
[...]

Ik kan gewoon zien met Mobus dat hij staat te laden, dan weet ik dat de CT is verbonden.

En bij "uitgeschakeld" wordt dat bolletje rood. Speelgoed hé

[pascallj]

dannyro schreef op donderdag 9 oktober 2025 @ 11:29:
[...]

En bij "uitgeschakeld" wordt dat bolletje rood. Speelgoed hé

[Afbeelding]

En dat komt uit de Modbus? En werkt ook echt?

[dannyro]

WargamingPlayer schreef op donderdag 9 oktober 2025 @ 11:25:
[...]

Ik kan gewoon zien met Mobus dat hij staat te laden, dan weet ik dat de CT is verbonden.

Ja, maar als er geen zon is en de Marstek staat op 11% en stand-by zie je ook niets hé?

[dannyro]

pascallj schreef op donderdag 9 oktober 2025 @ 11:31:
[...]


En dat komt uit de Modbus? En werkt ook echt?

Neen, dat komt uit Hame Relay. Daarom was mijn vraag gisteren of dit niet mogelijk was bij modbus uitlezing omdat ik dit veel betrouwbaarder vind. Als er een FW update komt en Hame Relay werkt weer niet ben ik deze sensoren kwijt. Ik probeer zo weinig mogelijk te doen met Hame Relay. En ja, dit werkt zeer goed. uitvoerig getest op allerlei manieren. Bij de rode bol krijg ik ook een melding op de telefoon.

[ Voor 11% gewijzigd door dannyro op 09-10-2025 11:36 ]

[pascallj]

dannyro schreef op donderdag 9 oktober 2025 @ 11:34:
[...]

Neen, dat komt uit Hame Relay. Daarom was mijn vraag gisteren of dit niet mogelijk was bij modbus uitlezing omdat ik dit veel betrouwbaarder vind. Als er een FW update komt en Hame Relay werkt weer niet ben ik deze sensoren kwijt. Ik probeer zo weinig mogelijk te doen met Hame Relay. En ja, dit werkt zeer goed. uitvoerig getest op allerlei manieren. Bij de rode bol krijg ik ook een melding op de telefoon.

Gisteren schreef je dat het uit de Atom Stack (dus Modbus) kwam, vandaar de verwarring. Maar goed, dan heb ik dus niks gemist met het testen van registers .

[dannyro]

pascallj schreef op donderdag 9 oktober 2025 @ 11:37:
[...]


Gisteren schreef je dat het uit de Atom Stack (dus Modbus) kwam, vandaar de verwarring. Maar goed, dan heb ik dus niks gemist met het testen van registers .

Dan is dit wel een vergissing, volgens mij heb ik dit niet gezegd, anders had ik de vraag niet gesteld aan @AUijtdehaag Post van woensdag 8 oktober 2025 12:25

[ Voor 4% gewijzigd door dannyro op 09-10-2025 11:46 ]

[Chris96]

Zijn er mensen die een 0 op de meter regeling gemaakt hebben in home assistant via aansturing via de lilygo?

En zijn er ook mensen die stuiter gedrag ervaren doordat de HW p1 meter langzamer data doorgeeft via de B2500 meter dan de Marstek p1 meter?

[b4gg3r1]

Ik wil voor de V3 een rj45 modus kabel maken voor de elfin ew11a.
De kabel voor de V2 was wel duidelijk, maar op pagina 1 spreken een tabel en een plaatje elkaar tegen.

Volgens de tabel zijn
pin 4+5 ( blauw / blauw-wit) +5V
pin 7+8 (bruin-wit / bruin) de GND.

Volgens het plaatje is het precies andersom.

[pascallj]

b4gg3r1 schreef op donderdag 9 oktober 2025 @ 16:00:
Ik wil voor de V3 een rj45 modus kabel maken voor de elfin ew11a.
De kabel voor de V2 was wel duidelijk, maar op pagina 1 spreken een tabel en een plaatje elkaar tegen.

Volgens de tabel zijn
pin 4+5 ( blauw / blauw-wit) +5V
pin 7+8 (bruin-wit / bruin) de GND.

Volgens het plaatje is het precies andersom.
[Afbeelding]

De kleuren kunnen sowieso wijzigen afhankelijk van hoe jouw ethernet kabel bedraad is, dus meten is weten. Maar qua pin-out is het plaatje incorrect en de tabel is juist. Daar kwamen wij ook op de harde manier achter: pascallj in "Marstek Venus / Duravolt PnP Thuisaccu Modbus koppeling"

[b4gg3r1]

pascallj schreef op donderdag 9 oktober 2025 @ 16:03:
[...]


De kleuren kunnen sowieso wijzigen afhankelijk van hoe jouw ethernet kabel bedraad is, dus meten is weten. Maar qua pin-out is het plaatje incorrect en de tabel is juist. Daar kwamen wij ook op de harde manier achter: pascallj in "Marstek Venus / Duravolt PnP Thuisaccu Modbus koppeling"

De standaard die ik altijd volg voor alle NW kabels die ik maak, is
van 1 - 8
OranjeWit, Oranje, GroenWit, Blauw, BlauwWit, Groen, BruinWit, Bruin

Ik wilde de kabel alvast maken, de V3 is onderweg, dus ik kon nog even niets meten ;-)

Maar bedankt, ik maak de kabel alvast, meet voor de zekerheid nog even als de V3 binnen is en dan komt het wel goed.

[dbra]

b4gg3r1 schreef op donderdag 9 oktober 2025 @ 16:00:
Ik wil voor de V3 een rj45 modus kabel maken voor de elfin ew11a.
De kabel voor de V2 was wel duidelijk, maar op pagina 1 spreken een tabel en een plaatje elkaar tegen.

Volgens de tabel zijn
pin 4+5 ( blauw / blauw-wit) +5V
pin 7+8 (bruin-wit / bruin) de GND.

Volgens het plaatje is het precies andersom.
[Afbeelding]

Zie ook mijn post van 3 dagen terug.

Voor een netwerkkabel volgens T-568B standaard:

RS485 A : Oranje-wit
+ 5V : Blauw en/of Blauw-wit
- GND : Bruin en/of Bruin-Wit
RS485 B : Oranje

Als je de 5V en GND verkeerdom aansluit, dan start de Lilygo niet op; ik weet niet wat de Elfin doet. Als je de RS485 A en B omwisselt krijg je in de log foutmeldingen als deze:

22:13:25 [D] [modbus_controller:039] Modbus command to device=1 register=0x8D04 no response received - removed from send queue

Oh, en je hebt software versie 139 nodig op de V3, anders leest hij maar enkele parameters uit.

[Ies Korpershoek]

Deze is wel interessant. Ben op 1 sept jl met vakantie gegaan en afgelopen weekend teruggekomen. Ik heb een Martek Venus 2, met Lilo RS485. Gedurende mijn vakantie was de batterij aangesloten. Besturing op manueel zonder taken in de vakantie. Bij vertrek was de SOC 69%, Bij terugkomst 40%. Het eigen(intern) gebruik is aanzienlijk lijkt mij of zie ik dit verkeerd.?

[wrak]

Ies Korpershoek schreef op vrijdag 10 oktober 2025 @ 09:16:
Deze is wel interessant. Ben op 1 sept jl met vakantie gegaan en afgelopen weekend teruggekomen. Ik heb een Martek Venus 2, met Lilo RS485. Gedurende mijn vakantie was de batterij aangesloten. Besturing op manueel zonder taken in de vakantie. Bij vertrek was de SOC 69%, Bij terugkomst 40%. Het eigen(intern) gebruik is aanzienlijk lijkt mij of zie ik dit verkeerd.?

[Afbeelding]

1.6 watt lijkt me heel redelijk.

[pascallj]

Ies Korpershoek schreef op vrijdag 10 oktober 2025 @ 09:16:
Deze is wel interessant. Ben op 1 sept jl met vakantie gegaan en afgelopen weekend teruggekomen. Ik heb een Martek Venus 2, met Lilo RS485. Gedurende mijn vakantie was de batterij aangesloten. Besturing op manueel zonder taken in de vakantie. Bij vertrek was de SOC 69%, Bij terugkomst 40%. Het eigen(intern) gebruik is aanzienlijk lijkt mij of zie ik dit verkeerd.?

[Afbeelding]

Ik heb laatst het stand-by verbruik geprobeerd te beredeneren: zonder back-up stopcontact aan hebben we het over ongeveer 3 Watt en met stopcontact aan nog over 7-8 Watt extra.

Normaal mag je eigenlijk niet rekenen met de SoC indicator, want die is incorrect en gaat ook wijken over tijd. Het is slechts een indicatie.

Maar stel dat we het toch doen om een grove indicatie te krijgen: 29 procent van 5,12 kWh is 1500 Wh. Met een stand-by verbruik van 3 W is dat dus 500 uur. Delen door 24 uur per dag, zit je op 21 dagen.

Dus voor een vakantie van meer dan een maand is dit helemaal niet onredelijk. Sterker nog, ik denk dat je werkelijke capaciteit nog veel lager zit, probeer hem maar eens leeg te trekken. Voortaan kan je beter de batterij helemaal uitzetten als je zo lang van huis gaat en stroom wil besparen.

Sommigen hier voeden ook hun Modbus apparaat vanuit de Modbus aansluiting van de batterij: dat gebruikt ook allemaal stroom.

Overigens kan je dit voortaan ook beter plaatsen in het 'hoofdtopic'. Je zit nu speciaal in het Modbus topic, maar dit heeft niet zo veel met Modbus te maken.

[Ies Korpershoek]

pascallj schreef op vrijdag 10 oktober 2025 @ 09:26:
[...]


Ik heb laatst het stand-by verbruik geprobeerd te beredeneren: zonder back-up stopcontact aan hebben we het over ongeveer 3 Watt en met stopcontact aan nog over 7-8 Watt extra.

Normaal mag je eigenlijk niet rekenen met de SoC indicator, want die is incorrect en gaat ook wijken over tijd. Het is slechts een indicatie.

Maar stel dat we het toch doen om een grove indicatie te krijgen: 29 procent van 5,12 kWh is 1500 Wh. Met een stand-by verbruik van 3 W is dat dus 500 uur. Delen door 24 uur per dag, zit je op 21 dagen.

Dus voor een vakantie van meer dan een maand is dit helemaal niet onredelijk. Sterker nog, ik denk dat je werkelijke capaciteit nog veel lager zit, probeer hem maar eens leeg te trekken. Voortaan kan je beter de batterij helemaal uitzetten als je zo lang van huis gaat en stroom wil besparen.

Sommigen hier voeden ook hun Modbus apparaat vanuit de Modbus aansluiting van de batterij: dat gebruikt ook allemaal stroom.

Overigens kan je dit voortaan ook beter plaatsen in het 'hoofdtopic'. Je zit nu speciaal in het Modbus topic, maar dit heeft niet zo veel met Modbus te maken.

Super bedankt, De modbus (LiLO) krijgt zijn voeding inderdaad ook uit de Venus.
Backup uitgang stond/staat uit.
Sorry voor het plaatsen in het verkeerde topic onderdeel.

[sponsjeee]

Ik heb 2x LILYGO® TTGO T-CAN485 ESP32 Kan RS-485 omdat ik ook 2 accu's heb.
Eén van de twee doet om de zoveel uur spontaan een reboot.

Beide draaien op hetzelfde bestand: lilygo-rs485-2.yaml
Hebben wel aparte namen etc, het werkt ook goed behalve de reboots om de x uur die 1 bordje uitvoert.
Best irritant, heb er al een losse voeding op aangesloten en opnieuw geflashed, maar het probleem blijft.

Ik weet niet goed hoe ik dit moet troubleshooten. Enige tips? Zijn er ergens logbestanden terug te vinden?

De andere blijft gewoon stabiel draaien.

[WargamingPlayer]

pascallj schreef op vrijdag 10 oktober 2025 @ 09:26:
[...]


Ik heb laatst het stand-by verbruik geprobeerd te beredeneren: zonder back-up stopcontact aan hebben we het over ongeveer 3 Watt en met stopcontact aan nog over 7-8 Watt extra.

Normaal mag je eigenlijk niet rekenen met de SoC indicator, want die is incorrect en gaat ook wijken over tijd. Het is slechts een indicatie.

Maar stel dat we het toch doen om een grove indicatie te krijgen: 29 procent van 5,12 kWh is 1500 Wh. Met een stand-by verbruik van 3 W is dat dus 500 uur. Delen door 24 uur per dag, zit je op 21 dagen.

Dus voor een vakantie van meer dan een maand is dit helemaal niet onredelijk. Sterker nog, ik denk dat je werkelijke capaciteit nog veel lager zit, probeer hem maar eens leeg te trekken. Voortaan kan je beter de batterij helemaal uitzetten als je zo lang van huis gaat en stroom wil besparen.

Sommigen hier voeden ook hun Modbus apparaat vanuit de Modbus aansluiting van de batterij: dat gebruikt ook allemaal stroom.

Overigens kan je dit voortaan ook beter plaatsen in het 'hoofdtopic'. Je zit nu speciaal in het Modbus topic, maar dit heeft niet zo veel met Modbus te maken.

Ik kwam uit tussen 7 en de 8 Watt. Wanneer ik mijn Elfin er af haal, maakt dat niks uit, het fluctueert tussen de 7 en 8 Watt. Ik heb 1 van de Accu's een 12 uur op 11% gehad zonder aansluiting en na 12 uur stond hij nog gewoon op 11%, eigenlijk verbruikt de Venus dus minder dan mijn WiFi.

Ik heb waarden van 50W gezien hier in het topic, maar waar dat vandaan komt weet ik niet, omdat de praktijk namelijk iets anders zegt.

[superduper1969]

Ies Korpershoek schreef op vrijdag 10 oktober 2025 @ 09:16:
Deze is wel interessant. Ben op 1 sept jl met vakantie gegaan en afgelopen weekend teruggekomen. Ik heb een Martek Venus 2, met Lilo RS485. Gedurende mijn vakantie was de batterij aangesloten. Besturing op manueel zonder taken in de vakantie. Bij vertrek was de SOC 69%, Bij terugkomst 40%. Het eigen(intern) gebruik is aanzienlijk lijkt mij of zie ik dit verkeerd.?

[Afbeelding]

Volgende keer op vakentie test herhalen zonder de Modbus aangesloten.
Dat zal vermoedelijk veel schelen.
De ingebouwde computer wordt nu de hele tijd ingezet om modbusverkeer te coordineren.
Het is ook bekend dat de MT zonder modbus verkeer in een slaapstand gaat als er geen klokprogramma draait en dat zal inderdaad zuiniger zijn.

[superduper1969]

sponsjeee schreef op vrijdag 10 oktober 2025 @ 09:41:
Ik heb 2x LILYGO® TTGO T-CAN485 ESP32 Kan RS-485 omdat ik ook 2 accu's heb.
Eén van de twee doet om de zoveel uur spontaan een reboot.

Beide draaien op hetzelfde bestand: lilygo-rs485-2.yaml
Hebben wel aparte namen etc, het werkt ook goed behalve de reboots om de x uur die 1 bordje uitvoert.
Best irritant, heb er al een losse voeding op aangesloten en opnieuw geflashed, maar het probleem blijft.

Ik weet niet goed hoe ik dit moet troubleshooten. Enige tips? Zijn er ergens logbestanden terug te vinden?

De andere blijft gewoon stabiel draaien.

De 2 in lilygo-rs485-2.yaml is niet vernoemd naar de V2 maar gewoon voor de 2e accu (V1/V2/V3)
Accu 1 = lilygo-rs485.yaml deze heeft geen nummer in de naam want in December 2024 was ik daar nog helemaal niet mee bezig.

Als je zelf namen hebt aangepast kan ik niet garanderen dat je ze allemaal correct hebt aangepast.
En ik heb recent nog wat updates gedaan met snellere code en snellere kloksnelheid, dus misschien moet je gewoon de laatste en juiste code gebruiken.

[pascallj]

WargamingPlayer schreef op vrijdag 10 oktober 2025 @ 10:49:
[...]

Ik kwam uit tussen 7 en de 8 Watt. Wanneer ik mijn Elfin er af haal, maakt dat niks uit, het fluctueert tussen de 7 en 8 Watt. Ik heb 1 van de Accu's een 12 uur op 11% gehad zonder aansluiting en na 12 uur stond hij nog gewoon op 11%, eigenlijk verbruikt de Venus dus minder dan mijn WiFi.

Ik heb waarden van 50W gezien hier in het topic, maar waar dat vandaan komt weet ik niet, omdat de praktijk namelijk iets anders zegt.

Dat is dan dus met stopcontact aan? Ow jij hebt het zeker over het verbruik uit het net? Dat is inderdaad 7 Watt, maar dat is wat anders. We hebben het hier over het verbruik uit de batterij zelf en niet uit het net. Die 7 Watt uit het net komt er nog eens bovenop.

Die 40/50 W heb ik denk ik de wereld in geslingerd omdat dat is wat je via Modbus uitleest wat er uit de batterij komt. Aangezien de rest van de Modbus accuraat is, was ik daar hier ook van uit gegaan. Maar goed meten is weten en dat bleek dus niet waar.

[ Voor 12% gewijzigd door pascallj op 10-10-2025 14:00 ]

[pascallj]

superduper1969 schreef op vrijdag 10 oktober 2025 @ 13:43:
[...]

Volgende keer op vakentie test herhalen zonder de Modbus aangesloten.
Dat zal vermoedelijk veel schelen.
De ingebouwde computer wordt nu de hele tijd ingezet om modbusverkeer te coordineren.
Het is ook bekend dat de MT zonder modbus verkeer in een slaapstand gaat als er geen klokprogramma draait en dat zal inderdaad zuiniger zijn.

Dat laatste is een vermoeden maar nog nooit echt bewezen volgens mij. Je kunt namelijk geen data meer zien dus je kan het niet weten. Lijkt mij ook sterk dat hij in een slaapstand gaat als WiFi en BT nog wel actief is.

We weten wel dat als het backup-stopcontact uit staat en de stroom valt weg, dat hij na een uur vanzelf uitgaat (zonder Modbus). Dat is laatst door iemand getest.

[WargamingPlayer]

pascallj schreef op vrijdag 10 oktober 2025 @ 13:58:
[...]


Dat laatste is een vermoeden maar nog nooit echt bewezen volgens mij. Je kunt namelijk geen data meer zien dus je kan het niet weten. Lijkt mij ook sterk dat hij in een slaapstand gaat als WiFi en BT nog wel actief is.

We weten wel dat als het backup-stopcontact uit staat en de stroom valt weg, dat hij na een uur vanzelf uitgaat (zonder Modbus). Dat is laatst door iemand getest.

Wat wel mee speelt is dat een aangesloten Modbus er voor zorgt dat de Venus niet in Deep Sleep gaat bij Standby, als die modus al bestaat. Misschien kan dat wel in verbruik schelen. Ik heb nu bij Marstek het volgende neergelegd:

1. Powerdraw from Grid and Battery when Battery is connected to Grid and Battery in Stand-by?
2. Powerdraw from Battery when Grid is not connected and Battery in Stand-by?
3. Powerdraw from Grid and Battery when Battery is connected to Grid and Battery is Off?
4. Powerdraw from Battery when Grid is not connected and Battery is Off?
5. All above with Modubus port is used.

[Kenhas]

@WargamingPlayer spreken de woorden Deep Sleep en Standby mekaar niet beetje tegen ?

[sponsjeee]

superduper1969 schreef op vrijdag 10 oktober 2025 @ 13:49:
[...]

De 2 in lilygo-rs485-2.yaml is niet vernoemd naar de V2 maar gewoon voor de 2e accu (V1/V2/V3)
Accu 1 = lilygo-rs485.yaml deze heeft geen nummer in de naam want in December 2024 was ik daar nog helemaal niet mee bezig.

Als je zelf namen hebt aangepast kan ik niet garanderen dat je ze allemaal correct hebt aangepast.
En ik heb recent nog wat updates gedaan met snellere code en snellere kloksnelheid, dus misschien moet je gewoon de laatste en juiste code gebruiken.

Duidelijk!

Ik heb ze nu alle 2 opnieuw geflashed.
1 met lilygo-rs485.yaml & de ander met lilygo-rs485-2.yaml. Inhoudelijk niks anders dan api, ota en wifi gegevens aangepast.

Even aankijken of het dat is, bedankt voor de reactie!


*edit

Beide zijn nu 17+ uur online, daarmee is het probleem opgelost. Bedankt!

[ Voor 4% gewijzigd door sponsjeee op 11-10-2025 10:25 ]

[dbra]

sponsjeee schreef op vrijdag 10 oktober 2025 @ 09:41:
Ik heb 2x LILYGO® TTGO T-CAN485 ESP32 Kan RS-485 omdat ik ook 2 accu's heb.
Eén van de twee doet om de zoveel uur spontaan een reboot.

Beide draaien op hetzelfde bestand: lilygo-rs485-2.yaml
Hebben wel aparte namen etc, het werkt ook goed behalve de reboots om de x uur die 1 bordje uitvoert.
Best irritant, heb er al een losse voeding op aangesloten en opnieuw geflashed, maar het probleem blijft.

Ik weet niet goed hoe ik dit moet troubleshooten. Enige tips? Zijn er ergens logbestanden terug te vinden?

De andere blijft gewoon stabiel draaien.

Er is een entity Reset Reason. Heb je daar al naar gekeken?

[LodeBo]

dannyro schreef op donderdag 9 oktober 2025 @ 11:29:
[...]

En bij "uitgeschakeld" wordt dat bolletje rood. Speelgoed hé

[Afbeelding]

Uit welke sensor haal je dat ?
“CT Connection abnormal” ?

Ben bezig met de de kaart aan te passen. Wifi zit er al in. Mss CT ook toevoegen?

[pascallj]

LodeBo schreef op zondag 12 oktober 2025 @ 10:55:
[...]


Uit welke sensor haal je dat ?
“CT Connection abnormal” ?

Ben bezig met de de kaart aan te passen. Wifi zit er al in. Mss CT ook toevoegen?

[Afbeelding]

Die data komt blijkbaar uit hm2mqtt. De CT Connection Abnormal uit de Modbus werkt voor zover ik heb kunnen testen niet.

[Ies Korpershoek]

Hier een vraag van een beginner. Heb de Marstek venus 2. Ik gebruik een LiliyGo voor een koppeling met Home Assistant. Ik zie alle waarden. NU mijn vraag. Alles staat nog in test, na het aansluiten van de LilyGo heb ik, tot gisteren, weinig/niet met de batterij geëxperimenteerd. Via de app heb is gisteren, in de 'manual' een laad sessie in gepland. Maar er gebeurde niets. Batterij uitgeschakeld, stekker eruit en de RS485 losgemaakt. Daarna weer alles aan. Nieuwe laadsessie gepland via de 'manual' optie en alles werkte zoals verwacht. Mag ik hieruit afleiden dat als de RS485 is aangesloten de App instellingen niet meer werken en ik dit via RS485 moet plannen ?

[dannyro]

LodeBo schreef op zondag 12 oktober 2025 @ 10:55:
[...]


Uit welke sensor haal je dat ?
“CT Connection abnormal” ?

Ben bezig met de de kaart aan te passen. Wifi zit er al in. Mss CT ook toevoegen?

[Afbeelding]

Ik haal deze uit de Hame Relay. "CT Status". Ik had deze ook graag in de modbus uitlezing gekregen, maar dat is precies niet mogelijk. Gewoon omdat Modbus uitlezing betrouwbaarder is nav eventuele FW updates.

[superduper1969]

Ies Korpershoek schreef op zondag 12 oktober 2025 @ 11:19:
Hier een vraag van een beginner. Heb de Marstek venus 2. Ik gebruik een LiliyGo voor een koppeling met Home Assistant. Ik zie alle waarden. NU mijn vraag. Alles staat nog in test, na het aansluiten van de LilyGo heb ik, tot gisteren, weinig/niet met de batterij geëxperimenteerd. Via de app heb is gisteren, in de 'manual' een laad sessie in gepland. Maar er gebeurde niets. Batterij uitgeschakeld, stekker eruit en de RS485 losgemaakt. Daarna weer alles aan. Nieuwe laadsessie gepland via de 'manual' optie en alles werkte zoals verwacht. Mag ik hieruit afleiden dat als de RS485 is aangesloten de App instellingen niet meer werken en ik dit via RS485 moet plannen ?

Nee, hij doet exact wat je hebt ingesteld. Voor uitleg van de instellingen en de relatie tussen de instellingen kijk je in de startpost. Waarschijnlijk heb je RS485 Control aan staan dan wordt de app genegeerd.

[Chris96]

Is er veel veranderd sinds 3 week geleden?
Ik probeerde vanmiddag de laatste versie van het script erop te zetten en die gaf vrij vlot al een foutmelding:
Iemand enig idee waar het fout gaat?

code:

INFO Package configuration completed successfully
INFO Package configuration completed successfully
HARDWARE: ESP32 240MHz, 320KB RAM, 4MB Flash
 - framework-espidf @ 3.50402.0 (5.4.2) 
 - tool-cmake @ 3.30.2 
 - tool-esp-rom-elfs @ 2024.10.11 
 - tool-esptoolpy @ 5.0.2 
 - tool-mklittlefs @ 3.2.0 
 - tool-ninja @ 1.13.1 
 - tool-scons @ 4.40801.0 (4.8.1) 
 - toolchain-xtensa-esp-elf @ 14.2.0+20241119
Reading CMake configuration...
-- git rev-parse returned 'fatal: not a git repository (or any parent up to mount point /)
Stopping at filesystem boundary (GIT_DISCOVERY_ACROSS_FILESYSTEM not set).'
-- Building ESP-IDF components for target esp32
-- Configuring incomplete, errors occurred!

fatal: not a git repository (or any parent up to mount point /)
Stopping at filesystem boundary (GIT_DISCOVERY_ACROSS_FILESYSTEM not set).
CMake Error at /data/cache/platformio/packages/framework-espidf/tools/cmake/build.cmake:620 (message):
  Traceback (most recent call last):

    File "<frozen runpy>", line 189, in _run_module_as_main
    File "<frozen runpy>", line 112, in _get_module_details
    File "/root/.platformio/penv/.espidf-5.4.2/lib/python3.12/site-packages/idf_component_manager/__init__.py", line 6, in <module>
      from idf_component_tools.environment import ComponentManagerSettings
    File "/root/.platformio/penv/.espidf-5.4.2/lib/python3.12/site-packages/idf_component_tools/__init__.py", line 9, in <module>
      if ComponentManagerSettings().DEBUG_MODE:
         ^^^^^^^^^^^^^^^^^^^^^^^^^^
    File "/root/.platformio/penv/.espidf-5.4.2/lib/python3.12/site-packages/pydantic_settings/main.py", line 193, in __init__
      super().__init__(
    File "/root/.platformio/penv/.espidf-5.4.2/lib/python3.12/site-packages/pydantic/main.py", line 250, in __init__
      validated_self = self.__pydantic_validator__.validate_python(data, self_instance=self)
                       ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
    File "/root/.platformio/penv/.espidf-5.4.2/lib/python3.12/site-packages/idf_component_tools/environment.py", line 148, in fallback_to_default
      if field.validation_alias:
         ^^^^^^^^^^^^^^^^^^^^^^

  AttributeError: 'NoneType' object has no attribute 'validation_alias'

Call Stack (most recent call first):
  /data/cache/platformio/packages/framework-espidf/tools/cmake/project.cmake:718 (idf_build_process)
  CMakeLists.txt:3 (project)

[AUijtdehaag]

@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

[ Voor 58% gewijzigd door AUijtdehaag op 12-10-2025 16:22 ]

[pascallj]

Chris96 schreef op zondag 12 oktober 2025 @ 15:57:
Is er veel veranderd sinds 3 week geleden?
Ik probeerde vanmiddag de laatste versie van het script erop te zetten en die gaf vrij vlot al een foutmelding:
Iemand enig idee waar het fout gaat?

code:

INFO Package configuration completed successfully
INFO Package configuration completed successfully
HARDWARE: ESP32 240MHz, 320KB RAM, 4MB Flash
 - framework-espidf @ 3.50402.0 (5.4.2) 
 - tool-cmake @ 3.30.2 
 - tool-esp-rom-elfs @ 2024.10.11 
 - tool-esptoolpy @ 5.0.2 
 - tool-mklittlefs @ 3.2.0 
 - tool-ninja @ 1.13.1 
 - tool-scons @ 4.40801.0 (4.8.1) 
 - toolchain-xtensa-esp-elf @ 14.2.0+20241119
Reading CMake configuration...
-- git rev-parse returned 'fatal: not a git repository (or any parent up to mount point /)
Stopping at filesystem boundary (GIT_DISCOVERY_ACROSS_FILESYSTEM not set).'
-- Building ESP-IDF components for target esp32
-- Configuring incomplete, errors occurred!

fatal: not a git repository (or any parent up to mount point /)
Stopping at filesystem boundary (GIT_DISCOVERY_ACROSS_FILESYSTEM not set).
CMake Error at /data/cache/platformio/packages/framework-espidf/tools/cmake/build.cmake:620 (message):
  Traceback (most recent call last):

    File "<frozen runpy>", line 189, in _run_module_as_main
    File "<frozen runpy>", line 112, in _get_module_details
    File "/root/.platformio/penv/.espidf-5.4.2/lib/python3.12/site-packages/idf_component_manager/__init__.py", line 6, in <module>
      from idf_component_tools.environment import ComponentManagerSettings
    File "/root/.platformio/penv/.espidf-5.4.2/lib/python3.12/site-packages/idf_component_tools/__init__.py", line 9, in <module>
      if ComponentManagerSettings().DEBUG_MODE:
         ^^^^^^^^^^^^^^^^^^^^^^^^^^
    File "/root/.platformio/penv/.espidf-5.4.2/lib/python3.12/site-packages/pydantic_settings/main.py", line 193, in __init__
      super().__init__(
    File "/root/.platformio/penv/.espidf-5.4.2/lib/python3.12/site-packages/pydantic/main.py", line 250, in __init__
      validated_self = self.__pydantic_validator__.validate_python(data, self_instance=self)
                       ^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^^
    File "/root/.platformio/penv/.espidf-5.4.2/lib/python3.12/site-packages/idf_component_tools/environment.py", line 148, in fallback_to_default
      if field.validation_alias:
         ^^^^^^^^^^^^^^^^^^^^^^

  AttributeError: 'NoneType' object has no attribute 'validation_alias'

Call Stack (most recent call first):
  /data/cache/platformio/packages/framework-espidf/tools/cmake/project.cmake:718 (idf_build_process)
  CMakeLists.txt:3 (project)

Zie: https://github.com/esphome/esphome/issues/11162

Oftewel als je handmatig werkt: .platformio map verwijderen en anders de addon verwijderen inclusief data.

[Ies Korpershoek]

superduper1969 schreef op zondag 12 oktober 2025 @ 15:06:
[...]

Nee, hij doet exact wat je hebt ingesteld. Voor uitleg van de instellingen en de relatie tussen de instellingen kijk je in de startpost. Waarschijnlijk heb je RS485 Control aan staan dan wordt de app genegeerd.

Bedankt

Volgens de info uit de Liligo in Home Assistant staat RS485 disabled
Ik ga kijken of ik dat ergens kan controleren
Zal zeker de startpost doornemen

[Chris96]

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

Ik heb de Beta versie ook geprobeerd, Het lijkt er niet op dat het voorlopig gefixed gaat zijn.
Terug naar 2025.8 lijkt het probleem inderdaad te verhelpen gek genoeg.

[pascallj]

Chris96 schreef op zondag 12 oktober 2025 @ 20:51:
[...]


Ik heb de Beta versie ook geprobeerd, Het lijkt er niet op dat het voorlopig gefixed gaat zijn.
Terug naar 2025.8 lijkt het probleem inderdaad te verhelpen gek genoeg.

Zie mijn post

[sponsjeee]

Heeft iemand in HA iets moois weten te maken mbt een automation voor laden op goedkope momenten met dynamische tarieven (ANWB)?
Ben aan het prutsen geweest maar krijg niks stabiels eruit.

Laden op goedkoopste momenten van de dag tot vol (gespreid of in één keer?) op basis van dynamische tarieven.
Na laden weer op zelfverbruik.

Eigenlijk wat de AI doet, maar die werkt nu dus niet.

Heeft iemand dit in HA gemaakt? en hoe ziet die YAML er dan uit?

[GoBieN-Be]

pascallj schreef op woensdag 8 oktober 2025 @ 12:41:
[...]

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.

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.

[ Voor 29% gewijzigd door GoBieN-Be op 13-10-2025 00:30 . Reden: het is al laat ... ]

[Chris96]

sponsjeee schreef op zondag 12 oktober 2025 @ 22:00:
Heeft iemand in HA iets moois weten te maken mbt een automation voor laden op goedkope momenten met dynamische tarieven (ANWB)?
Ben aan het prutsen geweest maar krijg niks stabiels eruit.

Laden op goedkoopste momenten van de dag tot vol (gespreid of in één keer?) op basis van dynamische tarieven.
Na laden weer op zelfverbruik.

Eigenlijk wat de AI doet, maar die werkt nu dus niet.

Heeft iemand dit in HA gemaakt? en hoe ziet die YAML er dan uit?

Ik heb iets wat voor 90% van de gevallen werkt, soms moet ik manueel nog wat aanpassen.
En dat doe ik met onderstaande script. Als je het geheel wil kan ook maar dan moet je meer aanmaken.

Voor als de prijs bijna op het laagste punt is:

code:

condition: template
value_template: >-
  {% set high = states('sensor.epex_spot_data_highest_price') | replace(',',
  '.') | float(none) %}

  {% set low  = states('sensor.epex_spot_data_lowest_price')  | replace(',',
  '.') | float(none) %}

  {% set cur  = states('sensor.epex_spot_data_price')         | replace(',',
  '.') | float(none) %}

  {% if high is number and low is number and cur is number and high > low %}
    {% set grens = low + (high - low) * 0.15 %}
    {{ cur <= grens }}
  {% else %}
    false
  {% endif %}

Voor als de prijs zich boven het dag gemiddelde uit beweegt, Batterij naar nul op de meter

code:

{% set high = states('sensor.epex_spot_data_highest_price') | replace(',', '.') | float(none) %}
{% set cur  = states('sensor.epex_spot_data_price')         | replace(',', '.') | float(none) %}
{% if high is number and cur is number and high > 0 %}
  {{ cur >= high * 0.5 }}
{% else %}
  false
{% endif %}

[Kammika]

Chris96 schreef op maandag 13 oktober 2025 @ 08:11:
[...]


Ik heb iets wat voor 90% van de gevallen werkt, soms moet ik manueel nog wat aanpassen.
En dat doe ik met onderstaande script. Als je het geheel wil kan ook maar dan moet je meer aanmaken.

Voor als de prijs bijna op het laagste punt is:

code:

condition: template
value_template: >-
  {% set high = states('sensor.epex_spot_data_highest_price') | replace(',',
  '.') | float(none) %}

  {% set low  = states('sensor.epex_spot_data_lowest_price')  | replace(',',
  '.') | float(none) %}

  {% set cur  = states('sensor.epex_spot_data_price')         | replace(',',
  '.') | float(none) %}

  {% if high is number and low is number and cur is number and high > low %}
    {% set grens = low + (high - low) * 0.15 %}
    {{ cur <= grens }}
  {% else %}
    false
  {% endif %}

Voor als de prijs zich boven het dag gemiddelde uit beweegt, Batterij naar nul op de meter

code:

{% set high = states('sensor.epex_spot_data_highest_price') | replace(',', '.') | float(none) %}
{% set cur  = states('sensor.epex_spot_data_price')         | replace(',', '.') | float(none) %}
{% if high is number and cur is number and high > 0 %}
  {{ cur >= high * 0.5 }}
{% else %}
  false
{% endif %}

Ziet er goed uit.. op welke manier haal je de epex data op? Ik heb zelf nu zelf de HACS entso-e integratie. Maar die werkt nog met uurprijzen. Zoek nog iets wat kwartierprijzen binnenhaalt in HA

[Chris96]

Kammika schreef op maandag 13 oktober 2025 @ 08:35:
[...]

Ziet er goed uit.. op welke manier haal je de epex data op? Ik heb zelf nu zelf de HACS entso-e integratie. Maar die werkt nog met uurprijzen. Zoek nog iets wat kwartierprijzen binnenhaalt in HA

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.

Ik heb 2 werk modi: Solar en EPEX. (en Off)

Op Solar gaat de batterij standby totdat 1500w PV bereikt is, Werkt het beste in de zomer maanden.
Op EPEX blijft de batterij op nul op de meter tenzij de prijs lager dan de laagste 15% van de dag is. Dan gaat hij automatisch met 2500 laden. Is het een kwartier later hoger dan 50% van de dagprijs dan gaat hij terug naar nul op de meter.

Onze elektrische boiler werkt volgens identiek protocol. Je zou redelijk wat aan en uit schommelingen verwachten maar dat valt tot nu toe reuze mee.

[denbeire]

Hallo,

Ik ben bezig met de integratie van mijn Marstek Venus E Gen 3.0 (V3) thuisbatterij in Home Assistant via een Elfin-EW11A Modbus TCP-converter en loop vast op de onbekende registeradressen.

De communicatie werkt perfect (ik krijg antwoord van de batterij), maar ik krijg consequent foutcodes, wat erop wijst dat de V3-registers compleet anders zijn dan de bekende V2-lijsten.

Kan iemand met een werkende Modbus-integratie voor de V3-versie bevestigen welke Holding Register-adressen (Function Code 03) moeten worden gebruikt voor de State of Charge (SOC) en Power?
Kortom, de communicatie is correct, maar de gehele Modbus-tabel is onbekend en wijkt af van alles wat logisch of bekend is.

Als iemand de werkende adressen voor de V3 (Holding Registers) kent, zou dit enorm helpen!

Alvast bedankt voor de hulp!

[pascallj]

denbeire schreef op maandag 13 oktober 2025 @ 16:30:
Hallo,

Ik ben bezig met de integratie van mijn Marstek Venus E Gen 3.0 (V3) thuisbatterij in Home Assistant via een Elfin-EW11A Modbus TCP-converter en loop vast op de onbekende registeradressen.

De communicatie werkt perfect (ik krijg antwoord van de batterij), maar ik krijg consequent foutcodes, wat erop wijst dat de V3-registers compleet anders zijn dan de bekende V2-lijsten.

Kan iemand met een werkende Modbus-integratie voor de V3-versie bevestigen welke Holding Register-adressen (Function Code 03) moeten worden gebruikt voor de State of Charge (SOC) en Power?
Kortom, de communicatie is correct, maar de gehele Modbus-tabel is onbekend en wijkt af van alles wat logisch of bekend is.

Als iemand de werkende adressen voor de V3 (Holding Registers) kent, zou dit enorm helpen!

Alvast bedankt voor de hulp!

Heb je al firmware v139 aangevraagd? Daarin zijn een hoop Modbus codes toegevoegd/gelijkgetrokken met de eerdere versies. Schijnt dat nog niet iedereen deze versie automatisch krijgt, maar we hebben wel al gelezen dat er veel registers werken met configuraties die gemaakt zijn voor de V2 of eerder.

[MoreJ]

Chris96 schreef op maandag 13 oktober 2025 @ 08:11:
[...]


Ik heb iets wat voor 90% van de gevallen werkt, soms moet ik manueel nog wat aanpassen.
En dat doe ik met onderstaande script. Als je het geheel wil kan ook maar dan moet je meer aanmaken.

Voor als de prijs bijna op het laagste punt is:

code:

condition: template
value_template: >-
  {% set high = states('sensor.epex_spot_data_highest_price') | replace(',',
  '.') | float(none) %}

Dit is interessant, hier was ik ook al naar aan het kijken. Ik laat de Marstek nu tussen manual en AI schakelen in de hoop dat AI op de juiste momenten gaat laden. Maar hiermee kun je zelf volledig de regie nemen.
Om dit werkend te krijgen moet ik de Venus 2 wel geforceerd kunnen laten laden.
Ik gebruik deze integratie: https://github.com/viperrnmc/marstek_venus_modbus en draai op firmware V1.53
Maar de Force Charge commando's zijn niet beschikbaar. Weet iemand of dit aan de firmware ligt?

Verder stond de Venus vanmiddag in storing, rood lampje op het display. Hoe kun je achterhalen wat de storing heeft veroorzaakt?

[denbeire]

pascallj schreef op maandag 13 oktober 2025 @ 16:32:
[...]


Heb je al firmware v139 aangevraagd? Daarin zijn een hoop Modbus codes toegevoegd/gelijkgetrokken met de eerdere versies. Schijnt dat nog niet iedereen deze versie automatisch krijgt, maar we hebben wel al gelezen dat er veel registers werken met configuraties die gemaakt zijn voor de V2 of eerder.

En hoe vraag je deze dan aan? of is het afwachten hiervoor?

[pascallj]

denbeire schreef op maandag 13 oktober 2025 @ 17:12:
[...]

En hoe vraag je deze dan aan? of is het afwachten hiervoor?

Via Feedback kan je een berichtje sturen. Dan kan je vragen om firmware versie v139. Je kunt in het instellingen menu zien op welke je nu zit. Ik verwacht dan v114 net als veel anderen hier.

[denbeire]

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


Via Feedback kan je een berichtje sturen. Dan kan je vragen om firmware versie v139. Je kunt in het instellingen menu zien op welke je nu zit. Ik verwacht dan v114 net als veel anderen hier.

idd, versie 114. Ik vraag de update meteen aan, bedankt

[comfix]

Heb volgende gekocht: https://www.waveshare.com/wiki/RS485_TO_POE_ETH_(B)#FAQ
Enkel krijg ik totaal geen info binnen op HA. Ook een modpoll test krijg ik een timeout.
Ik heb de orange en oranje/wit beiden getest en gewisseld, helaas geen input in HA.

De batt zit op v122 en ik heb support gevraagd om een update te sturen, geen idee hoe snel ze reageren.
Maar er zouden toch een aantal registers beschikbaar moeten zijn die ik kan testen?

[LodeBo]

Ik zag net dat 1 batterij was ontladen tot 1% ???
Nu is hij terug aan het bijladen.
Heeft dat nog al iemand voor gehad ?
Dat kan toch niet gezond zijn.

[pascallj]

LodeBo schreef op maandag 13 oktober 2025 @ 18:47:
Ik zag net dat 1 batterij was ontladen tot 1% ???
Nu is hij terug aan het bijladen.
Heeft dat nog al iemand voor gehad ?
Dat kan toch niet gezond zijn.

In het hoofdtopic hebben we het hier al vaker over gehad en heb ik er een test voor gedaan. Ik weet niet of mijn post het het beste beschrijft, maar wist ik wel makkelijk terug te vinden: pascallj in "Hame / Marstek / Duravolt 5,12kWh plug en play thuisaccu"

[pascallj]

comfix schreef op maandag 13 oktober 2025 @ 17:50:
Heb volgende gekocht: https://www.waveshare.com/wiki/RS485_TO_POE_ETH_(B)#FAQ
Enkel krijg ik totaal geen info binnen op HA. Ook een modpoll test krijg ik een timeout.
Ik heb de orange en oranje/wit beiden getest en gewisseld, helaas geen input in HA.

De batt zit op v122 en ik heb support gevraagd om een update te sturen, geen idee hoe snel ze reageren.
Maar er zouden toch een aantal registers beschikbaar moeten zijn die ik kan testen?

Hoe heb je het allemaal precies aangesloten? Krijg je überhaupt wel iets terug? Foutmelding oid? Weet je zeker dat de je de adapter etc goed hebt ingesteld en de verbinding daarmee goed is?

Volgens mij zijn dit de registers die zouden moeten werken met versies voor v139: https://github.com/ViperR...ek_modbus/registers_v3.py

Ik kan de tabel die hier gepost is met de vergelijking tussen v2 en v3 niet meer vinden.

Aah deze bedoelde ik: https://docs.google.com/s...pubhtml?gid=0&single=true

Volgens mij was deze tabel gemaakt nog voordat v139 beschikbaar was.

Zie ook: FirefoxNL in "Marstek Venus / Duravolt PnP Thuisaccu Modbus koppeling"

[ Voor 19% gewijzigd door pascallj op 13-10-2025 19:07 ]

[Chris96]

MoreJ schreef op maandag 13 oktober 2025 @ 16:49:
[...]


Dit is interessant, hier was ik ook al naar aan het kijken. Ik laat de Marstek nu tussen manual en AI schakelen in de hoop dat AI op de juiste momenten gaat laden. Maar hiermee kun je zelf volledig de regie nemen.
Om dit werkend te krijgen moet ik de Venus 2 wel geforceerd kunnen laten laden.
Ik gebruik deze integratie: https://github.com/viperrnmc/marstek_venus_modbus en draai op firmware V1.53
Maar de Force Charge commando's zijn niet beschikbaar. Weet iemand of dit aan de firmware ligt?

Verder stond de Venus vanmiddag in storing, rood lampje op het display. Hoe kun je achterhalen wat de storing heeft veroorzaakt?

Hierbij de volledige code voor homeassistant die ik gebruik voor de besturing.
Zelf gebruik ik de marstek app helemaal niet meer behalve voor firmware updates.

code:

alias: Battery Control
description: ""
triggers:
  - trigger: time_pattern
    enabled: true
    minutes: /5
  - trigger: state
    entity_id:
      - input_select.energy_control
    from: null
  - entity_id: sensor.epex_spot_data_price
    trigger: state
  - trigger: state
    entity_id:
      - sensor.lilygo_rs485_marstek_battery_state_of_charge
    from: null
  - trigger: numeric_state
    entity_id:
      - sensor.solar_power
    above: 1000
conditions:
  - condition: state
    entity_id: input_boolean.vakantie
    state: "off"
    for:
      hours: 0
      minutes: 5
      seconds: 0
actions:
  - alias: "Optie 1: Solar Charge (Solar)"
    if:
      - condition: state
        entity_id: input_select.energy_control
        state: Solar
      - condition: numeric_state
        entity_id: sensor.solar_power
        above: 1500
      - condition: not
        conditions:
          - condition: state
            entity_id: input_select.battery_mode
            state: Nul op de meter
    then:
      - target:
          entity_id: input_select.battery_mode
        data:
          option: Nul op de meter
        action: input_select.select_option
  - alias: "Optie 2: Low Price (Epex Price)"
    if:
      - condition: state
        entity_id: input_select.energy_control
        state: Epex Price
      - condition: state
        entity_id: sensor.epex_spot_data_price_trend
        state: Omlaag
      - alias: EPEX Price Check
        condition: or
        conditions:
          - condition: numeric_state
            entity_id: sensor.epex_spot_data_price
            below: 0.01
          - condition: template
            value_template: >-
              {% set high = states('sensor.epex_spot_data_highest_price') |
              replace(',', '.') | float(none) %}

              {% set low  = states('sensor.epex_spot_data_lowest_price')  |
              replace(',', '.') | float(none) %}

              {% set cur  = states('sensor.epex_spot_data_price')         |
              replace(',', '.') | float(none) %}

              {% if high is number and low is number and cur is number and high
              > low %}
                {% set grens = low + (high - low) * 0.10 %}
                {{ cur <= grens }}
              {% else %}
                false
              {% endif %}
      - condition: numeric_state
        entity_id: sensor.lilygo_rs485_marstek_battery_state_of_charge
        below: 95
    then:
      - target:
          entity_id:
            - input_select.battery_mode
        data:
          option: Volledig opladen
        action: input_select.select_option
    else:
      - alias: "Optie 2b: High Price -> Normal"
        if:
          - condition: state
            entity_id: input_select.energy_control
            state: Epex Price
          - condition: not
            conditions:
              - condition: state
                entity_id: input_select.battery_mode
                state: Nul op de meter
          - condition: template
            value_template: >-
              {% set high = states('sensor.epex_spot_data_highest_price') |
              replace(',', '.') | float(none) %}

              {% set cur  = states('sensor.epex_spot_data_price')         |
              replace(',', '.') | float(none) %}

              {% if high is number and cur is number and high > 0 %}
                {{ cur >= high * 0.5 }}
              {% else %}
                false
              {% endif %}
          - condition: numeric_state
            entity_id: sensor.epex_spot_data_net_price
            below: 0.5
        then:
          - target:
              entity_id:
                - input_select.battery_mode
            data:
              option: Nul op de meter
            action: input_select.select_option
      - alias: "Optie 2c: Extreme Price -> discharge"
        if:
          - condition: state
            entity_id: input_select.energy_control
            state: Epex Price
          - condition: not
            conditions:
              - condition: state
                entity_id: input_select.battery_mode
                state: Volledig ontladen
          - condition: numeric_state
            entity_id: sensor.epex_spot_data_net_price
            above: 0.5
          - condition: numeric_state
            entity_id: sensor.lilygo_rs485_marstek_battery_state_of_charge
            above: 75
        then:
          - target:
              entity_id: input_number.battery_override_power
            data:
              value: 2500
            action: input_number.set_value
          - target:
              entity_id:
                - input_select.battery_mode
            data:
              option: Volledig ontladen
            action: input_select.select_option
  - alias: "Optie 3: Full Battery "
    if:
      - condition: state
        entity_id: input_select.energy_control
        state: Epex Price
      - condition: numeric_state
        entity_id: sensor.lilygo_rs485_marstek_battery_state_of_charge
        above: 99
      - condition: not
        conditions:
          - condition: state
            entity_id: input_select.battery_mode
            state: Nul op de meter
    then:
      - target:
          entity_id:
            - input_select.battery_mode
        data:
          option: Nul op de meter
        action: input_select.select_option
mode: single

[comfix]

pascallj schreef op maandag 13 oktober 2025 @ 19:01:
[...]


Hoe heb je het allemaal precies aangesloten? Krijg je überhaupt wel iets terug? Foutmelding oid? Weet je zeker dat de je de adapter etc goed hebt ingesteld en de verbinding daarmee goed is?

Volgens mij zijn dit de registers die zouden moeten werken met versies voor v139: https://github.com/ViperR...ek_modbus/registers_v3.py

Ik kan de tabel die hier gepost is met de vergelijking tussen v2 en v3 niet meer vinden.

Aah deze bedoelde ik: https://docs.google.com/s...pubhtml?gid=0&single=true

Volgens mij was deze tabel gemaakt nog voordat v139 beschikbaar was.

Zie ook: FirefoxNL in "Marstek Venus / Duravolt PnP Thuisaccu Modbus koppeling"

Dit zijn de instelligen van de Waveshare:



Aansluiting is een RJ45 kabel die ik heb geknipt. Aangesloten:
- Oranje/wit: A+
- Oranje: B+
- Blauw: GND

A+ en B+ al gewisseld en beiden krijg ik niets binnen.

[LodeBo]

pascallj schreef op maandag 13 oktober 2025 @ 18:51:
[...]


In het hoofdtopic hebben we het hier al vaker over gehad en heb ik er een test voor gedaan. Ik weet niet of mijn post het het beste beschrijft, maar wist ik wel makkelijk terug te vinden: pascallj in "Hame / Marstek / Duravolt 5,12kWh plug en play thuisaccu"

Thx.
Ik heb eens even verder teruggekeken en zie dat dit op 7, 11 en 13 oktober gebeurd is.
Dat kan niet normaal zijn.
Heeft er iemand hier al melding van gemaakt bij Marstek ?

[pascallj]

comfix schreef op maandag 13 oktober 2025 @ 19:45:
[...]

Dit zijn de instelligen van de Waveshare:

[Afbeelding]

Aansluiting is een RJ45 kabel die ik heb geknipt. Aangesloten:
- Oranje/wit: A+
- Oranje: B+
- Blauw: GND

A+ en B+ al gewisseld en beiden krijg ik niets binnen.

Heb je toevallig een kabel gepakt die als T568A bedraad is? Dan is groen en groen-wit pin 1&2 en dus het Modbus paar. Ook is blauw + 5V dus die moet je niet als GND gebruiken. Als je die als Modbus GND gebruikt kan dat ook de reden zijn dat het niet werkt. Je hebt voor korte afstanden geen Modbus GND nodig, dus die kan je weglaten.

[pascallj]

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

Thx.
Ik heb eens even verder teruggekeken en zie dat dit op 7, 11 en 13 oktober gebeurd is.
Dat kan niet normaal zijn.
Heeft er iemand hier al melding van gemaakt bij Marstek ?

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.

[bpssoftware]

Zojuist ook twee Marstek Venus E 3.0 ontvangen. Het is mij ook nog niet gelukt om RS485 werkend te krijgen, heb zelf kabels gemaakt op basis van de pinout. Ik heb een bericht gestuurd voor andere firmware, hopelijk is dat het probleem

[pascallj]

bpssoftware schreef op maandag 13 oktober 2025 @ 21:11:
Zojuist ook twee Marstek Venus E 3.0 ontvangen. Het is mij ook nog niet gelukt om RS485 werkend te krijgen, heb zelf kabels gemaakt op basis van de pinout. Ik heb een bericht gestuurd voor andere firmware, hopelijk is dat het probleem

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

Welke pin-out heb je gebruikt? Die van thuisbatterij.nl klopt niet.

[bpssoftware]

pascallj schreef op maandag 13 oktober 2025 @ 21:14:
[...]
Welke pin-out heb je gebruikt? Die van thuisbatterij.nl klopt niet.

Welke pinout is dan wel goed? Is het niet pin 1 en 2?

[pascallj]

bpssoftware schreef op maandag 13 oktober 2025 @ 21:25:
[...]


Welke pinout is dan wel goed? Is het niet pin 1 en 2?

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.

[ Voor 5% gewijzigd door pascallj op 13-10-2025 21:29 ]

[comfix]

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.

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

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