Home Assistant + warmtepomp: koppelen via Modbus, met YAML-voorbeelden

Kijk welke uren morgen goedkoop zijn. Op stroomprijzen morgen zie je de uurprijzen van morgen en de goedkoopste uren en laadblokken: de uren waarin je de buffer van je warmtepomp wilt laten opladen.

Disclosure: de links naar HomeWizard, ANWB Energie en EnergyZero in dit artikel zijn affiliate-links (via Daisycon). Sluit je daarvia iets af, dan ontvangen wij mogelijk een commissie, zonder extra kosten voor jou. Met warmtepompfabrikanten en de andere energieleveranciers in dit artikel hebben wij géén commissie- of affiliaterelatie; die namen worden alleen genoemd omdat hun integratie of documentatie relevant is. Bron voor de integratie-informatie: home-assistant.io, gecontroleerd op 19 oktober 2026. HomeWizard-prijs: homewizard.com, gecontroleerd op 19 oktober 2026.

Kort antwoord: een warmtepomp koppel je aan Home Assistant via een merkintegratie (Nibe, MELCloud, ViCare, Atag One) of — als die er niet is — via Modbus TCP met de registeradressen uit het serviceboek. Daarna heb je een prijsentiteit en een buffer nodig om warmte naar goedkope uren te verschuiven. Hieronder de YAML die daarvoor nodig is.

Wat werkt er echt: de integraties die in Home Assistant core zitten

De volgende integraties staan in Home Assistant core (gecontroleerd op home-assistant.io, 19 oktober 2026):

Twee dingen die hier níet in staan, en die je elders wel als feit ziet opduiken:

• Quatt. Er is op 19 oktober 2026 geen integratiepagina voor Quatt in Home Assistant core (home-assistant.io/integrations/quatt/ geeft een 404). Koppelen kan via een custom-integratie uit de community, maar dat is geen door HA-core onderhouden en gedocumenteerde integratie. Wij noemen die koppeling daarom onbevestigd en niet als officiële integratie.
• Vaillant en Bosch. Ook hiervoor staat niets in core. Voor Vaillant bestaat een community-integratie op de myVAILLANT-API (mypyllant-component op GitHub). Volgens de makers is die niet gelieerd aan Vaillant en kent de Vaillant-API geregeld storingen en strikte limieten, wat tot fouten in de integratie leidt. Voor Bosch-warmtepompen vonden wij geen core-integratie.

Check vóór aanschaf of jouw exacte model in core staat of een Modbus-poort heeft. Een merk dat alleen via een app-API te bereiken is, is kwetsbaarder dan een lokale koppeling.

Stappenplan

Stap 1 — meet eerst, stuur later. Zet een P1-meter in Home Assistant en laat het een tot twee weken meelopen. Je wil weten hoeveel kWh de warmtepomp per etmaal trekt en op welke uren. Zonder dat getal kun je later niet zien of je automatisering iets oplevert.

De HomeWizard P1-meter heeft een officiële, lokale Home Assistant-integratie (home-assistant.io/integrations/homewizard). Bekijk de HomeWizard P1-meter (€24,95)

Stap 2 — haal de prijsdata binnen. Je hebt een entiteit nodig met de prijs per uur (of per kwartier) voor vandaag en, zodra die in de loop van de middag bekend zijn, voor morgen. Dat kan via de integratie van je leverancier, of via een REST-sensor op een publieke bron. Zie het YAML-voorbeeld hieronder met onze eigen open endpoint.

Stap 3 — koppel de warmtepomp. Eerst kijken of je merk in de tabel hierboven staat. Zo niet: serviceboek erbij, Modbus TCP aanzetten op de regelaar en de registeradressen opzoeken. Begin met alleen lezen (temperaturen, vermogen) voordat je iets gaat schrijven.

Stap 4 — bepaal wat je stuurt. Er zijn drie realistische stuurgrepen, in volgorde van veiligheid: (a) het setpoint van het buffervat of de warmtapwaterboiler, (b) een verschuiving op de stooklijn (een paar graden op of af), (c) aan/uit via een blokkeeringang. Optie (c) is het grofst.

Stap 5 — bouw een fallback. De warmtepomp moet zonder Home Assistant zijn eigen regeling blijven volgen. Schrijf nooit een permanente blokkade weg die blijft staan als HA crasht, en zet een for-duur of een watchdog-automatisering op elke blokkade.

Stap 6 — evalueer over een heel stookseizoen. Vergelijk niet twee weken met twee weken: correct voor graaddagen. Een milde week ziet er al snel uit als een succesvolle automatisering.

YAML-voorbeeld 1: Modbus TCP (generiek)

Onderstaande configuratie is een template: de registeradressen hieronder zijn voorbeelden en verschillen per fabrikant en zelfs per firmwareversie. Haal jouw adressen uit het Modbus-document of serviceboek van je toestel — verkeerde adressen schrijven kan instellingen overschrijven.

# configuration.yaml
modbus:
  - name: warmtepomp
    type: tcp
    host: 192.168.1.50
    port: 502
    delay: 5
    message_wait_milliseconds: 30
    sensors:
      - name: wp_aanvoertemperatuur
        slave: 1
        address: 40001          # voorbeeldadres — vervang door dat van jouw toestel
        input_type: holding
        data_type: int16
        scale: 0.1
        precision: 1
        unit_of_measurement: "°C"
        device_class: temperature
      - name: wp_retourtemperatuur
        slave: 1
        address: 40002
        input_type: holding
        data_type: int16
        scale: 0.1
        precision: 1
        unit_of_measurement: "°C"
        device_class: temperature
      - name: wp_elektrisch_vermogen
        slave: 1
        address: 40010
        input_type: holding
        data_type: uint16
        unit_of_measurement: W
        device_class: power
        state_class: measurement
    climates:
      - name: warmtepomp_buffer
        slave: 1
        address: 40100
        input_type: holding
        target_temp_register: 40100
        data_type: int16
        scale: 0.1
        precision: 1
        min_temp: 20
        max_temp: 55
        temp_step: 0.5

Dit levert je een climate.warmtepomp_buffer plus drie sensoren op. Begin met de sensoren en laat het climates-blok eruit tot je zeker weet dat het adres klopt.

YAML-voorbeeld 2: day-ahead-prijzen als REST-sensor

Heeft je leverancier geen integratie, dan kun je de uurprijzen ophalen uit een publieke bron. Onderstaand voorbeeld gebruikt onze eigen open endpoint, die de day-ahead-prijzen (kale EPEX-prijs inclusief btw, exclusief energiebelasting en inkoopvergoeding) per uur in Nederlandse tijd teruggeeft:

# configuration.yaml
rest:
  - resource: https://beheer.wtdigital.nl/api/public/stroomprijzen
    scan_interval: 900
    sensor:
      - name: stroomprijs_gemiddeld_vandaag
        value_template: "{{ value_json.gemiddelde }}"
        unit_of_measurement: "EUR/kWh"
      - name: stroomprijs_nu
        value_template: >
          {% set u = now().hour %}
          {{ (value_json.uren | selectattr('uur','eq',u) | map(attribute='prijs') | first) | default(0) }}          
        unit_of_measurement: "EUR/kWh"
        json_attributes:
          - uren
          - datum
          - bron

Let op: dit is de kale marktprijs. Wat jij per kWh betaalt is die prijs plus energiebelasting (€0,11085 per kWh inclusief btw in 2026) plus de inkoopvergoeding en vaste kosten van je leverancier. Voor sturing maakt dat niet uit — de belasting is elk uur gelijk, dus de spread tussen uren is hetzelfde — maar voor het uitrekenen van je besparing wel.

YAML-voorbeeld 3: is dit een goedkoop uur?

Een drempel van “onder 10 cent” werkt in de winter anders dan in de zomer. Beter is een relatieve drempel: goedkoop ten opzichte van het daggemiddelde.

# configuration.yaml
template:
  - binary_sensor:
      - name: Goedkoop uur
        unique_id: goedkoop_uur
        state: >
          {% set nu = states('sensor.stroomprijs_nu') | float(0) %}
          {% set gem = states('sensor.stroomprijs_gemiddeld_vandaag') | float(0) %}
          {{ gem > 0 and nu < (gem - 0.05) }}          
        availability: >
          {{ states('sensor.stroomprijs_nu') not in ['unknown', 'unavailable'] }}          

YAML-voorbeeld 4: buffer opladen in de goedkope uren

# automations.yaml
- alias: Buffer opladen bij lage dagprijs
  id: wp_buffer_laden_goedkoop
  trigger:
    - platform: state
      entity_id: binary_sensor.goedkoop_uur
      to: "on"
  condition:
    - condition: numeric_state
      entity_id: sensor.buitentemperatuur
      above: -2
    - condition: numeric_state
      entity_id: sensor.wp_aanvoertemperatuur
      below: 42
  action:
    - service: climate.set_temperature
      target:
        entity_id: climate.warmtepomp_buffer
      data:
        temperature: 47
    - delay: "02:00:00"
    - service: climate.set_temperature
      target:
        entity_id: climate.warmtepomp_buffer
      data:
        temperature: 38
  mode: single

Twee dingen over deze automatisering. Ten eerste: de delay met een terugzet-actie is de eenvoudigste vorm van een fallback — na twee uur staat het setpoint weer normaal, ook als de prijsdata daarna uitvalt. Ten tweede: service: mag in recente Home Assistant-versies ook action: heten; beide werken, service: is de vorm die in alle versies sinds jaren geldig is.

Wil je hetzelfde voor warmtapwater, dan is dat vaak de veiligere eerste stap: een boiler van 180 liter die je van 45 naar 55 °C opwarmt parkeert ongeveer 2 kWh warmte (180 liter × 10 graden × 1,16 Wh per liter per graad), zonder dat de temperatuur in huis verandert.

YAML-voorbeeld 5: blokkeren op de piek, met watchdog

# automations.yaml
- alias: Warmtepomp terugschroeven op het duurste uur
  id: wp_piek_terug
  trigger:
    - platform: template
      value_template: >
        {% set uren = state_attr('sensor.stroomprijs_nu','uren') | default([], true) %}
        {% set nu = states('sensor.stroomprijs_nu') | float(0) %}
        {% set top = uren | map(attribute='prijs') | list | sort | last | default(0) %}
        {{ uren | count > 0 and nu >= top }}        
  action:
    - service: climate.set_temperature
      target:
        entity_id: climate.warmtepomp_buffer
      data:
        temperature: 32
  mode: single

- alias: Watchdog — setpoint nooit langer dan 3 uur verlaagd
  id: wp_watchdog
  trigger:
    - platform: numeric_state
      entity_id: climate.warmtepomp_buffer
      attribute: temperature
      below: 34
      for: "03:00:00"
  action:
    - service: climate.set_temperature
      target:
        entity_id: climate.warmtepomp_buffer
      data:
        temperature: 38
  mode: single

Wat levert het op? Een modelberekening

Onderstaande cijfers zijn een modelberekening met expliciete aannames, geen meting van een eigen installatie.

Aannames: een warmtepomp die per etmaal 20 kWh elektrisch verbruikt in een koude periode, waarvan je 6 kWh kunt verschuiven van een duur naar een goedkoop uur. Op basis van de EPEX-data over 2025 (jaargemiddelde €0,105/kWh inclusief btw) is een spread van €0,08/kWh tussen het goedkoopste en het duurste kwart van de dag een realistische orde van grootte in het stookseizoen: in ons uurarchief was het verschil tussen het gemiddelde van de zes duurste en de zes goedkoopste uren over januari–maart en oktober–december 2025 gemiddeld €0,083. Sommige dagen zijn veel beter, sommige vlak.

• Bruto prijswinst: 6 kWh × €0,08 = €0,48 per etmaal.
• Rendementsverlies: warmte wegzetten op een hogere temperatuur verlaagt de COP (bij de Vaillant aroTHERM plus bijvoorbeeld is de opgegeven SCOP bij 35 °C 4,83–5,13 en bij 55 °C 3,62–3,86 (vaillant.nl)). Ga uit van 8 procent slechter rendement op die 6 kWh, dan kost dat ongeveer 0,5 kWh extra tegen een gemiddelde all-in prijs van €0,26/kWh (aanname all-in: EPEX €0,105 + energiebelasting €0,11085 + €0,044 opslag en vaste-kostenomslag, alle bedragen inclusief btw) — circa €0,13.
• Netto: ongeveer €0,35 per etmaal, over 150 stookdagen circa €50 per jaar.

Prijssturing van een warmtepomp is daarmee een optimalisatie, geen verdienmodel. Het loont vooral als je toch al een dynamisch contract hebt, als je een echt buffervat hebt (niet alleen vloerverwarming) en als je het opzetten als hobby ziet. Heb je een vast contract, dan is er hooguit het verschil tussen dal- en normaaltarief (bij een dubbeltarief) en verder alleen hysterese-optimalisatie.

Reken het door met je eigen cijfers: kijk in de stroomprijzen per uur hoe groot de spread op jouw dagen werkelijk is.

Voorbeeldopzet: warmtepomp met Modbus of merkintegratie op een dynamisch contract

Een opzet met publiek gedocumenteerde onderdelen: bijvoorbeeld een Nibe S-serie via de ingebouwde Modbus TCP-server en de nibe_heatpump-integratie (home-assistant.io), met de uurprijzen uit een leveranciersintegratie of de REST-sensor hierboven.

De automatisering: zakt de dag-vooruitprijs onder de drempel én ligt de buitentemperatuur boven nul, dan gaat het setpoint van het buffervat omhoog zodat er warmte wordt weggezet in de goedkope uren. In de dure uren draait de pomp op een lager setpoint of staat hij stil.

Wat dit oplevert hangt af van drie dingen: de bufferomvang (hoeveel kWh je kunt wegzetten), het temperatuurverschil dat je bereid bent te accepteren, en de spread tussen goedkope en dure uren. Het verschuiven van warmte naar een hogere aanvoertemperatuur kost rendement — hoe hoger de aanvoertemperatuur, hoe lager de COP (bij de Vaillant aroTHERM plus bijvoorbeeld is de opgegeven SCOP bij 35 °C 4,83–5,13 en bij 55 °C 3,62–3,86 (vaillant.nl)) — dus de prijswinst moet groter zijn dan het COP-verlies. Bij smalle spreads valt dat nadelig uit, bij brede spreads gunstig.

Deze automatisering levert alleen iets op met een dynamisch energiecontract: met een vast enkeltarief kost een kWh om 3 uur ’s nachts net zoveel als om 6 uur ’s avonds. Bij een dynamisch contract betaal je per uur de beursprijs plus een vaste opslag. Vergelijk de opslag en de vaste kosten per maand, want die bepalen of de €50 per jaar uit de modelberekening overblijft; het volledige overzicht staat in dynamische energiecontracten vergelijken.

Bekijk het dynamische contract van ANWB Energie Bekijk het dynamische contract van EnergyZero

Veelgemaakte integratiefouten

1. Te agressief sturen. Laat de regeling van de warmtepomp zelf moduleren en stuur niet met veel aan/uit-commando’s; kijk in de handleiding van je toestel wat de fabrikant daarover zegt.
2. Buitensensor negeren. Sturen op alleen prijs, zonder buitentemperatuur, leidt in het voorjaar tot oververhitting en in strenge vorst tot een pomp die op het verkeerde moment uit staat.
3. Verkeerde Modbus-mapping. Niet elk toestel van hetzelfde merk heeft dezelfde registeradressen; ze wijzigen ook tussen firmwareversies. Serviceboek erbij, en eerst alleen lezen.
4. Geen veiligheidsfallback. Als HA crasht moet de warmtepomp zijn eigen logica blijven volgen. Bouw een watchdog zoals in voorbeeld 5.
5. Vloerverwarmingstraagheid onderschatten. Een vloer reageert in uren op een setpointwijziging, niet in minuten. Plan vooruit, of stuur op het buffervat en de boiler in plaats van op de vloer.
6. Cloud-API-limieten negeren. Bij ViCare loop je op de gratis laag tegen de limiet aan als je elke 10 seconden pollt; de integratie valt dan uit precies wanneer je hem nodig hebt.

Wanneer integratie de moeite niet waard is

Heb je een vast energiecontract, dan is er geen prijsverschil per uur om op te sturen, hooguit het verschil tussen dal- en normaaltarief bij een dubbeltarief; wat verder overblijft is comfort en inzicht. Heb je een hybride opstelling zonder dataport voor modulatie, dan kun je via HA hooguit aan/uit sturen, en dat is de grofste vorm van sturing. En heb je geen enkele buffer (geen buffervat, geen boiler, alleen radiatoren), dan is er niets om warmte in te parkeren.

Verder lezen: energiemonitor en P1-meters vergeleken, de day-ahead-prijzen per uur, wat het einde van de saldering betekent, openHAB voor zonnepanelen en thuisbatterij en Tado, Nest en Honeywell als slimme thermostaat vergeleken.