Realisatie: PV-overschot sturen voor zwembadpomp en airco

Waarom dit project

Bij een klant met zonnepanelen, een zwembadpomp en twee Daikin airco’s botsten we op een klassiek probleem. De pomp draaide op een vast schema en de airco’s stonden meestal uit, terwijl de panelen op zonnige dagen vrolijk overschot het net op duwden. Dat hebben we omgedraaid: de zon stuurt nu de zware verbruikers, niet de klok.

In dit artikel lopen we door hoe we dat opbouwden in één Home Assistant package, hoe we de logica robuust maken (geen pomp die elke wolk volgt) en welke knoppen we bewust aan de gebruiker hebben gegeven.

De vraag

De klant wou drie dingen tegelijk:

• Zoveel mogelijk eigen verbruik in plaats van injectie naar het net.
• Geen verlies van controle. Als hij de pomp wil aanzetten, moet dat gewoon kunnen.
• Een dagelijks minimum runtime voor de zwembadpomp (filtratie blijft niet-onderhandelbaar).

De architectuur in één blik

We gebruikten één Home Assistant package, zwembad_airco.yaml, dat alle helpers, sensoren, scripts en automations samenbrengt. Dat houdt de installatie verplaatsbaar en makkelijk te lezen voor de klant.

homeassistant:
  packages: !include_dir_named packages

Bovenstaande regel in configuration.yaml zorgt dat Home Assistant alle YAML-bestanden in de map packages/ automatisch inleest. Het package zelf bevat dan alles wat bij deze use case hoort, los van de rest van de configuratie.

De bestaande hardware

We bouwden bovenop wat er al stond:

• P1-meter met sensor.qpg4lwzx_export_power (kW geïnjecteerd) en sensor.qpg4lwzx_import_power (kW afgenomen)
• Zwembadpomp als slimme schakelaar (switch.pool_pump_pump) met aparte vermogensmeting
• Twee Daikin airco’s (climate.living en climate.keuken). Belangrijk: ze delen één buitenunit.

Dat laatste is een detail dat verderop in de logica doorweegt. Twee splits op één buitenunit kunnen niet vrij elk in een andere mode (cool versus heat) draaien. We moesten dus in de automation altijd beide units in dezelfde modus zetten.

Stap 1: kW naar W omzetten

De P1-sensoren leveren waarden in kW. Onze logica werkt intern liever in W omdat de drempels zo natuurlijker leesbaar zijn (“3300 W export” voelt concreter dan “3,3 kW”). We maken daarom twee template-sensoren:

template:
  - sensor:
      - name: "P1 export power W"
        unique_id: p1_export_power_w
        unit_of_measurement: "W"
        state: "{{ (states('sensor.qpg4lwzx_export_power') | float(0)) * 1000 }}"
      - name: "P1 import power W"
        unique_id: p1_import_power_w
        unit_of_measurement: "W"
        state: "{{ (states('sensor.qpg4lwzx_import_power') | float(0)) * 1000 }}"

Deze twee sensoren worden enkel intern in de triggers gebruikt. In Lovelace tonen we nog steeds de originele kW-versies omdat “1.95 kW” prettiger leest op een dashboard dan “1950 W”. Klein detail, maar dit voorkomt veel verwarring later. De waarde is hetzelfde, alleen de eenheid verschilt.

Stap 2: drempels en tijden tunbaar maken via de UI

We willen dat de klant zelf kan spelen met drempels zonder dat we YAML moeten openen. Daarom staat elke parameter als helper (input_number / input_datetime / input_boolean) in Home Assistant:

Helper	Default	Functie
zwembad_pomp_vermogen	3300 W	export-drempel om de pomp te starten
zwembad_min_uren	4 u	dagelijks minimum runtime
zwembad_burst_min_minuten	30 min	minimale aaneengesloten draaitijd na start
airco_min_overschot	1000 W	extra export bovenop de pomp om airco te starten
airco_setpoint_zomer	23 °C	doel-temperatuur in koel-modus

De volledige tabel staat in de README van het project. Belangrijke ontwerpkeuze: de pompdrempel staat boven het nominaal pompvermogen zodat de pomp pas start als er écht surplus is. De for: 2 min-bewaking voorkomt dat een voorbij-trekkend wolkje de pomp doet hakkelen.

Stap 3: de zwembadlogica

In het zomer-window (09:00 tot 18:00) volgt de pomp dit ritme:

- alias: Pomp aan op surplus
  trigger:
    - platform: numeric_state
      entity_id: sensor.p1_export_power_w
      above: !input zwembad_pomp_vermogen
      for:
        minutes: !input zwembad_export_for_min
  condition:
    - condition: state
      entity_id: input_boolean.automatisatie_master
      state: "on"
    - condition: state
      entity_id: input_boolean.zomer_modus
      state: "on"
    - condition: state
      entity_id: input_select.zwembad_modus
      state: "auto"
  action:
    - service: switch.turn_on
      target:
        entity_id: switch.pool_pump_pump
    - service: timer.start
      target:
        entity_id: timer.zwembad_burst_lock

Wat hier gebeurt: zodra de export langer dan twee minuten boven 3300 W staat, gaat de pomp aan en start een burst-lock van 30 minuten. Tijdens die lock kan de pomp niet meer automatisch uitschakelen op import, ook als er even een wolk passeert. Dat voorkomt het irritante on-off-on-off-gedrag dat je krijgt als je puur op live waarden stuurt.

Verder hebben we een vangnet ingebouwd. Als om 16:00 de pomp nog geen 4 uur gedraaid heeft, wordt hij geforceerd aan tot het minimum bereikt is. Filtratie is een functioneel doel, geen “leuk om te hebben”-feature.

Stap 4: de aircologica met respect voor de buitenunit

De airco’s krijgen pas surplus als de pomp al voorzien is. Daarom rekent de trigger met extra overschot bovenop een lopende pomp:

- alias: Airco's aan bij dubbel surplus
  trigger:
    - platform: numeric_state
      entity_id: sensor.p1_export_power_w
      above: !input airco_min_overschot
      for:
        minutes: !input airco_overschot_for_min
  condition:
    - condition: state
      entity_id: input_select.airco_modus
      state: "auto"
  action:
    - choose:
        - conditions:
            - condition: state
              entity_id: input_boolean.zomer_modus
              state: "on"
          sequence:
            - service: climate.set_hvac_mode
              data: { hvac_mode: cool }
              target: { entity_id: [climate.living, climate.keuken] }
            - service: climate.set_temperature
              data: { temperature: !input airco_setpoint_zomer }
              target: { entity_id: [climate.living, climate.keuken] }
        - default:
            - service: climate.set_hvac_mode
              data: { hvac_mode: heat }
              target: { entity_id: [climate.living, climate.keuken] }

Beide units worden altijd samen aangestuurd, in dezelfde mode. Dat is geen luiheid, het is een hardware-randvoorwaarde: één buitenunit kan niet tegelijk een binnenunit koelen en een andere verwarmen. Wie dat toch wil (bv. één kamer warm houden in oktober) kan via airco_modus = handmatig aan zelf de Daikin-app gebruiken.

Stap 5: de manual override en kill-switch

In zo’n setup vinden we de uit-knop minstens zo belangrijk als de slimme logica zelf. Drie helpers maken dat sluitend:

• input_boolean.automatisatie_master is de globale kill-switch. Staat hij uit, dan vuren géén automatisaties. De gebruiker bedient pomp en airco dan gewoon zelf.
• input_select.zwembad_modus heeft drie standen: auto, handmatig aan of handmatig uit. In handmatig aan houdt de automation de pomp actief aan, ook als iemand hem via een andere weg uitschakelt.
• input_select.airco_modus werkt analoog aan de pomp.

Die “actieve handhaving” in handmatig-modus klinkt streng, maar voorkomt verwarring. Als de klant beslist dat de airco aan moet blijven, dan moet hij dat ook blijven. Wijzigingen via de Daikin-app worden dan teruggedraaid zolang de modus zo staat.

Wat er bewust niet in zit

We hebben enkele zaken doelbewust niet opgenomen:

• Geen comfort-deadline op de airco. Hij volgt puur de PV-curve. Op grijze winterdagen draait hij dus weinig of niet, en dat is exact de afspraak.
• Geen weersvoorspelling. Houdt de logica voorspelbaar en debugbaar.
• Geen aparte sturing van de zwembad-warmtepomp. Die werkt enkel als de filterpomp draait, dus de koppeling is impliciet.
• Geen koppeling met de Easee laadpaal. Die volgt zijn eigen schema.

Een feature niet bouwen is soms net zo waardevol als ze wel bouwen. Elke extra integratie is iets dat later kan breken of verkeerd geïnterpreteerd kan worden door de gebruiker.

Resultaat

Sinds de oplevering draait de zwembadpomp grotendeels op zonneoverschot in plaats van op het oude vaste schema. De airco’s pakken het surplus dat de pomp niet opvangt, en op zonnige zomerdagen blijft het huis daardoor aangenaam zonder dat er een kWh van het net komt. Op grijze dagen blijft het systeem stil, wat ook de bedoeling is.

De klant heeft alle drempels nu in handen via de UI en heeft er ondertussen al wat aan getuned (de export-drempel voor de pomp staat ondertussen lager dan onze default).

Wat we hieruit meenemen

Twee dingen die we ook in volgende projecten zo aanhouden:

• Een burst-lock voor zware verbruikers. PV-overschot is grillig op partly cloudy dagen. Een minimale aaneengesloten draaitijd voorkomt schakelschade en verwarring.
• Eerst de override, dan de slimheid. We bouwden de master-kill-switch en de modus-selectoren vóór we de eerste automation schreven. Dat dwingt je om je logica zo te ontwerpen dat ze altijd te bypassen is.

Wil je iets gelijkaardigs voor je eigen installatie? Neem contact op. We werken graag mee.