Mijn huis bepaalt sinds kort zelf wanneer het stroom gebruikt

Mijn huis beslist zelf wanneer de auto laadt, de boiler opwarmt, de vaatwasser draait en de thuisaccu laadt of ontlaadt. Elk kwartier rekent het opnieuw uit wat het goedkoopst is, op basis van de stroomprijzen, de zonverwachting en mijn agenda. Ik bouwde het in Home Assistant, samen met AI. Hieronder leg ik uit hoe, met de echte code erbij.

Waarom ik dit bouwde

Door het afschaffen van de salderingsregeling wilde ik uitzoeken hoe ik met mijn zonnepanelen moest omgaan. We besloten een thuisaccu aan te schaffen. De reden: overdag hebben we een overschot, en de vraag naar stroom zit juist buiten de uren dat de zonnepanelen opbrengen. Met een accu werd het ook zinvoller om over te stappen naar een dynamisch contract.

Daarnaast kan onze accu het huis laten draaien tijdens een stroomstoring. Dat wordt voor ons belangrijker, omdat het stroomnet in Nederland steeds voller raakt en daardoor naar ons idee minder stabiel wordt.

Met een dynamisch contract verschilt de stroomprijs per kwartier, soms met een factor drie op één dag. Wie zijn grote verbruikers op het goede moment laat draaien, bespaart echt geld. Wie dat met losse timers en schakelaars probeert, verliest het overzicht.

Dit is de situatie bij ons thuis (oktober 2025 tot en met september 2026):

De vraag is elke dag dezelfde: wie krijgt welke kilowattuur, en wanneer? Laadt de accu nu uit het net omdat het straks duur wordt? Wacht de auto tot na middernacht? Warmt de boiler op met zonnestroom of op een goedkoop moment uit het net?

Die beslissingen hangen van elkaar af. Als de accu en de auto tegelijk op het goedkoopste kwartier mikken, overbelast je je aansluiting of laadt de auto uit de thuisaccu. Daarom moest één planner alles tegelijk afwegen.

Het ontwerp in één plaatje

Home Assistant verzamelt de gegevens en vertaalt elk apparaat naar drie getallen. EMHASS maakt daar elk kwartier één plan van voor alles samen. Per apparaat voert een eigen regelaar het plan uit, en die valt terug op een veilige stand als het plan uitblijft.

Het brein: elk kwartier een nieuw plan

De planner is EMHASS, een open-source optimalisatie die als app naast Home Assistant draait. Elk kwartier krijgt EMHASS de prijzen die Tibber al kent (minimaal 24 en maximaal 48 uur vooruit), de zonverwachting, het verwachte stroomgebruik van het huis en de stand van de accu. Dat stroomgebruik kennen we uit de gegevens van de kWh-meter in de meterkast. Daaruit rekent een lineair programma het goedkoopste plan uit voor de accu en drie “uitstelbare lasten”: boiler, vaatwasser en auto.

Het doel is winst: zo weinig mogelijk betalen voor import en zo veel mogelijk verdienen aan export. Zodra de salderingsregeling stopt, verandert dat doel waarschijnlijk naar zo veel mogelijk zelf verbruiken. Elk kwartier opnieuw rekenen heet voorspellend regelen: als de zon anders schijnt of de auto later thuiskomt, past het volgende plan zich vanzelf aan.

De automatisering die dit aanstuurt is kort. Eerst haalt hij de prijzen op bij Tibber, dan stuurt hij alles naar EMHASS:

- alias: EMHASS - MPC optimalisatie met Tibber prijzen
  triggers:
    - trigger: time_pattern
      minutes: /15
  actions:
    - action: tibber.get_prices
      data:
        start: "{{ now().strftime('%Y-%m-%d') }} 00:00:00"
        end: "{{ (now() + timedelta(days=2)).strftime('%Y-%m-%d') }} 00:00:00"
      response_variable: tibber_response
    - action: rest_command.emhass_mpc_optim
      data:
        load_cost: "..."         # alleen de prijzen vanaf het huidige kwartier
        soc_init: "{{ states('sensor.thuisaccu_soc') | float(0) / 100 }}"
        boiler_timesteps: "{{ states('sensor.boiler_benodigde_kwartieren') }}"
        vaat_timesteps: "{{ states('sensor.vaatwasser_emhass_kwartieren') }}"
        ev_timesteps: "{{ states('sensor.ev_emhass_kwartieren') }}"
        # ... en per apparaat de deadline en het vermogen
    - action: rest_command.emhass_publish_data

Het belangrijkste ontwerpbesluit zit in die laatste regels. Elk apparaat vertelt EMHASS alleen hoeveel kwartieren het nodig heeft, voor wanneer en met welk vermogen. Home Assistant rekent die drie getallen per apparaat uit. EMHASS bepaalt welke kwartieren het worden. Zo blijft de planner generiek en zit de kennis over het apparaat in Home Assistant.

De aanroep naar EMHASS zelf ziet er zo uit:

rest_command:
  emhass_mpc_optim:
    url: "http://emhass:5000/action/naive-mpc-optim"
    method: POST
    payload: >
      {"load_cost_forecast": {{ load_cost }},
       "prod_price_forecast": {{ prod_price }},
       "soc_init": {{ soc_init }},
       "prediction_horizon": {{ prediction_horizon }},
       "number_of_deferrable_loads": 3,
       "nominal_power_of_deferrable_loads": [1500, {{ vaat_power }}, {{ ev_power }}],
       "operating_timesteps_of_each_deferrable_load": [{{ boiler_timesteps }}, {{ vaat_timesteps }}, {{ ev_timesteps }}],
       "end_timesteps_of_each_deferrable_load": [{{ boiler_end_timestep }}, {{ vaat_end_timestep }}, {{ ev_end_timestep }}],
       "treat_deferrable_load_as_semi_cont": [true, true, false],
       "set_deferrable_load_single_constant": [false, {{ vaat_aan }}, false],
       "minimum_power_of_deferrable_loads": [0, 0, {{ ev_min_power }}]}

Drie details maken het verschil:

• Aan of uit, of traploos. De boiler en de vaatwasser zijn semi-continu: vol vermogen of niets. De auto mag traploos laden tussen 4,1 kW (6 ampère) en 11 kW. Later kan dat naar 22 kW, maar eerst bouwen we een beveiliging zodat de hoofdzekering er niet uitklapt.
• Eén blok. De vaatwasser krijgt single_constant: één aaneengesloten blok. Een programma kun je niet halverwege pauzeren.
• Niet dubbel tellen. EMHASS voorspelt het stroomgebruik van het huis uit het verleden, op basis van de kWh-meter. Daar zaten de boiler en de auto ook in, dus die werden dubbel geteld: één keer in de voorspelling en één keer als uitstelbare last. Een aparte sensor haalt ze er nu uit (sensor.power_load_no_var_loads).

EMHASS zet zijn plan terug in Home Assistant als sensoren: sensor.p_batt_forecast voor de accu en sensor.p_deferrable0 tot en met 2 voor de apparaten. Daarop reageren de regelaars hieronder.

De thuisaccu: het plan naar de omvormer

De thuisaccu is een Fronius-batterij aan de Fronius Gen24-omvormer. EMHASS zegt per kwartier hoeveel watt de accu moet laden of ontladen. Een automatisering vertaalt dat naar de vier standen die de Fronius via Modbus kent: Auto (eigen verbruik), Charge from Grid (laden uit het net), Discharge to Grid (ontladen naar het net) en Block Discharging (ontladen blokkeren).

- alias: EMHASS - Accu aansturen via Fronius Modbus
  triggers:
    - trigger: state
      entity_id: sensor.p_batt_forecast
    - trigger: time_pattern
      minutes: /15
    - trigger: state
      entity_id: binary_sensor.ev_laadt
  actions:
    - choose:
        # 1. De auto laadt: de thuisaccu mag niet in de auto leeglopen
        - conditions:
            - condition: state
              entity_id: binary_sensor.ev_laadt
              state: "on"
          sequence:
            - action: select.select_option
              target: { entity_id: select.thuisaccu_storage_control_mode }
              data: { option: Block Discharging }
        # 2. Geen vers plan: terug naar de veilige standaard
        - conditions:
            - condition: template
              value_template: >
                {{ states('sensor.p_batt_forecast') in ['unavailable', 'unknown']
                   or (now() - states.sensor.p_batt_forecast.last_updated).total_seconds() > 300 }}
          sequence:
            - action: select.select_option
              target: { entity_id: select.thuisaccu_storage_control_mode }
              data: { option: Auto }
        # 3. Ontladen naar het net (dure kwartieren)
        - conditions:
            - condition: numeric_state
              entity_id: sensor.p_batt_forecast
              above: 200
            - condition: numeric_state
              entity_id: sensor.thuisaccu_soc
              above: 16
          sequence:
            - action: select.select_option
              target: { entity_id: select.thuisaccu_storage_control_mode }
              data: { option: Discharge to Grid }
            - action: number.set_value
              target: { entity_id: number.thuisaccu_grid_discharge_power }
              data:
                value: "{{ [[states('sensor.p_batt_forecast') | float(0), 6000] | min, 200] | max }}"
        # 4. Laden uit het net (goedkope kwartieren): zelfde patroon, met Charge from Grid
      default:
        - action: select.select_option
          target: { entity_id: select.thuisaccu_storage_control_mode }
          data: { option: Auto }

De volgorde van de takken is het ontwerp. Eerst de bescherming van de auto, dan de veiligheid, pas daarna het geld. Valt EMHASS uit, dan staat de accu binnen vijf minuten weer op Auto en doet de omvormer gewoon eigen verbruik. Niets blijft hangen op “ontladen naar het net”.

In de EMHASS-configuratie staan de grenzen van de accu: tussen 15% en 90% laden, en een slijtagekost van 2 cent per kWh. Die laatste voorkomt dat de accu voor een paar cent prijsverschil een volledige cyclus maakt. In de simulatie halveerde dat bijna het aantal cycli, voor 2 tot 3 euro per maand.

De boiler: een accu van 120 liter

Een boiler is eigenlijk een warmteaccu. Het maakt niet uit wanneer hij opwarmt, als er ‘s ochtends warm water is. Mijn boiler is een “domme” Daalderop Mono koper van 120 liter, zonder eigen slimme functies. Alle slimheid zit erbuiten: een Shelly 1PM schakelt het element van 1.500 W, en een temperatuursensor onderin het vat meet hoe warm het water is.

Home Assistant rekent uit hoeveel kwartieren opwarmen nodig zijn tot de volgende deadline. ’s Nachts is dat 65 °C om 6 uur ‘s ochtends, zodat er gedoucht kan worden. Overdag is het 75 °C voor de avond, want dan gaan de kinderen in bad:

- name: "Boiler benodigde kwartieren"
  state: >-
    {% set temp = states('sensor.boiler_temperatuur') | float(none) %}
    {% set doel = states('sensor.boiler_plan_doel') | float(65) %}
    {% set rate = states('input_number.boiler_opwarmsnelheid') | float(10) %}   {# K per uur #}
    {% set maxk = states('sensor.boiler_kwartieren_tot_deadline') | int(16) %}
    {% set laden = is_state('switch.boiler', 'on') %}
    {% if temp is none %}0
    {% else %}
      {% set delta = doel - temp %}
      {# dode zone van 3 K: niet voor elke tiende graad een kwartier plannen #}
      {% if delta <= 0 or (delta < 3 and not laden) %}0
      {% else %}{{ [((delta / (rate / 4)) | round(0, 'ceil') | int), maxk] | min }}{% endif %}
    {% endif %}

EMHASS kiest de kwartieren. Maar het relais wordt niet door EMHASS geschakeld. Dat doet één regelaar die elke vijf minuten opnieuw beslist welke modus geldt, in een vaste volgorde:

nieuwe_modus: >-
  {% if not sensor_ok %}sensor_fout
  {% elif modus == 'handmatig' and handmatig_sec < 10800 %}handmatig
  {% elif temp < floor or (modus == 'safety' and temp < recovery_eff) %}safety
  {% elif not enabled %}uit
  {% elif leg_due and (modus == 'legionella' or prijs < prijs_gem or leg_uren_over > 24) %}legionella
  {% elif holiday %}uit
  {% elif negatief and temp < boost - 3 %}boost
  {% elif temp < dfloor - 3 and kw_tot_deadline <= kw_tot_floor + 1 %}deadline
  {% elif emhass_vraagt and temp < plan_doel %}emhass
  {% else %}uit{% endif %}

Dit is wat ik een toestandsgestuurde regelaar noem. Hij reageert niet op gebeurtenissen (“zet aan om 3:15”), maar kijkt elke vijf minuten naar de toestand en zet het relais waar het hoort. Na een herstart of een haperende wifi herstelt hij zichzelf binnen vijf minuten. Dit willen we nog slimmer maken.

De vangnetten liggen boven het geld:

• Veiligheid: onder de 50 °C altijd opwarmen. Is de stroom dan duur, dan alleen tot 55 °C. De rest plant EMHASS goedkoop in.
• Uiterste tijd: dreigt EMHASS de ochtend te missen, dan grijpt de regelaar zelf in.
• Legionella: elke week minstens een half uur boven de 60 °C, liefst op een goedkoop moment, uiterlijk een dag te laat.
• Negatieve prijs: opwarmen tot 85 °C. Je krijgt geld toe om warm water te maken.
• Op de Shelly zelf: een klein script bewaakt de minimumtemperatuur en de legionellacyclus, ook als Home Assistant helemaal plat ligt.

In de doorrekening scheelt slim opwarmen zo’n 25% ten opzichte van opwarmen tegen de gemiddelde dagprijs.

De vaatwasser: jij laadt in, het huis kiest het moment

Voor de vaatwasser hoeft niemand een app te openen. Je ruimt in, kiest een programma, drukt op Start op afstand en doet de deur dicht. De rest gaat vanzelf:

1. Home Assistant ziet via Home Connect dat de machine klaarstaat en legt een deadline vast. Overdag ingedrukt: schoon voor 17:00. ’s Avonds ingedrukt: schoon voor 6:00.
2. Uit het gekozen programma volgt hoe lang hij draait en hoeveel hij gemiddeld verbruikt. Eco 50 duurt 16 kwartieren op ~230 W, Quick 45 twee kwartieren op ~1.400 W.
3. Er draait direct een nieuwe EMHASS-planning, en het gezin krijgt een melding: “Gepland op het goedkoopste moment: start om 02:45.”
4. Zodra EMHASS de vaatwasser inplant, start Home Assistant het programma.

De deadline kiezen is het slimste stukje. Past het programma niet meer voor de eerstvolgende deadline, dan schuift hij door naar de volgende. De vaat is dan toch niet op tijd voor het eten, dus kan hij net zo goed op het goedkoopste moment:

deadline: >-
  {% set duur = timedelta(minutes=15 * states('sensor.vaatwasser_benodigde_kwartieren') | int(12)) %}
  {% set ochtend = today_at(states('input_datetime.vaatwasser_klaar_ochtend')) %}
  {% set middag = today_at(states('input_datetime.vaatwasser_klaar_middag')) %}
  {% set ns = namespace(d=none) %}
  {% for d in [ochtend, middag, ochtend + timedelta(days=1), middag + timedelta(days=1)] %}
    {% if ns.d is none and d - now() >= duur %}{% set ns.d = d %}{% endif %}
  {% endfor %}
  {{ ns.d.strftime('%Y-%m-%d %H:%M:%S') }}

Het starten zelf heeft twee triggers: het moment dat EMHASS kiest, en een vangnet op “deadline min programmaduur”. Ook als EMHASS uitvalt, is de vaat op tijd schoon.

- alias: Vaatwasser - Starten op EMHASS-moment
  triggers:
    - trigger: state
      entity_id: binary_sensor.vaatwasser_emhass_vraagt
      to: "on"
      id: emhass
    - trigger: template
      value_template: >-
        {% set u = states('sensor.vaatwasser_uiterlijke_start') | as_datetime %}
        {{ u is not none and now() >= u }}
      id: vangnet
  conditions:
    - condition: state
      entity_id: input_boolean.vaatwasser_wacht_op_emhass
      state: "on"
  actions:
    - action: home_connect.start_selected_program
    - action: input_boolean.turn_off
      target: { entity_id: input_boolean.vaatwasser_wacht_op_emhass }

Een randgeval verraste ons. Als een programma klaar is, springt de status van finished naar ready, met de deur dicht en Start op afstand nog aan. Voor Home Assistant lijkt dat precies op een nieuwe aanvraag, dus de vaatwasser plande zichzelf opnieuw in. De oplossing: een nieuwe aanvraag telt pas als de deur na het vorige programma open is geweest. Dat soort gedrag leer je alleen door het in je eigen huis te laten draaien.

De auto: van agenda naar laadstroom

De auto is de grootste verbruiker die je kunt verschuiven: 64 kWh accu, 11 kW laden. De vraag is niet alleen wanneer laden, maar ook hoeveel. Daarvoor kijkt het huis in mijn agenda.

Stap 1: hoe ver rijd ik morgen?

Elke avond om 19:55 leest een script de agenda’s van morgen:

• de werklocatie uit mijn werkagenda (kantoor, een klant, of thuis)
• vergaderingen met een fysieke ruimte, die het vertrek vervroegen of de thuiskomst later maken
• de gezamenlijke gezinsagenda.

Voor elke bestemming vraagt Home Assistant de afstand en reistijd op bij Waze, keer twee voor de terugweg. Uit de eerste afspraak volgt de vertrektijd.

- action: waze_travel_time.get_travel_times
  data:
    origin: zone.home
    destination: "{{ bestemming }}"
    region: eu
  response_variable: reis

Om 20:00 krijg ik een melding: “Morgen 56 km, vertrek 07:30, laden tot 71%.” Met knoppen om te bevestigen, aan te passen (typ 120 06:45) of toch vol te laden.

Stap 2: hoeveel moet erin?

De basis volgt uit de rit, met een reserve bij thuiskomst, een marge die meegroeit met de afstand, en een vaste buffer van 100 km voor als er iets tussenkomt:

- name: "EV basis SoC"
  unit_of_measurement: "%"
  state: >-
    {% set km = states('input_number.ev_km_morgen') | float(0) %}
    {% set soc_per_km = states('input_number.ev_verbruik_kwh_km') | float(0.2)
                        / states('input_number.ev_accu_kwh') | float(64.7) * 100 %}
    {% set rit_soc = km * soc_per_km %}
    {% set buffer_soc = states('input_number.ev_buffer_km') | float(0) * soc_per_km %}
    {% set rit_doel = states('input_number.ev_aankomst_reserve_soc') | float(20)
                      + rit_soc * (1 + states('input_number.ev_marge_pct') | float(15) / 100)
                      + buffer_soc %}
    {{ [[states('input_number.ev_ondergrens_soc') | float(30), rit_doel] | max, 100] | min | round(1) }}

Daarbovenop komt de prijs. Is de stroom voor vertrek goedkoop genoeg (onder de 15 cent), dan wordt het doel 80%. Is hij ergens negatief, dan 100%. Een laatste check vergelijkt dat met morgen: als de zon na thuiskomst gratis stroom belooft, laadt hij vannacht alleen de basis.

Stap 3: EMHASS plant, Home Assistant voert uit

De benodigde energie gaat als derde uitstelbare last naar EMHASS, met de vertrektijd als deadline. Het plan komt terug als vermogen in watt. Een laadregelaar zet dat om in ampère voor de wallbox, met een duidelijke volgorde:

- name: "EV modus"
  state: >-
    {% if is_state('input_boolean.ev_automatisering', 'off') %}uit
    {% elif is_state('binary_sensor.ev_stekker', 'off') %}geen_stekker
    {% elif is_state('input_boolean.ev_geforceerd_laden', 'on') %}geforceerd
    {% elif soc >= states('sensor.ev_doel_soc') | float(100) %}doel_bereikt
    {% elif not emhass_vers or not soc_vers %}failsafe
    {% else %}emhass{% endif %}
  attributes:
    stroom: >-
      {% set f = 3 * 230 %}
      {{ [(states('sensor.p_deferrable2') | float(0) / f) | round(0, 'floor') | int, 16] | min }}

De noodstand bestaat omdat de laadstand van de auto via de cloud van BMW binnenkomt, en die zwijgt soms urenlang. Is het plan van EMHASS ouder dan 30 minuten, of is de laadstand oud terwijl de auto laadt? Dan laadt de regelaar zelf tot de ondergrens van 30%, in de goedkoopste resterende kwartieren. De auto staat nooit leeg op de oprit.

Elke beslissing komt met een reden in het logboek, bijvoorbeeld: “EMHASS plant 7.360 W nu (laadstand 48% → doel 71%, prijs 12,4 ct).” Bij een systeem dat zelf beslist is dat essentieel: je moet achteraf kunnen zien waarom het iets deed. Zo kunnen we hier in de toekomst op verder bouwen en het nog slimmer maken.

Bouwen met AI: wat Claude deed en wat ik deed

Ik heb dit niet regel voor regel zelf getypt. Ik bouwde het samen met Claude Code, een AI-assistent die rechtstreeks in de configuratiemap van mijn Home Assistant werkt. Het verschil met een chatbot waar je code uit kopieert: Claude kan zelf de data lezen, bestanden aanpassen, controleren of de configuratie klopt, en het resultaat in het echte systeem bekijken.

Wat Claude deed:

• Meten voor het bouwen. Via de koppeling met Home Assistant las Claude een jaar aan meetgegevens: net, zon, accu, boiler, prijzen. Het rekende mijn Tibber-rekening na tot binnen 3% van de factuur, en simuleerde daarna scenario’s: wat als er geen accu was, wat als de boiler en de auto op de goedkoopste uren draaien? Zo wisten we waar het geld zat voordat er een regel code was.
• Het werk zelf. De pakketten voor boiler, vaatwasser en auto, de EMHASS-koppeling, de vangnetten en het laaddashboard. Bij elk pakket een README-bestand dat uitlegt hoe het werkt en waarom het zo gebouwd is.
• Fouten opsporen in het echte huis. Waarom laadde de accu de auto op? Waarom plande de vaatwasser zichzelf opnieuw in? Waarom telde EMHASS de boiler dubbel? Claude zocht het uit in de geschiedenis van de sensoren, niet door te gokken.
• Opruimen. Een controle van de hele configuratie vond kapotte automatiseringen, ongebruikte sensoren en wachtwoorden die in git stonden.

Wat ik deed:

• Bepalen wat het huis moet doen en wat belangrijk is: warm water gaat voor geld, de auto mag nooit leeg staan.
• Testen in het dagelijks leven, en terugkomen met “dit klopt niet”.
• De beslissingen nemen die je niet kunt terugdraaien.

Wat ik heb geleerd over werken met een AI-agent:

1. Geef hem echte data. De beste beslissingen kwamen uit de analyse van een jaar meetgegevens, niet uit aannames.
2. Eis uitleg in het systeem zelf. Elke beslissing in het logboek en een uitleg-attribuut op elke doelwaarde. Dan kun je het controleren, en vertrouw je het.
3. Kleine stappen, met een vangnet. Een git-commit na elke wijziging, en een terugvalstand voor als iets uitvalt.
4. Houd de onomkeerbare acties bij de mens. Toen Claude ongebruikte sensoren wilde verwijderen, werden een paar verwijderingen tegengehouden om een bevestiging te vragen. Zo hoort het.
5. Laat hem documenteren. Over drie maanden weet ik niet meer waarom de dode zone 3 graden is. Het README-bestand wel.

Dit is ook wat ik in mijn werk doe. Bij Forrict geef ik training in werken met AI-agents zoals Claude, en help ik mkb-bedrijven hun eigen workflows te automatiseren: met echte data, kleine stappen, vangnetten en uitleg in het systeem zelf, net als hierboven. Lees meer over AI met Claude.

Resultaten

In september 2026 betaalden we € 76,50 voor stroom (energiedeel, zonder vastrecht en netbeheer). Zonder slimme aansturing en accu was dat volgens de doorrekening € 142 geweest. Vóór dit alles zaten we met een vast contract op zo’n € 200 per maand. Het model rekent de werkelijke rekening na met minder dan 3% afwijking. De accusturing draait sinds maart 2026, toen de thuisaccu erbij kwam. In één maand kregen we zelfs € 100 terug.

Drie dingen vallen op:

• De accu verdient zichzelf terug door te handelen, niet door zonnestroom op te slaan. Tibber vergoedt teruglevering per kwartier tegen bijna de inkoopprijs. Het verschil zit in de prijs tussen uren: EMHASS laadde in september gemiddeld in voor 27,5 cent en leverde terug voor 40,5 cent.
• De planning zit binnen € 5 van het theoretische maximum. Met een perfecte voorspelling van zon en verbruik haal je nauwelijks meer.
• De volgende winst zit in de auto. De laatste regel van de tabel laat zien wat er nog te halen valt als de auto en de boiler ook op prijs laden. Dat is precies wat er sindsdien gebouwd is. De cijfers daarvan volgen.

Over het hele jaar (oktober 2025 tot en met september 2026) verbruikte het huis netto ~11.200 kWh. Daarvan kwam 35% uit eigen zon en accu, en 44% van de zonnestroom gebruikten we zelf.

Lessen en wat ik anders zou doen

• Eén planner, veel uitvoerders. EMHASS rekent, en per apparaat beslist een eenvoudige regelaar met vaste prioriteiten. Valt de planner uit, dan draait alles veilig door.
• Vangnetten boven geld. Warm water, een auto die niet leeg staat en een accu die niet blijft hangen op “ontladen” zijn belangrijker dan een paar cent.
• Maak het uitlegbaar. Een systeem dat zelf beslist, moet kunnen vertellen waarom. Anders zet je het binnen een maand uit.
• Kijk naar de regels die veranderen. Vanaf 1 januari 2027 stopt de salderingsregeling. Terugleveren levert dan minder op en zelf gebruiken meer. Omdat de logica in één planner zit, pas ik vooral de prijzen en een paar instellingen aan in plaats van alles opnieuw te bouwen.

Waarom niet gewoon evcc? evcc is een uitstekend open-source project voor slim laden en volgt het zonne-overschot sneller dan mijn oplossing. Maar evcc regelt alleen de auto. Het weet niets van mijn agenda, en plant de auto niet samen met de accu, de boiler en de vaatwasser. Voor mij zit de winst juist in dat geheel.

Tot slot

Dit project begon als hobby, maar het patroon is breder dan een huis. Data uit verschillende systemen samenbrengen, een optimalisatie die elke paar minuten opnieuw beslist, vangnetten voor als iets uitvalt, en een AI-agent die het bouwt, test en documenteert. Belangrijk daarbij: het proces zelf is deterministisch. Met dezelfde gegevens neemt het altijd dezelfde beslissing. Dat werkt net zo goed voor andere processen, zoals energiebeheer in een bedrijf of workflows die facturen verwerken. Daarnaast maak ik ook Ai-workflows die niet deterministisch zijn voor specifieke cases.

Wil je dit soort automatisering ook in jouw organisatie? Ik geef training aan teams die met AI aan de slag willen, en help mkb-bedrijven hun workflows te automatiseren. Of wil je gewoon de volledige code zien? Stuur me een bericht. Ik denk graag mee.

Bronnen

• EMHASS, open-source energiebeheer voor Home Assistant (MIT-licentie): documentatie en uitleg over naive-mpc-optim, broncode op GitHub
• Tibber: overstappen via mijn persoonlijke uitnodigingslink
• Fronius Modbus-integratie voor Home Assistant, met de storage control modes: redpomodoro/fronius_modbus
• Home Assistant: Home Connect-integratie, Tibber-integratie, Waze Travel Time-integratie
• Anthropic: Claude Code