Jeetje. Hoop werk
We zullen het zien. Ik denk dat ik ook wat weg ga gooien.
Zoals de flow: geen elektrische kachel in de schuur aan (vorstvrij houden) als de auto laadt.
Zoals de flow: als de maximale (3x40A) wordt bereikt dan 1A langzamer laden.
Zoals de flow: als de 350V wordt bereikt dan sneller laden (nooit nodig geweest in mijn straat)
Wat blijft: meer zon-opwek dan 3x32A via de Netaansluiting dan 1A sneller
Vraagje. Volgens mij heeft de Venus C geen ethernet aansluiting? En welke versie van de Venus E heb je? Kortom, praten ze Modbus TCP?
@Roedi_de_Lion de c zijn via WiFi en de e met utp. Heb ze nu gekoppeld met de app Marstek Batterijconnector | Homey
Hmm… ik ben geen fan van de API van Marstek. Combinatie van TCP en API kan niet in mijn app en ga ik ook niet ondersteunen. Teveel issues continue.
Als je voor de C overstapt naar een Lilygo per batterij, dan zorg ik dat het in de app kan.
@Roedi_de_Lion dank je wel! Daar ga ik over nadenken. Weinig ervaring met Lilygo. Jij tips voor aanschaf?
Misschien @Linden85 je helpen. Die heeft dat onlangs ook gedaan.
Die Venus C heeft wel een modbus aansluiting?
@Roedi_de_Lion
M.b.t. Apparaten (beta)
Ik kan via deze weg zowel mijn vaatwasser, wasmachine als droger toevoegen. Echter hebben ze alledrie “hetzelfde” probleem er is geen goede weergave, dus leercurve, van het opgenomen elektrisch vermogen.
Is het mogelijk om een apparaat aan te maken, maar voor de energie meting een 2de apparaat (plug) te selecteren, zodat je het beste uit alle mogelijkheden kan halen
Hoe gaan anderen hiermee om en wat is jullie manier van werken hiermee?
hey @Roedi_de_Lion
Het valt me op dat sinds een aantal weken, de indevolt accu gaat ontladen als de auto begint te laden.
Laadpaal Is toegevoegd als kritisch apparaat en, houdt volgens de instellingen van slimladen het vermogen van de laadpaal buiten beschouwing.
Zou het zo kunnen zijn dat in het NOM blok van slimladen, de indevolt terugvalt naar zijn eigen P1 meter? (Door eventuele update van indevolt)
Als je laad via de nieuwe ev-laden mogelijkheid van SlimLaden plant ie perfect om de laadurwn van de ev heen. Ik had ook regelmatig problemen met het ontladen van de accu’s bij een NOM situatie. Soms goed maar af en toe toch weer ontlading. Ondanks dat alles goed stond ingesteld. Nu laad ik de EV via SlimLaden. En hoewel er nog wel verbeteringen mogelijk zijn voor ev laden werkt het al fijner als mijn oude laad app. Met name de samenwerking tussen thuis accu’s en de ev is erg fijn en zeker.
Nog een vraag mbt apparaten (beta)
ik heb een aquarium
hier heb ik draaien
pompen
verlichting
verwarming
co2
skimmer
Ik meet graag het gehele stroomverbruik, maar zou graag onder de totale groep ook nog de deel apparaten toevoegen, waar dit uit opgebouwd is.
Is dit mogelijk en kan slimladen hier dan goed mee omgaan.
bv pomp draait 24/7
verwarming schakelt af en toe aan en uit
Volgende stap, Homey Podcast?
Hoi Roedi,
Ik gebruik SlimLaden Thuis & Auto met de strategie Max Winst en twee Marstek Venus batterijen.
Ik loop tegen het volgende aan.
In de avond wil ik regelmatig mijn vaatwasser aanzetten. SlimLaden heeft mijn batterijen dan echter vaak al zover ontladen dat de SOC rond de 12% staat. Daardoor wordt het verbruik van de vaatwasser vervolgens grotendeels uit het net gehaald.
Nu heb ik mijn vaatwasser dmv een slimme stekker toegevoegd bij apparaten (beta). Tussen 19-22.30u zet ik mijn vaatwasser handmatig aan. Klopt het als ik dit dagelijks doe dat deze wordt meegenomen en meetelt. in het gebruik. En door het zelflerende vermogen er capaciteit wordt gereserveerd voor mijn vaatwasser?
Ik heb geprobeerd dit met een Homey-flow en een HomeWizard Energy Socket op te lossen, maar ik twijfel of dit wel de juiste aanpak is.
Mijn ideale situatie zou zijn:
-
Overdag gewoon Max Winst blijven gebruiken.
-
Voor de avond voldoende SOC beschikbaar houden voor de vaatwasser.
-
Als de vaatwasser wordt aangezet, deze zoveel mogelijk vanuit de batterijen laten draaien.
-
Daarna mag SlimLaden weer verder volgens het normale laad-/ontlaadplan.
Is dit binnen SlimLaden zelf op een goede manier in te stellen, bijvoorbeeld met een minimale SOC/reserve op bepaalde uren?
Of moet ik hiervoor juist een Homey-flow gebruiken die tijdelijk ingrijpt in het SlimLaadplan?
Ik hoor graag wat volgens jou de beste manier is om dit te realiseren.
Misschien ten overvloede: de app werkt uitstekend via Wifi op de Marstek Venus E 3.0.
Misschien iets van een flow naar Max eigen gebruik vanaf 22u? En daarna kan je kijken naar nachtreserve of een reserve houden met piekinstellingen . Tenzij het plan rekening houd met de apparaten wat je toevoegd maar dat durf ik niet te zeggen 
Ben net begonnen met Homey en kwam deze fantastische app tegen. Echt super!!
Even een vraagje over NOM : ik heb 2 Sessy batterijen en 1 Indevolt Powerflex. Volgens mij zet SlimLaden bij NOM de batterijen in de NOM stand en kun je kiezen of batterijen individueel om de beurt op NOM gaan of gezamenlijk. Als ik het goed begrijp/zie zet SlimLaden de batterijen in NOM mode van de fabrikant.
Nu werken de Sessy’s en Indevolt niet met elkaar samen en heeft elk merk een eigen P1 meter. In de zomer is dat prima aangezien er dan zelden meer dan 800 Watt (max van Indevolt) wordt gevraagd. In de winter heb ik met grotere gebruikers echter wel meer verbruik met o.a. hybride warmtepomp. SlimLaden zet de batterijen in hun NOM / Zelfconsumptie modus, maar de batterijen werken dan niet samen maar individueel.
Zou het mogelijk zijn om uit de SlimLaden app het doelvermogen voor NOM naar de batterijen te sturen? Als je dan alle batterijen op api modus hebt staan kun je ook in winter in NOM ook echt NOM draaien. Ik draai ook nog HomeAssistant (zit in overgang naar Homey) en werk daar met Sessy XOM blueprint van Pim Doos welke het doelvermogen berekent en middels api naar Sessy('s) stuurt, deze werkt ook alleen voor Sessy en niet voor meerdere merken. Zou super zijn als iets dergelijks ook in SlimLaden app zou kunnen worden geintegreerd maar dan voor alle batterijmerken middels api.
Nieuwe migratie-gerelateerde bug: zonvoorspelling in het laadplan lijkt fors te hoog t.o.v. de live Solcast-meting, waardoor de accu’s vandaag agressief op vol vermogen laden terwijl er van dat vermogen maar een fractie echt door de zon gedekt wordt.
Context: 3 sept ben ik gemigreerd naar een Homey Pro (2026, 4GB) i.v.m. chronisch vol geheugen op de oude Homey Pro (Early 2023). Sindsdien is opnieuw gekoppeld via een verse API-key, alles werkt weer, maar vandaag (6 sept) valt op dat de accu’s al de hele ochtend op bijna vol vermogen laden (~2200W per Sessy x3 = ~6,5kW) terwijl de Solcast-app (“Forecast.Solar”) live maar ~2,4kW aan zonproductie meet.
In het Laadplan zelf zie ik dat de “Zon”-kolom voor vandaag onrealistisch hoog staat: 10:30 = 1,81 kWh/kwartier (gemiddeld 7,2 kW), 10:45 = 1,64 kWh (6,6 kW), terwijl de live meting op dat moment rond de 2,4 kW schommelde. Actie “Zon-laden” wordt hierdoor ingezet op basis van een veel te optimistische zonvoorspelling, met als gevolg dat het merendeel van dat laadvermogen gewoon van het net komt (prijs nu €0,136-0,138, dus niet gratis) i.p.v. van de zon.
Mogelijk gerelateerd: in het diagnostiekscherm staan 50 recente foutmeldingen, allemaal om 00:16:20 vannacht gelogd, “[ProcessManager2.0] Invalid quarter data” met consumption/totalWh = null, voor circa 13 kwartieren vandaag (10:00-12:30) en bijna de hele dag morgen (01:30-12:30). Dat lijkt hetzelfde ProcessManager2.0-onderdeel te raken als de zonvoorspelling, dus vermoed ik één onderliggende oorzaak, mogelijk iets dat na de migratie opnieuw moet worden opgebouwd (leerdata/verbruiksmodel?).
Ik heb zelf voor nu een eigen “Boost laden bij lage prijs”-flow aangepast (extra voorwaarde “geen onbenut zonoverschot”) om te voorkomen dat mijn eigen automatisering bovenop dit probleem nog eens extra boost, maar dat lost de onderliggende te-hoge zonvoorspelling natuurlijk niet op. Herkent iemand dit, en is er een manier om de zonvoorspelling/rooftop-configuratie te forceren te verversen na een Homey-migratie?
Misschien snap ik iets niet… kan iemand uitleg geven?
Laadplan vandaag zie onder, Zon Optimaal. Paarse balkjes = zon-overschot volgens de WIKI moet hij dan STOP staan. Bij controle met Insights staat de batterij op NOM. En er zit plots 1 kwartier op NOM tussen om 8:30.
Verder zou ik verwachten dat NOM of LADEN pas na 10:30 u is als de prijs 0 € is. Dat is niet zo, hij begint al een uur eerder te Zon-Laden.
Ik zie in de SOC lijn een STOP van 10:45 tot 12:15 terwijl in de tabel Zon-Laden staat? 14:15 t/m 14:45 ineens op STOP, maar waarom? Als de batterij vol is dan op NOM, zoals daarna vanaf 15:00
De bedoeling is goed maar maakt de solver de juiste berekeningen?
Wellicht ligt het aan je prijsconfiguratie. D,at je een prijs van 0 hebt is heel bijzonder, de lage prijzen liggen vandaag bij mij rond de 12 cent. Ik zou eerst het kostengedeelte goed in orde maken en dan kijken hoe het dan gaat.
