Raumklima: Taupunkt, Entfeuchter, Luftreiniger und ein Windfang

Der Raumfühler im Gästezimmer meldete 21,0 °C, das Ventil am Heizkörper 20,8 °C. Der Zwischenstecker in der Zimmerecke meldete 18,5 °C. In dieser Ecke droht Schimmel, deshalb hängt dort eine kleine Flächenheizung, und ihr Stecker hat einen eigenen Temperaturfühler. Bis dahin hatten wir die Ecke geschätzt. Ab da konnten wir sie messen.

Taupunktabstand statt Luftfeuchte

Die relative Feuchte allein sagt wenig: 60 % bei 22 °C sind harmlos, 60 % bei 16 °C nicht. Brauchbar ist der Taupunktabstand, also Temperatur minus Taupunkt. Er sagt, wie viel kälter eine Fläche als die Luft sein darf, bevor sie beschlägt.

Der SNZB-02P im Gästezimmer liefert keinen Taupunkt, deshalb rechnet ihn ein Template-Sensor nach der Magnus-Formel. Beim Einbau ergaben 21,6 °C bei 51 % einen Taupunkt von 11,0 °C, also 10,6 K Abstand.

Die Lüftungsmeldung binary_sensor.gastezimmer_luften schlägt unter 5 K an, bei 21 °C etwa ab 72 % Feuchte. Das ist eine Vorwarnung, denn unter 3 K beschlägt praktisch jede Außenwand. delay_on und delay_off stehen auf 30 Minuten: Eine offene Tür soll nicht melden, und nach dem Lüften soll die Meldung nicht zurückkommen, nur weil die Feuchte kurz zurückschwingt.

Die Meldung sagt „hier wird es eng“, nicht „Lüften hilft“. Das hinge an der absoluten Feuchte draußen, und diesen Vergleich haben wir nicht gebaut. Dass ein steiler Fall des Taupunkts ein offenes Fenster verrät, steht in Teil 2.

17 Watt Schimmelschutz in der Ecke

Die Flächenheizung hängt an einem FRITZ!Smart Energy 200 und hatte bis zum 12.09. keine Steuerung. Sie ist ein Schutz, keine Heizung. Gesteuert wird nach dem Taupunktabstand, nicht nach der Außentemperatur: Zwei Tage mit 2 °C draußen sind völlig verschieden, wenn drinnen einmal 45 % und einmal 70 % Feuchte herrschen.

Nachts abzuschalten wäre die schlechteste Wahl. Dann ist die Wand am kältesten, die Raumheizung senkt auf 16 °C ab, und kühlere Luft bei gleicher absoluter Feuchte heißt kleinerer Abstand. Gemessen: nachts 8,4 bis 8,6 K, tagsüber 8,9 K.

Die erste Fassung steuerte nach dem Raumfühler und zog für die Ecke geschätzte 3 bis 5 K ab, die Schwelle lag bei 7 K. Noch am selben Tag fiel auf, dass der Stecker selbst in der kritischen Ecke sitzt:

Über drei Tage lag die Ecke im Mittel bei 20,0 °C, der Raum bei 22,3 °C. Das sind rund 2,5 K, nicht 3 bis 5. Seitdem rechnet der Sensor mit dem Taupunkt der Raumluft und der Temperatur der Ecke:

- name: "Gästezimmer Ecke Taupunktabstand"
  state: >-
    {% set roh  = states('sensor.schalter_gastezimmer_temperatur') %}
    {% set raum = states('sensor.klima_gastezimmer_temperature') %}
    {% set tp   = states('sensor.klima_gastezimmer_taupunkt') %}
    {% if tp in ['unknown', 'unavailable'] %}
    {% elif roh not in ['unknown', 'unavailable'] %}
      {{ ((roh | float) - (tp | float)) | round(1) }}
    {% elif raum not in ['unknown', 'unavailable'] %}
      {{ ((raum | float) - 2.5 - (tp | float)) | round(1) }}
    {% endif %}
  # ...
- name: "Gästezimmer Flächenheizung Bedarf"
  state: >-
    {% set abstand = states('sensor.gastezimmer_ecke_taupunktabstand') | float(99) %}
    {% set ein     = states('input_number.gastezimmer_flachenheizung_schwelle') | float(4) %}
    {% set laeuft  = this.state == 'on' %}
    {{ abstand < (ein + 1.5) if laeuft else abstand < ein }}
  # ...

Unter 4,0 K an, über 5,5 K aus. Die Schwelle sank von 7 auf 4 K, weil der Abschlag jetzt im Messwert steckt. Zwei Grad sind für den Unterschied zwischen Eckenluft und Wandoberfläche gedacht, zwei sind Reserve. Fällt der Stecker aus, rechnet der Sensor mit Raumwert minus 2,5 K weiter. Fehlen beide Quellen, bleibt die Steckdose unberührt.

Anders als bei den Heizkörpern wird hier durchgesetzt. Ein time_pattern löst alle 30 Minuten aus und stellt den Sollzustand wieder her. Am Ventil ist ein Handgriff eine Komfortentscheidung, die bis zum nächsten Schaltpunkt gilt (Teil 3). Wer hier den Schimmelschutz abschaltet, hat ihn nach spätestens einer halben Stunde zurück.

Geprüft haben wir mit drei Schwellen gegen 8,2 K Eckenabstand. Bei 10,0 zog die Heizung an. Bei 7,0 hielt sie, weil für die laufende Heizung 7,0 + 1,5 = 8,5 galt. Bei 4,0 fiel sie ab. Sie zieht 17 W, im Dauerbetrieb wären das rechnerisch rund 35 kWh im Winter.

Offen ist zweierlei. Der Stecker misst Luft, nicht die Wand; das würde ein Infrarot-Thermometer für etwa 15 Euro klären. Und die laufende Heizung wärmt den Fühler im Stecker mit. Springt die Ecke beim ersten echten Lauf binnen Minuten um mehrere Grad, muss die Hysterese größer werden.

Der Entfeuchter in der Küche

In der Küche misst ein SNZB-02B. Kriterium ist hier die relative Feuchte, weil es um Kochdampf geht und nicht um eine kalte Wand. Der Bedarfsmelder ist nach demselben Muster wie oben gebaut: an über 65 %, aus unter 60 %.

Zuerst hing der Entfeuchter an einer Tapo P110, die Home Assistant nicht schalten kann. Den Umweg über die Matter-Brücke und zwei Alexa-Routinen haben wir gebaut und eine knappe halbe Stunde später zurückgenommen (mehr in Teil 8). Jetzt steckt er an einer Zigbee-Steckdose SONOFF S60ZBTPF.

Die erste Frage war, ob er nach einem Stromausfall von selbst anläuft oder auf einen Tastendruck wartet. Die Leistungsmessung beantwortete das: 180 Sekunden lang 8,5 W für Lüfter und Elektronik, ab etwa 200 Sekunden rund 165 W. Nach seiner eingebauten Anlaufsperre lief der Kompressor also von allein.

Die Automation setzt den Bedarf um und setzt ihn durch:

- id: kuche_entfeuchter
  # ...
  triggers:
    - trigger: state
      entity_id: binary_sensor.kuche_entfeuchter_bedarf
      to: ["on", "off"]
    - trigger: time_pattern
      minutes: "/30"
    - trigger: homeassistant
      event: start
  conditions:
    - condition: template
      value_template: >-
        {{ states('binary_sensor.kuche_entfeuchter_bedarf') in ['on', 'off']
           and states('switch.entfeuchter_kuche') not in ['unknown', 'unavailable']
           and states('binary_sensor.kuche_entfeuchter_bedarf')
               != states('switch.entfeuchter_kuche') }}
  actions:
    - action: "switch.turn_{{ states('binary_sensor.kuche_entfeuchter_bedarf') }}"
      target:
        entity_id: switch.entfeuchter_kuche

Ist der Bedarfsmelder nicht verfügbar, wird nichts geschaltet. Ob ein Handgriff bis zum nächsten Bedarfswechsel halten sollte, haben wir besprochen und verworfen. Die Feuchteregel entscheidet allein:

19:47:21   an     an der Steckdosentaste
19:51      168 W  Kompressor läuft
20:00:00   aus    Küche Entfeuchter nach Bedarf (Feuchte 60,8 % < 65 %)

Die Leistung verrät noch mehr. binary_sensor.kuche_entfeuchter_steht wird wahr, wenn die Steckdose an ist und weniger als 50 W fließen. Das delay_on von zehn Minuten überbrückt die Anlaufsperre. Meist ist dann der Tank voll, und die Meldung erscheint in Home Assistant und auf dem Fernseher. Das funktioniert nur, wenn der eigene Feuchteregler des Geräts nicht vor unserem aufhört, deshalb steht es auf Dauerbetrieb. Live geprüft ist die Meldung noch nicht.

Zwei Luftreiniger, eine Nacht

Die beiden Levoit-Luftreiniger in Schlafzimmer und Gästezimmer sind eine Ausnahme von der lokalen Linie. Sie hängen über die VeSync-Integration an der Levoit-Cloud, und die Integration kennt nur eine Voreinstellung: sleep.

Dem Haushalt fiel auf, dass das Schlafzimmergerät einem alten Plan folgte. Es schaltete sich um 20:00:51 selbst ein, auf Stufe 66 % statt im Schlafmodus, ohne Auslöser in Home Assistant. Der Plan lag in der Hersteller-App. Beim Gästezimmergerät zeigte der Verlauf zweimal täglich ein Tauziehen: Die App schaltete ein, unsere damalige Pausenautomation sofort wieder aus, vier Runden im Minutentakt. Der App-Zeitplan ist gelöscht, damit nur eine Stelle steuert.

Jetzt laufen beide von 19:00 bis 05:00. Die Zeiten stehen in zwei schedule-Helfern mit je zwei Blöcken (00–05 und 19–24), weil ein Zeitplan nicht über Mitternacht laufen kann. Die Automation luftreiniger_nachts bedient beide über eine Geräteliste und setzt den Schlafmodus fünf Sekunden nach dem Einschalten, weil er sich erst dann schreiben lässt.

Hier wird nicht durchgesetzt. Wer nachts ausschaltet, weil das Gerät stört, darf das, am nächsten Abend kommt es zurück. Dafür wird jeder Befehl geprüft: repeat … until mit bis zu drei Versuchen, dazwischen ein wait_template von einer Minute auf den neuen Zustand. Das ist keine Vorsicht auf Vorrat:

21:00:00   ein   unser Befehl
21:00:31   aus   Gerät meldet aus
21:01:31   ein   zweiter Versuch, sitzt
05:00:00   aus   unser Befehl
05:00:42   an    Gerät meldet an
05:02:42   aus   zweiter Versuch, sitzt

In der Probe mit beiden Geräten brauchten beim Ausschalten wieder beide den zweiten Versuch.

Beginnt eine Abwesenheit, gehen beide aus, und zur Nachtzeit bleibt der Einschaltbefehl aus. Endet sie am Tag, schaltet die Rückkehr ein Gerät nur ein, wenn sein Zeitplan gerade läuft. Sonst holt es die Nachtautomatik um 19 Uhr. Die Abwesenheit selbst steht in Teil 4.

Beide Geräte hatten 0 % Filter gezeigt, was auch fehlende Daten sein konnten. Nach dem Neuladen der Integration blieb es im Schlafzimmer bei 0 %, der Filter war wirklich verbraucht. Inzwischen sind beide gewechselt und am Gerät zurückgesetzt, die Sensoren melden 100 %. Zehn statt vierundzwanzig Stunden am Tag schonen die Filter, ersetzen den Wechsel aber nicht.

Der Windfang: 105 Watt Infrarot

Der Windfang ist ein eigener Raum, in Home Assistant der Bereich „Eingang“. Die Infrarotheizung dort hängt seit dem 23.09. an einer zweiten S60ZBTPF und zieht etwa 105 W, beim Warmwerden fallend (107,9 auf 103,9 W in zwei Minuten). Die Luft heizt das kaum, schon gar nicht bei offener Tür. Man spürt die Wärme aber sofort dort, wo man steht.

Vorher hatte ein SNZB-02B nur mitgemessen:

Kein Kondensatrisiko, derzeit kein Heizbedarf, es ist eine Winterfunktion. Der Haushalt wählte Wärme bei Anwesenheit, dazu Taupunkt-Schutz. Eine Mindesttemperatur zu halten haben wir verworfen: Mit 105 W liefe der Strahler im Winter stundenlang, ohne dass sich die Luft spürbar ändert.

Der Bewegungsmelder hängt innen im Windfang. Aus den Namen ließ sich das nicht ableiten, denn die Pflanze „Eingang“ zum Beispiel steht draußen. Claude fragte nach, der Haushalt bestätigte.

Zwei Melder mit je einer Aufgabe und eigener Hysterese, dazu binary_sensor.eingang_heizung_bedarf, der beide mit or zusammenfasst:

- name: "Eingang Wärme bei Anwesenheit"
  state: >-
    {% set t     = states('sensor.klima_eingang_temperature') | float(99) %}
    {% set unter = states('input_number.eingang_heizen_unter') | float(18) %}
    {% set nach  = states('input_number.eingang_heizung_nachlauf') | float(10) %}
    {% set bew   = states.binary_sensor.bewegungsmelder_3_occupancy %}
    {% set da = bew is not none and (bew.state == 'on'
                or (bew.state == 'off'
                    and (now() - bew.last_changed).total_seconds() < nach * 60)) %}
    {% set grenze = unter + (1 if this.state == 'on' else 0) %}
    {{ da and t < grenze }}
# ... "Eingang Taupunkt-Schutz": an unter 5 K, aus über 6,5 K

Weil die Vorlage now() enthält, rechnet Home Assistant sie jede Minute neu, und der Nachlauf läuft sauber aus. Der Sammelmelder trägt ein Merkmal grund mit „anwesenheit“, „taupunkt“, beidem oder „keiner“, damit der Verlauf zeigt, warum der Strahler lief. Die Automation setzt den Bedarf alle 30 Minuten in beide Richtungen durch. Anders als beim Entfeuchter geht der Strahler aus, wenn der Raumfühler fehlt. Ist der Bedarf einer Heizung unbekannt, ist aus die sichere Richtung.

Die 5 K Taupunktschwelle sind geschätzt. Der Fühler misst die Luft an der Innenwand gegenüber der Tür, gefährdet ist aber die kalte Außentür. Kalibrieren können wir erst im Winter.

Met.no: Die Höhe muss stimmen

Bis zum 20.09. hatte das Haus keine Außentemperatur. Jetzt liefert die eingebaute Met.no-Integration weather.forecast_zuhause, und zwei Template-Sensoren ziehen temperature und humidity als eigene Messreihen heraus. Das ist eine Vorhersage für den Ort, keine Messung an der Hauswand, und ein Cloud-Anteil. Wer die Werte nutzt, braucht einen Rückfall für unavailable.

Beim Einrichten stand die Höhe auf 0 m, und Claude notierte das als offenen Punkt. Der Haushalt meinte, Met.no nehme ohnehin die nächste Wetterstation, deren Höhe stecke also schon drin. Das klang vernünftig, stimmte aber nicht. Met.no ist ein gerechnetes Gittermodell, und die Integration schickt die Höhe immer mit, damit der Dienst dorthin umrechnet:

# components/met/coordinator.py
elevation = self._config[CONF_ELEVATION]
coordinates = {"lat": ..., "lon": ..., "msl": str(elevation)}

Also haben wir gemessen, am selben Ort in derselben Minute, nur mit anderer Höhenangabe. Mit 0 m lag die Temperatur gut fünf Grad höher als mit der tatsächlichen Höhe des Hauses, einige hundert Meter über dem Meer. Feuchte und Luftdruck (auf Meereshöhe umgerechnet) waren in beiden Abfragen gleich. Die genauen Werte lassen wir weg, aus ihnen ließe sich die Höhe zurückrechnen.

Die falsche Höhe wurde also nicht ignoriert, sie hat den Wert kräftig verfälscht. Die Integration kann die Höhe nachträglich nicht ändern, also haben wir den Eintrag gelöscht und neu angelegt und die Höhe auch in den allgemeinen Einstellungen korrigiert. Die Entitäts-ID blieb erhalten, die Template-Sensoren liefen ohne Änderung weiter.

Welcher Fühler wohin

Der Ort zählt so viel wie das Modell. Über dem Heizkörper fällt die relative Feuchte zu niedrig aus und verdeckt das Problem. Sonne, Fensternische, Vorhang, Außenwand und geschlossenes Regal verfälschen ebenfalls. Die Meldeschwellen stehen in Teil 5.

Was wir mitnehmen

• Den Taupunktabstand an der kältesten Stelle messen. Manchmal steckt dort schon ein Zwischenstecker mit Temperaturfühler. Unsere Ecke lag 2,5 K unter dem Raum.
• Schutz durchsetzen, Komfort nur schalten. Flächenheizung, Entfeuchter und Windfang korrigieren alle 30 Minuten. Die Luftreiniger schalten nur an ihren Wechselpunkten, damit ein Handgriff hält.
• Leistung ist Zustand. 8,5 W gegen 165 W zeigen, ob der Kompressor läuft, ob das Gerät nach Stromausfall anläuft und ob der Tank voll ist.
• Cloud-Befehle prüfen und wiederholen, und nur eine Stelle steuern lassen. Zeitpläne in Hersteller-Apps gehören gelöscht.
• Bei Met.no die Höhe eintragen. Mit 0 m lag unsere Außentemperatur gut fünf Grad zu hoch.