9ec15c8f-b72a-4e63-b72c-88fca848f06c
Gewoon een json aub.
@Roedi_de_Lion ticket gemaakt
Ff een vraagje. Ik heb nu mn Azimuth verhaal een beetje bijgeschaafd hij was veel te vroeg vol.
- Als Solcast uitvalt dan valt die terug op jouw app?
- Maar wat moet je dan als totale capaciteit invullen als je 2 dakvlakken hebt?
3a. Stel de batterij staat op zon overschot = STOP en de laadkwartieren van de goedkope uren worden geladen maar hij merkt / haalt het niet om vol te worden volgens plan wat gaat die dan doen? Geforceerd bijladen? Dit is voor het MAX eigen vebruik plan.
3b dit kan doordat je bijvoorbeeld een vaatwasser, droger of zelfs de auto gaat laden. Dan staat die dus de gehele tijd te wachten maar op het moment dat hij zou laden vult hij zichzelf niet.
Hoe doe ik dat ?
De omschrijving is idd fout. Hij stopt het laden, omdat hij later goedkoper kan laden. Opgelost in volgende versie 9.1.16. het gaat verder gewoon goed.
Top, dankjewel.
Je kunt via Open meteo toch ook drie dakvlakken invullen?
Hij plant elk kwartier opnieuw vanaf NU.
Als je app Monitor gebruikt, past hij meteen je eigen verbruik aan. Sterker nog, hij draait ook meteen een nieuw plan. Als je automatsich leren aan hebt staan, dan weet hij niet van de droger etc. App monitor heeft daar ook mijn eigen voorkeur.
Forceerd hij dan ook laden? Want anders mis je de goedkope uren en moet de batterij daarna nog proberen te vullen.
Viel me net op dat als ik Zon optimaal aan klik. Zon-overschot (paars) maar het commando NOM afgeeft wat dus betekend dat de batterij gaat laden.
Zonoptimaal zorgt namelijk wel voor dat geforceerde laden op goedkoopste uren.
Doet die dus niet bij eigen verbuik max dan geeft die netjes stop af.
Hmm.. Ik zie het nu ook. Er zit verschil in de actie bij paars. Moet ik even onderzoeken. Nu eerst in de tuin bezig.
Zou ik ook doen schitterend weer om niet achter je pc te zitten. Oh ik zit er nog haha.
Hahhaha…hup lummel. Aan de slag!
84 is aan het einde van het kwartier hè
MMMmmmm 
, zou misschien kunnen kloppen. Maar jij hebt het over versie 16, die zie ik nog niet, kan dat kloppen?
Bij mij helaas nog steeds die soc schakeling bij 2 batterijen.
Kan er geen pijl op trekken soms. De ene keer denk ik het gaat goed en de andere reageert die niet.
Ik ken ook de criteria niet wanneer die mag bijschakelen of welke tijd het duurt voordat die schakelt of terug schakelt dus kan ik niet zeggen of het wel of niet juist is
Vraag: kan je ook beide batterijen aansluiten via mijn Shelly Simulator. Dus bij beide Batterijen de CT op Shelly krijgen? Dan op sequentieel zetten in Slimladen?
Sequentieel NOM
Er zijn twee lagen: rotatie + scaling.
Laag 1: Startbatterij kiezen
Bij activatie wordt gekeken naar de power flow (gemiddelde battery power):
- Laden (power < -50W): kies batterij met laagste SOC (meeste ruimte)
- Ontladen/idle (power > -50W): kies batterij met hoogste SOC (meeste energie)
De gekozen batterij krijgt NOM, alle anderen krijgen STOP.
Laag 2: Monitoring elke 30 seconden
Er draait een setInterval van 30s die twee dingen checkt:
A. NOM Scaling (P1-gebaseerd)
Kijkt naar het P1 vermogen (slimme meter):
Dus als 1 batterij het niet aankan (P1 nog steeds hoge import/export), schakelt hij de 2e bij. En
als het rustig is, schakelt hij er weer eentje uit.
B. SOC Rotatie (alleen als 1 batterij actief)
Elke 30s, maar met minimum 20 minuten tussen rotaties:
Edge cases
Batterij vol (SOC ≥ max_charge_cutoff, typisch 95%):
- Urgent rotatie — slaat de 20 minuten-timer en 10% drempel over
- Schakelt direct naar batterij met laagste SOC
- Als alle batterijen vol: geen rotatie, logt “All batteries full”
Batterij leeg (SOC ≤ minDoD + 5%):
- In de API-variant: bij re-entry (kwartierwissel) checkt hij of de actieve batterij leeg is
- Zo ja → directe switch naar een batterij die wél nog SOC heeft
- In de MQTT-variant: dit wordt indirect afgevangen door de ontladen-rotatie (hoogste SOC wint)
Geen SOC data beschikbaar:
- Geen enkele batterij reageert → fallback naar standaard NOM (alle batterijen)
- Eén batterij null → wordt overgeslagen in alle berekeningen, index-mapping blijft intact
Re-entry bij kwartierwissel:
- Als sequentieel NOM al draait en een nieuw kwartier hetzelfde commando geeft → bestaande state
behouden - Maar wél een quick SOC check: als er een betere primaire batterij is, direct wisselen
Geen P1 data:
- NOM Scaling wordt overgeslagen (“no P1 data available”)
- Alleen SOC-rotatie is dan actief
Dat wil ik wel. Moet ik daar apart iets voor kopen of zo?
