Laadlogica voor de auto

Dit is het huidige naslagwerk (herschreven in juli 2026 voor het model met één keuzelijst van v1.6.3+, #618). Zet je automatiseringen over van de schakelaars van vóór v1.6.3, zie dan het gearchiveerde oude naslagwerk (Engels) — daarin staat de vertaling van oude naar nieuwe modi.

Bijgewerkt voor v1.7.3 — twee betrouwbaarheidswijzigingen bovenop het model hierboven:

• Laadpaal-reconciler (#392): SEM geeft niet meer elke cyclus opnieuw een hardware- commando. Een reconciler die gewenst tegenover waargenomen vergelijkt (coordinator/charger_reconciler.py), geeft het minimum aan commando’s om daar te komen en laat de laadpaal daarna met rust — dat maakt een einde aan het KEBA-probleem “zakt naar 6 A” / de stroom aan keba.disable, en voegt reconciliatie van de inschakelschakelaar + terugtrekken toe voor laadpalen met een schakelaar (Wallbox, #536).
• Zonnepoort (#537): in elke modus ondersteunt de thuisbatterij het laden van de auto alleen als het echte zonne-overschot minstens battery_assist_min_surplus is (standaard 1200 W; zet op 0 W om batterijondersteuning overal toe te staan, ook ’s nachts). Onder de poort is de batterij gereserveerd voor het huis en neemt de auto af van net + zon. Verschilt van Minimaal zonnevermogen (de ruisondergrens voor de totale PV).

---

De vijf laadmodi

Eén keuzelijst per laadpaal — select.sem_charger_<id>_charge_mode — bevat de hele intentie (de verzameling schakelaars van vóór v1.6.3 is uitgefaseerd; zie het gearchiveerde oude naslagwerk als je oude automatiseringen overzet):

Eerdere versies van deze tabel zeiden dat de batterij bij Alleen zon “mag ondersteunen” — dat deed ze nooit. solar_only leidt alleen vermogen om dat de batterij zou hebben geladen; de ontlaadondersteuning zat alleen in Min + zon, en dat is precies het gat dat Zon + accu dicht.

De details per modus staan op dezelfde kaart: Laaddoel (Min / Max kWh), deadline Klaar om, Min / Max stroom, en Als standaard instellen.

Alleen zon en de nachtelijke ondergrens (#679). De modus is de as voor overdag; de ondergrens Minstens X is een aparte garantie die in elke modus kan gelden. Onder Alleen zon is die garantie strikt een opt-in: ze telt alleen als je haar op die laadpaal instelt, in de eenheid waarop die laadpaal mikt (doel in kWh → Minstens X kWh; doel in % → Minimale SOC). Laat je haar met rust, dan doet Alleen zon ’s nachts niets, wat de gedocumenteerde belofte is. Een globale standaardwaarde in de installatie zet een laadpaal op Alleen zon niet aan — dat kan ook niet, omdat de installatie dat vakje voor je invult, dus het draagt geen intentie. De andere modi die ’s nachts kunnen laden, volgen de globale waarde wel, omdat de aanvulling ’s nachts voor hen het hele doel van de modus is.

Laadmodus Uit is handen af (#898). SEM stuurt niets naar een laadpaal op Uit — geen stop, geen parkeren bij loskoppelen, geen failsafe. Een sessie die je elders in Home Assistant start, loopt ongestoord; overschakelen naar Uit terwijl de eigen lading van SEM loopt, beëindigt die lading één keer. De VPP-exportpauze stopt de auto met een eigen expliciete stop, niet door Uit te lenen.

solar_only en de batterij-“omleiding” (#899). Een deel van de gemeten batterijlading kan aan de auto worden toegeschreven in de veronderstelling dat de omvormer het afstaat. Een opgedragen batterijlading (geforceerd / gepland laden) wordt nooit toegeschreven, en de omleiding telt alleen zolang de meter het ermee eens is: drie cycli met aanhoudende netafname terwijl er een omleiding in het budget zit, sluiten hem uit voor de rest van de aansluitsessie.

Nachtladen uitzetten — zet de ondergrens op 0 (#680). De ondergrens Minstens is de enige bediening voor nachtladen: SEM vult het gat tussen overschot en dat doel aan, dus een ondergrens van 0 betekent geen nachtlading (in elke modus). Er is geen aparte schakelaar — het doel dat je al instelt, is de schakelaar. Dit werkt nu in beide eenheden: het kWh-doel kon altijd al 0 worden, en het %-doel (Minimale SOC) loopt nu van 0–100 % op zowel het handvat Minstens als Hoogstens (vroeger zat het vast op een minimum van 50 %, waardoor een laadpaal op Alleen zon met een %-doel niet kon worden gezegd “nooit ’s nachts van het net” en elke nacht vanaf het net tot ≥ 50 % aanvulde). Om een laadpaal alleen op zon, nooit ’s nachts vanaf net/batterij te laten laden, zet je Minstens = 0 % en Hoogstens = 100 % — overdag laadt overschot tot het plafond, en ’s nachts wordt niets aangevuld. De regeling houdt het effectieve plafond ≥ de ondergrens, dus een Max onder de Min kan geen kwaad.

De bedieningselementen (per laadpaal)

Hoe een beslissing ampère wordt

Elke cyclus van 10 s, per laadpaal: een zuivere beslissing (decide()) berekent de intentie vanuit de eigen kijk van deze laadpaal → het stabiliteitsfilter past mediaanafvlakking toe, in-/uitschakelvertragingen, de startladder (verhoogt automatisch een voorzichtig aanbod van 6 A totdat een kieskeurige auto aanslaat) en het terugtrekken bij een volle auto (#610: na 3 geweigerde ladders 20 min rust) → de reconciler geeft het minimum aan hardwarecommando’s om daar te komen en laat de laadpaal daarna met rust. De strategiesensor vertelt elke stap.

Daarvóór schoont de sensorlezer de vermogensmeting van de laadpaal op: een mediaan over 3 vangt de enkele UDP-uitschieter op die sommige apparaten geven, en (#910) een meting die terugvalt onder 5 % van de laatst geaccepteerde waarde terwijl de eigen status van de laadpaal nog laden aangeeft, wordt maximaal twee cycli op die waarde vastgehouden en gemarkeerd als ev_power_held — een knipper in de rapportagetiming, geen meting. Het vasthouden hangt aan de status: zodra het apparaat zegt dat het gestopt is, gaat de volgende meting ongewijzigd door, en een laadpaal zonder statussensor houdt alleen de mediaan.

Waar het plafond vandaan komt. Twee dingen, en de laagste wint:

1. Max. ampère (number.sem_charger_<id>_maximum_current, 6–80 A) — wat jij instelt. Gebruik het om op te geven waarvoor de laadpaal echt is gebouwd, of om hem daaronder te begrenzen als hij een aansluiting deelt.
2. De eigen limiet van de laadpaal (max_current_a, die bij een apparaat dat via een entiteit wordt gestuurd het eigen maximum van het stuurgetal al meeneemt, #536). De adapter begrenst elk commando daarop, dus de specificatie van het apparaat is de harde grens, wat je hierboven ook instelt.

SEM beslist tegen min(hardware, Max. ampère) — een ingestelde waarde kan om minder vragen dan de hardware toestaat, nooit om meer, want beslissen boven de begrenzing is een verschil tussen wat SEM plant en wat het kan opdragen (#627).

Vóór #746 bestond Max. ampère helemaal niet. Het plafond kwam uit max_charging_current, een configuratiesleutel die geen installatiestap en geen entiteit ooit schreef — de knop laadpaal toevoegen van het dashboard zette hem letterlijk op 32. Elke laadpaal op elke installatie werd daardoor begrensd op 32 A zonder dat de interface iets uitlegde, en dat is twee derde van een laadpaal van 48 A. Installaties die upgraden, houden de waarde die ze hadden: de nieuwe schuifregelaar neemt de oude sleutel over.

#789 was de andere helft van hetzelfde defect. De rekensom van de planner loopt voordat er hardware wordt geraadpleegd en valt terug op 32 A; die terugvalwaarde stond vroeger op dertien plaatsen met de hand uitgeschreven en vijf daarvan zeiden 16 A, zodat de planner voor nachtladen de nacht dimensioneerde op de helft van de energie die een laadpaal van 32 A levert — hij begon vroeger en boekte meer goedkope uren dan nodig. De hardware liep nooit gevaar; het plan zat er alleen naast. Beide helften lopen nu via één functie (devices.base.resolve_max_current) en één constante.

---

Batterijondersteuning en goedkoopste uren

Batterijondersteuning

De thuisbatterij kan de auto voeden als de zon niet genoeg is.

Sinds #545 (“maximaal tot eigen verbruik”), als de batterij in de ondersteuningsband zit (SOC ≥ de buffer-SOC) en er echt zonne-overschot is voorbij de zonnepoort, biedt SEM de volledige ondersteuningsruimte aan — het verhoogt de aangeboden ampère zodat de auto meer afneemt en de omvormer de batterij in de auto ontlaadt, tot aan de buffer-SOC (de ondergrens voor eigen verbruik). Onder de buffer is de batterij niet beschikbaar voor de auto, en de ondersteuning bouwt af naarmate de SOC ernaartoe zakt, zodat de batterij nooit voorbij de ondergrens wordt leeggetrokken. Dit vervangt het oudere gedrag (#501) dat de auto alleen tot het minimum van de laadpaal aanvulde en een volle batterij ongebruikt liet terwijl de auto van het net laadde.

De aparte instelling Ondergrens ondersteuning SOC is verwijderd (opgegaan in de buffer-SOC) — zie CHANGELOG v1.7.3-beta.59.

Wie het eerst uitgeeft (#885). De batterij is één bron, dus de ene apparaten- lijst bepaalt de volgorde: van een last die je boven een laadpaal hebt gesleept, wordt het aandeel opzijgezet voordat die laadpaal iets wordt aangeboden, en de laadpaal draait vanaf daar op zon en net. Lasten die op ’s nachts afmaken met → Batterij staan, zijn de uitzondering — die nemen af onder de buffer-SOC, een band waarin de ondersteuningsgrens van de auto hem verbiedt te komen, dus reserveren ze niets tegenover een auto en eet een auto nooit hun nachtvenster op. Zie Apparaatprioriteit.

Actief in Zon + accu en Min + zon (in beide begrensd door de zonnepoort + buffer-SOC — niet in Alleen zon, dat de batterij nooit voor de auto ontlaadt). Niet in Altijd (max) — die modus neemt per definitie alles van overal. Pure ampère — SEM geeft geen batterijcommando; het eigen eigenverbruiksgedrag van de omvormer doet het ontladen.

Goedkoopste uren (tariefbewust laden)

Het gedrag voor goedkoopste uren (ingebouwd in de modus Zon + goedkoopste uren, en voor Min + zon beschikbaar via de optie Goedkoopste uren per laadpaal) verandert het gedrag op vier plaatsen — niet alleen ’s nachts:

Cheap price threshold (bijv. 0,15) en Expensive price threshold (bijv. 0,35) bepalen de grenzen als geen dynamische leverancier niveaulabels levert.

---

De planner voor nachtladen, stap voor stap

Elke 10 s tijdens het nachtvenster, voor elke laadpaal:

1. Min already reached?  → idle (only top up to "Up to Full" from surplus).

2. Compute deadline_amps = ceil( remaining_kWh / hours_left / watts_per_amp )
                          clamped to [Min current, Max current].

3. Compute effective_rate = Max current            if forcing deadline (deadline earlier than window end)
                            peak_managed_amps      otherwise   ← peak-aware (#274/C1)
   where peak_managed_amps = (peak_limit − avg_energy_plan_home_W) / watts_per_amp.

4. Reachable? = (remaining_kWh / effective_rate) ≤ hours_left.

5. Ask the energy plan (#638) whether this charger is COVERED tonight:
     a. Covered and inside its block?   → charge.
     b. Covered and outside its block?  → WAIT (state = tariff_waiting_for_cheap,
                                          card shows the block's start time).
     c. UNCOVERED (no fresh plan)?      → charge at deadline / top-up amps.
                                          Fail-open: the Min floor is a guarantee,
                                          so a missing plan never costs you the car.
                                          The card says "reactive — no plan yet".

6. Apply current = max(deadline_amps, gentle_ramp_amps). When tonight's plan
   places the charge in a block, the block's watts become amps by the
   charger's **learned W/A ladder** (#904) — the largest setpoint whose
   predicted draw fits the block — never by dividing by a single bucket's
   W/A, which on a car that tapers at high setpoints asked 14 A for a 5.3 kW
   block. A limit lowering the current (slot guard, shed) is written in the
   same cycle (#905); a night verdict is honoured through a blind cycle (#907).
   If shared peak budget exceeded (multi-charger), throttle proportionally (#274/H1).

Gewijzigd in v2.0 (#638). Stap 5 was vroeger de eigen rekensom van de laadpaal voor de goedkoopste uren — tel de goedkope uren vóór de deadline op, wacht als ze de behoefte dekken. Die eigen kiezer is verwijderd. Het nachtvenster komt nu uit het gezamenlijke plan, dat deze laadpaal afweegt tegen de batterij, de uitstelbare lasten en de comfortbanden onder één pieklimiet en één prijs- curve — zodat wachten niet meer betekent “deze uren zijn goedkoop” maar “dit is jouw plek”. Al het andere in de lijst (de deadline, de Min-ondergrens, haalbaarheid, het tempo binnen het piekbeheer, de rustige opbouw) is ongewijzigd en nog steeds reactief.

---

Uitgewerkte voorbeelden

Voorbeeld A — Eén laadpaal, alles standaard

• Modus Min + zon, Min 8,5 kWh, deadline 07:00 (= einde van het venster), goedkoopste uren uit, slim nachtladen uit
• Aangesloten om 22:00, SOC op 30 %, remaining_to_min = 8,5 kWh
• Zonnevoorspelling voor morgen niet van belang (slim nachtladen uit)
• Uren tot de deadline = 9
• Benodigd tempo = 8,5 / 9 = 0,94 kW = ~1,4 A bij driefasig
• Onder het minimum van 6 A → bouwt op naar 6 A en is ~02:00 klaar, daarna rust tot 07:00.

Voorbeeld B — Tariefgeoptimaliseerd, het plan vindt ruimte in de goedkope uren

• Dezelfde opstelling maar met gedrag voor goedkoopste uren aan (modus Zon + goedkoopste uren, of de optie Goedkoopste uren)
• De goedkoopste uren van de nacht zijn 01:00–05:00; effective_rate ≈ 4,1 kW bij 6 A ruimte onder de piek
• Het plan past 8,5 kWh in 01:00–03:00 — dat past binnen de pieklimiet naast wat verder is ingepland
• SEM doet niets vanaf 22:00, status = tariff_waiting_for_cheap, “Volgende: 01:00” op de kaart
• Om 01:00 laadt hij; klaar ~03:00; rust tot 07:00
• De kaart Energieplan toont het blok en de reden: gepland — goedkoopste uren

Voorbeeld C — De nacht is te kort om kieskeurig te zijn

• Min 30 kWh (bijna een volle lading), deadline 07:00, goedkoopste uren aan
• De goedkoopste uren alleen kunnen vóór 07:00 bij het door de piek begrensde tempo geen 30 kWh leveren
• Het plan zet het blok daarom vanaf 22:00, niet in het goedkope dal — het plant de uren die het echt nodig heeft, goedkoopste eerst, totdat de vraag gedekt is
• SEM wacht niet. Laadt vanaf 22:00; status = night_charging
• Komt er helemaal geen plan, dan gebeurt hetzelfde om een andere reden: niet-gedekte EV-vraag valt terug op deadline-ampère en de kaart zegt reactief — nog geen plan. De Min-ondergrens is hoe dan ook een garantie.

Voorbeeld D — Forcerende deadline

• Min 8,5 kWh, deadline = 03:00 (vroeger dan het einde van het venster), goedkoopste uren uit
• Uren tot de deadline = 5
• Benodigd tempo = 8,5 / 5 = 1,7 kW ≈ 2,5 A → wordt toch begrensd op de ondergrens van 6 A
• MAAR: de deadline is “forcerend”, dus SEM gaat voorbij aan het tempo binnen het piekbeheer. Zou de pieklimiet normaal afknijpen tot 4,1 kW, dan duwt de deadline-ondergrens erdoorheen.
• Status: night_charging, deadline_active = true. Zou dit de pieklimiet overschrijden, dan heeft de gebruiker die afweging expliciet geaccepteerd door een vroege deadline in te stellen.

Voorbeeld E — Tariefpauze overdag

• Modus Min + zon met goedkoopste uren aan, bewolkte middag
• De Min-garantie zou normaal van het net trekken om de ondergrens van 6 A vast te houden
• De prijs bereikt om 12:00 het niveau EXPENSIVE
• SEM valt terug op alleen overschot: is de zon minder dan 6 A waard, dan pauzeert de laadpaal. Hervat als de prijs weer naar normaal zakt of de zon het dekt.

---

Wanneer wordt de teller voor het dagdoel gereset?

Elke laadpaal heeft zijn eigen dagelijkse energievak (daily_ev voor die laadpaal). Het vak wisselt op het eigen tijdstip Charge by van de laadpaal (standaard het einde van het nachtvenster, bijv. 07:00).

Waarom niet bij zonsopkomst? Zonsopkomst kan op korte zomernachten eerder zijn dan het einde van het nachtvenster (zonsopkomst 05:30, einde venster 07:00). Een reset bij zonsopkomst zou het vak wissen nadat Min was gehaald (~03:00) maar voordat het nachtvenster sluit — waardoor SEM weer remaining = daily_target zou zien en het nachtladen opnieuw zou starten tot 07:00, waardoor de gebruiker dubbel betaalt. De grens op basis van de deadline sluit dat venster: het vak wisselt pas als de toezegging van vandaag is nagekomen. (#280)

Meerdere laadpalen: het vak van elke laadpaal wordt gereset op zijn eigen deadline. Auto A om 07:00 en auto B om 08:00 resetten onafhankelijk — auto B wordt niet verstoord als de dag van auto A wisselt. Het totaal (sensor.sem_daily_ev_energy) gebruikt de gedeelde deadline zolang alle laadpalen er één delen; zodra hun tijden Klaar om verschillen, is er geen gedeelde deadline meer om op te wisselen, en wordt het totaal om middernacht gereset — de enige grens die alle laadpalen delen (#724). Een tijdstip Klaar om verschuiven verandert nooit de sleutel van de dag die al aan het optellen is; de nieuwe grens geldt vanaf de volgende wisseling. Let op de vorm van een verschuiving naar later: de lopende dag wordt één keer verlengd (hij reset niet op het oude tijdstip — een verschuiving van 07:00 → 23:00 midden op de dag maakt die ene EV-dag tot ~40 uur lang), daarna keert het normale ritme terug.

Zon tussen zonsopkomst en de deadline: telt nog mee in het vak van gisteren. Onschuldig, want Min was al gehaald.

---

Probleemoplossing

---

Warmtepomp — twee geldige aansluitroutes voor SG-Ready

SEM levert geen apparaatdrivers mee — het werkt met HA-entiteiten die andere integraties aanbieden (zie ARCHITECTURE.md → “SEM is not an integration”, Engels). Voor warmtepompen met SG-Ready-ingangen zijn er twee even geldige aansluitroutes, en SEM behandelt ze allebei hetzelfde: als twee switch-entiteiten die tussen on en off wisselen.

Route A — Fysieke relais op AUX-ingangen

Voor Nibe-units zonder Modbus, of elke warmtepomp waarvan de enige SG-Ready-interface een paar hardwarerelais is:

1. Sluit twee fysieke relais aan (bijv. 2× Shelly 1 Mini, een ESP-relaisbord, of elke switch die HA ondersteunt) op de ingangen AUX1 / AUX2 van de warmtepomp.
2. In HA: controleer of beide schakelaars verschijnen onder Ontwikkelhulpmiddelen → Toestanden en correct schakelen.
3. In SEM: open het tabblad Configuratie → sectie Warmtepomp → zet heat_pump_relay1_entity en heat_pump_relay2_entity op die twee schakelaars.

SEM stuurt de vier SG-Ready-toestanden door de twee schakelaars op de contact- paren te zetten die de standaard voorschrijft, precies zoals een hardwarekastje voor netsignalen dat zou doen — zie de relaistabel in de installatiegids. Het is geen gewone 2-bitstelling: BLOCKED is 1:0, NORMAL is 0:0. Zijn je contacten normally-closed bedraad, zet dan SG-Ready omkeren om in plaats van opnieuw te bedraden.

Route B — Software-SG-Ready via Modbus / integratie van de fabrikant

Voor de Nibe S-serie (firmware ≥ 4.7.5) en elke warmtepomp die SG-Ready ondersteunt via een Modbus-register of cloud-API van de fabrikant, is geen hardware nodig:

1. Installeer de bijbehorende HA-integratie — de nibe-integratie van HA, de algemene modbus-integratie met handmatige registerkoppeling, of de officiële integratie van de fabrikant.
2. Stel de integratie zo in dat ze het SG-Ready-register aanbiedt / beschrijft (bijv. holding register 3032 van Nibe schakelt SG-Ready via Modbus in; volgende schrijfacties sturen de toestand).
3. Maak twee template switch-entiteiten in HA. Elke schrijft bij omschakelen één bit van de SG-Ready-toestand naar het juiste register, en leest het huidige bit terug voor zijn toestand.
4. In SEM: hetzelfde als route A — wijs heat_pump_relay1_entity / heat_pump_relay2_entity naar de template-schakelaars.

SEM weet niet en hoeft niet te weten dat er Modbus onder zit. Het ziet twee schakelaars en zet ze om. De HA-integratie is eigenaar van het protocol.

Waarom dit ontwerp?

Sommige HEMS-hulpmiddelen leveren fabrikantspecifieke Modbus-sjablonen mee die rechtstreeks naar registers van omvormers/laadpalen schrijven. SEM kiest bewust een andere vorm — het blijft in de wereld van entiteiten en services van HA, zodat het geen protocolbibliotheek voor elk merk hoeft mee te leveren, niet elke firmwareversie hoeft bij te houden, en geen HA-integraties vervangt die de gebruiker al vertrouwt. Zie ARCHITECTURE.md (Engels) voor het volledige principe.

Zo zie je welke route je gebruikt

• sensor.sem_heat_pump_registration_status toont de actieve modus: registered_sg_ready (alleen relais), registered_climate_only (geen relais, alleen boost via de climate-entiteit), of registered_sg_ready_and_climate (beide).
• Klik op Instellingen → SEM → ⋮ → Diagnose downloaden → het blok heat_pump in de JSON toont de gevonden entiteit-ID’s + hun live toestanden.

---

Faseschakeling — 1↔3 fasen, waargenomen, handmatig en automatisch (#804)

2.1: standaard uit. Bij tests in de praktijk bleek het meegeleverde model schadelijk bij twee merken (een Wattpilot bleef na elke omschakeling gepauzeerd hangen; een Zaptec heeft geen fasecommando — die schakelt op een stroomdrempel). Faseschakeling sluimert totdat je Faseschakeling aanzet voor de laadpaal (Configuratie → Laadpalen). De herziening — een startsignaal per merk, het drempelmodel, een stroombewaking per fase — is het 2.1-traject; alles hieronder beschrijft het gedrag zodra het is ingeschakeld.

Sommige laadpalen kunnen wisselen tussen 1- en 3-fasig laden (de keuzelijst psm van go-e, de KEBA X-serie via Modbus, de vlag van openWB). SEM ondersteunt ze in drie lagen — waarneming, handmatige bediening en automatisch schakelen:

• Schatting van het actieve aantal fasen. Zolang een laadpaal echt vermogen afneemt, deelt SEM de gemeten afname door de opgedragen ampère — watt per ampère is de spanning die echt in gebruik is, en bij ~230 V per fase levert dat het aantal fasen op dat de auto werkelijk gebruikt (een driefasige laadpaal die een eenfasige auto voedt, geeft 1). Een fysieke ondergrens houdt het eerlijk: één fase kan maximaal amps × 230 W dragen, dus de schatting geeft nooit minder fasen dan de afname bewijst — een auto die minder neemt dan het aanbod, geeft de ondergrens in plaats van een leugen, en het exacte aantal zodra hij het aanbod gebruikt (live gevonden: een Zoe die bij een aanbod van 32 A 10 kW afnam ≈ 15 A × 3 fasen). Per laadpaal zichtbaar als active_phases in het attribuut per_charger_phases van sensor.sem_charging_state en als charger_<id>_active_phases in de diagnosedownload. null als de laadpaal te weinig afneemt om te meten.
• De schakelmogelijkheid is een entiteit die jij opgeeft, nooit geraden. Heeft je laadpaal een faseschakelaar, stel dan Faseschakelaar-entiteit in in het laadpaalblok op het tabblad Configuratie van het dashboard (of in de opties: Instellingen → SEM → Configureren → Laadpaal → bewerken). SEM controleert of die bestaat en een select/number/switch is, en toont het oordeel (switch_valid) naast de schatting. Bij een select moet je ook de velden waarde 1-fasig / waarde 3-fasig invullen met de eigen optienamen van de entiteit (dat is het vocabulaire van het apparaat — SEM raadt nooit); een number gebruikt standaard 1/3 en een switch off/on, beide te overschrijven (het psm-getal van go-e gebruikt 2 voor driefasig).
• Handmatig schakelen — het opgeven van de mogelijkheid maakt select.sem_charger_<id>_phase_mode aan (Auto / 1-fasig / 3-fasig). Kies je 1 of 3, dan draait de enige veilige reeks waarmee SEM ooit schakelt: stoppen → omschakelen → laten bezinken (60 s) → starten. Nooit onder belasting — die reeks voorkomt de pauzes, genegeerde commando’s en hangende auto’s die andere projecten per merk oplappen. Tussen twee omschakelingen zit minimaal 2 minuten. Een driefasige laadpaal in de winter vastzetten op eenfasig voor weinig zon is het klassieke handmatige gebruik.
• Automatisch schakelen (phase_mode: auto, de standaard) schaalt de laadpaal naar het overschot: omlaag naar eenfasig na 10 aanhoudende minuten onder het driefasige minimum (~4,1 kW bij 6 A), omhoog naar driefasig na 5 aanhoudende minuten ruimte daarboven (+10 % marge). Harde grenzen beschermen de hardware: maximaal één automatische omschakeling per 30 minuten en 4 per laadsessie — daarna blijft de fase staan tot de volgende keer aansluiten. De W/A-schatting hierboven bevestigt onafhankelijk dat elke omschakeling fysiek is gelukt zodra het laden hervat.
• De live toestand van de reeks en wat SEM op dat moment aanneemt, staan in hetzelfde attribuut per_charger_phases (switch_state, believed_phases) en in de diagnosedownload.

---

De begrenzingstest — zonnestroom oogsten die een exportlimiet verbergt

Sommige omvormers begrenzen hun teruglevering — permanent (een wettelijke limiet) of dynamisch (naar 0 W als de verkoopprijs van stroom negatief is). De prijs is alleen de meest voorkomende reden voor de limiet — hij is geen onderdeel van wat SEM detecteert. De test kijkt alleen naar natuurkunde: een exportlimiet die actief is, wat hem daar ook heeft gezet. Een installatie zonder teruglevering activeert hem op een gewone zonnige dag bij een gewone prijs. Met de limiet actief verlaagt de omvormer de productie tot het lokale verbruik, zodat het gemeten overschot van SEM eerlijk ~0 aangeeft terwijl de panelen kilowatts meer zouden kunnen leveren. Harder uitlezen lost dit niet op — meer verbruik is het enige instrument dat het verborgen vermogen zichtbaar maakt.

Opties → EV-instellingen → “Begrenzingstest” (standaard uit) zet precies dat instrument aan:

1. Vermoeden — de zonnevoorspelling zegt veel meer dan de panelen leveren, de teruglevering staat vast op ~0, en productie ≈ verbruik (het kenmerk van begrenzing; een gewoon bewolkte dag valt af op de voorspellingsterm). De voorspelling wordt ruw gelezen, niet gedempt — de dempingsfactor leert van de vandaag gemeten productie, die op een begrensde dag tot het verbruik wordt beperkt, zodat de gedempte waarde op precies de dag waarvoor de test bestaat zou wegzakken naar wat de omvormer toont. De test mag ook starten als het verborgen vermogen iets onder het minimum van de laadpaal valt (tot 10 % daarvan): ~140 W afnemen om 4 kW aan anders weggegooide zonnestroom vrij te spelen is de goede ruil zodra de begrenzing echt is — negatieve prijzen, of een installatie zonder teruglevering bij elke prijs. In het slechtste geval ≈ 4 ct/uur, bewust begrensd. Merken die hun exportlimiet publiceren, maken dit scherper: SEM herkent de limiet- entiteit automatisch (Huawei active power control, GoodWe grid export limit, SolaX export control, Victron max feed-in, …) — “limiet actief” versnelt de test, “geen limiet” onderdrukt hem volledig. Het veld “Exportlimiet-entiteit” overschrijft de automatische herkenning voor exotische opstellingen.
2. Test — SEM start de auto op minimale ampère. Stijgt de productie binnen ~2 minuten mee, dan was de begrenzing echt; zo niet, dan trekt de test zich terug en probeert hij het 15 minuten niet opnieuw. Een mislukte test kost ongeveer twee minuten afname op minimale ampère — dat is de prijs van de vraag, en de reden dat de functie een opt-in is.
3. Oogsten — de gestegen productie maakt de normale overschotlus zelfdragend. De test blijft telkens één stap ruimte op de ladder aanbieden zodat het laden naar de voorspelling toe klimt — en elke stap moet binnen zijn venster door productie worden gevolgd, anders stopt de klim waar het echte vermogen van de panelen ophoudt. Er wordt nooit een stap op goed geloof gezet.

Een voorspellingsintegratie (Solcast, Forecast.Solar of Open-Meteo) is vereist — zonder voorspelling van het “vermogen nu” is er niets om tegen te verdenken.

Verwante documentatie

• README — Recente verbeteringen (Engels) — releaseopmerkingen per versie
• Gebruikershandleiding — Configuratieopties — volledig overzicht van instellingen
• Meerdere apparaten — opstelling met meerdere laadpalen
• Dashboardgids — uitleg van de interface per kaart
• Probleemoplossing — algemene problemen