Marstek Venus / Duravolt PnP Thuisaccu Modbus koppeling

[BertSmelik]

Ik probeer HBC aan de praat te krijgen, maar loop tegen een probleem aan:
Ik heb hulp nodig bij het gebruik van cheapest-energy-hours in de marstek-venus-rs485-node-red battery control solution.
Ik heb een dynamishc contract (Van de Bron) en wil graag de batterijen aansturen zodat ze opladen tijdens goedkope uren en energie leveren als de prijzen hoog zijn.
Het lukt me niet om de prijzen in te stellen in de dynamic strategy.
Ik heb de cheapest-energy macro geïnstalleerd en ik vind daar de code om het voor mijn situatie te gebruiken. Maar ik heb geen idee waar ik de gevonden code:

NORDPOOL

use_blueprint:
path: TheFes/energy_price_sensor.yaml
input:
entity_id: sensor.nordpool_ceh_prices
source: nordpool
resolution: 60 # this will give hourly prices, remove the line or set to 15 for quarter-hourly prices
add_vat: 21
add_fixed: 0.023 # the fixed price (including VAT) added by your energy provider
name: Nordpool Cheapest Energy Hours
unique_id: 881b6558-26c6-44bb-81c5-d86c05451bd4

moet plaatsen.
Kan iemand mij de weg wijzen hoe dit te doen?
Alvast bedankt!

[UenJL]

In dit bestand: house_battery_control_config.yaml

[BertSmelik]

UenJL schreef op donderdag 15 januari 2026 @ 16:01:
In dit bestand: house_battery_control_config.yaml

Dankjewel!

Hij staat er nu in.
Kost wel enig schuiven om alles op de goede inspringing te krijgen. In elk geval klaagt HA niet meer!
Ik denk dat ik nu een tijdje moet wachten om inderdaad resultaat te zien.
Nu heb ik "Nordpool (custom)" geselecteerd. Is dat de goeie Tariff data source?

[ Voor 43% gewijzigd door BertSmelik op 15-01-2026 17:20 ]

[Heineken01]

suave1234 schreef op woensdag 14 januari 2026 @ 20:47:
[...]


ik heb hetzelfde, laden is gelukt maar self consumption doet ie niks

Oplossing was bij mij dat ik een Node-red flow was vergeten te importeren Bob zag het in een printscreen die ik had gestuurd Deze ontbrak dus in het rode rechter rijtje.
Presets zijn nu geladen en ontladen met 0 op de meter gaat nu goed.

Presets https://github.com/gitcod...0presets-switch-flow.json

[UenJL]

BertSmelik schreef op donderdag 15 januari 2026 @ 16:55:
[...]

Dankjewel!

Hij staat er nu in.
Kost wel enig schuiven om alles op de goede inspringing te krijgen. In elk geval klaagt HA niet meer!
Ik denk dat ik nu een tijdje moet wachten om inderdaad resultaat te zien.
Nu heb ik "Nordpool (custom)" geselecteerd. Is dat de goeie Tariff data source?

Waarom niet Tibber/Nordpool Core? Als het je gaat om de exacte prijs die je moet betalen dan zou ik Tibber of Nordpool Custom (hier neeem je dan je belasting, handelingsfee etc in op ) nemen maar als het om de schakelmomenten gaat dan is Tibber/Nordpool Core voldoende)

[Duupje1]

Wat doe ik mis, ik krijg 0,0 data uit mijn batterij.
Marstek Venus v2 v153
Elfin ew11

[pascallj]

Duupje1 schreef op vrijdag 16 januari 2026 @ 15:57:
Wat doe ik mis, ik krijg 0,0 data uit mijn batterij.
Marstek Venus v2 v153
Elfin ew11
[Afbeelding]

[Afbeelding]

[Afbeelding]

[Afbeelding]

Kan van alles zijn. Om te beginnen heeft de Local API er niets mee te maken, dus die kan uit. Hoe heb je de Elfin aangesloten op de batterij? Welke kleuren waar? Hoe voedt je de Elfin? Stuur je überhaupt wel commando's naar de Elfin? Zonder commando, krijg je ook geen antwoord. Ik zie namelijk 0 paketten, dus blijkbaar heb je ook geen aanvragen verstuurd.

[suave1234]

Heineken01 schreef op donderdag 15 januari 2026 @ 21:40:
[...]

Oplossing was bij mij dat ik een Node-red flow was vergeten te importeren Bob zag het in een printscreen die ik had gestuurd Deze ontbrak dus in het rode rechter rijtje.
Presets zijn nu geladen en ontladen met 0 op de meter gaat nu goed.

Presets https://github.com/gitcod...0presets-switch-flow.json

[Afbeelding]

die presets was ik ook vergeten....ontdekte ik vanmiddag. Zal even testen of het nu werkt bij mij,

[BertSmelik]

UenJL schreef op vrijdag 16 januari 2026 @ 07:46:
[...]

Waarom niet Tibber/Nordpool Core? Als het je gaat om de exacte prijs die je moet betalen dan zou ik Tibber of Nordpool Custom (hier neeem je dan je belasting, handelingsfee etc in op ) nemen maar als het om de schakelmomenten gaat dan is Tibber/Nordpool Core voldoende)

In beide gevallen krijg geen prijzen (alles staat op 0,0). Ben ik dan te ongeduldig?

Ik heb de Nordpool integratie (versie van HA) geïnstalleerd (geen Tibber, want daar ben ik geen klant van).

Ik heb verder gegraven en de template maakt een entity "Template Sensor" en die heeft wel degelijk prijsinformatie. Geen idee hoe ik dat aan HBC kan koppelen!

Help!

[ Voor 22% gewijzigd door BertSmelik op 16-01-2026 17:40 ]

[suave1234]

@AUijtdehaag ik blijf fouten houden nu ik jouw aangepaste versie erop hebt gezet:

Ik heb die entiteit met number al verwijderd maar er staat ook een rood icoontje bij de nieuwe?!?

[AUijtdehaag]

@suave1234 Klik eens op Marstek m1 battery state of charge (die met het uitroeptekentje
En dan het tandwieltje (instellingen) en dan verwijderen.
Als je dan een nieuwe Marstek m1 battery state of charge hebt, nogmaals erop klikken, tandwieltje en dan refresh (cirkeltje met pijltje)
Dan klopt de entity id weer.

[SatScan]

Duupje1 schreef op vrijdag 16 januari 2026 @ 15:57:
Wat doe ik mis, ik krijg 0,0 data uit mijn batterij.
Marstek Venus v2 v153
Elfin ew11
[Afbeelding]

[Afbeelding]

[Afbeelding]

[Afbeelding]

Misschien de firmware versie ik vermoed dat het vanaf 154 pas echt werkt.

[pascallj]

SatScan schreef op zondag 18 januari 2026 @ 21:31:
[...]


Misschien de firmware versie ik vermoed dat het vanaf 154 pas echt werkt.

Modbus werkt vanaf dag 1 op de V1&2. Al zeker vanaf v147

[superduper1969]

Ik kreek deze reactie op mijn Github, ik heb om dit moment geen tijd om dit te controleren.
De insteek is de nieuwe UPS ModeHeeft iemand hier al ervaring mee?

It sounds a bit crazy, but "Mode" in the Marstek App IS NOT a one-on-one match with the LilyGO's "Marstek User Work Mode" sensor.
The actual Marstek Work Mode is determined by a combination of values of two LilyGO sensors AND ALSO the order in which their states are changed.
The HA sensor doesn't respond as expected unless the states of these two sensors are set in the correct order by the Marstek Battery Control automation, for instance.
It could also explain why the displayed option can change 10 seconds after an HA user input.
I think this may also explain the behaviour of the HA Venus-E User Work Mode Sensor,
Default LilyGO reboot state for "Marstek RS485 Control Mode" (address 43200) )is 21947, "disable".
Default LilyGO reboot state for "Marstek User Work Mode" (address 43000) is now 0
This equates to "UPS" in the Marstek app.
To avoid confusing matters, I'm now using the option numbers for the sensor optionsmap.
It looks like the current Work Mode sensor should be hidden and a new helper must be created for the UI, employing user-friendly option descriptions that match those in the app.
The helper must set the values of addresses 4200 and 4300 when changed in HA and simply display work mode selected in the Marstek if the user selects a different work mode in the app.
I tested this by entering values for the correct sensors in http://lilygo-3-for-marstek.local/ and then observing the change in state after 5 seconds, both on this page and in the app.
To improve responsiveness, I reduced skip_updates from 2 to 1. (5 seconds.) It can also help to reload the app (with a swipe) after seeing the state updating on the web page.
Here are the results of my tests. (It may be necessary to toggle control values to trigger the Marstek mode change.)
RS485 Control Mode "disable" & "Marstek RS485 Control Mode" 0 equals "UPS" in the Marstek App.
If RS485 Control Mode is "disable", then setting "Marstek User Work Mode" to 1 causes "Self Consumption" to be displayed in the Marstek App.
Change "Marstek User Work Mode" to 1 (Set 0 first and then toggle back to 1 if necessary) then change RS485 Control Mode to "enable", to display "Mode" in the App. (Manual Mode, controlled by RS485?)
Change RS485 Control Mode back to "disable", followed by changing "Marstek User Work Mode" to 1 to set "Self Consumption" in the Marstek App.
Set "Marstek User Work Mode" to 2 It's state will flip back to 1) and mode "AI Optimization" will be displayed in the Marstek App.
Only "Marstek User Work Mode" 1 allows RS485 Control Mode to have state "enable". (Manual Mode, controlled by RS485)
Selecting "Manual" in the marstek disables RS485 Control Mode, with the app determining charge/discharge power.

[pascallj]

superduper1969 schreef op maandag 19 januari 2026 @ 13:07:
Ik kreek deze reactie op mijn Github, ik heb om dit moment geen tijd om dit te controleren.
De insteek is de nieuwe UPS ModeHeeft iemand hier al ervaring mee?

It sounds a bit crazy, but "Mode" in the Marstek App IS NOT a one-on-one match with the LilyGO's "Marstek User Work Mode" sensor.
The actual Marstek Work Mode is determined by a combination of values of two LilyGO sensors AND ALSO the order in which their states are changed.
The HA sensor doesn't respond as expected unless the states of these two sensors are set in the correct order by the Marstek Battery Control automation, for instance.
It could also explain why the displayed option can change 10 seconds after an HA user input.
I think this may also explain the behaviour of the HA Venus-E User Work Mode Sensor,
Default LilyGO reboot state for "Marstek RS485 Control Mode" (address 43200) )is 21947, "disable".
Default LilyGO reboot state for "Marstek User Work Mode" (address 43000) is now 0
This equates to "UPS" in the Marstek app.
To avoid confusing matters, I'm now using the option numbers for the sensor optionsmap.
It looks like the current Work Mode sensor should be hidden and a new helper must be created for the UI, employing user-friendly option descriptions that match those in the app.
The helper must set the values of addresses 4200 and 4300 when changed in HA and simply display work mode selected in the Marstek if the user selects a different work mode in the app.
I tested this by entering values for the correct sensors in http://lilygo-3-for-marstek.local/ and then observing the change in state after 5 seconds, both on this page and in the app.
To improve responsiveness, I reduced skip_updates from 2 to 1. (5 seconds.) It can also help to reload the app (with a swipe) after seeing the state updating on the web page.
Here are the results of my tests. (It may be necessary to toggle control values to trigger the Marstek mode change.)
RS485 Control Mode "disable" & "Marstek RS485 Control Mode" 0 equals "UPS" in the Marstek App.
If RS485 Control Mode is "disable", then setting "Marstek User Work Mode" to 1 causes "Self Consumption" to be displayed in the Marstek App.
Change "Marstek User Work Mode" to 1 (Set 0 first and then toggle back to 1 if necessary) then change RS485 Control Mode to "enable", to display "Mode" in the App. (Manual Mode, controlled by RS485?)
Change RS485 Control Mode back to "disable", followed by changing "Marstek User Work Mode" to 1 to set "Self Consumption" in the Marstek App.
Set "Marstek User Work Mode" to 2 It's state will flip back to 1) and mode "AI Optimization" will be displayed in the Marstek App.
Only "Marstek User Work Mode" 1 allows RS485 Control Mode to have state "enable". (Manual Mode, controlled by RS485)
Selecting "Manual" in the marstek disables RS485 Control Mode, with the app determining charge/discharge power.

Nee dit is allemaal oude wijn in nieuwe zakken. Combinatie van hoe de UPS modus werkt samen met die bug die we al heel lang kennen dat er geen modus beschikbaar is voor Modbus Control waardoor het lijkt alsof deze op Anti Feed staat.

Ik zal wel een reactie daar posten.

[dannyro]

pascallj schreef op maandag 19 januari 2026 @ 13:10:
[...]


Nee dit is allemaal oude wijn in nieuwe zakken. Combinatie van hoe de UPS modus werkt samen met die bug die we al heel lang kennen dat er geen modus beschikbaar is voor Modbus Control waardoor het lijkt alsof deze op Anti Feed staat.

Ik zal wel een reactie daar posten.

Zie ik iets over het hoofd? RS485 Control Mode heeft hier bij mij, enable en disable. Dat zijn toch 2 modes?
Als de Control mode enable staat kan ik nog altijd de user mode aanpassen naar wens.

[ Voor 7% gewijzigd door dannyro op 19-01-2026 13:23 ]

[pascallj]

dannyro schreef op maandag 19 januari 2026 @ 13:21:
[...]

Zie ik iets over het hoofd? RS485 Control Mode heeft hier bij mij, enable en disable. Dat zijn toch 2 modes?
Als de Control mode enable staat kan ik nog altijd de user mode aanpassen naar wens.

Met die redenering heeft een apparaat dat zowel aan als uit kan ook twee standen .

Nee maar ik snap waar je gedachte vandaan komt. Je moet RS485 Control mode zien als de 4e modus (naast self-consumption, AI en handmatig). UPS reken ik niet mee, want dat is geen echte modus maar slechts een variant op handmatig. Zet je RS485 Control aan, wordt deze vierde modus geactiveerd, en zet je het uit wordt de laatst gebruikte andere modus weer teruggezet.

Als je de user mode verandert nadat je RS485 control hebt aangezet, wordt RS485 control gewoon weer uitgezet (want die modus is dan dus niet meer actief).

Hier is mijn lange Engelstalige reactie met de technische details op de reactie die bedoeld werd:

https://github.com/Superd...5#issuecomment-3768113365

[ Voor 7% gewijzigd door pascallj op 19-01-2026 13:37 ]

[SatScan]

pascallj schreef op maandag 19 januari 2026 @ 13:36:
[...]


Met die redenering heeft een apparaat dat zowel aan als uit kan ook twee standen .

Nee maar ik snap waar je gedachte vandaan komt. Je moet RS485 Control mode zien als de 4e modus (naast self-consumption, AI en handmatig). UPS reken ik niet mee, want dat is geen echte modus maar slechts een variant op handmatig. Zet je RS485 Control aan, wordt deze vierde modus geactiveerd, en zet je het uit wordt de laatst gebruikte andere modus weer teruggezet.

Als je de user mode verandert nadat je RS485 control hebt aangezet, wordt RS485 control gewoon weer uitgezet (want die modus is dan dus niet meer actief).

Hier is mijn lange Engelstalige reactie met de technische details op de reactie die bedoeld werd:

https://github.com/Superd...5#issuecomment-3768113365

Top reactie! Helemaal mee eens!

[savale]

Hier nog in afwachting van Stedin die mijn slimme meter gaat vervangen voor een exemplaar die 1seconde updates geeft op de p1 poort in plaats van iedere 10 seconden. Ze gaan dat kosteloos doen, dus moet maar niet klagen dat ik al 2 maanden wacht.

Enige ding is dat de venus 3 echt voor geen meter naar nul regelt met laden / ontladen met 10 seconden updates. Ik zit te denken aan een tijdelijk workaround.

Wat er nu gebeurd met een voorbeeld verbruik van 400 watt:
De accu stuurt dan wel mooi naar 400 watt ontladen, maar vervolgens komt er geen feedback. De accu ziet nog steeds een verbruik van 400watt, dus hij gaat in stapjes met een hogere stroom ontladen. Vervolgens komt de p1 update, dan regelt de accu terug want hij ziet een negatief verbruik, maar er komt weer geen feedback....
Je ziet uiteindelijk een flinke slingerbeweging. Voor zover ik weet kan ik het algoritme van marstek niet aanpassen om wat langzamer te regelen?

Ik gebruik nu een CT simulator die nu de p1 data uit home assistant gebruikt. Ik zit er nu als workaround aan te denken om iedere seconde toch een CT waarde aan te gaan leveren op basis van de laatst gemeten p1 waarde en zolang er geen nieuwe p1 update komt de ontlaad / laad waarde van accu hierbij te tellen.

Dus stel de beginsituatie: 400 watt verbruik, accu gaat 390 watt onladen, dan is mijn volgende CT waarde:
oude P1 waarde - oude ontlaad waarde + verschil oude ontlaadwaarde - huidige ontlaadwaarde.

400 - 0 + (0-390) = CT waarde 10
stel dan komt nieuwe P1 en accu gaat 400 watt ontladen
10 - 390 + (390-400) = CT waarde 0....

Zal niet zo mooi werken als 1 seconde updates omdat ik de werkelijke p1 waarde niet weet, maar de regeling gaat hopelijk dan wel rustiger werken.
Nu nog uitvinden hoe ik dit in een automation / sensor template kan stoppen... Tips zijn welkom!

[pascallj]

savale schreef op maandag 19 januari 2026 @ 13:59:
Hier nog in afwachting van Stedin die mijn slimme meter gaat vervangen voor een exemplaar die 1seconde updates geeft op de p1 poort in plaats van iedere 10 seconden. Ze gaan dat kosteloos doen, dus moet maar niet klagen dat ik al 2 maanden wacht.

Enige ding is dat de venus 3 echt voor geen meter naar nul regelt met laden / ontladen met 10 seconden updates. Ik zit te denken aan een tijdelijk workaround.

Wat er nu gebeurd met een voorbeeld verbruik van 400 watt:
De accu stuurt dan wel mooi naar 400 watt ontladen, maar vervolgens komt er geen feedback. De accu ziet nog steeds een verbruik van 400watt, dus hij gaat in stapjes met een hogere stroom ontladen. Vervolgens komt de p1 update, dan regelt de accu terug want hij ziet een negatief verbruik, maar er komt weer geen feedback etc....

Voor zover ik weet kan ik het algoritme van marstek niet aanpassen?

Ik gebruik hiervoor nu een CT simulator die nu de p1 data uit home assistant gebruikt. Ik zit er nu als workaround aan te denken om iedere seconde toch een CT waarde aan te gaan leveren op basis van de laatst gemeten p1 waarde en zolang er geen nieuwe p1 update komt de ontlaad / laad waarde van accu hierbij te tellen.

Dus stel de beginsituatie: 400 watt verbruik, accu gaat 390 watt onladen, dan is mijn volgende CT waarde:
oude P1 waarde - oude ontlaad waarde + verschil oude ontlaadwaarde - huidige ontlaadwaarde.

400 - 0 + (0-390) = CT waarde 10
stel dan komt nieuwe P1 en accu gaat 400 watt ontladen
10 - 390 + (390-400) = CT waarde 0....

Zal niet zo mooi werken als 1 seconden updates omdat ik de werkelijke p1 waarde niet weet, maar de regeling gaat hopelijk dan wel rustiger werken.
Nu nog uitvinden hoe ik dit in een automation / sensor template kan stoppen... Tips zijn welkom!

Is dit niet precies waar de CT Poll Rate optie voor bedoeld is die je kan laten aanpassen door Marstek? Weet niet zeker of je het daar al een keer over gehad hebt.

[savale]

pascallj schreef op maandag 19 januari 2026 @ 14:01:
[...]


Is dit niet precies waar de CT Poll Rate optie voor bedoeld is die je kan laten aanpassen door Marstek? Weet niet zeker of je het daar al een keer over gehad hebt.

Ja dat is misschien een idee, maar omdat het tijdelijk is, wil ik support er eigenlijk liever niet mee lastig vallen. Goede kans dat het over een paar weken/maanden weer terug naar 1 seconde moet...
Het voor nu even zelf fiksen lijkt me dan veiliger / beter. De CT poll rate kunnen we niet via rs485 aanpassen toevallig?

[ Voor 5% gewijzigd door savale op 19-01-2026 14:07 ]

[SatScan]

savale schreef op maandag 19 januari 2026 @ 14:03:
[...]


Ja dat is misschien een idee, maar omdat het tijdelijk is, wil ik support er eigenlijk liever niet mee lastig vallen. Goede kans dat het over een paar weken/maanden weer terug naar 1 seconde moet...
Het voor nu even zelf fiksen lijkt me dan veiliger / beter. De CT poll rate kunnen we niet via rs485 aanpassen toevallig?

Als je HA heb draaien zou ik deze eens proberen https://github.com/gitcod...de-red?tab=readme-ov-file

Werkt uitstekend en is een stuk 'slimmer' dan de standaard regeling ook bij langzamere p1 updates!

[SatScan]

Heineken01 schreef op donderdag 15 januari 2026 @ 21:40:
[...]

Oplossing was bij mij dat ik een Node-red flow was vergeten te importeren Bob zag het in een printscreen die ik had gestuurd Deze ontbrak dus in het rode rechter rijtje.
Presets zijn nu geladen en ontladen met 0 op de meter gaat nu goed.

Presets https://github.com/gitcod...0presets-switch-flow.json

[Afbeelding]

Heineken... oke

[Filip91]

Beste,

Momenteel draait mijn Marstek V2 gewoon NOM (Self-consumption mode). Ik overweeg echter om mij te verdiepen in Home Assistant, om de batterij en mogelijks laadpaal (nog aan te kopen) beter aan te sturen. Voldoende zonnepanelen aanwezig.

Ondanks de zeer goede samenvatting op de eerste pagina, zie ik het bos niet meer door de bomen. Welke oplossing is de "beste" voor de Marstek V2 (Lilygo en connectors), of maakt de keuze van modbus oplossing niet echt iets uit?


In het lang:
Doel van sturing Marstek is om NOM te draaien, zij het enkel door te laden met zonne-energie op de meest optimale ogenblikken, geen inkoop op goedkope momenten.
Doel van sturing laadpaal: opladen met resterende overtollige zonne-energie.

Meer concreet zou ik onderstaande willen automatiseren, waarvan ik hoop dat dit via Home assistant kan.
1) 5h-10h: Marstek enkel laten ontladen om gebruik te compenseren MAAR niet opladen als verwachtte opbrengt zonnepanelen voldoende hoog is die dag. Reden: om te voorkomen dat Marstek reeds begint te laten met eerste zonneoverschot (lage efficiëntie), wanneer injectieprijzen in de ochtend bovendien vaak de duurder zijn.

Bv door de Marstek standaard in Self-consumption mode te plaatsen (=discharge als er te weinig zonne-energie is), en te schakelen naar manual zonder planning (=uitschakelen) van zodra er tussen 5h-10h meer zonneopbrengst dan verbruik is (bv door te monitoren wanneer de Marstek wil laden).

2) Vanaf 10h: Auto opladen met enkel zonne-energie, waarbij het opladen van de Marstek prioriteit zou moeten krijgen. Indien de batterij vol is lijkt dit me vrij eenvoudig, idealiter start het laden ook al wanneer de Marstek aan vol vermogen aan het laden is (Indien er bv slechts 3kwh zonne-energie beschikbaar is, is het mogelijks zelfs interessanter om het oplaadvermogen van de Marstek wat te verlagen, zodat het laden al van start kan gaan [vanaf 1.4kwh]).

Indien dit mogelijk is, zijn alle andere tips ook meer dan welkom (eg hardware om Home Assistant te draaien of kan dit prima op mijn Synology NAS, interessante laadpalen om naar te kijken, etc...).

[AUijtdehaag]

@Filip91
V2 kan je een m5stack (zie mijn adv) voor kopen of als je al een lilygo hebt die gebruiken.
Op mijn github staat code voor beide
Voor m5stack en lilygo kan je modbus tcp code erop zetten of de standaard esphome code

Dan ga je aan de gang met de nodered code van Bob (2 post boven je staat de link)

Ik draai HA en nodered (HA addon) op een odroid c4 (sos solutions heeft kant en klare HA oplossingen eventueel, anders zelf een emmc usb writer erbij kopen)
Dat emmc (64 gb aanbevolen) overleeft stroomstoringen zonder problemen (raar om dat in dit topic op te merken)
Vanwege het emmc kaartje gaat dat gewoon verder waar het gebleven was.

Ik kan wel voorspellen dat het toekomstige weerbericht er ook nog in verwerkt gaat worden in die nodered flow.
De programmeur van die code gaat stapje voor stapje steeds verder met verschillende stategien en is erg bedreven. Je kan je wensen laten blijken op de discord server.
Draait hier al volledig op dynamisch laden en ontladen met een V1, V2 en V3 op de beste uren

[ Voor 12% gewijzigd door AUijtdehaag op 20-01-2026 22:48 ]

[Heineken01]

@AUijtdehaag , na update van v1.0 => v1.3 krijg ik bovenstaande. Als ik de v1.0 weer terugzet voor Accu 1, doet deze het weer keurig. Wat doe ik niet goed? Ik heb de codes vergeleken, maar zie niet waar het 123 mis kan gaan. Bedankt alvast.

[AUijtdehaag]

@Heineken01
Heb je wel de goede branch? Er zijn er nu 3. Main is V3, v12 is V1/V2 en Venus-A is venus A

34002 was SOC met 1 cijfer achter de komma in % (nieuw)
32104 was SOC met hele getallen (oude)
op de V3
Wellicht kent jouw marstek dan geen 34002 (v1 en V2 kent dat register niet)
Beide staan nog in v1.3 dus kan je uitcommenten.

Welke firmware heb je op de v3?
V144 of v146?

[ Voor 11% gewijzigd door AUijtdehaag op 26-01-2026 22:41 ]

[sun62]

Heb nog een handig modbus tooltje gemaakt om registers te testen zonder dat je vaak moet herstarten.
https://flows.nodered.org...7358c45281e10b83a8fc65744

[ Voor 151% gewijzigd door sun62 op 26-01-2026 22:49 ]

[Heineken01]

AUijtdehaag schreef op maandag 26 januari 2026 @ 22:30:
@Heineken01
Heb je wel de goede branch? Er zijn er nu 3. Main is V3, v12 is V1/V2 en Venus-A is venus A

34002 was SOC met 1 cijfer achter de komma in % (nieuw)
32104 was SOC met hele getallen (oude)
op de V3
Wellicht kent jouw marstek dan geen 34002 (v1 en V2 kent dat register niet)
Beide staan nog in v1.3 dus kan je uitcommenten.

Welke firmware heb je op de v3?
V144 of v146?

Bedankt voor de juiste richting. Inderdaad via uitcommenten gelukt.
Ik heb 2x 146 en 1x 146.3 firmware, op alle 3 zelfde resultaat voor het uitcommenten.

[AUijtdehaag]

@Heineken01
Ik zou ook de laatste versie van cheapest hours niet naar 7.2.1 brengen. Er werd bij mij niet ge-update van de nieuwe dag.
Heb hem terug kunnen zetten naar 7.2.0 via hacs

[savale]

Wellicht nog leuk voor iemand die in hetzelfde schuitje als ik zit: ik wacht nog op de plaatsing van een nieuwe slimmer meter met 1 seconde updates. Tot die tijd gebruik ik deze automation om de regeling van het ontladen wat rustig te houden. Wat het doet: stel je verbruikt 1000 watt. Dan geeft deze aan de accu een hele lage waarde door (maar net hoe zwaar je filtert, maar zeg 50 watt). Maar omdat de p1 updates maar iedere 10 seconde komen, regelt de accu in die 10 seconden bijvoorbeeld naar 500 watt ontladen. Dan komt de p1 met 500 watt. Dan geeft het script voor 10 seconden 25 watt. accu regelt naar 750watt etc etc....
Dit is wel een hele "slome" regeling, maar het werkt best aardig. Enkel negeert hij nu dingen als een quooker die aanslaat voor 20 seconden.
Nu ik dit zo opschrijf zou ik liever een wat sneller reagerend filter hebben denk ik zelf, maar daar moet ik nog even mee gaan experimenteren

code:

alias: _dsmrsecfake
description: ""
triggers:
  - trigger: state
    entity_id:
      - sensor.electricity_meter_power_consumption
  - trigger: state
    entity_id:
      - sensor.electricity_meter_power_production
conditions:
  - condition: numeric_state
    entity_id: sensor.electricity_meter_power_consumption
    above: 0
actions:
  - action: input_number.set_value
    metadata: {}
    target:
      entity_id: input_number.dsmrsecfake
    data_template:
      value: >-
        {{ ((states('sensor.electricity_meter_power_consumption') | float) * 40)
        | int }}
  - delay:
      hours: 0
      minutes: 0
      seconds: 2
      milliseconds: 0
  - action: input_number.set_value
    metadata: {}
    data_template:
      value: >-
        {{ ((states('sensor.electricity_meter_power_consumption') | float) * 20)
        | int }}
    target:
      entity_id: input_number.dsmrsecfake
mode: single

[Z900]

Hoi,
Heb het al in diverse FB groepen gevraagd maar schijnbaar weet niemand 't antwoord (of willen niet antwoorden)
Kun je nou via het bekende Venus V3 Modbus dashboard (in HA) de weergave zo maken dat je kan zien in een grafiek hoeveel energie er is gegaan van de batterij naar het huis (eigenverbruik) EN terug naar 't net.
Alsmede hoe de batterij is opgeladen: wat komt van het lichtnet en wat van de zonnepanelen?

Mag ook in een ander dashboard of als iemand een andere oplossing heeft.

Of kun je de scheiding zonnepanelen/lichtnet niet maken voor battery opladen ?

[pascallj]

Z900 schreef op dinsdag 27 januari 2026 @ 20:07:
Hoi,
Heb het al in diverse FB groepen gevraagd maar schijnbaar weet niemand 't antwoord (of willen niet antwoorden)
Kun je nou via het bekende Venus V3 Modbus dashboard (in HA) de weergave zo maken dat je kan zien in een grafiek hoeveel energie er is gegaan van de batterij naar het huis (eigenverbruik) EN terug naar 't net.
Alsmede hoe de batterij is opgeladen: wat komt van het lichtnet en wat van de zonnepanelen?

Mag ook in een ander dashboard of als iemand een andere oplossing heeft.

Of kun je de scheiding zonnepanelen/lichtnet niet maken voor battery opladen ?

Ja hoor dat kan zeker. Is gewoon een kwestie van P1 data vergelijken met data uit de batterij. En dan die twee met elkaar verrekenen. Als de batterij gaat opladen en je P1 is positief, ben je blijkbaar aan het laden van het net. Is het negatief, heb je blijkbaar genoeg overschot. Je weet hoeveel de batterij aan het laden is, dus de rest is je huisverbruik.
Als de batterij gaat ontladen en je P1 is positief, verbruik je blijkbaar meer stroom dan de batterij kan leveren. Is de P1 negatief, lever je een overschot terug en is je huisverbruik dus het verschil van die twee. Etc.

Het HA energie dashboard rekent dit standaard voor je uit per uur als je aangeeft waar het de data kan vinden.

Je zit natuurlijk wel met betrouwbaarheid van de data. De P1 data mag je vanuit gaan dat die nauwkeurig is. De Marstek is op hoge vermogens redelijk nauwkeurig, op lage minder. Daarbij heb je natuurlijk ook verschil tussen wanneer de data wordt opgevraagd. Als je elke 5 seconde de data opvraagt, kan het zijn dat er in die 5 seconde verschil zit tussen wat de P1 doorgeeft en wat de batterij doorgeeft als ze bijvoorbeeld 2 seconde van elkaar verschoven zitten. Je vergelijkt dus mogelijk data met elkaar dat 4,9999 etc. verschilt met de werkelijkheid etc. Dus je moet altijd wel een beetje met gespleten ogen kijken, of er een filter overheen leggen wat de boel een beetje middelt.

[andypieters]

Ik heb een Marstek Venus v2 met een lilygo al een aantal maanden draaien in home assistant via esp home. Alleen altijd als de accu leeg is, is de lilygo uitgeschakeld. Ook als ik via de Forcible Charge/Discharge hem op stop zet schakelt de lilygo uit.

Hierdoor kan ik niet via de modbus sturen wanneer hij weer op moet laden.

De 5v aansluiting op de lilygo heb ik al via een usb-a kabel via een usb adapter aangesloten, want via de 5v aansluiting op de modbus kabel start de lilygo ook helemaal niet op.

Wanneer de marstek actief is werkt alles wel gewoon.

Is dit normaal gedrag? Of is er iets wat ik er aan kan doen?
Het zou fijn zijn als ik wanneer de marstek leeg is, ik hem via de modbus kan laten laden.

[pascallj]

andypieters schreef op dinsdag 27 januari 2026 @ 20:44:
Ik heb een Marstek Venus v2 met een lilygo al een aantal maanden draaien in home assistant via esp home. Alleen altijd als de accu leeg is, is de lilygo uitgeschakeld. Ook als ik via de Forcible Charge/Discharge hem op stop zet schakelt de lilygo uit.

Hierdoor kan ik niet via de modbus sturen wanneer hij weer op moet laden.

De 5v aansluiting op de lilygo heb ik al via een usb-a kabel via een usb adapter aangesloten, want via de 5v aansluiting op de modbus kabel start de lilygo ook helemaal niet op.

Wanneer de marstek actief is werkt alles wel gewoon.

Is dit normaal gedrag? Of is er iets wat ik er aan kan doen?
Het zou fijn zijn als ik wanneer de marstek leeg is, ik hem via de modbus kan laten laden.

Zit die USB adapter dan soms in het backup-stopcontact? Dat schakelt uit als de batterij leeg is, dus dan valt de LilyGo ook uit. Als je deze gewoon op een los stopcontact direct op het net aansluit, zal het moeten blijven werken.

[andypieters]

pascallj schreef op dinsdag 27 januari 2026 @ 20:47:
[...]


Zit die USB adapter dan soms in het backup-stopcontact? Dat schakelt uit als de batterij leeg is, dus dan valt de LilyGo ook uit. Als je deze gewoon op een los stopcontact direct op het net aansluit, zal het moeten blijven werken.

OMG

Wat stom dat ik dat nooit geprobeerd heb zeg haha. Ik ging er eigenlijk van uit dat het backup stopcontact gewoon op pass trough zou staan.

Maar thnx hij doet het nu inderdaad!

[pascallj]

andypieters schreef op dinsdag 27 januari 2026 @ 20:53:
[...]


OMG

Wat stom dat ik dat nooit geprobeerd heb zeg haha. Ik ging er eigenlijk van uit dat het backup stopcontact gewoon op pass trough zou staan.

Maar thnx hij doet het nu inderdaad!

Het stopcontact staat anders aan wanneer de omvormer in gebruik is ook al heb je die optie niet aan gezet. Vandaar dat het anders ook werkte, maar zodra je op stop zet, staat de battery ik stand-by en werkt dat dus ook niet meer:

[Z900]

pascallj schreef op dinsdag 27 januari 2026 @ 20:35:
[...]


Ja hoor dat kan zeker. Is gewoon een kwestie van P1 data vergelijken met data uit de batterij. En dan die twee met elkaar verrekenen. Als de batterij gaat opladen en je P1 is positief, ben je blijkbaar aan het laden van het net. Is het negatief, heb je blijkbaar genoeg overschot. Je weet hoeveel de batterij aan het laden is, dus de rest is je huisverbruik.
Als de batterij gaat ontladen en je P1 is positief, verbruik je blijkbaar meer stroom dan de batterij kan leveren. Is de P1 negatief, lever je een overschot terug en is je huisverbruik dus het verschil van die twee. Etc.
Het HA energie dashboard rekent dit standaard voor je uit per uur als je aangeeft waar het de data kan vinden.

Je zit natuurlijk wel met betrouwbaarheid van de data. De P1 data mag je vanuit gaan dat die nauwkeurig is. De Marstek is op hoge vermogens redelijk nauwkeurig, op lage minder. Daarbij heb je natuurlijk ook verschil tussen wanneer de data wordt opgevraagd. Als je elke 5 seconde de data opvraagt, kan het zijn dat er in die 5 seconde verschil zit tussen wat de P1 doorgeeft en wat de batterij doorgeeft als ze bijvoorbeeld 2 seconde van elkaar verschoven zitten. Je vergelijkt dus mogelijk data met elkaar dat 4,9999 etc. verschilt met de werkelijkheid etc. Dus je moet altijd wel een beetje met gespleten ogen kijken, of er een filter overheen leggen wat de boel een beetje middelt.

MAAR: hoe kun je "bereken" wat van de zonnepanelen OF van het lichtnet in de batterij is gegaan ?
Sorry, maar dat zie ik even niet in hoe dat te ondervangen is !? Of zie ik nu spoken......

[pascallj]

Z900 schreef op dinsdag 27 januari 2026 @ 21:20:
[...]


MAAR: hoe kun je "bereken" wat van de zonnepanelen OF van het lichtnet in de batterij is gegaan ?
Sorry, maar dat zie ik even niet in hoe dat te ondervangen is !? Of zie ik nu spoken......

Ik vrees dat je gelijk hebt! Ik weet niet waar ik zat met mijn hoofd, had denk ik honger . Je kunt inderdaad niet zien wat van de panelen komt en wat je huisverbruik is. Je hebt natuurlijk dan twee variabelen. Je zal op een of andere manier ook inzicht moeten krijgen in of je totale huisverbruik, of in de zonnepanelen.

[ Voor 9% gewijzigd door pascallj op 27-01-2026 21:24 ]

[andypieters]

Z900 schreef op dinsdag 27 januari 2026 @ 21:20:
[...]


MAAR: hoe kun je "bereken" wat van de zonnepanelen OF van het lichtnet in de batterij is gegaan ?
Sorry, maar dat zie ik even niet in hoe dat te ondervangen is !? Of zie ik nu spoken......

Het gaat well een beetje off topic hier. Maar dat kun je niet berekenen, tenzij je los meet wet de zonnepanelen opbrengen en wat de batterij in/uit gaat.
Ik heb dat zelf met een homewizard energy socket gedaan op de marstek. Mijn zonnepanelen meet lk met een kwh meter, ook van home wizard.

Je zou het ook via modbus uit kunnen lezen, maar rechtstreeks op het stopcontact heb je de meest accurate meting.

Belangrijkste is dat je voor alle 3 de bronnen data hebt.
Daarna kan je dat in het energy dashboard instellen.

[Z900]

andypieters schreef op dinsdag 27 januari 2026 @ 21:33:
[...]

Het gaat well een beetje off topic hier. Maar dat kun je niet berekenen, tenzij je los meet wet de zonnepanelen opbrengen en wat de batterij in/uit gaat.
Ik heb dat zelf met een homewizard energy socket gedaan op de marstek. Mijn zonnepanelen meet lk met een kwh meter, ook van home wizard.

Je zou het ook via modbus uit kunnen lezen, maar rechtstreeks op het stopcontact heb je de meest accurate meting.

Belangrijkste is dat je voor alle 3 de bronnen data hebt.
Daarna kan je dat in het energy dashboard instellen.

Dat heb ik allemaal precies zo wat jij bezit.
Maar ik denk dat het standaard dashboard voor de V3 Modbus dat niet kan, je zult iig berekeningen moeten maken (per minuut/5min oid) en daar een grafiek van produceren.
Helaas kan ik niet overweg met formules in HA

PS: dan nog steeds niet overtuigd of het werkelijk te realiseren is......

[ Voor 4% gewijzigd door Z900 op 27-01-2026 22:24 ]

[andypieters]

Z900 schreef op dinsdag 27 januari 2026 @ 22:23:
[...]


Dat heb ik allemaal precies zo wat jij bezit.
Maar ik denk dat het standaard dashboard voor de V3 Modbus dat niet kan, je zult iig berekeningen moeten maken (per minuut/5min oid) en daar een grafiek van produceren.
Helaas kan ik niet overweg met formules in HA

PS: dan nog steeds niet overtuigd of het werkelijk te realiseren is......

Ik weet niet precies wat je bedoeld.
Deze grafiek krijg je zodra je een 'individuele gebruiker' toevoegt in het energy dashboard.


En deze grafiek als je ook bij elke bron een 'vermogen' sensor hebt ingesteld.

[Z900]

andypieters schreef op dinsdag 27 januari 2026 @ 23:43:
[...]
Ik weet niet precies wat je bedoeld.

Simpel gezegd: hoeveel vermogen komt van de zon en hoeveel van t lichtnet als de accu van leeg naar vol geladen is ? (dat grafisch zichtbaar in KWh)

Grafiek bij jouw "Energiestroom" lijkt idd te voldoen (er zijn echter geen percentages bij vermeld, maar de breedte van de kleurbalken zijn bepalend denk ik). Dank iig !

PS: waar/hoe voeg ik een individuele gebruiker toe ? (sorry niet goed thuis nog in HA)

[ Voor 29% gewijzigd door Z900 op 28-01-2026 00:24 ]

[De Senaat]

Z900 schreef op dinsdag 27 januari 2026 @ 22:23:
PS: dan nog steeds niet overtuigd of het werkelijk te realiseren is......

Dit is zoals ik het heb weergegeven.
Per uur zie je 2 kolommen. De linker kolom geeft het verbruik weer op basis van de meterstanden van de slimme meter. De rechterkolom geeft aan wat de opwek van de 3 afzonderlijke omvormers is geweest.
Het verschil tussen het netto verbruik in de linker kolom en de bruto opwek in de rechter kolom is het eigenverbruik wat daar dan ook rechts wordt weergegeven.
Dit allemaal op basis van meterstanden van de omvormers die 1x per uur worden vastgelegd.
Je kunt hier nu al wel de werking van de batterij uit halen, maar ik moet nog iets inbouwen dat ook het resterend vermogen (bat_capacity) van de MT 1x per uur wordt vastgelegd. Vervolgens wordt dat dan ook nog zichtbaar gemaakt in de rechter kolom als extra energiebron onderaan, of als extra verbruiker bovenaan in die kolom.

PS. Ik werk niet met HA dus kan je daar ook niet meer over vertellen, maar het inzichtelijk maken kan dus wel volgens mij.

[dannyro]

Z900 schreef op woensdag 28 januari 2026 @ 00:19:
[...]


Simpel gezegd: hoeveel vermogen komt van de zon en hoeveel van t lichtnet als de accu van leeg naar vol geladen is ? (dat grafisch zichtbaar in KWh)

Grafiek bij jouw "Energiestroom" lijkt idd te voldoen (er zijn echter geen percentages bij vermeld, maar de breedte van de kleurbalken zijn bepalend denk ik). Dank iig !

PS: waar/hoe voeg ik een individuele gebruiker toe ? (sorry niet goed thuis nog in HA)

In HA zit een standaard energie dashboard. Daar moet je rechts op het potloodje klikken, dan krijg je een scherm waar jij de juiste entiteiten van je gegevensbronnen moet inzetten. Dan krijg je dit...Een modbus dashboard bestaat niet of je moet het zelf maken.

[ Voor 19% gewijzigd door dannyro op 28-01-2026 09:30 ]

[Z900]

dannyro schreef op woensdag 28 januari 2026 @ 09:25:
[...]

In HA zit een standaard energie dashboard. Daar moet je rechts op het potloodje klikken, dan krijg je een scherm waar jij de juiste entiteiten van je gegevensbronnen moet inzetten. Dan krijg je dit...Een modbus dashboard bestaat niet of je moet het zelf maken.[Afbeelding]

Er zijn voor zover ik weet 2 " MODBUS Venus V3" dashboards uitgebracht (via HACS),

Dat bovenste overzichtsgrafiekje (links) en dan het zonnepaneel deel ervan dat heb ik ook en dat is mooi, maar dan bedoel ik met mijn verhaal dat je bij die 3 lijntjes apart de KWh waarde bij vermeld krijgt (zoals in mijn bijgevoegde voorbeeld afbeelding)


Nog even over nagedacht maar wat ik wil verwezelijken kan echt niet denk ik :
Neem de Zonnepanelen, die leveren OF stroom aan het lichtnet OF aan de batterij OF aan het eigenverbruik.
Nu zit er bij mij 1 KWh meter tussen zonnepanelen en het lichtnet dat is de gezamelijk stroom naar de bovengenoemde 3 punten. Kun je volgens mij niet opsplitsen in 3 aparte metingen.
Evt. te berekenen, wat ik nog steeds niet voor me zie...Helaas kan ik nog niet overweg met formules in HA, andes had ik het kunnen testen.

[ Voor 20% gewijzigd door Z900 op 28-01-2026 13:15 ]

[andypieters]

Z900 schreef op woensdag 28 januari 2026 @ 12:39:
[...]


Er zijn voor zover ik weet 2 " MODBUS Venus V3" dashboards uitgebracht (via HACS),

Dat bovenste overzichtsgrafiekje (links) en dan het zonnepaneel deel ervan dat heb ik ook en dat is mooi, maar dan bedoel ik met mijn verhaal dat je bij die 3 lijntjes apart de KWh waarde bij vermeld krijgt (zoals in mijn bijgevoegde voorbeeld afbeelding)
[Afbeelding]

Nog even over nagedacht maar wat ik wil verwezelijken kan echt niet denk ik :
Neem de Zonnepanelen, die leveren OF stroom aan het lichtnet OF aan de batterij OF aan het eigenverbruik.
Nu zit er bij mij 1 KWh meter tussen zonnepanelen en het lichtnet dat is de gezamelijk stroom naar de bovengenoemde 3 punten. Kun je volgens mij niet opsplitsen in 3 aparte metingen.
Evt. te berekenen, wat ik nog steeds niet voor me zie...Helaas kan ik nog niet overweg met formules in HA, andes had ik het kunnen testen.

In de energiestroom grafiek kan je dat wel zien als je er met je muis op gaat staan.

Om deze te krijgen moet je minimaal 1 individueel apparaat opgeven in de instellingen van je energiedashboard.
Dus bij energiedashboard, potloodje en bij individuele apparaten een apparaat toevoegen die een kwh sensor heeft. Dit mag niet je batterij of de zonnepanelen zijn, want die heb je al.
Ik heb zelf de CT002 apart op een home wizard socket zitten, om deze uit en aan te kunnen zetten wanneer deze is vastgelopen.

[Z900]

andypieters schreef op woensdag 28 januari 2026 @ 13:34:
[...]
Dus bij energiedashboard, potloodje en bij individuele apparaten een apparaat toevoegen die een kwh sensor heeft. Dit mag niet je batterij of de zonnepanelen zijn, want die heb je al.

[EDIT] : SUPER ! Ik heb de HW kWh meter toegevoegd als individueel apparaat (stroom import),
en ja hoor geweldig, eindelijk inzichtelijk ! Super man !
Nu nog een neven vraagje: kun je deze energiestroom ook als enige grafiek laten tonen in HA ?

Mmm OK, ik heb:

1. HW kWh meter tussen zonnepanelen en het lichtnet
2. HW Energy socket tussen batterij en lichtnet
3. 2x P1 meter (ZP en HW)
4. en dan kan ik nog de SolarEdge omvormer uitlezen...

Is hier 1 geschikt van ?

[ Voor 18% gewijzigd door Z900 op 28-01-2026 15:44 ]

[LodeBo]

Als mijn batterijen een paar dagen niet geladen hebben zakken ze ongeveer 1% per dag. Nu krijg ik wel een melding van HA en laden ze automatisch bij maar dit kan toch niet de bedoeling zijn.

Wat me ook is opgevallen is dat wanneer ik de batterijen op handmatig zet, het stand-by verbruik 0W is. Zet ik ze terug op zelf geïnitieerd dan is het stand-by verbruik 7W.
Dat verklaart misschien wel die één procent per dag maar is dit normaal?

[pascallj]

LodeBo schreef op woensdag 28 januari 2026 @ 17:26:
Als mijn batterijen een paar dagen niet geladen hebben zakken ze ongeveer 1% per dag. Nu krijg ik wel een melding van HA en laden ze automatisch bij maar dit kan toch niet de bedoeling zijn.

Wat me ook is opgevallen is dat wanneer ik de batterijen op handmatig zet, het stand-by verbruik 0W is. Zet ik ze terug op zelf geïnitieerd dan is het stand-by verbruik 7W.
Dat verklaart misschien wel die één procent per dag maar is dit normaal?

Ja hoor dat is normaal. Een deel van de stroom gebruikt door de elektronica komt uit de batterij en een deel komt uit het net. Als je het backup-stopcontact aan hebt staan is het sowieso hoger want dan kan komt in veel gevallen al het verbruik uit de batterij.

[AUijtdehaag]

andypieters schreef op dinsdag 27 januari 2026 @ 20:53:
[...]


OMG

Wat stom dat ik dat nooit geprobeerd heb zeg haha. Ik ging er eigenlijk van uit dat het backup stopcontact gewoon op pass trough zou staan.

Maar thnx hij doet het nu inderdaad!

Ik haal de 5V voor mijn M5stack atom s3 rs485 base gewoon uit de modbus stekker. Zie topicstart

[LodeBo]

pascallj schreef op woensdag 28 januari 2026 @ 17:30:
[...]


Ja hoor dat is normaal. Een deel van de stroom gebruikt door de elektronica komt uit de batterij en een deel komt uit het net. Als je het backup-stopcontact aan hebt staan is het sowieso hoger want dan kan komt in veel gevallen al het verbruik uit de batterij.

Ik ben niet duidelijk geweest denk ik.
Voordat ik die automation had in HA bleven ze gewoon zakken tot ver onder de 11%. Normaal zouden ze toch automatisch moeten bijladen als ze onder de 11% komen?

[andypieters]

AUijtdehaag schreef op woensdag 28 januari 2026 @ 17:34:
[...]

Ik haal de 5V voor mijn M5stack atom s3 rs485 base gewoon uit de modbus stekker. Zie topicstart

Dat heb ik ook geprobeerd, maar dan start hij helemaal niet op bij mij.
Ik heb ook gemeten wat voor spanning er op die draden staat en dat was erg weinig, het is al een tijdje geleden maar ik dacht iets van 2.7 volt ofzo

Vervolgens kwam ik er achter dat als ik de usb-c aansluiting op de lilygo aan een adapter hing dat hij wel werkte.
Daarna heb ik zelf 5 volt op de 5 volt ingang van de lilygo gezet via een usb kabeltje en toen werkte het.

[pascallj]

LodeBo schreef op woensdag 28 januari 2026 @ 17:36:
[...]


Ik ben niet duidelijk geweest denk ik.
Voordat ik die automation had in HA bleven ze gewoon zakken tot ver onder de 11%. Normaal zouden ze toch automatisch moeten bijladen als ze onder de 11% komen?

Ah zo, dat klopt. Heb je een V1/2 of V3? Bij een V1/2 t/m BMS v215 was het vanaf lager dan 11 procent meteen naar 0 procent en dan laden tot '11', wat in de praktijk geen 11 was natuurlijk. Vanaf BMS 216 is dat niet meer zo en dat is ook niet erg.

Hoe het gedrag bij de V3 is en was weet ik niet precies.

[LodeBo]

pascallj schreef op woensdag 28 januari 2026 @ 18:11:
[...]


Ah zo, dat klopt. Heb je een V1/2 of V3? Bij een V1/2 t/m BMS v215 was het vanaf lager dan 11 procent meteen naar 0 procent en dan laden tot '11', wat in de praktijk geen 11 was natuurlijk. Vanaf BMS 216 is dat niet meer zo en dat is ook niet erg.

Hoe het gedrag bij de V3 is en was weet ik niet precies.

Als we jou toch niet hadden 😉
Altijd paraat om te antwoorden. Dat verdient wel eens een dikke DANKJEWEL!!!!!

Ik heb twee V2’s maar zoals ik al zei zakken ze geleidelijk. Ik durf ze niet te laag laten komen en daarom die automation gemaakt. Moet ik nu eens proberen om ze niet automatisch te laden en kijken wat er gebeurt?

[pascallj]

LodeBo schreef op woensdag 28 januari 2026 @ 18:33:
[...]


Als we jou toch niet hadden 😉
Altijd paraat om te antwoorden. Dat verdient wel eens een dikke DANKJEWEL!!!!!

Ik heb twee V2’s maar zoals ik al zei zakken ze geleidelijk. Ik durf ze niet te laag laten komen en daarom die automation gemaakt. Moet ik nu eens proberen om ze niet automatisch te laden en kijken wat er gebeurt?

Haha dankjewel

Ja hoor dat kan je wel doen. Als je richting de 0 procent gaat zou ik toch wel even bijladen, maar ik mag toch hopen dat de batterij dan al zelf wel heeft ingegrepen.

Overigens is natuurlijk wel altijd het advies dat als je weet dat je de batterijen lange tijd niet gaat gebruiken, om ze dan uit te schakelen en uit het stopcontact te halen voor volledige uitschakeling. Als het langdurig is, het liefste ook met een lading van ongeveer 50 procent.

[savale]

andypieters schreef op woensdag 28 januari 2026 @ 17:47:
[...]

Dat heb ik ook geprobeerd, maar dan start hij helemaal niet op bij mij.
Ik heb ook gemeten wat voor spanning er op die draden staat en dat was erg weinig, het is al een tijdje geleden maar ik dacht iets van 2.7 volt ofzo

Vervolgens kwam ik er achter dat als ik de usb-c aansluiting op de lilygo aan een adapter hing dat hij wel werkte.
Daarna heb ik zelf 5 volt op de 5 volt ingang van de lilygo gezet via een usb kabeltje en toen werkte het.

Tip: pak beide GND en 5v aders vanaf de marstek, dan werkt het waarschijnlijk wel... Votage drop over zo een dun UTP kabeladertje is soms gewoon teveel anders. Hier werkt het vrijwel altijd met opstarten. Heel soms moet ik hem na het uit / aanzetten nog een keer opnieuw erin steken.

(Bovenstaande geldt voor een v3)

[AUijtdehaag]

@savale
Het gaat over een v2
Misschien heeft @andypieters de verkeerde pinnen aangesloten
Die zijn anders dan de V1
De gnd zit op een andere plaats van de 5V dan voor de v1

[andypieters]

AUijtdehaag schreef op zaterdag 31 januari 2026 @ 09:36:
@savale
Het gaat over een v2
Misschien heeft @andypieters de verkeerde pinnen aangesloten
Die zijn anders dan de V1
De gnd zit op een andere plaats van de 5V dan voor de v1

Hmm ik heb ze nog eens doorgemeten en het lijkt er op dat ik inderdaad de verkeerde aders had. Ik denk dat ik het plaatje van de 1 b heb genomen, want ik had inderdaad een rode en een zware draad, maar de 5v zit inderdaad tussen de 2 zwarte draden. Hij draait nu inderdaad gewoon via de modbus kabel, geen aparte 5v meer nodig!

[Heineken01]

Ik had zaterdag de 3x Marstek Venus E 3.0 voorzien van nieuwe firmware 146 => 147 en zag vanochtend dat de batterijen zich niet aan het opladen waren, ondanks dat het zonnetje aan het schijnen is. HomeAsistant een volledige herstart gegeven, zonder succes. Daarna hem van Full Control even op Manual gezet en na een paar seconden weer terug en nu is de accu weer aan het laden 🙂

[sun62]

Ik zie ander gedrag op v147 tov v144. Bij mij was mijn venus A ook niet gestart op self consumption.
Manueel opladen of ontladen via force mode werkt wel.
Nu ben ik er achter als ik in de app een tijds blok aanmaak en via modbus extern stuur op register 43000 deze wel schakelt. Maar nul op de meter doet niets. Vanavond maar eens een power cycle doen.

[savale]

V147 via support aangevraagd? Hier zitten er 3 nog op v145 en eentje op v144. Werkt wel prima op zich: behalve de load balancing met ontladen is een beetje scheef.

[Heineken01]

savale schreef op maandag 2 februari 2026 @ 15:36:
V147 via support aangevraagd? Hier zitten er 3 nog op v145 en eentje op v144. Werkt wel prima op zich: behalve de load balancing met ontladen is een beetje scheef.

Yes, via support

[pascallj]

sun62 schreef op maandag 2 februari 2026 @ 12:33:
Ik zie ander gedrag op v147 tov v144. Bij mij was mijn venus A ook niet gestart op self consumption.
Manueel opladen of ontladen via force mode werkt wel.
Nu ben ik er achter als ik in de app een tijds blok aanmaak en via modbus extern stuur op register 43000 deze wel schakelt. Maar nul op de meter doet niets. Vanavond maar eens een power cycle doen.

En met sturen op register 43000 bedoel je dus eigenlijk gewoon het handmatige programma aanzetten. Het lijkt mij makkelijker om tijdens het debuggen gewoon alleen de app te gebruiken aangezien de Modbus er niet zo veel mee te maken heeft. Kan je het ook meteen in het andere topic posten waar meer mensen meelezen.

Overigens stond daar een paar posts terug een vergelijkbaar probleem. Daar was gewoon de autodiagnose van de CT mislukt. Zou zomaar kunnen dat het bij jou iets vergelijkbaars is.

[savale]

Is dit trouwens van een tweaker? https://github.com/rweijnen/marstek-fw-checker

Nog niet geprobeerd, maar het lijkt erop datje daarmee ook je firmware kunt updaten...

[pascallj]

savale schreef op maandag 2 februari 2026 @ 15:53:
Is dit trouwens van een tweaker? https://github.com/rweijnen/marstek-fw-checker

Nog niet geprobeerd, maar het lijkt erop datje daarmee ook je firmware kunt updaten...

Ja dat is van @bommel. Je kunt daar de firmware niet mee updaten. Het is bedoeld om een archief te maken van alle firmware versies: https://github.com/rweijnen/marstek-firmware-archive. Aangezien veel firmware versies per batterij worden uitgestuurd zolang ze nog niet voor iedereen beschikbaar zijn, kan je de firmware link alleen krijgen als specifiek jouw batterij die firmware heeft gekregen.

Deze tool laat je inloggen met je account zodat de tool de link kan scrapen als jij een specifieke firmware versies hebt gekregen voor een batterij. Vervolgens wordt alle metadata gestuurd naar het archief en wordt de firmware versie daar opgeslagen. Momenteel werkt de tool niet meer.

Met de Marstek Venus Monitor (ook van ~bommel) kan er geloof ik wel firmware geupdate worden, maar weet niet zeker of dat voor alles goed werkt ondertussen (BMS, VNS, en EMS).

[ Voor 10% gewijzigd door pascallj op 02-02-2026 15:59 ]

[savale]

Ahh jammer. Wel handig om firmware versies te achiveren. Ook wel tof als er manier is om die dan zelf te flashen...

[sun62]

pascallj schreef op maandag 2 februari 2026 @ 15:43:
[...]


En met sturen op register 43000 bedoel je dus eigenlijk gewoon het handmatige programma aanzetten. Het lijkt mij makkelijker om tijdens het debuggen gewoon alleen de app te gebruiken aangezien de Modbus er niet zo veel mee te maken heeft. Kan je het ook meteen in het andere topic posten waar meer mensen meelezen.

Overigens stond daar een paar posts terug een vergelijkbaar probleem. Daar was gewoon de autodiagnose van de CT mislukt. Zou zomaar kunnen dat het bij jou iets vergelijkbaars is.

Net een power cycle gedaan en het was ok. Via aansturen modbus met de Node-red UI.

[Tazzios]

Tazzios schreef op dinsdag 16 december 2025 @ 16:14:
[...]


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

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

maar onderstaande afbeelding is misschien wat duidelijker:
[Afbeelding]

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

Home assistant Blueprint 'Marstek X Range OM' ondersteunt nu ViperRNMC ethernet modbus integration.

Version: 1.9
New: HA integration marstek venus modbus support

https://github.com/Tazzios/ha-marstek/tree/main/blueprints

[bommel]

pascallj schreef op maandag 2 februari 2026 @ 15:58:
[...]


Ja dat is van @bommel. Je kunt daar de firmware niet mee updaten. Het is bedoeld om een archief te maken van alle firmware versies: https://github.com/rweijnen/marstek-firmware-archive. Aangezien veel firmware versies per batterij worden uitgestuurd zolang ze nog niet voor iedereen beschikbaar zijn, kan je de firmware link alleen krijgen als specifiek jouw batterij die firmware heeft gekregen.

Deze tool laat je inloggen met je account zodat de tool de link kan scrapen als jij een specifieke firmware versies hebt gekregen voor een batterij. Vervolgens wordt alle metadata gestuurd naar het archief en wordt de firmware versie daar opgeslagen. Momenteel werkt de tool niet meer.

Met de Marstek Venus Monitor (ook van ~bommel) kan er geloof ik wel firmware geupdate worden, maar weet niet zeker of dat voor alles goed werkt ondertussen (BMS, VNS, en EMS).

Firmware flash met de BLE tool is inderdaad mogelijk, er is een mede tweaker die het getest heeft en heb zelf mijn V2 naar v156 geflashed. Maar het is vooral bedoeld voor die gevallen waarin je via Marstek de juiste versie niet kunt krijgen of als je bijv. een downgrade zou willen doen. Maar gebruik blijft uiteraard op eigen risico.

[Robbe VDK]

Ik weet niet als dit hier al besproken is.
Maar weet iemand hoe ik de baudrate van de batterij kan aanpassen?
Ik wil mijn 2 batterijen graag koppelen aan mijn Loxone systeem. Maar mijn modbusextention werd vroeger ingesteld op een baudrate van 9600, stopbits 2 en parity, none.
Dit was nodig voor een ander apparaat en ondertussen heb ik al een 15 tal sensoren en apparaten die zo gekoppeld zijn.

Ik vroeg al meerdere kereb hulp aan de helpdesk maar kreeg geen antwoord...

[pascallj]

Nope voor zover ik weet is dat niet mogelijk. Ik heb zelf ook twee Modbus netwerken. Eentje op 9600 en eentje op 115200. In mijn geval gekoppeld aan dezelfde ESPHome met meerdere RS485 adapters. Kan je niet iets vergelijkbaars regelen met Loxone?

[Broodro0ster]

Klopt het dat je voor de Marstek V3 geen dongle meer nodig hebt? Zijn er bepaalde beperkingen?
Ik heb nu een Marstek V2 met Elfin module om hem via Modbus aan te sturen. Ik sta op het punt nog een V3 bij te kopen en wil de uiteraard ook via modbus mee in HA en EVCC krijgen.

[pascallj]

Broodro0ster schreef op donderdag 5 februari 2026 @ 17:04:
Klopt het dat je voor de Marstek V3 geen dongle meer nodig hebt? Zijn er bepaalde beperkingen?
Ik heb nu een Marstek V2 met Elfin module om hem via Modbus aan te sturen. Ik sta op het punt nog een V3 bij te kopen en wil de uiteraard ook via modbus mee in HA en EVCC krijgen.

Klopt. Als je hem via LAN aansluit kan je via die interface gebruik maken van Modbus TCP. Schijnt exact hetzelfde te werken als Modbus RTU via de Modbus poort.

[Gwaihir]

Robbe VDK schreef op dinsdag 3 februari 2026 @ 19:33:
Ik weet niet als dit hier al besproken is.
Maar weet iemand hoe ik de baudrate van de batterij kan aanpassen?

Ik vroeg al meerdere kereb hulp aan de helpdesk maar kreeg geen antwoord...

Oh, daar heb ik wel van iemand antwoord op gehad (al vroeg ik het m.b.t. de Jupiter en kwam het antwoord wellicht niet van Marstek zelf): dat kan niet.

Ik kocht een Waveshare converter van ModbusTCP naar Modbus RTU. Er zijn ook vele andere beschikbaar, zoals in dit topic behandeld. Zo'n converter is tientjeswerk, dus véél goedkoper dan een extra extension en wellicht nog makkelijker met kabels ook.

[Gwaihir]

pascallj schreef op donderdag 5 februari 2026 @ 17:05:
Klopt. Als je hem via LAN aansluit kan je via die interface gebruik maken van Modbus TCP. Schijnt exact hetzelfde te werken als Modbus RTU via de Modbus poort.

Ja, die Venus interfaces schijnen allemaal exact hetzelfde te werken.

Dus hopelijk kan iemand mij helpen met een vraag die eigenlijk over de -A gaat en ik vóór aanschaf beantwoord wil hebben.

Ik ga er PV aan hangen. En ga niets over de panelen zien, weet ik al. Maar kun je wel via modbus zien met hoeveel Watt de accu laadt of ontlaad? (Dus los van hoeveel er naar je huis gaat, want met PV eraan is dat niet hetzelfde.)

[pascallj]

Gwaihir schreef op donderdag 5 februari 2026 @ 19:13:
[...]

Ja, die Venus interfaces schijnen allemaal exact hetzelfde te werken.

Dus hopelijk kan iemand mij helpen met een vraag die eigenlijk over de -A gaat en ik vóór aanschaf beantwoord wil hebben.

Ik ga er PV aan hangen. En ga niets over de panelen zien, weet ik al. Maar kun je wel via modbus zien met hoeveel Watt de accu laadt of ontlaad? (Dus los van hoeveel er naar je huis gaat, want met PV eraan is dat niet hetzelfde.)

Je kunt bij de Venus En V1&2 via Modbus zien hoeveel vermogen er de batterij in of uit gaat (DC) net als hoeveel vermogen er in of uit de grid ingang gaat (AC).

Hier een oud overzichtje:



Hier komt nog min en max cell voltage bij. Bij de V3 alle celvoltages. Maar of er daar nog dingen van dit lijstje missen weet ik niet. Of het op de Venus A ook hetzelfde is, durf ik niet te zeggen.

[Gwaihir]

pascallj schreef op donderdag 5 februari 2026 @ 19:19:
Hier komt nog min en max cell voltage bij. Bij de V3 alle celvoltages. Maar of er daar nog dingen van dit lijstje missen weet ik niet. Of het op de Venus A ook hetzelfde is, durf ik niet te zeggen.

Ik hoor her en der dat 't eigenlijk allemaal hetzelfde is; men heeft dat van de Venus V1 gepakt en hooguit ietsje er tegenaan geplakt.

(En 'terug' naar de Jupiter lijkt het nimmer nog te komen.)

[sun62]

Ik ben al een heel end met mijn venus A maar denk dat niet alle registers hetzelfde zijn. Bij een aantal krijg ik er niets uit. Zie mijn app wat wel al werkt:

[savale]

Beetje een v3 update zootje hier: 3 van de 4 zitten nu op v145 en eentje nog op v144. Zie nu dat er een update klaar staat voor één van de v145. Geen idee naar welke versie... gebruik ze met hardware modbus. (bevalt goed). Wel of niet updaten?

[pascallj]

savale schreef op vrijdag 6 februari 2026 @ 08:35:
Beetje een v3 update zootje hier: 3 van de 4 zitten nu op v145 en eentje nog op v144. Zie nu dat er een update klaar staat voor één van de v145. Geen idee naar welke versie... gebruik ze met hardware modbus. (bevalt goed). Wel of niet updaten?

Je kunt altijd 1 scherm verder om te kijken welke updates er klaar staan.

Ik zou overigens nog even niet updaten als het goed werkt.

[savale]

pascallj schreef op vrijdag 6 februari 2026 @ 08:53:
[...]


Je kunt altijd 1 scherm verder om te kijken welke updates er klaar staan.

Ik zou overigens nog even niet updaten als het goed werkt.

Soort minor update

[pascallj]

savale schreef op vrijdag 6 februari 2026 @ 09:01:
[...]

[Afbeelding]

Soort minor update

Dat is een BMS update. Versienummers bij de V3 zijn opgebouwd als EMS.VNS(omvormer).BMS

[savale]

Trouwens nog een leuk home assistant puzzeltje op te lossen: heeft iemand dit al geknutseld? Volgens mij niet?

Wat heb ik:

1. p1 data (consume + production)
2. 4x venus v3 met modbus data. (esphome) Ik wil deze graag wel gewoon via de CT data (in self consumption mode) laten werken.
3. solar opbrengst totaal data
4. elektrische auto laad info
5. netto_verbruik_sensor: -p1 production + p1 usage + accu_totaal (template sensor)
   voorbeeld:
   -50 production + 0 consume -1000 accu's (laden) = -1050

Dit is dan enkel de strategie voor het oplaad script. Voor het ontladen zal ik ook weer iets moeten knutselen, maar dat komt later.


automation: trigger iedere 10 seconden?

code:

if netto_verbruik_sensor < 0 AND auto niet aan het laden

dan: 
accu's laden! // met soort van strategie :)
{
    if netto_verbruik_sensor < 5000
    {
        charge 3 laagste (self consumption)
        andere accu manual
        {
            if accu x niet manual -> manual
        }
    }
    if netto_verbruik_sensor < 2500
    {
        charge 2 laagste (self consumption)
        andere 2 manual
        {
            if accu x niet manual -> manual
            if accu y niet manual -> manual
        }
    }
    else
    {
        charge laagste
        andere 3 manual
        {
            if accu x niet manual -> manual
            if accu y niet manual -> manual
            if accu z niet manual -> manual
        }
    }
}
else
{
if (! accu's ontladen)
{
    if accu 1 niet manual -> manual
    if accu 2 niet manual -> manual
    if accu 3 niet manual -> manual
    if accu 4 niet manual -> manual
}

[Beekforel]

@savale https://github.com/gitcodebob/marstek-venus-rs485-node-red regelt dit en meer voor je, scheelt een hoop geknutsel.

[savale]

Beekforel schreef op vrijdag 6 februari 2026 @ 15:28:
@savale https://github.com/gitcodebob/marstek-venus-rs485-node-red regelt dit en meer voor je, scheelt een hoop geknutsel.

Ja, maar niet met self-consumption mode toch? De hele tijd de laad / ontlaad waardes via modbus vind ik toch wat spannend...

Edit: ooh nieuwe feature zo te zien. Gaan we die weg eens bewandelen! Thanks!

[ Voor 10% gewijzigd door savale op 06-02-2026 15:32 ]

[superduper1969]

savale schreef op vrijdag 6 februari 2026 @ 15:25:
Trouwens nog een leuk home assistant puzzeltje op te lossen: heeft iemand dit al geknutseld? Volgens mij niet?

Wat heb ik:

1. p1 data (consume + production)
2. 4x venus v3 met modbus data. (esphome) Ik wil deze graag wel gewoon via de CT data (in self consumption mode) laten werken.
3. solar opbrengst totaal data
4. elektrische auto laad info
5. netto_verbruik_sensor: -p1 production + p1 usage + accu_totaal (template sensor)
   voorbeeld:
   -50 production + 0 consume -1000 accu's (laden) = -1050

Dit is dan enkel de strategie voor het oplaad script. Voor het ontladen zal ik ook weer iets moeten knutselen, maar dat komt later.


automation: trigger iedere 10 seconden?

code:

if netto_verbruik_sensor < 0 AND auto niet aan het laden

dan: 
accu's laden! // met soort van strategie :)
{
    if netto_verbruik_sensor < 5000
    {
        charge 3 laagste (self consumption)
        andere accu manual
        {
            if accu x niet manual -> manual
        }
    }
    if netto_verbruik_sensor < 2500
    {
        charge 2 laagste (self consumption)
        andere 2 manual
        {
            if accu x niet manual -> manual
            if accu y niet manual -> manual
        }
    }
    else
    {
        charge laagste
        andere 3 manual
        {
            if accu x niet manual -> manual
            if accu y niet manual -> manual
            if accu z niet manual -> manual
        }
    }
}
else
{
if (! accu's ontladen)
{
    if accu 1 niet manual -> manual
    if accu 2 niet manual -> manual
    if accu 3 niet manual -> manual
    if accu 4 niet manual -> manual
}

Ik heb al een keer eerder een opzetje gemaakt waarbij via Modbus geswitched wordt tussen NOM/AI/Timer.
Het probleem is de bug dat Mode switchen via Modbus lijkt te lukken maar in de praktijk niet betrouwbaar werkt.
https://gathering.tweakers.net/forum/view_message/83521488

Om het goed te laten werken zou je eerst weer terug moeten gaan naar manual voordat je weer een andere modus kiest of iets dergelijks. ik ben er mee gestopt omdat de Node Red oplossing vorm begon te krijgen.

[dannyro]

superduper1969 schreef op vrijdag 6 februari 2026 @ 16:09:
[...]

Ik heb al een keer eerder een opzetje gemaakt waarbij via Modbus geswitched wordt tussen NOM/AI/Timer.
Het probleem is de bug dat Mode switchen via Modbus lijkt te lukken maar in de praktijk niet betrouwbaar werkt.
https://gathering.tweakers.net/forum/view_message/83521488

Om het goed te laten werken zou je eerst weer terug moeten gaan naar manual voordat je weer een andere modus kiest of iets dergelijks. ik ben er mee gestopt omdat de Node Red oplossing vorm begon te krijgen.

Hier kom ik aan de nom/ai/manual niet aan. Deze blijft altijd op nom staan. Mijn automatisaties sturen alleen de RS485 control mode en Forcible Charge/Discharge aan of uit. Dit werkt al maanden probleemloos.

[AUijtdehaag]

savale schreef op vrijdag 6 februari 2026 @ 15:31:
[...]
Ja, maar niet met self-consumption mode toch? De hele tijd de laad / ontlaad waardes via modbus vind ik toch wat spannend...

De kans dat je met een foute firmware je batterij brickt is groter

[gigabit]

Bij het updaten van esphome naar de lilygo een melding dat er iets niet meer zou werken in versie XX van esphome zou installeren.
Daarop de laatste versie van Superduper1969 lilygo-rs485.yaml proberen weg te schijven maar hierbij een foutmelding:
"ERROR Error auth result: Error: Authentication invalid. Is the password correct?"
Zie log hieronder.
Wat doe ik fout?

code:

INFO ESPHome 2026.1.4
INFO Reading configuration /config/esphome/lilygo-rs485.yaml...
INFO Generating C++ source...
INFO Setting CONFIG_LWIP_MAX_SOCKETS to 14 (registered: api=4, captive_portal=4, mdns=2, ota=1, web_server=3)
INFO Compiling app... Build path: /data/build/lilygo-rs485
Processing lilygo-rs485 (board: esp32dev; framework: espidf; platform: https://github.com/pioarduino/platform-espressif32/releases/download/55.03.35/platform-espressif32.zip)
--------------------------------------------------------------------------------
HARDWARE: ESP32 240MHz, 320KB RAM, 4MB Flash
 - contrib-piohome @ 3.4.4 
 - framework-espidf @ 3.50502.0 (5.5.2) 
 - tool-cmake @ 4.0.3 
 - tool-esp-rom-elfs @ 2024.10.11 
 - tool-esptoolpy @ 5.1.0 
 - 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+20251107
Reading CMake configuration...
Dependency Graph
|-- noise-c @ 0.1.10
|-- ArduinoJson @ 7.4.2
Compiling .pioenvs/lilygo-rs485/src/main.cpp.o
Linking .pioenvs/lilygo-rs485/firmware.elf
                            Memory Type Usage Summary                             
┏━━━━━━━━━━━━━━━━━━━━━┳━━━━━━━━━━━━━━┳━━━━━━━━━━┳━━━━━━━━━━━━━━━━┳━━━━━━━━━━━━━━━┓
┃ Memory Type/Section ┃ Used [bytes] ┃ Used [%] ┃ Remain [bytes] ┃ Total [bytes] ┃
┡━━━━━━━━━━━━━━━━━━━━━╇━━━━━━━━━━━━━━╇━━━━━━━━━━╇━━━━━━━━━━━━━━━━╇━━━━━━━━━━━━━━━┩
│ Flash Code          │       758188 │          │                │               │
│    .text            │       758188 │          │                │               │
│ Flash Data          │       240804 │          │                │               │
│    .rodata          │       240548 │          │                │               │
│    .appdesc         │          256 │          │                │               │
Total image size: 1095647 bytes (.bin may be padded larger)
│ IRAM                │        80099 │    61.11 │          50973 │        131072 │
│    .text            │        79071 │    60.33 │                │               │
│    .vectors         │         1028 │     0.78 │                │               │
│ DRAM                │        36724 │    20.32 │         144012 │        180736 │
│    .bss             │        20168 │    11.16 │                │               │
│    .data            │        16556 │     9.16 │                │               │
└─────────────────────┴──────────────┴──────────┴────────────────┴───────────────┘
Note: The reported total sizes may be smaller than those in the technical reference manual due to reserved memory and application configuration. The total flash size available for the application is not included by default, as it cannot be reliably determined due to the presence of other data like the bootloader, partition table, and application partition size.
RAM:   [=         ]  11.2% (used 36724 bytes from 327680 bytes)
Flash: [======    ]  59.7% (used 1095391 bytes from 1835008 bytes)
Building .pioenvs/lilygo-rs485/firmware.bin
Creating ESP32 image...
Successfully created ESP32 image.
merge_factory_bin([".pioenvs/lilygo-rs485/firmware.bin"], [".pioenvs/lilygo-rs485/firmware.elf"])
Info: bootloader.bin not found - skipping
Info: partition-table.bin not found - skipping
Info: ota_data_initial.bin not found - skipping
Info: lilygo-rs485.bin not found - skipping
Using FLASH_EXTRA_IMAGES from PlatformIO environment
Merging binaries into /data/build/lilygo-rs485/.pioenvs/lilygo-rs485/firmware.factory.bin
Merging binaries with esptool
SHA digest in image updated.
Wrote 0x11b870 bytes to file '/data/build/lilygo-rs485/.pioenvs/lilygo-rs485/firmware.factory.bin', ready to flash to offset 0x0.
Successfully created /data/build/lilygo-rs485/.pioenvs/lilygo-rs485/firmware.factory.bin
esp32_copy_ota_bin([".pioenvs/lilygo-rs485/firmware.bin"], [".pioenvs/lilygo-rs485/firmware.elf"])
Copied firmware to /data/build/lilygo-rs485/.pioenvs/lilygo-rs485/firmware.ota.bin
========================= [SUCCESS] Took 48.43 seconds =========================
INFO Build Info: config_hash=0xbef921e2 build_time_str=2026-02-06 21:23:00 +0100
INFO Successfully compiled program.
INFO Connecting to 192.168.178.115 port 3232...
INFO Connected to 192.168.178.115
INFO Uploading /data/build/lilygo-rs485/.pioenvs/lilygo-rs485/firmware.bin (1095792 bytes)
ERROR Error auth result: Error: Authentication invalid. Is the password correct?
WARNING Failed to upload to ['192.168.178.115']

[Tazzios]

@gigabit lijkt mij ota wachtwoord in de yaml niet klopt. Heb je die gewijzigd?

[gigabit]

Nee niet gewijzigd overgenomen van de oude code.

Of toch misschien wel!
Hoe kom ik achter deze code?

[ Voor 37% gewijzigd door gigabit op 06-02-2026 22:13 ]

[pascallj]

gigabit schreef op vrijdag 6 februari 2026 @ 22:06:
Bij het updaten van esphome naar de lilygo een melding dat er iets niet meer zou werken in versie XX van esphome zou installeren.
Daarop de laatste versie van Superduper1969 lilygo-rs485.yaml proberen weg te schijven maar hierbij een foutmelding:
"ERROR Error auth result: Error: Authentication invalid. Is the password correct?"
Zie log hieronder.
Wat doe ik fout?

code:

INFO ESPHome 2026.1.4
INFO Reading configuration /config/esphome/lilygo-rs485.yaml...
INFO Generating C++ source...
INFO Setting CONFIG_LWIP_MAX_SOCKETS to 14 (registered: api=4, captive_portal=4, mdns=2, ota=1, web_server=3)
INFO Compiling app... Build path: /data/build/lilygo-rs485
Processing lilygo-rs485 (board: esp32dev; framework: espidf; platform: https://github.com/pioarduino/platform-espressif32/releases/download/55.03.35/platform-espressif32.zip)
--------------------------------------------------------------------------------
HARDWARE: ESP32 240MHz, 320KB RAM, 4MB Flash
 - contrib-piohome @ 3.4.4 
 - framework-espidf @ 3.50502.0 (5.5.2) 
 - tool-cmake @ 4.0.3 
 - tool-esp-rom-elfs @ 2024.10.11 
 - tool-esptoolpy @ 5.1.0 
 - 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+20251107
Reading CMake configuration...
Dependency Graph
|-- noise-c @ 0.1.10
|-- ArduinoJson @ 7.4.2
Compiling .pioenvs/lilygo-rs485/src/main.cpp.o
Linking .pioenvs/lilygo-rs485/firmware.elf
                            Memory Type Usage Summary                             
┏━━━━━━━━━━━━━━━━━━━━━┳━━━━━━━━━━━━━━┳━━━━━━━━━━┳━━━━━━━━━━━━━━━━┳━━━━━━━━━━━━━━━┓
┃ Memory Type/Section ┃ Used [bytes] ┃ Used [%] ┃ Remain [bytes] ┃ Total [bytes] ┃
┡━━━━━━━━━━━━━━━━━━━━━╇━━━━━━━━━━━━━━╇━━━━━━━━━━╇━━━━━━━━━━━━━━━━╇━━━━━━━━━━━━━━━┩
│ Flash Code          │       758188 │          │                │               │
│    .text            │       758188 │          │                │               │
│ Flash Data          │       240804 │          │                │               │
│    .rodata          │       240548 │          │                │               │
│    .appdesc         │          256 │          │                │               │
Total image size: 1095647 bytes (.bin may be padded larger)
│ IRAM                │        80099 │    61.11 │          50973 │        131072 │
│    .text            │        79071 │    60.33 │                │               │
│    .vectors         │         1028 │     0.78 │                │               │
│ DRAM                │        36724 │    20.32 │         144012 │        180736 │
│    .bss             │        20168 │    11.16 │                │               │
│    .data            │        16556 │     9.16 │                │               │
└─────────────────────┴──────────────┴──────────┴────────────────┴───────────────┘
Note: The reported total sizes may be smaller than those in the technical reference manual due to reserved memory and application configuration. The total flash size available for the application is not included by default, as it cannot be reliably determined due to the presence of other data like the bootloader, partition table, and application partition size.
RAM:   [=         ]  11.2% (used 36724 bytes from 327680 bytes)
Flash: [======    ]  59.7% (used 1095391 bytes from 1835008 bytes)
Building .pioenvs/lilygo-rs485/firmware.bin
Creating ESP32 image...
Successfully created ESP32 image.
merge_factory_bin([".pioenvs/lilygo-rs485/firmware.bin"], [".pioenvs/lilygo-rs485/firmware.elf"])
Info: bootloader.bin not found - skipping
Info: partition-table.bin not found - skipping
Info: ota_data_initial.bin not found - skipping
Info: lilygo-rs485.bin not found - skipping
Using FLASH_EXTRA_IMAGES from PlatformIO environment
Merging binaries into /data/build/lilygo-rs485/.pioenvs/lilygo-rs485/firmware.factory.bin
Merging binaries with esptool
SHA digest in image updated.
Wrote 0x11b870 bytes to file '/data/build/lilygo-rs485/.pioenvs/lilygo-rs485/firmware.factory.bin', ready to flash to offset 0x0.
Successfully created /data/build/lilygo-rs485/.pioenvs/lilygo-rs485/firmware.factory.bin
esp32_copy_ota_bin([".pioenvs/lilygo-rs485/firmware.bin"], [".pioenvs/lilygo-rs485/firmware.elf"])
Copied firmware to /data/build/lilygo-rs485/.pioenvs/lilygo-rs485/firmware.ota.bin
========================= [SUCCESS] Took 48.43 seconds =========================
INFO Build Info: config_hash=0xbef921e2 build_time_str=2026-02-06 21:23:00 +0100
INFO Successfully compiled program.
INFO Connecting to 192.168.178.115 port 3232...
INFO Connected to 192.168.178.115
INFO Uploading /data/build/lilygo-rs485/.pioenvs/lilygo-rs485/firmware.bin (1095792 bytes)
ERROR Error auth result: Error: Authentication invalid. Is the password correct?
WARNING Failed to upload to ['192.168.178.115']

Ik vermoed dat het hiermee te maken heeft in ESPHome 2026.1:

This release completes major security transitions: API password authentication has been removed and API encryption is now required, while OTA updates require SHA256 authentication. ESP-IDF is now the default for ESP32, ESP32-C3, ESP32-S2, and ESP32-S3, delivering up to 40% smaller binaries and faster compile times.

En:

ESPHome versions before 2025.10.0 that use password authentication cannot OTA to devices running 2026.1.0 or later.

If you use multiple systems to install and/or update your ESPHome devices, be sure they’re all up-to-date! If you need to downgrade to a version before 2025.10.0, downgrade to 2025.12.x first, then OTA to an earlier version.

Waarschijnlijk te lang niet geüpdatet. Of je moet eenmalig via USB flashen, of eerst updaten naar bijvoorbeeld 2025.12 en dan naar 2026.1.

[gigabit]

Eerst met 2025.12 geprobeerd maar helaas. Morgen maar eens met USB flashen aan de gang.
Kan ik er dan een nieuw willekeurig ota wachtwoord in zetten?

[RefleXion]

Omdat ik geen reactie kreeg van Marstek Nederland over de modbus (is het veilig om vaak te schrijven?) heb ik een apparte controller gebouwd.
Ik draai nu op een raspberry pi 5 een zelf geschreven Python programma dat voor alle 9 accu's apart een meter emuleert aan de hand van een HomeWizard P1 meter (elke seconde). Via Elfin 11a's leest de controller via de modbus de actuele energielevering, SoC en error's uit van alle accu's.
Op poort 80 heb ik een API gemaakt zodat ik in home assistant alles kan uitlezen en bedienen (modus, balanceren, min / max laadsnelheid, min / max lading etc.)
Uiteindelijk veel te veel tijd aan kwijt geweest, maar nu wel een super stabiele oplossing en volledige controle over de accu's.
Ergens wel jammer dat dit nodig is, maar de Marstek software werkt echt waardeloos met 9 accu's. De accu's verliezen willekeurig verbinding met de eigen Marstek P1 meter en SoC's lopen ver uiteen.

[AUijtdehaag]

@RefleXion
3 accus per fase dus 7500 watt / 32 A per fase? Wat voor hoofdaansluiting heb je dan?

Je had ook Gitcode Bob even kunnen aanschrijven via zijn discord channel
Die ondersteund 4 batterijen (wellicht was 9 ook mogelijk)
Maar chapeau dat je het zelf al voor elkaar hebt

Aanname: het is niet zo vreemd dat Marstek er geen antwoord op geeft wat betreft modbus.
Stel dat de mensen de app niet meer gebruiken....

[ Voor 20% gewijzigd door AUijtdehaag op 07-02-2026 11:21 ]

[RefleXion]

AUijtdehaag schreef op zaterdag 7 februari 2026 @ 11:17:
@RefleXion
3 accus per fase dus 7500 watt / 32 A per fase? Wat voor hoofdaansluiting heb je dan?

Je had ook Gitcode Bob even kunnen aanschrijven via zijn discord channel
Die ondersteund 4 batterijen (wellicht was 9 ook mogelijk)
Maar chapeau dat je het zelf al voor elkaar hebt

3x 40A hoofdaansluiting, past precies. Pieklevering zonnepanelen kan ik nu precies opvangen.
Zelf aanmodderen en ervan leren is de Tweaker way toch .

[AUijtdehaag]

@RefleXion
Misschien toch eens met de warmtebeeldcamera alles nalopen.
En zeker geen backup box aanschaffen met 100 A door de nul

[ Voor 28% gewijzigd door AUijtdehaag op 07-02-2026 11:28 ]

[RefleXion]

AUijtdehaag schreef op zaterdag 7 februari 2026 @ 11:23:
@RefleXion
Misschien toch eens met de warmtebeeldcamera alles nalopen.

One step ahead of you. Al gedaan! Voor verzwaren hoofdaansluiting blies ik er wel eens een hoofdzekering (25A) uit met de teruglevering, maar binnenshuis is alles stabiel en koel.

Sorry voor de off-topic reactie.

[savale]

sun62 schreef op maandag 2 februari 2026 @ 12:33:
Ik zie ander gedrag op v147 tov v144. Bij mij was mijn venus A ook niet gestart op self consumption.
Manueel opladen of ontladen via force mode werkt wel.
Nu ben ik er achter als ik in de app een tijds blok aanmaak en via modbus extern stuur op register 43000 deze wel schakelt. Maar nul op de meter doet niets. Vanavond maar eens een power cycle doen.

Heb je self consumption toevallig weer aan de gang? Hier 1 accu over op v147 maar self consumption blijft in standby...