Goede morgen allemaal. Van mij komende week even geen last. Ben weekje op vakantie 
Fijne vakantie!
Veel plezier.
Eindelijk rust. 
Fijne vakantie!!
Fijne vakantie, geniet ervan.
Airco heeft sinds gisteren en dus ook de hele nacht aangestaan.
Vanochtend echter is er blijkbaar automatisch een nieuwe learning van 240 minuten gestart en is alle handmatig ingevoerd verbruik weer verdwenen.
Pas nadat ik de airco eerst uit en daarna weer aan heb gezet, werd het extra verbruik toegevoegdin de verwachting van de planning.
Ticket aangemaakt?
Ik heb versie 9.2.1 gepubliceerd. Daarin het ik maar weer eens de winst berekening onder de loep genomen:
- Voorspelling van 0.00 uur is er nu uit. A klopte daar steeds niets van. B als de prijzen van morgen binnenkomen, verandert de winst van de dag sowieso, doordat het ontladen dan vaak uitgesteld wordt naar morgen. je winst wort dan sowieso anders/lager dan dat je aan het begin. van de dacht dacht.
- Ik vergelijk de winst met en zonder batterij nog steeds.
- Op de winst zonder batterij wordt in mindering gebracht met de zon die in de abterij achterblijft aan het einde van de dag. Dit om een eerlijke vergelijk te maken met de winst MET batterij.
Even een vraag aan de mensen die al een mixed-battery setup draaien en natuurlijk ook aan Roedi.
Ik heb momenteel een Zendure SolarFlow 2400AC+ met 2 x AB3000L en daarnaast een HomeWizard Plug-in Batterij. Deze configuratie heeft korte tijd gewerkt, maar daarna begonnen de batterijen te pendelen. Daarom heb ik de HomeWizard-batterij voorlopig uitgeschakeld.
De Zendure wordt aangestuurd via een Zendure Smart P1-meter en de HomeWizard via een HomeWizard P1-meter. Op dit moment loop ik tegen een vreemd probleem aan waar Roedi op de achtergrond al naar meekijkt.
Als dat probleem is opgelost, ben ik benieuwd naar het volgende:
Hoe voorkomt SlimLaden dat meerdere batterijsystemen elkaar gaan tegenwerken? Op basis van welke criteria of logica wordt bepaald welke batterij wanneer mag laden of ontladen?
Ik heb zelf wel wat ideeën hoe dit eventueel geïmplementeerd zou kunnen worden, maar als SlimLaden dit al goed afdekt, is het natuurlijk niet nodig om daar verder aan te sleutelen.
Ik ben benieuwd naar jullie ervaringen en inzichten.
Groeten,
Jan
ben benieuwd @Roedi_de_Lion wat dit voor gedrag gaat opleveren. Ik zie voor morgen al, vanwege het slechte weer wat voorspeld wordt vs de uurpijzen, heel ander laadgedrag. Ook fijn dat je nu duidelijk onderscheid tussen de winst met en zonder batterij hebt gemaakt. Gezien ik dit jaar mijn setup nog maximaal Winst laa maken, en volgend jaar Max eigenverbruik ben ik benieuwd wat dit jaar nog te realiseren valt. De afgelopen 2 maanden waren al -xx,xx euro op de factuur 
Heb zelf een tijdje getest met de Zendure api, maar aangezien ik even afwezig was toch terug gestapt naar custom slim laden aansturing icm flow. Als ik weer wat meer tijd heb zal ik ook weer de Zendure integratie testen
Ik gebruik voor het aansturen van de batterijen een LP-Optimizer. Die bepaalt welke batterij wat moet gaan doen. Het probleem zit met name in NOM, daar wordt het moeilijk. Er zijn ook nog eens 2 varianten. Parallel en Sequentieel. Claude zegt:
Parallel (multi_battery_nom_mode=‘parallel’, de gangbare setting):
- HW + Zendure draaien tegelijk, geen rotatie. HW absorbeert direct de eerste ~800W
(hardware, snel). Zendure’s software-NOM ziet 10s later het residu P1 (wat HW niet kon
dekken) en stuurt de Zendure daarheen. Beide zien dezelfde P1.→ convergeren via
natuurlijke feedback. Dus niet sequentieel — parallel met automatische taakverdeling (HW
eerst, Zendure vult aan).
Sequential (=‘sequential’):
- Eén actieve batterij per tick (rotatie via _apiCurrentActiveBattery). Software-NOM
stuurt alleen als de actieve een Zendure is; is de actieve HW → software-NOM idle, HW
doet 't hardwarematig (regel 256-257). Plus de utilization-based 1↔2 opschaling.
Met het feit dat hij 2 verschillende p1 meters heeft had ik nog even nit aan gedacht. Dat maakt het nog moeilijker.
Welk idee heb jij?
Hi @Roedi_de_Lion, mijn 2 Sessy’s hebben de gehele nacht een kleine hoeveelheid geladen van het Net terwijl de actie STOP had moeten zijn. TEvens geeft de Laadplan Controller 2-6-2026, 07:08:22 [MQTTManager] [Sessy] Unknown action: CHARGE_FROM_SURPLUS aan. HEb je een ticket gelogd op de backlog met screenshots en JSON. ter analyse
Goed dat je hier noemt @Marco_Rombout . Ik zie dezelfde errors bij mijn Sessy’s een paar dagen.
Oplossing komt vandaag.
Een andere gedachte is om de HomeWizard-batterij bijvoorbeeld tussen 01:00 en 06:00 zelfstandig het werk te laten doen.
De Zendure kan de grotere vermogens aan, dus vanaf 06:00 zou ik die op NOM zetten en laten opladen tot bijvoorbeeld 95% SOC. Daarna kan de HomeWizard-batterij worden opgeladen tot 100% SOC, waarna deze weer in standby gaat.
Vervolgens laat je de Zendure weer op NOM draaien en het grootste deel van de dag voor zijn rekening nemen. Rond 01:00 gaat de Zendure weer in standby en neemt de HomeWizard-batterij het over.
Het is misschien minder dynamisch dan de oplossing die je nu hebt gemaakt voor één type batterij, maar het voorkomt dat de twee verschillende batterijen elkaar gaan tegenwerken.
Ik heb er overigens alle vertrouwen in dat het je gaat lukken om ook twee verschillende batterijsystemen slim te laten samenwerken en de verschillende plannen daarop los te laten.
Doet hij dat ook in andere browser? of na hard refresh van de pagina.
Hahahaha…slimmert!
