Bekende beperkingen

Eerst het Energie-dashboard, niet alleen het Energie-dashboard

De eerste keus van SEM voor zijn sensoren voor zon, net en batterij is de configuratie van het Energie-dashboard van HA (.storage/energy), omdat dat al de officiële lijst met energiesensoren in je systeem is. Sinds 2.1 (#915) is het geen vereiste meer: als die pagina leeg is of zon of net ontbreekt, vraagt de installatie de energie-integraties die je al draait wat ze aanmaken en biedt het de sensoren vooringevuld aan, zodat jij ze kunt bevestigen. Zie Als je geen Energie- dashboard hebt in de Installatiegids. Wat SEM nog steeds niet kan, is een sensor raden voor een systeem dat niets herkenbaars publiceert — elk veld valt dan terug op een gewone entiteitkiezer.

Modules verwijderen de entiteiten van hardware die je niet hebt (2.1, #923)

SEM bouwt alleen de modules die je installatie heeft — batterij, auto, warmtepomp, warm water. De entiteiten van een ontbrekende module worden bij het starten verwijderd en komen terug als de hardware wordt toegevoegd. Dit draait zonder schakelaar; een huis dat SEM niet kan plaatsen, houdt alles.

Slechts één installatie

Er wordt maar één SEM-configuratie-invoer per Home Assistant-installatie ondersteund. Een tweede invoer aanmaken wordt tijdens de configuratiestappen geweigerd.

Vereisten voor de laadpaal

De laadpaal moet aan te sturen zijn via een ondersteunde HA-integratie (KEBA, Easee, go-eCharger, Wallbox, Zaptec, ChargePoint, Heidelberg, OpenWB, OCPP-compatibel, Ohme, Peblar, V2C Trydan, Alfen Eve, Blue Current, OpenEVSE, NRGkick, ABL eMH1, Wallbox achter de MQTT-brug) of via een algemene number-entiteit voor stroomsturing. Wordt de laadpaal niet automatisch herkend, dan moeten de entiteit-ID’s handmatig worden ingesteld.

Ontlaadbeveiliging van de batterij

Ontlaadbeveiliging van de batterij vereist een Huawei Solar-omvormer (of compatibel) die een number-entiteit biedt voor de ontlaadvermogenlimiet van de batterij. Bij andere omvormers zonder deze entiteit kan de ontlading niet actief worden begrensd.

Exportbewaking: wat de omvormer toestaat (2.1, #955)

De exportbewaking werkt met wat de merkintegratie aanbiedt, en de hardware heeft het laatste woord:

• Huawei. De sturing van het actieve vermogen is één register met vijf modi. De referentie-SUN2000 accepteert Unlimited niet (modus 0) — de service-aanroep komt netjes terug en het register komt in plaats daarvan op de modus van de netbeheerder uit — dus “geen begrenzing” wordt uitgedrukt als Limited to 100 %. DI Active Scheduling is een modus van de netbeheerder en wordt niet vervangen tenzij Externe planning overschrijven aan staat. Het teruglezen van de modus (sensor.<omvormer>_active_power_control) wordt traag gepolld: het loopt bij een tweede lezer tot ~15 minuten achter op een schrijfactie, wordt ~60 s unavailable op de host die schreef, en kan na een herstart minutenlang unavailable blijven. Zolang het onleesbaar is, weigert de bewaking te begrenzen.
• Twee HA-hosts op één Huawei-omvormer vechten om de modbus-sessie: de pollings van de tweede host verlopen rond de schrijfacties van de eerste. Draai de bewaking vanaf één host.
• Een vaste terugleververgoeding sluit de meter nooit. De bewaking schakelt in bij een negatieve terugleverprijs, en die kan alleen een dynamische terugleverentiteit melden. Bij een statisch tarief doet de bewaking niets (het getal voor het exporttarief in de interface kan niet onder 0).
• Deye begrenst via de keuzelijst System Work Mode en heeft die besturing ingeschakeld nodig; elke andere omvormer heeft een schrijfbare number-entiteit voor de exportlimiet nodig. Een merk zonder beide weigert en zegt dat.

De ontlaadgrens voor de auto is zo goed als de nachtschatting (#878)

Als uitgeven op basis van de voorspelling aan staat, stopt de ondersteuning batterij→auto bij de hoogste van je buffer-SOC of de ondergrens die is berekend uit wat je huis ’s nachts werkelijk heeft verbruikt. Twee eerlijke beperkingen van dat tweede getal:

• Het is een schatting uit je eigen historie, een hoog percentiel van gemeten nachten, geen voorspelling van specifiek deze nacht. Een ongewoon koude of drukke nacht kan er toch boven uitkomen, en dan eindigt de batterij lager dan de ondergrens bedoelde. De buffer eronder is het harde vangnet.
• Het heeft bewijs nodig. Totdat er vijf goede nachten zijn vastgelegd, blijft het budget op Leren, wordt er geen ondergrens berekend en beslist alleen de buffer — precies zoals voorheen. Dat is de bedoelde terugval, geen fout.

Uitgeven op basis van de voorspelling uitzetten herstelt het oude gedrag volledig: er wordt geen ondergrens berekend en de buffer is de enige grens.

Zonnepoort (ondersteuning batterij → auto)

De zonnepoort (battery_assist_min_surplus, standaard 1200 W) bepaalt hoeveel echt zonne-overschot er moet zijn voordat de thuisbatterij het laden van de auto mag ondersteunen, in elke modus (zet op 0 W om batterijondersteuning overal toe te staan, ook ’s nachts). Opmerkingen:

• Het instelbare bereik is 0–5000 W, dus bij een zeer grote PV-installatie kun je niet meer dan 5 kW overschot eisen voordat de batterij ondersteunt.
• De ontlaadbegrenzing die het aanstuurt, is alleen een harde grens bij omvormers die een number-entiteit voor het ontlaadvermogen bieden (zie hierboven); bij andere bepaalt de poort nog steeds de door SEM gevraagde ampère, maar kan het de ontlading van de omvormer niet fysiek begrenzen.

Arbitrage batterij → net (gekoppeld in v2.0, standaard uit)

Arbitrage batterij → net — opgeslagen energie terugverkopen aan het net als de dynamische terugleverprijs hoger is dan de kosten van opnieuw laden — is volledig gekoppeld sinds v2.0 (#638): het energieplan bepaalt wanneer een verkoopblok mag lopen, de live economie beslist of het op dat moment nog loont, en de modus per batterij beslist of het überhaupt mag.

Het blijft desondanks sluimeren op elke installatie tenzij je het bewust aanzet (#533 blijft staan): de globale opt-in staat standaard uit, allow_arbitrage van elke batterij staat standaard uit, en de v14-migratie zet de vlag één keer uit zodat geen installatie hem per ongeluk erft.

Twee beperkingen om te kennen voordat je het aanzet:

• Controleer eerst je aansluitovereenkomst. Veel contracten staan teruglevering van zonnestroom toe, maar niet van opgeslagen energie. SEM kan je contract niet kennen. sensor.sem_flow_battery_to_grid_power is de getuige voor naleving — met arbitrage uit hoort die altijd 0 W aan te geven.
• De verkoop wordt begrensd op het vermogen dat uit het blok volgt (kWh ÷ uren), niet op het maximale ontlaadvermogen van de omvormer — SEM verkoopt de geplande energie over het geplande venster in plaats van de batterij op volle snelheid leeg te gooien.

Volledige uitleg met uitgewerkte voorbeelden: Batterij-exportarbitrage.

Meterdag op basis van zonsopkomst

SEM gebruikt bewust drie daggrenzen: dagelijkse ENERGIEtotalen (zon / huis / net / batterij) worden om middernacht gereset, gelijk aan het Energie-dashboard van HA en de facturering van energiebedrijven. De dagteller van de auto wisselt op de deadline Klaar om (standaard 07:00), zodat een nachtlading in één vak komt — die komt niet overeen met een vergelijking per kalenderdag. Bij installaties met meerdere laadpalen geldt dit voor het totaal alleen zolang alle laadpalen één deadline delen; met verschillende tijden Klaar om wisselt het totaal om middernacht (de enige grens die alle laadpalen delen, #724), terwijl de eigen teller van elke laadpaal zijn eigen deadline houdt. Looptijddoelen van lasten wisselen bij zonsopkomst, zodat een aanvulling ’s nachts de uren van gisteren afmaakt. Vergelijk je een van de drie met een bron met een andere grens, dan zie je te verwachten verschuivingen, geen afwijking.

Sinds v1.7.5 wordt de dagelijkse huisregel afgeleid van de gereconcilieerde tellers van de dag in plaats van geïntegreerd (#628) — zie het onderdeel in Probleemoplossing. Eén gevolg om te weten: op de dag dat je naar v1.7.5 upgradet, houdt de huisregel voor die ene kalenderdag het oude gedrag en schakelt hij vanaf de volgende middernacht over op de balans.

Financieel overzicht

Kostenbewaking gebruikt óf statisch ingestelde tarieven (HT/NT) óf een dynamische tariefentiteit (Tibber, Nordpool, aWATTar). Er is geen automatische herkenning van tarieven bij energiebedrijven. Terugleveringstarieven moeten handmatig worden ingesteld.

Zonnevoorspelling

Functies op basis van voorspellingen (laadadviezen, beslissingen over batterijondersteuning) vereisen dat Solcast PV Solar (HACS) of Forecast.Solar (ingebouwd) apart is geïnstalleerd en ingesteld. Zonder voorspellingsintegratie zijn deze functies uitgeschakeld.

Uitgeven op basis van de voorspelling heeft bewijs nodig voordat het uitgeeft (2.1)

Het budget wordt gemeten, niet aangenomen, dus het biedt geen getal aan totdat het de metingen heeft. Er lopen twee klokken onafhankelijk van elkaar: vijf vastgelegde nachten van nachtelijk batterijgebruik, en zeven afgesloten dagen van voorspellingsnauwkeurigheid voor de horizon die het wil vertrouwen. Totdat aan beide is voldaan, toont het tabblad Batterij Leren en wordt er niets uitgegeven — dat is het bedoelde gedrag, geen fout.

Beide kunnen worden ingekort vanuit je eigen recorderhistorie (Opnieuw opbouwen uit historie op de batterijkaart, en Nauwkeurigheid van de voorspelling leren uit de historie), maar alleen als de tellers bestaan — zie hieronder.

Twee dingen die mensen van Zon + accu verwachten maar die het bewust niet doet:

• Het stopt iets boven de berekende ondergrens, niet precies erop. Het aanbod bouwt af naarmate de batterij de ondergrens nadert, en een auto met een hoge minimale stroom (een KEBA op 8 A wil ~3,2 kW) accepteert niets meer voordat de afbouw de ondergrens bereikt. Gemeten op een echte installatie: stop op 81 % tegenover een ondergrens van 78,6 %. Een auto met een lager minimum komt dichterbij.
• Het gebruikt de batterij niet voor de nachtelijke aanvulling tot “Minstens”. Zodra het nachtvenster opent, wordt de gegarandeerde ondergrens bewust vanaf het net gevuld — na donker is de taak van de batterij het huis.

Gereconstrueerde nachten zijn een bovengrens, en hebben vier meters nodig (2.1)

Het opnieuw opbouwen van de nachthistorie leest oplopende energietellers in plaats van vermogen te volgen, en daarom kan het maanden terugkijken. Twee gevolgen:

• De teller van de batterij meldt alles wat ze heeft afgegeven, en kan niet scheiden wat het huis verbruikte van wat naar de auto of het net ging. Een gereconstrueerde ontlading is daarom een bovengrens voor het huishoudelijk verbruik. Dat neigt naar meer achterhouden, wat de manier van ernaast zitten is die je niet kan laten stranden — maar het betekent wel dat de schatting iets voorzichtig uitvalt bij een installatie die vanuit de historie is opgebouwd in plaats van live gemeten.
• Het afsluiten van de nachtbalans vereist vier tellers — ontlading van de batterij, netafname, lading van de batterij, en de energie van de laadpaal als je een auto laadt. Ontbreekt er een, dan kan SEM niet zien hoeveel van de nacht het net heeft gedragen, dus melden die nachten alleen het aandeel van de batterij en onderschatten ze het huis. SEM geeft een reparatiemelding met de naam van de ontbrekende sensor in plaats van stilletjes slechter te werken, en nachten die het live heeft gemeten, krijgen altijd de voorkeur boven gereconstrueerde.

De kwartierbewaking beschermt de meter, niet de bedrading (2.1)

De kwartierbewaking begrenst wat SEM opdraagt ten opzichte van je doel-piek- limiet. Ze kan niet begrenzen wat ze niet aanstuurt: alles wat je met de hand schakelt, commando’s van een andere integratie, of een last zonder SEM-apparaatinvoer neemt nog steeds vrij af. Twee verdere beperkingen om te kennen:

• Ze heeft de minimale stroom van de laadpaal als ondergrens in plaats van een auto te stoppen, bewust — dus een kwartier kan nog steeds doorschieten als de basislast van het huis alleen al boven het doel ligt. De reactieve toestand NOOD blijft de harde stop.
• Ze stuurt op de meterstand. Valt de netsensor midden in een kwartier weg, dan draagt de teller de laatste geldige afname over het gat heen en wordt de ruimte begrensd op het doel totdat de meter weer leesbaar is (#906) — de bewaking blijft aan, maar kan een last die tijdens het gat start niet zien. Een installatie waarvan de meter minutenlang blind is, vertrouwt voor die periode nog steeds op de reactieve NOOD-stop.

Zet de schuifregelaar Doellimiet op het tabblad Besturing op MAX (Geen netlimiet) om het piekbeheer volledig uit te schakelen, inclusief de bewaking.

Een knipperende voeding van de omvormer wordt vastgehouden, niet getoond

Sommige omvormerintegraties (vooral Huawei via modbus) vallen meerdere keren per uur een paar seconden weg. De eigen meetentiteiten van SEM (zon, net, batterijvermogen, SOC) houden hun laatste goede waarde tot 180 s vast zolang de bron onleesbaar is en hebben in de tussentijd een attribuut stale_s; alleen een onderbreking die langer duurt, wordt getoond als unavailable. De regellaag gebruikt de vastgehouden waarde niet — een donkere cyclus telt voor elke beslissing nog steeds als donker (inputs degraded — holding). Een waarde die nooit is gelezen (een sensor die sinds een herstart niets heeft gemeld), wordt niet vastgehouden: die blijft onbeschikbaar in plaats van 0 te tonen.

Een netmeter die is ingesteld als apart paar voor afname / teruglevering (Growatt, Senec, Anker, elk handmatig paar) volgt vanaf 2.1 dezelfde regel (#925): de gecombineerde netwaarde is alleen donker als beide helften onleesbaar zijn, en één donkere helft markeert de cyclus nog steeds als verminderd voor de regeling. Daarvóór kon een gesplitst paar zichzelf nooit als donker melden, waardoor elke bescherming tegen een blinde meter voor die installaties stilletjes uit stond.

Piekbeheer

Piekbeheer vereist stuurbare apparaten met schakelaarentiteiten om af te schakelen. Apparaten zonder vindbare schakelaarentiteit moeten handmatig worden ingesteld. De berekening van het voortschrijdende kwartiergemiddelde begint na elke herstart van HA opnieuw.

OCPP-laadpalen stoppen via de schakelaar voor laadsturing (2.1, #976)

Bij de OCPP-integratie is het getal voor de maximale stroom een laadprofiel dat het laadpunt vasthoudt, dus een limiet van 0 A is een vergrendeling, geen pauze. SEM schrijft daar nooit 0 A; het stopt via switch.<laadpunt>_charge_control (RemoteStop) en heeft die schakelaar nodig — automatisch overgenomen van het laadpunt, of ingesteld als Start-/stopentiteit van de laadpaal. Zonder die schakelaar zegt de reparatiemelding “Laadpaal kan niet worden gestopt” dat ook.

Beperkingen van laadpalen

Sommige laadpalen hebben beperkingen die volledige sturing door SEM verhinderen:

• Tesla Wall Connector — alleen monitoren. De Wall Connector biedt in Home Assistant geen vermogenssensor of entiteit voor stroomsturing. SEM kan spanning/stroom lezen maar het laden niet sturen.
• Myenergi Zappi — de Zappi heeft ingebouwde zonne-omleidingslogica die botst met externe overschotsturing. SEM kan de Zappi monitoren maar de laadstroom niet sturen — de Zappi regelt het laden op overschot intern.
• KSTAR-omvormers — er bestaat geen eigen HA-integratie. Gebruik ha-solarman met KSTAR-YAML-profielen voor ondersteuning van omvormer/batterij.
• Easee — de vermogenssensor staat in de HA-integratie van Easee standaard uit. Die moet handmatig worden ingeschakeld onder Instellingen > Apparaten > Easee voordat SEM de laadpaal kan herkennen en instellen.

Faseschakeling 1↔3 voor de auto staat standaard uit

Automatische faseschakeling bestaat, maar sluimert tenzij je het per laadpaal aanzet (ev_phase_switching_enabled). Bij echte tests bleek het meegeleverde model schadelijk bij twee van de drie merken die het probeerden: een Wattpilot blijft hangen in een gepauzeerde geforceerde toestand die een stroomschrijfactie niet kan opheffen, en een Zaptec heeft helemaal geen fasecommando — die schakelt impliciet op een stroomdrempel, waardoor de reeks de laadpaal stopte, niets omschakelde en het opnieuw probeerde. Het veilig maken voor alle merken is werk voor 2.1; tot dan activeert de entiteit alleen het pad niet, en is de keuzelijst voor de fasemodus aan dezelfde sleutel gekoppeld zodat een keuzelijst nooit iets kan beloven wat de aansturing niet doet.

SG-Ready-sturing van de warmtepomp

SEM ondersteunt SG-Ready-sturing van warmtepompen via twee relais-entiteiten (Shelly, ESPHome, enz.). Stel relais 1 en relais 2 in bij de opties onder “Warmtepomp (SG-Ready)”. De warmtepomp wordt beheerd door de overschotregeling — als het zonne-overschot het nominale vermogen van de warmtepomp overschrijdt, schakelt SEM naar de modus BOOST (SG-Ready-toestand 3) en verhoogt het eventueel het temperatuursetpoint. Bij een zeer hoog overschot (instelbare drempel, standaard 5000W) schakelt SEM naar de modus FORCE_ON (toestand 4).

Vereisten: twee schakelaarentiteiten die de SG-Ready-relaisaansluitingen aansturen. Optioneel een climate-entiteit voor temperatuurboost en een vermogenssensor om het verbruik bij te houden.

EV-intelligentie

• Nauwkeurigheid van de virtuele SOC — hangt af van afbouwherkenning of kalibratie via de API van de auto voor het eerste ankerpunt. Zonder een van beide drijft de SOC-schatting in de loop van de tijd af, alleen gebaseerd op het bijhouden van energie en het voorspelde verbruik. Een auto die een start weigert, wordt vastgelegd als geweigerd, niet als vol — de schatting verandert niet bij een weigering.
• Koude start van de verbruiksvoorspeller — heeft minstens 3 dagen gegevens nodig voordat voorspellingen per weekdag bruikbaar zijn. In de eerste 3 dagen wordt een voorzichtige standaardwaarde gebruikt.
• Temperatuurcorrectie — vereist een sensor voor de buitentemperatuur (automatisch herkend via een weather.*-entiteit). Zonder die sensor staat de temperatuurcorrectie uit en gaan voorspellingen uit van 20°C.
• Accugezondheid volgen — vereist meerdere laadsessies over weken/maanden om zinvolle schattingen te geven. Waarden op korte termijn kunnen schommelen.

Eén voertuig per laadpaal

SEM modelleert bewust één auto per laadpaal — de laadpaal is het voertuig. Alle voertuigspecifieke instellingen (SOC-sensor, accucapaciteit, rendement, en de SOC-/%-laad- doelen) en de schatting van de virtuele SOC worden per laadpaal opgeslagen. Meerdere laadpalen (elk één auto) worden volledig ondersteund; twee verschillende auto’s die één laadpaal delen niet.

Delen twee auto’s één laadpaal, dan worden de functies op basis van SOC (%-doel, virtuele SOC, afgeleide actieradius) onnauwkeurig, omdat de toestand per laadpaal geen twee voertuigen kan voorstellen. De auto-onafhankelijke functies werken voor beide auto’s wel correct: gebruik een laaddoel in kWh (geen %), en de afbouwherkenning stopt het laden nog steeds als de accu vol is, ongeacht welke auto is aangesloten.

Samenvoegen van meerdere apparaten

SEM ondersteunt meerdere omvormers, batterij-units en tariefregels voor het net uit het Energie-dashboard van HA (v1.3.0+). Beperkingen:

• SOC van de batterij wordt gemiddeld over de units — hebben batterijen sterk verschillende capaciteiten, dan geeft het gemiddelde de werkelijke gezamenlijke toestand misschien niet goed weer.
• Netvermogensensoren — zijn er meerdere netvermogensensoren, dan worden die opgeteld. Zorg dat ze elkaar niet overlappen (voeg bijv. niet zowel een tussenmeter als een hoofdmeter toe).

Meerfasig laden van de auto

SEM gaat standaard uit van driefasig laden op 230V per fase. Een- of tweefasige configuraties moeten via de opties van de integratie worden ingesteld. Een verkeerde faseconfiguratie leidt tot onnauwkeurige stroomberekeningen.

Betrouwbaarheid van de stekkersensor van de laadpaal over een herstart van HA heen (bevestigd bij KEBA P30)

SEM leest de stekkersensor van de integratie van de laadpaal (bijv. binary_sensor.keba_p30_plug) om te weten wanneer de auto is aangesloten. Bij een KEBA P30 is gezien dat die sensor gedurende langere tijd off meldde (60+ minuten op 29-05-2026 PROD) over een herstart van HA heen, terwijl er continu een auto was aangesloten die actief laadde. Dit lijkt een wisselwerking tussen de HA-integratie en de KEBA-firmware te zijn — de sensor liegt; SEM vertrouwt hem.

Sinds v1.6.0 past SEM een natuurkundige verdediging toe: is ev_charging True of ev_power > 100 W, dan leidt SEM ev_connected = True af, wat de stekkersensor ook zegt (er kan geen stroom lopen zonder verbinding). Een WARNING-regel in het logboek legt elke afleiding vast, zodat het onderliggende probleem bij de bron zichtbaar blijft. De verdediging geldt voor elke laadpaalintegratie, niet alleen voor KEBA.

Zie je SEM ev_connected inferred from physics: plug sensor reported off but ev_power=XW loggen, dan is de verdediging actief en is de stekkersensor van je laadpaalintegratie onbetrouwbaar. De verdediging is volkomen veilig — koppel je de auto WEL los, dan dalen zowel ev_power als ev_charging en gaat SEM correct over naar losgekoppeld.

De laadpaal hervat zelf bij aansluiten (bevestigd bij KEBA P30)

De firmware van de KEBA P30 onthoudt zijn laatste stroomsetpoint ook na een stroomonderbreking. Wordt een auto aangesloten — of na bepaalde interne gebeurtenissen die SEM niet kan waarnemen — dan start de KEBA zelf op het opgeslagen setpoint, volledig los van SEM. Dit werd bevestigd tijdens een PROD-duurtest op 31-05-2026 waarin de laadmodus op Uit stond en de auto werd aangesloten: de KEBA trok zelf 4,1 kW terwijl SEM correct “Solar mode – System ready” meldde met 0 A opgedragen.

Sinds v1.6.5 beperkt SEM dit door de merkspecifieke uitschakelservice (bijv. keba.disable) elke coördinatorcyclus (~10 s) opnieuw te geven zolang de strategie van de gebruikersintentie "disabled" is (modus=Uit) EN DEZE laadpaal meer dan 500 W afneemt (handshake in rust is 100–200 W; echt laden begint bij 4140 W). De beperking is correct per laadpaal bij opstellingen met meerdere laadpalen — alleen de laadpaal die uit staat krijgt de uitschakeling opnieuw; andere laadpalen met actieve modi blijven ongemoeid.

De ongewenste afname is in het slechtste geval begrensd door de periode van de coördinatorcyclus (~10 s): de KEBA kan zelf starten, één cyclus opbouwen, en SEM vangt het in de volgende cyclus op en roept keba.disable aan. Een WARNING-regel in het logboek legt elke zelfhervatting vast, zodat het gedrag bij de bron zichtbaar blijft:

Charger <name> self-resumed while mode=off (drawing 4140W). Calling
stop_session() — will re-assert every cycle until ev_power drops
below 500W. (#315)

Maak je je zelfs zorgen over dat begrensde venster van 10 s — bijv. omdat je stroomtarief elke netafname bestraft — koppel de auto dan gewoon los als hij niet actief laadt. De beperking werkt alleen als de laadmodus op Uit staat én de laadpaal aangesloten is; losgekoppelde kabels kunnen niet zelf starten.

Andere laadpalen (Wallbox, Easee, go-eCharger, OpenEVSE, …) behandelen 0 A over het algemeen als “stoppen” in plaats van “minimum vasthouden” en vertonen dit gedrag niet; de aanroep _set_current(0) van SEM volstaat daar. De oplossing van v1.6.5 geldt echter overal — meldt een laadpaal- integratie een afname > 500 W met laadmodus = Uit, dan treedt het merkspecifieke mechanisme stop_session() in werking, ongeacht de eigenaardigheden van de firmware.

Modus batterijondersteuning kan een kleine netstroom tijdelijk aan de auto toeschrijven

Laadt de auto in de modus battery_assist (zone 4, thuisbatterij ≥ battery_auto_start_soc), dan biedt SEM de auto een budget aan dat de verwachte bijdrage van de batterijontlading omvat (tot battery_assist_max_power, standaard 4500 W). De boordlader van de auto schakelt vrijwel direct naar die stroom, maar de thuisbatterij — een LFP-pakket dat door het BMS van de omvormer wordt beheerd — heeft enkele seconden nodig om haar ontlading op te bouwen van 0 W naar het gevraagde niveau. Tijdens dat opbouwvenster vult het net het gat.

De evenredige toerekening van stromen door SEM (coordinator/flow_calculator.py: calculate_power_flows) verdeelt de werkelijke netstroom over de auto en de huislasten naar hun aandeel in de vraag, dus tijdens de opbouw van de batterijontlading zie je sensor.sem_flow_grid_to_ev_power misschien kort tot een paar honderd watt stijgen, ook al heeft SEM de auto zelf nooit gevraagd van het net af te nemen. Dit is de natuurkunde van de opbouw, geen fout: het duurt een handvol cycli (meestal ≤ 30 s), en het over de dag geïntegreerde getal net-naar-auto blijft meestal onder 5 % van het sessietotaal. De live controle tests/live/test_solar_only_no_grid.sh controleert terecht alleen de strikte netvloer-invariant voor solar_only (waar de officiële belofte “helemaal geen net” is), en behandelt netstroom bij battery_assist als informatief.

Wil je strikt nooit-net-gedrag, kies dan de laadmodus Self-consumption of PV in plaats van Auto, of verlaag battery_buffer_soc zodat de ondersteuningsband hoger eindigt (de vroegere optie battery_assist_floor_soc is verwijderd — de ondersteuningsruimte is onder de buffer al 0).

Tariefmodellen die SEM niet modelleert (2.1, #994)

Het prijsniveau van SEM is een vergelijking tussen de uren van een dag. Twee echte tariefvormen kunnen niet zo worden uitgedrukt, en SEM zegt dat ook in plaats van ze stilletjes in te delen — zie TARIFF_MODELS.md (Engels).

Critical peak pricing (CPP). Een handvol aangekondigde kritieke gebeurtenissen per jaar, geprijsd ver boven de normale band. SEM kent geen aangekondigde gebeurtenissen: bij een dynamisch tarief worden de uren van zo’n gebeurtenis gewoon als duur ingedeeld zodra ze in de curve verschijnen, en dat is laat. Heeft je contract CPP- gebeurtenissen, ga er dan van uit dat het plan van SEM er niets van weet.

Blok- / trapprijzen naar verbruik. Sommige energiebedrijven rekenen af op het cumulatieve maandverbruik in kWh — het SCE-patroon, waarbij het tarief van ~31 ct naar ~42 ct springt zodra de basistoewijzing voor de maand is overschreden. Die prijs hangt af van hoeveel je deze maand hebt verbruikt, niet van het uur, dus geen niveau per uur kan hem weergeven. SEM deelt zo’n tarief in op basis van de tijdsstructuur die het daarnaast heeft (of meldt unknown als die er niet is), en de besparingscijfers gebruiken het tarief dat de integratie op dat moment meldt.

Geen van beide vormen is gevaarlijk — SEM handelt niet op een niveau dat het niet heeft — maar voor geen van beide wordt geoptimaliseerd.

Een herkend merk is een voorstel, geen koppeling (2.1, #915, #956)

SEM leest wat een integratie over zichzelf aangeeft en stelt entiteiten en services voor op het tabblad Configuratie. Het koppelt niets wat jij niet hebt bevestigd. Daaruit volgen twee beperkingen:

• Een service die SEM niet direct kan aansturen, wordt genoemd, niet aangeboden. set_max_current van go-eCharger wil een laadpaalnaam die SEM niet kan invullen; sommige services richten zich op een entiteit. Zo’n voorstel toont met de hand koppelen met de reden.
• Een merk dat vanuit de broncode is toegevoegd, krijgt de status geïmplementeerd, niet live getest. NRGkick, ABL eMH1 en Wallbox via de MQTT-brug zijn in kaart gebracht op basis van de eigen code van de integraties; de eerste eigenaar die het bevestigt, maakt de regel live getest.

Setpointmodellen (2.1, #809, #869)

Eén setpointmodel per installatie. Een huis met twee batterijen die verschillende modellen nodig hebben, wordt nog niet ondersteund. Met direction_select schrijft SEM eerst de richting en pas daarna de watts zodra de keuzelijst die teruggeeft, dus een richtingswisseling komt bewust één cyclus later aan.

De afvoer naar het huis is alles-of-niets (#970 open)

Wordt de batterij vastgehouden, dan betaalt het net het hele huis; staat ze open, dan doet de batterij dat. Een tussenvorm — net tot de pieklimiet, batterij voor de rest — is niet gebouwd.

Elke bediening wordt getoond (#996 open)

Een huis met een vlak tarief ziet nog steeds de prijsbedieningen, die daar niets kunnen doen. Bedieningen verbergen die dit huis niet kan gebruiken, is gepland, niet gebouwd.

KEBA: Uit en Pauzeren houden ongeveer 10 minuten stand

De failsafe van de KEBA brengt het apparaat ongeveer 10 minuten na elke stop terug op zijn terugvalstroom (meestal 8 A), omdat de officiële integratie geen terugvalwaarde van 0 A accepteert en SEM die failsafe bij elke start bewust instelt (een uitgevallen regeling mag de auto niet laten stranden). SEM stopt één keer en vecht niet tegen het apparaat; het geeft in plaats daarvan een reparatiemelding. Een stop houdt alleen stand als het instellen door SEM is uitgezet (keba_arm_failsafe: false via set_option) en de eigen Curr FS van het apparaat op 0 staat.