Ik kom niet aan deze registers. je maakt een klein foutje in de software en je batterijen laden op meer dan je wil. Ik doe dat uit veiligheid niet. Officeel zou het voor V3 ook niet kunnen, maar het kan dus wel zie ik. Heb het ook bij mijn batterijen niet willen testen.
Eventueel wel een tip: Als je wil dat je batterijen bijvoorbeeld ook niet naar 2500 wil hebben in nom…moet je deze aanpassen.
Daar moet ik dan nog even induiken. De settings van de batterijen in HA gaan ook via Hacs best ver. Ik heb de PI waarop HA draait nu ook weer uitgezet en kijk deze week ff aan of die niet weer in de Marstek app verkeert staan. Ik heb de bedrading in mijn woning niet aangelegd dus ben erg voorzichtig met hard laden en zeker ontladen. Dan liever een 3e marstek op weer een andere fase.
De app van je collega stuurt wel hard op de registers en daar haalde ik uit dat er iets niet goed stond. Ik gebruik die app puur om de batterij status op te halen, per batterij want dat kan ik nu niet zien, alleen de laadplan controller van beide batterijen.
sinds de laatste update van de app pakt hij de derde batterij in mijn setup niet meer mee bij een handmatige NOM (Multi-batterij NOM-modus). Volgens mij zou hij bij ontladen en x percentage moeten omschakelen van de ene batterij naar de andere en dit dan op basis van de hoogste SOC weer moeten starten?
Voorheen werkte dit wel goed, maar sinds de update lijkt hij alleen de eerste twee batterijen mee te nemen. Enig idee waar dit aan ligt?
Geinig, wilde een support ticket indienen, maar moest eerst updaten van versie van gister naar die van vannacht. Blijkbaar is daar iets in veranderd een nu gooit hij de derde wel leeg. Idealiter blijven ze natuurlijk wel een beetje bij elkaar in de buurt. Klopt het dat er iets in is veranderd?
En wat zijn eigenlijk de SOC waarden waarop overschakelen gebeurd?
Vraag over het EV-laden. Vandaag (woensdag) werk ik thuis, dus ik had gisteravond al ingesteld dat mijn auto pas morgen (donderdag) om 6:00 weer vol genoeg hoeft te zijn voor de volgende werkdag.
De app plant alle laaduren na middernacht. Vermoedelijk omdat de stroomprijzen dan nog niet bekend zijn en als 0 worden gerekend?
Naar alle waarschijnlijkheid zijn de uren vandaag overdag goedkoper dan de uren komende nacht.
Ik neem aan dat als rond 13:00 de nieuwe prijzen bekend worden dat 'ie dan alsnog overdag gaat laden. Maar dan gaat het algoritme op dit moment er wel vanuit dat het de hele dag de hand vrij heeft met de thuisbatterij en dat zal niet het geval zijn.
Ik weet nog niet of dit een issue is, laat staan wat de oplossing zou zijn. Wat zijn jullie gedachten? Ik hou het in de gaten.
De batterijen staan inderdaad op seriële NOM, maar ergens moet toch een trigger gegeven worden dat een batterij moet ontladen? Ik dacht juist dat de app dat zou doen op basis van deze instelling? Voor 2 van de 3 werkt dit namelijk prima.
Geen fouten in de logs nee. Ik was er inderdaad ook vanuit gegaan dat de app het zou regelen (en dat werkte ook wel voor 2/3). Na de laatste update ontlaad hij nu dus de derde (waarschijnlijk omdat hij de hoogste SOC heeft). Ik denk (aanname) dat hij bij een 10% verschil zou moeten omschakelen naar de hoogste SOC, maar dat weet ik niet zeker.
Vanochtend stonden er overigens teveel tickets open, nu niet meer, dus heb even een diag json ingestuurd.
Ja dat blijft lastig. Plannen als de prijzen nog niet bekend zijn. Maar dit lijkt mij in elk geval veilig. Ik hoop dat als rond 13:00 de prijzen bekend zijn er een nieuw laadplan ev uitrolt. Mooi testcase. Ik gebruik de app voor laden nu enkele dagen (ik was tester) Ik heb wel al eens de situatie meegemaakt dat het laadplan de Laadsessie over twee blokken ging plannen. Deels het goedkoopste uur gisteren en deels goedkoopste uur afgelopen nacht. Dus plan zocht echt naar losse blokken en niet een aangesloten blok.
Bij wijzigingen in de beslissingscriterea zou het plan voor ev laden een trigger moeten krijgen om het plan aan te passen. Ik neem aan dat dit nu al zo is. Plannen in een periode dat er nog geen prijzen bekend zijn blijft koffiedik kijken
Overigens stopt de sessie niet op exact 80% maar bijvoorbeeld op 82%. (Als je laden tot 80% hebt ingesteld) Ligt niet aan de app maar de tesla intergratie rapporteert eens per xx minuten/swconden (instelbaar) dit omdat er kosten worden berekend als je boven een aantal api aanroepen komt. Ik heb het nu aan de veilige kant ingesteld (eens per 5 minuten opvragen)
Even afwachten waar dat op 1 maand op uit komt. Eeste inschatting is rond de 5 $. Als dat inderdaad zo is zou ik naar elke 3 minuten opvragen kunnen gaan.
Dit gaat bij tesla dus per maand. (Op de 1ste staat alles dus op 0) Tot 10$ wordt er niets berekend. Kom je daarboven dan wordt het wel berekend op de manier zoals je hebt ingesteld in je Tesla developer account. Heb je niets ingesteld dan stopt de API voor de rest van de maand. Dit is dus in hetzelfde account waar je de api voor Homey moet aanmaken en laden in je auto (dat heet dan bij tesla “virtuele sleutel”). Was hele uitzoekerij.
Dit ter info, bij andere merken is dit dus anders geregeld. Gelukkig vaak ook gratis en onbeperkte toegang.
Eh ja ik werk met een SHS config voor slimladen thuis maar geen EV.
Maar ik heb een andere vraag kan ik ergens een vinkje zetten dat ik niet naar de “slim-laden.app” wil en gewoon m’n homey wil blijven benadren voor de besturing ect. http:\\ip-homey:8778
Nu word ik omgeleid naar buiten toe (extern ip 104.21.82.235 “cloudflare” ik heb juist een homey genomen om zoveel mogelijk mijn data binnen de deur te houden zonder gebruik te maken van externe bronnen.
Ja, ik begrijp dat ontwikkeling en display mogelijkheden op deze manier naar een hoger en mooier level geheel kunnen worden gebracht. Maar als internet er uit ligt zal het nog wel werken maar dan kan ik er niet meer bij.
En ik vind het niet zo fijn als mijn dat spontaan word om geleid naar buiten en weer terug
Ik zou graag een vinkje zien om het gebruik van de “web-app” uit te schakelen en gewoon intern op de Homey te blijven, dan maar beparkte mogelijkheden.