ESPAltherma Teil 3: Wärmepumpe steuern und im Dashboard überwachen

In Teil 1 und Teil 2 dieser Serie ging es um Hardware, Firmware und die reine Auslese-Seite von ESPAltherma. Damit ist die Diagnose-Ebene fertig – aber eine Wärmepumpe will im Alltag auch gesteuert werden, nicht nur beobachtet. In diesem letzten Teil zeige ich, wie die Steuerung bei mir tatsächlich abläuft (Cloud-Integration plus SG-Ready), und wie aus den ESPAltherma-Werten ein Dashboard wird, das mehr zeigt als nur „Wärmepumpe läuft“.

Steuerung im Alltag: Die Cloud-Integration übernimmt das Eingemachte

Wie in Teil 1 erklärt, kann ESPAltherma nicht steuern – dafür ist bei mir die offizielle Daikin-Cloud-Integration (Onecta) zuständig. Sie bringt unter anderem die Climate-Entity climate.altherma_leaving_water_offset mit, über die sich sowohl der Betriebsmodus (Heizen/Aus) als auch ein Vorlauftemperatur-Offset setzen lassen – letzteres nutze ich bereits ausführlich für PV-Überschuss-Automationen, die ich in einem eigenen Artikel im Detail beschrieben habe. Diese Automationen erhöhen bei ausreichendem PV-Überschuss (Einspeiseleistung, Akkustand und Solcast-Prognose werden dafür kombiniert geprüft) den Offset um +2 °C, um überschüssigen Strom in Heizwärme statt ins Netz zu stecken, und setzen ihn zurück, sobald der Überschuss wegbricht.

Eine zweite, bisher noch nicht veröffentlichte Automation nutzt dieselbe Climate-Entity für einen ganz anderen Zweck: die Vermeidung von unnötigem Kompressor-Takten in der Übergangszeit. Bei milden Außentemperaturen um die 12 °C neigt die Wärmepumpe dazu, ständig kurz an- und wieder abzuschalten, was auf Dauer den Verschleiß erhöht. Die Lösung: eine Automation, die anhand der Außentemperatur (aus der Onecta-Integration: sensor.altherma_climatecontrol_aussentemperatur) den Heizbetrieb komplett aus- statt nur zu drosseln:

alias: Heizung Übergangszeit – Außentemperatur-Schaltung
description: >
  Schaltet die Wärmepumpe automatisch nach Außentemperatur ein/aus,
  um häufiges Takten des Kompressors bei mildem Wetter zu vermeiden.
  EIN: Außentemp. unter 11°C für 30 Minuten.
  AUS: Außentemp. über 13°C für 30 Minuten.
  2°C Hysterese zwischen den Schwellen, damit die Anlage nicht bei
  Temperaturen um 12°C ständig ein-/ausschaltet.
triggers:
  - trigger: numeric_state
    entity_id: sensor.altherma_climatecontrol_aussentemperatur
    below: 11
    for: "00:30:00"
    id: kalt
  - trigger: numeric_state
    entity_id: sensor.altherma_climatecontrol_aussentemperatur
    above: 13
    for: "00:30:00"
    id: mild
conditions: []
actions:
  - choose:
      - conditions:
          - condition: trigger
            id: kalt
          - condition: state
            entity_id: climate.altherma_leaving_water_offset
            state: "off"
          - condition: state
            entity_id: binary_sensor.altherma_climatecontrol_urlaubsmodus
            state: "off"
        sequence:
          - action: climate.set_hvac_mode
            data:
              hvac_mode: heat
            target:
              entity_id: climate.altherma_leaving_water_offset
      - conditions:
          - condition: trigger
            id: mild
          - condition: state
            entity_id: climate.altherma_leaving_water_offset
            state: heat
        sequence:
          - action: climate.set_hvac_mode
            data:
              hvac_mode: "off"
            target:
              entity_id: climate.altherma_leaving_water_offset
mode: singleCode-Sprache: PHP (php)

Der wichtigste Kniff hier ist die 2 °C-Hysterese zwischen den beiden Schwellwerten (11 °C zum Einschalten, 13 °C zum Ausschalten): Ohne diesen Puffer würde die Automation bei einer Außentemperatur, die genau um einen einzigen Schwellwert pendelt, ständig zwischen Ein und Aus wechseln – exakt das Takten, das eigentlich vermieden werden soll. Die Schwellen selbst sind bei mir noch ein erster Startwert, den ich nach den ersten vollständigen Heiztagen im Herbst nachjustieren werde.

SG-Ready für den Warmwasser-Boost

Neben der Cloud-Integration nutze ich für die Warmwasserbereitung zusätzlich die SG-Ready-Kontakte der Wärmepumpe – ein einfaches, potentialfreies Signal, das die Wärmepumpe selbst auswertet, ganz ohne Umweg über Cloud oder ESPAltherma. Wie ich diese Kontakte per Shelly-Relais ansteuere und in eine PV-Überschuss-Logik einbinde, habe ich bereits in einem eigenen Artikel beschrieben. Der Grund, warum ich das bewusst getrennt von der Vorlauf-Offset-Automation halte: SG-Ready ist deutlich robuster gegenüber Cloud-Ausfällen, weil die Wärmepumpe das Signal direkt an der Hardware auswertet – ideal für die eher grobe, aber zuverlässige Extra-Portion Warmwasser bei PV-Überschuss.

Von mir für die SG-Ready-Ansteuerung verwendet: Shelly 1 bei Amazon ansehen*

* Affiliate-Link: Wenn du über einen entsprechend gekennzeichneten Link etwas kaufst, erhalte ich möglicherweise eine Provision. Für dich ändert sich der Preis dadurch nicht. Als Amazon-Partner verdiene ich an qualifizierten Verkäufen.

Das Dashboard: Aus Rohdaten wird Übersicht

Mit den in Teil 2 gebauten Template-Sensoren lässt sich jetzt ein Dashboard bauen, das deutlich mehr zeigt als der Standard-Thermostat-Karte der Cloud-Integration. Grundgerüst sind bei mir drei Kartentypen: History-Graphen für Temperaturverläufe, eine Automation samt Counter für die Taktrate, und Gauge-Karten für die Momentaufnahme.

Home Assistant selbst läuft bei mir auf einem Raspberry Pi 4*, auf dem die ESPAltherma-Daten, Cloud-Integration, SG-Ready-Automationen und das Dashboard zusammenlaufen.

Temperaturverläufe per History-Karte

Eine History-Graph-Karte mit den relevanten Temperatur-Template-Sensoren aus Teil 2 zeigt auf einen Blick, wie sich Vorlauf, Rücklauf und Kältekreis-Temperaturen über den Tag entwickeln:

type: history-graph
title: WP Temperaturen
hours_to_show: 24
entities:
  - entity: sensor.hp_inlet_water_temp
    name: Rücklauf
  - entity: sensor.hp_leaving_water_before_buh
    name: Vorlauf
  - entity: sensor.hp_delta_vorlauf_rucklauf
    name: Delta
  - entity: sensor.hp_heissgas_temp_2
    name: Heißgas
  - entity: sensor.hp_hochdruck_2
    name: HochdruckCode-Sprache: CSS (css)
Die History-Graph-Karte „WP Temperaturen“ im fertigen Dashboard

Besonders das Delta zwischen Vor- und Rücklauf ist ein guter Blick-Indikator: Ein ungewöhnlich kleines Delta über einen längeren Zeitraum kann auf ein Durchfluss- oder Hydraulikproblem hindeuten, noch bevor die Wärmepumpe selbst eine Fehlermeldung ausgibt.

Taktraten aufzeichnen: Kompressorstarts mitzählen

Eine der für mich aufschlussreichsten Kennzahlen ist die reine Anzahl der Kompressorstarts. Häufiges Takten (viele kurze Starts statt weniger, dafür längerer Laufzeiten) ist ein klassisches Anzeichen für eine überdimensionierte Wärmepumpe oder – wie oben beschrieben – für unnötiges Ein/Aus in der Übergangszeit. Dafür genügt ein einfacher counter-Helfer plus eine kleine Automation, die auf den Sprung der Inverter-Frequenz von 0 auf einen Wert größer 0 reagiert:

alias: WP Verdichterstart erfassen
description: >
  Erhöht den Taktungs-Zähler, wenn die Altherma-Verdichterfrequenz
  von 0 auf größer 0 springt (Kompressorstart)
triggers:
  - trigger: numeric_state
    entity_id: sensor.hp_inv_frequenz_2
    above: 0
actions:
  - action: counter.increment
    target:
      entity_id: counter.wp_starts_total
mode: singleCode-Sprache: CSS (css)

Der Trick an dieser Automation ist ihre Einfachheit: Sie braucht keine komplexe Zustandslogik, weil der numerische Trigger von Home Assistant selbst nur beim tatsächlichen Überschreiten der Schwelle (und nicht bei jedem Update des Sensors) auslöst. Den resultierenden Counter counter.wp_starts_total zeige ich auf dem Dashboard einfach als einfache Entity- oder Statistik-Karte an, wahlweise auch als Verlauf über die Zeit, um Trends über mehrere Wochen zu erkennen.

Die Taktungs-Karte mit Starts heute/gestern/7-Tage-Ø/Total

COP berechnen: Wie effizient arbeitet die Wärmepumpe gerade?

Der COP (Coefficient of Performance) beschreibt das Verhältnis von abgegebener Heizleistung zu aufgenommener elektrischer Leistung – ein COP von 4 bedeutet vereinfacht: aus 1 kWh Strom werden 4 kWh Wärme. Mit den vorhandenen Sensoren lässt sich daraus ein eigener Template-Sensor bauen, der Durchfluss, Temperaturdifferenz und Stromverbrauch kombiniert:

template:
  - sensor:
      - name: "WP COP aktuell"
        unique_id: wp_cop_aktuell
        unit_of_measurement: "COP"
        state: >
          {% set durchfluss = states('sensor.hp_durchfluss') | float(0) %}
          {% set delta = states('sensor.hp_delta_vorlauf_rucklauf') | float(0) %}
          {% set strom = states('sensor.altherma_climatecontrol_taglicher_stromverbrauch_heizung') | float(0) %}
          {% if strom > 0 %}
            {{ ((durchfluss * delta * 4.187) / strom) | round(2) }}
          {% else %}
            0
          {% endif %}Code-Sprache: JavaScript (javascript)

Die Konstante 4,187 ergibt sich aus der spezifischen Wärmekapazität von Wasser (in kJ pro kg und Kelvin) und dient dazu, aus Durchfluss und Temperaturdifferenz die tatsächlich abgegebene Heizleistung zu berechnen. Wichtig für die Interpretation: Ein so berechneter Momentan-COP schwankt naturgemäß stark, gerade während der Anlaufphase des Kompressors – aussagekräftiger wird der Wert, wenn man ihn über die Utility-Meter-Integration auf Tages- oder Wochenbasis mittelt statt den Momentanwert direkt zu betrachten.

COP Verlauf im Dashboard

Gauge-Karten für die Momentaufnahme

Für den schnellen Blick beim Betreten des Raums (in dem das Dashboard ohnehin meist auf einem Tablet läuft) reichen ein paar Gauge-Karten mit sinnvollen Wertebereichen – zum Beispiel die Heizleistung, Vorlauf und Rücklauf, die Stromaufnahme, die Temperatur des Wassertanks etc. Gauges eignen sich hier besser als reine Zahlenwerte, weil sich auf einen Blick erkennen lässt, ob ein Wert im „grünen Bereich“ liegt, ohne die konkreten Grenzwerte im Kopf haben zu müssen.

Das fertige Dashboard im Gesamtüberblick

Verknüpfung mit der Amortisations-Serie

Die hier gewonnenen Werte – allen voran der Stromverbrauch aus der Cloud-Integration und der selbstberechnete COP – lassen sich direkt in mein bestehendes Amortisations-Tracking für Wärmepumpe, PV und Akku einspeisen. Ein dauerhaft niedriger COP über mehrere Wochen wäre dort nicht nur ein technisches, sondern auch ein wirtschaftliches Warnsignal – die Amortisationsrechnung reagiert direkt auf einen höheren tatsächlichen Stromverbrauch pro erzeugter Wärmemenge.

Fazit der Serie

Über alle drei Teile hinweg zeigt sich ein Muster, das sich vermutlich auf viele Smart-Home-Projekte übertragen lässt: Die beste Lösung ist selten ein einzelnes, allmächtiges Tool, sondern die durchdachte Kombination mehrerer, jeweils auf ihre Stärke reduzierter Bausteine. ESPAltherma liefert die Tiefe, die Cloud-Integration die zuverlässige Alltagssteuerung, SG-Ready die robuste PV-Logik – und aus allen drei zusammen entsteht ein Dashboard, das zeigt, was eine Wärmepumpe wirklich tut, statt nur, dass sie läuft.

Schreibe einen Kommentar