Apparaatprioriteit

Toegevoegd in 1.7.5. Ontwerp: docs/superpowers/specs/2026-07-10-load-priority-above-battery-design.md.

Je lasten die op overschot worden beheerd (zwembadpomp, verwarmingen, …) gaan nu voor op het laden van de thuisbatterij boven de reservezone — de prioriteitsvolgorde in Victron-stijl. Dit is geen modus die je aanzet; het is gewoon hoe apparaatprioriteit zich tot de batterij verhoudt: de batterij is de afvoer onderaan de prioriteitsronde.

Wat het doet

Boven de reservezone (Battery priority SOC, standaard 30 %) wordt vermogen dat anders de batterij zou laden, aan de overschotpool toegevoegd, en SEM verdeelt het over je overschotapparaten in hun normale prioriteitsvolgorde. Wat de lasten niet nemen, gaat naar de batterij — bij een omvormer voor eigen verbruik laadt de batterij gewoon op de overgebleven zon (er wordt haar niets geforceerd opgedragen).

Onder de reservezone vult de batterij zich nog steeds als eerste, zodat je avondreserve beschermd is.

Stel de volgorde in door de batterij te verslepen

De thuisbatterij verschijnt als apparaat in de prioriteitenlijst op het tabblad Besturing (de kaart “Sleep om te ordenen”), gewoon naast de laadpaal en je lasten. Haar positie is de bediening:

• Lasten boven de batterij nemen haar laadvermogen terug (die laden eerst).
• Lasten onder de batterij wijken — de batterij laadt eerst.

Sleep de batterij omhoog om haar te beschermen (minder lasten gaan voor); sleep haar omlaag om meer lasten vóór haar te laten laden. Standaard staat ze onderaan, dus elke overschotlast gaat voor totdat je haar verplaatst. De batterijregel toont haar SOC en het huidige laadvermogen; ze heeft geen aan/uit- of moduskeuze — haar enige bediening is waar je haar neerzet.

De schuifregelaar Battery priority SOC (Instellingen → SEM → Configureren → batterijstap) is nog steeds een absolute ondergrens: daaronder springt de batterij naar de top en laadt ze als eerste, waar je haar ook naartoe hebt gesleept, om je avondreserve te beschermen.

Hoe de prioriteitsronde werkt

De verdeelbare pool wordt het overschot vóór de batterij. SEM loopt je overschot- apparaten af op prioriteit en geeft elk zijn deel als er genoeg beschikbaar is:

Een discrete last gaat alleen aan als het beschikbare overschot zijn volledige nominale vermogen dekt; anders wijkt hij en gaat dat vermogen naar de batterij.

Waar het vermogen vandaan komt, doet ertoe (#744). Heb je de last geregistreerd met een rated_power, dan is dat het getal. Anders houdt SEM een plaatshouder van 1 kW aan totdat het de last één keer ziet draaien, en neemt het daarna de gemeten afname over — in beide richtingen, zodat een lamp aan een meetstekker op zijn echte 8 W uitkomt in plaats van op de plaatshouder te blijven staan en nooit overschot aangeboden te krijgen. Na die eerste meting stijgt het vermogen alleen nog, tot de grootste ooit gemeten afname. Een last zonder vermogenssensor houdt de plaatshouder van 1 kW voorgoed; dat is bewust, want het alternatief is een niet-meetbare last bij elk straaltje overschot aanzetten en de rest van het net halen.

Uitgewerkte voorbeelden

Reservezone = 30 %, twee verwarmingen van 1 kW op prioriteit 2 en 3.

Bewakingen en wisselwerking

• Reserve-ondergrens. Onder Battery priority SOC is het gedrag hetzelfde als voorheen. Dit beschermt de avond.
• Expliciete batterijcommando’s winnen. Een geforceerde lading, een geplande nachtlading of arbitrage batterij→net wordt nooit teruggenomen — de last wijkt ervoor.
• Geen pendelen. De pool is solar − home (onafhankelijk van hoe hij wordt verdeeld), en de eigen afname van een apparaat wordt weer bij het signaal opgeteld, zodat verbruik uit de pool hem precies krimpt met wat er verbruikt is en convergeert. Bestaande mediaan-/EMA-afvlakking en anti-flikker vangen de resterende onrust op.

De auto en elk apparaat volgen dezelfde lijst (1.7.5-beta.3, #576 fase 2)

De prioriteitenlijst is nu de enige bediening voor alles — niet alleen voor de lasten en de batterij:

• De laadpaal is een volwaardige regel, met zijn eigen bedienings-id als sleutel. Boven de batterij → hij neemt het laadvermogen van de batterij terug (laadt eerst, boven de reserve- zone); eronder → hij wijkt. Dit vervangt de oude vaste SOC-poort van 90 %. Je positie in de lijst bepaalt ook de volgorde van verdeling over meerdere laadpalen (de oude ev_surplus_priority is nu alleen de beginwaarde).
• Elk apparaattype doet mee op positie — overschotschakelaars, modulerende lasten, climate/airco, de warmtepomp (SG-Ready) en warm water worden allemaal afgelopen op hun plek in de lijst en delen het teruggenomen laadvermogen van de batterij op dezelfde manier.
• Warmtepomp en warm water zijn ook versleepbare regels (v1.7.5-beta.11, #602) — ze verschijnen met hun eigen pictogrammen (warmtepomp / boiler) en hun overschot- prioriteit is hun positie in de lijst, bij de upgrade één keer overgenomen uit de oude waarden heat_pump_priority / hot_water_priority. De aparte prioriteitsschuifregelaars zijn uitgefaseerd; de oude EV-vlaggen (ev_load_priority, ev_shed_priority, ev_priority_over_battery) worden door de schemamigratie v16 uit opgeslagen configuraties verwijderd (#604).
• De standaardvolgorde is auto → batterij → lasten. Lasten wijken voor het laden van de batterij totdat je er een boven de batterij sleept; de reserve-ondergrens Battery priority SOC blijft een absolute overschrijving (daaronder laadt de batterij eerst, ongeacht de positie).

De batterij — en de zon — uitgeven volgt ook dezelfde lijst (2.1, #885)

Alles hierboven gaat over wie wijkt terwijl de batterij laadt. De gespiegelde vragen — wie de batterij mag uitgeven als ze ontlaadt, en wie de zon krijgt — negeerden de lijst vroeger volledig.

Twee subsystemen hadden elk een eigen kopie van Battery assist max power en behandelden die elk als hun eigen volledige budget: het EV-pad en het lastenpad. Niets bracht ze in overeenstemming, zodat een batterij van 5 kW in dezelfde cyclus 5 kW aan de auto’s én 5 kW aan de lasten kon worden aangeboden. En omdat over elke laadpaal wordt beslist voordat de lastenronde draait, nam een laadpaal met prioriteit 9 batterijvermogen vóór een warmwatervat met prioriteit 1 — dat vat naar boven slepen veranderde niets.

Nu is er één toelage, uitgegeven in de volgorde van de lijst:

• Van apparaten die boven een laadpaal staan, wordt het aandeel opzijgezet voordat de laadpaal de batterij krijgt aangeboden. Wat overblijft, gaat naar de laadpaal; het volgende apparaat eronder draait op zon en net.
• Alleen apparaten die ervoor hebben gekozen doen mee. Een last reserveert niets tenzij zijn modus de batterij omvat (“Zon + accu”), en — nieuw in 2.1 — een laadpaal kan afzonderlijk worden uitgesloten met Batterij mag deze laadpaal ondersteunen, zodat een installatie met twee laadpalen kan zeggen “de garage mag, de gastenlaadpaal niet”. De batterijtoestemming voor de hele installatie geldt daar nog bovenop: een schakelaar per laadpaal kan alleen beperken, nooit een batterij overschrijven die je voor auto’s verboden hebt verklaard.
• Lasten met “’s Nachts afmaken met → Batterij” reserveren niets tegenover een auto. Ze draaien onder de buffer, tot de harde reserve — een band waarin de ondersteuningsgrens van de auto hem verbiedt te komen. De twee concurreren niet om dezelfde energie, dus een nachtvat laat de auto nooit verhongeren en eet de auto nooit het nachtvenster van het vat op.

De reservering is een schatting — het geleerde vermogen van een apparaat, of de drempel die het nodig heeft om aan te gaan. Neemt een apparaat daarna minder af, dan blijft de rest in de volgende cyclus gewoon in de pool.

Hetzelfde geldt nu voor de zon. Over laadpalen wordt eerder in de cyclus beslist dan over lasten, dus vóór 2.1 kon een laadpaal onderaan je lijst de zon uitgeven voordat een last bovenaan überhaupt werd gevraagd — en die last draaide dan op het net. Van lasten die boven een laadpaal staan, wordt nu eerst hun aandeel van het overschot opzijgezet.

Heb je lasten boven een laadpaal gesleept, dan krijgt die laadpaal nu minder zon aangeboden dan vroeger. Dat is de bedoelde wijziging: dat is wat de volgorde altijd al had moeten betekenen.

Eén asymmetrie om te kennen, omdat die op een inconsistentie lijkt: een last die al draait, reserveert niets meer van de zon (zijn afname zit al in het getal voor het huisverbruik dat elke laadpaal aftrekt), maar blijft wel van de batterij reserveren (het batterijplafond is een getal voor de laadtoestand en heeft zo’n term niet). Zonder dat zou een last met batterijondersteuning zichzelf steeds uit en weer aan zetten.

Hoe de positie samenhangt met de batterijmodus

Koppelingen “Vereist” (afhankelijkheidsketens)

Een apparaat kan een ander vereisen (de koppeling “Vereist” in zijn venster Configureren): een handdoekradiator die alleen moet draaien als de zwembadpomp draait, bijvoorbeeld. Een vereist onderliggend apparaat staat altijd direct onder zijn bovenliggende apparaat in de lijst en beweegt mee — sleep het bovenliggende apparaat en het onderliggende volgt, zodat de keten nooit uit elkaar valt. De koppeling wordt bewaard, dus ze overleeft een versleping, de periodieke herontdekking en een herstart.

SEM weigert een koppeling die een kring zou vormen — een apparaat kan zichzelf niet vereisen, en het kan niets vereisen wat (direct of via andere) het al vereist. Een geweigerde koppeling wordt gelogd en de vorige koppeling blijft staan, zodat twee apparaten elkaar nooit in een impasse houden terwijl ze op elkaar wachten om te starten.

Het vermogen van de EV-regel

De regel van de laadpaal toont zijn minimale vermogen (min. ampère × fasen × spanning) als vermogen — de overschotdrempel om te beginnen met laden — niet het theoretische maximum van 32 A × 3 fasen (dat las als “de auto neemt 22 kW af”). Tijdens het laden toont hij de live afname; in rust die startdrempel.

Het plan bekijken

De gelaagde trace (diagnose, section: trace) meldt de rol van elk apparaat in de lijst — bijv. “sink at list position 2”, “charging first — below reserve” — zodat je kunt zien wie elke cyclus vóór wie laadt. Plan van vandaag toont de zwembadpomp / warmte- pomp / warm water in dezelfde vooruitkijkende tijdlijn als de batterij en de auto.

---

Dagelijkse looptijddoelen voor een last (#620)

Toegevoegd in 1.7.5. Ontwerp: docs/superpowers/specs/2026-07-20-620-device-goal-model-design.md.

De prioriteitenlijst bepaalt wie als eerste overschot krijgt; de doel- editor per apparaat (de 🎯-doelknop op de regel van een last) bepaalt hoeveel die last moet draaien en uit welke bron. Het is de tegenhanger aan de lastenkant van het EV- laaddoel: continue verdeling op prioriteit, begrensd door twee harde plafonds — de pieklimiet van het net en de reserve-SOC van de batterij — en bewust geen deadlines per apparaat (zie “Waarom geen deadlines” hieronder).

Modus — hoe SEM de last aanstuurt

De regel van elke last heeft een keuzelijst Modus:

De modus is as 1 — de bron overdag. Wat er ’s nachts (zonder zon) gebeurt, is een aparte keuze, de kiezer “’s Nachts afmaken met” hieronder.

Min- / Max-looptijd (de dubbele schuifregelaar)

Onder de 🎯-doelknop stelt een schuifregelaar met twee handvatten het dagelijkse looptijd- venster in (alleen zichtbaar in de twee zonnemodi):

• Minimum (groen handvat) — een ondergrens, geen stop. Dit is de looptijd waarvoor SEM wil betalen: daaronder mag de last de thuisbatterij of het net met goedkoop tarief gebruiken (zie “’s Nachts afmaken met” hieronder). Is de ondergrens gehaald, dan stoppen die betaalde bronnen — maar gratis zonne-overschot laat de last doordraaien tot het Maximum. Zet op 0 voor “geen doel — neem gewoon overschot”.
• Maximum (oranje handvat) — een plafond, en de enige harde stop. De last draait nooit langer dan dit per dag. Helemaal open = Onbegrensd (“draai zolang de zon duurt”). Blijft bewaard na een herstart; draait een last als hij het plafond raakt, dan zet SEM hem uit.

Het paar leest dus precies zoals de kaart het labelt: “minstens X … tot Y.” Dit spiegelt het bereik voor het laaddoel van de auto (#245), waarbij het doel de door het net gegarandeerde ondergrens is en overschot het laden voorbij die grens tot het maximum mag brengen. Vóór #688 was het Minimum als harde stop gekoppeld, waardoor elk Maximum erboven onbereikbaar was.

Komen beide handvatten op dezelfde plek terecht, tik dan op de splitsknop (⬍) die verschijnt om ze uit elkaar te duwen, zodat je ze weer allebei kunt pakken.

De teller wordt na zonsopkomst gereset, niet om middernacht — zodat een last die de batterij mag gebruiken niet midden in de nacht wordt gereset en opnieuw leegtrekt voordat het overschot van de nieuwe dag komt.

Minimale looptijd / minimale pauze — tegen pendelen

Onder de Min/Max-schuifregelaar staan twee kleine invoervelden: Minimale looptijd en Minimale pauze, in minuten (#688). Ze voorkomen dat een last flippert bij een voorbijtrekkende wolk: zodra SEM een last aanzet, blijft die minstens de minimale looptijd aan, en zodra het hem uitzet, blijft hij minstens de minimale pauze uit. Samen begrenzen ze het pendelen tot ongeveer één periode per looptijd-plus-pauze.

Ze gelden alleen waar SEM degene is die schakelt — de twee zonnemodi. In Alleen piek wordt de last door de gebruiker beheerd en leest de piekafschakelaar deze vensters niet; de regel toont ze nog wel, maar niets raadpleegt ze daar.

Standaardwaarden als je de vakjes leeg laat:

De getallen voor warm water en warmtepomp zijn de getallen die SEM gebruikt voor zijn eigen compressorlogica (#508): een warmtepomp die na een pauze van één minuut opnieuw start, is pure slijtage terwijl het water in het circuit nog op temperatuur komt, en dat is wat de oude standaard van 60 seconden voor warm water deed (#914).

Een waarde die je intypt, wordt opgeslagen, aan je teruggetoond en na elke herstart opnieuw op het apparaat toegepast (2.1, #914 — daarvóór viel hij stilletjes terug naar de standaard). De grijze plaatshouder in een leeg vakje is het venster dat het apparaat op dit moment echt aanhoudt, of een streepje als het apparaat nog niet is opgestart; nooit een verzonnen getal. Het bereik (0–120 min) komt uit de ene grenzentabel van SEM, en de service blijft elke niet-negatieve waarde accepteren, zodat een oudere installatie met een groter getal ongemoeid blijft.

’s Nachts afmaken met — de nachtelijke bron (as 2)

Dit zijn afmaakbronnen: ze worden actief zodra het gratis venster het doel niet meer kan halen, en een last die nog draait wanneer dat weer wel kan, wordt gestopt — overdag levert altijd de modus hierboven. Batterij is alleen ’s nachts (#633): die wordt actief nadat de nachtmodus begint en stopt bij het aanbreken van de dag. Net (2.1, #953) wordt actief zodra het resterende daglicht van vandaag korter is dan de looptijd die nog openstaat — de hele nacht, en het staartje van een korte winterdag — maar nooit op een ochtend waarop de zon nog tijd heeft om het te dekken. Vóór #953 had de netkant helemaal geen venster: het eerste goedkope vak nadat de meterdag bij zonsopkomst wisselt, kocht het doel van de hele dag van de meter, terwijl de zon nog moest komen.

Is de zon weg en is het dagdoel niet gehaald, dan bepaalt één kiezer “’s Nachts afmaken met” (zichtbaar voor beide zonnemodi) wat — als er al iets is — de looptijd afmaakt:

De twee assen zijn onafhankelijk: de modus kiest de bron overdag (zon, of zon + batterijondersteuning boven de buffer), en ’s Nachts afmaken met kiest de bron zonder zon (niets / batterij tot de reserve / goedkoop net). De kiezer omzetten stopt ook een last die al draait op de bron die je hebt verlaten — je hoeft niet te wachten tot de reserve-ondergrens of het goedkope venster afloopt.

De batterijondersteuning overdag (modus “Zon + accu”) spiegelt de EV-ondersteuning (zonnepoort, battery_assist_min_surplus); het nachtelijke ontladen van de batterij stopt bij Battery priority SOC (standaard 30 %).

Optionele stopvoorwaarde

Elke last kan zijn run ook eerder beëindigen als een sensor een waarde passeert — kies de sensor met de entiteitzoeker (de kiezer Stoppen als ≥: bijv. vatniveau ≥ vol, watertemperatuur ≥ 28 °C, SOC van de auto ≥ 80 %). Wis hem met het ✕ van de kiezer.

Waarom geen deadlines (en geen geforceerde aanvulling vanaf het net)

Het oorspronkelijk gevraagde “garandeer het minimum vóór een deadline met het net” is bewust niet gebouwd. In de winter kan een last met hoge prioriteit (de auto) urenlang op het piekplafond zitten, zodat een deadline apparaten met lagere prioriteit (de warmtepomp) zou dwingen allemaal tegelijk tegen dat plafond van het net af te nemen — precies de strijd die we vermijden. Onderzoek in de praktijk (evcc, Solarmanager) bevestigde dat geen van beide deadlines voor algemene apparaten levert; beide regelen continu af op prioriteit. #620 geeft je in plaats daarvan de kiezer “’s Nachts afmaken met” — batterij (opgeslagen zon) of net (venster met goedkoop tarief) — om de looptijd af te maken als de zon tekortschiet, nooit een harde deadline met geforceerde afname.