Marstek Venus / Duravolt PnP Thuisaccu Modbus koppeling

[tdolder]

WargamingPlayer schreef op dinsdag 22 juli 2025 @ 18:19:
[...]

Ik heb een post hierover gemaakt waarin de Elfin uitgelegd wordt. Hij is ook compleet te voeden door de Marstek. Moet geen enkel probleem zijn.

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

Templates:
https://github.com/Wargam...-Venus-E-Modbus/tree/main

Op mijn Git staat ook waar je even rekening mee moet houden en welke stappen je moet doen met de Elfin.

Ik heb jouw Git ook gebruikt en deze werkt als een zonnetje. Dank!

[superduper1969]

Ik kreeg deze vraag binnen via Github, iemand al ervaring?

[pascallj]

superduper1969 schreef op donderdag 24 juli 2025 @ 10:31:
Ik kreeg deze vraag binnen via Github, iemand al ervaring?
[Afbeelding]

Ja heb ik beschreven in de datasheet gelinkt in deze post:

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

Het is niet firmware 153 die de verandering veroorzaakt, maar BMS 213:

[vsander]

WargamingPlayer schreef op dinsdag 22 juli 2025 @ 18:19:
[...]

Ik heb een post hierover gemaakt waarin de Elfin uitgelegd wordt. Hij is ook compleet te voeden door de Marstek. Moet geen enkel probleem zijn.

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

Templates:
https://github.com/Wargam...-Venus-E-Modbus/tree/main

Op mijn Git staat ook waar je even rekening mee moet houden en welke stappen je moet doen met de Elfin.

Super, thanks! Je bent mijn held! het werkt nu als een zonnetje!

[pascallj]

Voor degene die hier monitoren: ik probeer wat karakteristieken van de Marstek in kaart te brengen. Heeft er iemand de volgende data of kan dit voor mij monitoren:

* De via Modbus gerapporteerde "Battery Power", "Battery Current" en "Battery Voltage" niet onder load (dus geen draaiend NOM of manueel programma) bij zowel 100% SoC en bij ongeveer 50% SoC.

Wil het gedrag van mijn batterij vergelijken met die van anderen.

[SatScan]

pascallj schreef op vrijdag 25 juli 2025 @ 14:13:
Voor degene die hier monitoren: ik probeer wat karakteristieken van de Marstek in kaart te brengen. Heeft er iemand de volgende data of kan dit voor mij monitoren:

* De via Modbus gerapporteerde "Battery Power", "Battery Current" en "Battery Voltage" niet onder load (dus geen draaiend NOM of manueel programma) bij zowel 100% SoC en bij ongeveer 50% SoC.

Wil het gedrag van mijn batterij vergelijken met die van anderen.

Bij mij staan de batterijen in de NOM modi.

Ik voeg een plaatje toe zodat je kunt zien wat er veranderd is in de monitoring vanaf Batterij FW 153. Dat is volgens mij strikt gedaan voor MT support en misschien voorloper op de open API integratie.

Succes met je zoektocht!

[pascallj]

SatScan schreef op vrijdag 25 juli 2025 @ 16:15:
[...]


Bij mij staan de batterijen in de NOM modi.

Ik voeg een plaatje zodat je kunt zien wat er veranderd is in de monitoring vanaf Batterij FW 153. Dat is volgens mij strikt gedaan voor MT support en misschien voorloper op de open API integratie.

Succes met je zoektocht!

[Afbeelding]

Dankje! Het gaat mij echter specifiek om de load in standby bij die twee verschillende SoC. Dus als de batterij niet in standby staat is de ruis te groot.

[rb1213]

beste tweakers vrienden,

ik slaag er maar niet in om met de batterij te spreken via modbus serial in mn home assistent
rechtstreeks vanuit windows lukt het met mn usb-->rs485 converter , maar niet in HA
heeft iemand dat aan de praat gekregen via modbus serial met een kabel(niet tcp!)

modbus:
- name: Marstek_Venus_E
type: serial
method: rtu
port: /dev/serial/by-id/usb-ATC_High_Speed_USB_To_RS-485_DAYM9W8X-if00-port0
baudrate: 115200
bytesize: 8
parity: N
stopbits: 1

[SatScan]

pascallj schreef op vrijdag 25 juli 2025 @ 16:18:
[...]


Dankje! Het gaat mij echter specifiek om de load in standby bij die twee verschillende SoC. Dus als de batterij niet in standby staat is de ruis te groot.

Eigenlijk zitten die periodes hier ook tussen... als de EV wordt geladen gaan de batterijen op manueel zonder een opdracht. Welke duur in die toestand is voor jou handig? Kan ik wel een keer uitvoeren als ik toch de EV moet laden.

laat maar weten bij interesse

[pascallj]

SatScan schreef op vrijdag 25 juli 2025 @ 18:35:
[...]


Eigenlijk zitten die periodes hier ook tussen... als de EV wordt geladen gaan de batterijen op manueel zonder een opdracht. Welke duur in die toestand is voor jou handig? Kan ik wel een keer uitvoeren als ik toch de EV moet laden.

laat maar weten bij interesse

Een seconde of tien laten stabiliseren is genoeg. Gaat me echt alleen om het idle verbruik zoals het gerapporteerd wordt.

[superduper1969]

rb1213 schreef op vrijdag 25 juli 2025 @ 17:14:
beste tweakers vrienden,

ik slaag er maar niet in om met de batterij te spreken via modbus serial in mn home assistent
rechtstreeks vanuit windows lukt het met mn usb-->rs485 converter , maar niet in HA
heeft iemand dat aan de praat gekregen via modbus serial met een kabel(niet tcp!)

modbus:
- name: Marstek_Venus_E
type: serial
method: rtu
port: /dev/serial/by-id/usb-ATC_High_Speed_USB_To_RS-485_DAYM9W8X-if00-port0
baudrate: 115200
bytesize: 8
parity: N
stopbits: 1

Hoe draait je HA, die van mij in HyperV en dan werkt USB niet.
In Virtualbox zou usb wel moeten werken met wat moeite.

Dit is het full serial sample van HA modbus.
Dus ik mis nog een de delay, messagewait en timeout.

# Example yaml: full udp connection
modbus:
- name: modbus_hub
type: serial
port: /dev/ttyUSB0
baudrate: 9600
bytesize: 8
method: rtu
parity: E
stopbits: 1

delay: 0
message_wait_milliseconds: 30
timeout: 5

[tdolder]

rb1213 schreef op vrijdag 25 juli 2025 @ 17:14:
beste tweakers vrienden,

ik slaag er maar niet in om met de batterij te spreken via modbus serial in mn home assistent
rechtstreeks vanuit windows lukt het met mn usb-->rs485 converter , maar niet in HA
heeft iemand dat aan de praat gekregen via modbus serial met een kabel(niet tcp!)

modbus:
- name: Marstek_Venus_E
type: serial
method: rtu
port: /dev/serial/by-id/usb-ATC_High_Speed_USB_To_RS-485_DAYM9W8X-if00-port0
baudrate: 115200
bytesize: 8
parity: N
stopbits: 1

Ik heb dit ook geprobeerd via USB serial maar ook geen succes. Ik gebruik nu de Elfin EW11 en dit werkt top!

[Mattie112]

Ik heb gister 2x de Venus E besteld. HA draai ik al enige tijd en ik denk voor de batterij binnen komt even kijken hoe we die in HA gaan krijgen. Zo kwam ik op dit topic.

Als ik het goed begrijp is dat zelfs als je de batterij niet via HA aan wil sturen je alsnog het beste via 1 van de manieren uit de TS de boel uit kan lezen? Dat zou namelijk mijn belangrijkste doel zijn: puur wat statistieken in HA krijgen.

Stel dat je wel de batterij via modbus aan wil sturen, kan HA dat (op basis van P1) voor je regelen? Misschien dat ik hem in de schuur zet waar ik LAN heb. Natuurlijk kan ik een AP ophangen maar als een modbus bordje met LAN ook werkt is dat misschien net zo stabiel.

In de TS staan 7 opties, is daar een bepaalde optie "het beste" of is het puur "wat kan je verkrijgen". Maakt het nog uit als je 2 batterijen hebt? Ik neem aan dat je ze beide moet uitlezen?

Het lijkt alsof de Elfin het meest transparante is? Aangezien dat puur een modbus->wifi dingetje is waar HA vervolgens verder de data verwerkt?

[Maarten69]

[b]Mattie112 in "Marstek Venus / Duravolt PnP Thuisaccu Modbus koppeling"Mattie112 schreef
Stel dat je wel de batterij via modbus aan wil sturen, kan HA dat (op basis van P1) voor je regelen?

Ja, gebruik hiervoor de HA addon b2500 meter en simuleer een shellypro3em.

[ Voor 36% gewijzigd door Maarten69 op 26-07-2025 15:21 ]

[Mattie112]

Maarten69 schreef op zaterdag 26 juli 2025 @ 15:19:
[...]

Ja, gebruik hiervoor de HA addon b2500 meter en simuleer een shellypro3em.
[Afbeelding]

Thanks, is dat stuk alvast duidelijk!


Ik vind hier het ook nog 2x een D1 Mini v3 ESP8266 en 1x en ESP32

Misschien heb ik wel aan puur een TTL->R485 genoeg dan....

[superduper1969]

Mattie112 schreef op zaterdag 26 juli 2025 @ 14:57:
Ik heb gister 2x de Venus E besteld. HA draai ik al enige tijd en ik denk voor de batterij binnen komt even kijken hoe we die in HA gaan krijgen. Zo kwam ik op dit topic.

Als ik het goed begrijp is dat zelfs als je de batterij niet via HA aan wil sturen je alsnog het beste via 1 van de manieren uit de TS de boel uit kan lezen? Dat zou namelijk mijn belangrijkste doel zijn: puur wat statistieken in HA krijgen.

Stel dat je wel de batterij via modbus aan wil sturen, kan HA dat (op basis van P1) voor je regelen? Misschien dat ik hem in de schuur zet waar ik LAN heb. Natuurlijk kan ik een AP ophangen maar als een modbus bordje met LAN ook werkt is dat misschien net zo stabiel.

In de TS staan 7 opties, is daar een bepaalde optie "het beste" of is het puur "wat kan je verkrijgen". Maakt het nog uit als je 2 batterijen hebt? Ik neem aan dat je ze beide moet uitlezen?

Het lijkt alsof de Elfin het meest transparante is? Aangezien dat puur een modbus->wifi dingetje is waar HA vervolgens verder de data verwerkt?

De code van de Lilygo wordt door mij actief onderhouden als er weer nieuwe registers worden gevonden. Ik vind de UI van ESP Home fijner dan die van HA Modbus.
Maar het staat je vrij om een Elfin te nemen. Een ieder die registers uit nieuwe firmware ook in de Elfin code implementeert mag ook in GitHub een voorstel tot aanpassing doen.

Zelf ga ik die niet meer testen. Maar in December was ik met de Elfin begonnen omdat door een FW bug dat het enige was wat ik aan de gang kon krijgen met mijn kennis.

Maar toevoegen van nieuwe registers is net zo makkelijk bij de Elfin als bij de Lilygo oplossing.

Met 2 accu's gebruiken de meeste 2 Lilygo of 2 Elfin . Technisch kan 1 ook maar dat is nogal een gedoe en niet uitgeschreven op Tweakers. Ik heb zelf ook maar 1 accu dus ik ga het ook niet doen. En ze zijn ook niet duur.

[[RNMC] Viper]

WargamingPlayer schreef op woensdag 23 juli 2025 @ 00:19:
Inmiddels een kleine update met wat extra sensoren en wat fixes.

https://github.com/Wargam...-Venus-E-Modbus/tree/main

Ben overigens met belangstelling naar de Plugin van @[RNMC] Viper aan het kijken, want dat is heel veelbelovend. Moet nog even python leren om het helemaal te begrijpen. Maar wanneer die plugin klaar is, dan kan mijn werk de prullenbak in

Viper's custom Integratie.
https://github.com/ViperRNMC/marstek_venus_modbus

Dat is ook de reden waarom ik hem gedeeld heb, laten we het vooral gezamenlijk beter/eenvoudiger maken. Mijn integratie kan sowieso goed omgaan met meerdere batterijen. Eerst even vakantie en dan weer verder verbeteren.

Trouwens die cuttoff issue is wel een gekke, je kunt hem in Home Assistant ook naar 11% drukken, terwijl 12 minimum is volgens documentatie van duravolt.

[pascallj]

[RNMC] Viper schreef op zaterdag 26 juli 2025 @ 22:23:
[...]


Dat is ook de reden waarom ik hem gedeeld heb, laten we het vooral gezamenlijk beter/eenvoudiger maken. Mijn integratie kan sowieso goed omgaan met meerdere batterijen. Eerst even vakantie en dan weer verder verbeteren.

Trouwens die cuttoff issue is wel een gekke, je kunt hem in Home Assistant ook naar 11% drukken, terwijl 12 minimum is volgens documentatie van duravolt.

Hij gaat uit bij het cutoff percentage - 1. Dus 12 wordt 11 etc. Als ik het goed herinner wordt 11 niet als geldige waarde geaccepteerd.

[ Voor 5% gewijzigd door pascallj op 26-07-2025 22:26 ]

[SatScan]

pascallj schreef op zaterdag 26 juli 2025 @ 22:25:
[...]


Hij gaat uit bij het cutoff percentage - 1. Dus 12 wordt 11 etc. Als ik het goed herinner wordt 11 niet als geldige waarde geaccepteerd.

Oke ik dacht om de backup poort actief te houden maar dat is dus niet zo...
Zet ik die op 15%

[Tom Jansen]

Hoi, ik zie al een aantal maanden dat de gemiddelde temperatuur, interne temperatuur van mijn Marstek zo'n 40° graden is.
Is dit bij jullie ook? Extra koeling dmv. fans op de koel ribben heeft weinig effect....
Vraag is dus, is deze temperatuur bij jullie ook op deze waarde?

[JanAllElectric]

Tom Jansen schreef op zondag 27 juli 2025 @ 11:03:
Hoi, ik zie al een aantal maanden dat de gemiddelde temperatuur, interne temperatuur van mijn Marstek zo'n 40° graden is.
Is dit bij jullie ook? Extra koeling dmv. fans op de koel ribben heeft weinig effect....
Vraag is dus, is deze temperatuur bij jullie ook op deze waarde?

geen gemiddelde beschikbaar, maar op dit moment:

M1: 33 graden (active)
M2: 28 graden (passive)
M3: 36 graden (active)

[pascallj]

Tom Jansen schreef op zondag 27 juli 2025 @ 11:03:
Hoi, ik zie al een aantal maanden dat de gemiddelde temperatuur, interne temperatuur van mijn Marstek zo'n 40° graden is.
Is dit bij jullie ook? Extra koeling dmv. fans op de koel ribben heeft weinig effect....
Vraag is dus, is deze temperatuur bij jullie ook op deze waarde?

Als de batterij in NOM staat is dat niet zo heel gek, de omvormer staat dan continu aan. Bij mij staat hij vaak in Stand-by en dan is het wat lager, 30-35. Je merkt ook dat als hij een tijdje helemaal uit heeft gestaan, en dan aangezet wordt de temperatuur ook oploopt vanaf ongeveer kamertemperatuur, tot die waarde, dus de sensor klopt wel. Mijn vermoeden is dat de sensor in de buurt van het BMS zit.

[dannyro]

Maarten69 schreef op zaterdag 26 juli 2025 @ 15:19:
[...]

Ja, gebruik hiervoor de HA addon b2500 meter en simuleer een shellypro3em.
[Afbeelding]

Heeft deze addon voordelen tgo de regeling via HW P1 meter in de app? Of de regeling tgo modbus?

[Tom Jansen]

JanAllElectric schreef op zondag 27 juli 2025 @ 11:12:
[...]


geen gemiddelde beschikbaar, maar op dit moment:

M1: 33 graden (active)
M2: 28 graden (passive)
M3: 36 graden (active)

Thanks. Weet ik dat mijn gemiddelde ''normaal'' is.

[Tom Jansen]

pascallj schreef op zondag 27 juli 2025 @ 11:13:
[...]


Als de batterij in NOM staat is dat niet zo heel gek, de omvormer staat dan continu aan. Bij mij staat hij vaak in Stand-by en dan is het wat lager, 30-35. Je merkt ook dat als hij een tijdje helemaal uit heeft gestaan, en dan aangezet wordt de temperatuur ook oploopt vanaf ongeveer kamertemperatuur, tot die waarde, dus de sensor klopt wel. Mijn vermoeden is dat de sensor in de buurt van het BMS zit.

Thanks! Ik vermoed het ook dat de temp gemeten wordt bij het BMS. Maakt dat mijn temp uitlezing redelijk normaal is

[Horla]

Tom Jansen schreef op zondag 27 juli 2025 @ 11:03:
Hoi, ik zie al een aantal maanden dat de gemiddelde temperatuur, interne temperatuur van mijn Marstek zo'n 40° graden is.
Is dit bij jullie ook? Extra koeling dmv. fans op de koel ribben heeft weinig effect....
Vraag is dus, is deze temperatuur bij jullie ook op deze waarde?

Ik draai NOM en ik zie dat de interne temperatuur 's avonds/'s nachts inderdaad altijd rond de 40° graden is. Tijdens het laden loopt dit dan op naar begin 50°. De hoogste temperatuur van de afgelopen maand is 55° trouwens. De twee andere sensoren geven altijd een paar graden kouder aan. De batterij staat bij mij in de berging (waar ook droogkast en wasmachine staan).

[AUijtdehaag]

pascallj schreef op woensdag 16 juli 2025 @ 14:36:
[...]


Bij deze een vervolg m.b.t. onbekende Modbus registers.

Heb nu een aantal dagen de onbekende registers gemonitord en wat tests gedraaid en voor een hoop is nu duidelijk waar het voor dient. Helaas zijn veel registers dubbel uitgevoerd, dus aan die data hebben we niet zoveel. Heb alles gedocumenteerd in de datasheet.

Hier een overzicht van wat we tot nu toe extra weten ten opzichte van het Duravolt document, maar voor de details verwijs ik je naar de datasheet:

• Battery voltage average (dubbel)
• Battery current (average) (dubbel)
• AC voltage (dubbel)
• AC current (dubbel)
• AC offgrid voltage (dubbel)
• Internal MOS1 temperature (dubbel)
• Internal MOS2 temperature (dubbel)
• Internal temperature (dubbel)
• WiFi status (nieuw!)
• BT status (nieuw!)
• Cloud status (nieuw!)
• WiFi Signal Strength (nieuw!)
• BMS version (HEX) (dubbel)
• Software version (HEX) (dubbel)
• Firmware version (HEX) (dubbel)
• Device MAC address
• Communication module firmware version
• Firmware version
• BMS version
• AC power (dubbel)
• Battery SOC (dubbel)
• Cell temperature (dubbel)
• Maximum cell voltage
• Minimum cell voltage
• Power restriction (nieuw!)
• WiFi SSID

Er zijn nog een paar registers onbekend die wel regelmatig van waarde veranderen, maar die ik nog niet kan thuisbrengen. De rest van de registers blijft leeg, of bevat waarschijnlijk een instelling/status die ik niet heb kunnen zien veranderen.

Zoals ook al gemeld door @rtlvandeven is het ook mogelijk om 'Grid loss' uit te lezen in de error registers (op meerdere plekken), maar verder is het lastig om andere errors te simuleren.

Wat aanvullingen en aanpassingen gedaan aan de m5stack Atom S3 versie vanuit jouw info:
• WIFI /BT /CLOUD status
• WIFI strength % / Battery WIFI strength %
• Software/Firmware/BMS version
• Power restriction status


(wellicht handig om ook over te nemen voor de lilygo)

[Mattie112]

Kan je de LilyGO versie ook direct voeden vanuit RS485 of dan dat alleen met de Elfin of de M5Stack Atom?

[tinamar]

@tom jansen

MT staat bij mij in glazen veranda waar het makkelijk tot 35° kan worden, draai NOM Dip naar 27° is met MT uitgezet

[ Voor 2% gewijzigd door tinamar op 27-07-2025 22:42 . Reden: typo ]

[pascallj]

Mattie112 schreef op zondag 27 juli 2025 @ 17:41:
Kan je de LilyGO versie ook direct voeden vanuit RS485 of dan dat alleen met de Elfin of de M5Stack Atom?

Ja hoor kan. Even goed kijken in de TS welke versie je hebt en welke kabel en dan gewoon + en - op de DC IN aansluiten.

[AUijtdehaag]

@Mattie112
Je hebt dan ook nog een verloopkabeltje nodig, tenzij je de originele stekker afknipt.

[TDSgame]

AUijtdehaag schreef op zondag 27 juli 2025 @ 19:11:
@Mattie112
Je hebt dan ook nog een verloopkabeltje nodig, tenzij je de originele stekker afknipt.

Arduino (dupont) kabeltjes werken ook als "tijdelijke" oplossing.

[Mattie112]

Thx all, liep wat minder soepel vandaag dus had niet echt tijd er naar te kijken. Wil wel vanaf het eerste moment de boel monitoren dus bij @AUijtdehaag 2 setjes gekocht

Ik laat het nog wel weten of alles goed werkt! Ben heel benieuwd!

(1 van de problemen van vandaag was zelfs een stukke SSD waar m'n homeassistant op draait, lekkere timing.. . Was maar 1 jaar 3mnd oud!)

[dannyro]

AUijtdehaag schreef op zondag 27 juli 2025 @ 16:27:
[...]

Wat aanvullingen en aanpassingen gedaan aan de m5stack Atom S3 versie vanuit jouw info:
• WIFI /BT /CLOUD status
• WIFI strength % / Battery WIFI strength %
• Software/Firmware/BMS version
• Power restriction status

[Afbeelding]
(wellicht handig om ook over te nemen voor de lilygo)

Werkt Perfect/ Bedankt @AUijtdehaag

[TDSgame]

Mattie112 schreef op zondag 27 juli 2025 @ 21:28:
Thx all, liep wat minder soepel vandaag dus had niet echt tijd er naar te kijken. Wil wel vanaf het eerste moment de boel monitoren dus bij @AUijtdehaag 2 setjes gekocht

Ik laat het nog wel weten of alles goed werkt! Ben heel benieuwd!

(1 van de problemen van vandaag was zelfs een stukke SSD waar m'n homeassistant op draait, lekkere timing.. . Was maar 1 jaar 3mnd oud!)

SSD of SD en van welk merk? Was deze overvol geraakt misschien?

[Mattie112]

TDSgame schreef op maandag 28 juli 2025 @ 11:35:
[...]


SSD of SD en van welk merk? Was deze overvol geraakt misschien?

offtopic:
Nee echt de SSD, vol geen idee het was een 500GB versie dus lijkt me sterk maar dat kan ik nu niet meer checken haha

Weet iemand trouwens hoe dat zit in HomeAssistant? Ziet die 1 'grote' batterij of meerdere ?

[TDSgame]

Mattie112 schreef op maandag 28 juli 2025 @ 11:55:
[...]

offtopic:
Nee echt de SSD, vol geen idee het was een 500GB versie dus lijkt me sterk maar dat kan ik nu niet meer checken haha

Weet iemand trouwens hoe dat zit in HomeAssistant? Ziet die 1 'grote' batterij of meerdere ?

offtopic:
Welk merk? (weet ik wat te vermijden...) zelf al niet super ervaring met Kingston

HomeAssistant zal iedere batterij apart zien, dit kan wel gecombineerd worden door helpers aan te maken.

[JanAllElectric]

Mattie112 schreef op maandag 28 juli 2025 @ 11:55:
[...]

offtopic:
Nee echt de SSD, vol geen idee het was een 500GB versie dus lijkt me sterk maar dat kan ik nu niet meer checken haha

Weet iemand trouwens hoe dat zit in HomeAssistant? Ziet die 1 'grote' batterij of meerdere ?

Ik heb 3 accus met ieder een eigen lilygo. Home asistant ziet derhalve 3 afzonderlijke accu's.

Ik de configuratie yaml tel ik ze bij elkaar op. Dan kan je ze ook uitlezen als 1 grote accu. Aansturen moet je evenwel individueel doen.

[ Voor 35% gewijzigd door JanAllElectric op 28-07-2025 12:18 ]

[superduper1969]

AUijtdehaag schreef op zondag 27 juli 2025 @ 16:27:
[...]

Wat aanvullingen en aanpassingen gedaan aan de m5stack Atom S3 versie vanuit jouw info:
• WIFI /BT /CLOUD status
• WIFI strength % / Battery WIFI strength %
• Software/Firmware/BMS version
• Power restriction status

[Afbeelding]
(wellicht handig om ook over te nemen voor de lilygo)

Ziet er goed uit, ik zal gaan testen voor de Lilygo en dan includen op Github.

[Mattie112]

JanAllElectric schreef op maandag 28 juli 2025 @ 12:08:
[...]

Ik heb 3 accus met ieder een eigen lilygo. Home asistant ziet derhalve 3 afzonderlijke accu's.

Ik de configuratie yaml tel ik ze bij elkaar op. Dan kan je ze ook uitlezen als 1 grote accu. Aansturen moet je evenwel individueel doen.
[Afbeelding]

Cool zoiets is top ja!

[iorses]

JanAllElectric schreef op maandag 28 juli 2025 @ 12:08:
[...]

Ik heb 3 accus met ieder een eigen lilygo. Home asistant ziet derhalve 3 afzonderlijke accu's.

Ik de configuratie yaml tel ik ze bij elkaar op. Dan kan je ze ook uitlezen als 1 grote accu. Aansturen moet je evenwel individueel doen.
[Afbeelding]

Zou je eventueel de yamls willen delen? Dashboard/Automatiseringen enzo?
Ik ben benieuwd hoe je het in elkaar gestoken hebt en ben hard op zoek naar wat inspiratie en ideeën.

[JanAllElectric]

iorses schreef op maandag 28 juli 2025 @ 18:07:
[...]

Zou je eventueel de yamls willen delen? Dashboard/Automatiseringen enzo?
Ik ben benieuwd hoe je het in elkaar gestoken hebt en ben hard op zoek naar wat inspiratie en ideeën.

ik werk niet met automatiseringen binnen HASS, maar met HASS/node-red en veel javascript + MQTT en HASS/node-red API.

Toevallig op verzoek wat javascript-code gedeeld en het resultaat object in HASS/node-red:
JanAllElectric in "Hame / Marstek / Duravolt 5,12kWh plug en play thuisaccu"

[ Voor 19% gewijzigd door JanAllElectric op 28-07-2025 18:58 ]

[iorses]

JanAllElectric schreef op maandag 28 juli 2025 @ 18:57:
[...]


ik werk niet met automatiseringen binnen HASS, maar met HASS/node-red en veel javascript + MQTT en HASS/node-red API.

Toevallig op verzoek wat javascript-code gedeeld en het resultaat object in HASS/node-red:
JanAllElectric in "Hame / Marstek / Duravolt 5,12kWh plug en play thuisaccu"

Dankjewel, ben er niet mega in thuis maar als ik het me even goed bestudeer denk ik wel dat ik er chocolade van kan maken.
Waarmee doe je de PV voorspelling? Ik heb momenteel een dagelijkse vergelijking lopen tussen 3 verschillende om te kijken welke ik zou kunnen gebruiken maar tot nu toe verschilt het per dag nogsteeds heel erg!

[JanAllElectric]

iorses schreef op maandag 28 juli 2025 @ 19:20:
[...]

Dankjewel, ben er niet mega in thuis maar als ik het me even goed bestudeer denk ik wel dat ik er chocolade van kan maken.
Waarmee doe je de PV voorspelling? Ik heb momenteel een dagelijkse vergelijking lopen tussen 3 verschillende om te kijken welke ik zou kunnen gebruiken maar tot nu toe verschilt het per dag nogsteeds heel erg!

Ik gebruik deze (gratis) integratie: https://github.com/rany2/ha-open-meteo-solar-forecast.

Die levert bij mij redelijk nauwkeurige voorspellingen op.

Hiervoor gebruikte ik de betaalde integratie forcast_solar. Die zat er met dezelfde instellingen flink naast.

Verder houd ik bij hoeveel % van de PV opbrengst gemiddeld voor de accu's overblijft. Met dit % "weet" ik of ik met de voorspelling van vandaag de accu's met PV kan vullen (of dat ik moet bijkopen).

NB: deze functie berekent ook hoeveel kWh ik in de nacht nodig heb. Hiermee weet ik het minimum_level waarmee ik overdag mijn accu's moet vullen.

code:

function updateVerbruikEnZelfgebruik(standHuis, standPVoverschot, pvDagOpbrengst, nachtStart, nachtEind, aantalDagen, d = {}) {
    d.prevStandHuis ??= standHuis;
    d.thuisVerbruikUur ??= Array(24).fill(0);
    d.thuisVerbruikUurHistory ??= Array.from({ length: 24 }, () => []);
    d.nachtVerbruikHistory ??= [];
    d.pvOverschotPctHistory ??= [];

    const tijd = global.get('Time');

    // Vul per uur bij minuut 59
    if (tijd.mmm === 59 && tijd.ss === 0) {
        d.thuisVerbruikUur[tijd.hh] = standHuis - d.prevStandHuis;
        
        // Voeg toe aan history (max aantalDagen)
        const uurArray = d.thuisVerbruikUurHistory[tijd.hh];
        uurArray.push(d.thuisVerbruikUur[tijd.hh]);
        if (uurArray.length > aantalDagen) uurArray.shift();
        
        d.prevStandHuis = standHuis;  
    } 

    // net voor middernacht: bereken dagresultaten
    if (tijd.tijd === '23:59:30') {
        const nachtIndices = getUrenInInterval(nachtStart, nachtEind)
        //const nachtIndices = [...Array(24).keys()].filter(u => (u >= nachtStart || u < nachtEind));
        const nachtVerbruik = nachtIndices.reduce((sum, i) => sum + d.thuisVerbruikUur[i], 0);
        const pvPct = pvDagOpbrengst ? Math.min(100, Math.round(100 * standPVoverschot / pvDagOpbrengst)) : 0;

        // Voeg toe aan history (max aantalDagen)
        if (d.nachtVerbruikHistory.push(nachtVerbruik) > aantalDagen) d.nachtVerbruikHistory.shift();
        if (d.pvOverschotPctHistory.push(pvPct) > aantalDagen) d.pvOverschotPctHistory.shift();

        d.nachtVerbruikLaatste = nachtVerbruik;
        d.pvOverschotPctLaatste = pvPct;

        //reset standen
        d.prevStandHuis = 0;
        d.thuisVerbruikUur = Array(24).fill(0);
    }

    d.nachtVerbruikGem = Math.round(d.nachtVerbruikHistory.reduce((a, b) => a + b, 0) / d.nachtVerbruikHistory.length || 0);
    d.thuisVerbruikUurGem =  d.thuisVerbruikUurHistory.map(uurArray => Math.round(uurArray.reduce((a, b) => a + b, 0) / uurArray.length || 0));
    d.pvOverschotPctGem = Math.round(d.pvOverschotPctHistory.reduce((a, b) => a + b, 0) / d.pvOverschotPctHistory.length || 0);
    
    return {  
        ...d
    };
}

//****************************************
function getUrenInInterval(start, eind) {
    const uren = [];
    let uur = start;
    while (true) {
        uren.push(uur);
        uur = (uur + 1) % 24;
        if (uur === eind) break;
    }
    return uren;
}

//****************************************
var states = global.get('homeassistant.homeAssistant.states');


let standVerbruikhuis = 1000 * states['sensor.daghuisverbruik'].state;
let standPVdagopbrengst = parseFloat(Number(1000 * states['sensor.dagopbrengst_pv'].state).toFixed(0));
let standPVdagteruglevering = parseFloat(Number(1000 * states['sensor.dagteruglevering_pv'].state).toFixed(0));
let standPVdagpvaccuin = parseFloat(Number(1000 * states['sensor.pv_accu_in'].state).toFixed(0))

let standPVoverschot = standPVdagteruglevering + standPVdagpvaccuin;

const sunriseUur = new Date(states['sun.sun'].attributes.next_rising).getHours() + 3;
const sunsetUur = new Date(states['sun.sun'].attributes.next_setting).getHours() - 2;

// Vorige data ophalen
let d = flow.get('VerbruikEnZelfgebruik');
d = updateVerbruikEnZelfgebruik(standVerbruikhuis, standPVoverschot, standPVdagopbrengst, sunsetUur, sunriseUur, 5, d);
flow.set('VerbruikEnZelfgebruik', d);

context.set('Stand', { standVerbruikhuis: standVerbruikhuis, standPVoverschot: standPVoverschot, standPVdagopbrengst: standPVdagopbrengst});

node.status({ text: 'Nachtvebruik: ' + d.nachtVerbruikLaatste + ' W / pct PV overschot: ' + d.pvOverschotPctLaatste + ' %' + ', sunset -2: ' + sunsetUur + ' uur, sunrise +3: ' + sunriseUur + ' uur'});

return msg;

[ Voor 80% gewijzigd door JanAllElectric op 28-07-2025 19:56 ]

[iorses]

JanAllElectric schreef op maandag 28 juli 2025 @ 19:45:
[...]


Ik gebruik deze (gratis) integratie: https://github.com/rany2/ha-open-meteo-solar-forecast.

Die levert bij mij redelijk nauwkeurige voorspellingen op.

Hiervoor gebruikte ik de betaalde integratie forcast_solar. Die zat er met dezelfde instellingen flink naast.

Verder houd ik bij hoeveel % van de PV opbrengst gemiddeld voor de accu's overblijft. Met dit % "weet" ik of ik met de voorspelling van vandaag de accu's met PV kan vullen (of dat ik moet bijkopen).

NB: deze functie berekent ook hoeveel kWh ik in de nacht nodig heb. Hiermee weet ik het minimum_level waarmee ik overdag mijn accu's moet vullen.

code:

function updateVerbruikEnZelfgebruik(standHuis, standPVoverschot, pvDagOpbrengst, nachtStart, nachtEind, aantalDagen, d = {}) {
    d.prevStandHuis ??= standHuis;
    d.thuisVerbruikUur ??= Array(24).fill(0);
    d.thuisVerbruikUurHistory ??= Array.from({ length: 24 }, () => []);
    d.nachtVerbruikHistory ??= [];
    d.pvOverschotPctHistory ??= [];

    const tijd = global.get('Time');

    // Vul per uur bij minuut 59
    if (tijd.mmm === 59 && tijd.ss === 0) {
        d.thuisVerbruikUur[tijd.hh] = standHuis - d.prevStandHuis;
        
        // Voeg toe aan history (max aantalDagen)
        const uurArray = d.thuisVerbruikUurHistory[tijd.hh];
        uurArray.push(d.thuisVerbruikUur[tijd.hh]);
        if (uurArray.length > aantalDagen) uurArray.shift();
        
        d.prevStandHuis = standHuis;  
    } 

    // net voor middernacht: bereken dagresultaten
    if (tijd.tijd === '23:59:30') {
        const nachtIndices = getUrenInInterval(nachtStart, nachtEind)
        //const nachtIndices = [...Array(24).keys()].filter(u => (u >= nachtStart || u < nachtEind));
        const nachtVerbruik = nachtIndices.reduce((sum, i) => sum + d.thuisVerbruikUur[i], 0);
        const pvPct = pvDagOpbrengst ? Math.min(100, Math.round(100 * standPVoverschot / pvDagOpbrengst)) : 0;

        // Voeg toe aan history (max aantalDagen)
        if (d.nachtVerbruikHistory.push(nachtVerbruik) > aantalDagen) d.nachtVerbruikHistory.shift();
        if (d.pvOverschotPctHistory.push(pvPct) > aantalDagen) d.pvOverschotPctHistory.shift();

        d.nachtVerbruikLaatste = nachtVerbruik;
        d.pvOverschotPctLaatste = pvPct;

        //reset standen
        d.prevStandHuis = 0;
        d.thuisVerbruikUur = Array(24).fill(0);
    }

    d.nachtVerbruikGem = Math.round(d.nachtVerbruikHistory.reduce((a, b) => a + b, 0) / d.nachtVerbruikHistory.length || 0);
    d.thuisVerbruikUurGem =  d.thuisVerbruikUurHistory.map(uurArray => Math.round(uurArray.reduce((a, b) => a + b, 0) / uurArray.length || 0));
    d.pvOverschotPctGem = Math.round(d.pvOverschotPctHistory.reduce((a, b) => a + b, 0) / d.pvOverschotPctHistory.length || 0);
    
    return {  
        ...d
    };
}

//****************************************
function getUrenInInterval(start, eind) {
    const uren = [];
    let uur = start;
    while (true) {
        uren.push(uur);
        uur = (uur + 1) % 24;
        if (uur === eind) break;
    }
    return uren;
}

//****************************************
var states = global.get('homeassistant.homeAssistant.states');


let standVerbruikhuis = 1000 * states['sensor.daghuisverbruik'].state;
let standPVdagopbrengst = parseFloat(Number(1000 * states['sensor.dagopbrengst_pv'].state).toFixed(0));
let standPVdagteruglevering = parseFloat(Number(1000 * states['sensor.dagteruglevering_pv'].state).toFixed(0));
let standPVdagpvaccuin = parseFloat(Number(1000 * states['sensor.pv_accu_in'].state).toFixed(0))

let standPVoverschot = standPVdagteruglevering + standPVdagpvaccuin;

const sunriseUur = new Date(states['sun.sun'].attributes.next_rising).getHours() + 3;
const sunsetUur = new Date(states['sun.sun'].attributes.next_setting).getHours() - 2;

// Vorige data ophalen
let d = flow.get('VerbruikEnZelfgebruik');
d = updateVerbruikEnZelfgebruik(standVerbruikhuis, standPVoverschot, standPVdagopbrengst, sunsetUur, sunriseUur, 5, d);
flow.set('VerbruikEnZelfgebruik', d);

context.set('Stand', { standVerbruikhuis: standVerbruikhuis, standPVoverschot: standPVoverschot, standPVdagopbrengst: standPVdagopbrengst});

node.status({ text: 'Nachtvebruik: ' + d.nachtVerbruikLaatste + ' W / pct PV overschot: ' + d.pvOverschotPctLaatste + ' %' + ', sunset -2: ' + sunsetUur + ' uur, sunrise +3: ' + sunriseUur + ' uur'});

return msg;

Dankjewel wederom, ik ga zelf een aantal weken monitoren en dit is de sheet tot nu toe.
Ik heb nu 1 Marstek en twijfel om 2 of 3 bij te kopen, wat is jou jaarlijkse verbruik ongeveer en heb je dat dan gedekt met 3 Marsteks?
Ik kan volgend jaar over op dynamisch maar eenmaal op dynamisch wil ik eigenlijk ook mijn gehele verbruik dagelijks uit de accu laten komen zo heb ik ook volledige controle op het tarief.

[TDSgame]

iorses schreef op maandag 28 juli 2025 @ 19:20:
[...]

Dankjewel, ben er niet mega in thuis maar als ik het me even goed bestudeer denk ik wel dat ik er chocolade van kan maken.
Waarmee doe je de PV voorspelling? Ik heb momenteel een dagelijkse vergelijking lopen tussen 3 verschillende om te kijken welke ik zou kunnen gebruiken maar tot nu toe verschilt het per dag nogsteeds heel erg!

Ik gebruik deze eens goed ingesteld vrij accuraat. https://github.com/BJReplay/ha-solcast-solar

[iorses]

TDSgame schreef op maandag 28 juli 2025 @ 20:17:
[...]


Ik gebruik deze eens goed ingesteld vrij accuraat. https://github.com/BJReplay/ha-solcast-solar

Buiten de hellingshoek en de liggingsgraden wat kan ik nog tweaken dan?
OpenMeteo zit tot nu toe het beste maar de dagen dat hij er naast zit dan zit hij er ook heel flink naast!

[superduper1969]

Topicstart aangepast:
- 28-7-2025 Grote aanpassingen Lilygo Github dankzij @AUijtdehaag (fonske)
• WebUI met iconen
• WIFI /BT /CLOUD status
• WIFI strength %
• Battery WIFI strength %
• Software/Firmware/BMS version
• Power restriction status

[ Voor 27% gewijzigd door superduper1969 op 28-07-2025 21:37 ]

[iorses]

Iemand enig idee hoe ik dit vertaal naar een HA sensor?
Mijn modbus kennis gaat niet verder dan basis om eerlijk te zijn!

[pascallj]

iorses schreef op maandag 28 juli 2025 @ 21:49:
Iemand enig idee hoe ik dit vertaal naar een HA sensor?
Mijn modbus kennis gaat niet verder dan basis om eerlijk te zijn!
[Afbeelding]

Dit register werkt niet, dus bespaar jezelf de moeite.

Mijn documentatie is nauwkeuriger: https://docs.google.com/s...9238506&single=true&pli=1

Maar eerlijk gezegd, als je het niet kan vertalen, moet je dan wel zelf een Modbus implementatie gaan schrijven ipv een van de bestaande oplossingen uit dit topic gebruiken?

[iorses]

pascallj schreef op maandag 28 juli 2025 @ 21:52:
[...]


Dit register werkt niet, dus bespaar jezelf de moeite.

Mijn documentatie is nauwkeuriger: https://docs.google.com/s...9238506&single=true&pli=1

Maar eerlijk gezegd, als je het niet kan vertalen, moet je dan wel zelf een Modbus implementatie gaan schrijven ipv een van de bestaande oplossingen uit dit topic gebruiken?

Buiten dat ik dit niet snap heb ik alles naar wens draaien via een modbus gateway, het is niet dat ik niks ervanaf weet alleen bitmasking snap ik niet echt.
Ik haal de CT connectie status nu nog uit de MQTT maar zou dit graag uit de modbus halen.
Overigens in de basis heb ik de Elfin config gebruikt zodat ik niet alles handmatig hoefde te doen maar dit heb ik ook aangepast en uitgedund naar wens.
Echter is deze config nog niet aangepast op de nieuwste ontwikkelingen die hier geweest zijn.

[ Voor 18% gewijzigd door iorses op 28-07-2025 22:02 ]

[JanAllElectric]

superduper1969 schreef op maandag 28 juli 2025 @ 21:17:
Topicstart aangepast:
- 28-7-2025 Grote aanpassingen Lilygo Github dankzij @AUijtdehaag (fonske)
• WebUI met iconen
• WIFI /BT /CLOUD status
• WIFI strength %
• Battery WIFI strength %
• Software/Firmware/BMS version
• Power restriction status
[Afbeelding]

Bij mij werkt deze versie niet (goed). Blijft heel lang offline. De enige keer dat ik even online was zag de website er veel beter uit en alle info was actueel .

De "vorige versie" gaf een signaal sterkte van -42dB. Nu kom ik niet verder dan -68dB/ -75dB en soms helemaal geen connectie meer.

Vervelend is dat via OTA de vorige versie terugzetten ook niet meer werkt. Signaalsterkte blijft -75dB.
Morgen maar helemaal clearen en opnieuw via usb flashen.

Edit: sorry: ik moet dit natuurlijk als issue via github doen

Wat doet deze code precies?
vorige versie:

code:

web_server:
  port: 80

nieuwe versie:

code:

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

[ Voor 39% gewijzigd door JanAllElectric op 28-07-2025 23:48 ]

[SatScan]

JanAllElectric schreef op maandag 28 juli 2025 @ 23:19:
[...]


Bij mij werkt deze versie niet (goed). Blijft heel lang offline. De enige keer dat ik even online was zag de website er veel beter uit en alle info was actueel .

De "vorige versie" gaf een signaal sterkte van -42dB. Nu kom ik niet verder dan -68dB/ -75dB en soms helemaal geen connectie meer.

Vervelend is dat via OTA de vorige versie terugzetten ook niet meer werkt. Signaalsterkte blijft -75dB.
Morgen maar helemaal clearen en opnieuw via usb flashen.

Edit: sorry: ik moet dit natuurlijk als issue via github doen

Wat doet deze code precies?
vorige versie:

code:

web_server:
  port: 80

nieuwe versie:

code:

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

Maakt sub-groepen/overzichten aan in lay-out

[SatScan]

superduper1969 schreef op maandag 28 juli 2025 @ 21:17:
Topicstart aangepast:
- 28-7-2025 Grote aanpassingen Lilygo Github dankzij @AUijtdehaag (fonske)
• WebUI met iconen
• WIFI /BT /CLOUD status
• WIFI strength %
• Battery WIFI strength %
• Software/Firmware/BMS version
• Power restriction status
[Afbeelding]

Getest en werkt! De txt ruimte is wel beperkt en woorden worden afgekapt, als mogelijk is de kolombreedte aanpassen svp.

PS als ik in browser speel met de schermbreedte zodanig dat de Debug Log naar beneden wordt verplaatst is de kolombreedte prima en alles goed te lezen. Misschien dat de Debug log standaard onderaan getoond kan worden?

PPS mooie toevoeging door op informatie-sensoren te klikken je het verloop krijgt te zien!

[ Voor 43% gewijzigd door SatScan op 29-07-2025 11:05 ]

[superduper1969]

JanAllElectric schreef op maandag 28 juli 2025 @ 23:19:
[...]


Bij mij werkt deze versie niet (goed). Blijft heel lang offline. De enige keer dat ik even online was zag de website er veel beter uit en alle info was actueel .

De "vorige versie" gaf een signaal sterkte van -42dB. Nu kom ik niet verder dan -68dB/ -75dB en soms helemaal geen connectie meer.

Vervelend is dat via OTA de vorige versie terugzetten ook niet meer werkt. Signaalsterkte blijft -75dB.
Morgen maar helemaal clearen en opnieuw via usb flashen.

Edit: sorry: ik moet dit natuurlijk als issue via github doen

Wat doet deze code precies?
vorige versie:

code:

web_server:
  port: 80

nieuwe versie:

code:

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

Deze code veranderd alleen het aantal sensoren en de presentatie daarvan.
Meer kan ook niet!, Ik heb niet "effe" de Wifi code herschreven.
Onthoudt dat ESPHome Builder óók net nieuw is, en dat bij een update van ESPHome Builder nog veel meer wordt bijgewerkt als deze Code. Dus het heeft geen zin om daarvoor een GitHub issue aan te maken.

Signaalsterkte is nu ook beschikbaar in % én in dBm kijk je bij de goede?
En er is er één van de Liligo en één van de Marstek.
En anders is na de reboot de Lilygo verbonden aan een van de andere routers in je Mesh, komt vanzelf goed.

web_server:
port: 80
version: 3
include_internal: False > Verberg onbelangrijke items
# ota: False > Dit verbergt de OTA knop binnen de Web interface

Dit is de WebMenu Structuur:
name: "Info" = Label
sorting_weight: -40 = Volgorde


Kopieer alle code vanaf Regel 34 Web Server

[ Voor 38% gewijzigd door superduper1969 op 29-07-2025 06:48 ]

[JanAllElectric]

superduper1969 schreef op dinsdag 29 juli 2025 @ 06:32:
[...]

Deze code veranderd alleen het aantal sensoren en de presentatie daarvan.
Meer kan ook niet!, Ik heb niet "effe" de Wifi code herschreven.
Onthoudt dat ESPHome Builder óók net nieuw is, en dat bij een update van ESPHome Builder nog veel meer wordt bijgewerkt als deze Code. Dus het heeft geen zin om daarvoor een GitHub issue aan te maken.

Signaalsterkte is nu ook beschikbaar in % én in dBm kijk je bij de goede?
En er is er één van de Liligo en één van de Marstek.
En anders is na de reboot de Lilygo verbonden aan een van de andere routers in je Mesh, komt vanzelf goed.

web_server:
port: 80
version: 3
include_internal: False > Verberg onbelangrijke items
# ota: False > Dit verbergt de OTA knop binnen de Web interface

Dit is de WebMenu Structuur:
name: "Info" = Label
sorting_weight: -40 = Volgorde


Kopieer alle code vanaf Regel 34 Web Server

Je hebt inderdaad gelijk. Ik gebruik 2025.4.2.De betreffende Marstek M1 blijkt ineens op mijn hoofd Amplifi (in de kamer op 25 meter afstand) te zijn verbonden en niet meer zoals M2 en M3 op de mesh in het tuinhuis (2 meter afstand) . Ik heb al meerdere malen nieuwe versies met OTA geüpgraded. Dit nog niet meegemaakt.

Edit 10:05: geheel opnieuw erasen en flashen via usb heeft het probleem opgelost. Nu weer -33dB signaalsterkte. Alleen lijkt het rebooten veel langer te duren dan voorheen.

Edit: 12:00: flashen via OTA van M2 en M3 met nieuwe versie ging wel in 1 keer goed .

[ Voor 8% gewijzigd door JanAllElectric op 29-07-2025 12:09 ]

[TDSgame]

iorses schreef op maandag 28 juli 2025 @ 20:20:
[...]

Buiten de hellingshoek en de liggingsgraden wat kan ik nog tweaken dan?
OpenMeteo zit tot nu toe het beste maar de dagen dat hij er naast zit dan zit hij er ook heel flink naast!

De locatie kan ingesteld worden en dan AC vermogen, DC vermogen, de richting en efficiency en na alles ingesteld te hebben en misschien enkele keren de efficiency aan te passen klopt dit vrij goed.

[pascallj]

iorses schreef op maandag 28 juli 2025 @ 21:56:
[...]

Buiten dat ik dit niet snap heb ik alles naar wens draaien via een modbus gateway, het is niet dat ik niks ervanaf weet alleen bitmasking snap ik niet echt.
Ik haal de CT connectie status nu nog uit de MQTT maar zou dit graag uit de modbus halen.
Overigens in de basis heb ik de Elfin config gebruikt zodat ik niet alles handmatig hoefde te doen maar dit heb ik ook aangepast en uitgedund naar wens.
Echter is deze config nog niet aangepast op de nieuwste ontwikkelingen die hier geweest zijn.

Ik heb wat basis testjes gedaan met CT gebruiken en loskoppelen, maar heb via Modbus geen verschillen kunnen waarnemen. Ik gebruik zelf geen CT dus kan het op de lange duur niet monitoren, maar lijkt er op alsof dat niet via Modbus op te vragen is.

[superduper1969]

JanAllElectric schreef op dinsdag 29 juli 2025 @ 09:34:
[...]


Je hebt inderdaad gelijk. Ik gebruik 2025.4.2.De betreffende Marstek M1 blijkt ineens op mijn hoofd Amplifi (in de kamer op 25 meter afstand) te zijn verbonden en niet meer zoals M2 en M3 op de mesh in het tuinhuis (2 meter afstand) . Ik heb al meerdere malen nieuwe versies met OTA geüpgraded. Dit nog niet meegemaakt.

Edit 10:05: geheel opnieuw erasen en flashen via usb heeft het probleem opgelost. Nu weer -33dB signaalsterkte. Alleen lijkt het rebooten veel langer te duren dan voorheen.

Edit: 12:00: flashen via OTA van M2 en M3 met nieuwe versie ging wel in 1 keer goed .

Je bent een professionele troubleshooter die kan inschatten welke omgevingsvariabelen invloed hebben, of je bent het niet!
Bron: Mezelf

[AUijtdehaag]

De webserver kan wat belastener zijn voor de ESP als de pagina opgevraagd wordt.
Maar op de Atom S3 lite gaat dat eigenlijk wel goed (ESP32S3)

De lilygo is echter een gewone esp32 dus wat trager volgens mij
(*de Atom lite is ook een gewone esp32 waarmee ik wel eens test. Laden van de esphome code duurt een stuk langer via usb in ieder geval dan met een esp32s3)

Ik gebruik deze code wel eens om te testen.
https://github.com/gekkek...lob/main/confs/debug.yaml
Maar geen idee of je daarmee iets wijzer wordt.

@superduper1969
De lange namen kan je makkelijk in korten
friendly_name korter
https://github.com/fonske...main/lilygo-rs485.yaml#L3
vs
https://github.com/fonske...tom_s3_lite_rs485.yaml#L3

en alle marstek uit de benamingingen halen in de esphome code.

Krijg je wel allemaal andere entities uiteraard na compile

[ Voor 28% gewijzigd door AUijtdehaag op 29-07-2025 17:31 ]

[Mirabis]

In de TS kan ik wel vinden hoe je een Elvin aan EVCC koppelt maar ik vroeg me af of dat ook kan met de LilyGo. Beetje googlen kwam ik uit op https://esphome.io/components/modbus_controller.html. waar staat dat je ook modbus server kan maaken.

Ik heb de batterij via de LilyGo nu aan HomeAssistant gekoppeld maar koppeling naar EVCC ontbreekt nog. Iemand dat al eerder gedaan? Dus zowel ontsluiten naar HA (via modbus -> LilyGo) als koppeling third party tooling via Modbus TCP (of RTU) beschikbaar gesteld door ESPHome.

[superduper1969]

AUijtdehaag schreef op dinsdag 29 juli 2025 @ 16:51:
De webserver kan wat belastener zijn voor de ESP als de pagina opgevraagd wordt.
Maar op de Atom S3 lite gaat dat eigenlijk wel goed (ESP32S3)

De lilygo is echter een gewone esp32 dus wat trager volgens mij
(*de Atom lite is ook een gewone esp32 waarmee ik wel eens test. Laden van de esphome code duurt een stuk langer via usb in ieder geval dan met een esp32s3)

Ik gebruik deze code wel eens om te testen.
https://github.com/gekkek...lob/main/confs/debug.yaml
Maar geen idee of je daarmee iets wijzer wordt.

@superduper1969
De lange namen kan je makkelijk in korten
friendly_name korter
https://github.com/fonske...main/lilygo-rs485.yaml#L3
vs
https://github.com/fonske...tom_s3_lite_rs485.yaml#L3

en alle Marstek uit de benamingen halen in de esphome code.

Krijg je wel allemaal andere entities uiteraard na compile

De Webserver op de Lilygo gaat als een speer en laad binnen 2 seconden of zo, niets bijzonders en zeker niet onwerkbaar.
Inmiddels draaien zoveel mensen (ook veel Duitsers) met deze code dat ze als ik de naming structuur ga wijzigen dat veel mensen hun HA Overview opnieuw moeten inrichten en ook historische data kwijt zijn.
Na een paar maanden zitten we al in de Legacy Support LOL.

In het prille begin dachten we dat de delays die getoond worden in ESP home een gevolg zouden zijn van de traagheid van de ESP maar dat bleek niet het geval te zijn. De vertragingen zijn een gevolg van de verwerkingstijd van de MT.

Natuurlijk kunnen de namen in de WebUI en ook de HA Sensoren een stuk korter maar ik denk dat er een aantal gebruikers hier niet op zitten wachten.
Om nog een 2e codebase met korte namen te aan te maken maal 3 zit ik ook niet op te wachten.

Iedereen dit dit wil kan in notepad++ of zelfs in de ESPHome Builder Editor een Find & Replace doen om de namen in te korten. Wel eerst effe een Backupje maken natuurlijk.

[Javice19]

gevonden

[ Voor 97% gewijzigd door Javice19 op 30-07-2025 18:03 ]

[tomdn]

Ik heb een marstek venus e 2.0 met een LilyGo T-Can485
Alle gegevens kan ik zien die ik in ha onder het apparaat LilyGo maar als ik de led status uitschakel gaat het uit maar gaat binnen de seconde terug aan.
Maar alle senoren van my battery zijn leeg of onbekend.
Ik weet niet wat ik precies verkeerd doen maar ik vind het niet

[iorses]

pascallj schreef op dinsdag 29 juli 2025 @ 11:54:
[...]


Ik heb wat basis testjes gedaan met CT gebruiken en loskoppelen, maar heb via Modbus geen verschillen kunnen waarnemen. Ik gebruik zelf geen CT dus kan het op de lange duur niet monitoren, maar lijkt er op alsof dat niet via Modbus op te vragen is.

Doe jij alleen via de force sturen dan dus geen NOM?
Want als je namelijk NOM draait en de CT is niet verbonden blijft hij standby wat gruwelijk vervelend is.

[tdolder]

Vandaag 2e Marstek Venus E v2 ontvangen. Vrijdag komt er weer een setje Elfin EW11 binnen dus kan kan ik ze volledige integreren in HA.
Binnenkort starten met aanpassen van de subverdeler (meterkast) in de garage/schuur zodat ik ze bij elkaar kan zetten en gelijk op eigen groepen.

[pascallj]

iorses schreef op woensdag 30 juli 2025 @ 15:55:
[...]

Doe jij alleen via de force sturen dan dus geen NOM?
Want als je namelijk NOM draait en de CT is niet verbonden blijft hij standby wat gruwelijk vervelend is.

Ja klopt inderdaad! Ik handel op dynamisch, dus maar keer per dag externe aansturing en dat is het.

Waarom is het vervelend dat hij op stand-by gaat als er geen CT verbonden is? Dat lijkt mij het enige juiste gedrag. Als je niet weet wat het verbruik van de woning is, kan je daar ook niet op sturen.

[SatScan]

tomdn schreef op woensdag 30 juli 2025 @ 15:03:
Ik heb een marstek venus e 2.0 met een LilyGo T-Can485
Alle gegevens kan ik zien die ik in ha onder het apparaat LilyGo maar als ik de led status uitschakel gaat het uit maar gaat binnen de seconde terug aan.
Maar alle senoren van my battery zijn leeg of onbekend.
Ik weet niet wat ik precies verkeerd doen maar ik vind het niet
[Afbeelding]

Je hebt beide files met hetzelfde opvolgnummer gebruikt?

lilygo-rs485-3.yaml
marstek_venus_battery3_control.yaml

[tomdn]

SatScan schreef op donderdag 31 juli 2025 @ 10:38:
[...]


Je hebt beide files met hetzelfde opvolgnummer gebruikt?

lilygo-rs485-3.yaml
marstek_venus_battery3_control.yaml

Ja dat heb ik gedaan ik heb alles al 3 keer opnieuw geprobeert

[SatScan]

tomdn schreef op donderdag 31 juli 2025 @ 11:13:
[...]

Ja dat heb ik gedaan ik heb alles al 3 keer opnieuw geprobeert

Oke, ik heb al een tijdje hetzelfde probleem en dacht dat het aan mij lag mbt vele HA aanpassingen etc.
Mocht je het vinden dan hoor ik het graag!

[superduper1969]

tomdn schreef op woensdag 30 juli 2025 @ 15:03:
Ik heb een marstek venus e 2.0 met een LilyGo T-Can485
Alle gegevens kan ik zien die ik in ha onder het apparaat LilyGo maar als ik de led status uitschakel gaat het uit maar gaat binnen de seconde terug aan.
Maar alle senoren van my battery zijn leeg of onbekend.
Ik weet niet wat ik precies verkeerd doen maar ik vind het niet
[Afbeelding]

Als je maar 1 batterij hebt waarom gebruik je de lilygo-rs485-3.yaml i.p.v. lilygo-rs485.yaml?
En marstek_venus_battery3_control.yaml i.p.v. marstek_venus_battery_control.yaml
Wat laat de Web Pagina van de Lilygo zien? (ESPHome Builder > Visit)
Gebruik SPOOK om configuratiefouten in HA op te sporen.
SPOOK Video: The Ultimate Home Assistant Clean-up Tool - Spook, Not Your Homie

[Hometek]

SOC drift/calibratie

Ik had in de eerste weken met de Marsteks enkele keren opgemerkt dat de SOC plotseling van een waarde tussen 20 en 30% in een keer terug viel naar 11%. (anderen hier op het forum hebben ondertussen soorgelijke ervaringen gemeld).
De oorzaak is meestal SOC drift, de geschatte capaciteit klopt niet meer met de werkelijkheid. Mijn batterijen waren in die eerst weken zelden tot 100% geraakt.

Ondertussen is er meer PV opwek en heb ik een sturing via modbus/HA met een strategie die er voor zorgt dat de batterijen regelmatig tot 100% opgeladen worden. Omdat ik relatief veel batterij capaciteit heb raken de batterijen nu echter niet meer leeg.
Vandaag heb ik een test gedaan om te zien of de SOC nog betrouwbaar is.
Ik heb 1 Marstek ontladen met 1450W (EV met laag vermogen bijgeladen).
De batterij was al 2 maanden niet meer volledig ontladen.

SOC 2 maanden


SOC vandaag tijdens ontladen met ca. 1450W


SOC laatste paar minuten, plotselinge daling van 15 naar 11%


Één test is te weinig om harde conclusies te trekken, bovendien heb ik pas kort geleden de update naar BMS V213 geinstaleerd, maar mijn eerste indruk is dat de SOC redelijk goed gecalibreert wordt mits je regelmatig naar 100% oplaad. Regelmatig volledig ontladen lijkt niet noodzakelijk.
Voorlopig blijf ik bij mijn strategie waarbij de batterijen zo veel mogelijk vol opgeladen worden.

In mijn ervaring moet de batterij ca. alle 3 a 4 dagen naar 100% voor een redelijk betrouwbare SOC (ervaring is echter gebaseerd op BMS V210 en V212!)
De batterij zal trouwens ook prima blijven werken als je niet vaak 100% oplaadt, alleen de waarden in de app zijn dan niet meer betrouwbaar.

Deze SOC 'test' staat los van de discussie over cel balancing.

[tomdn]

superduper1969 schreef op donderdag 31 juli 2025 @ 12:12:
[...]

Als je maar 1 batterij hebt waarom gebruik je de lilygo-rs485-3.yaml i.p.v. lilygo-rs485.yaml?
En marstek_venus_battery3_control.yaml i.p.v. marstek_venus_battery_control.yaml
Wat laat de Web Pagina van de Lilygo zien? (ESPHome Builder > Visit)
Gebruik SPOOK om configuratiefouten in HA op te sporen.
SPOOK Video: The Ultimate Home Assistant Clean-up Tool - Spook, Not Your Homie

Ik heb de yaml files aangepast en opnieuw geupload met geen verschil
web pagina van de lilgo zit er goed uit denk ik

Spook toont geen fout meldingen
ik zie wel dit

[iorses]

pascallj schreef op woensdag 30 juli 2025 @ 17:02:
[...]


Ja klopt inderdaad! Ik handel op dynamisch, dus maar keer per dag externe aansturing en dat is het.

Waarom is het vervelend dat hij op stand-by gaat als er geen CT verbonden is? Dat lijkt mij het enige juiste gedrag. Als je niet weet wat het verbruik van de woning is, kan je daar ook niet op sturen.

Ik bedoel meer een logisch maar vervelend gevolg, je wilt dat het nooit in ‘storing’ gaat en de CT altijd verbonden is.

[pascallj]

Hometek schreef op donderdag 31 juli 2025 @ 14:20:
SOC drift/calibratie

Ik had in de eerste weken met de Marsteks enkele keren opgemerkt dat de SOC plotseling van een waarde tussen 20 en 30% in een keer terug viel naar 11%. (anderen hier op het forum hebben ondertussen soorgelijke ervaringen gemeld).
De oorzaak is meestal SOC drift, de geschatte capaciteit klopt niet meer met de werkelijkheid. Mijn batterijen waren in die eerst weken zelden tot 100% geraakt.

Ondertussen is er meer PV opwek en heb ik een sturing via modbus/HA met een strategie die er voor zorgt dat de batterijen regelmatig tot 100% opgeladen worden. Omdat ik relatief veel batterij capaciteit heb raken de batterijen nu echter niet meer leeg.
Vandaag heb ik een test gedaan om te zien of de SOC nog betrouwbaar is.
Ik heb 1 Marstek ontladen met 1450W (EV met laag vermogen bijgeladen).
De batterij was al 2 maanden niet meer volledig ontladen.

SOC 2 maanden
[Afbeelding]

SOC vandaag tijdens ontladen met ca. 1450W
[Afbeelding]

SOC laatste paar minuten, plotselinge daling van 15 naar 11%
[Afbeelding]

Één test is te weinig om harde conclusies te trekken, bovendien heb ik pas kort geleden de update naar BMS V213 geinstaleerd, maar mijn eerste indruk is dat de SOC redelijk goed gecalibreert wordt mits je regelmatig naar 100% oplaad. Regelmatig volledig ontladen lijkt niet noodzakelijk.
Voorlopig blijf ik bij mijn strategie waarbij de batterijen zo veel mogelijk vol opgeladen worden.

In mijn ervaring moet de batterij ca. alle 3 a 4 dagen naar 100% voor een redelijk betrouwbare SOC (ervaring is echter gebaseerd op BMS V210 en V212!)
De batterij zal trouwens ook prima blijven werken als je niet vaak 100% oplaadt, alleen de waarden in de app zijn dan niet meer betrouwbaar.

Deze SOC 'test' staat los van de discussie over cel balancing.

De vraag is alleen of de capaciteit wordt aangepast aan de gemeten capaciteit. Sinds BMS 213 is de capaciteit veranderd en klopt de SoC bij mij nooit meer met ontladen: hij meet altijd te veel en blijft dus op 15/16 hangen, totdat hij leeg genoeg is loopt dan pas naar 11. Met opladen gaat het prima. Ik maak alleen hele cyclussen van 11 naar 100 en sinds BMS 213 is de curve nog nooit correct geweest.

[Mattie112]

[SatScan]

tomdn schreef op donderdag 31 juli 2025 @ 14:24:
[...]

Ik heb de yaml files aangepast en opnieuw geupload met geen verschil
web pagina van de lilgo zit er goed uit denk ik

Hier geen foutmeldingen met spook en werkt ook niet.
Ben nu aan het onderzoeken of er iets met de broker niet goed gaat...

[Metsubsidie]

Mattie112 schreef op donderdag 31 juli 2025 @ 14:50:
[Afbeelding]

Gefeliciteerd met je aankoop, weet zeker dat er een wereld voor je open gaat !

Veel plezier ermee !

Nu nog over de drempel zien te krijgen.

[superduper1969]

tomdn schreef op donderdag 31 juli 2025 @ 14:24:
[...]

Ik heb de yaml files aangepast en opnieuw geupload met geen verschil
web pagina van de lilgo zit er goed uit denk ik
[Afbeelding]
Spook toont geen fout meldingen
ik zie wel dit
[Afbeelding]

Dus spook ziet Wel meldingen. Dit zijn sensoren die kennelijk inmiddels niet meer bestaan of hernoemd zijn.

Er zijn 2 manieren van energy metingen:
Bij de oude firmware was de data van de batterij niet correct. Daarom werd deze berekend als utility_meter.
Bij de nieuwe firmware is deze wel correct. Afhankelijk van je firmware versie kon je de schaal aanpassen.
Deze staat dacht ik standaard met ###### in GitHub code.

Alles wat wel correct staat op de Lilygo web pagina moet je gewoon kunnen tonen in HA mits je de correcte sensor kiest.

Dit is makkelijker als je eerst kijkt bij Developer Tools > States en dan zoekt met de loep naar sensoren met de correcte waarde.

De andere methode is gewoon alle sensoren van de Settings >Devices >ESPHome pagina te bezoeken en daar Add to Dashboard te kiezen en de volgorde aan te passen of sensoren te verwijderen.

[Mattie112]

@AUijtdehaag Ik heb 1 van de accus aangesloten op de Atom en netjes stats in HomeAssistant zo te zien!

(nog niet met 2 batterijen getest want die 2e wil nog even niet de P1 meter zien, zie algemene topic)

Vroeg me af:

Wat is de settings "RS485 Control Mode", met die op disabled kan ik settings aanpassen. Of heeft dat te maken met de "Force Charge/Discharge" (die los staat van de "manual" stand neem ik aan?)

[pascallj]

Mattie112 schreef op donderdag 31 juli 2025 @ 19:36:
@AUijtdehaag Ik heb 1 van de accus aangesloten op de Atom en netjes stats in HomeAssistant zo te zien!

(nog niet met 2 batterijen getest want die 2e wil nog even niet de P1 meter zien, zie algemene topic)

Vroeg me af:

Wat is de settings "RS485 Control Mode", met die op disabled kan ik settings aanpassen. Of heeft dat te maken met de "Force Charge/Discharge" (die los staat van de "manual" stand neem ik aan?)

Klopt! Zie de TS daar staat het beschreven.

[Mattie112]

pascallj schreef op donderdag 31 juli 2025 @ 19:38:
[...]


Klopt! Zie de TS daar staat het beschreven.

Ah verrek, overheen gelezen, thanks!

[Tom Jansen]

Horla schreef op zondag 27 juli 2025 @ 12:09:
[...]

Ik draai NOM en ik zie dat de interne temperatuur 's avonds/'s nachts inderdaad altijd rond de 40° graden is. Tijdens het laden loopt dit dan op naar begin 50°. De hoogste temperatuur van de afgelopen maand is 55° trouwens. De twee andere sensoren geven altijd een paar graden kouder aan. De batterij staat bij mij in de berging (waar ook droogkast en wasmachine staan).

Thanks. Inmiddels 2, 160mm fans geïnstalleerd. Geplaats op de koelribben. Temp blijft nu max 40°C al een paar dagen. 👊🏻

[pascallj]

In mijn eeuwig durende queeste om de Modbus implementatie volledig en correct te krijgen bedacht ik mij ineens het volgende. Onderstaande registers sloegen eigenlijk nergens op met de huidige implementatie :

Battery charge voltage limit (5,71 V)
Battery charge current limit (0-10 A)
Battery discharge current limit (0-10A)

Maar moet de komma niet 1 decimaal naar rechts opgeschoven worden? Dan heb je een spanningslimiet van 57,1 V (dat zou neerkomen op 3,57 V per cel bij een perfect gebalanceerde batterij, precies voordat OVP in zou schakelen) en een laad- en ontlaadstroomlimiet van 100 A (het zijn 100 Ah cellen, dus dat zou precies 1 C zijn).

De momenten waarop de stroomlimieten veranderen, komen ook precies overeen met wanneer de batterij in vermogen schakelt (op de foto ordegrootte nog niet aangepast):



Het enige is alleen dat de batterij zich bij het ontladen dan niet aan limiet van 20 A zou houden, het is op dat moment namelijk 25 A. Met opladen klopt het wel en zit het laatste stukje niet onder de 20 A.

Je hebt dan alsnog weinig aan deze waardes maar toch

Plausibel?

[ Voor 7% gewijzigd door pascallj op 31-07-2025 22:21 ]

[superduper1969]

pascallj schreef op donderdag 31 juli 2025 @ 22:18:
In mijn eeuwig durende queeste om de Modbus implementatie volledig en correct te krijgen bedacht ik mij ineens het volgende. Onderstaande registers sloegen eigenlijk nergens op met de huidige implementatie :

Battery charge voltage limit (5,71 V)
Battery charge current limit (0-10 A)
Battery discharge current limit (0-10A)

Maar moet de komma niet 1 decimaal naar rechts opgeschoven worden? Dan heb je een spanningslimiet van 57,1 V (dat zou neerkomen op 3,57 V per cel bij een perfect gebalanceerde batterij, precies voordat OVP in zou schakelen) en een laad- en ontlaadstroomlimiet van 100 A (het zijn 100 Ah cellen, dus dat zou precies 1 C zijn).

De momenten waarop de stroomlimieten veranderen, komen ook precies overeen met wanneer de batterij in vermogen schakelt (op de foto ordegrootte nog niet aangepast):

[Afbeelding]

Het enige is alleen dat de batterij zich bij het ontladen dan niet aan limiet van 20 A zou houden, het is op dat moment namelijk 25 A. Met opladen klopt het wel en zit het laatste stukje niet onder de 20 A.

Je hebt dan alsnog weinig aan deze waardes maar toch

Plausibel?

Charge voltage limit heb ik al tijden zo staan.
En 47A x 53V (Gemiddeld) is rond de 2500W.

[ Voor 10% gewijzigd door superduper1969 op 31-07-2025 22:57 ]

[pascallj]

superduper1969 schreef op donderdag 31 juli 2025 @ 22:54:
[...]

Charge voltage limit heb ik al tijden zo staan.
En 47A x 53V (Gemiddeld) is rond de 2500w

Oh ik zie het. Ga ik dat in de documentatie ook maar aanpassen.

[Klausn]

Thanks for your work. Its working fine for me! Nice stable solution so far.

[Klausn]

I use a venus e 5,12 kwh and a shelly 3 em pro.

[tdolder]

Vandaag 2 x Elfin EW11 ontvangen. Eentje voor de 2e accu die ik deze week heb ontvangen en 1 op voorraad voor de 3e nog aan te schaffen accu. Nu eerst de onderverdeler in de garage/schuur aanpassen naar 3 fasen.
Wat een leuke hobby :-)

[wesjuhdabomb]

Ik heb de Lilygo besteld om een Marstek Venus E met Mosbus uit te lezen a.d.h.v. dit topic. Voornaamste doel is om gebruiksgegevens in home assistant te krijgen.

Omdat ik een SMR 4.2 meter heb, heb ik ook last van pendelen. De batterij gaat vaak van laden naar ontladen en 'wacht' eigenlijk niet op wat zijn aanpassing in laad / ontlaad vermogen doet op de P1. Kijk je live mee zie je dan ook dat de batterij zijn vermogen wat seconden later nog een keer opschaalt, en zodra de P1 meter uiteindelijk update, gaat het verhaal andersom hetzelfde.

Omdat dit gedrag wat in te dammen had ik het idee om met HA en de modbus koppeling het maximale laad vermogen te beperken tot het minimale wanner er minder dan 200w uit de zonnepanelen komt. De kans dat er dan overcapaciteit is om te laden is dan toch al nihil en in een NoM scenario wil je niet laden van het net (wat nu dus wel af en toe gebeurd).

Iemand een idee of dit kan werken, en wat het minimale instelbare laadvermogen via modbus is?

[pascallj]

wesjuhdabomb schreef op vrijdag 1 augustus 2025 @ 19:44:
[...]

Iemand een idee of dit kan werken, en wat het minimale instelbare laadvermogen via modbus is?

[...]

Dat kan zeker. Je kunt hem ook gewoon tijdelijk uit zetten. Zijn al een aantal die slimme sturingen gemaakt hebben. Misschien lees je hier meer daarover: Marstek PIB Domotica integratie en je Energierekening

Het vermogen is traploos instelbaar tussen 0 en 2500 voor zowel laden als ontladen.

[wesjuhdabomb]

Dat is goed om te horen! Zal nog wat verder lezen voordat de Lilygo binnen is . Bedankt.

[iorses]

Iemand enig idee wat inverter state code: 6 is? Het lijkt backup mode maar volgens de PDF zou dit normaliter code 4 zijn?

[pascallj]

iorses schreef op vrijdag 1 augustus 2025 @ 21:25:
Iemand enig idee wat inverter state code: 6 is? Het lijkt backup mode maar volgens de PDF zou dit normaliter code 4 zijn?

Dat is inderdaad Backup / AC Bypass.

Volgens `hm2mqtt` is dit de volgorde:

TypeScript:

        switch (v) {
          case '0':
            return 'sleep';
          case '1':
            return 'standby';
          case '2':
            return 'charging';
          case '3':
            return 'discharging';
          case '4':
            return 'backup';
          case '5':
            return 'upgrading';
          case '6':
            return 'bypass';
          default:
            return 'standby';
        }

En volgens de code van ~superduper1969:

C++:

      switch (int(id(inverter_state).state)) {
        case 0: return std::string("Sleep");
        case 1: return std::string("Standby");
        case 2: return std::string("Charge");
        case 3: return std::string("Discharge");
        case 4: return std::string("Fault");
        case 5: return std::string("Idle");
        case 6: return std::string("AC bypass");
        default: return std::string("Unknown");
      };

Waar zij deze statussen vandaan hebben weet ik niet.

Overigens niet om mijzelf steeds maar aan te prijzen, maar ik zou mijn documentatie gebruiken; die is nauwkeuriger. Daar staat ook de AC bypass op 6 in. Maar 4/5 zijn wel anders, moet nog kijken hoe dat nu zit.

[pascallj]

Overigens zit ik zojuist mijn eigen test nog eens door te kijken en is status 4 dus Backup zonder Grid en 6 AC Bypass (backup met grid). Dacht net dat er niets nuttigs uit de test kwam, maar heb gewoon niet goed gekeken.

[Ellroe32]

Herkent iemand dit:

Ik zet rs485_control_mode op enable......en een aantal minuten later spring hij vanzelf weer terug naar disable.

[pascallj]

Ellroe32 schreef op zaterdag 2 augustus 2025 @ 12:32:
Herkent iemand dit:

Ik zet rs485_control_mode op enable......en een aantal minuten later spring hij vanzelf weer terug naar disable.

Je verandert niet toevallig de User Work Mode hierna? Die springt naar Anti-Feed, maar moet je gewoon daarop laten staan.

[iorses]

pascallj schreef op vrijdag 1 augustus 2025 @ 21:58:
[...]


Dat is inderdaad Backup / AC Bypass.

Volgens `hm2mqtt` is dit de volgorde:

TypeScript:

        switch (v) {
          case '0':
            return 'sleep';
          case '1':
            return 'standby';
          case '2':
            return 'charging';
          case '3':
            return 'discharging';
          case '4':
            return 'backup';
          case '5':
            return 'upgrading';
          case '6':
            return 'bypass';
          default:
            return 'standby';
        }

En volgens de code van ~superduper1969:

C++:

      switch (int(id(inverter_state).state)) {
        case 0: return std::string("Sleep");
        case 1: return std::string("Standby");
        case 2: return std::string("Charge");
        case 3: return std::string("Discharge");
        case 4: return std::string("Fault");
        case 5: return std::string("Idle");
        case 6: return std::string("AC bypass");
        default: return std::string("Unknown");
      };

Waar zij deze statussen vandaan hebben weet ik niet.

Overigens niet om mijzelf steeds maar aan te prijzen, maar ik zou mijn documentatie gebruiken; die is nauwkeuriger. Daar staat ook de AC bypass op 6 in. Maar 4/5 zijn wel anders, moet nog kijken hoe dat nu zit.

Super info, wordt erg op prijs gesteld!

[AUijtdehaag]

Ellroe32 schreef op zaterdag 2 augustus 2025 @ 12:32:
Herkent iemand dit:

Ik zet rs485_control_mode op enable......en een aantal minuten later spring hij vanzelf weer terug naar disable.

De app nog open staan misschien?

[SatScan]

Heeft even geduurd.. maar alles werkt nu eindelijk weer zoals eerder.
Probleem? Alles verwijdert opnieuw HA gestart en opnieuw geïnstalleerd en het werkte!

Fingers Crossed.