Marstek Venus / Duravolt PnP Thuisaccu Modbus koppeling

[superduper1969]

Dolf_Tweakers schreef op woensdag 2 april 2025 @ 13:59:
@superduper1969

Kan je even kijken in het andere topic Hame / Marstek / Duravolt 5,12kWh plug en play thuisaccu
mijn forumpost Dolf_Tweakers in "Hame / Marstek / Duravolt 5,12kWh plug en play thuisaccu"


Als jullie aansturen via Modbus, blijft dan de CT via Wifi actief in de batterij?
Wordt daar dan nog iets mee gedaan?

Dezelfde vraag blijft als je deze dan ook al gebruikt in de HA.
Blijft die alsnog ook actief in de app?

Je kan HA switchen tussen control door HA of AI/NOM/Manual van de app
Wifi van MT kan actief blijven en moet actief blijven als je AI/NOM van MT wil gebruiken of statistieken in je APP wil zien. Ik zie geen reden waarom je dit uit wil zetten.
CT003 heeft geen koppeling in HA, dus je als je een actie wil uitvoeren aan de hand van een waarde dan moet iets gebruiken wat je wel in HA ziet zoals een HW-P1 of 20 andere oplossingen die HA aan een slimme meter kunnen koppelen.

[Babavers]

JorisLammar schreef op woensdag 2 april 2025 @ 10:10:
niet verdelen over 3 batterijen, maar naar maximaal vermogen streven omdat dit het minste verlies geeft en dan pas extra batterijen inschakelen.

Waar haal je die informatie? Ik zit met eenzelfde situatie. Ik heb er 2 en stuur die aan via home assistant met een eigen programma in java script (via NodeRed), maar heb dat nu zo gemaakt dat beide batterijen netjes synchroon laden en ontladen en zelfs zodanig dat ze mekaar bijbenen als er eentje een lagere of hogere SoC heeft dan de andere. Het principe is dus 'samen vol, samen leeg' en nooit situaties waarbij eentje staat te laden terwijl de andere aan het ontladen is. En in de praktijk, vermits dat voortdurend bijstuurt, betekent dat dat ze altijd op dezelfde SoC staan en quasi altijd hetzelfde vermogen opnemen of afgeven op enkele W na.
Maar dat zou verkeerd zijn volgens wat ik lees in jouw bericht.
Is de efficiëntie effectief beter bij grotere vermogens? Zijn er ergens gegevens van RTE in functie van vermogen beschikbaar? Ik heb daar al naar gezocht maar vind dat eigenlijk niet.

[superduper1969]

Babavers schreef op donderdag 3 april 2025 @ 10:23:
[...]

Waar haal je die informatie? Ik zit met eenzelfde situatie. Ik heb er 2 en stuur die aan via home assistant met een eigen programma in java script (via NodeRed), maar heb dat nu zo gemaakt dat beide batterijen netjes synchroon laden en ontladen en zelfs zodanig dat ze mekaar bijbenen als er eentje een lagere of hogere SoC heeft dan de andere. Het principe is dus 'samen vol, samen leeg' en nooit situaties waarbij eentje staat te laden terwijl de andere aan het ontladen is. En in de praktijk, vermits dat voortdurend bijstuurt, betekent dat dat ze altijd op dezelfde SoC staan en quasi altijd hetzelfde vermogen opnemen of afgeven op enkele W na.
Maar dat zou verkeerd zijn volgens wat ik lees in jouw bericht.
Is de efficiëntie effectief beter bij grotere vermogens? Zijn er ergens gegevens van RTE in functie van vermogen beschikbaar? Ik heb daar al naar gezocht maar vind dat eigenlijk niet.

Ik heb in het andere topic een paar efficientie testen gedaan. Liefst blijf je boven de 200W.

Als ik er 2 zou hebben OP 1 FASE dan zou ik dit doen:
Ontladen = 800w op gedeelde groep
Ontladen = 2500w op aparte groep
Dit schema zou natuurlijk het beste werken als je 2500w kan ontladen.

MT1 = NOM, MT2= Pause/Manual zonder schema.
Als MT1 = Charging & P1 >50W dan MT2 ook op NOM zodat deze kan laden. (MT2 laden boven 2500w Solar + eigenverbruik)
Als MT1 <100% en P1 = onder 50W dan MT2 weer op pauze i.v.m. wolken of zo.
Als MT1 = 100% = Pause, MT2 draait dan nog NOM en gaat uiteindelijk weer naar 11%
MT2 = 11% = Pauze en MT1 weer op NOM (Deze is dan 100%) en dan ben je weer in je startpositie.

Eventueel nog met exta rules voor Laadpaal / Elec. Koken

[JorisLammar]

Babavers schreef op donderdag 3 april 2025 @ 10:23:
[...]

Waar haal je die informatie? Ik zit met eenzelfde situatie. Ik heb er 2 en stuur die aan via home assistant met een eigen programma in java script (via NodeRed), maar heb dat nu zo gemaakt dat beide batterijen netjes synchroon laden en ontladen en zelfs zodanig dat ze mekaar bijbenen als er eentje een lagere of hogere SoC heeft dan de andere. Het principe is dus 'samen vol, samen leeg' en nooit situaties waarbij eentje staat te laden terwijl de andere aan het ontladen is. En in de praktijk, vermits dat voortdurend bijstuurt, betekent dat dat ze altijd op dezelfde SoC staan en quasi altijd hetzelfde vermogen opnemen of afgeven op enkele W na.
Maar dat zou verkeerd zijn volgens wat ik lees in jouw bericht.
Is de efficiëntie effectief beter bij grotere vermogens? Zijn er ergens gegevens van RTE in functie van vermogen beschikbaar? Ik heb daar al naar gezocht maar vind dat eigenlijk niet.

Ik heb dit getest met Homewizards plugs.

[JorisLammar]

Babavers schreef op donderdag 3 april 2025 @ 10:23:
[...]

Ik heb er 2 en stuur die aan via home assistant met een eigen programma in java script (via NodeRed),...

Kan je complexe logica kwijt met NodeRed? Als ik mijn logica in YAML kwijt wil, moet ik met veel te veel hulpvariabelen gaan werken. Maar voor één of andere duistere reden lukt het niet via pyscript (zoals aangegeven wel het aanpassen van de entiteiten, maar de batterij reageert niet op die wijzigingen, wel als ik ze via YAML of manueel invoer)

[ Voor 39% gewijzigd door JorisLammar op 03-04-2025 12:18 ]

[Babavers]

JorisLammar schreef op donderdag 3 april 2025 @ 12:17:
[...]


Kan je complexe logica kwijt met NodeRed? Als ik mijn logica in YAML kwijt wil, moet ik met veel te veel hulpvariabelen gaan werken. Maar voor één of andere duistere reden lukt het niet via pyscript (zoals aangegeven wel het aanpassen van de entiteiten, maar de batterij reageert niet op die wijzigingen, wel als ik ze via YAML of manueel invoer)

Ja zeker. Ik heb NodeRed leren kennen op aanraden van chatgpt. Om je met zoiets op gang te helpen is AI werkelijk fantastisch. Ik ben er ondertussen een paar maanden mee aan het 'spelen' (ook voor mijn laadpaal, voornamelijk mbt beperking capaciteitstarief). Je kan daar fantastische dingen mee doen en het nodige in javascript programmeren in een of meer functie-nodes. Dat werkt voortreffelijk en je hebt direct toegang tot alle devices en entiteiten in Home Assistant, zowel om uit te lezen als acties te ondernemen.

Voor wie het interesseert, hier mijn huidige flow binnen nodered. Je kan die zo importeren, maar dat gaat wel wat aanpassingswerk vragen om al die blauwe nodes (home assistant links) correct in te stellen als je het draaiend wil krijgen.

Er zit ook een beetje code in om data uit te wisselen met een gelijkaardige flow voor de regeling van mijn laadpaal, maar dat kan je zo schrappen als je wil. Bovendien log ik een en ander naar een databank. Dat kan je er ook uit halen als je wil. Dat helpt wel enorm bij het debuggen.

Het resultaat ziet er dan zo uit (zie screenshot van vanmiddag). Rond 13:00 heb ik trouwens nog wat opgeladen omdat mijn batterijen al vol waren.
Van zodra ik mijn auto overdag aankoppel ontladen die de batterijen aan full power bovenop wat de laadpaal nog van de zon rechtstreeks krijgt. En ondertussen blijft de P1 op 0, zowel tijdens als na het laden. En bovendien laad ik dan maar liefst met 9 kW als het zonnetje schijnt. Die nom-regeling is minstens even goed als wanneer de MT rechtstreeks communiceert met een P1 dongle, maar in mijn geval dus 2 synchroon wat tot dusver nog altijd een probleem is als je de MT's op basis van dezelfde P1 meter zelf hun ding laat doen.

Maar misschien moet ik het toch eens herschrijven als blijkt dat er een belangrijk rendementsverschil is tussen bv. (ont)laden op 1000W tov 2500 W. Alle gedetailleerde info daaromtrent is altijd welkom...

[JanAllElectric]

Mijn 2 Marstek 5kWh komen over een paar weken. Ik ga met 2 lilygo's werken en de code van @superduper1969. Verder HA en node-red.

Leuk om ook over de beslisregels te discussiëren

Ik ga deze op een bijna lege groep zetten. Alleen een PV inverter (max 1500/2000W) zit op deze groep. Ik heb er een PV verdeler voor geplaatst zodat de Marsteks beiden nooit meer dan 3600W kunnen (ont)laden.

Volgens ChatGPT is het efficiënter om eerste de ene accu te (ont)laden en daarna de 2e (=efficiënter dan beiden tegelijk?). Hiervoor verdeel ik het beschikbare vermogen van 3600W over beide accus (2500/1100 -> 0,2500).

Ik draai (nu in een simulatie) NOM met eventuele bijkoop wanneer PVopbrengst te klein is. ik denk nog aan de volgende opties:
- XOM: geen nom tussen bv -200W en +200W
- geen NOM als de marge <€ 0.05 (ongeveer de kosten van 1 cycle incl RTE verlies).
- strategie kopen/verkopen op hoogste en laagste momenten van de dag. Ik gebruik hiervoor de ATAWAR methode (very cheap, cheap, normal, expensive, very expensive) op basis afwijking huidig tarief tov gemiddeld tarief. Wanneer je cheap voor laden en expensive voor ontladen gebruik heb je automatisch blokken om te (ont)laden.

Ik wil het opladen van EV 77 kWh buiten de accu houden. @Babavers wat is jouw overweging om juist wel uit de accu's te laden?

wat zijn er nog meer voor opties?

[Babavers]

JanAllElectric schreef op donderdag 3 april 2025 @ 20:14:
Ik wil het opladen van EV 77 kWh buiten de accu houden. @Babavers wat is jouw overweging om juist wel uit de accu's te laden?

Dat is voor mij de logica zelf. Het kan maar verbruikt zijn (tenminste als je je auto elders niet goedkoper kan laden). En zeker met dagen zoals nu. Iedereen heeft nu wel overschot, dan kan je toch niet beter doen dan die batterij overladen in je auto van zodra je de mogelijkheid hebt en zolang er nog ruimte is in je auto-batterij.
Ik heb het nu zo geprogrammeerd dat mijn auto de batterijen leeg trekt tussen 6 uur 's morgens en 3 uur namiddags. Dat laatste heb ik voorzien om te voorkomen dat ik de avond in ga met lege batterijen. Dat is nefast voor het capaciteitstarief (iets Belgisch/Vlaams) dat is een extra kost gebaseerd op het gemiddelde kwartierverbruik. Een batterij die niet leeg is helpt om dat laag te houden en dat telt enorm 's avonds als er gekookt en gebakken wordt. Vandaar wil ik toch dat na 15:00 niet alles naar de auto gaat, ook als die nog aangekoppeld zou zijn.
Anyway, je kan niet beter doen dan er in elk geval voor te zorgen dat je batterijen bij het ochtendgloren leeg zijn, tenminste als je de energie nergens aan hebt moeten verspillen. Op die manier haal je het maximale uit de zon.

[WitteVerf]

Zou het kunnen dat er een foutje zit in de yaml code van de lilygo? ik gebruik de lilygo om over modbus nul op de meter te sturen. Echter, ik wens ook de backup uitgang als een no break uitgang te gebruiken. Om nul op de meter te draaien stuur ik op de modi "charge" en "discharge" in combinatie met een stroom waarde die ik bereken. Om te garanderen dat de backup uitgang steeds onder spanning blijft zet ik de batterij in de modus "stop" van zodra de SOC onder een drempel zakt. Ik ga vervolgens opladen naar de drempelwaarde plus 2%. Dit doe ik door het "Charge to SOC" input number te schrijven met de drempelwaarde plus 2%. Wanneer er terug stroomoverschotten zijn wordt de modus van de batterij opnieuw gewijzigd naar charge en begint alles van voor af aan. Ik stel echter vast dat de batterij ook blijft kijken naar de "charge to SOC" waarde. Dit zorgt voor een ongecontroleerd laden en ontladen. In de startpost is te zien dat de Lilygo op een "charge to SOC" van 0% staat. Ik veronderstel dat de functie daarmee uitgeschakeld wordt. 0 is echter volgens de huidige yaml code niet instelbaar. Zou het bereik niet moeten aangepast worden zoals hieronder:

- name: "Marstek Charge To SOC"
icon: mdi:battery-charging-medium
mode: box
platform: modbus_controller
modbus_controller_id: mt
register_type: holding
address: 42011
value_type: U_WORD
unit_of_measurement: "%"
min_value: 0
max_value: 100
step: 1

Graag jullie input.

[SatScan]

WitteVerf schreef op zaterdag 5 april 2025 @ 09:52:
Zou het kunnen dat er een foutje zit in de yaml code van de lilygo? ik gebruik de lilygo om over modbus nul op de meter te sturen. Echter, ik wens ook de backup uitgang als een no break uitgang te gebruiken. Om nul op de meter te draaien stuur ik op de modi "charge" en "discharge" in combinatie met een stroom waarde die ik bereken. Om te garanderen dat de backup uitgang steeds onder spanning blijft zet ik de batterij in de modus "stop" van zodra de SOC onder een drempel zakt. Ik ga vervolgens opladen naar de drempelwaarde plus 2%. Dit doe ik door het "Charge to SOC" input number te schrijven met de drempelwaarde plus 2%. Wanneer er terug stroomoverschotten zijn wordt de modus van de batterij opnieuw gewijzigd naar charge en begint alles van voor af aan. Ik stel echter vast dat de batterij ook blijft kijken naar de "charge to SOC" waarde. Dit zorgt voor een ongecontroleerd laden en ontladen. In de startpost is te zien dat de Lilygo op een "charge to SOC" van 0% staat. Ik veronderstel dat de functie daarmee uitgeschakeld wordt. 0 is echter volgens de huidige yaml code niet instelbaar. Zou het bereik niet moeten aangepast worden zoals hieronder:

- name: "Marstek Charge To SOC"
icon: mdi:battery-charging-medium
mode: box
platform: modbus_controller
modbus_controller_id: mt
register_type: holding
address: 42011
value_type: U_WORD
unit_of_measurement: "%"
min_value: 0
max_value: 100
step: 1

Graag jullie input.

Ik kan alleen je constatering bevestigen, ik stuurde eerst ook zo voor laden EV.
Nu gebruik ik de opties zal van Anti-feed - AI - Manueel (waarbij ik manueel schema van 24/7 op 100w laden heb staan).

Kort en goed , volgens mij heb je gelijk

[SatScan]

JanAllElectric schreef op donderdag 3 april 2025 @ 20:14:
Mijn 2 Marstek 5kWh komen over een paar weken. Ik ga met 2 lilygo's werken en de code van @superduper1969. Verder HA en node-red.

Leuk om ook over de beslisregels te discussiëren

Ik ga deze op een bijna lege groep zetten. Alleen een PV inverter (max 1500/2000W) zit op deze groep. Ik heb er een PV verdeler voor geplaatst zodat de Marsteks beiden nooit meer dan 3600W kunnen (ont)laden.

Volgens ChatGPT is het efficiënter om eerste de ene accu te (ont)laden en daarna de 2e (=efficiënter dan beiden tegelijk?). Hiervoor verdeel ik het beschikbare vermogen van 3600W over beide accus (2500/1100 -> 0,2500).

Ik draai (nu in een simulatie) NOM met eventuele bijkoop wanneer PVopbrengst te klein is. ik denk nog aan de volgende opties:
- XOM: geen nom tussen bv -200W en +200W
- geen NOM als de marge <€ 0.05 (ongeveer de kosten van 1 cycle incl RTE verlies).
- strategie kopen/verkopen op hoogste en laagste momenten van de dag. Ik gebruik hiervoor de ATAWAR methode (very cheap, cheap, normal, expensive, very expensive) op basis afwijking huidig tarief tov gemiddeld tarief. Wanneer je cheap voor laden en expensive voor ontladen gebruik heb je automatisch blokken om te (ont)laden.

Ik wil het opladen van EV 77 kWh buiten de accu houden. @Babavers wat is jouw overweging om juist wel uit de accu's te laden?

wat zijn er nog meer voor opties?

Prachtig al die opties... maar welk doel wil je bereiken?

Al die RTE berekeningen en aannames kunnen wat mij betreft de prullenbak in!
Mijn RTE is +80% met op 2500w en altijd NOM - lekker simpel en effectief!
Laden bij overschot en bijspringen bij tekort van de PV. Rest gaat naar het net als terug levering!

Bij opladen EV schakelt de batt naar manueel - laden 100w). In de zomermaanden laad de EV alleen bij voldoende overschot (eco-modus of Full green in Wallbox app) vanuit PV.

Bij >1batt laat ik MT zelf uitzoeken hoe de batt te benutten ivm kalibreren en laad/ontlaad cyclussen

En verder is, met alle respect!, 100w meer of minder gerommel in de marge. Meet je bij de batt of bij niet... hoelang zijn je stroomkabels... mijn kabel is tenminste 20m vanaf batt naar meterkast...

Ik wacht even rustig af wat MT de komende maanden met de optie AI gaat doen, die gaan ze verder ontwikkelen zodra de werking van meerdere batterijen is geoptimaliseerd.

Mijn wens op dit punt zou zijn dat je een spread kunt instellen voor laden/ontladen bij AI.

m2c

[stoutski]

Heb de waardes verwerkt in m'n TC001 met behulp van HA en Node-RED en MQTT

[Ronald_61]

Ik had verwacht dat op adres 32105 een variabele was die aan gaf hoeveel capaciteit in de accu zat maar dan ik kWh. Net zoals de battery SOC in percentage maar dan in Wh.

Helaas ik krijg continu de 5120Wh als vaste waarde. Volgens mij is die niet in de modbus aanwezig.
Heeft iemand die wel gevonden?

[JanAllElectric]

SatScan schreef op zaterdag 5 april 2025 @ 10:19:
[...]


Prachtig al die opties... maar welk doel wil je bereiken?

Al die RTE berekeningen en aannames kunnen wat mij betreft de prullenbak in!
Mijn RTE is +80% met op 2500w en altijd NOM - lekker simpel en effectief!
Laden bij overschot en bijspringen bij tekort van de PV. Rest gaat naar het net als terug levering!

Bij opladen EV schakelt de batt naar manueel - laden 100w). In de zomermaanden laad de EV alleen bij voldoende overschot (eco-modus of Full green in Wallbox app) vanuit PV.

Bij >1batt laat ik MT zelf uitzoeken hoe de batt te benutten ivm kalibreren en laad/ontlaad cyclussen

En verder is, met alle respect!, 100w meer of minder gerommel in de marge. Meet je bij de batt of bij niet... hoelang zijn je stroomkabels... mijn kabel is tenminste 20m vanaf batt naar meterkast...

Ik wacht even rustig af wat MT de komende maanden met de optie AI gaat doen, die gaan ze verder ontwikkelen zodra de werking van meerdere batterijen is geoptimaliseerd.

Mijn wens op dit punt zou zijn dat je een spread kunt instellen voor laden/ontladen bij AI.

m2c

Nieuwe ideeën opdoen hoe aan te sturen.

Uit jouw antwoord distileer ik dat als je de EV oplaadt de:
- accu op manueel zet met 100W opladen.
Dit zat nog niet in mijn aansturing

Voor de rest stuur ik de accu's (2 op 1 groep) op een beetje dezelfde manier aan als jij (NOM en bijkopen op een relatief goedkoop moment als er onvoldoende PV opbrengst is).

NB: ik krijg de accu's pas 30-4, ik simuleer de werking op dit moment als voorbereiding.

[vinom]

JanAllElectric schreef op zaterdag 5 april 2025 @ 20:49:
[...]


Nieuwe ideeën opdoen hoe aan te sturen.

Uit jouw antwoord distileer ik dat als je de EV oplaadt de:
- accu op manueel zet met 100W opladen.
Dit zat nog niet in mijn aansturing

Voor de rest stuur ik de accu's (2 op 1 groep) op een beetje dezelfde manier aan als jij (NOM en bijkopen op een relatief goedkoop moment als er onvoldoende PV opbrengst is).

NB: ik krijg de accu's pas 30-4, ik simuleer de werking op dit moment als voorbereiding.

Hoe/waar stimuleer je die? Home Assistant?
Hier komen ook twee stuks binnen de 28e.

[ Voor 3% gewijzigd door vinom op 05-04-2025 21:27 ]

[SatScan]

JanAllElectric schreef op zaterdag 5 april 2025 @ 20:49:
[...]


Nieuwe ideeën opdoen hoe aan te sturen.

Uit jouw antwoord distileer ik dat als je de EV oplaadt de:
- accu op manueel zet met 100W opladen.
Dit zat nog niet in mijn aansturing

Voor de rest stuur ik de accu's (2 op 1 groep) op een beetje dezelfde manier aan als jij (NOM en bijkopen op een relatief goedkoop moment als er onvoldoende PV opbrengst is).

NB: ik krijg de accu's pas 30-4, ik simuleer de werking op dit moment als voorbereiding.

Idd ik gebruik de manueel opladen omdat de ontlaad powerregeling van 0 naar 100% in Modbus niet goed werkt. Dat van mijn eerste oplossing het terug regelen van 0 naar 100% van ontlaad power en werkte niet stabiel. (zal nog eens proberen met >0% en dan weer terug naar 100%)

Is hier door andere gebruiker al gemeld ik kan dit bevestigen. Daarom deze workaround met 24/7 manueel op 100w laden. Dit werkt voor nu perfect! Helaas zelf geen tijd om hier dieper in te duiken en eventueel op te lossen.

En nogmaals over RTE zou ik me voorlopig niet druk maken, alle verhalen over kleine en grote omvormers etc. is wat mij betreft onzin, mijn praktijk wijst anders uit! Met 2500w op aparte groep heb ik altijd een RTE van >80% gemeten door HW energie socket bij batt en P1 meter, met een kabellengte van >20m van batt maar energiemeter. Voor handelen met energie zou een werkende spread instelling zinvol zijn!

Aanvulling: ik heb even getest met Discharge power naar 100w bij Wallbox aan en weer terug naar 2500w bij Wallbox off en dat werkt. Ik vermoed dat 100w de ondergrens is van de instelling die je kunt maken.
Ik hou deze in gebruik zodat ik alle andere opties ter beschikking hou.

2de Aanvulling: Bovenstaande werkte toch niet vandaag met de EV aan de wallbox. Weer terug naar EV laden = Manueel en niet laden = Anti-feed (NOM). Dat werkt tot nu toe perfect.

[ Voor 13% gewijzigd door SatScan op 07-04-2025 15:55 ]

[superduper1969]

Ronald_61 schreef op zaterdag 5 april 2025 @ 20:16:
Ik had verwacht dat op adres 32105 een variabele was die aan gaf hoeveel capaciteit in de accu zat maar dan ik kWh. Net zoals de battery SOC in percentage maar dan in Wh.

Helaas ik krijg continu de 5120Wh als vaste waarde. Volgens mij is die niet in de modbus aanwezig.
Heeft iemand die wel gevonden?

Schaal aangepast zodat het goed staat in kWh volgens de uitleg.
Het is altijd dezelfde waarde tenzij je de kleine accu koopt, dan heb je de 2.5 kWh

Als je de huidige waarde wil weten in kWh dan moet je een berekening maken.
Waarde SOC x Total Energy.

[fjskmdl2]

---

[ Voor 255% gewijzigd door fjskmdl2 op 08-04-2025 17:54 . Reden: intussen opgelost ]

[M_E_B]

Heeft er iemand zo'n kabeltje over die ik kan kopen/lenen?
Ik heb ze besteld bij Ali, echter liggen ze al meer dan een week stil ergens in China.

[SatScan]

M_E_B schreef op dinsdag 8 april 2025 @ 14:38:
Heeft er iemand zo'n kabeltje over die ik kan kopen/lenen?
Ik heb ze besteld bij Ali, echter liggen ze al meer dan een week stil ergens in China.

Welk kabeltje bedoel je? Stekker met 6 gekleurde snoertjes?

Als die het is stuur maar en DM dan doe ik die op de post.

[Edvd1]

Dank voor deze mooie koppeling! Enige waar ik tegenaanloop is dat de Modus van de batterij nu al een aantal keer onverwachts van Auto naar Manual is gesprongen. Kan dat kloppen? Of moet ik de oorzaak ergens anders zoeken?

[jbeMR]

Sorry to reach out to you in english (not speaking dutch), and maybe the qestion I have is already answered but I did not read all the pages (very cumbersome even with translation). I have seen on the first page with the "cook-book" you not connect the signal GND. Is there a special reason? I have seen some remarks (at least the translation say so) with instable connection. So I did connect ...and it works

[superduper1969]

jbeMR schreef op woensdag 9 april 2025 @ 18:18:
Sorry to reach out to you in english (not speaking dutch), and maybe the qestion I have is already answered but I did not read all the pages (very cumbersome even with translation). I have seen on the first page with the "cook-book" you not connect the signal GND. Is there a special reason? I have seen some remarks (at least the translation say so) with instable connection. So I did connect ...and it works

Yes. Not connecting ground is part of the RS485 standard.

[superduper1969]

Edvd1 schreef op woensdag 9 april 2025 @ 17:17:
Dank voor deze mooie koppeling! Enige waar ik tegenaanloop is dat de Modus van de batterij nu al een aantal keer onverwachts van Auto naar Manual is gesprongen. Kan dat kloppen? Of moet ik de oorzaak ergens anders zoeken?

Het doet exact wat je insteld. Dus als je instelt wat je wil dan doet het wat je verwacht.

En aangezien we hier niet helderziende zijn, screenshots, screenshots, screenshots!

[SatScan]

Edvd1 schreef op woensdag 9 april 2025 @ 17:17:
Dank voor deze mooie koppeling! Enige waar ik tegenaanloop is dat de Modus van de batterij nu al een aantal keer onverwachts van Auto naar Manual is gesprongen. Kan dat kloppen? Of moet ik de oorzaak ergens anders zoeken?

Heb je de AI functie gekozen? Dan is dat het, zet op anti-feed (NOM) dan blijft de stand behouden.

[savale]

Super tof dat ze via modbus / esphome kunnen worden aangestuurd. Heb dat liever zelf in de hand dan via de marstek app Hier zit alle zonnepanelen "kennis" en p1 waardes al in home assistant. Gaan nog wel heel wat uurtjes in zitten om het volgende voor elkaar te krijgen:

3 marsteks (allemaal eigen fase) met eigen esphome modbus controller

doelen:
SOC gelijk zien te houden van de 3 batterijen.
overdag opladen met zonne energie. (wellicht tot max 90% vol).
proberen het verbruik op nul te houden.

Iemand dit al voor elkaar?

Later nog eens kijken naar "handelen" van energie...

[elgringo]

Ik heb een marstek venus 5.1 kwh. Hier communiceer ik met modbus mee. Dat gaat prima.

Zodra ik de mode in 'manual' zet. wordt de status '6' (omloopstatus). ik weet niet wat dit is, deze is ook niet te vinden in: https://duravolt.nl/wp-co...lug-in-Battery-Modbus.pdf
Status even genegeerd. Ik heb:
42000 staat op 0x55aa zodat modbus werkt
43000 staat op 0, manual
42010 staat op 2: discharge
42021 staat op 100: 100 watt ontladen.

Echter gebeurd er niets in dat apparaat.
Als ik bovenstaande registers uitless zijn het de waarde die ik verwacht.

Ik zag wel dat de SOC in procenten wordt gerapporteerd ipv 0.1% zoals de documentatie vermeld.
Betekend dat 44000 en 44001 ook in procenten zijn?

Edit: Dat was de oorzaak. 44000 en 44001 moeten in procenten ipv 0.1% hierna werkte het laden en ontladen

[ Voor 6% gewijzigd door elgringo op 09-04-2025 23:22 ]

[Goede14]

savale schreef op woensdag 9 april 2025 @ 23:09:
Super tof dat ze via modbus / esphome kunnen worden aangestuurd. Heb dat liever zelf in de hand dan via de marstek app Hier zit alle zonnepanelen "kennis" en p1 waardes al in home assistant. Gaan nog wel heel wat uurtjes in zitten om het volgende voor elkaar te krijgen:

3 marsteks (allemaal eigen fase) met eigen esphome modbus controller

doelen:
SOC gelijk zien te houden van de 3 batterijen.
overdag opladen met zonne energie. (wellicht tot max 90% vol).
proberen het verbruik op nul te houden.

Iemand dit al voor elkaar?

Later nog eens kijken naar "handelen" van energie...

Jawel, met een Jullix EMS werkt dat perfect met die Marstek CT003 is het huilen met de pet op , de ene batterij gaat de andere opladen, de syncronisatie is niet OK, de reactietijd is te traag, kortom brol op wieltjes

Maar waarom opladen tot 90% De batterijen worden maar perfect uitgebalanceerd als ze tot 100% opgeladen worden , die 100% houdt toch maximum een halve dag aan vooraleer ze weer beginnen te ontladen dus ....

[savale]

Goede14 schreef op donderdag 10 april 2025 @ 08:46:
[...]


Jawel, met een Jullix EMS werkt dat perfect met die Marstek CT003 is het huilen met de pet op , de ene batterij gaat de andere opladen, de syncronisatie is niet OK, de reactietijd is te traag, kortom brol op wieltjes

Maar waarom opladen tot 90% De batterijen worden maar perfect uitgebalanceerd als ze tot 100% opgeladen worden , die 100% houdt toch maximum een halve dag aan vooraleer ze weer beginnen te ontladen dus ....

Inmiddels beter ingelezen. Lithium ion heeft wel baat bij max opladen tot 90%. Bij LifePo4 is het beter om niet zo diep te ontladen. Opladen tot 100% is niet perse slecht voor de levensduur.

De Jullix EMS ken ik nog niet, maar lijkt inderdaad handig. Ik ga denk ik wel de handmatige route eerst proberen: ik heb alle info al (P1 data / weersvoorspelling / solar opbrengst...), dus het is een kwestie van een goed script maken. (snap wel dat dit lastig gaat worden )

[JanAllElectric]

elgringo schreef op woensdag 9 april 2025 @ 23:13:
..............

Zodra ik de mode in 'manual' zet. wordt de status '6' (omloopstatus). ik weet niet wat dit is, deze is ook niet te vinden in: https://duravolt.nl/wp-co...lug-in-Battery-Modbus.pdf
Status even genegeerd. Ik heb:
42000 staat op 0x55aa zodat modbus werkt
43000 staat op 0, manual
42010 staat op 2: discharge
42021 staat op 100: 100 watt ontladen.

......................

Ik krijg 2 Marsteks eind van de maand. Ik ben nu al bezig met aansturing via HA/Node-Red. Ik ga voornamelijk NOM werken dus veel wisselingen in charge en discharge.

Vraagje. Moet je charge, discharge en stop (42010) iedere keer meesturen samen met de hoeveelheid bv 500W. Tot nu toe ging ik ervan uit dat 500W naar "forcible charge (42020)" of "forcible discharge (42021)" sturen voldoende was en dat 0W gelijk is aan "stop".

[kaasmakert]

Eerste versie van de PCB is binnen, hieronder werkend te zien.
Tevens te zien is een probeersel van onderkant behuizing, om de maatvoering te checken.
Aan de linkerkant is er ruimte om de connector weg te werken. Een passende connector is onderweg uit China.

-Vanavond hopelijk 3D print behuizing afmaken/testen
-Dit weekend alles documenteren en eerste versie op GitHub plaatsen.

[SatScan]

JanAllElectric schreef op donderdag 10 april 2025 @ 09:35:
[...]


Ik krijg 2 Marsteks eind van de maand. Ik ben nu al bezig met aansturing via HA/Node-Red. Ik ga voornamelijk NOM werken dus veel wisselingen in charge en discharge.

Vraagje. Moet je charge, discharge en stop (42010) iedere keer meesturen samen met de hoeveelheid bv 500W. Tot nu toe ging ik ervan uit dat 500W naar "forcible charge (42020)" of "forcible discharge (42021)" sturen voldoende was en dat 0W gelijk is aan "stop".

Mijn ervaringen tot nu toe moet je alle waardes moet meesturen en op 0 zetten als stop werkt bij mij niet binnen HA

[Hometek]

Ik ben bezig om de Marstek als backup aan mijn huisinstallatie te koppelen (zie deze post in het andere Marstek topic).
Bij de test kwam ik er achter dat de BACKUP aansluiting op de Venus E inverter niet geaard is als de GRID aansluiting afgekoppeld is. Gezien de aard van het product, een losse batterij met een backup stopcontact is het een verklaarbare keuze van Marstek om de nul van de backup niet vast met aarde te verbinden.
Sommige inverters hebben een relais om de nul-aarde verbinding (N-E bounding) aan of uit te zetten afhankelijk van de actieve aansluitingen.
Weet iemand hier of de Marstek Venus een N-E bounding relais heeft?
En als dat er is, kun je het relais via modbus aansturen? Ik heb in de Duravolt 485 protocol pdf gezocht, maar zag niets dat aan aarding gerelateerd lijkt.
Voorlopig ga ik de aarding met een extern relais oplossen, maar ik zou graag weten of het ook via modbus zou kunnen.

[Edvd1]

SatScan schreef op woensdag 9 april 2025 @ 19:30:
[...]

Heb je de AI functie gekozen? Dan is dat het, zet op anti-feed (NOM) dan blijft de stand behouden.

Nee, zeker niet. Gewoon in de app de de "zelf geïnitieerde zelfconsumptiemodel" gekozen. Vandaag is hij 3x terug naar Manual gesprongen. Ik zal de enige zijn denk ik haha.
Marstek – Plug & Charge Thuisbatterij 5.12 kWh, Apparaat v148, App v1.6.30.

[matrag]

Edvd1 schreef op donderdag 10 april 2025 @ 20:21:
[...]


Nee, zeker niet. Gewoon in de app de de "zelf geïnitieerde zelfconsumptiemodel" gekozen. Vandaag is hij 3x terug naar Manual gesprongen. Ik zal de enige zijn denk ik haha.
Marstek – Plug & Charge Thuisbatterij 5.12 kWh, Apparaat v148, App v1.6.30.

Als de batterij terugkeert naar handmatig, houdt dit in mijn geval verband met het overschrijden van het maximale vermogen (max. 2500 W, maar kan worden aangepast via Modbus).
Ik heb een automatisering gemaakt die deze verandering detecteert en onder bepaalde omstandigheden de batterij opnieuw activeert in de automatische modus.
(vertaling door Google omdat ik Frans ben)

[superduper1969]

Startpost bijgewerkt met tekening kabel en model stekker Weipu SP17 met dank aan @kaasmakert

[Edvd1]

matrag schreef op donderdag 10 april 2025 @ 22:10:
[...]
Als de batterij terugkeert naar handmatig, houdt dit in mijn geval verband met het overschrijden van het maximale vermogen (max. 2500 W, maar kan worden aangepast via Modbus).
Ik heb een automatisering gemaakt die deze verandering detecteert en onder bepaalde omstandigheden de batterij opnieuw activeert in de automatische modus.
(vertaling door Google omdat ik Frans ben)

Dank voor je antwoord. Prima vertaling denk ik
Ik zie het volgens mij ook terug in homeassistant, de modus wijzigt steeds tijdens het laden. Ik zet hem vervolgens handmatig weer terug.

Zou je je automation willen delen/ of me op weg kunnen helpen? Thanks!

[elgringo]

Als ik de batterij in 'manual' zet wordt de status 6 (address 35100); omloopstatus. Wat betekend dit>

Ik krijg hem nog steeds niet aan de gang om de met de hand op te laden. terwijl
42010 en 42020 wel goed staan.

Wie heeft nog ideeen?

of werk manualmode alleen als je een charge / discharge timer hebt? en de force laden en ontladen dus niet

Edit:
Ik heb het tijdschema gepakt om te laten en de ontladen (register 43100 tm 43104). Dit werkt wel, geforceerd laden op commando lijk ik niet aan de praat te kunnen krijgen

[ Voor 38% gewijzigd door elgringo op 11-04-2025 14:52 ]

[kaasmakert]

Eerste versie van wat nu "MarstekMonitor" heet, draait!



3D geprinte behuizing met daarin alles om de Marstek te monitoren (en aan te sturen via ESPHome/HA).
Connector zit in het kastje en plugt rechtstreeks in de RS485 poort.
Kastje is daarbij draaibaar zodat je zelf kan kiezen hoe het display zit.
Uiteraard wordt alle data ook doorgestuurd naar Home Assistant

Alle files zijn te vinden in bovenstaande GitHub repo.

Paar verbeteringen die ik nog door ga voeren:
-Behuizing kan nog een slag compacter en strakker geprint worden
-Ruimte maken voor contramoer aan de binnenkant
-Text meer gecentreerd weergeven
-Kleine bugfix op het PCB
-Beschrijving en how-to maken

[Babavers]

elgringo schreef op vrijdag 11 april 2025 @ 10:47:
Als ik de batterij in 'manual' zet wordt de status 6 (address 35100); omloopstatus. Wat betekend dit>

Ik krijg hem nog steeds niet aan de gang om de met de hand op te laden. terwijl
42010 en 42020 wel goed staan.

Wie heeft nog ideeen?

of werk manualmode alleen als je een charge / discharge timer hebt? en de force laden en ontladen dus niet

Edit:
Ik heb het tijdschema gepakt om te laten en de ontladen (register 43100 tm 43104). Dit werkt wel, geforceerd laden op commando lijk ik niet aan de praat te kunnen krijgen

Wil je met de hand laden (modus manual in de app) dan heb je inderdaad een (ontlaad)schema nodig. In de app kan je die trouwens ook niet op hand zetten zonder tenminste één schema aan te maken.
Hiervoor moet je via modbus 42000 op 'disable' zetten (of dat gebeurt vanzelf als je op de app 'manual' kiest).
Wil je via modbus (geforceerd) het laden en ontladen aansturen dan moet je ten eerste 42000 op 'enable' zetten.
Dan kies je op 42010 de juiste modus en via 42020 en/of 42021 het juiste vermogen. Maar dit laatste werkt alleen als 42000 op de juiste modus staat. Zo werkt het bij mij feilloos en daarmee stuur ik 2 batterijen synchroon aan naar nom zonder dat er oscilaties ontstaan en/of de ene begint te laden terwijl de andere aan het ontladen is.

Je moet natuurlijk ook wel zorgen dat 44000 en 44001 juist staan, maar dat zet je normaal op zijn uiterste en verder blijf je daar af. Hetzelfde voor 42011, 44002 en 44003.

[superduper1969]

MarstekMonitor van kaasmakert en Venus-Control van Edzelf toegevoegd aan de startpost.

[Avenger 2.0]

Goede14 schreef op donderdag 10 april 2025 @ 08:46:
[...]
Jawel, met een Jullix EMS werkt dat perfect met die Marstek CT003 is het huilen met de pet op , de ene batterij gaat de andere opladen, de syncronisatie is niet OK, de reactietijd is te traag, kortom brol op wieltjes

Maar waarom opladen tot 90% De batterijen worden maar perfect uitgebalanceerd als ze tot 100% opgeladen worden , die 100% houdt toch maximum een halve dag aan vooraleer ze weer beginnen te ontladen dus ....

Hier de pre-order gedaan van Marstek en Jullix EMS. Zijn ze deze al komen installeren bij jou of zelf gedaan?
Hoe zijn je ervaringen met de Jullix en Marstek? Bepaalde nadelen? Werkt deze ook op 2500W ontladen?

[elgringo]

Babavers schreef op vrijdag 11 april 2025 @ 15:23:
[...]

Wil je met de hand laden (modus manual in de app) dan heb je inderdaad een (ontlaad)schema nodig. In de app kan je die trouwens ook niet op hand zetten zonder tenminste één schema aan te maken.
Hiervoor moet je via modbus 42000 op 'disable' zetten (of dat gebeurt vanzelf als je op de app 'manual' kiest).
Wil je via modbus (geforceerd) het laden en ontladen aansturen dan moet je ten eerste 42000 op 'enable' zetten.
Dan kies je op 42010 de juiste modus en via 42020 en/of 42021 het juiste vermogen. Maar dit laatste werkt alleen als 42000 op de juiste modus staat. Zo werkt het bij mij feilloos en daarmee stuur ik 2 batterijen synchroon aan naar nom zonder dat er oscilaties ontstaan en/of de ene begint te laden terwijl de andere aan het ontladen is.

Je moet natuurlijk ook wel zorgen dat 44000 en 44001 juist staan, maar dat zet je normaal op zijn uiterste en verder blijf je daar af. Hetzelfde voor 42011, 44002 en 44003.

Plan is om via modbus te laden. igv laden heb ik:
42000 heb ik op enable gezet (0x55aa), ik dacht dat dit nodig was om uberhaupt aansturing via modbus te
doen
42010 op 1
42020 op 100 (voor 100 watt laden)
44000 op 1000 (100%)
44001 op 200 (20%)
42011 gebruik ik niet. ik dat dat force charge/discharge genoeg is.
44002 op 2500
44003 ook op 2500

Als ik je post zo lees dat denk ik wat dat ik met 42011 moet, maar het is mij onbeken d wat dit register precies doet

[Babavers]

elgringo schreef op vrijdag 11 april 2025 @ 20:08:
[...]


Plan is om via modbus te laden. igv laden heb ik:
42000 heb ik op enable gezet (0x55aa), ik dacht dat dit nodig was om uberhaupt aansturing via modbus te
doen
42010 op 1
42020 op 100 (voor 100 watt laden)
44000 op 1000 (100%)
44001 op 200 (20%)
42011 gebruik ik niet. ik dat dat force charge/discharge genoeg is.
44002 op 2500
44003 ook op 2500

Als ik je post zo lees dat denk ik wat dat ik met 42011 moet, maar het is mij onbeken d wat dit register precies doet

42011 staat bij mij op 0. Ik neem aan dat wanneer je dat op bv. 50 zet, dat het laden dan zal stoppen zodra SoC 50% is. Maar wat dan juist het verschil is met charging cutt-off weet ik ook niet. Ik heb er niet mee geëxperimenteerd.

[Maxwp]

Babavers schreef op vrijdag 11 april 2025 @ 21:56:
[...]

42011 staat bij mij op 0. Ik neem aan dat wanneer je dat op bv. 50 zet, dat het laden dan zal stoppen zodra SoC 50% is. Maar wat dan juist het verschil is met charging cutt-off weet ik ook niet. Ik heb er niet mee geëxperimenteerd.

.het minimale behoord 11% te zijn niet 0.

[JorisLammar]

savale schreef op woensdag 9 april 2025 @ 23:09:
Super tof dat ze via modbus / esphome kunnen worden aangestuurd. Heb dat liever zelf in de hand dan via de marstek app Hier zit alle zonnepanelen "kennis" en p1 waardes al in home assistant. Gaan nog wel heel wat uurtjes in zitten om het volgende voor elkaar te krijgen:

3 marsteks (allemaal eigen fase) met eigen esphome modbus controller

doelen:
SOC gelijk zien te houden van de 3 batterijen.
overdag opladen met zonne energie. (wellicht tot max 90% vol).
proberen het verbruik op nul te houden.

Iemand dit al voor elkaar?

Later nog eens kijken naar "handelen" van energie...

Ik ben net terug van een weekje vakantie en de batterijen hebben netjes hun werk gedaan (totaal geen verbruik van het net gehaald). Ik heb 3 marsteks die nu synchroon laden en ontladen. Routine is een combinatie van een simpele Python met een script en een automation die de script draaiende houdt. Indien interesse wil ik de code wel delen.
Ik ga de volgende weken wel werken aan het optimaliseren van het laden (zie vorige posts). Het rendement is beter om in hogere vermogens te werken. Dus niet synchroon laden/ontladen, maar zoveel mogelijk concentreren naar 1 batterij (rekening houden met de onbalans op de fases). Zit momenteel nog in idee-fase.

[Svs79]

Vraagje, ik ben zelf niet zo goed in programmeren e.d.
is er iemand die me een modbus sturing kan maken voor 3 marsteks?
Mag evt via pb. Thanks!

[Njord1]

JorisLammar schreef op zondag 13 april 2025 @ 12:00:
[...]


Ik ben net terug van een weekje vakantie en de batterijen hebben netjes hun werk gedaan (totaal geen verbruik van het net gehaald). Ik heb 3 marsteks die nu synchroon laden en ontladen. Routine is een combinatie van een simpele PHP met een script en een automation die de script draaiende houdt. Indien interesse wil ik de code wel delen.
Ik ga de volgende weken wel werken aan het optimaliseren van het laden (zie vorige posts). Het rendement is beter om in hogere vermogens te werken. Dus niet synchroon laden/ontladen, maar zoveel mogelijk concentreren naar 1 batterij (rekening houden met de onbalans op de fases). Zit momenteel nog in idee-fase.

Misschien een idee om het in de startpost te laten zetten?

[Eastman]

Svs79 schreef op zondag 13 april 2025 @ 12:40:
Vraagje, ik ben zelf niet zo goed in programmeren e.d.
is er iemand die me een modbus sturing kan maken voor 3 marsteks?
Mag evt via pb. Thanks!

Ik zit in dezelfde boot. Eind van de maand verwacht ik 3 Marsteks. Configureren lukt me nog wel, maar hardware maken en programmeren is een stap te ver.

Ik zou graag een modbus koppeling willen die ik met homey pro flows kan aansturen.

[Njord1]

Svs79 schreef op zondag 13 april 2025 @ 12:40:
Vraagje, ik ben zelf niet zo goed in programmeren e.d.
is er iemand die me een modbus sturing kan maken voor 3 marsteks?
Mag evt via pb. Thanks!

Zie startpost. https://gathering.tweakers.net/forum/list_messages/2282240/0

[ Voor 11% gewijzigd door Njord1 op 13-04-2025 12:58 ]

[JorisLammar]

Njord1 schreef op zondag 13 april 2025 @ 12:52:
[...]

Misschien een idee om het in de startpost te laten zetten?

Zal ik doen als ik de verbeterde code heb ontwikkel (moet eerst nog een spoedcursus Python volgen). Heb nog niet veel ervaring met Tweakers. Hoe zit ik dat bij de startpost? Misschien aan Superduper1969 overlaten?

[PVerga]

Ik heb mijn Marstek batterij nu een maand operationeel en wil mijn ervaringen en benadering delen, misschien is het nuttig voor iemand.
Situatie:
Enkelfasige electrische installatie, dynamisch electriciteitstarief.
Bestaande oudere 3,8 kWp PV installatie met niet gekoppelde (domme) inverter.
Bestaande Shelly Pro 3EM in enkelfasige configuratie met ct klemmen op de net aansluiting, pv omvormer en laadstation phev.
Bestaand Loxone home automation systeem onder eigen beheer.
En dus de Marstek Venus met de modbus koppeling zoals gedocumenteerd door Superduper1969 maar met Waveshare RS232/485 TO POE ETH convertor (ik wou standaard product met bekabelde netwerk verbinding met POE voeding).

Objectief:
Optimalisatie zelfvervbruik (NOM) voor huishoudelijk verbruik, phev enkel opladen wanneer er PV surplus is (PV overschot na aftrek eventuele laadstroom batterij en huishoudelijk verbruik) of tijdens goedkoopste uren dynamisch tarief (=uren in laagste prijskwadrant van de dag).
Nooit batterij wagen opladen vanuit Marstek batterij, tenzij manueel zo gekozen.
Wanneer er voor een dag niet voldoende PV opbrengst wordt voorspeld voor het opladen van de battterij, bijladen tijdens goedkoopste uren dynamisch tarief.
Vermits mijn wagen een phev is, heeft het laden van de Marstek battterij steeds voorrang op het laden van de wagen.

Aanpak:
Vermits ik de Marstek enkel wil gebruiken voor optimalisatie huishoudelijk verbruik, dus los van phev laden en ik reeds beschikte over de Shelly, heb ik de CT003 in de doos gelaten en een Shelly emulator gebouwd in Loxone.
Dus zo lang de phev laadstroom nul is, standaard NOM.
Wanneer de phev laadstroom > 0: NOM = net - laadstroom phev.
Phev begint met laden wanneer de export naar het net > 700W is (gemiddelde laatste 2 minuten). Hysteresis om te stoppen met laden op 2000W net import om flip-flop effect te voorkomen wanneer huishoudelijk ergens iets kort wordt ingeschakeld.
De 700W is ongeveer de helft van het minimale laadvermogen van mijn laadstation, ik kan het laden sturen tussen min. 6A en max. 16A.
Daarnaast start de phev met laden tijdens de goedkoopste uren dynamisch tarief laadstroom gespreid over aantal goedkoopste uren.

De Marstek blijkt dus permanent op Auto (zelfconsumptie) staan en ik manipuleer de net meting van de Shelly om te sturen naar wens.
Ik lees dan de laadstroom van de Marstek om de 2 seconden voor de terugkoppeling en herberekening NOM.
Momenteel heb ik naast de normale NOM werking volgende bijsturingen:
- Marstek laden aan manueel ingesteld aantal Watt ipv NOM target. Gebruik ik wanneer pv opbrengst sterk afwijkt van voorspelling of om ruimte te geven in PV overschot om wagen bij te laden aan NOM.
- Spreiden van de laadstroom op dagen met negatieve uurprijzen, zodat de SOC van de batterij nog laag genoeg is wanneer de prijzen negatief worden. Dagen met negatieve prijzen zijn gewoonlijk zeer zonnig dus risico dat de batterij dan te snel vol is met laden aan NOM.
- Bijladen van de batterij aan instelbaar vermogen wanneer de SOC daalt onder x% tot terug aan y% met de bedoeling de backup uitgang steeds aktief te houden. (Maar ik denk eraan de backup piste op te geven en deze optie evt te verwijderen, Marstek is geen UPS)
- Bijladen van de Marstek tijdens de goedkoopste uren dynamisch tarief wanneer er niet voldoende PV opbrengst wordt verwacht.

Gezien de overvloed aan zon de afgelopen maand heeft deze laatste optie nog geen dienst gedaan en is wat fine tuning waarschijnlijk nog wel aan de orde.
Op dit ogenblik is de enige modbus sturing die ik gebruik voor de Marstek een toggle tussen auto en manual, dit laatste om de Marstek ‘inactief’ te maken wanneer gewenst.
Tot nu toe werkt deze benadering prima voor mij, de NOM volging van de Marstek is zeker goed genoeg. Marstek firmware v148.

Enkele screen shots, merk op dat Loxone het laden van de battterij niet beschouwt als zelfconsumptie. Discutabel maar wat telt is % export te minimaliseren:

[Edzelf]

Svs79 schreef op zondag 13 april 2025 @ 12:40:
Vraagje, ik ben zelf niet zo goed in programmeren e.d.
is er iemand die me een modbus sturing kan maken voor 3 marsteks?
Mag evt via pb. Thanks!

Denk dat het wel lukt met mijn "Venus-control". Kan helaas zelf niet testen met 3 stuks, maar wellicht samenwerken? Zie de documentatie. Daar vindt je ook m'n mail-adres.

[Maxwp]

kaasmakert schreef op vrijdag 11 april 2025 @ 11:06:
Eerste versie van wat nu "MarstekMonitor" heet, draait!

[Afbeelding]

[Afbeelding]

[Afbeelding]

3D geprinte behuizing met daarin alles om de Marstek te monitoren (en aan te sturen via ESPHome/HA).
Connector zit in het kastje en plugt rechtstreeks in de RS485 poort.
Kastje is daarbij draaibaar zodat je zelf kan kiezen hoe het display zit.
Uiteraard wordt alle data ook doorgestuurd naar Home Assistant

Alle files zijn te vinden in bovenstaande GitHub repo.

Paar verbeteringen die ik nog door ga voeren:
-Behuizing kan nog een slag compacter en strakker geprint worden
-Ruimte maken voor contramoer aan de binnenkant
-Text meer gecentreerd weergeven
-Kleine bugfix op het PCB
-Beschrijving en how-to maken

Is de bedoeling dat iedereen dit diy gaat doen of ga of wil je er ook een paar al dan niet voor field testing sturen/maken

[Maxwp]

PVerga schreef op zondag 13 april 2025 @ 14:38:
Ik heb mijn Marstek batterij nu een maand operationeel en wil mijn ervaringen en benadering delen, misschien is het nuttig voor iemand.
Situatie:
Enkelfasige electrische installatie, dynamisch electriciteitstarief.
Bestaande oudere 3,8 kWp PV installatie met niet gekoppelde (domme) inverter.
Bestaande Shelly Pro 3EM in enkelfasige configuratie met ct klemmen op de net aansluiting, pv omvormer en laadstation phev.
Bestaand Loxone home automation systeem onder eigen beheer.
En dus de Marstek Venus met de modbus koppeling zoals gedocumenteerd door Superduper1969 maar met Waveshare RS232/485 TO POE ETH convertor (ik wou standaard product met bekabelde netwerk verbinding met POE voeding).

Objectief:
Optimalisatie zelfvervbruik (NOM) voor huishoudelijk verbruik, phev enkel opladen wanneer er PV surplus is (PV overschot na aftrek eventuele laadstroom batterij en huishoudelijk verbruik) of tijdens goedkoopste uren dynamisch tarief (=uren in laagste prijskwadrant van de dag).
Nooit batterij wagen opladen vanuit Marstek batterij, tenzij manueel zo gekozen.
Wanneer er voor een dag niet voldoende PV opbrengst wordt voorspeld voor het opladen van de battterij, bijladen tijdens goedkoopste uren dynamisch tarief.
Vermits mijn wagen een phev is, heeft het laden van de Marstek battterij steeds voorrang op het laden van de wagen.

Aanpak:
Vermits ik de Marstek enkel wil gebruiken voor optimalisatie huishoudelijk verbruik, dus los van phev laden en ik reeds beschikte over de Shelly, heb ik de CT003 in de doos gelaten en een Shelly emulator gebouwd in Loxone.
Dus zo lang de phev laadstroom nul is, standaard NOM.
Wanneer de phev laadstroom > 0: NOM = net - laadstroom phev.
Phev begint met laden wanneer de export naar het net > 700W is (gemiddelde laatste 2 minuten). Hysteresis om te stoppen met laden op 2000W net import om flip-flop effect te voorkomen wanneer huishoudelijk ergens iets kort wordt ingeschakeld.
De 700W is ongeveer de helft van het minimale laadvermogen van mijn laadstation, ik kan het laden sturen tussen min. 6A en max. 16A.
Daarnaast start de phev met laden tijdens de goedkoopste uren dynamisch tarief laadstroom gespreid over aantal goedkoopste uren.

De Marstek blijkt dus permanent op Auto (zelfconsumptie) staan en ik manipuleer de net meting van de Shelly om te sturen naar wens.
Ik lees dan de laadstroom van de Marstek om de 2 seconden voor de terugkoppeling en herberekening NOM.
Momenteel heb ik naast de normale NOM werking volgende bijsturingen:
- Marstek laden aan manueel ingesteld aantal Watt ipv NOM target. Gebruik ik wanneer pv opbrengst sterk afwijkt van voorspelling of om ruimte te geven in PV overschot om wagen bij te laden aan NOM.
- Spreiden van de laadstroom op dagen met negatieve uurprijzen, zodat de SOC van de batterij nog laag genoeg is wanneer de prijzen negatief worden. Dagen met negatieve prijzen zijn gewoonlijk zeer zonnig dus risico dat de batterij dan te snel vol is met laden aan NOM.
- Bijladen van de batterij aan instelbaar vermogen wanneer de SOC daalt onder x% tot terug aan y% met de bedoeling de backup uitgang steeds aktief te houden. (Maar ik denk eraan de backup piste op te geven en deze optie evt te verwijderen, Marstek is geen UPS)
- Bijladen van de Marstek tijdens de goedkoopste uren dynamisch tarief wanneer er niet voldoende PV opbrengst wordt verwacht.

Gezien de overvloed aan zon de afgelopen maand heeft deze laatste optie nog geen dienst gedaan en is wat fine tuning waarschijnlijk nog wel aan de orde.
Op dit ogenblik is de enige modbus sturing die ik gebruik voor de Marstek een toggle tussen auto en manual, dit laatste om de Marstek ‘inactief’ te maken wanneer gewenst.
Tot nu toe werkt deze benadering prima voor mij, de NOM volging van de Marstek is zeker goed genoeg. Marstek firmware v148.

Enkele screen shots, merk op dat Loxone het laden van de battterij niet beschouwt als zelfconsumptie. Discutabel maar wat telt is % export te minimaliseren:
[Afbeelding]

[Afbeelding]

De andere waveshare zonder wifi maar met eth werken ook gewoon uitwisselbaar met elkaar dus?
Ben zelf okk wel meer fan van een vaste kabel dan draadloos

[superduper1969]

JorisLammar schreef op zondag 13 april 2025 @ 12:00:
[...]


Ik ben net terug van een weekje vakantie en de batterijen hebben netjes hun werk gedaan (totaal geen verbruik van het net gehaald). Ik heb 3 marsteks die nu synchroon laden en ontladen. Routine is een combinatie van een simpele Python met een script en een automation die de script draaiende houdt. Indien interesse wil ik de code wel delen.
Ik ga de volgende weken wel werken aan het optimaliseren van het laden (zie vorige posts). Het rendement is beter om in hogere vermogens te werken. Dus niet synchroon laden/ontladen, maar zoveel mogelijk concentreren naar 1 batterij (rekening houden met de onbalans op de fases). Zit momenteel nog in idee-fase.

Top!, Zet het op Github en dan kan ik het verwerken in de startpost.

[AUijtdehaag]

Ik heb inmiddels een m5stack RS485 base met Atom S3r (display) werkend
Probleem was dat de ingebouwde DC/DC buck converter van de 5.1V die hij aangebood kreeg, er 4,5V van maakte waardoor de ESP bleef rebooten.

Ik heb de buck converter gebypassed met een draadje gesoldeerd op de onderzijde printplaatje en nu krijgt de esp32s3 gewoon 5.1V voor zijn kiezen. Problem solved

Verder ben ik sinds gisteren avond met de nodered flow van @Babavers aan de gang, welke gecontroleerd 2 batterijen laat werken. Hartelijk dank daarvoor.
Met kleine aanpassingen werkt dit ook op 1 batterij. Ik heb er "voorlopig" maar 1.
Eindelijk NOM dankzij deze aansturing via esphome en nodered..

De APP werking was ik na een week als nieuwe eigenaar van de MT al behoorlijk beu met V149.
Ik hoef er nu niet meer naar te kijken

Nu werkt het eindelijk zoals het hoort (nog een paar dagen aankijken)
P1 HW als meter elke 5 sec (kan per 1 sec via nodered flow en http uitlezen van de dsmr5, maar als het zo ook werkt vind ik het prima)

Toch wel fijn om niet meer afhankelijk te zijn van die ontwikkelaars
Al een paar keer een bericht gestuurd via de app maar geen reakties tot nog toe.
De MT was veel te veel ongecontroleerd aan het laden en ontladen. Of deed die niks.

@superduper1969 jij ook bedankt uiteraard voor de modbus code en onderhouden van dit topic.
Heel fijn die tweakers community,

[ Voor 22% gewijzigd door AUijtdehaag op 13-04-2025 21:35 ]

[PVerga]

Maxwp schreef op zondag 13 april 2025 @ 19:32:
[...]

De andere waveshare zonder wifi maar met eth werken ook gewoon uitwisselbaar met elkaar dus?
Ben zelf okk wel meer fan van een vaste kabel dan draadloos

Ik denk wel dat dit zal werken, voor zo ver ik me herinner zijn hun convertors zeer gelijkaardig qua instellingen.
Documentatie is wel ‘chinese style’ dus heb even even moeten experimenteren om het goed te krijgen.
Ook firmware upgrade moeten doen en daar heb ik hun hulp voor moeten inroepen, maar hun support is goed.
Ik werk in de Modbus TCP <==> Modbus RTU mode, de rest van de instellingen is vrij vanzelfsprekend.

[Maxwp]

PVerga schreef op zondag 13 april 2025 @ 21:37:
[...]


Ik denk wel dat dit zal werken, voor zo ver ik me herinner zijn hun convertors zeer gelijkaardig qua instellingen.
Documentatie is wel ‘chinese style’ dus heb even even moeten experimenteren om het goed te krijgen.
Ook firmware upgrade moeten doen en daar heb ik hun hulp voor moeten inroepen, maar hun support is goed.
Ik werk in de Modbus TCP <==> Modbus RTU mode, de rest van de instellingen is vrij vanzelfsprekend.

In de begin post is de wifi versie gebruikt jij hebt al de eth versie dus werkt het gewoon of wat bedoel je met dat he wel denkt dat het zal werken ? Je hebt de eth versie nu al draaien

[matrag]

Goedeavond,

Voor de geïnteresseerden heb ik wat efficiëntietesten gedaan: door de waarden 32102 (batterijvermogen) en 32202 (wisselstroom) te vergelijken. Tijdens mijn tests had mijn batterij een SOC van 50%.

Tijdens het opladen is de waarde van het batterijvermogen lager dan die van wisselstroom.
Bij het ontladen is de waarde van het batterijvermogen groter dan die van wisselstroom.
Ik heb een thuisassistent-sjabloon berekend met de verhouding van de twee, afhankelijk van opladen of ontladen.

Hier zijn de resultaten:

Aanval :
100W: varieert van 30% tot 75%
200W: 80%
500W: 91%
1000W: 91%
2000W: 91%
2500W: 91%

Dumpen:
100W: varieert van 30% tot 75%
200 W: 86% tot 95%
500W: 95%
1000W: 97%
1500W: 97%
2000W: 96%
2500W: 96%

Het is dus interessanter om de batterij met een vermogen van +500 W te gebruiken, zowel bij opladen als ontladen.
Ontladen heeft een beter rendement dan opladen.

Franse vertaling door Google

[bruneelm]

En staat voor die rendementstesten de waarde van de omvormer continue op 2500W of voor de laagste vermogens op 800W?

[PVerga]

Maxwp schreef op zondag 13 april 2025 @ 22:13:
[...]
In de begin post is de wifi versie gebruikt jij hebt al de eth versie dus werkt het gewoon of wat bedoel je met dat he wel denkt dat het zal werken ? Je hebt de eth versie nu al draaien

Sorry, had je verkeerd begrepen en dacht dat je vraag ging over het gebruiken van een ander Waveshare model zonder WiFi.
Vaste netwerk verbinding, in mijn geval met POE voor de voeding van de Waveshare, werkt vlekkeloos.

[superduper1969]

matrag schreef op zondag 13 april 2025 @ 22:16:
Goedeavond,

Voor de geïnteresseerden heb ik wat efficiëntietesten gedaan: door de waarden 32102 (batterijvermogen) en 32202 (wisselstroom) te vergelijken. Tijdens mijn tests had mijn batterij een SOC van 50%.

Tijdens het opladen is de waarde van het batterijvermogen lager dan die van wisselstroom.
Bij het ontladen is de waarde van het batterijvermogen groter dan die van wisselstroom.
Ik heb een thuisassistent-sjabloon berekend met de verhouding van de twee, afhankelijk van opladen of ontladen.

Hier zijn de resultaten:

Aanval :
100W: varieert van 30% tot 75%
200W: 80%
500W: 91%
1000W: 91%
2000W: 91%
2500W: 91%

Dumpen:
100W: varieert van 30% tot 75%
200 W: 86% tot 95%
500W: 95%
1000W: 97%
1500W: 97%
2000W: 96%
2500W: 96%

Het is dus interessanter om de batterij met een vermogen van +500 W te gebruiken, zowel bij opladen als ontladen.
Ontladen heeft een beter rendement dan opladen.

Franse vertaling door Google

Merci, Dat komt aardig overeen met mijn eerdere test: https://gathering.tweaker...message/81761006#81761006

[Gwaihir]

Gwaihir schreef op zaterdag 29 maart 2025 @ 16:22:
Leuke berekening, maar ik houd het er toch op dat deze claims over AC-laden en off-grid functionaliteit van de Jupiter complete BS zijn. (Evenals de claim op de Duravolt site dat het ding een USB-A poort heeft.)

Ik heb er over gemaild, maar het blijft erg stil.

Heb me hier vorige week maar 'ns kwaad over gemaakt. Het is tenslotte Marstek zelf die deze 'info' op de site had staan. En ik herinnerde me dat het mij ook nogal verward had, tijdens het uitzoeken van zo'n apparaat. (Daarna met de Engelstalige site verder gegaan en die had die onzin er niet op staan.)

Afijn: het is er nu af . De Jupiter C/E kan inderdaad niet laden vanaf AC en er is ook niets (zelfstandig) off-grid aan. (Nu niet, nooit niet.)

@superduper1969

[Sangoes]

Thx @superduper1969. Ben er leuk mee aan de slag kunnen gaan.

Wel vraag ik mij af waarom deze sensoren extra gemaakt worden?

code:

sensor:
    - platform: integration
      name: Marstek Discharging in kWh
      unique_id: marstek_battery_discharging_in_kwh
      source: sensor.marstek_battery_discharging_in_w
      round: 2
      unit_prefix: k
      unit_time: h
      method: left
    - platform: integration
      name: Marstek Battery Charging in kWh
      unique_id: marstek_battery_charging_in_kwh
      source: sensor.marstek_battery_charging_in_w
      round: 2
      unit_prefix: k
      unit_time: h
      method: left

Deze haal je ook in feite op uit de Marstek via Modbus?
Dat zelfde geldt eigenlijk voor die utility sensoren.
Is er een reden waarom je ze dubbel laat lopen?

[william.geurts]

Hallo, ik heb sinds een kleine week de accu en de Lilygo interface in Homeassistant. Ik heb de led gedimd, maar af en toe spring deze weer terug naar 100%. Zie melding in HA:



Bij nadere controle zie ik dat alle sensoren uitvallen en een minuut later weer werken.



Kan iemand dat verklaren?

Daarnaast zie ik soms een rode streep onder de 0% bij SOC waarde. Hier heb ik geen schermafdruk van. Het lijkt bij een volle batterij te zijn.

Laatste vraag, de WIFi status via de LED is dat de Marstek WIFI status of die vn de LilyGo?

[ Voor 35% gewijzigd door william.geurts op 17-04-2025 14:04 ]

[SatScan]

william.geurts schreef op donderdag 17 april 2025 @ 14:02:
Hallo, ik heb sinds een kleine week de accu en de Lilygo interface in Homeassistant. Ik heb de led gedimd, maar af en toe spring deze weer terug naar 100%. Zie melding in HA:

[Afbeelding]

Bij nadere controle zie ik dat alle sensoren uitvallen en een minuut later weer werken.

[Afbeelding]

Kan iemand dat verklaren?

Daarnaast zie ik soms een rode streep onder de 0% bij SOC waarde. Hier heb ik geen schermafdruk van. Het lijkt bij een volle batterij te zijn.

Laatste vraag, de WIFi status via de LED is dat de Marstek WIFI status of die vn de LilyGo?

1) Lijkt op dat er soms onvoldoende vermogen is voor je lilygo en hierdoor een reboot doet en hierdoor de led weer op 100%. Probeer eens een tijdje met een extra voeding of het dan verholpen is.
2) Geeft de wifi ontvangst van je lilygo aan.


PS als je zoek in topic kom je berichten tegen mbt verschillende versie ligygo irt het gevraagde vermogen.

[superduper1969]

Aanpassing TS en Lilygo config
Bitmask voor error codes nu correct in HEX met dank aan pascallj

[superduper1969]

Sangoes schreef op woensdag 16 april 2025 @ 21:14:
Thx @superduper1969. Ben er leuk mee aan de slag kunnen gaan.

Wel vraag ik mij af waarom deze sensoren extra gemaakt worden?

code:

sensor:
    - platform: integration
      name: Marstek Discharging in kWh
      unique_id: marstek_battery_discharging_in_kwh
      source: sensor.marstek_battery_discharging_in_w
      round: 2
      unit_prefix: k
      unit_time: h
      method: left
    - platform: integration
      name: Marstek Battery Charging in kWh
      unique_id: marstek_battery_charging_in_kwh
      source: sensor.marstek_battery_charging_in_w
      round: 2
      unit_prefix: k
      unit_time: h
      method: left

Deze haal je ook in feite op uit de Marstek via Modbus?
Dat zelfde geldt eigenlijk voor die utility sensoren.
Is er een reden waarom je ze dubbel laat lopen?

In het begin was de Marstek Firmware niet correct in het weergeven van deze waarden dus ik laat ze berekenen.
Geen idee of het nu gefixed is met al die nieuwe FW versies of anders is als je met een nieuwere FW bent gestart.
Andere reden is omdat ze anders niet te integreren zijn voor de volgende stap als Utility meter voor in het Energy Dashboard. Om hieraan te voldoen moet het format geschikt zijn voor Utility Dashboard. Het werkt dus ik heb het nooit meer aangepast.

Ik zie dat het bij mij met V149 nog steeds niet klopt, total is goed, maar daily is veel te hoog en gelijk aan monthly die ook veel te hoog is.

[ Voor 16% gewijzigd door superduper1969 op 18-04-2025 21:59 ]

[pascallj]

superduper1969 schreef op vrijdag 18 april 2025 @ 21:20:
Aanpassing TS en Lilygo config
Bitmask voor error codes nu correct in HEX met dank aan pascallj

Goed om te weten dat je PR's accepteert, want dan heb ik er mogelijk nog veel meer in de aanbieding

[superduper1969]

pascallj schreef op vrijdag 18 april 2025 @ 21:29:
[...]


Goed om te weten dat je PR's accepteert, want dan heb ik er mogelijk nog veel meer in de aanbieding

Voor mij is het ook een ontdekkingstocht, eerste keer dat ik iets op github heb gezet.
Maar leef je uit, alles waar het beter van wordt.

Als je een makkelijk truukje hebt om 41100 modbus adres (eenmalig) te programmeren dan zullen mensen met 2 of 3 accu's ook blij zijn.

Ik zit tegenwoordig wat krap in mijn tijd en heb veel puzzels op mijn werk die aandacht vragen, dus ik doe voornamelijk de TS bijhouden.

[pascallj]

superduper1969 schreef op vrijdag 18 april 2025 @ 21:25:
[...]

Ik zie dat het bij mij met V149 nog steeds niet klopt, total is goed, maar daily is veel te hoog en gelijk aan monthly die ook veel te hoog is.
[Afbeelding]

Je hebt nog een Pull Request

superduper1969 schreef op vrijdag 18 april 2025 @ 21:37:
[...]

Voor mij is het ook een ontdekkingstocht, eerste keer dat ik iets op github heb gezet.
Maar leef je uit, alles waar het beter van wordt.

Als je een makkelijk truukje hebt om 41100 modbus adres (eenmalig) te programmeren dan zullen mensen met 2 of 3 accu's ook blij zijn.

Ik zit tegenwoordig wat krap in mijn tijd en heb veel puzzels op mijn werk die aandacht vragen, dus ik doe voornamelijk de TS bijhouden.

Mooi projectje om ervaring op te doen met dit soort dingen lijkt me zo. Ik heb jouw project als basis gebruikt en ondertussen zelf flink aangepast (gebruik zelf ook geen LilyGo). Ik zal kijken of ik die wijzigingen terug kan laten vloeien het project in.

Het lastige aan het programmeren van het modbus adres is, is dat het moet gebeuren als er geen andere apparaten zijn gekoppeld. Dus makkelijk zal het nooit zijn. Maar ik zal erover nadenken.

Heb wel al een idee om de configuratie te vereenvoudigen voor het aansturen van meerdere apparaten (volgens mij werkt deze zo ook niet). Maar wat was het doel van de meerdere bestanden precies? Meerdere accu's op 1 LilyGo of gewoon meerdere LilyGo's in je ecosysteem?

[superduper1969]

pascallj schreef op vrijdag 18 april 2025 @ 22:24:
[...]


Je hebt nog een Pull Request


[...]


Mooi projectje om ervaring op te doen met dit soort dingen lijkt me zo. Ik heb jouw project als basis gebruikt en ondertussen zelf flink aangepast (gebruik zelf ook geen LilyGo). Ik zal kijken of ik die wijzigingen terug kan laten vloeien het project in.

Het lastige aan het programmeren van het modbus adres is, is dat het moet gebeuren als er geen andere apparaten zijn gekoppeld. Dus makkelijk zal het nooit zijn. Maar ik zal erover nadenken.

Heb wel al een idee om de configuratie te vereenvoudigen voor het aansturen van meerdere apparaten (volgens mij werkt deze zo ook niet). Maar wat was het doel van de meerdere bestanden precies? Meerdere accu's op 1 LilyGo of gewoon meerdere LilyGo's in je ecosysteem?

Ja, voor mezelf maakt het niet uit want ik heb maar 1 accu, maar er zijn er zat die er 2 of 3 hebben binnenkort. Als ze alle 3 bij elkaar staan zou je met 1 lilygo toekunnen, aan de andere kant, ze zijn super goedkoop dus dat moet ook geen probleem zijn.

[Sangoes]

superduper1969 schreef op vrijdag 18 april 2025 @ 21:25:
[...]

In het begin was de Marstek Firmware niet correct in het weergeven van deze waarden dus ik laat ze berekenen.
Geen idee of het nu gefixed is met al die nieuwe FW versies of anders is als je met een nieuwere FW bent gestart.
Andere reden is omdat ze anders niet te integreren zijn voor de volgende stap als Utility meter voor in het Energy Dashboard. Om hieraan te voldoen moet het format geschikt zijn voor Utility Dashboard. Het werkt dus ik heb het nooit meer aangepast.

Ik zie dat het bij mij met V149 nog steeds niet klopt, total is goed, maar daily is veel te hoog en gelijk aan monthly die ook veel te hoog is.

[Afbeelding]

Ah helder. Ik zit op V151 na aanvragen nieuwste firmware
Wel gek want die van mij klopt qua dialy behoorlijk. Met wat Marstek over de Modbus gooit ( zelfde als in de app )

Modbus:


Utility meter HA

[superduper1969]

Sangoes schreef op zaterdag 19 april 2025 @ 09:34:
[...]


Ah helder. Ik zit op V151 na aanvragen nieuwste firmware
Wel gek want die van mij klopt qua dialy behoorlijk. Met wat Marstek over de Modbus gooit ( zelfde als in de app )

Modbus:
[Afbeelding]

Utility meter HA
[Afbeelding]

Bij mij Reset s'nachts niet hij niet maar telt door, maar ik heb ook een van de allereerste uit december 2024.
Als ik eens tijd heb zal ik een factory reset doen, misschien scheelt dat? Dat heb ik nog nooit hoeven doen.

[ Voor 5% gewijzigd door superduper1969 op 19-04-2025 11:06 ]

[pascallj]

superduper1969 schreef op zaterdag 19 april 2025 @ 11:00:
[...]

Bij mij Reset s'nachts niet hij niet maar telt door, maar ik heb ook een van de allereerste uit december 2024.
Als ik eens tijd heb zal ik een factory reset doen, misschien scheelt dat? Dat heb ik nog nooit hoeven doen.
[Afbeelding]

Ik heb er nogmaals naar gekeken, maar zie verder niets geks in config. Aangezien anderen ook aangeven dat het wel werkt (neem aan dat zij wel jouw standaard code draaien), denk dat het aan jouw Marstek ligt inderdaad. Heb je de datum en tijd wel goed ingesteld? Heb je hem ook nog gekoppeld aan het internet?

Misschien verliest hij na een tijdje de datum en tijd als de verbinding kwijt is.

[william.geurts]

Satscan, bedankt voor je reactie. Ik gebruikte de power van de Marstek voor de LilyGo. Ik heb nu de extra 5V aangesloten. Toch nog storing, en nu heb ik de power kabel naar de Marstek doorgeknipt. Het lijkt nu wel te werken.

[william.geurts]

Ik wil eigenlijk dat mijn apparatuur geen verbinding met de Marstek cloud maakt. Heeft iemand al uitgezocht hoe dit kan?

[pascallj]

william.geurts schreef op zaterdag 19 april 2025 @ 22:58:
Ik wil eigenlijk dat mijn apparatuur geen verbinding met de Marstek cloud maakt. Heeft iemand al uitgezocht hoe dit kan?

Van de wifi afhalen? Volgens mij is daar geen optie voor, maar even een tijdelijke hotspot maken, daarmee de Marstek laten verbinden en vervolgens de hotspot niet meer gebruiken zorgt er wel voor dat er foutieve WiFi gegevens in het geheugen staan.

Gezien het Bluetooth beveiligingsprobleem, gaat de mijne uiteindelijk in een soort van Faraday kooi mocht het verwijderen van de antenne niet genoeg blijken. Klinkt dramatisch, maar ik neem beveiliging serieus.

[walt 60]

is er iemand die mij een compleet pakket kan geven voor de modbus aansturing ? of werkt dat alleen met HA?

[ Voor 14% gewijzigd door walt 60 op 20-04-2025 11:03 ]

[AUijtdehaag]

@walt 60
Wat gebruik je dan ipv home assistant?

[walt 60]

ik ben een leek , ik heb nu home wizard draaien zodat ik wat kan kijken , maar zou graag meer op mijn laptop willen bekijken . mijn marstek 5,2 werkt nu al maanden perfect automatisch op de ct 003 mijn meter is de landisgyr 4,2 E350 .geeft wel wat laat de gegevens door . maar werkt tot nu toe perfect , krijg eind deze maand een batterij erbij

[ Voor 47% gewijzigd door walt 60 op 20-04-2025 13:55 ]

[Tom Jansen]

Iemand bekent met deze melding van de LilyGo na integratie in HA:

[component:239]
Component modbus_controller took a long time for an operation (61 ms)......

Welke setting in de Yaml file zou ik hiervoor kunnen aanpassen?
Alles werkt overigens wel, maar vind de melding 'not nice' .....
Vast bedankt!

[leejoow]

Tom Jansen schreef op zondag 20 april 2025 @ 14:21:
Iemand bekent met deze melding van de LilyGo na integratie in HA:

[component:239]
Component modbus_controller took a long time for an operation (61 ms)......

Welke setting in de Yaml file zou ik hiervoor kunnen aanpassen?
Alles werkt overigens wel, maar vind de melding 'not nice' .....
Vast bedankt!

Die melding is geen probleem, heb ik ook bij de aansturing van de warmtepomp. De modbus_controller is geprogrammeerd op een manier die de main thread blokkeert, als hij het dan druk heeft duurt dit iets langer dan ESPHome wil. Kan je dus veilig negeren

[superduper1969]

walt 60 schreef op zondag 20 april 2025 @ 13:50:
ik ben een leek , ik heb nu home wizard draaien zodat ik wat kan kijken , maar zou graag meer op mijn laptop willen bekijken . mijn marstek 5,2 werkt nu al maanden perfect automatisch op de ct 003 mijn meter is de landisgyr 4,2 E350 .geeft wel wat laat de gegevens door . maar werkt tot nu toe perfect , krijg eind deze maand een batterij erbij

Gebruik 2 energy sockets en kijk online op https://hwenergy.app/overview simpeler kan ik het niet maken.

[superduper1969]

superduper1969 schreef op zaterdag 19 april 2025 @ 11:00:
[...]

Bij mij Reset s'nachts niet hij niet maar telt door, maar ik heb ook een van de allereerste uit december 2024.
Als ik eens tijd heb zal ik een factory reset doen, misschien scheelt dat? Dat heb ik nog nooit hoeven doen.
[Afbeelding]

Het lijkt erop dat dit is gefixed in V151.

[ Voor 23% gewijzigd door superduper1969 op 20-04-2025 16:04 ]

[Edzelf]

walt 60 schreef op zondag 20 april 2025 @ 13:50:
ik ben een leek , ik heb nu home wizard draaien zodat ik wat kan kijken , maar zou graag meer op mijn laptop willen bekijken . mijn marstek 5,2 werkt nu al maanden perfect automatisch op de ct 003 mijn meter is de landisgyr 4,2 E350 .geeft wel wat laat de gegevens door . maar werkt tot nu toe perfect , krijg eind deze maand een batterij erbij

Misschien is mijn Venus-control een oplossing. Zie de documentatie hier. Let op de knop "More pages" onderaan de pagina.

[SatScan]

william.geurts schreef op zaterdag 19 april 2025 @ 22:58:
Ik wil eigenlijk dat mijn apparatuur geen verbinding met de Marstek cloud maakt. Heeft iemand al uitgezocht hoe dit kan?

Alles instellen en extern-internet voor die IP adressen blokkeren. Werkt alleen nog lokaal en uiteraard is Wifi noodzakelijk. De mode AI werkt niet meer en firmware updates.

[Gwaihir]

pascallj schreef op zaterdag 19 april 2025 @ 23:34:
Van de wifi afhalen?

Waarom moet hij ooit op de Wifi dan? Besturen via modbus, updaten via Bluetooth?

Gezien het Bluetooth beveiligingsprobleem

Oh? Ik heb iets gemist..

[Maxwp]

SatScan schreef op zondag 20 april 2025 @ 17:56:
[...]


Alles instellen en extern-internet voor die IP adressen blokkeren. Werkt alleen nog lokaal en uiteraard is Wifi noodzakelijk. De mode AI werkt niet meer en firmware updates.

Firmware updates gaan via bluetooth

[SatScan]

Maxwp schreef op zondag 20 april 2025 @ 19:32:
[...]

Firmware updates gaan via bluetooth

Oke, dan toch via een MT account neem ik aan...

[SatScan]

superduper1969 schreef op zondag 20 april 2025 @ 15:56:
[...]

Het lijkt erop dat dit is gefixed in V151.
[Afbeelding]

Yep hier ook, is gefixt!

[pascallj]

Gwaihir schreef op zondag 20 april 2025 @ 18:52:
[...]

Oh? Ik heb iets gemist..

Iedereen binnen Bluetooth bereik kan zo je Marstek overnemen aangezien hij altijd staat uit te zenden zonder wachtwoord.

[SatScan]

pascallj schreef op zondag 20 april 2025 @ 23:11:
[...]


Iedereen binnen Bluetooth bereik kan zo je Marstek overnemen aangezien hij altijd staat uit te zenden zonder wachtwoord.

Kun je de procedure beschrijven om dit te doen zodat we het kunnen reproduceren.
Dan kan het daarna aan MT gemeld worden met verzoek dit asap op te lossen!

Dank je wel!

[pascallj]

SatScan schreef op maandag 21 april 2025 @ 10:08:
[...]


Kun je de procedure beschrijven om dit te doen zodat we het kunnen reproduceren.
Dan kan het daarna aan MT gemeld worden met verzoek dit asap op te lossen!

Dank je wel!

Zie ook: pascallj in "Hame / Marstek / Duravolt 5,12kWh plug en play thuisaccu"

[elgringo]

Ik heb nu de batterij via modbus aangesloten en kan deze bedienen.
Vervolgens een script gemaakt waar ik de huidige P1 waarde heb en hiermee de batterij wil aansturen zodat deze met 0 op de meter komt.

Reden hiervoor is dat de CT003 internet nodig heeft en ik vertrouw niet dat ze discreet met de data om gaan.

Probleem is dat ik altijd een fout heb. De batterij regeert traag (vraag nu 2500w, en pas over 10 sec is deze er) waardoor ik te vaak er net wat naast zit.

Wat voor regeling werkt een beetje om de batterij aan te sturen?

Ik ben begonnen met:
requestedPower = deliveredPower + huidigeP1

Deze deed het aardig maar begone rond 0 te schommelen. Met een factor is het beter maar ik vind nog steeds dat er teveel fout in zit

[pascallj]

elgringo schreef op maandag 21 april 2025 @ 11:16:
Ik heb nu de batterij via modbus aangesloten en kan deze bedienen.
Vervolgens een script gemaakt waar ik de huidige P1 waarde heb en hiermee de batterij wil aansturen zodat deze met 0 op de meter komt.

Reden hiervoor is dat de CT003 internet nodig heeft en ik vertrouw niet dat ze discreet met de data om gaan.

Probleem is dat ik altijd een fout heb. De batterij regeert traag (vraag nu 2500w, en pas over 10 sec is deze er) waardoor ik te vaak er net wat naast zit.

Wat voor regeling werkt een beetje om de batterij aan te sturen?

Ik ben begonnen met:
requestedPower = deliveredPower + huidigeP1

Deze deed het aardig maar begone rond 0 te schommelen. Met een factor is het beter maar ik vind nog steeds dat er teveel fout in zit

Volgens mij heeft de CT003 geen internet nodig, maar WiFi om te communiceren met de batterij. Ik gebruik het zelf niet, maar dat is volgens mij wat ik meerdere malen gelezen heb.

Desalniettemin is zelf sturen nog steeds leerzaam en meer controleerbaar.

[Maxwp]

elgringo schreef op maandag 21 april 2025 @ 11:16:
Ik heb nu de batterij via modbus aangesloten en kan deze bedienen.
Vervolgens een script gemaakt waar ik de huidige P1 waarde heb en hiermee de batterij wil aansturen zodat deze met 0 op de meter komt.

Reden hiervoor is dat de CT003 internet nodig heeft en ik vertrouw niet dat ze discreet met de data om gaan.

Probleem is dat ik altijd een fout heb. De batterij regeert traag (vraag nu 2500w, en pas over 10 sec is deze er) waardoor ik te vaak er net wat naast zit.

Wat voor regeling werkt een beetje om de batterij aan te sturen?

Ik ben begonnen met:
requestedPower = deliveredPower + huidigeP1

Deze deed het aardig maar begone rond 0 te schommelen. Met een factor is het beter maar ik vind nog steeds dat er teveel fout in zit

Ok dat wist ik niet dys modbus aansturing heeft net z'n trage reactie snelheid ?

[Maxwp]

SatScan schreef op maandag 21 april 2025 @ 10:08:
[...]


Kun je de procedure beschrijven om dit te doen zodat we het kunnen reproduceren.
Dan kan het daarna aan MT gemeld worden met verzoek dit asap op te lossen!

Dank je wel!

Dit is wel al eerder gepost probleem

Is ook al eerder gemeld bij mt maar blijft erg stil.

[ Voor 7% gewijzigd door Maxwp op 21-04-2025 11:38 ]

[Gwaihir]

elgringo schreef op maandag 21 april 2025 @ 11:16:
Probleem is dat ik altijd een fout heb. De batterij regeert traag (vraag nu 2500w, en pas over 10 sec is deze er) waardoor ik te vaak er net wat naast zit.

Wat reageert er (te) traag? Die 10 seconden komt me voor als een P1 waarde die maar elke 10 seconden wordt bijgewerkt. DSMR 4.x meters doen dat en daar moet je het dan maar mee doen. (En dus inderdaad naar een oplossing zoals de CT003 overstappen.)