-
Je mag volgens Marstek meerdere batterijen toch niet anders aansturen dan met een ct van Marstek zelf? Mocht dit wel anders kunnen dan hoor ik het graag hoe en met welke meter ik ze dan aan kan sturen.
-
Als ik het op parallel zet dan laden steeds beide batterijen een beetje? Of heb je dat met jouw app omzeild?
Goedemorgen!
Ik heb sinds gisteren de Lilygo’s weer gekoppeld aan mijn Marstek batterijen. Hiervoor een tijdje met API gedraaid. Ik merk dat ik een instabiele MQTT verbinding heb. Hebben jullie nog tips?
- Dat is idd wat ik probeer te doen. Maar misschien kan dat toch niet. Dat weet ik niet zeker. Hij moet dan op sequentieel staan. (Dit dan met een andere p1 dan die van Marstek)
- Ik zou zeggen, dan neemt Marstek het roeleren tussen de batterijen over. Hij staat dan op paralel en beide krijgen het NOM commando, maar Marstek regelt de rest. Klopt dus niet? Wat doet Marstek dan wel?
Wat je misschien zou kunnen proberen: 1 batterij even ontkoppelen van mijn app zodat alleen 1 batterij op paralel een NOM commando krijgt en de ander niets.
DAnk voor je toelichting @Roedi_de_Lion omtrent de Gele en Paarse balken. Mijn beredenering: zo lang er zon(overschot) is, zou ik dat in de Batterij willen stoppen ipv het Net op. ‘s Avonds zie je in jouw grafiek een actief ontlaad moment ipv NOM om je zelfconsumptie zo hogelijk te houden. Ik gebruik liever de zonnestroom ipv het in de avond of nacht weer terug te moeten kopen incl BTW
Ik heb zelf ook een Venus E met een LilyGo. Ik kan niet meer goed testen met MQTT. Ik zou je willen vragen om over te stappen op TCP. Daar heb ik een yaml voor.
Ik werk vandaag thuis dus ik zal punt 2. testen en kom daarop terug in de loop van de dag. Bedankt voor alle moeite!
Kan je deze delen? Dan weet ik zeker dat deze correct is…
Dank je wel!
Kan je deze delen? Dan weet ik zeker dat deze correct is…
Dank je wel!
Kan je deze delen? Dan weet ik zeker dat deze correct is…
Zou je denken
Maar laatst ging ook iemand over en die moest toch nog iets aanpassen. Ben even kwijt wie dat was. Dropbox (Ik heb hem intussen gevraagd)
Hij had dit nog aangepast:
In modbus_bridge.cpp heb ik regel 478 ESP_LOGI(TAG, “TCP server started on %s:%d”, ips[0].str_to().c_str(), this->tcp_port_); aangepast naar
char ip_buf[16];
ESP_LOGI(TAG, “TCP server started on %s:%d”, ips[0].str_to(ip_buf), this->tcp_port_);
DAnk voor je toelichting @Roedi_de_Lion omtrent de Gele en Paarse balken. Mijn beredenering: zo lang er zon(overschot) is, zou ik dat in de Batterij willen stoppen ipv het Net op. ‘s Avonds zie je in jouw grafiek een actief ontlaad moment ipv NOM om je zelfconsumptie zo hogelijk te houden. Ik gebruik liever de zonnestroom ipv het in de avond of nacht weer terug te moeten kopen incl BTW
Je kan dat nu dus aanpassen met een extra troggel. Dan zet je ook voor die kwartieren Solar capture aan.
Btw. Helpt de reden in het masterplan en beetje?
Zoeken zoeken zoeken… die toggle kon ik niet vinden tot ik ging kijken onder SlimPlanner(1). Het plaatje wees het uiteindelijk wel uit. Er zijn nu zoveel functies dat ik soms door de bomen het bos niet meer zie, sorry.
Zonvoorspelling ‘werkelijk’ blijft sinds gisteren op 0 staan. Iemand anders dit ook? Herstart Homey helpt niet, Zonvoorspelling Controller instellingen zijn niet gewijzigd.
Anders maak ik ff een support ticket aan..
Hoi Roedi, bij mij gaat zon laden naar het net.
Punt 2 nu een tijdje kunnen testen.
Uitkomst. Parralel is dus dat beiden tegelijk de stroom verdelen dus 1KW totaal is 500W voor de 1e en 500W voor de 2e. Dit kan ik nergens aanpassen in de app van Marstek. Rouleren doet die dus niet.
Dus heb ik hem maar weer op SEQ gezet. Ik vind dit namelijk logischer.
Ik hoog dat je een aanpassing kan doen dat hij ongeacht welke CT /P1 meter die gebruikt de SOC gaat wisselen. Je wilt gewoon niet dat die niet efficient laad.
Of anders dat die gewoon de 1e vol laad en daarna de 2e pakt en bijschakeld bij >2.5kw. Is nog altijd beter dan gedeeld.
update 10.01 Weet niet of het toeval is of niet maar hij ging nu laden in mijn 2e baterij terwij die andere nog niet vol is. Zal hij dan toch rouleren? heb hem nog steeds op SEQ staan
Anders maak ik ff een support ticket aan..
Inclusief analyse van je zon device
Nee, bij mij werkt het weer prima. Zon voorspelling is nu spot on.
Het plan doet nu vrijwel wat ik verwacht en wil. Extra voorwaarde mbt in de ochtend laden. Ik ga nog een flow maken die schakelt naar HAND en LADEN zodat het laadvermogen meer wordt verdeeld over de tijd. Dat is iets wat ik graag zou zien: gele balkjes is status LADEN ipv NOM, dan kan de gebruiker zelf bepalen of hij wil smoren of niet dmv de settings.
Beter misschien want ik betwijfel of snelladen op max power goed is voor een batterij. Terwijl ik nog lange tijd zon heb en zonnestroom over, dan kan ik ook rust aan laden. Hij mag ook later beginnen met laden pas middaguur met lage stroomprijs, moet ik de voorwaarden nog aanpassen.
Bij mij staan sinds 8h de Werkelijke waarden van Zonvoorspelling en Verbruik weer op nul.
Was gisteren ook, toen duurde dat tot 17h
Ik heb de bug gemeld in Backlog
Zonvoorspelling ‘werkelijk’ blijft sinds gisteren op 0 staan. Iemand anders dit ook? Herstart Homey helpt niet, Zonvoorspelling Controller instellingen zijn niet gewijzigd.
Gedaan. En ik zie meer mensen met het zelfde probleem.. laat maar weten als je verder iets van me nodig hebt… thx!
Iets wat ik niet snap is dat de app gele kolommen geeft (nu 13:48 u) en zou hij op NOM moeten staan. Ik heb m HAND gezet op LADEN.
Telkens stopt de batterij met laden precies op het kwartier, dus geen NOM en geen LADEN, ook al staat de HAND override aan. Laadplan geeft SoC% 100% aan terwijl er onder op de battery status 78% staat, wat overeenkomt met de lichtbalk en de Marstek app.
Misschien geeft het laadplan ondanks HAND toch stiekem een STOP op basis van de foute SoC% waarde in het laadplan.
Dat ie op een of andere manier automatisch van HAND afschakelt en dit niet zichbaar is tenzij op de lichtbalk is waarschijnlijk een klein maar hinderlijk bugje?








