Probleemoplossing

Sensoren tonen “unavailable”

Oorzaak: SEM leest sensoren uit het Energie-dashboard van HA. Zijn die sensoren onbeschikbaar, dan zijn de SEM-sensoren dat ook.

Oplossing:

1. Ga naar Instellingen > Dashboards > Energie en controleer of de zon- en netsensoren zijn ingesteld
2. Controleer of de onderliggende hardware-integratie (Huawei Solar, SolarEdge, enz.) online is
3. Controleer of de entiteit-ID’s niet zijn veranderd (bijv. na het opnieuw toevoegen van een integratie)
4. Kijk in Ontwikkelhulpmiddelen > Toestanden en zoek de sensorentiteit — toont die “unavailable”, herstel dan eerst de bronintegratie

---

Het laden van de auto start niet

Oorzaak: SEM moet de binaire sensoren Verbonden en Laden van de laadpaal kunnen herkennen.

Oplossing:

1. Controleer of de integratie van de laadpaal (KEBA, Easee, go-eCharger, Wallbox) geïnstalleerd is en werkt

2. Controleer of de Verbonden-sensor “on” toont in Ontwikkelhulpmiddelen > Toestanden als de auto is aangesloten

3. Ga naar Instellingen > Apparaten & diensten > Solar Energy Management > Configureren en controleer de configuratie van de EV-sensoren

4. Bij laden op zon: controleer of het overschot boven het hardwareminimum van je laadpaal ligt:

   • Eenfasige laadpalen: ~1380 W (6 A × 230 V)
   • Driefasige laadpalen: ~4140 W (6 A × 3 × 230 V)

   De instelling min_solar_power (standaard 1000 W in de stap Optimalisatie-instellingen) is de ondergrens voor het overschot waaronder SEM niet eens probeert de laadpaal te starten — houd die ruim onder het hardwareminimum, zodat SEM ruimte heeft om op te bouwen vóór de grens.

5. Bij nachtladen: controleer de select.sem_charger_<id>_charge_mode van deze laadpaal. Min + Solar (de standaard), Solar + cheapest hours en Always (max) laden ’s nachts; Solar only niet, tenzij je voor die laadpaal een ondergrens “Minstens” instelt. Zorg ook dat het binnen het nachtvenster valt.

---

De auto blijft laden terwijl de laadmodus op “Uit” staat

Symptoom: Je zet select.sem_charger_<id>_charge_mode op Uit, het SEM- dashboard toont “Solar mode – System ready” met 0 A opgedragen, maar de laadpaal neemt nog steeds vermogen af.

Oorzaak (vóór v1.6.4): Een regressie in de samengevoegde keuzelijst Laadmodus van v1.6.3. De toestandsmachine viel door naar SOLAR_CHARGING_ALLOWED in plaats van SOLAR_IDLE, en het stoppad van de aansturing werd nooit bereikt.

Oorzaak (na v1.6.4 bij KEBA): de firmware van de KEBA P30 onthoudt zijn laatste stroomsetpoint ook na een stroomonderbreking. Wordt een auto aangesloten (of treedt er bij KEBA een bepaalde interne gebeurtenis op), dan start de laadpaal zelf op het opgeslagen setpoint, los van SEM. Omdat SEM nooit een eigen sessie had gestart, stond zijn vlag _session_active op False en werd het uitschakelpad stilletjes overgeslagen.

Oplossing (v1.6.5+): Upgrade naar v1.6.5 of later. Sinds v1.7.3-beta.50 (#392) regelt de laadpaal-reconciler dit: elke coördinatorcyclus vergelijkt hij de gewenste toestand met wat het apparaat werkelijk doet, en geeft hij de merkspecifieke uitschakelopdracht (bijv. keba.disable) opnieuw zodra de laadmodus op Uit staat en de laadpaal zichzelf heeft hervat. Dat is idempotent — de opdracht gaat alleen uit zolang de waarneming nog afwijkt — en veilig voor de KEBA-firmware. In de logboeken zie je:

reconcile(ev_charger): DISABLE — <reason>

op INFO-niveau (coordinator.charger_reconciler) telkens als hij opnieuw ingrijpt.

Noodoplossing als je op v1.6.4 of ouder zit:

1. Roep handmatig de service keba.disable (of het equivalent van je laadpaal) aan via Ontwikkelhulpmiddelen > Acties.
2. Of koppel de auto gewoon los — KEBA kan niet zelf starten met een losgekoppelde kabel.

De oplossing van v1.6.5 heeft in het slechtste geval een venster van 10 seconden waarin KEBA vermogen kan afnemen voordat SEM de zelfhervatting opmerkt; zie je aanhoudende afname langer dan dat, meld dan een issue met de SEM-logregel en het KEBA- setpoint max_current dat op het moment van hervatten werd gemeld.

Oorzaak (entiteitservice ingesteld als laadpaalservice, v1.7.3+): Staat ev_charger_service op een entiteitservice als number.set_value, input_number.set_value of select.select_option, dan vertaalt SEM het commando automatisch naar de bijbehorende schrijfactie op de entiteit (v1.7.3-beta.8 voor number.set_value, algemeen gemaakt in beta.9). Er is wel een passend doel nodig: zet ev_current_control_entity op de number.*– / input_number.*– / select.*– entiteit voor de maximale stroom van de laadpaal. Een doel in het verkeerde domein logt bij de registratie een WARNING met de naam van de laadpaal. Na 3 opeenvolgende geweigerde commando’s geeft SEM een reparatiemelding (“Laadpaal accepteert geen commando’s”) — die verdwijnt automatisch bij de volgende geslaagde schrijfactie, en sinds beta.9 wordt een verouderde reparatiemelding van vóór een configuratiecorrectie ook gewist bij de eerste goede schrijfactie na het herladen.

Oorzaak (helemaal geen stopmechanisme ingesteld, v1.7.5+ maakt het zichtbaar): de meest voorkomende vorm hiervan bij niet-KEBA-hardware, en het moeilijkst te zien, omdat alles er goed uitziet: de modus staat op Uit, de intentie van SEM is UIT, en SEM geeft elke cyclus de stopopdracht. Die komt alleen niet aan. Is de enige besturing die je SEM hebt gegeven een stroomentiteit number.* met een minimum van 6 A (de meeste opstellingen met Wallbox/Heidelberg/algemene laders), dan:

• is 0 A schrijven onmogelijk — Home Assistant weigert een schrijfactie buiten het bereik voordat die de laadpaal bereikt, dus SEM slaat hem over (#487); en
• is er geen ander mechanisme — geen stopservice, geen keuzelijst voor de laadmodus, geen start-/stopschakelaar, geen <merk>.disable — om op terug te vallen.

Resultaat: niets opent de schakelaar. Bij een installatie met een thuisbatterij is dat geen cosmetisch probleem — de auto trekt rustig enkele kW uit je batterij, ’s nachts, in “Alleen zon” of “Uit” (#627).

Sinds v1.7.5 herkent SEM dit vooraf in plaats van mislukte stops te tellen, en geeft het een reparatiemelding — “Laadpaal kan niet worden gestopt” — met de naam van de laadpaal, het vermogen dat nog stroomt en de entiteit waar het aan vastzit.

Oplossing: geef de laadpaal in de SEM-opties een echt stopmechanisme — in volgorde van voorkeur:

1. ev_start_stop_entity — een switch.* (of input_boolean.*) die de schakelaar opent. De beste optie; de meeste integraties bieden er een (switch.<laadpaal>_charging, …_enable, …_pause).
2. Een laadmodus-select.* plus de optie “stop”/”off” (go-eCharger, OpenWB).
3. Een stopservice van het merk (ev_stop_service).

Kan de stroomentiteit number.* van je laadpaal echt 0 A uitdrukken, dan is dat alleen ook genoeg — SEM gebruikt hem dan. Controleer het attribuut min van de entiteit in Ontwikkelhulpmiddelen → Toestanden.

De reparatiemelding verdwijnt vanzelf zodra de laadpaal geen vermogen meer afneemt.

---

De auto werd ’s nachts geladen terwijl ik alleen zonne-overschot wilde

Oorzaak: De laadmodus van de laadpaal staat nachtladen met netondersteuning toe, en er was een laaddoel (een dagdoel in kWh of een doel-SOC in %) dat de auto nog niet had gehaald — dus heeft SEM ’s nachts aangevuld vanaf het net. De standaardmodus bij een nieuwe installatie is Min + Solar, die bewust ’s nachts laadt.

Oplossing: Om een laadpaal alleen op overschot te laten laden, zet je de select.sem_charger_<id>_charge_mode op Solar only en laat je de ondergrens “Minstens” op 0 (kWh-modus) / de doel-SOC op het huidige niveau (SOC-modus).

Beide helften doen ertoe: Solar only met een ondergrens boven nul vult die ondergrens nog steeds vanaf het net aan vóór het tijdstip Klaar om — met die ondergrens vraag je om een nachtelijke garantie zonder de zon-eerst-modus te verlaten (#634/#679). Met de ondergrens op nul neemt de laadpaal alleen zonne-overschot af.

---

Energiewaarden worden niet bijgewerkt

Oorzaak: De energie-integratie draait elke 10 seconden met trapeziumintegratie. Waarden veranderen alleen als de bronsensoren voor vermogen veranderen.

Oplossing:

1. Controleer of de coördinator draait: sensor.sem_charging_state mag NIET unavailable zijn. Is dat wel zo, dan is de integratie niet gestart — zie de HA-logboeken.
2. Controleer of de vermogenssensoren numerieke waarden hebben (niet “unknown” of “unavailable”)
3. Zoek in de HA-logboeken naar SEM-fouten: Instellingen > Systeem > Logboeken, filter op solar_energy_management
4. Dagelijkse ENERGIEwaarden (zon / huis / net / batterij) worden om middernacht gereset — gelijk aan het Energie-dashboard van HA. Twee bewuste uitzonderingen: de dagteller van de auto wisselt op de deadline Klaar om (standaard 07:00, zodat een nachtlading in één vak blijft; bij installaties met meerdere laadpalen alleen zolang alle laadpalen één deadline delen — anders wisselt het totaal om middernacht, #724), en looptijddoelen van lasten wisselen bij zonsopkomst (zie Meerdere apparaten)

---

Het dashboard verschijnt niet

Het SEM-dashboard wordt bij de eerste installatie automatisch gegenereerd (de schakelaar “Dashboard genereren” in de laatste installatiestap staat standaard aan). Het hoort binnen enkele seconden na het afronden van de configuratie in de zijbalk te verschijnen. Gebeurt dat niet:

Herstel:

1. Roep de service solar_energy_management.generate_dashboard aan via Ontwikkelhulpmiddelen > Acties (zoek op “Solar Energy Management”).
2. Het dashboard verschijnt direct onder Dashboards in de zijbalk — geen herstart van HA nodig.
3. Ververs je browser hard (Ctrl+Shift+R) zodat nieuw geïnstalleerde eigen kaarten uit /config/www/ worden opgepikt.

Verschijnt het dashboard maar tonen kaarten “Custom element doesn’t exist”: sinds v1.7.5 (#617) heeft het dashboard geen enkele verplichte HACS-kaart — elke SEM- kaart zit in de meegeleverde sem-cards.js en de rest is standaard HA. Deze fout na een update is bijna altijd een verouderde browsercache: ververs hard (Ctrl+Shift+R) of wis de cache van de Companion-app. Optionele extra’s (sankey-chart, k-flow-card) worden automatisch herkend als ze geïnstalleerd zijn — zie Dashboardgids → Benodigde HACS-kaarten.

---

Dashboard leeg, logboek meldt “ResourceYAMLCollection has no attribute async_create_item”

Symptoom: het dashboard laadt zonder kaarten (of alleen met de titel), en het HA-logboek toont:

WARNING ... solar_energy_management: SEM detected YAML-mode Lovelace; SEM
card resources cannot be registered automatically. Add the following to
configuration.yaml under `lovelace.resources` and restart:
  - url: /local/custom_components/solar_energy_management/dashboard/card/dist/sem-cards.js
    type: module
  - url: /local/custom_components/solar_energy_management/dashboard/card/sem-localize.js
    type: module

Oorzaak: je draait Lovelace in YAML-modus (je hebt lovelace: mode: yaml in configuration.yaml). In YAML-modus is de lijst met bronnen alleen-lezen — SEM kan zijn bundel niet automatisch registreren, dus de kaarten worden niet geladen en het dashboard blijft leeg. (Gemeld als #283; in v1.6.0 opgelost zodat de bruikbare waarschuwing hierboven verschijnt in plaats van een nietszeggende fout “Could not register”.)

Twee manieren om het op te lossen:

Optie A — overstappen op Lovelace in opslagmodus (het makkelijkst)

Instellingen → Dashboards → ⋮ → “Beheer overnemen” op het hoofddashboard. Dit is de standaard voor nieuwe HA-installaties en waar SEM omheen is gebouwd. De automatische registratie werkt dan bij de volgende herstart.

Optie B — in YAML-modus blijven en handmatig registreren

Voeg de twee bronnen uit de waarschuwing toe aan je configuration.yaml onder lovelace.resources:

lovelace:
  mode: yaml
  resources:
    - url: /local/custom_components/solar_energy_management/dashboard/card/dist/sem-cards.js
      type: module
    - url: /local/custom_components/solar_energy_management/dashboard/card/sem-localize.js
      type: module
    # plus the HACS cards SEM needs:
    - url: /hacsfiles/lovelace-card-mod/card-mod.js
      type: module
    - url: /hacsfiles/lovelace-mushroom/mushroom.js
      type: module
    # ... and apexcharts-card, sankey-chart as installed.

Herstart HA. De waarschuwing wordt nog steeds één keer per opstart gelogd (YAML-modus is bewust alleen-lezen — SEM kan hem niet onderdrukken), maar de kaarten worden geladen.

---

Netafname en teruglevering zijn omgedraaid

De omdraaiing met één tik is gekoppeld aan de meter waarop ze is toegepast (2.1, #971). Netteken herstellen legt vast welke netbron is gecorrigeerd (de gecombineerde sensor, een opgegeven afname-/terugleverpaar, een automatisch gevonden paar). Verander je later hoe SEM het net uitleest — bijvoorbeeld van een gecombineerde meter naar expliciete grid_import_power_entity / grid_export_power_entity — dan wordt de oude tik niet toegepast op de nieuwe bron; de tekendiagnose toont user_flip_applies: false en het logboek meldt het één keer. Tik opnieuw op de nieuwe bron als die echt omgekeerd is, of voer reset_sign_detection uit om schoon te beginnen.

Symptoom: SEM toont netafname terwijl het huis eigenlijk teruglevert (of andersom). Het teken van sensor.sem_grid_power is het tegenovergestelde van de vermogensmeter in de hardware.

Hoe SEM de netrichting bepaalt: SEM leest de netvermogensensor uit de configuratie van je Energie-dashboard in HA. Daarna vergelijkt het het teken van de vermogenssensor met de energietellers voor afname/teruglevering (ook uit het Energie-dashboard) om de tekenconventie automatisch te bepalen. Dat werkt omdat de energietellers altijd in de juiste richting oplopen — loopt de afnameteller op terwijl de vermogenssensor positief is, dan weet SEM dat positief afname betekent en corrigeert het daarop.

Bij een installatie met zonnepanelen draait er eerst een tweede stemmer: zonneproductie heeft geen dubbelzinnig teken, dus als de zon met ≥ 500 W springt en de meter in dezelfde cyclus antwoordt (minstens een kwart van de schommeling beweegt, batterij in rust), laat de richting van dat antwoord de conventie zien. Een cyclus waarin de meter niet bewoog, is geen waarneming en telt niet mee (2.1, #889): bij omvormers die worden gepolld — vooral Huawei via modbus — worden de registers van omvormer en meter seconden na elkaar gelezen, zodat de zonnestap en het antwoord van de meter vaak in verschillende cycli van 10 s vallen, en een zonnesensor die unavailable wordt leest als 0 W, wat eruitziet als een schommeling van 4 kW terwijl de meter stil blijft staan. Vóór #889 was elke zo’n cyclus een volwaardige stem “normaal”, en vier daarvan zetten de SEM-conventie vast op een meter met HA-conventie. Wordt er nooit een schone gelijktijdige beweging gezien, dan blijft de zonnestemmer gewoon stil en beslist de tellerstemmer hierboven.

Als SEM vóór 2.1 het verkeerde teken heeft vastgezet (je bent geüpgraded van een versie die op verouderde cycli stemde): de vastzetting is opgeslagen, dus tik één keer op Tekendetectie resetten (tabblad Besturing → Geavanceerd → Netteken). De detectie draait opnieuw met de gecorrigeerde stemmer; had je de schakelaar Netteken omdraaien als noodoplossing aangezet, zet die daarna dan uit zodat de automatische herkenning weer de leiding heeft.

Vereisten:

• Het Energie-dashboard van HA moet zijn ingericht met energiesensoren voor netafname ÉN teruglevering
• Beide energiesensoren moeten beschikbaar zijn (niet “unknown” of “unavailable”)
• Het netvermogen moet boven 100W liggen om de detectie te activeren

Oplossing:

1. Controleer of je Energie-dashboard zowel flow_from– (afname) als flow_to– (teruglevering) energiesensoren heeft onder Instellingen > Dashboards > Energie > Net
2. Herstart HA — de detectie draait automatisch na het opstarten
3. Controleer de logboeken: ha core logs | grep "Grid sign" — je hoort “Grid sign confirmed/detected” te zien
4. Verschijnt er geen logregel, dan is het vermogen misschien te laag (<100W) of zijn de energietellers onbeschikbaar

Tekenconventies per omvormermerk:

Heb je de netentiteiten handmatig ingesteld (grid_import_power_entity / grid_export_power_entity in de SEM-opties): SEM gebruikt precies wat jij hebt ingesteld en corrigeert het teken NIET automatisch — handmatige configuratie wordt als expliciete intentie behandeld. Sinds v1.7.3-beta.7 vergelijkt SEM je handmatige entiteiten met de tellers van het Energie-dashboard en logt het een WARNING (Manual grid power entities CONTRADICT…) en zet het diag_grid_manual_mismatch: true in de diagnose als de twee velden omgewisseld lijken. Checklist voor de handmatige velden:

• Het veld afname krijgt de sensor die niet nul is terwijl je van het net afneemt; het veld teruglevering de sensor die niet nul is terwijl je teruglevert. Twijfel je, kijk dan naar beide in Ontwikkelhulpmiddelen → Toestanden op een moment van bekende zware afname (bijv. de auto die ’s nachts laadt).
• Beide velden moeten vermogenssensoren zijn (W/kW) — een energieteller (kWh) in een van de velden wordt met een WARNING gemarkeerd en levert onzinwaarden op.
• Stel beide velden in of geen van beide. Met maar één kant ingesteld leest de andere een vaste 0 W en kan die stroomrichting nooit verschijnen (“altijd terugleveren”).

Nederlandse meters met dubbel tarief (DSMR): je meter splitst elke richting in tellers voor tarief 1 en tarief 2 (…verbruik_tarief_1/2, …productie_tarief_1/2). Stel alle vier in in het Energie-dashboard van HA (Instellingen → Dashboards → Energie → Net — je kunt per richting meerdere stromen toevoegen). Met maar de tellers van één tarief ingesteld tellen de netenergiestatistieken van SEM te weinig tijdens de uren van het andere tarief, en is de tekencontrole in die periodes blind.

---

SEM heeft je netvermogensmeters geraden

Symptoom: een reparatiemelding noemt twee entiteiten die SEM heeft aangenomen als je meters voor netafname en teruglevering, en de netcijfers op het dashboard komen niet overeen met wat je meter aangeeft (een huis dat 1,5 kW afneemt, toont 10 W afname).

Oorzaak (#911): er is geen netvermogensentiteit ingesteld en de netbron van het Energie- dashboard heeft geen vermogenssensor, dus valt SEM terug op het vergelijken van entiteitnamen met bekende meterpatronen (power_consumption, power_production, import_from_grid, …). Waar geen treffer op hetzelfde apparaat zit als je netenergietellers, is de keuze een gok — bij een grote installatie kan power_consumption van een warmtepomp of power_production van een voorspelling winnen. Sinds #911 wordt een gok hardop gemeld (deze reparatiemelding en één WARNING) en zijn voorspellings-/schattingsentiteiten nooit kandidaat. Sinds #947 wordt helemaal niet op een gok gestuurd totdat die is bevestigd — zie de volgende sectie. Zolang SEM nog aan het controleren is, toont het netvermogen 0 in plaats van een getal waar niemand achter staat.

Oplossing: open Instellingen → Integraties → SEM → Configureren → Sensoren en zet Netafname-vermogen en Netteruglevering-vermogen op je echte meterentiteiten (beide alleen positief, in W). De reparatiemelding verdwijnt bij de volgende uitlezing. Biedt je omvormer alleen registers per fase, dan werkt een template-sensor die ze optelt — zie grid_import_power_entity in de installatiegids.

SEM kon je netvermogensmeters niet vinden

Symptoom: een reparatiemelding noemt twee entiteiten en zegt dat het niet je meters zijn, en SEM meldt helemaal geen netvermogen.

Oorzaak (#947): de sem_grid_import_power van de melder was een keurige blok- golf — ~852 W gedurende één cyclus, dan 0 — terwijl elke echte meter in huis ongeveer nul aangaf. SEM had sensor.power_production_now, een zonnevoorspellingsentiteit, gekoppeld als terugleveringsmeter, omdat een van de naampatronen voor teruglevering power_production is (de terugleveringsmeter van DSMR/P1).

Voorspellingen uitsluiten loste die ene botsing op (#911), maar een zwarte lijst over elke sensor in een huis raakt nooit af: de afnamepatronen omvatten power_consumption, wat net zo goed een warmtepomp, een apparaatmonitor of een UPS noemt als een meter. Een naamtreffer is dus op zichzelf geen bewijs meer.

SEM beantwoordt de vraag nu in drie niveaus, het zwakste als laatste:

1. Opgegeven — de eigen integratie van de entiteit zegt dat deze sleutel de meter voor netafname/ teruglevering is. SEM leest dat uit de integratielijst, die is opgebouwd uit de eigen repository van elke integratie. Growatt, Senec, Fronius, Tibber en Anker geven zo een volledig paar op. Een voorspellingsintegratie geeft helemaal geen netrol op, dus op dit niveau kan de botsing van #947 niet gebeuren — structureel, niet door een zwarte lijst die iemand compleet moet houden.
2. Zelfde apparaat — een vermogenssensor op het eigen apparaat van de netteller.
3. Naamtreffer — een gok, en het enige niveau dat zijn plek moet verdienen.

Voor dat laatste niveau integreert SEM de kandidaat over een venster en vergelijkt die met de netenergietellers die het al heeft en niet heeft geraden. Een echte meter volgt zijn eigen teller; een voorspelling of een deellast doet dat niet. Drie uitkomsten, en het zijn er echt drie, niet twee:

Een keuze uit niveau 1 of niveau 2 is geen gok en komt nooit in het bevestigingstraject.

Oplossing: geef de echte meters op. Open Instellingen → Integraties → SEM → Configureren → Sensoren en stel Netafname-vermogen en Netteruglevering- vermogen in. Publiceert je omvormer- of cloudintegratie helemaal geen snel netvermogen — cloud-API’s van fabrikanten zoals de northbound-API van FusionSolar doen dat meestal niet — dan is beide leeg laten het juiste antwoord, en is het feit dat SEM zegt dat het blind is voor het net de eerlijke weergave, geen fout om omheen te werken.

Het batterijplatform staat vast op generic

Symptoom: een reparatiemelding zegt dat het batterijplatform op generic staat terwijl er een merkintegratie (Huawei, GoodWe, Deye, …) geladen is, en de batterij- besturing gedraagt zich grof — de ontlaadlimiet wordt elke cyclus opnieuw geschreven, of geforceerd laden/ontladen wordt geweigerd.

Oorzaak (#900): oudere versies van de optiewizard boden op de platformpagina alleen generic / deye aan en stonden standaard op generic — één keer door die pagina lopen zette een merkinstallatie vast op de generieke adapter. De instelling is battery_charge_platform in de opties van de integratie.

Oplossing: open Instellingen → Apparaten & diensten → SEM → Configureren, ga naar de batterijpagina en zet het platform op auto (SEM herkent het merk aan de geladen integratie) of op het merk zelf. De wizard biedt nu elk platform aan dat hij kent en bewaart de opgeslagen waarde. De reparatiemelding verdwijnt in de volgende cyclus.

Laden en ontladen van de batterij zijn omgedraaid

Symptoom: SEM toont dat de batterij laadt terwijl ze eigenlijk ontlaadt (of andersom). Het teken van sensor.sem_battery_power is het tegenovergestelde van wat de hardware meldt.

Hoe SEM de batterijrichting bepaalt: SEM vergelijkt het teken van de vermogenssensor van de batterij met de laad-/ontlaadenergietellers uit het Energie-dashboard. Loopt de ontlaadteller op terwijl het batterijvermogen positief is, dan weet SEM dat positief ontladen betekent (het tegenovergestelde van de SEM-conventie) en corrigeert het automatisch.

Vereisten:

• Het Energie-dashboard van HA moet zijn ingericht met energiesensoren voor laden ÉN ontladen van de batterij
• Beide energiesensoren moeten beschikbaar zijn (niet “unknown” of “unavailable”)
• Het batterijvermogen moet boven 100W liggen om de detectie te activeren

Oplossing:

1. Controleer of je Energie-dashboard energiesensoren voor laden en ontladen van de batterij heeft onder Instellingen > Dashboards > Energie > Batterij
2. Herstart HA — de detectie draait automatisch na het opstarten
3. Controleer de logboeken: ha core logs | grep "Battery sign" — je hoort “Battery sign confirmed/detected” te zien

Tekenconventies per omvormermerk:

---

Piekbeheer werkt niet

Lees eerst de zin die SEM je geeft. Sinds 2.1 zegt een service die echt lastbeheer nodig heeft, welke van twee dingen waar is: uitgeschakeld (zet het aan onder Configuratie → Lastbeheer op het SEM-dashboard) of ingeschakeld maar niet gestart (zoek in het logboek naar “Failed to initialize load management” en herlaad). Twee dingen die vroeger werden geweigerd met lastbeheer uit, worden dat niet meer: het instellen van de doel- pieklimiet — de EV-planner leest dat plafond, of afschakelen nu actief is of niet — en elke instelling per apparaat die via het apparatenregister loopt (modus, afhankelijkheden, doelen, comfortband, anti-cyclusvensters).

Oorzaak: Lastbeheer moet expliciet worden ingeschakeld en ingesteld met een doel-pieklimiet.

Oplossing:

1. Ga naar Instellingen > Apparaten & diensten > Solar Energy Management > Configureren
2. Controleer of load_management_enabled is aangevinkt, en of Geen netlimiet (peak_limit_unlimited) uit staat — dat verbergt de kW-velden en schakelt het piekbeheer volledig uit, inclusief het plafond waarop de laadpaal zich afstemt
3. Stel een realistische target_peak_limit in — het maximum van je netaansluiting, uit het leveringscontract of van de hoofdschakelaar (bijv. 5,0 kW voor een gemiddeld Europees huishouden, ongeveer 38 kW voor een Noord-Amerikaanse aansluiting van 200 A). Het veld accepteert 1–80 kW.
4. Controleer of er stuurbare apparaten zijn gevonden: sensor.sem_controllable_devices_count hoort > 0 te zijn
5. Het voortschrijdende kwartiergemiddelde (sensor.sem_consecutive_peak_15min) moet het doel overschrijden voordat afschakelen wordt geactiveerd

---

“Waarom heeft SEM dat apparaat aangeraakt?” — een lastregel in de diagnose lezen

Elke last in de diagnosedownload (Instellingen → Apparaten & diensten → Solar Energy Management → ⋮ → Diagnose downloaden) bevat twee onafhankelijke antwoorden, en die door elkaar halen is verreweg de meest gemaakte leesfout:

Dus has_control_handle: true op een apparaat dat je op Modus: Uit hebt gezet, is correct en te verwachten — het zegt dat er een schakelaar bestaat, niet dat SEM die mag gebruiken. Lees may_actuate voor “zou SEM dit aanraken”; zegt dat false en greep SEM toch in, dan is dat een fout die het melden waard is (#780).

Vóór v2.0 was dit één veld met de naam is_controllable, dat las als toestemming maar betekende: mogelijkheid-plus-een-beetje-toestemming. Het bestaat nog steeds, afgeleid, zodat oudere hulpmiddelen blijven werken.

---

Kosten of besparingen tonen onjuiste waarden

Oorzaak: SEM gebruikt de ingestelde tarieven voor kostenberekeningen.

Oplossing:

1. Controleer de afname-/terugleveringstarieven in de configuratie van de integratie
2. Bij dynamische tarieven (Tibber/Nordpool/aWATTar): controleer of de prijssensorentiteit bestaat en een numerieke toestand heeft
3. De valuta wordt uit de HA-instellingen gelezen: Instellingen > Algemeen > Valuta
4. Kostensensoren worden dagelijks om middernacht gereset (samen met de energietellers) — waarden voor een deel van de dag zijn te verwachten

---

Dynamisch tarief: prijzen worden als leeg gelezen / classificatie blijft op “normal” hangen

Oorzaak: De ingestelde prijssensor biedt geen prijsreeks in een vorm die SEM herkent. SEM leest prices_today/prices_tomorrow, today/tomorrow (Tibber-kern), prices, today_raw/tomorrow_raw (Tibber Grid Reward), raw_today/raw_tomorrow (Nordpool) en forecasts/rates (Amber/Octopus).

Diagnose: Voer de actie solar_energy_management.diagnose uit met section: tariff. tariff_parsed_attribute noemt het attribuut dat overeenkwam (of null als er geen was), tariff_parsed_count het aantal prijspunten, en tariff_parsed_interval_seconds de gevonden fijnmazigheid (3600 per uur / 900 voor kwartiermarkten).

Oplossing:

1. Wijs Dynamische tariefentiteit naar de eigen sensor van de leverancier die de reeksen bevat — niet naar een template- of afgeleide sensor die alleen de actuele prijs spiegelt
2. Tibber Pulse zonder voorspellingssensor: de Tibber-kernintegratie maakt soms geen sensor electricity_price aan (een probleem bij de bron). Installeer de HACS-integratie Tibber Grid Reward en gebruik de sensor.current_price daarvan (ondersteund sinds v1.7.3-beta.10)
3. Staat de vorm van je leverancier er niet tussen, geef de reeks dan door via een attribuut prices_today op een template-sensor, of open een issue met een dump van de attributen van de sensor

---

De besturingskaart zegt “SEM grijpt niet in”, welke modus ik ook kies

Symptoom: de schakelaar van een last is correct herkend, je zet de modus op Zon (of Alleen piek), en de besturingskaart antwoordt nog steeds “Uit — SEM grijpt niet in”. De modus wijzigen verandert niets.

Oorzaak (opgelost in 2.1, #888): dat oordeel heeft twee invoerwaarden, en de modus is er maar één van. De andere is een handen-af-vlag — “raak deze last nooit aan” — die SEM zelf zette. Was de schakelaar van een apparaat nog niet zichtbaar toen SEM startte (heel gewoon bij een nieuwe installatie, waar de ontdekking ongeveer een halve minuut later klaar is), dan noteerde SEM het apparaat als “niet stuurbaar”. Dat was een rekensom, geen voorkeur. Een halve minuut later las het zijn eigen notitie terug alsof jij dat had gezegd, en sloeg het een permanente handen-af-vlag op die via geen enkel scherm te wissen was. In het eigen huis van de ontwikkelaar stonden acht lasten in die toestand.

Wat de update naar 2.1 doet: bij de eerste start na de upgrade wist SEM elke handen-af-vlag die het zelf over zichzelf had verzonnen, één keer, en logt het één regel met de namen: “cleared N hands-off flag(s) SEM had set about itself, not the user”. Verder verandert er niets. Toont je last daarna “SEM mag ingrijpen”, dan ben je klaar.

Zegt het daarna nog steeds handen af, dan is dat nu een echte vlag, en is het aan jou om die te zetten of te wissen. De toestemming is bereikbaar via de service onder haar eigen naam:

service: solar_energy_management.update_device_config
data:
  device_id: energy_dashboard_pool_pump
  property: hands_off
  value: "false"      # "true" = SEM keeps its hands off; "false" = SEM may act

controllable is dezelfde schakelaar onder zijn oudere naam (value: "true" betekent daar dat SEM mag ingrijpen). Een echte handen-af-vlag die zo is gezet, blijft bewaard na elke herstart en elke toekomstige upgrade — het eenmalige wissen hierboven draait nooit twee keer.

Twee HA-installaties sturen dezelfde hardware aan

Oorzaak: Draai je zowel een productie- als een testinstallatie van HA met SEM op dezelfde fysieke apparaten (KEBA, omvormer, Shelly-schakelaars), dan ontstaan tegenstrijdige commando’s.

Oplossing: Zet de observatiemodus aan op de testinstallatie:

1. Ga naar Instellingen > Apparaten & diensten > Solar Energy Management > Configureren
2. Ga naar Optimalisatie-instellingen
3. Zet Observatiemodus (alleen-lezen) aan
4. Herstart — controleer of het logboek Observer mode: hardware control disabled toont

In observatiemodus leest SEM alle sensoren en berekent het alles normaal, maar stuurt het geen service-aanroepen naar hardware. Dit is veilig om naast een productie-installatie te draaien.

---

Opties tonen “Unknown error occurred”

Oorzaak: Opgelost in v1.2.0. De oorzaak was een NumberSelector met step=0.0001, onder de minimaal toegestane stapwaarde van HA 2026.4, in combinatie met standaardwaarden null in de configuratie waardoor het optiescherm vastliep.

Oplossing: Werk SEM bij naar v1.2.0 of nieuwer. Dit probleem komt in v1.2.0+ niet voor.

---

Easee-laadpaal wordt niet herkend

Oorzaak: De vermogenssensor van Easee staat in de HA-integratie van Easee standaard uit. SEM kan de laadpaal niet herkennen zonder een actieve vermogenssensor.

Oplossing:

1. Ga naar Instellingen > Apparaten & diensten > Easee
2. Klik op het Easee-apparaat
3. Zoek de entiteit voor de vermogenssensor (die staat als uitgeschakeld vermeld)
4. Klik op de entiteit, klik daarna op Inschakelen en bevestig
5. Wacht tot de entiteit beschikbaar is en configureer SEM daarna opnieuw

---

Tesla Wall Connector kan het laden niet aansturen

Oorzaak: De Tesla Wall Connector biedt in Home Assistant geen vermogenssensor of entiteit voor stroomsturing. Dit is een beperking van hardware/integratie — de API van de Wall Connector ondersteunt geen externe stroomsturing.

Status: Alleen monitoren. SEM kan spannings- en stroomwaarden lezen als die beschikbaar zijn, maar kan het laden niet starten/stoppen of de laadstroom aanpassen.

---

Warm water wordt niet verwarmd

Oorzaak: SEM verwarmt warm water alleen als er zonne-overschot is (normale modus) of als een legionelladesinfectiecyclus aan de beurt is (geforceerde modus). Is aan geen van beide voldaan, dan blijft de verwarming uit.

Oplossing:

1. Controleer of de warmwaterentiteit in SEM is ingesteld: kijk bij Instellingen > Apparaten & diensten > Solar Energy Management > Configureren
2. Controleer of de entiteit bestaat en beschikbaar is in Ontwikkelhulpmiddelen > Toestanden — zoek je water_heater.*-, climate.*– of switch.*-entiteit
3. Controleer of de stuurmodus van het apparaat op surplus staat (niet peak_only of off) — SEM schakelt geen apparaten in die op peak_only of off staan
4. Controleer of er genoeg zonne-overschot is: binary_sensor.sem_surplus_available hoort aan te staan — die gaat aan als het overschot het minimumvermogen van de verwarming dekt
5. Gebruik je een water_heater– of climate-entiteit, controleer dan of de sensor voor de actuele temperatuur goed meldt — SEM heeft nauwkeurige temperatuurwaarden nodig om te beslissen wanneer het verwarmt

---

De legionellacyclus draait niet

Oorzaak: De legionelladesinfectiecyclus start alleen als het ingestelde interval (standaard 72 uur) is verstreken sinds het water voor het laatst de desinfectiedoeltemperatuur (standaard 65°C) heeft bereikt.

Oplossing:

1. Controleer hoe lang de laatste desinfectie geleden is: kijk in de attributen van de warmwatersensor of de debuglogboeken van SEM naar de teller uren-sinds-laatste-60C
2. Controleer de instelling van het desinfectie-interval — staat die op 168 uur (maximum), dan zijn de cycli zeldzaam
3. Controleer of de temperatuursensor nauwkeurig is — meldt de sensor ten onrechte temperaturen boven 60°C, dan reset SEM de teller en slaat het de cyclus over
4. Controleer of de warmwaterentiteit beschikbaar en stuurbaar is — SEM kan verwarmen niet afdwingen als de entiteit onbeschikbaar is of in een fouttoestand staat
5. Zet debuglogging aan (zie hieronder) en zoek in de logboeken op legionella of hot_water om de toestand van de cyclus te volgen

---

GoodWe-omvormer — geen waarden na de installatie

Symptoom: SEM installeert zonder problemen met een GoodWe-omvormer, maar alle sensoren tonen “unknown” of 0.

Oorzaak: GoodWe werkt met SEM, maar het Energie-dashboard van HA moet eerst met de juiste GoodWe-energiesensoren zijn ingericht. SEM leest zijn bronsensoren uit het Energie-dashboard — zijn die niet ingesteld, dan heeft SEM niets om te lezen.

Oplossing:

1. Ga naar Instellingen > Dashboards > Energie
2. Voeg onder Zonnepanelen je GoodWe-zonne-energiesensor toe (bijv. sensor.goodwe_total_energy of sensor.goodwe_e_day)
3. Voeg onder Netverbruik je energiesensoren voor netafname/teruglevering toe
4. Heb je een GoodWe-batterij (ES/EM/ET-serie), voeg dan energiesensoren voor laden/ontladen van de batterij toe
5. Herstart Home Assistant en configureer SEM daarna opnieuw

Tekenconventies van GoodWe: SEM herkent de tekenconventie automatisch door vermogenssensoren te vergelijken met energietellers. GoodWe gebruikt meestal positief=teruglevering voor het net en positief=laden voor de batterij — SEM regelt dit automatisch.

GoodWe + Easee-laadpaal: gebruik je een Easee-laadpaal met GoodWe, dan staat de vermogenssensor van Easee in HA standaard uit. Schakel hem in onder Instellingen > Apparaten > Easee > Entiteiten voordat je SEM configureert.

---

De meeste waarden tonen 0 (SolaX en andere opstellingen met alleen energiesensoren)

Symptoom: SEM installeert, maar het grootste deel van de entiteiten (vermogen van zon/net/batterij en alles wat daarvan is afgeleid) blijft op 0. Gemeld voor SolaX via de integratie SolaX Inverter Modbus (solax-modbus) (#250).

Oorzaak: SEM leest realtime vermogen uit de vermogenskoppelingen van het Energie-dashboard van HA (het veld stat_rate, toegevoegd in HA 2025.12). Die worden apart ingesteld van de energiesensoren (kWh) en ontbreken vaak — bij veel integraties, waaronder SolaX, worden alleen de energiesensoren aan het dashboard gekoppeld. Zonder vermogenskoppeling heeft SEM geen live vermogen om te lezen.

Oplossing (automatisch): Sinds v1.5.13 leidt SEM de ontbrekende vermogenssensor automatisch af van hetzelfde apparaat als de ingestelde energiesensor — bij SolaX vindt het bijvoorbeeld zelf sensor.solax_pv_power_total (zon), sensor.solax_measured_power (net) en sensor.solax_battery_power_charge (batterij). De SOC-sensor van SolaX (met de naam Battery Capacity, sensor.solax_battery_capacity) wordt nu herkend via zijn device_class: battery + eenheid %. Gewoon bijwerken en herstarten — in de meeste gevallen zijn er geen handmatige stappen nodig.

Zijn de waarden nog steeds 0: voeg de vermogenssensoren dan handmatig toe aan het Energie-dashboard:

1. Ga naar Instellingen > Dashboards > Energie.
2. Open elke bron (Zon / Net / Batterij) en voeg naast de energiesensor de vermogenssensor toe (W of kW, state_class: measurement).
3. Herstart Home Assistant.

Controleren wat SEM heeft gevonden (het snelst): vouw op het tabblad Systeem van het dashboard Diagnose open en druk op Diagnose kopiëren. De gekopieerde tekst bevat een regel Config:, bijv. solar:pwr=derived,energy=ok | grid:pwr=stat_rate,imp=ok,exp=ok | batt:pwr=none,chg=ok,dis=ok. pwr=none of energy=MISSING laat precies zien welke bron niet gekoppeld is; pwr=stat_rate betekent dat HA de vermogenskoppeling leverde, pwr=derived dat SEM die van het apparaat heeft afgeleid. Plak dit bij het melden van een probleem.

Alle details: download de diagnose via Instellingen > Apparaten & diensten > Solar Energy Management > ⋮ > Diagnose downloaden en kijk bij energy_dashboard.power_sensors / power_source / energy_sensors voor de exacte entiteit-ID’s.

Tekenconventie: SolaX gebruikt positief=afname voor het net (patroon D) — SEM herkent en corrigeert dit automatisch op basis van de energietellers; er is geen template-sensor nodig.

---

Waarden zijn 0 na een herstart van HA, maar kloppen na het herladen van de integratie (#274)

Symptoom: Na een herstart van Home Assistant (zacht of hard) blijven de SEM-waarden op 0 / leeg. De SEM-integratie herladen (Instellingen > Apparaten & diensten > Solar Energy Management > ⋮ > Herladen) brengt ze meteen terug. Gemeld voor SolaX (solax-modbus).

Oorzaak: SEM leidt zijn realtime vermogenssensoren af van het apparaat van de bronintegratie (zie de sectie hierboven). Bij een koude start kan SEM klaar zijn met laden voordat de bronintegratie (bijv. solax-modbus) haar entiteiten heeft geregistreerd, zodat die afleiding niets vindt — en het vermogen op 0 blijft. Handmatig herladen werkt omdat de bron dan volledig geladen is.

Oplossing (automatisch): Sinds v1.5.15 blijft SEM de vermogenssensoren elke updatecyclus opnieuw afleiden totdat ze gevonden zijn, zodat de waarden binnen een cyclus of twee nadat de bronintegratie is opgestart vanzelf verschijnen — handmatig herladen is niet nodig. Je ziet Energy Dashboard power sensors resolved on attempt N — readings starting (#274) in het logboek zodra het herstelt. Het opnieuw proberen is begrensd, zodat een opstelling met alleen energiesensoren en helemaal geen vermogenssensor gewoon stopt met proberen in plaats van eindeloos door te gaan.

---

Debuglogging

De makkelijkste manier is de ingebouwde route van Home Assistant — geen YAML, geen herstart:

1. Instellingen → Apparaten & diensten → Solar Energy Management → Debuglogging inschakelen
2. Laat het probleem opnieuw optreden.
3. Klik op Debuglogging uitschakelen — Home Assistant downloadt een uittreksel van het logboek dat je aan een bugrapport kunt toevoegen.

Op het normale logniveau is SEM bewust stil: een gezonde installatie voegt vrijwel niets toe aan je Home Assistant-logboek. Debuglogboeken zijn gebaseerd op overgangen — SEM logt wanneer een beslissing verandert (laadintentie, batterijcommando, een sensor die stil valt of terugkomt), niet elke cyclus dezelfde onveranderde toestand. Een stil debuglogboek betekent dus dat het systeem stabiel is, niet dat het loggen kapot is.

Als alternatief via configuration.yaml (blijft bewaard na een herstart):

logger:
  default: warning
  logs:
    custom_components.solar_energy_management: debug

Om alleen voor een specifieke module te loggen:

logger:
  logs:
    custom_components.solar_energy_management.coordinator.coordinator: debug
    custom_components.solar_energy_management.coordinator.charging_control: debug
    custom_components.solar_energy_management.coordinator.surplus_controller: debug

Niveaus kunnen ook tijdens het draaien zonder herstart worden gewijzigd via Ontwikkelhulpmiddelen → Acties → logger.set_level.

---

De dagelijkse zon is hoger dan wat mijn PV-strings / mijn omvormer zeggen (hybride omvormers)

Oorzaak: SEM controleert de dagelijkse zon tegen de productieteller die in je Energie- dashboard is ingesteld, zodat een via de cloud gepollde vermogenssensor die tussen metingen naar 0 zakt de dag niet te laag telt. Bij een DC-gekoppelde hybride omvormer is die teller vaak de totale opbrengst van de omvormer, die de AC-uitvoer van de omvormer meet — niet PV. ’s Nachts is die uitvoer je batterij die ontlaadt om het huis te bedienen, zodat de teller in het donker blijft oplopen en SEM dat vroeger als zonneproductie boekte. Op onze eigen Huawei SUN2000 + LUNA2000 leverde dat 3,06 kWh “zon” vóór zonsopkomst op (#681).

Opgelost in v1.7.5-beta.25: beweging van de teller wordt genegeerd zolang de zon onder de horizon staat. Er verandert niets aan het herstel overdag — het geval waarvoor deze functie bestaat, werkt nog steeds.

Hoe je controleert of je getroffen was: vergelijk op een afgeronde dag sensor.sem_daily_solar_energy met de som van je sensoren sensor.sem_pv_string_*_daily_energy. Die horen binnen een paar procent overeen te komen. Is de zon te hoog, dan is het huisverbruik ook te hoog — dat wordt berekend uit de energiebalans, dus opgeblazen zon blaast het 1-op-1 op.

Let op: op de dag dat de oplossing binnenkomt, zijn de cijfers van de getroffen dag al vastgelegd. Dagwaarden zijn correct vanaf de volgende middernacht; maand-/jaar-/totaalwaarden houden de historische overschatting.

“Huis” in SEM is veel lager dan “Huis” in het Energie-dashboard van HA

Dit is meestal geen fout — de twee getallen beantwoorden verschillende vragen.

Het Energie-dashboard van HA toont het totale verbruik en tekent afzonderlijk gevolgde apparaten als een deel daarvan, niet als iets wat ervan wordt afgetrokken. Op elke dag dat je een auto laadt, is het getal van HA dus groter dan daily_home_energy van SEM, met ongeveer de energie van de auto, en zijn ze allebei correct.

De controle, voor een afgeronde dag:

{{ states('sensor.sem_daily_total_consumption') }}   {# compare THIS to the Energy Dashboard #}
{{ states('sensor.sem_daily_home_energy') }}         {# house only, excludes the car #}

Komt daily_total_consumption overeen met je Energie-dashboard en daily_home_energy niet, dan is er niets mis. Wijkt het totaal ook af, dan is dat een echte afwijking — zie de sectie hieronder.

Het dagelijkse huisverbruik komt niet overeen met mijn meter (of met de andere dagregels)

Oorzaak (opgelost in v1.7.5): het huis is de enige regel die niets meet — het is per definitie wat overblijft als de gemeten regels van elkaar worden afgetrokken. SEM berekende die balans vroeger ogenblikkelijk (in watt, elke cyclus) en integreerde de uitkomst. Omdat het huis een klein verschil van grote termen is, komt elke kleine fout van elke sensor vergroot op de huisregel terecht: installaties waarvan de regels voor zon/net/batterij elk tot ≤0,5 % met hun meters overeenkwamen, zagen het dagelijkse huisverbruik toch −8 % tot +15 % afwijken, in beide richtingen.

Sinds v1.7.5 wordt de dagelijkse huisregel afgeleid van de gereconcilieerde tellers van de dag (solar + import − export + discharge − charge − EV), op dezelfde manier als het huisverbruik voor totaal en jaar al werd berekend. Het praktische gevolg: de zeven dagcijfers van SEM tellen nu op — het huis is het exacte restant van de zes regels die ernaast worden gepubliceerd.

Opmerkingen:

• Op de dag dat je upgradet houdt de huisregel één kalenderdag het oude gedrag (de interne middernachtspiegel van de auto heeft een volle dag historie nodig voordat hij in de balans kan). Vanaf de volgende middernacht wordt hij afgeleid.
• De balans neemt het alleen over als elke stromende term wordt ondersteund door een hardwareteller uit je Energie-dashboard; anders houdt de oude integrator de regel. Blijft het huis afwijken, controleer dan of de tellers voor zon, net en batterij zijn ingesteld onder Instellingen → Dashboards → Energie.
• De ogenblikkelijke sensor.sem_home_consumption_power is ongewijzigd (zie ADR 0004) — alleen de dagelijkse energieregel is naar de balans verhuisd.

De auto pauzeerde voor “Zone 1 — batterijprioriteit” vlak na een herstart

Opgelost in 2.1 (#875). De SOC-sensor van de batterij meldt zijn eerste waarde enige tijd na een herstart (een Huawei LUNA2000 heeft tot ~3 minuten nodig). SEM stuurde die periode vroeger op een SOC van 0 % die nooit was gelezen — de laadpaalkaart zei “Zone 1 (SOC=0% < priority=30%) — battery priority” en de auto wachtte op een batterij die eigenlijk in orde was. Een niet-gelezen SOC is nu onbekend, niet 0 %: de auto laadt op zonne-overschot (gedrag van zone 2), er wordt geen batterijondersteuning aangeboden, en de batterij wordt beschermd tegen ontladen in de auto totdat de eerste echte waarde binnenkomt. Er hoeft niets te worden ingesteld. Zie je meer dan een paar minuten na een herstart nog steeds een reden zone 1 met SOC=0%, dan meldt de SOC-sensor zelf niets — controleer hem onder Instellingen → Entiteiten.

Het laden stopte voordat mijn auto-app het doel toonde (trage SOC-sensoren)

Dit is bewust (v1.7.6, #708). Sommige auto-integraties (OnStar en vergelijkbare) vragen de SOC van het voertuig maar eens per 30 minuten op. Sturen op zo’n verouderde waarde liet het doel vroeger doorschieten met sensorvertraging × laadvermogen — een doel van 60 % kon op 67 % uitkomen. SEM houdt nu ook de energie bij die het tijdens de sessie werkelijk heeft geleverd: zegt laatste waarde + geleverde energie dat het doel is bereikt, dan stopt het laden, ook al toont de sensor van de auto nog de oude waarde.

• De laadpaalkaart toont de redenering live: Car: 55 % (28 min ago) · est. now ~59 %, en “Doel bereikt — ~60 % geschat” na de stop. Een mobiele melding legt het ook uit.
• Als de sensor eindelijk bijwerkt: bevestigt die het doel, dan gebeurt er niets. Komt die onder het doel uit, dan hervat SEM automatisch voor het verschil — je ziet misschien een of twee korte aanvullingen met tussenpozen gelijk aan het pollinginterval van de sensor. Dat is de functie die je belofte “minstens X %” nakomt, geen geflipper.
• De batterijmeter toont altijd precies wat je auto meldt — de schatting verschijnt alleen in de inforegel, en alleen zolang de sensor tijdens een sessie verouderd is.

Energiewaarden schoten omhoog na een update of herstart van een integratie

Oorzaak: Herstart of update een hardware-integratie (bijv. Huawei Solar), dan worden haar sensoren kort unavailable. Komen ze terug, dan kon de energie-integrator van SEM de teruggekeerde vermogenswaarde vermenigvuldigen met de hele duur van de onderbreking, wat onrealistische energiepieken opleverde (bijv. 40+ kWh ontladen uit een batterij van 15 kWh).

Bescherming (v1.4.1+): SEM slaat het optellen van energie automatisch over als het tijdsverschil tussen updates groter is dan 120 seconden. Zoek naar deze logmelding:

Energy integration gap: XXXs > 120s limit — skipping cycle to prevent accumulator spike

Als de waarden al omhoog zijn geschoten:

1. De dagtellers worden om middernacht gereset — wacht tot de volgende dag
2. Voor directe correctie: vergelijk de SEM-waarden met de dagtellers van de hardware (bijv. sensor.batteries_tagesentladung) en pas zo nodig de opslag aan
3. Herstart de integratie na correcties: Instellingen > Apparaten & diensten > Solar Energy Management > Herladen

De energie van één apparaat vandaag is absurd (duizenden kWh)

Oorzaak (opgelost in 2.0.0): de energieteller van het apparaat viel terug naar nul — een firmware-update, een opnieuw gekoppeld apparaat, een vervangen meter — en liep daarna weer op tot zijn oude stand. SEM ving de val op maar niet de terugkeer, waardoor het totaal over de levensduur als verbruik van één cyclus werd geboekt. Het kenmerk is de gezondheids- controle van de energiebalans: de onderdelen tellen op tot veel meer dan het totaal van het huis, en precies één onderdeel is verantwoordelijk.

Nu: SEM onthoudt de stand waarvandaan de teller viel en boekt alleen wat die daarboven heeft gewonnen — het werkelijke verbruik tijdens de onderbreking. Een verschil dat geen venster fysiek zou kunnen leveren (meer dan 100 kW voor één last), wordt geweigerd, vastgelegd als blind in plaats van nul, en de meter wordt weer vertrouwd vanaf waar hij nu staat. Zoek naar:

energy counter sensor.X recovered to N kWh after a reset from M — booking … kWh consumed across the … s outage, not the whole reading

Een getal dat vóór de upgrade is geboekt, verdwijnt bij de volgende daggrens (zonsopkomst).

Apparaten & diensten toont tientallen lasten die instellingen zijn, geen apparaten

Oorzaak (opgelost in 2.0.0): het ontdekken van lasten liet elke switch.* toe die het aan een vermogenssensor kon koppelen. Veel hardware publiceert zijn eigen knoppen als schakelaars — reverse / freeze / night light van een WLED-strip, het kinderslot van een wasmachine, het status-LED van een router — en één sensor.*_power koppelt met alle broers en zussen van een apparaat, zodat één strip een dozijn regels kon opleveren, elk stuurbaar op 0 W.

Nu: Home Assistant markeert die entiteiten als configuratie of diagnose, en SEM leest die markering — ze worden niet ontdekt, niet gekozen als stuurelement van een apparaat, en regels die een oudere versie heeft geschreven, verdwijnen vanzelf bij de volgende vernieuwing (gelogd als #781 dropped load row …). Entiteiten die je register niet kent (template-schakelaars, YAML-helpers), blijven behouden, net als alles wat je zelf met register_surplus_device hebt geregistreerd.

---

Reparatiemeldingen uitgelegd — wat elke melding betekent en wat het oplost

Elke reparatiemelding van SEM linkt hierheen (of, waar SEM zelf waarschijnlijk de boosdoener is, naar een vooringevuld bugrapport). Elke sectie zegt wat de melding betekent, waarom SEM hem gaf, en de oplossing — in die volgorde.

Een ingestelde sensor is onbeschikbaar

SEM leest een sensor die je tijdens de installatie hebt opgegeven en Home Assistant meldt hem als unavailable. SEM blijft draaien op de laatste bruikbare route, maar elke beslissing die deze waarde nodig heeft, werkt beperkt. Oplossing: controleer de integratie die de sensor levert (Instellingen → Apparaten & diensten) — herstart die als ze een fout toont; heb je de entiteit hernoemd of verwijderd, wijs SEM dan naar de vervanger op het tabblad Configuratie. De melding verdwijnt vanzelf als de sensor terugkomt.

Een sensor werkt niet meer bij (verouderd)

De sensor bestaat en heeft een toestand, maar die is veel langer niet veranderd dan zijn normale ritme — een bevroren waarde is erger dan een ontbrekende, omdat elk getal daarachter er stilletjes mee door blijft rekenen. Oplossing: de gebruikelijke boosdoener is de verbinding van het apparaat (Modbus/wifi/cloud), niet Home Assistant. Zet de bronintegratie uit en aan of herlaad haar. SEM wist de melding bij de eerste verse update.

SEM noemt een sensor alleen bevroren als zijn hele integratie stil is gevallen: heeft een andere entiteit uit dezelfde integratie-invoer in de afgelopen tien minuten iets gemeld, dan wordt een vlakke waarde als eerlijk beschouwd (integraties zoals foxess_modbus herschrijven een ongewijzigde waarde niet, dus een terugleversensor die de hele middag op 0 W staat, of een batterij in rust, “meldt” nooit — dat is geen stilstand). Een zonnesensor op 0 W met de zon onder wordt ook met rust gelaten, ook als de integratie ’s nachts slaapt.

Geen integratie voor zonnevoorspelling gevonden

SEM plant het nachtladen en de batterijbudgetten op basis van de zonne- voorspelling voor morgen, en er is geen ondersteunde voorspellingsintegratie geïnstalleerd. Alles wat reactief is, werkt nog; alles op basis van de voorspelling staat uit. Oplossing: installeer een van Forecast.Solar (geen account nodig), Open-Meteo Solar Forecast of Solcast, en herlaad daarna SEM. De sectie Zonnevoorspelling op het tabblad Configuratie toont wat SEM heeft gevonden.

De recorder is niet beschikbaar

De recorder van Home Assistant (de historiedatabase) is uitgeschakeld of kapot, en SEM gebruikt die om jaarstatistieken te vullen en van de historie te leren. Oplossing: schakel de standaard recorder: in configuration.yaml weer in (of herstel de database waar die naar wijst). SEM werkt zonder, maar de leerfuncties beginnen bij nul.

SG-Ready-relais van de warmtepomp onbeschikbaar

De schakelentiteit die SEM aanstuurt voor een SG-Ready-signaal is onbeschikbaar, dus de boost van de warmtepomp kan niet worden aangestuurd. Oplossing: controleer de integratie van het relais (vaak een Shelly of vergelijkbaar); is de entiteit hernoemd, kies hem dan opnieuw in de instellingen van de warmtepomp.

Warmtepomp: maar één SG-Ready-relais

SG-Ready codeert vier bedrijfstoestanden op TWEE relais; met één relais kan SEM alleen tussen twee toestanden wisselen en zegt het dat ook in plaats van te doen alsof. Oplossing: sluit het tweede relais aan en stel het in als je warmtepomp het volledige schema met vier toestanden ondersteunt; anders is deze melding ter informatie en kan ze worden weggeklikt.

Contactwaarden SG-Ready van de warmtepomp

Reparatiemelding: “SG-Ready-contact N kan niet worden aangestuurd”.

Een SG-Ready-contact hoeft geen schakelaar te zijn — het kan een text-, number-, select– of input_*-entiteit zijn, en zo voert een Buderus/Bosch achter EMS-ESP zijn twee SG-Ready-ingangen (een bitreeks in een tekstveld). SEM kan de waarde om daarin te schrijven niet verzinnen, dus vraagt het er twee per contact: wat te schrijven om het te SLUITEN en wat te schrijven om het te OPENEN.

Deze melding betekent dat een van de twee ontbreekt, waardoor elk SG-Ready-commando voor die warmtepomp mislukt. Oplossing: open Instellingen → Integraties → SEM → Configureren → Warmtepomp, of het tabblad Configuratie van het dashboard, en vul beide waarden in voor het contact dat in de melding wordt genoemd — of wijs het naar een schakel- entiteit, die geen waarden nodig heeft. De melding verdwijnt in de volgende cyclus.

Schakelaar voor warm water onbeschikbaar

De schakelaar die je warmwaterboost start, is onbeschikbaar — SEM kan zijn warmwaterprogramma niet uitvoeren. Oplossing: zoals bij elk relais: controleer de leverende integratie en kies de entiteit opnieuw als die is veranderd.

Temperatuursensor voor warm water onbeschikbaar

Zonder de temperatuur kan SEM niet bepalen of een boost nodig of klaar is, dus staat het warmwaterprogramma in de wacht. Oplossing: herstel de sensor (of kies een andere in de instellingen); het programma hervat bij de volgende meting.

Een schrijfactie naar de batterijbesturing wordt niet overgenomen

Reparatiemelding: “SEM schreef {entity_id} en die nam de waarde nooit over”.

SEM stelde een batterijbesturing in — meestal de ontlaadvermogenlimiet — en in de volgende cycli gaf de entiteit nog steeds de oude waarde, drie keer achter elkaar. De service-aanroep gaf geen fout; het register hield simpelweg niet vast wat het kreeg.

Dat is geen fout in SEM, en ook niet iets wat een integratiecatalogus van tevoren kan weten. Sommige registers accepteren een schrijfactie en laten die verlopen (de snellading van EG4 duurt 60 minuten en zet zichzelf uit). Sommige zijn globale instellingen die de fabrikant ongemoeid wil laten (EG4’s system_charge_soc_limit, “aanbevolen 101”). Sommige hebben een hartslag of elders een inschakelschakelaar nodig voordat ze overnemen (een AC-THOR-setpoint). Sommige zijn gewoon alleen-lezen-spiegels met een number-domein. Een opgegeven naam ziet er in elk geval hetzelfde uit; alleen de eerste schrijfactie onderscheidt ze.

Wat te doen: open de entiteit in Ontwikkelhulpmiddelen → Toestanden, stel hem met de hand in, en kijk of hij blijft staan. Is dat niet zo, dan is de entiteit de verkeerde voor deze rol — kies het juiste register in de batterijkiezers van de configuratiekaart (de sectie Gedetecteerde hardware toont de kandidaten die de integratie opgeeft). Blijft hij met de hand wel staan maar niet voor SEM, dan heeft de integratie misschien eerst een begeleidende schakelaar of modus nodig; vertel ons het merk en de entiteit en het wordt een regel in de ondersteuningsmatrix.

De reparatiemelding verdwijnt vanzelf zodra een schrijfactie wordt overgenomen.

Een stuurentiteit van de laadpaal is kapot

Een number/switch die SEM gebruikt om je laadpaal aan te sturen, bestaat in het register maar weigert schrijfacties of meldt onbeschikbaar — vaak nadat de integratie van de laadpaal opnieuw is geïnstalleerd en entiteit-ID’s zijn veranderd. Oplossing: open de instellingen van de laadpaal op het tabblad Configuratie van SEM en kies de huidige stuurentiteit opnieuw. De reparatiemelding noemt de exacte entiteit die bedoeld wordt.

De KEBA-failsafe vecht tegen SEM

De failsafe van je KEBA (Curr FS / Tmo FS) zet een terugvalstroom terug zodra SEM stil valt, waardoor de sturing van SEM ongedaan wordt gemaakt. SEM stelt normaal zelf een failsafe in die niet uitslaat; deze melding betekent dat dat niet lukte. Oplossing: stel in de webinterface of DIP-configuratie van de KEBA de terugvalstroom van de failsafe in op 0 (betekenis: een stille regeling = uit blijven), of laat SEM het beheren door de benodigde rechten te geven in de instellingen van de laadpaal.

Je laadpaal draait de stop van SEM op een timer terug

Het apparaat schakelde zichzelf een vast aantal seconden na de stop van SEM weer in, minstens twee keer, zonder commando ertussen — het kenmerk van een failsafe/time-out-terugval aan de kant van de laadpaal (elk merk, niet alleen KEBA; gebruikelijk bij laadpalen die via Modbus worden aangestuurd). SEM vecht er bewust niet tegen — sneller opnieuw stoppen zou de schakelaar laten flikkeren en het apparaat wint toch. Oplossing: zoek de instelling voor de failsafe/terugvalstroom op de laadpaal en zet de terugvalstroom op 0. De melding verdwijnt vanzelf zodra een stop blijft staan.

Bij een KEBA zijn de instellingen Curr FS (terugvalstroom) en Tmo FS (time-out); bij een laadpaal via Modbus staan ze meestal in het registerblok dat de integratie al gebruikt. Is dit een KEBA op de officiële integratie, dan is de timer van SEM zelf: SEM stelt de failsafe van het apparaat bij elke start in (600 s, laadondergrens) zodat een uitgevallen regeling de auto toch laadt, en vraagt om 0 A bij elke stop — wat de KEBA weigert (zijn ondergrens is 6 A). Zet eerst het instellen door SEM uit (solar_energy_management.set_option met keba_arm_failsafe: false) en stel daarna het apparaat in. Tot dan blijven Uit en Pauzeren ongeveer het interval staan dat de melding noemt. Sluit een andere regeling uit (een tweede SEM, een automatisering, de app van de fabrikant op een schema) voordat je het apparaat wijzigt — een vast herinschakelinterval past daar net zo goed bij.

SEM trok zich terug terwijl de laadpaal bleef laden

Elke stop die SEM stuurde, kwam aan, en elke keer sloot de laadpaal zijn schakelaar zelf weer. Na een paar rondes stopt SEM met vechten — voor 30 minuten, verdubbelend als het apparaat weer terugkomt — omdat een schakelaar die om de paar minuten aan en uit gaat de auto in een laadfout kan brengen. Ondertussen blijft de auto afnemen, van het net of van de thuisbatterij. Twee oorzaken zien er vanaf de kant van SEM hetzelfde uit: de eigen autostart of autorisatie van de laadpaal die opnieuw sluit als de auto het opnieuw probeert, of een andere regeling — een tweede SEM- installatie, een automatisering, de app van de fabrikant — die dezelfde laadpaal aanstuurt. Oplossing: zet autostart op de laadpaal uit (of vereis autorisatie), of geef SEM een stopmechanisme dat het apparaat respecteert. Kan er een andere regeling bestaan, zet die dan eerst stil: houden de stops van SEM dan wel stand, dan was dat het. De melding verdwijnt zodra de auto niet meer afneemt of SEM de controle weer overneemt.

De laadpaal neemt af op een ander aantal fasen dan SEM denkt

Symptoom: de auto neemt een fractie — of een veelvoud — af van het vermogen dat SEM zegt te geven, en de getallen komen nooit bij elkaar. Bij een laadpaal op Zon + goedkoopste uren of Min + zon weigert de planner ook de nacht überhaupt te boeken, omdat het minimum dat hij berekent groter is dan de ruimte die hij heeft.

Elke stroom die SEM opdraagt, is watts ÷ (phases × volts). Dat ene getal bepaalt dus de aangeboden stroom, het minimum waarvan de nachtplanner denkt dat de auto het nodig heeft, en de ruimte die de piekbewaking overlaat. De standaard van SEM is 3, en het getal Fasen per laadpaal is waar je het corrigeert.

Twee foutrichtingen, allebei echt:

SEM meldt het nu zelf — maar alleen als het dat kan bewijzen. Een afname boven wat de aanname toestaat, weerlegt die direct: één fase van 230 V kan maximaal 230 W per opgedragen ampère afnemen, dus een hoger getal betekent meer fasen, bij elk afzonderlijk setpoint. Een afname eronder bewijst op zichzelf niets — een auto die een derde van het aanbod neemt, ziet er precies zo uit als een auto op één van de drie fasen. Wat ze onderscheidt, is de ladder: een vaste vermogensgrens geeft minder watt per ampère naarmate het aanbod stijgt; een aantal fasen geeft bij elk setpoint dezelfde watt per ampère. Daarom meldt SEM de lage richting pas als het twee setpoints heeft gezien die ver genoeg uit elkaar liggen om die twee verhalen te onderscheiden, en blijft het anders stil in plaats van te gokken.

Totdat je een echte afwijking corrigeert, leert SEM helemaal niets van die laadpaal: elke meting valt buiten de aannemelijke band en wordt weggegooid, dus het herstelt niet vanzelf.

Oplossing: zet Fasen op de laadpaal op het getal dat de reparatiemelding noemt — dat is het aantal dat de meter over de hele ladder heeft gemeten, en dat is het aantal waarmee SEM moet rekenen. Verander je later de auto of de bedrading, dan zegt SEM het opnieuw. De melding verdwijnt vanzelf in de volgende cyclus.

Krijg je geen reparatiemelding maar kloppen de getallen nog steeds niet, dan heeft SEM waarschijnlijk op deze laadpaal nog maar één setpoint opgedragen, waarbij de vraag op basis van watts alleen echt niet te beantwoorden is. ev_watts_per_amp in de diagnose- download toont wat het heeft: implied_phases per setpoint is het getal om te lezen.

De diagnose (Instellingen → Apparaten & diensten → SEM → ⋮ → Diagnose downloaden) bevat het volledige plaatje onder ev_watts_per_amp en charger_adapters.<id>.phases: de gemeten tabel W/A per (laadpaal, aantal fasen), de vakken die nog vertrouwen aan het opbouwen zijn, en de weigeringen met hun redenen. Een weigering met de naam phase_belief is deze fout.

De exportbewaking schakelt nooit in, of toont “refused”

Symptoom: de terugleverprijs is negatief, sensor.sem_export_guard_state blijft idle of holding, of toont refused, en de modus van de omvormer verandert nooit.

Lees eerst de toestand. sensor.sem_charging_state bevat export_guard (toestand, reden, would) en sink_verdicts.grid_export. De reden is in bijna alle gevallen het antwoord:

Drie weigeringen op rij geven een reparatiemelding; de toestand verdwijnt aan de open kant zodra de vrijgavevertraging is verstreken.

In observatiemodus wordt niets geschreven, maar de exacte aanroep is zichtbaar: switch.sem_observer_mode → withheld_commands.export_guard noemt de service en de payload die de bewaking zou sturen (standing: false) of blijft elke cyclus de vastgehouden begrenzing noemen (standing: true). Toont die regel een weigering, dan zou de live opstelling ook weigeren.

Het register controleren. De modussensor op de schrijvende host vernieuwt direct na een geslaagde schrijfactie en maakt zichzelf daarna ~60 s blind; een tweede HA- host die dezelfde omvormer uitleest, loopt tot ~15 minuten achter. Dwing beide af met homeassistant.update_entity — die uitlezing is de waarheid.

Een OCPP-laadpaal accepteert een start en stopt een seconde later (2.1, #976)

Symptoom: nadat SEM een lading heeft gestopt, weigert de laadpaal elke nieuwe sessie — de app, de laadpas en de OCPP-schakelaar krijgen allemaal RemoteStartTransaction: Accepted gevolgd door StopTransaction een seconde later. Op een Huawei SCharger knippert de led 4 s blauw / 1 s uit.

Oorzaak: de algemene stop van SEM is “schrijf 0 A naar het stroomgetal”. Bij de OCPP-integratie is dat getal een laadprofiel en houdt het laadpunt het vast, zodat de limiet van 0 A de sessie overleeft. Sinds 2.1 schrijft SEM nooit 0 A naar een OCPP-stroomgetal en stopt het in plaats daarvan via de schakelaar voor laadsturing (automatisch overgenomen van hetzelfde laadpunt als je alleen het getal had ingesteld; of zet Start-/stopentiteit zelf op switch.<laadpunt>_charge_control).

Herstel, in deze volgorde: haal SEM ervan af (laadmodus Uit, of observatie- modus) → zet het OCPP-getal voor de maximale stroom terug op je maximum → komt hij daarmee alleen niet vrij, roep dan de service ocpp.clear_profile aan → daarna ocpp.reset (een zachte reset) — een fabrieksreset is het laatste redmiddel, niet het eerste.

De omvormer weigert geforceerd ontladen

SEM vroeg je omvormer/batterij drie keer om geforceerd te ontladen (export van batterij naar net) en elke keer werd de schrijfactie geweigerd — deze hardware of de integratie ervan ondersteunt het niet. SEM stopt met vragen en probeert het stilletjes elke tien minuten opnieuw, zodat een firmware-update vanzelf herstelt. Oplossing: was je nooit van plan de batterij terug te leveren, wis dan de entiteit voor geforceerd ontladen in de batterij- instellingen van SEM en de melding verdwijnt; wil je het wel, controleer dan of de firmware-/integratieversie van je omvormer een werkende ontlaadsturing biedt. Lees eerst de eigen woorden van het apparaat in de fouttekst van de melding: een setpoint buiten het bereik van het register, of een register dat de omvormer in zijn huidige modus vergrendelt, weigert net zo consequent als een ontbrekend register. Zolang de schrijfactie is ingetrokken, wordt de routinematige veiligheidsschrijfactie die SEM doet bij het terugzetten van de batterij naar normaal bedrijf overgeslagen — onschuldig, er was niets te wissen — en laden, ontlaadlimieten en het dagelijkse bedrijf blijven onaangetast. Een herstart laat SEM het opnieuw proberen, zodat een firmware-update of een gecorrigeerde entiteit vanzelf wordt opgepikt.

Het vermogenssetpoint van de batterij valt steeds weg

Hetzelfde symptoom als in de sectie hierboven — export van batterij naar net ingetrokken na drie weigeringen — maar een andere oorzaak, en SEM geeft deze variant als zijn eigen bewijs naar de entiteit wijst in plaats van naar de hardware.

Twee verschillende controles weigeren deze schrijfactie. De leesbaarheidscontrole van SEM draait eerst en weigert als de entiteit geen eenheid W/kW heeft of geen numerieke toestand; het apparaat weigert later, met de eigen fouttekst van zijn integratie. Hebben beide in dezelfde periode geweigerd, dan was de entiteit in sommige cycli leesbaar en in andere niet — en dat is een beschikbaarheidsprobleem, geen ontbrekend register.

Oplossing: controleer of de batterij online blijft (een batterij die slaapt, of een integratie die haar verbinding verliest, publiceert unavailable tussen metingen), en controleer of de entiteit die je hebt gekozen onder Entiteit voor geforceerd ontlaadvermogen altijd een eenheid W of kW en een numerieke toestand heeft. Sommige integraties bieden het setpoint alleen aan terwijl de batterij wakker is — kies een entiteit die altijd wordt gepubliceerd als die bestaat. SEM probeert het stilletjes elke tien minuten opnieuw en wist de reparatiemelding zodra een schrijfactie aankomt, dus er is geen herstart nodig zodra de entiteit stabiel is.

Een last staat op stroomsturing maar zijn entiteit is in watt

SEM stuurt een van je overschotapparaten niet aan, en het toegewezen overschot ervan blijft op 0 W.

Stroomsturing betekent ampère. Het bestaat voor laadpalen, die een stroom tussen ongeveer 6 en 32 A krijgen. Wijs je het naar een entiteit die een waarde in watt neemt — een my-PV AC-THOR, een dompelverwarmer, een verwarmingsstaaf, een vermogenslimiet van een omvormer — dan zou niets wat SEM kan schrijven betekenen wat jij bedoelt, dus weigert het het apparaat aan te sturen in plaats van een getal in de verkeerde eenheid te schrijven.

Vroeger registreerde het het apparaat toch en schreef het er gewoon nooit naar, wat zich uitte als een boiler die tussen je laadpalen werd geteld en een overschottoewijzing die op nul bleef staan zonder dat iets uitlegde waarom.

Wat je nu doet: wordt het apparaat echt via stroom gestuurd, wijs de instelling dan naar zijn ampère-entiteit. Is het een variabele vermogenslast — wat de meeste overschotlasten van deze soort zijn — dan kan SEM het nog niet moduleren: het heeft geen apparaatklasse die “neem precies 800 W” betekent. Dat is #880, en daar wordt aan gebouwd. Intussen kun je het apparaat nog wel gebruiken als aan/uit– overschotlast door in plaats daarvan een schakelentiteit in te stellen, wat je grof eigen verbruik geeft in plaats van geen.

De netpiek wordt veroorzaakt door een last die SEM niet aanstuurt

SEM gaf de reparatiemelding “De netpiek wordt veroorzaakt door een last die SEM niet aanstuurt”. Dat betekent: de meter zit boven je doel, en zelfs als SEM alles wat het mag uitschakelen zou uitschakelen, zou de meter nog steeds boven het doel zitten. De niet-aangestuurde kilowatts die in de melding worden genoemd, zijn de afname van iets wat SEM niet beheert — een auto aan een laadpaal die SEM niet heeft gekregen, een oven, een sauna, een warmtepomp met een eigen regeling.

Het huis afschakelen kan die piek niet oplossen, dus schakelt SEM niets af zolang dit geldt (een eerdere versie bleef de ene groep na de andere afschakelen totdat het huis donker was). Je opties:

• Geef SEM de last. Is het een laadpaal, voeg hem dan toe onder Configureren → Laad- palen; SEM regelt hem dan binnen dezelfde piekruimte als al het andere. Is het een schakelbare last, voeg hem dan toe als apparaat met een stuurentiteit en een andere modus dan Uit.
• Verhoog het doel als het plafond niet echt dat van je contract is. Het doel is het maximum van je aansluiting — zie Instellingen voor lastbeheer.
• Accepteer de piek voor lasten die moeten draaien — de melding verdwijnt vanzelf zodra de piek weer haalbaar is.

Alles wat SEM kan afschakelen, staat op de kaart Lastprioriteiten; een last die als kritiek is gemarkeerd of op Uit staat, telt bewust nooit mee.

SEM kan de historie van je batterijnachten niet opnieuw opbouwen

Je drukte op Opnieuw opbouwen uit historie en SEM antwoordde dat het geen energiesensor voor de ontlading van de batterij heeft.

SEM bepaalt hoeveel van je batterij veilig kan worden uitgegeven door te kijken hoeveel je huis er ’s nachts uit haalt, en het wil vijf goede nachten voordat het een getal aanbiedt. Opnieuw opbouwen slaat dat wachten over door de eigen vastgelegde historie van de teller te lezen — daarvoor is dus een oplopende energieteller nodig, in kWh, die alleen maar stijgt. Een vermogenssensor in watt is iets anders en kan niet worden gebruikt: die zegt wat de batterij nu doet, niet wat ze heeft gedaan.

De knop staat op het tabblad Batterij, onder de voortgang van de verzamelde nachten:

Oplossing: voeg de energiesensor voor de ontlading van je batterij toe aan het Energie-dashboard van Home Assistant (Instellingen → Dashboards → Energie → Thuisbatterij-opslag), en druk daarna opnieuw op de knop. Wachten kost niets — SEM leest de historie van de teller, dus als je er over een maand op drukt, wordt die maand ook teruggehaald. Live vastleggen gaat intussen door met één nacht per dag, dus het wachten is een vertraging, nooit een doodlopende weg.

SEM stelde een service voor mijn laadpaal voor, maar er is geen knop (2.1, #956)

De voorstelregel zegt waarom. “Met de hand koppelen: velden die SEM niet kan invullen” betekent dat de service iets nodig heeft wat SEM niet kan weten — set_max_current van go-eCharger wil een laadpaalnaam. “Richt zich op een entiteit” betekent dat de service op een entiteit moet worden aangeroepen, wat de laadpaalfabriek van SEM niet doorgeeft. In beide gevallen stel je ev_charger_service en de parameternaam zelf in de configuratie van de laadpaal in. “Kon nog niet worden opgevraagd” betekent dat Home Assistant nog aan het opstarten was; de regel wordt bij het volgende rapport ingevuld.

Mijn auto verschijnt als onbekende hardware (2.1, #887)

Een voertuig via een transport als MQTT (bijvoorbeeld een OnStar-brug) werd vroeger gemeld als hardware die SEM niet kon plaatsen. Sinds 2.1 staat het onder voertuigen in het detectierapport en de diagnosedownload, met zijn laadniveau, actieradius en stekkerbronnen. Kies die in de voertuig- instellingen van de laadpaal; SEM koppelt ze niet zelf.

Opnieuw opgebouwde nachten kunnen niet zien wat het net bijdroeg

Het opnieuw opbouwen werkte, maar bij sommige teruggehaalde nachten kon alleen worden gemeten wat de batterij gaf, niet wat het net toevoegde.

Dat doet ertoe in de nachten die er het meest toe doen. Raakt de batterij vóór de ochtend leeg en maakt het net het af, dan is het eigen getal van de batterij maar een deel van wat je huis nam — dus zien die nachten er kleiner uit dan ze waren. Het zijn precies de grote nachten waartegen de schatting moet beschermen, en ze te klein tellen trekt het getal voor de besteedbare batterij lager dan het zou moeten zijn.

SEM sluit in plaats van te gokken de boeken van de nacht: ’s nachts is er geen zon, dus wat het huis nam, is wat het net en de batterij gaven, min wat de auto en de batterij opnamen. Daarvoor is voor elk daarvan een oplopende energieteller nodig, en daarom laat één ontbrekende sensor de nacht onverantwoord.

Oplossing: voeg de genoemde sensoren toe aan het Energie-dashboard — netafname, batterij laden, en de energie van je laadpaal als je een auto laadt — en druk opnieuw op Opnieuw opbouwen uit historie. De melding verdwijnt zodra elke nacht kan worden verantwoord. Nachten die SEM live heeft gemeten, worden niet beïnvloed: die bevatten het aandeel van het net al, en SEM geeft er altijd de voorkeur aan boven een gereconstrueerde nacht.

De batterij staat in een modus die SEM niet verwacht

De planning van SEM — het model voor de nachtelijke behoefte, het besteedbare budget, het geplande laden — gaat ervan uit dat de keuzelijst voor het bedrijfsbeleid van je omvormer in de modus voor eigen verbruik staat (Huawei noemt dat Maximise self-consumption). Deze reparatiemelding verschijnt als SEM een andere modus leest uit de keuzelijst die je hebt ingesteld onder Instellingen → Entiteit voor de batterijbedrijfsmodus.

Is de modus bewust gekozen (je draait bijvoorbeeld bewust Fully fed to grid): klik de melding weg. SEM houdt deze keuzelijst alleen in de gaten — het verandert hem nooit, en het vecht niet tegen je keuze. Houd er rekening mee dat de omvormer in deze modi zijn eigen schema volgt, dus de batterijplannen van SEM gaan misschien niet op.

Is het niet bewust: zet de omvormer terug in zijn modus voor eigen verbruik met de eigen app van de omvormer of de select-entiteit in Home Assistant, en de melding verdwijnt vanzelf.

De uitlezing wordt gedempt: korte uitval van de sensor (een onbeschikbare modbus- verbinding) laat de melding nooit verschijnen of verdwijnen.

De instelling van de Deye-werkmodus kan niet worden gebruikt

SEM werd gevraagd het exportbeleid van je Deye aan te sturen, maar de select-entiteit die je hebt opgegeven, biedt niet de drie labels die SEM verwacht (Selling First / Zero Export To Load / Zero Export To CT), of is onbeschikbaar. De melding bevat de exacte reden. Oplossing: controleer onder Configuratie → Batterij-intelligentie de select-entiteit en de drie optielabels tegen wat je Deye-integratie werkelijk toont; de labels moeten exact overeenkomen. SEM wist de melding zodra de instelling klopt.

De SOC-zones van je batterij staan in de verkeerde volgorde

De batterijzones van SEM zijn drie drempels die in volgorde moeten oplopen:

Tot 2.1 dwongen de schuifregelaars die volgorde per ongeluk af: Buffer kon niet onder 50% en Autostart niet onder 70%. Daardoor waren ook volkomen redelijke indelingen onmogelijk — bij een grote batterij is Prioriteit 20 / Buffer 30 / Autostart 50 een bewuste strategie, geen fout, en #870 vroeg precies daarom. Alle drie lopen nu van 5–100%.

De prijs van die vrijheid is dat ze in de verkeerde volgorde kunnen worden ingevuld, dus geeft SEM deze reparatiemelding als dat zo is. Die noemt wat je hebt ingesteld en wat SEM in plaats daarvan gebruikt.

SEM gedraagt zich intussen niet verkeerd. De zonegrenzen zijn dezelfde drie getallen, gesorteerd, dus er wordt nooit een zone overgeslagen — dat doet ertoe, omdat een ongesorteerde reeks de zones niet alleen anders ordent, maar er een wist. Met Autostart op 50% en Buffer op 80% zou een batterij op 60% “boven autostart” antwoorden en de bovenste zone melden, zonder ooit de buffertest te bereiken die je op 80% had ingesteld.

Oplossing: Instellingen → Apparaten & diensten → SEM → Configureren → Batterij, of het tabblad Configuratie op het SEM-dashboard. Alle waarden zijn prima zolang Prioriteit ≤ Buffer ≤ Autostart.

Bestanden van een eerdere SEM-installatie

Reparatiemelding: Er zijn bestanden van een eerdere SEM-installatie gevonden

SEM vond opslagbestanden van een configuratie-invoer die niet meer bestaat — bijna altijd omdat SEM is verwijderd en opnieuw toegevoegd op een versie die niet zelf kon opruimen. Die bestanden waren van SEM zelf, en SEM heeft ze verwijderd. De reparatiemelding gaat over het deel dat het niet heeft verwijderd.

Wat automatisch is opgeruimd

Opslag per invoer: energie- en dagtotalen, de versiemarkering, het record van het laadtempo, momentopnamen per batterij. Een bestand dat SEM niet herkent, wordt in het logboek genoemd en blijft precies staan waar het staat — een opruiming die bestanden verwijdert die ze niet kan identificeren, is een groter probleem dan het probleem dat ze oplost.

Wat er nog staat, omdat het van jou is

• Langetermijnstatistieken van de sensoren van de oude installatie. Dit is wat Spook na een de-installatie als achtergebleven items meldt. Het is je vastgelegde historie, en SEM verwijdert niet op eigen initiatief een jaar aan zonneopbrengst.
• Het gegenereerde dashboard, dat je misschien hebt aangepast.

Wat te doen

Niets, als je je historie wilt houden — de melding kan worden weggeklikt en er wordt verder niets verwijderd.

Om ze te wissen, voer je Ontwikkelhulpmiddelen → Acties → SEM: Restanten verwijderen uit. statistics staat standaard aan, dashboard uit. Beide zijn onomkeerbaar.

Ga je SEM de-installeren, voer die actie dan eerst uit — daarna is er geen SEM meer om hem uit te voeren.

Batterij-naar-net schakelt nooit in bij een AC-gekoppelde batterij (Sessy) en heet daarna “niet ondersteund” (2.1, #978)

Symptoom: met een keuzelijst Power strategy ingesteld wordt het setpoint voor geforceerd ontladen van SEM geweigerd (Setting value for Power Setpoint failed: Not supported by device) en na drie weigeringen meldt SEM batterij-naar-net als niet ondersteund — terwijl de keuzelijst nog nom aangeeft. Zet je de keuzelijst met de hand op api, dan komt hetzelfde setpoint direct aan. Het logboek van HA bevat Referenced entities select.sessy_N_power_strategy ... are missing or not currently available van de service-aanroep die SEM deed.

Oorzaak: het setpoint wordt genegeerd tenzij de strategie op api staat, dus zet SEM eerst de keuzelijst om. Vóór 2.1.0-beta.30 werd een omzetting die HA niet kon uitvoeren als gedaan onthouden en nooit opnieuw geprobeerd; het setpoint ging dan naar een batterij die nog op nom stond.

Wat SEM nu doet: het gelooft de keuzelijst. Een omzetting telt pas als de keuzelijst haar aangeeft; een die na 60 s niet is aangekomen, wordt opnieuw verstuurd en één keer gelogd — asked <select> for power strategy 'api' … and it still reads nom — en na drie missers noemt de reparatiemelding “Een schrijfactie naar de batterijbesturing wordt niet overgenomen” de keuzelijst met de gewenste en de gelezen waarde. Het setpoint wordt niet geschreven, en het apparaat krijgt niet de schuld, totdat de strategie goed staat.

Wat te controleren als je die regel ziet: de entiteit-ID in Keuzelijst vermogensstrategie (configuratiekaart → batterij) moet de LIVE keuzelijst zijn — open Ontwikkelhulpmiddelen → Toestanden, zoek de keuzelijst die de Sessy-integratie werkelijk levert, en kies die. “Missing or not currently available” van HA betekent dat de ID waarop SEM zich richt op dit moment niet door de select-integratie wordt bediend: een hernoemde entiteit, een herstelde maar dode registerinvoer, of een helper die geen select/input_select is.

State attributes for sensor.sem_… exceed maximum size of 16384 bytes (2.1, #979)

Symptoom: het logboek van HA herhaalt die regel elke cyclus voor een SEM-entiteit, en de historie van de entiteit is leeg — de recorder weigert de HELE attributenset zodra het vastgelegde deel boven 16 KB komt.

Wat SEM nu doet: de grote hulpattributen voor de live kaarten (het detectierapport op sem_diag_charger_control, would_decisions / withheld_commands van de observatieschakelaar, de apparatenkaarten) worden als niet-vastgelegd aangemerkt, en de attributen van elke SEM- entiteit gaan door één poort die het vastgelegde deel onder de grens houdt. Moet die ooit iets laten vallen, dan bevat de entiteit attributes_trimmed: [<namen>] — de volledige payload zit altijd in de diagnosedownload.

Zie je de regel nog steeds bij een SEM-entiteit, meld dan de entiteit-ID: het betekent dat een nieuw attribuut boven de grens is gegroeid en dat de poort het niet kon meten.

De laadpaal geeft een fout na een bewolkte dag vol starts en stops (2.1, #975)

Symptoom: op een dag met gebroken bewolking wordt de laadpaal steeds opnieuw gestart en gestopt en weigert hij uiteindelijk helemaal te laden totdat hij wordt uit- en aangezet of gereset. Gemeld bij een Zaptec Go 2, die sessieonderbrekingen zelf telt en boven zijn eigen limiet vergrendelt; andere laadpunten hebben vergelijkbare tellers.

Wat SEM nu doet: het telt de stops die het in de huidige aansluitsessie heeft opgedragen. De eerste vier zijn gratis; daarna verbreedt elke volgende stop zowel de startvertraging als de overbrugging van kortstondige dips — tot vier keer hun ingestelde waarden — zodat een flikkerend overschot steeds vaker de minimale stroom door de wolk heen vasthoudt in plaats van de sessie af te breken. Loskoppelen en opnieuw aansluiten start een nieuw budget.

Wat het bewust niet doet: de structurele stop oprekken. Is de zon echt weg (schemering, zware bewolking), dan stopt SEM nog steeds direct — daar een schakelaar gesloten houden zou de auto van de batterij en het net laten trekken (#461).

Blijft het toch schakelen: verhoog Uitschakelvertraging (Configuratie → Laden) zodat ook de eerste stops trager worden, en vertel ons welke laadpaal het is — het budget is merkblind, maar een laadpunt met een strakkere limiet dan de Go 2 is goed om van te weten.

De batterij dekt het huis nooit, en het net doet het in plaats daarvan (2.1, #994)

Symptoom: ’s nachts neemt het huis af van het net terwijl de batterij bijna vol is. sensor.sem_tariff_price_level geeft cheap, en het getal voor het maximale ontlaadvermogen van de omvormer is op 0 W gezet.

Oorzaak (vóór 2.1.0-beta.35): de functie het huis als afvoer voor de batterij houdt de batterij vast in goedkope uren om haar in dure uren uit te geven. Bij een vlak tarief — beide tarieven ingesteld op hetzelfde getal, of een agenda zonder regel voor hoogtarief — publiceerde SEM nog steeds cheap, afgeleid van de klok in plaats van van een vergelijking, zodat het vasthouden nooit werd opgeheven. Gemeten op de referentie-installatie: 3,66 kWh afgenomen in één nacht met een batterij op 92–100 %.

Wat SEM nu doet: een niveau bestaat alleen als er een vergelijking achter staat. Bij een vlak tarief geeft de sensor flat (“Geen prijsverschil”), blijft de afvoer naar het huis open, en wordt de ontlaadlimiet nooit op 0 gezet. Hetzelfde geldt voor een weekend onder HT/NT en voor een agenda waarvan het schema vandaag geen venster voor hoogtarief heeft — beide zijn één prijs van middernacht tot middernacht, wat de tarieftabel ook zegt.

Zie je het op 2.1.0-beta.35 of later: controleer sensor.sem_tariff_price_level. Toont die een echt niveau, dan varieert je tarief wel en kan het vasthouden correct zijn — zet Het huis als afvoer voor de batterij uit als je liever ongeacht de prijs zelf verbruikt. Toont die flat of no_prices en wordt de batterij toch vastgehouden, dan is dat een fout: stuur de diagnose- download op. no_prices bij een dynamisch tarief betekent ook dat je prijsentiteit niet wordt gelezen — zie eerst de tariefsectie hierboven.