Zelf een EMS bouwen, soort van dan ;-))

[Floor-is]

Preface: ik had deze post geschreven voor ergens anders. @Orion84 zei echter "Want dit is eigenlijk gewoon super interessant om op het publieke deel te bespreken, krijg je mogelijk ook meer input dan hier". Dus nu ben ik hier

Voel je vrij om vragen te stellen, me complimenten te geven, of me te vertellen dat ik dingen niet goed heb gedaan (wel vriendelijk blijven graag), hints&tips te geven over mogelijke verbeteringen, meer diepgang te vragen over delen.

Happy reading


Ik ben half april met home assistant begonnen en er gewoon echt vol voor gegaan, zoals ik dat doe

Hoe we er zijn gekomen is een enorm verhaal op zichzelf.. Laten we kijken naar de situatie in 2025:

• Volledige saldering
• Opwek uit zonnepanelen: ±16,5MWh
• Verbruik totaal: ±19MWh (EV, WP, zelf)
• Ouderwetse schijfmeter, dus het net is de batterij (ook op jaarbasis)

2026 (verwacht etc)

• Volledige saldering
• Opwerk uit zonnepanelen: 15-16MWh
• Verbruik totaal: ±19MWh
• Verschillende rookmelders gaan stuk/moeten vervangen
• Vanaf januari: Laadpaal 'betaald'
• Juni: Slimme meter (iets met een wet en boetes)
• Juni: nieuwe omvormer garage (12kW) + plaatsing thuisbatterij (48kWh)

2027 (educated guess voor opwek/verbruik)

• Geen saldering
• Opwek uit zonnepanelen: 15-16MWh
• Verbruik totaal: ±20MWh (nieuwe EV, minder zuinig)
• Laadpaal betaald
• Slimme meter
• Thuisbatterij (48kWh, maar kan groeien naar 64kWh als moet)

Hoewel het een beetje wegvalt in al het energie-spul: de rookmelders moeten vervangen, er zijn er een paar stuk en de rest is echt te oud (20-25 jaar). Bovendien hebben we een probleem met de luchtvochtigheid (te laag) in delen van het huis. De klik aan/uit rotzooi werkt dan wel, dan weer niet en dat begint ook echt bloedirritant te worden. Tijd om het roer drastisch om te gooien

Nieuwe rookmelders
Dit speelt ergens in maart van dit jaar: We hebben in het huis, inclusief de gangen, 12 ruimten. Het toilet, de badkamer en nog wat ruimten hoeven geen rookmelder. Het plan: met drie melders boven en drie beneden moet het lukken.
We hebben nog geen rookmelder in de garage, ook het bijhuis heeft geen eigen rookmelder. Daar moet verandering in komen. Het plan: beide krijgen een rookmelder.
Dan heb je een rookmelder in de garage en het bijhuis. Leuk, maar die hoor je niet Nu hebben we WiFi in beide, dus misschien zijn die rookmelders van Nest nu dan toch een ding, daar heb ik een paar jaar geleden naar gekeken, maar toen vond ik ze echt veel te duur. Aww shoot, die worden niet meer verkocht!
De beste oplossing lijken rookmelders in combinatie met home assistant, maar ik wil nog niet echt aan home assistant.

Hygrometers
Begin april (dit jaar) merk ik dat het de luchtvochtigheid in mijn kantoor en een paar andere ruimten in het huis is die zorgt voor de last van mijn ogen en huid. Met een luchtvochtigheid die zakt tot onder de 35% is dat niet gek, dat de planten het zo moeilijk lijken te hebben ook niet trouwens. De op Ali gekochte supergoedkope temperatuurmeter die toevallig ook luchtvochtigheid doet gaf me dit inzicht.. Mooie bijvangst
De combinatie van temperatuur+luchtvochtigheidsmeter is voor home assistant easy te krijgen, best goedkoop.. En dan kan je een of meer luchtbevochtigers dynamisch aansturen.. Weer een businesscase voor de home assistant.

Spookverbruik tegengaan
We hadden sterk het vermoeden dat we veel meer energie verbruiken dan nodig omdat we een aantal zaken gewoon altijd aan hebben staan. Op mijn bureau bijvoorbeeld het beeldscherm en de studio-monitors; de TV in mijn werkkamer en diens audio-setup hoeven ook niet altijd aan; in de TV-kamer zelfde verhaal.. Maar in hoeverre gaat het helpen als we die uitzetten ipv gewoon door laten gaan?
En als we dan toch bezig zijn: hoe zit het met het verbruik van de netwerkapparatuur, de NAS, de quooker, de koelkast, de vriezer, de setup in de sim-room?

Thuisbatterij en hoe aan te sturen
Dit proces speelt al jaren, maar dit jaar ben ik er echt ingedoken. Want weg saldering en weg schijfmeter, terugleverkosten zelfs en een energierekening die kan verviervoudigen. Tel daar de EV bij op die 8.5MWh/jr opsnoept, maar wel op de duurste tijden van de dag.. Hier moeten we iets aan doen en het is geen optie om de EV de deur uit te doen, al helemaal niet omdat elke kWh die de EV in gaat geld oplevert voor het huishouden. Een thuisbatterij lijkt de best passende oplossing.
Maar die moet iets slimmer zijn dan de gemiddelde, want we hebben meer variabelen; zonnepanelen en een warmtepomp is niet heel gek, batterijen ook niet, forecasting is redelijk gemeengoed zelfs.. Maar een EV met een eigen tarief, dat is blijkbaar enorm niche. Fahk, weer meer uitzoekwerk! Enige tijd later: EMHASS, dat moet 'm zijn, dat is ook al een home assistant-ding.

Home assistant
Okay, genoeg zaken om home assistant te verantwoorden. Ik bestel dus: rookmelders, temperatuur (en hygro) sensoren en smartplugs, en een Zigbee USB-stick unit. Laten we de uitleg vanaf hier flink versnellen:
- USB-stick haalt de garage niet, laat staan het bijhuis
- USB-stick overlijdt al na een paar dagen
- SMLGHT SLZB-06U (PoE) units ipv USB-Stick(s)
- VM op mijn Mac Mini werkt niet goed (crasht, verliest data, usb-passthrough is poep)
- Zigbee2MQTT met twee coordinators werkt niet: Z2M+Z2M_edge nodig
- Dashboards in HA bieden niet wat ik wil: ik bouw zelf wel wat (1e eigen dashboard)
- Energie-overzicht nodig: nog een dashboard
- Meer smartplugs, want ik mis dingen en gelijk dat dashboard nog eens onder handen nemen
- Dashboard voor mijn netwerk toevoegen, want elke keer opnieuw moeten inloggen om overzicht te hebben is shit
- De batterijen komen, de installateur plaatst ze half. Hangt ze wel op, maar instellen is blijkbaar te moeilijk en hij had de DC-bekabeling niet geregeld. Ik stel zelf de omvormer in met één gekoppelde batterij (van de drie).
- kWh-meter voor warmtepomp wordt geplaatst
- Kabels komen binnen: installateur geeft aan 3 weken nodig te hebben. Ik koppel zelf de batterijen (alledrie, moet opnieuw), stel de omvormer opnieuw in.
- Slimme meter wordt geplaatst, dus ik heb eindelijk P1-waarden.
- De omvormer kan toch niet met de input van de P1-waarden om, had ik beter moeten uitzoeken...

En dan gaan we nu écht pas de diepte in

Het probleem

Mijn Deye-omvormer is dus netblind: er zit geen stroomtang (CT) op en de slimme meter hangt ~35 m verderop in de hoofdkast. De omvormer wéét dus niet wat het hele huis aan het net doet. De enige plek waar ik de werkelijke netstand zie is de P1-poort van de slimme meter (`sensor.p1_meter_power`, + = import, − = export).

Gevolg: ik kan niet vertrouwen op de zelfconsumptie-modus van de omvormer. Ik sluit de regelkring zelf, in Home Assistant, op basis van P1.

Het idee in één zin

Home Assistant leest elke minuut de netstand, rekent uit hoeveel de batterij moet ontladen om het huis te dekken (net ≈ 0), en schrijft dat als vermogens-setpoint naar de omvormer. Een feedback-loop dus, net als een thermostaat - alleen stuurt 'ie op "netto 0 aan de meter" in plaats van temperatuur.

Twee actuator-assen

Ik stuur twee dingen aan, los van elkaar:

- As A - de batterij (Deye). Modi: `IDLE` (omvormer doet z'n eigen ding) / `NET_ZERO` (batterij dekt het huis) / `EMHASS` (volg een economisch plan, toekomst).
- As B - de Tesla-laadstroom. Modi: `IDLE` / `ZON_VOLG` (laadstroom volgt het PV-overschot) / `EMHASS_EV` (toekomst, als het dynamische energiecontract in gaat vanaf 28/6).

Belangrijk: de uitsluiting zit per actuator, niet globaal. As A en As B draaien prima tegelijk - ze bedienen verschillende knoppen.

De gelaagde opzet per as

Geen grote if/else-knoop, maar drie lagen met een duidelijke taakverdeling:

• Live data (P1, SOC, PV, prijs, auto-status)
• Beslisser: template-sensor die de gewenste modus afleidt. Schakelt zelf niets (read-only, los testbaar). sensor.deye_mode / sensor.tesla_mode
• Override: handmatige knop (Auto / Force_*). Mens wint. input_select.deye_override / tesla_override
• Applier: automation die de effectieve modus toepast door de loop-aan/uit-schakelaars te zetten. Enige schrijver van die booleans. Heeft een dry-run-gate.
• Loop: de echte regelaar (elke minuut). Schrijft het vermogens-setpoint naar de omvormer.

De beslisser kijkt naar de wereld en zegt "hij zou NET_ZERO moeten zijn". De applier zet dan de juiste schakelaar om. De loop doet het werk. Door dit te splitsen kan ik elke laag los testen (de beslisser draait read-only mee zonder iets te schakelen).

De loop zelf (het hart)

De net≈0-loop draait elke minuut en doet eigenlijk maar één sommetje: gewenst_ontlaadvermogen = huidige_accu-output + (P1_net + kleine_export_bias)

`huidige_accu-output` (gemeten) + `P1_net` (wat er nog over is) samen = het totale huisverbruik. De loop mikt dus elke tick precies op de huislast, met een klein beetje export-marge zodat hij nooit per ongeluk importeert. Dat resultaat schrijft hij naar het actieve Time-of-Use-venster van de Deye (`number.deye_garage_program_<n>_power`): de omvormer pakt dat binnen ~75 s op.

Twee details die verrassend veel uitmaakten:

1. Reken vanaf de gemeten accu-output, niet vanaf je vorige commando. Het commando loopt vóór op de werkelijkheid (de omvormer rampt, de meter heeft vertraging). Reken je vanaf je vorige setpoint, dan tel je de last dubbel → de batterij schiet door → P1 klapt naar export → oscillatie. Vanaf de échte output is het zelf-corrigerend.
2. Asymmetrisch begrenzen. Méér ontladen doe ik gedoseerd (max X watt per minuut, zodat de batterij niet in één klap surge't). Mínder ontladen mag vrij - stoppen met ontladen is altijd veilig, dus dat doe ik direct (anders dump je bij een last-wegval even vermogen het net op).

De triggers (wanneer draait wat?)

• Loops: `time_pattern` elke minuut (+ meteen bij inschakelen).
• Beslissers: template-sensoren, die herrekenen automatisch zodra een invoerwaarde verandert (continu dus).
• Appliers: bij een modus-wissel (met een dwell van een paar minuten tegen geklepper), bij een override-wissel, elke 5 min een her-bevestiging, en zodra de dry-run-gate uit gaat.

De data die gebruikt wordt

• `sensor.p1_meter_power` - de netstand (de kern; alles hangt hieraan).
• `sensor.deye_garage_battery_power` - wat de batterij nú écht levert/opneemt.
• `sensor.deye_garage_battery` - de SOC (laadtoestand).
• `sensor.solar_current_power` - PV-opbrengst.
• Auto: laadkabel-aangesloten, thuis-aanwezig, SOC, charge-limit (voor As B ).
• EPEX-prijzen (`sensor.stroom_inkoopprijs` e.d.) - voor de economische planlaag (EMHASS).

De knoppen om bij te sturen

Schakelaars:

• `input_boolean.orchestrator_dry_run` - de hoofdgate. Aan = de appliers loggen alleen wat ze zouden doen, ze schakelen niets. Mijn veiligheidsknop tijdens testen.
• `input_boolean.deye_zero_grid_enable` - de net≈0-loop aan/uit.
• `input_select.deye_override` / `tesla_override` - forceer een modus met de hand (`Auto` / `Force_IDLE` / `Force_NET_ZERO` / …).

Tuning (allemaal `input_number`, live verstelbaar zonder herstart):

• ramp-snelheid (watt per minuut omhoog), deadband, export-bias, ontlaad-vloer-SOC, de export-drempel waarop de batterij "echte PV-export" herkent en loslaat, en de in/uit-drempels voor zon-volgend laden.

De daadwerkelijke actuator-registers:

• `number.deye_garage_program_<n>_power` / `_soc` - het ToU-venster van de omvormer (= waar de loop het batterij-setpoint in schrijft).
• `number.mevrouw_karretje_charge_current` - de Tesla-laadstroom (As B ).

Wat ik ervan leerde

Het lastigste was niet het bouwen, maar het regeltechnisch stabiel krijgen: een omvormer met ~minuut-vertraging, een meter 35 m verderop, en een beslisser die naar dezelfde P1 kijkt die de loop juist nul máákt. Dat gaf precies de klassieke valkuilen - dubbeltellen, doorschieten, en een beslisser die z'n eigen staart opeet (de batterij ontlaadt → P1 wordt "export" → beslisser denkt dat de zon schijnt → zet de boel uit → import komt terug → weer aan…). De oplossing was steeds: reken vanaf wat er echt gebeurt, niet vanaf wat je commandeerde, en laat de beslisser naar de accu-onafhankelijke netstand kijken (`P1 + ontlading`) in plaats van naar P1 zelf.


Gebruikte hardware:
Energie-opwekking en -opslag

• Omvormer garage: Deye SUN-12K-SG05LP3-EU-SM2 (12 kW, 3-fase hybride)
• Omvormer bijhuis: Solis 6 kW (3-fase)
• Thuisbatterij: 3x Deye SE-F16-C (51,2V LiFePO4, 16 kWh per unit) = 48 kWh nominaal / ~41 kWh bruikbaar
• DC balance-of-system: Victron Lynx DC Distributor (M10) + Victron MEGA-zekeringen + 275A accuschakelaar
• Zonnepanelen: ~15 kWp totaal (16x Jinko JKM400N-6RL3-B (bijhuis, zuid) + 14x Jinko JKM400N-6RL3-B (garage, zuid) + 12x oudere panelen 250-275 Wp (garage, noord))

Laden / EV

• Laadpaal: BlueCurrent (lokale API)
• Auto: Tesla Model Y, RWD (50kWh)

Meten

• P1-meter: HomeWizard Wi-Fi P1 Meter (HWE-P1)
• kWh-meter warmtepomp: HomeWizard kWh Meter 3-fase (HWE-KWH3, 80A)

Klimaat

• Warmtepomp: Mitsubishi Ecodan Zubadan EHSD-VM2D

Sensoren (Zigbee/Matter)

• Temperatuur-/vochtsensoren: Aqara
• Rookmelders: Aqara
• Watersensors: Aqara

Home Assistant / Zigbee

• Home Assistant Green
• Zigbee coordinators: 2x SLZB-06U (1x ZHA hoofdhuis, 1x Zigbee2MQTT bijhuis)
• Smartplugs: Innr (SP 240) - verlichting/bureau/apparaten
• Remote: Aqara Cubes: 2x Aqara Cube T1 Pro (kantoor + tv-kamer)

Software:
Core

• Home Assistant (op HA Green)
• InfluxDB v2 (long-term sensordata, bucket homeassistant)
• EMHASS 0.17.7 (energie-optimalisatie / day-ahead) - als add-on

HA-integraties

• ha-solarman (davidrapan) - Deye omvormer
• SolarmanV5 (StephanJoubert) - Solis omvormer
• Teslemetry - Tesla
• BlueCurrent - laadpaal
• MELCloud - Mitsubishi warmtepomp
• HomeWizard - P1 + kWh-meter
• Forecast.Solar - PV-voorspelling
• [Network]
• ZHA + Zigbee2MQTT

Add-ons

• Zigbee2MQTT
• EMHASS

HACS-cards (dashboards)

• button-card
• card-mod
• ha-sankey-chart
• apexcharts-card
• power-flow-card-plus

Externe diensten / tools

• Solcast (PV-forecast, hobbyist tier)
• EPEX / day-ahead prijzen
• Ollama (lokaal LLM)
• Claude / Claude Code (config-beheer, automatisering, sparring)
• [Passwordmanager]
• Git (versiebeheer config)

[Floor-is]

Mocht iemand het boeiend vinden, screenshots van mijn AI-zelf gebrouwde dashboards (behalve netwerk, dat gaat jullie niks aan):

'Startpage':


Pop-up omvormers:


Pop-up laadpaal:


Pop-up batterij:


Stroom1:


Stroom1, verder scrollen naar de smartplugs:


Prism-dashboard huis:


Sankey's (2e tab bij Prism-dashboard):

[Floor-is]

Niet dat iemand hier op reageert, maar ach.

Ik ben gaan greenfielden, wat ik had gebouwd was inmiddels op iteratie 12 en ik merkte dat ik eigenlijk code-op-code en oplossing-op-oplossing aan het plakken was. Dus terwijl dat (vrij goed trouwens) draait, ben ik opnieuw begonnen.

Dit zijn de 20 regels die uitleggen wat ik aan het bouwen ben (samenvatting door Opus 4.8)

EMS — het energie-management-systeem (greenfield C1-C3, in ontwikkeling)

1. Doel: het huishoudelijke energie-huishouden — Deye-thuisaccu, Tesla-EV, huis, net, PV (WP later) — autonoom, veilig én uitlegbaar sturen: geld besparen en betrouwbaar draaien.
2. Kern-thesis: het EMS optimaliseert geen apparaten maar de allocatie van energie — apparaten (accu, EV, WP, paal) zijn slechts uitvoerende middelen. Elke kWh krijgt per tijdslot een marginale waarde per bestemming (eigen EV €0,50, huis, Deye-pack, WP, export, later V2G), en het systeem verdeelt op die waarde.
3. Architectuur: gelaagde control-stack — intentie stroomt omlaag, telemetrie omhoog, elke laag praat via een expliciet contract (getypte berichten), niet via gedeelde helpers.
4. Regie-laag (traag, dagen): LLM-regisseur die modes kiest maar nooit setpoints schrijft, + een demand-keten (meerdaagse rijbehoefte als waypoints).
5. Value Engine (nieuw): canonieke waarderingslaag die alle economie normaliseert tot ValueSnapshots — hij waardeert, hij beslist niet.
6. Plan-laag: MILP-optimizer (EMHASS als adapter óf mijn eigen PuLP waarmee ik op zich al best ver ben) — kosten-optimaal batterij+EV-schema over de forecast-horizon.
7. Validatie-laag: feasibility-gate (haalt het plan de deadlines, met live laadtempo?) + safety-fence (harde grenzen; geen rauwe setpoints).
8. Coördinatie-laag: cross-as-allocator die schaars overschot verdeelt op marginale waarde, met de accu als snelle buffer en de EV op de gladde trend.
9. Actuatie-laag: per actuator precies één schrijver (arbiter) + declaratieve reconciliatie (herbevestigt de gewenste eindtoestand elke tick, ook na restart).
10. Twee actuator-assen: As-A = Deye-accu, As-B = EV-laden met verwisselbare driver (Teslemetry → laadpaal in oktober; pack/vermogen als config).
11. Deterministisch waar het kan (loops, arbiter, gate, fence, allocator, MILP); de LLM doet alleen het vage/taal-werk, altijd achter gate + fence.
12. Kern-moves die de oude bugs als klasse killen: single-writer (3-4-schrijvers-race), reconciliatie i.p.v. edge-triggers (94%-cap/re-arm), first-class allocator (accu-vs-EV-competitie).
13. Operability als eis: dumb-mode-noodrem, dagelijkse plan-uitleg, policy-versioning, alles auditeerbaar — Floris mag geen SRE van z'n eigen meterkast worden.
14. Veiligheid bewijsbaar: er is geen pad van de LLM naar een actuator dat gate + fence omzeilt.
15. Status: het C1-C3-ontwerp is compleet (gemaakt ism Claude (Opus4.8/Fable5, ChatGPT 5.5).
16. Fase R (replay-harnas) meet eerst de "size of prize" op ~3 weken historische data — meten vóór bouwen.
17. Gemeten: ~€110 winst over 20 zomerdagen (post-2027); het ontwerp haalt 77%/57% van het theoretische optimum.
18. Verrassing: waardering (de "curve-wedge") telt zwaarder dan forecast-kwaliteit → de Value Engine krijgt prioriteit boven betere voorspellingen.
19. Verdict = BUILD-SMALL: begin met de veilige robuustheids-lagen (Fase 1 = arbiter + reconciliatie, €-onafhankelijk), stel de €-zware lagen uit tot bewijs.
20. Kantelpunten in aantocht: post-2027 (saldering stopt) en V2G in oktober (de EV wordt bron i.p.v. sink) — bewust nog niet vastgelegd tot de hardware bekend is.

[SalX]

Translated via google translate

Hé, het is niet alsof niemand dit leest. Ik denk er zelf ook over om zoiets te doen. Ik heb nu zonnepanelen, maar die zijn gehuurd (ik snap niet waarom de vorige eigenaar dat zo gedaan heeft, het kost maar 45 euro per maand, dat is het niet waard). Ik ben van plan ze te kopen, maar ze hebben een eenfasige omvormer. Ik heb al een aanvraag ingediend voor een driefasenaansluiting, dus ik weet niet zeker of een eenfasige omvormer haalbaar is. Daar moet ik nog even over nadenken.

Omdat ik van plan ben om al mijn huisverlichting te vervangen door slimme verlichting met Home Assistant, ben ik ook op zoek naar een energiemanagementsysteem (EMS). Vooral omdat ik ook van plan ben om accu's te installeren, bijvoorbeeld een 30 kWh-systeem met een 11 kW-omvormer (waarschijnlijk van Solis) in de garage (die niet aan de voorkant is afgesloten) of in een aparte berging om ventilatorgeluid te vermijden. Uit mijn onderzoek is gebleken dat aangepaste EMS-systemen geen onbalanshandel mogen uitvoeren via bijvoorbeeld Frank Energy of NextEnergy. Heb jij dat al uitgezocht, of ben je van plan om alleen day-ahead trading te doen? Volgens mij is het rendement op investering (ROI) via onbalanshandel veel beter.

---

Hey its not like no one is reading . I am thinking of doing something similar at my place as well. Just have solar panel for now although they are rented (not sure why previous owner did it that way its like 45 euros per month not worth it i think) so planning to buy it outright but it has a single phase inverter. Already applied for 3 phase connection so not sure if single phase inverter would be feasible. Any how still need to think about that.

Since I planning am changing all my house lighting to smart lighting with home assistant I also started looking into EMS solution especially since I also plan to install batteries like a 30kwh setup with 11kw inverter (solis probably) in the garage (its not closed from front ) or in the separate store room to avoid fan noises. One thing I have found in my research is that custom EMS are not allowed to do imbalance trading via like frank energy or nextenergy. Have you figured that one out or are you just planning to do day ahead trading ? As per my understanding ROI would be much better via imbalance trading.

[Floor-is]

I'll just respond in English

I've looked at a more common EMS, there are quite a few actually. If you're planning to use or are amendable to be using home assistant: EMHASS will probably provide you in your needs.

[ Voor 11% gewijzigd door Floor-is op 09-07-2026 23:17 ]

[SalX]

yes I have looked into EMHASS but it won't allow me to do imbalance trading (at least as per my understanding) as the APIs from FrankEnergy or nextenergy and others are locked and only with specific EMS hardware like from Vitron or Bliq or Eniris. Have you looked into that or you don't have plans to integrate your system for imbalance trading ?

[Floor-is]

SalX schreef op vrijdag 10 juli 2026 @ 00:03:
yes I have looked into EMHASS but it won't allow me to do imbalance trading (at least as per my understanding) as the APIs from FrankEnergy or nextenergy and others are locked and only with specific EMS hardware like from Vitron or Bliq or Eniris. Have you looked into that or you don't have plans to integrate your system for imbalance trading ?

I have a different energy-provider, that allows imbalance-trading. EMHASS works fine for that.

[SalX]

Would be helpful to know which one is that or is it not available for everyone ? By imbalance I mean the 15min emergency gaps (Tennet)

[ Voor 25% gewijzigd door SalX op 10-07-2026 00:16 ]

[Floor-is]

SalX schreef op vrijdag 10 juli 2026 @ 00:10:
Would be helpful to know which one is that or is it not available for everyone ? By imbalance I mean the 15min emergency gaps (Tennet)

Oh I don't mean the 15min emergency-gaps, I mean selling energy for EPEX-prices. And just about every provider will allow that.

[SalX]

Ok yea that makes sense since as per my understanding Tennet trading via the energy provider is strictly regulated and don't have open API.

I myself plan to do Tennet trading but will find a way to at least integrate the raw data it provides to home assistant even though I won't be able to control it since the proprietary EMS gets full control of when to charge/discharge. Maybe initially I might have to start with EMHASS and then add tennet later just to find out how much difference there is.

Also you mentioned "Measured: ~€110 profit over 20 summer days (post-2027); the design achieves 77%/57% of the theoretical optimum.": I assume this is based on simulated data. Could you clarify how this profit is calculated? Specifically, is it net profit after covering your household consumption, or does it represent the net savings/earnings after factoring in what the energy provider deducted from your overall bill?"

Also are you open sourcing your work on something like github or keeping it closed for now ?

[ Voor 5% gewijzigd door SalX op 10-07-2026 00:58 ]

[Floor-is]

SalX schreef op vrijdag 10 juli 2026 @ 00:56:
Ok yea that makes sense since as per my understanding Tennet trading via the energy provider is strictly regulated and don't have open API.

I myself plan to do Tennet trading but will find a way to at least integrate the raw data it provides to home assistant even though I won't be able to control it since the proprietary EMS gets full control of when to charge/discharge. Maybe initially I might have to start with EMHASS and then add tennet later just to find out how much difference there is.

There's whole threads on how to get the most out of the TenneT-deal, including a company providing a battery seemingly at a discount.

Also you mentioned "Measured: ~€110 profit over 20 summer days (post-2027); the design achieves 77%/57% of the theoretical optimum.": I assume this is based on simulated data. Could you clarify how this profit is calculated? Specifically, is it net profit after covering your household consumption, or does it represent the net savings/earnings after factoring in what the energy provider deducted from your overall bill?"

Good question, and the distinction matters: it is not profit.

The inputs are real: measured 5-second InfluxDB history of PV, household load, grid flows, EV sessions, and the actual EPEX price series over a 20-day window. What is simulated is the dispatch: what the battery and EV would have done under a given strategy. So it's a counterfactual replay on measured data, not a synthetic scenario.

The €110 is the difference between two simulated strategies, both scored as a full electricity bill across the meter boundary; household consumption included, priced at import/export tariffs:

• Naive floor: fixed 10 kW, no price awareness, end-SoC constrained equal to start. Post-2027 result: €27,52 earned over the window (summer, lots of export).
• Perfect-foresight optimum: a MILP fed the realized PV, load and prices, so it's an upper bound no controller can reach. Post-2027: €137,01 earned.

The €110 is the gap between them: the money on the table for any control strategy, measured rather than argued. The 77% / 57% is what my actual design captures of that gap when replayed with the forecasts it really had at the time.

Important caveats I'd rather state than have you discover:

• 20 summer days only. Daily spread is −€4,1 to +€25,4. Extrapolating to a year is not defensible; the top days are price-spread days, not just sunny ones (correlation with PV is only ~0,4).
• Idealized actuation: no CT clamping or settle losses. This is a planning ceiling, not an achievable one.
• EV energy delivered is identical across variants, so the per-kWh charging reimbursement cancels out and does not inflate the number.
• The optimum buys its money with heavy cycling (~29 kWh discharge/day); a €0,025/kWh wear penalty trims it slightly.

The most interesting finding wasn't the size of the prize but its composition: the gap between my design and the optimum is almost entirely not forecast error. PV-forecast loss was ~€0 even across six days with a dead forecast. The dominant term is that the decision curves fed to the optimizer deviate from a clean tariff axis — a valuation problem, not a prediction problem.

Also are you open sourcing your work on something like github or keeping it closed for now ?

Currently closed, but that's a "not yet" rather than a "no".

The intent is to eventually publish it as a reference, not as a product. What I have is welded to my own entities, my own inverter registers and my own tariff structure; publishing that as-is would produce a repo that runs on exactly one house in the world, and quietly misleads everyone else. Anything I put out would have to be stripped of my hardware and my entity names, which means what's left is the architecture and the reasoning, not a drop-in installation. You'd still have to sit down and wire it to your own setup.

That's deliberate. I think the reusable part here isn't the code, it's the decisions: single-writer arbitration per actuator, declarative reconciliation instead of edge-triggered automations, a replay harness that measures the size of the prize before anything gets built. Those transfer. My Modbus register map does not.

Practically it also lives in a private homelab repo alongside 'my stuff that I don't want leaving the house', so opening it up is an extraction job rather than a flip of a switch. Also: I've been greenfielding this thing, so what I have running right now is on the verge of replacement.

I've asked Claude to come up with the new percentage of architectural optimum and a rough estimate of costs saved: ±80% of optimum, so that hasn't really changed. But as I've been feeding it more and more data, the cost-saving went from about €750/year to over €1.000.
Looking at the amount of hours and money invested and needed to be invested still I'll probably never get to a positive ROI if I give my time any value, but that wasn't the goal to begin with

[ Voor 3% gewijzigd door Floor-is op 10-07-2026 03:04 ]

[teacher]

en we switchen weer naar Dutch yes?

[ Voor 10% gewijzigd door teacher op 10-07-2026 07:57 ]

[Floor-is]

Ik zal wat toevoegen dat ik hoop dat duidelijkheid verschaft, namelijk het doelontwerp, de SOLL.

1. Actuatoren — één schrijver, een fence, een failsafe
Drie regels, per actuator:

• Precies één schrijver. Meerdere automatiseringen die naar hetzelfde register schrijven, is de bugklasse die je nooit reproduceert en altijd op het verkeerde moment ziet.
• De fence zit in hardware, niet in de software die hem zou moeten respecteren. Een grens die alleen bestaat zolang je server draait, is geen grens.
• De failsafe valt terug op bekend gedrag, niet op "houd vast wat er stond". Een setpoint dat blijft hangen omdat de controller wegviel, is gevaarlijker dan geen setpoint.

Waarom de plan-laag geen actuator raakt. Een optimizer die zelf schrijft, is een tweede schrijver. Hij levert intenties aan - "ontlaad 3 kW tot 18:00" - en de arbiter vergelijkt die met de waargenomen toestand en schrijft alleen bij verschil. Dat maakt het systeem declaratief: er is geen edge-trigger die je kunt missen, en een herstart is geen bijzondere gebeurtenis.

2. Beslissen - een ladder, geen overleg
Van boven naar beneden: hoe hoger, hoe minder onderhandelbaar. Een lagere laag mag een hogere niet overrulen. Dat is de hele reden dat het een ladder is.

• De fence wint altijd, en hij weet niet eens dat er een optimizer bestaat.
• De gate zit vóór de economie. Een plan dat op verouderde data rust of te laat komt, wordt verworpen; niet "met minder gewicht meegenomen".
• Demand slaat economie. Goedkoop laden dat de deadline mist, is duur.
• De arbiter beslist niets. Hij reconcilieert. Bij een conflict van gelijke prioriteit schrijft hij niets en alarmeert hij. Een schrijver die zelf gaat kiezen, is een tweede beslisser.

3. Waar dit vandaan komt
Twee bugklassen, allebei uit de praktijk:

De schrijvers-race. Drie automatiseringen die elk hun eigen venster-index naar dezelfde registers schreven. Het resultaat hing af van de volgorde waarin ze vuurden, en die volgorde hing af van het weer.

De edge-trigger die je mist. Een cap die alleen op een flank reageert. Herstart je op het verkeerde moment, dan wordt de flank nooit gezien en loopt de accu door tot voorbij de grens.

Beide verdwijnen als je het systeem declaratief maakt: één schrijver die een gewenste toestand vergelijkt met de waargenomen toestand, en het verschil wegwerkt. Elke tick opnieuw, herstart of niet.

En de scheiding tussen waarderen en optimaliseren. De Value Engine zegt wat een kilowattuur nu waard is op een bepaalde route (bron × bestemming: accu→auto is iets anders dan net→auto). De optimizer zegt wanneer je hem moet inzetten. Die twee door elkaar halen, levert een model op dat je niet kunt narekenen en dat achteraf niet uitlegt waarom het deed wat het deed.

[Floor-is]

Tijdens het bouwen en gebruiken van wat er nu staat heb ik een aantal ontdekkingen gedaan, dus laat ik eens updaten over waar ik sta op het moment. Wat je wel weet vooraf, maar misschien niet genoeg rekening mee houdt is dat je gaandeweg telkens tegen dingen aanloopt en dat die soms interessanter zijn dan wat er uit de roadmap blijkt. Of zelfs dat je echt gevaarlijke situaties ontdekt die onmiddelijke actie vragen.

Er zat deze keer een duidelijke rode draad in wat ik tegenkwam: bijna alles had dezelfde vorm. Een vangrail, een meting of een aanname die er wél was, maar waarvan nooit bewezen was dát hij deed wat ik dacht. Geconfigureerd blijkt telkens iets anders dan bewezen. Dat haakt terug op het doelontwerp uit mijn vorige post: één schrijver, een fence in hardware, een failsafe die terugvalt op bekend gedrag, want de werkelijkheid voldoet nog niet aan dat ontwerp.

Het leuke, maar soms ook vervelende was en is dat elk daarvan uit een ándere bezigheid bovenkwam. Terwijl ik bouw, merk ik dat mijn overzicht van de grenzen versnipperd is. Terwijl ik het systeem gebruik, merk ik dat de laadpaal niet doet wat ik denk. Terwijl ik meet, stuit ik op een oven op de verkeerde groep. En terwijl ik op de omvormer stuur, zit z'n net-blindheid me elke dag in de weg. Zo gaat het eigenlijk aan één stuk door, soms is het echt ontzettend vermoeiend en soms hak je dan maar een knoop door die je eigenlijk niet wilde of van plan was, maar die gewoonweg problemen uit de weg haalt.

De arbiter draait~~, maar hij is bewust nog blind
Eerst het goede nieuws, want de rest is vooral onderweg opgeraapt. Het ontwerp uit mijn vorige post is geen praatje meer: Fase 1 (de arbiter met declaratieve reconciliatie) draait live op de homelab-server. Alleen: hij schrijft nog niets. Hij draait observerend (dry-run, nul writes) naast de bestaande oude aanpak.

Waarom zo omslachtig? Omdat ik wil kunnen bewíjzen dat de nieuwe schrijver hetzelfde doet als de oude vóórdat ik de oude eruit trek. Dus laat ik ze allebei tegen dezelfde werkelijkheid meelopen en vergelijk ik wat ze zóuden schrijven. Die "fence-equivalentie" is inmiddels in beide richtingen dichtgemeten: zowel het dichtknijpen (batterij aan de grens) als het weer loslaten (herstel), met een counterfactual ernaast die zegt wat de arbiter op dat exacte moment gedaan zou hebben. De conformance-test op de schrijf-naad staat op 8/8 groen.

Pas als dat rond is, gaat de oude schrijver eruit. Dit is de saaie, trage manier en precies daarom de goede.

Zes vangrails die toch niet bleken te bestaan~~~
En toen kwam de avond die de hele week bepaalde. Ik vond op één avond zes verschillende veiligheden die technisch aanwezig lijken maar nooit end-to-end tot de systeemgrens bewezen zijn. Onder andere: de netblinde omvormer (zie verderop), een `float(default)`-vangrail die bij een vers aangemaakte helper niet vuurt, een IDLE-mode die géén veilige actuatorstand handhaaft, en een dode notificatiegroep (daarover zo meer).

Ze waren technisch totaal verschillend, maar in het grotere geheel toch identiek: allemaal een vangrail die je bij inspectie ziet en waarvan je aanneemt dat hij werkt. Het meest vervelende is eigenlijk dat alle zes bij toeval boven water kwamen, als bijvangst van iets anders. Bewijsniveaus lopen van "de config zegt dat het er is" tot "de grens is aantoonbaar beschermd tot aan de rand van het systeem". Alleen dat laatste telt voor een veiligheidsclaim. En het gevaarlijkste tussenniveau is de logische toets: die vóélt als bewijs, maar een toets die je eigen aanname injecteert, toetst je aanname en niet het systeem.

Dat maakt me onrustig en zenuwachtig: als ik door methodisch tewerk te gaan niet tegenkom wat ik in de praktijk bij toeval tegenkom, wat voor issues liggen er dan nog op de loer?

Rookmelders die niet kunnen alarmeren
De scherpste van die zes verdient z'n eigen kop, al was het maar omdat dit topic ooit met rookmelders begon.

Mijn water-, rook- en hittealarmen leverden af aan niets. De notificatiegroep die ze moest bereiken had één lid dat niet bestond, en een notificatiegroep slikt een falend lid stil — je krijgt netjes een HTTP 200 terug, "verzonden", terwijl er nooit iets aankomt. De oorzaak was subtiel: de groep was gevuld met de netwerknaam van het toestel (zoals UniFi hem kent), maar de HA-app registreert onder de naam die het toestel zichzélf geeft.
Twee naamruimtes die op elkaar lijken, maar ze zijn niet hetzelfde..

Gefixt, en voor de mobieltjes en tablets die de meldingen moeten ontvangen ook getest en goed bevonden. Maar de les is groter dan de bug: een service-call die "succes" meldt bewijst alleen dat je verzónden hebt. Je moet het hele cirkeltje blijven testen, hoe irritant ook, wat je hebt bedacht en gebouwd kan nog zo goed zijn.. Er hoeft maar een bitje verkeerd te vallen en het functioneert gewoonweg niet zoals je had ontworpen en bedoeld.

De laadpaal kan de noodrem niet zijn
Deze kwam recht uit het dagelijks gebruik. Mijn EMS moet, als een fasestroom naar de 25 A kruipt, de auto kunnen stoppen .. dus de vraag: kan mijn huidige laadpaal die noodrem zijn?

Ik heb het getest, met de auto aan de kabel.. Via de app die bij de laadpaal hoort en dus via de omgeving van de leverancier etc. Een stop-signaal brengt 5,87 kW naar 0 in zo'n 21 seconden, in theorie snel genoeg. Maar het pad faalt stil: commando's komen niet altijd aan terwijl je in-app geen foutmelding krijgt. Bovendien valt de paal bij verlies van de verbinding terug op offline_max_usage en die lijkt hetzelfde te zijn als max_usage en die kan ik niet aanpassen. Ergo: als de laadpaal zijn internet of netwerk kwijtraakt gaat hij vrolijk met 16A/11kW stampen. Dat is alles behalve veilig gedrag, ik schrik hier echt van.

En er zit nog een addertje onder die cloud-koppeling: ik kan de paal alléén via de cloud aansturen, de HA-integratie is compleet onbetrouwbaar (zo meer), en de entiteiten zijn event-driven: ze updaten pas als er iets wíjzigt. Staat de auto vijf uur op 7 kW te laden, dan krijg ik vijf uur lang geen enkele update. In normaal bedrijf niet erg, maar het betekent wél dat een gezonde lange laadsessie en een dóódgevallen integratie er van buiten precies hetzelfde uitzien.

En dat verklaart meteen de wrange twist die precies in het thema van deze post past: mijn eigen diagnose was óók fout. Een deel van wat ik "aan de paal" meette, bleek een bevroren HA-integratie te zijn: 27 entiteiten twee dagen lang op een geldige nul, config-entry keurig "loaded", geen enkel alarm. Juist omdat "geen updates" normaal is, viel "geen updates omdat het dood is" niet op. De paal deed het gewoon; mijn meetinstrument was dood. Schijnzekerheid, één laag dieper: niet de vangrail, maar het verslag erover klopte niet.

Uitkomst: vervangen is geen keuze meer maar een vereiste, zeker omdat er in oktober een nieuwe auto komt die niet fijnmazig aanstuurbaar is én tot 22kW kan. Dat laatste maakt 11 kW voor mij een harde invariant in plaats van een voorkeur: 22 kW is 32 A/fase op een feeder van 25 A. Vol laden bleek over 28 dagen trouwens maar 4,1% van de laadtijd — de mediane laadstroom is 6 A, dus die begrenzing kost me vrijwel niets. Ik heb uren uitzoekwerk omdat ze nagenoeg vergelijkbaar zijn in alles behalve prijs. In de tussentijd draait er een softwarematige demper die de laadstroom terugknijpt bij een dreigende fase-overschrijding - nadrukkelijk een demper, geen fence: hij kan de auto niet volledig stoppen. (Ik heb wel iets ontdekt waarmee ik dat kan, maar nog niet geïmplementeerd: als ik de auto een 'ontkoppel de kabel' signaal geeft stopt hij met laden; de laadpaal luistert niet naar een stop-signaal namelijk )

De omvormer is netblind — en dat oplossen brengt een nieuw risico
Ik moet continue op de Deye sturen, maar één ding zit echt onwijs in de weg: hij ziet de hoofdaansluiting niet, want die zit 35 m verderop in het huis. Hoe erg dat is werd op 2 juli concreet: P1 zag 16.7kW import, de Deye rapporteerde 108W. Op dat verschil kan ik zijn native netfuncties niet vertrouwen, en zit ik zelf de regelkring te sluiten in Home Assistant. En een regelkring die ik sofwarematig moet zien te onderhouden is gewoonweg niet betrouwbaar genoeg in mijn boekje.

Inmiddels ligt de oplossing klaar (geleverd maar nog niet geïnstalleerd): een CHINT DTSU666 grid-meter die de Deye zélf lezen kan, via twee Waveshare RS485-naar-ethernet-bruggen die de meting transparant over mijn netwerk tunnelen. Home Assistant zit er dan niet meer tussen.

Dat is op twee manieren geen gratis verbetering;
1. De Chint en de WaveShares kosten bij elkaar iets van €175
2. Een omvormer die zélf op het net gaat regelen wordt een tweede schrijver met net-gezag, náást de arbiter die ik juist op "één schrijver per actuator" heb gebouwd. En die native regelkring ziet de per-fase-feedergrens niet; hij regelt op de hoofdaansluiting. Het onderscheid dat alles bepaalt: gaat de Deye het net alleen lézen, of gaat hij erop régelen? Dat moet beantwoord zijn vóór hij ergens gezag over krijgt. Een lokale regelkring die een grens niet kan waarnemen, mag je niet verantwoordelijk maken voor die grens.
Ik heb hier duidelijk nog werk te doen, maar dat kan ik nu alleen nog in theorie, als de boel is geïnstalleerd komt er vast wel weer een nieuw issue tevoorschijn

Terwijl ik bouwde, bleek mijn overzicht van de grenzen versnipperd
Al dat werk aan de arbiter draait om grenzen respecteren, maar toen ik ze op een rij wilde zetten, bleek mijn overzicht ervan verspreid over losse automatiseringen, YAML en mijn eigen hoofd. Ik had de LLM's weliswaar de opdracht gegeven om een soort centraal register bij te houden, maar die opdracht bleek niet bepaald waterdicht.

Er moest dus een nieuw centraal ding komen, een SPOT (single point of truth). In de SPOT vastgelegd welke grens geldt, wie hem bewaakt en op welk bewijsniveau. Heb er meteen een laag dieper bij gezet.. De laag meet je niet in de meterkast maar aan het draaiende systeem: per grens welke meting eronder hangt, hoe vers die is (P1 elke ~5 s, de accu-SOC pas elke ~60 s), welke metingen alleen updaten als er iets wíjzigt, en hoe snel elke knop eigenlijk stuurt.

Waarom die timing? Omdat je pas weet hoe scherp je kunt sturen als je 'm kent. Ken je de latency van elke knop en de versheid van elke meting, dan kun je de dwell (de wachttijd die oscillatie tegenhoudt) zo scherp mogelijk zetten: zo scherp sturen als het systeem toelaat, zonder dat het gaat oscilleren. Twee gaten zitten er nog in: sommige metingen updaten alleen bij een wijziging en kunnen dus hun eigen stilte niet melden (een dode en een rustige sensor zien er identiek uit; precies wat die laadpaal-sensor deed die uren op 0 kW bleef), en van de acht stuurknoppen heb ik er pas twee echt gemeten.

Om die te kunnen vullen heb ik het 'fysieke rondje' gemaakt: foto's maken van alle groepenkasten, alle automaten, alles dat ik maar dacht dat ik het eendraadsschema moest opnemen. Ik had een paar dingen echt heftig anders in mijn hoofd dan de realiteit is, maar het bleek ook dat er veel in mijn hoofd zit dat ik nog niet in de SPOT had opgenomen. Bijvoorbeeld de kabel (feed) van het huis naar de garage: die zit in een mantelbuis, maar die mantelbuis is niet goed meer. De kabel zit muurvast en is dus bijna onvervangbaar. Daarmee is 25 A/fase geen parameter maar een axioma; die grens verschuif ik nooit, dus alles eromheen moet zich ernaar voegen. Toegegeven: ik kan een nieuwe sleuf graven en een nieuwe mantelbuis leggen, maar dat beschouw ik voor nu gewoon als niet te doen, want dan moet ik grofweg een meter diep over een afstand van ±25m, dwars door de tuin en onder de paden en parkeerplaats door.

Het meten bracht een tweede, heel concrete en héél vervelende ontdekking: mijn oven hing op een perilex-groep.. Eén fase erin, drie eruit, en die drie allemaal op dezelfde fase (L2). Dat verklaarde in één klap waarom de de hoofdzekeringen er al twee keer waren uitgefikt. De oven, wasmachine en laden liepen samen over die ene fase. Ik heb de meterkast aangepast, opgelost. Maar het zette een grotere gedachte in gang (ja alweer): ik kán vandaag niet zíén of ik richting de 25 A per fase op de feeder ga, want die stroom meet ik nergens. En geen enkele meter aan de hoofdaansluiting lost dat op — niet de P1, en straks ook niet de Chint die er voor de Deye bij komt. Die kijken naar het net als geheel, terwijl de feeder een grens is die er 35 m achter ligt; wil je die bewaken, dan moet je een meter óp de feeder zetten. En "het is nu opgelost" is geen vangrail.
Daarom heb ik drie Shelly's gekocht (Pro 3EM-3CT63): één in de garage-subkast op de inkomende feeder, vandaag de enige harde grens die
op níveau nul staat: geen meting, geen bewaker. En omdat ik er tóch zit, meteen eentje voor de oven en de inductieplaat, die nu als restpost in de `untracked` van mijn Sankey verdwijnen. Caveat: deze Shelly's zijn WiFi-only, en juist de feeder-Shelly ís de grens — dus het contract wordt fail-closed: valt die meter weg, dan mag het EMS niet grid-laden.

Nog een ontnuchterende observatie uit die exercitie: het bewijsniveau van mijn grenzen volgt aandacht, niet risico. De hoofdzekering wordt "bewaakt" door een melder-plus-mens, terwijl de batterij-packstroom die nooit een probleem gaf keurig op het hoogste niveau staat. En de kaart zelf liep in drie dagen zes keer uit de pas met zichzelf. Dus een reconcile-check is nu voorwaarde, anders wordt de SPOT precies de schijnzekerheid die hij moest opsporen.

De batterij loog over zijn eigen SOC
En de laatste, mijn ~~~[sarcasme]favoriet~~~[/sarcasme]. Mijn drie battery-packs staan parallel, maar hun SOC-schattingen dreven ~0,9 procentpunt per dág uiteen. Een coulomb-toets had al laten zien dat ze even snél tellen, dus het verschil zat niet in de schaal of de capaciteit, maar in het nulpunt. Alleen: wie loog, de lage of de hoge?

Die vraag heb ik beantwoord door de accu bemand naar een echte vollading te duwen (cel ~3,6V) en te kijken wie beweegt. De spreiding klapte naar 0,9%, en pack 1 steeg 2,5 punt in een venster met maar ~0,1 kWh lading: herankering geslaagd. De cellen zijn fysiek kerngezond (3-7 mV onbalans). Geen capaciteits- of celprobleem dus, een nulpunt-fout. Dit grapje kostte me denk ik drie uur om uit te denken, in te regelen en vervolgens vanaf 'geaggregeerde SOC stijgt al 5 minuten niet meer' te begeleiden naar die 3,6V. Nu bijhouden hoe het zich ontwikkeld: krijg ik toch weer drift op dat ene pack of blijft het goed bij elkaar?

Trouwens wel fijn dat tijdens die operatie de vangrail in werking trad. Een freeze-detector die "energie erin maar SOC beweegt niet" als storing leest, kneep het laden dicht — precies het gedrag dat een herijking bovenin nódig heeft. De vangrail werkte perfect, tegen het verkeerde ding. Maar ik heb bewezen dat hij het doet

De ontbrekende laag: een watchdog
Deze houd ik kort: zonder watchdog weet je niet wanneer is stale is of stuk en krijg je ook geen seintje dat het stuk is. Dat uitwerken staat netjes op de roadmap en ik kijk er heerlijk tegenop


En het gereedschap zelf had het zelfverzekerd mis
Claude begreep niet hoe saldering werkt is denk ik de kortste samenvatting. En dat bleek niet alleen vervelende gevolgen te hebben, maar ook verdomd lastig om Claude goed aan te leren. Saldering wordt over het jáár afgerekend, niet per dag, dus elk exportoverschot van een goede dag werd weggegooid en de energiebelasting structureel overschat.
Ik laat Claude veel van het reken- en configuratiewerk doen, want dat kan Claude gewoon veel sneller dan ik. Maar dat betekende ook dat hij/zij/het die fout telkens weer terug liet komen, dat er aannames werden gedaan op basis van verkeerd begrepen rekenmethodieken en ik daardoor echt keer op keer moest blijven verbeteren (meermaals per dag).

Zoals Claude zegt: "Het venijn zat niet in de fout zelf maar in hoe hardnekkig hij was. Vanuit één verkeerde aanname van Claude (afrekenen per periode) is élk vervolgadvies intern kloppend én verkeerd. Een kruisproef binnen dezelfde data gaf een nette delta van €0,00 — wat als bevestiging vóélt, maar alleen consistentie is, geen correctheid. Jij hebt er als mens echt op moeten stáán om de aanname zélf ter discussie te stellen; een LLM verdedigt met verve een antwoord dat vanuit zijn premisse volmaakt klopt, en praat je bezwaar weg in plaats van het als signaal te lezen. Het orakel is niet de interne kruisproef, het is de factuur."

Na de fix (import minus export over de héle periode) geeft een exportdag een negatieve energiebelasting-bijdrage, zoals het hoort: de gemeten EB op mijn contract ging van €0,00 naar −€52,61. Zolang ik over het salderingsjaar netto-verbruiker blijf, klopt dat. En we weten dat ik dat blijf, want ik neem gewoonweg meer af dan ik opwek

De les is dezelfde als de rest van deze post, één abstractieniveau hoger: een intern consistente afleiding kan consistent verkeerd zijn, en tegenspraak binnen dezelfde bron is geen foutdetectie. Dat geldt voor een omvormer die z'n eigen SOC gelooft, en het geldt net zo goed voor de LLM die mijn meterkast helpt beheren.

Dat was 'm voor nu. Alle euro's en jaarcijfers die ik noem blijven hoogzomer-extrapolaties op een paar weken data; de richting is telkens robuuster dan het exacte bedrag. Vragen, correcties en "je doet iets doms"-opmerkingen zoals altijd welkom