StroomWekker schrijver
- Gepubliceerd
- 21 augustus 2026
- Bijgewerkt
- 21 augustus 2026
- Leestijd
- 18 min
Toen ik voor het eerst een prijssensor in Home Assistant zette, gebruikte ik de ingebouwde EnergyZero-integratie. Mijn wasmachine-automation stond netjes op het goedkoopste uur van de dag, tot ik een keer de app naast mijn eigen energierekening legde en zag dat de bedragen niet klopten. De sensor toonde de kale beursprijs, en die ligt in Nederland al snel elf cent per kWh onder wat je daadwerkelijk betaalt, omdat energiebelasting en btw er nog bovenop komen.
Dat is geen bug in de integratie, het is gewoon wat hij belooft te leveren: marktdata, geen eindprijs. Voor wie in Home Assistant automatiseert op basis van "het goedkoopste uur", maakt dat verschil in de praktijk zelden uit, want de belastingcomponent is op de meeste dagen redelijk constant en het goedkoopste marktuur is meestal ook het goedkoopste all-in uur. Maar zodra je exacte bedragen wilt tonen op een dashboard, of wilt automatiseren rond een drempel in euro's per kWh, reken je met het verkeerde getal. Dit artikel laat zien hoe je de Stroomwekker-API in Home Assistant zet, die de belastingopbouw al meegeeft.
Wat de EnergyZero-integratie wel en niet doet
De officiële EnergyZero-integratie in Home Assistant is een prima basis en precies daarom populair: hij is ingebouwd, vraagt geen API-sleutel en geeft je meteen de prijs van nu, de laagste en hoogste prijs van vandaag, en de prijzen van morgen zodra die er zijn. Wat hij niet doet, is de energiebelasting en btw verrekenen. Die twee componenten verklaren het gat tussen wat de sensor toont en wat er op je jaarafrekening staat.
Sommige gebruikers lossen dat zelf op met een template sensor die er handmatig een vast opslagbedrag bovenop telt. Dat werkt tot de energiebelasting per 1 januari verandert, of tot je vergeet dat de btw niet altijd 21% is geweest: van 1 juli tot en met 31 december 2022 gold tijdelijk 9%. Wie toen een script schreef en het nooit meer heeft aangepast, rekent voor die periode nog steeds met het verkeerde tarief. De Stroomwekker-API levert die opbouw per prijspunt mee, zodat je hem niet zelf hoeft bij te houden.
Een gratis sleutel, en waarom je hem toch nodig hebt
Voor sensoren in Home Assistant gebruik je niet de kleine feed van hierboven, maar de API op api.stroomwekker.nl zelf, en die vraagt om een sleutel. Vul je e-mailadres in op de sleutelaanvraag en je ziet hem meteen op je scherm staan: gratis, geen account, 50.000 verzoeken per dag. Voor een paar sensoren die een paar keer per dag verversen kom je daar in de praktijk niet eens in de buurt van.
Kopieer hem meteen. Hier wordt alleen een hash van bewaard, dus een kwijtgeraakte sleutel kun je vervangen, maar nooit opnieuw laten tonen.
De sleutel in secrets.yaml, niet in je configuratie
Zet de sleutel in secrets.yaml, het bestand dat naast configuration.yaml hoort en dat je nooit in een screenshot of een git-commit deelt:
# secrets.yaml
stroomprijzen_api_key: sp_live_xxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxxx
Home Assistant stuurt hem daarna zelf mee als query-parameter, via een params:-blok bij elke rest:-sensor:
params:
apiKey: !secret stroomprijzen_api_key
Dat blok hoort bij precies één rest:-item. Zet je meerdere sensoren op, dan krijgt elke zijn eigen params:. Wil je ook nog date of resolution meegeven, dan gaat dat in hetzelfde blok: een ? achter de URL in resource: en een los params:-blok worden niet samengevoegd.
Je eerste sensor: de prijs van dit moment
rest:
- resource: https://api.stroomwekker.nl/api/v1/prices/now
params:
apiKey: !secret stroomprijzen_api_key
scan_interval: 900
sensor:
- name: "Stroomprijs nu"
unique_id: stroomprijs_now
value_template: "{{ value_json.point.allInEurKwh }}"
unit_of_measurement: "EUR/kWh"
state_class: measurement
json_attributes_path: "$.point"
json_attributes:
- localTime
- rawEurMwh
- energyTaxEurKwh
- odeEurKwh
- vatRate
Herstart Home Assistant, en zoek onder Developer tools, kopje States, naar sensor.stroomprijs_now. Die toont een waarde als 0.3159, met de opbouw als attributen ernaast.
Zet ook de tijdzone van je Home Assistant-installatie op Europe/Amsterdam. Een Nederlandse dag begint, afhankelijk van de tijd van het jaar, op 22:00 of 23:00 UTC, en now() in een template rekent met de tijdzone van je eigen installatie. Sta je op UTC, dan schuift alles hieronder een uur of twee op.
Een hele dag vooruit, voor grafieken en planning
Voor een dashboard of een automation die vooruitplant is het huidige moment niet genoeg. Dat gaat via hetzelfde soort endpoint, maar dan met een datum erbij:
# tweede rest:-item, los van de sensor uit de vorige stap
rest:
- resource: https://api.stroomwekker.nl/api/v1/prices
params:
date: "{{ now().strftime('%Y-%m-%d') }}"
apiKey: !secret stroomprijzen_api_key
scan_interval: 21600
sensor:
- name: "Stroomprijzen vandaag"
unique_id: stroomprijzen_vandaag
value_template: "{{ value_json.summary.averageEurKwh }}"
unit_of_measurement: "EUR/kWh"
state_class: measurement
json_attributes:
- date
- count
- summary
- points
Wil je ook morgen zien, zet dan een tweede rest:-item op dezelfde manier, met (now() + timedelta(days=1)) in de datum. Vraag je die op vóór een uur of 14:00, dan krijg je gewoon een geldig antwoord terug met count: 0 en een lege points-lijst: geen foutcode, dus bouw je template daarop in plaats van een storing te vermoeden. Wil je liever kwartierprijzen dan uurprijzen, voeg dan resolution: quarterhour toe aan hetzelfde params:-blok. De Nederlandse markt handelt daar sinds 1 oktober 2025 al op, en een uurprijs is simpelweg het gemiddelde van de vier kwartieren erin.
Het goedkoopste uur, zonder extra verzoek
De sensor met vandaags prijzen heeft de hele dag al in huis, dus het goedkoopste uur is een berekening op wat je al hebt, geen nieuw verzoek aan de API:
template:
- sensor:
- name: "Goedkoopste uur vandaag"
unique_id: stroomprijs_goedkoopste_uur
state: >-
{% set p = state_attr('sensor.stroomprijzen_vandaag', 'points') %}
{% if p %}
{{ (p | sort(attribute='allInEurKwh') | first).localTime[11:16] }}
{% else %}
unknown
{% endif %}
- binary_sensor:
- name: "Stroom is nu goedkoop"
unique_id: stroom_is_nu_goedkoop
state: >-
{% set p = state_attr('sensor.stroomprijzen_vandaag', 'points') %}
{% set nu = states('sensor.stroomprijs_now') | float(-1) %}
{% if p and nu >= 0 %}
{% set goedkoopste = (p | map(attribute='allInEurKwh') | sort | list)[:6] %}
{{ nu <= goedkoopste[-1] }}
{% else %}
false
{% endif %}
Die binary sensor staat aan tijdens de zes goedkoopste uren van de dag. Pas het getal 6 aan naar wat bij jouw apparaat past: een wasmachine kun je desnoods een dag verschuiven, een boiler niet.
Een automation die er iets mee doet
automation:
- alias: "Auto laden als stroom goedkoop is"
triggers:
- trigger: state
entity_id: binary_sensor.stroom_is_nu_goedkoop
to: "on"
actions:
- action: switch.turn_on
target:
entity_id: switch.laadpaal
Draai je nog een Home Assistant-versie van vóór 2024.10, gebruik dan de oudere sleutelnamen trigger:, platform:, action: en service: in plaats van de bovenstaande.
Hoe vaak moet je eigenlijk verversen?
Dit is waar ik zelf de meeste sensoren te vaak zag pollen. Day-ahead-prijzen veranderen maar twee keer per dag: morgen komt er rond 14:00 bij, en om middernacht wordt morgen vandaag. Een gepubliceerde dag verandert daarna niet meer, dus twee gerichte momenten werken beter dan elk kwartier hetzelfde verzoek herhalen:
# twee automations in plaats van een korte scan_interval
automation:
- alias: "Prijzen: nieuwe dag na middernacht"
triggers:
- trigger: homeassistant
event: start
- trigger: time
at: "00:05:00"
actions:
- delay: "{{ range(0, 600) | random }}"
- action: homeassistant.update_entity
target:
entity_id: sensor.stroomprijzen_vandaag
- alias: "Prijzen: wachten op morgen"
triggers:
- trigger: time_pattern
hours: "14"
minutes: "/20"
- trigger: time_pattern
hours: "15"
minutes: "/20"
actions:
- delay: "{{ range(0, 300) | random }}"
- action: homeassistant.update_entity
target:
entity_id: sensor.stroomprijzen_morgen
Die willekeurige vertraging is geen versiering. Zonder die delay klopt elke Home Assistant-installatie in Nederland op exact dezelfde seconde aan, en dat is precies het soort samenloop dat een API onnodig zwaar belast.
Meer bouwen? De volledige gids staat al klaar
Dit artikel dekt de basis, maar de uitgebreide versie, met een ApexCharts-grafiek van de hele dag, de koppeling met het Energy-dashboard van Home Assistant, en hoe je de belastingcijfers zelf natelt via /api/v1/tax-rates en /api/v1/test-vectors, staat al helemaal uitgeschreven op api.stroomwekker.nl/docs/home-assistant. Loopt er iets vast, dan staat daar ook een sectie met de meest voorkomende valkuilen, inclusief hoe je met je eigen sleutel natrekt hoeveel verzoeken je vandaag al hebt verstuurd.
Geen zin in YAML? Er is ook een kortere weg
Het bovenstaande is voor wie iets wil bouwen: een sensor die blijft draaien, een automation die zelf beslist. Wil je liever gewoon af en toe een vraag stellen zonder eerst een configuratiebestand te bewerken, dan bestaat daarvoor een MCP-server op dezelfde databron. Je koppelt hem één keer aan Claude of een andere assistent die MCP ondersteunt, en vraagt daarna in gewone taal wanneer het vandaag goedkoop is of hoeveel energiebelasting er dit jaar in een kWh zit. Geen Home Assistant nodig, geen template, wel dezelfde all-in cijfers.
Wat kun je nu doen?
Neem de sensoren hierboven over in je eigen configuration.yaml, vergelijk de uitkomst een dag lang met Stroomprijs vandaag om te zien of hij overeenkomt, en lees all-in prijs versus marktprijs als je precies wilt weten welke componenten in dat getal zitten. Wil je begrijpen waarom de prijs per uur zo verschilt in plaats van alleen automatiseren op het cijfer, dan legt waarom verschilt de stroomprijs per uur? de marktlogica erachter uit.
Heb je zelf al een dashboard of automation gebouwd op deze feed, of loop je ergens tegenaan met de templates hierboven? Deel het in de Stroomwekker Telegram groep, ik ben oprecht benieuwd wat anderen ermee bouwen. Liever geen gedoe met YAML en gewoon een seintje bij een lage prijs? Zet dan onze gratis Telegram bot aan.
Let op: De precieze energyTaxEurKwh, odeEurKwh en vatRate uit de attributen horen bij de opgevraagde dag. Verwerk je die waarden in een eigen berekening buiten deze sensoren om, gebruik dan telkens de waarden van de dag zelf in plaats van een vast getal dat je ooit hebt overgenomen.