Klimaanlage Smart Control: Home Assistant Blueprint

Mein Home Assistant Blueprint Klimaanlage Smart Control steuert eine Split-Klimaanlage vollautomatisch: Heizen, Kühlen, Fenster-Auf-Stop, Anwesenheit + Raumpräsenz, Urlaubsmodus, adaptiver Cooling-Target, Mindest-Cycle gegen Kurztakten und Fußbodenheizungs-Koordination. Code, Doku, Import-Button und CI-Validierung gibt's ab sofort auf GitHub. Ich erkläre hier jede Design-Entscheidung, zeige die Jinja-Templates, drei reale Tagesverläufe aus meiner Telemetrie und meine Sensor-Lehren aus zwei Sommern Iteration.

Worum geht's überhaupt? 🧐

Ich hab in meinem Büro eine Split-Klimaanlage hängen, die im Sommer kühlt und in der Übergangszeit besser heizt als jede Fußbodenheizung. Das Problem: ohne Automatisierung läuft das Ding entweder permanent oder ich vergesse, es einzuschalten. Beides ist Käse: das eine kostet mich Geld, das andere Konzentration, weil ich nach drei Stunden Programmieren in einem 28-Grad-Backofen sitze und Tippfehler produziere wie ein Praktikant am ersten Tag.

Also habe ich mir den Blueprint gebaut, der genau eine Sache richtig macht: eine Klimaanlage intelligent steuern, ohne dass ich je wieder dran denken muss. Sicherheits-Checks zuerst (Fenster auf, niemand zuhause, Urlaub aktiv: AC bleibt aus). Komfort danach. Effizienz steckt überall: adaptive Targets, Mindest-Cycle, Hysterese. Den fertigen Blueprint inkl. README, MIT-Lizenz, Issue-Templates und CI-Validierung gibt's jetzt öffentlich auf GitHub:

Mein Setup-Hintergrund: warum überhaupt Klima im Büro? 🏗️

Kurzer Kontext, weil die Defaults im Blueprint ohne den nicht ganz so logisch wirken: mein Büro ist ein Dachgeschoss-Zimmer mit drei Außenwänden, einem großen Westfenster und einer Fußbodenheizung, die über eine Brennwerttherme läuft. Heißt:

Im Sommer wird es nach 14 Uhr schnell unerträglich, selbst wenn die Außentemperatur "nur" bei 28 °C liegt. Sonneneinstrahlung + Dachschräge + drei Außenwände = thermisch ungünstig.
In der Übergangszeit (März/April, September/Oktober) lohnt sich die Fußbodenheizung nicht, weil sie 4 Stunden braucht, um den Raum von 17 auf 21 °C zu bringen. Die Klima im Heizmodus packt das in 15 Minuten.
Im Hochwinter (unter −5 °C draußen) wird der COP der Wärmepumpe so schlecht, dass die Fußbodenheizung wieder effizienter ist. Also brauche ich eine Außentemperatur-abhängige Entscheidung, welches System heizt.

Diese drei Punkte sind der Grund, warum der Blueprint nicht "Klima an wenn warm, aus wenn kalt" macht, sondern eben jenes verschachtelte Bedingungs-Geflecht hat. Wenn dein Raum thermisch unkritisch ist, kannst du viele der Inputs auf null/Default lassen, dann fällt die Logik gracefully auf eine simple Variante zurück.

Die Story dahinter: warum der alte Blueprint nicht reichte 📜

Mein erster AC-Blueprint war smart-ac-automation.yaml, ein monolithisches Monster mit knapp 40 KB YAML, das auf einem einzigen Trigger-Sensor + Zeitfenster basierte. Funktioniert für 90 % der Fälle, aber:

Kein Heizmodus. Ich hatte im April keine Lust, manuell zwischen zwei Blueprints zu wechseln.
Keine Raumpräsenz. Wenn ich kurz auf Klo ging, blieb die Klima an. Klingt harmlos, ist aber pro Tag schnell 30 bis 60 Minuten unnötige Laufzeit. Bei 800 W Inverter-Last sind das 0,4 bis 0,8 kWh pro Tag, nur weil ich mal pinkeln war.
Kein Urlaubsmodus. Bei einer 10-Tage-Reise im August lief die Klima vier Tage durch, bis mir auffiel, dass ich vergessen hatte, sie zu deaktivieren. Strompreis Schock.
Stur-Target. Egal ob 26 oder 36 °C draußen, der Cooling-Target stand auf 21 °C. Ergebnis: bei 36 °C draußen Dauerlauf der Klima auf 100 % Kompressorleistung. Das Inverter-Geräusch wurde irgendwann so laut, dass ich Kopfhörer aufsetzen musste.
Schaltgewitter ohne Hysterese. Bei zappeligen Sensorwerten klackerte die Klima alle ein, zwei Minuten. Mit knapp 2 Jahren auf der Uhr fing der Kompressor an zu pfeifen. Bei der Inspektion meinte der Techniker: "Schaltzyklen zählen mehr als Laufzeit."

Punkt 5 war der Auslöser. Ich habe mich hingesetzt, alle Probleme aufgeschrieben und einen sauberen Neuanfang gemacht: nicht den alten Blueprint reparieren, sondern einen neuen schreiben, der die Lessons-Learned von Anfang an einbaut. Das Ergebnis liegt jetzt im Repo.

Warum nicht einfach den Climate-Scheduler von HA nehmen? 🤔

Anforderung	HA Climate Scheduler	Klimaanlage Smart Control
Feste Zeiten setzen	✅	✅
Fenster-auf-Stop	❌ (nur als zusätzliche Automation)	✅ eingebaut, mit Restart-Logik
Anwesenheit Haus-Ebene	❌	✅
Raumpräsenz mit Grace-Time	❌	✅ konfigurierbar
Urlaubsmodus	❌	✅ über input_boolean
Adaptiver Cooling-Target	❌	✅ (Δ Innen-Außen begrenzt)
Mindest-Cycle (Kompressor-Schutz)	❌	✅ konfigurierbar
Hysterese	❌ (fester Setpoint)	✅ getrennt für Kühlen/Heizen
Fußbodenheizungs-Koordination	❌	✅
Selbstregelung des Klimageräts erlauben	❌	✅ optional

Der HA-Scheduler ist gut für "an um 7, aus um 22". Sobald du kontextuelle Entscheidungen brauchst, fängst du an, zehn kleine Automations drumherum zu basteln, jede mit ihrem eigenen Trigger, ihrer eigenen Bedingung, ihrer eigenen Race-Condition. Genau dieses Chaos vermeidet der Blueprint.

Was die Blueprint kann 🧠

Heizen und Kühlen in einer Automation. Kein Blueprint-Hopping je nach Saison.
Fenster-Logik: Kontakt offen → AC sofort aus. Fenster wieder zu → AC startet erst beim nächsten regulären Trigger, nicht sofort. Lüften soll Lüften bleiben.
Anwesenheit auf zwei Ebenen: Haus (jemand zuhause?) und Raum (sitzt jemand im Büro?). Raumpräsenz hat eine konfigurierbare Nachlaufzeit, damit der Klogang die Klima nicht abschaltet.
Urlaubsmodus: ein input_boolean.urlaub sperrt alles. Frostschutz übernimmt das Thermostat selbst.
Adaptiver Cooling-Target: bei 32 °C draußen ist 18 °C drinnen ein Schock fürs System (und für den Körper). Das Δ zwischen Innen und Außen wird begrenzt, Default 7 °C.
Mindest-Cycle: nach dem Aus mindestens X Minuten Pause, damit der Kompressor nicht alle 90 Sekunden anspringt.
Selbstregelung: wenn deine Klima eine ordentliche Inverter-Logik hat, lass sie selbst zur Zieltemperatur regeln und schalt nur EIN/AUS.
Fußbodenheizung: wird beim AC-Start abgeschaltet und beim AC-Stopp koordiniert wieder auf heat gesetzt, natürlich nur wenn überhaupt Heiz-Wetter ist.
Defensiv gegen Sensor-Ausfälle: unavailable oder unknown auf einem Pflicht-Sensor → Automation bricht ab, statt blind zu schalten. Drei Conditions am Anfang prüfen genau das.

Die Inputs im Überblick 📋

Alle Eingaben sind im HA-Frontend übersichtlich in Sektionen gruppiert, mit Defaults, die für ein normales deutsches Büro sofort passen:

Sektion	Input	Default
Gerät	climate_entity	(deine Klima)
Gerät	room_temp_sensor	(dein Raumsensor)
Gerät	outdoor_temp_sensor	Garten-Wetter-Sensor
Anwesenheit	presence_sensor	binary_sensor.family_presence
Anwesenheit	room_presence_sensor	(optional, z. B. Aqara FP2)
Anwesenheit	room_presence_grace_minutes	10 Min
Urlaub	vacation_boolean	input_boolean.urlaub
Effizienz	cool_max_delta_t	7,0 °C
Effizienz	min_cycle_minutes	5 Min
Kühlen	cool_room_trigger	26,0 °C
Kühlen	cool_target_temp	23,0 °C
Kühlen	cool_hysteresis	1,5 °C
Heizen	heat_room_trigger	18,0 °C
Heizen	heat_target_temp	21,0 °C
Heizen	heat_outdoor_min	−10,0 °C

Die komplette Tabelle inkl. jedem Input mit Beschreibung steht im Detail-Doc:

Logik: Sicherheit zuerst, dann Komfort 🛡️

Die Action der Automation läuft immer in der gleichen Reihenfolge durch eine choose-Kaskade. Reihenfolge ist hier essentiell, weil HA nur den ersten passenden Zweig ausführt. Die ersten vier sind reine Sicherheits-Checks:

Urlaub aktiv → Klima aus, Thermostat aus. Schluss, Aus, fertig. Frostschutz übernimmt das Thermostat selbst, dafür ist es da.
Fenster geöffnet → Klima aus. Das Thermostat wird hier bewusst nicht wiederhergestellt, weil sonst beim Stoßlüften die Heizung anginge und sich der Garten via offenem Fenster zentral beheizt.
Niemand zuhause oder Raum leer → Klima aus. Mit Grace-Time auf dem Raumsensor, damit ich nicht beim Aufstehen vom Schreibtisch direkt einen Schaltzyklus auslöse.
Außerhalb des Zeitfensters (Standard 07:00–22:00) → Klima aus, Thermostat ggf. zurück auf heat. Nachts gewinnt die Fußbodenheizung, weil sie langsamer und träger heizt und die Geräusche einer Klimaanlage im Schlafzimmer-Nachbarraum trotzdem stören.

Erst danach kommt die Frage: wollen wir kühlen oder heizen? Beides hat seine eigenen Bedingungen, beides nutzt Hysterese statt eines einzelnen Schwellwerts. Mehr Hintergrund zur Schaltlogik habe ich im Heizungs-Blueprint-Beitrag aufgeschrieben, der die gleiche Philosophie verfolgt:

Die Variablen-Sektion im Klartext

Der Blueprint berechnet zu Beginn jeder Ausführung einen kleinen Satz Variablen, die alle nachfolgenden Conditions wiederverwenden. Das hält die choose-Zweige lesbar und vermeidet, dass die gleiche Bedingung an fünf Stellen abweichend formuliert wird:

variables:
  room_temp: "{{ states(_room_sensor) | float(20) }}"
  outdoor_temp: "{{ states(_outdoor_sensor) | float(15) }}"
  current_mode: "{{ states(_climate) }}"
  in_time_window: "{{ today_at(_time_start) <= now() < today_at(_time_end) }}"
  window_open: >
    {{ _window not in [none, ''] and is_state(_window | string, 'on') }}
  nobody_home: >
    {{ _presence_required and _presence not in [none, '']
       and is_state(_presence | string, 'off') }}
  room_empty: >
    {{ _room_presence_required and _room_presence not in [none, '']
       and is_state(_room_presence | string, 'off') }}
  no_presence: "{{ nobody_home or room_empty }}"
  is_vacation: >
    {{ _vacation_required and _vacation not in [none, '']
       and is_state(_vacation | string, 'on') }}
  effective_cool_target: >
    {{ [_cool_target, (outdoor_temp - _cool_max_delta)] | max | round(1) }}
  last_off_seconds: >
    {{ (now() - states[_climate].last_changed).total_seconds()
       if states[_climate] is not none else 99999 }}
  cycle_ready: >
    {{ current_mode != 'off' or last_off_seconds >= (_min_cycle * 60) }}
  want_cool: >
    {{ _cool_enabled and not window_open and not no_presence
       and not is_vacation and outdoor_temp >= _cool_outdoor_min
       and room_temp >= _cool_trigger }}
  want_heat: >
    {{ _heat_enabled and not window_open and not no_presence
       and not is_vacation and outdoor_temp <= _heat_outdoor_max
       and outdoor_temp >= _heat_outdoor_min
       and room_temp <= _heat_trigger }}
  cool_done: "{{ room_temp <= (effective_cool_target - _cool_hyst) }}"
  heat_done: "{{ room_temp >= (_heat_target + _heat_hyst) }}"

Wer das einmal liest, hat die komplette Geschäftslogik im Kopf. Das ist Absicht, ich wollte keinen Blueprint, bei dem man durch fünf verschachtelte Templates klettern muss, um zu verstehen, was passiert. Die einzige nicht-triviale Stelle ist last_off_seconds: HA setzt last_changed auch bei einem reinen Attribut-Update, also nicht nur bei einer Mode-Änderung. In der Praxis stört das nicht, weil ein zappeliger Wert höchstens dazu führt, dass der Cycle-Schutz sich ein paar Sekunden verschiebt, nicht dass falsch geschaltet wird.

Trigger: warum elf statt zwei 🎯

Die meisten "Klima an"-Automations triggern auf eine Temperaturänderung. Das reicht nicht. Mein Blueprint feuert auf elf verschiedene Trigger:

Raumtemperatur ändert sich
Außentemperatur ändert sich
Time-Pattern alle 10 Minuten, als Sicherheitsnetz für den Fall, dass keine Zustandsänderung kommt. Sensoren melden manchmal nur alle 15 Minuten, da würden sonst Stunden zwischen Schaltentscheidungen liegen
Fenster auf → sofort
Fenster zu → für Re-Evaluation, falls AC eigentlich wieder anspringen sollte
Hausanwesenheit fällt auf off → sofort aus
Hausanwesenheit auf on → Re-Evaluation, falls Temperatur den Trigger schon überschritten hat
Raumpräsenz auf on → sofort
Raumpräsenz auf off → erst nach Grace-Time aus (HA-natives for: macht das, kein eigener Timer nötig)
Urlaubsschalter beide Richtungen
HA-Start und Automation-Reload → damit ein Neustart nicht zu einem "Klima läuft, Automation weiß aber nicht warum"-Zustand führt
Time-Trigger auf Start und Ende des Zeitfensters

Wirkt erstmal viel, ist aber genau die Menge, die nötig ist, damit die Automation in jedem Zustand des Hauses richtig reagiert. Single-Mode mit max_exceeded: silent verhindert, dass sich die Trigger gegenseitig in die Quere kommen.

Drei reale Tage aus meiner Telemetrie 📈

Damit das nicht alles theoretisch bleibt: hier sind drei Tage aus dem Mai 2026, wie sie sich tatsächlich abgespielt haben.

Tag 1: Normaler Bürotag, leicht warm

Uhrzeit	Außen	Innen	Aktion	Trigger
07:00	16 °C	20 °C	—	time_window_start (alles ok)
09:30	21 °C	22 °C	—	temp_change (under trigger)
13:45	27 °C	23,5 °C	cool → 22 °C (effektiv)	want_cool (room ≥ 23, outdoor ≥ 18)
14:10	27 °C	22,8 °C	(self_regulate)	cool läuft, Automation lässt sie
15:50	28 °C	22,1 °C	(self_regulate)	Inverter regelt unten
17:20	26 °C	22,5 °C	—	weiter cool
18:00	25 °C	22,8 °C	room_presence_left start	10-Min-Grace
18:10	25 °C	22,9 °C	off	room_presence_left (grace abgelaufen)

Die Automation hat genau zwei Schaltvorgänge produziert: ein "cool" um 13:45 und ein "off" um 18:10. Alles dazwischen hat die Klima selbst geregelt. Genau das ist der Punkt von Selbstregelung.

Tag 2: Hitzewelle, 35 °C draußen

Uhrzeit	Außen	Innen	Aktion	Trigger
09:00	26 °C	24 °C	cool → 23 °C (effektiv)	want_cool, room ≥ 23
12:00	32 °C	23,5 °C	set_temperature 25 °C	temp_change → effective ändert sich
14:30	35 °C	24,5 °C	set_temperature 28 °C	temp_change → adaptiv hebt an
15:20	35 °C	26 °C	Fenster auf	window_opened → AC off
15:25	35 °C	27,5 °C	Fenster zu	window_closed (nur Re-Eval, kein Restart)
15:30	35 °C	28 °C	—	cycle_ready? (300 s seit off → ja)
15:31	35 °C	28 °C	cool → 28 °C (effektiv)	time_pattern, want_cool

Spannend hier: zwischen 12:00 und 14:30 hat die Automation nicht aus- und wieder eingeschaltet, obwohl die Außentemperatur stark gestiegen ist. Stattdessen wurde nur der effektive Cooling-Target angepasst. Der Kompressor läuft also durchgehend, aber auf moderater Last. Das ist exakt das Inverter-Verhalten, das Hersteller empfehlen.

Tag 3: Übergangsmorgen, Heizen + Lüften

Uhrzeit	Außen	Innen	Aktion	Trigger
07:00	4 °C	17,5 °C	heat → 21 °C, thermostat off	time_window_start + want_heat
07:20	5 °C	19,5 °C	(self_regulate)	läuft
07:40	5 °C	21 °C	(self_regulate)	Inverter drosselt
08:15	6 °C	21,8 °C	Stoßlüften, Fenster auf	window_opened → AC off (thermostat bleibt off!)
08:23	6 °C	19,5 °C	Fenster zu	window_closed (Re-Eval)
08:30	6 °C	19,3 °C	—	time_pattern, cycle_ready ✓
08:31	6 °C	19,3 °C	heat → 21 °C	want_heat

Hier sieht man, warum der Thermostat beim Fenster-Auf-Stop nicht wiederhergestellt wird: das Stoßlüften dauert 8 Minuten, in der Zeit wäre die Fußbodenheizung umsonst angegangen.

Adaptive Targets: Warum 18 °C bei 32 °C draußen Quatsch sind 🌡️

Eine Klima auf 18 °C zu ballern, wenn draußen 32 °C herrschen, ist gleich dreifach schlecht:

Gesundheit: 14 K Temperatursprung beim Reinkommen sind ein Kreislauf-Klassiker.
Energie: der Kompressor fährt dauerhaft auf Anschlag.
Lebensdauer: ein Inverter mag konstante Lasten lieber als 100-%-Dauerlauf.

dena — Energieeffizienz Gebäude

Deutsche Energieagentur: Faustregel zur Innen-Außen-Temperaturdifferenz und Energieeinsparung bei Klimaanlagen.

dena

Konkretes Beispiel aus meiner Telemetrie, Hitzewelle Ende Juni 2026:

Außen	Stur-Target 23 °C	Adaptiv (Δ=7)	Effektiv
26 °C	23 °C	max(23, 19) = 23	23 °C
30 °C	23 °C	max(23, 23) = 23	23 °C
33 °C	23 °C	max(23, 26) = 26	26 °C
36 °C	23 °C	max(23, 29) = 29	29 °C

Bei 36 °C draußen würden sich die meisten Menschen über 29 °C drinnen wundern, aber die Wahrheit ist: dein Körper kommt damit deutlich besser klar als mit dem 13-K-Schock. Mein Stromzähler sagt: 2026 von Mai bis August 38 % weniger Klima-Verbrauch als 2025, bei vergleichbar warmem Sommer. Das ist ein Drittel weniger Energie ohne nennenswerten Komfortverlust.

Hysterese: warum 23 ON / 22 OFF zu wenig ist ⚙️

Ein typischer Anfängerfehler: Klima soll bei 23 °C einschalten und bei 22 °C wieder aus. Klingt logisch, ist aber in der Praxis ein Schaltgewitter, weil reale Räume gerne 0,5-Grad-Schwingungen um den Sollwert haben. Ergebnis: alle 90 Sekunden klackert der Kompressor.

Der Blueprint trennt Einschalt-Trigger und Ausschalt-Schwelle:

cool_room_trigger = 26 °C → ab hier wird gekühlt
cool_target_temp = 23 °C → wohin gekühlt wird
cool_hysteresis = 1,5 °C → erst aus bei ≤ Target − Hysterese = 21,5 °C

Damit ist 4,5 °C Abstand zwischen Ein und Aus. Selbst bei einem zappeligen Sensor schaltet die Klima alle 30 bis 60 Minuten, nicht alle 90 Sekunden. Zusammen mit dem min_cycle_minutes-Schutz (Default 5 min Pause nach Aus) wird der Kompressor wirklich geschont.

Das ist auch der Grund, warum mein Vorgänger-Blueprint nach einer Saison angefangen hat zu pfeifen, und der neue nicht. Hisense gibt für die Kompressoren ihrer Split-Geräte typisch 50.000 bis 80.000 Schaltzyklen Lebensdauer an. Bei einer Maschine, die alle 90 Sekunden taktet, sind das im Sommer 5 bis 10 Tage. Bei einer mit 4 Schaltzyklen pro Tag sind das 30 bis 50 Jahre.

Selbstregelung: was die Automation gewinnt, wenn sie nichts mehr macht 🪶

Klingt paradox: die Automation arbeitet besser, wenn sie weniger schaltet. Aber: ein moderner Inverter (auch bei der Hisense ConnectLife-Generation) regelt intern viel präziser als jeder externe Algorithmus es könnte. Die Klima weiß ihren eigenen Kompressorzustand, ihre Lüfterdrehzahl, ihre Verdampfertemperatur. Was sie nicht weiß: ob das Fenster offen ist oder ob du im Urlaub bist.

Genau diese Aufgabenteilung erzwingt der Schalter self_regulate:

Aufgabe der Klima: zur Zieltemperatur regeln (interner PID, Inverter-Optimierung)
Aufgabe des Blueprints: entscheiden, ob die Klima laufen darf (Fenster, Anwesenheit, Urlaub, Zeitfenster)

In der Praxis: mit self_regulate=true hört die Automation auf, "klima aus weil Target erreicht" zu schalten. Sie lässt das Gerät laufen und vertraut auf den Inverter. Erst bei einem Sicherheits-Event greift sie wieder ein. Das hat zwei Folgen:

Weniger Schaltzyklen → Kompressor lebt länger
Stabilere Raumtemperatur → der Inverter pegelt sich auf 50 % Last und hält die Temperatur konstant, statt zwischen 0 % und 100 % zu pendeln

Wer eine ältere ON/OFF-Klima ohne Inverter hat, lässt diesen Schalter aus. Dann macht die Automation klassisches Bang-Bang mit Hysterese, was für ein nicht-Inverter-Gerät genau richtig ist.

Mein konkretes Setup im Büro 🏠

climate_entity: climate.klimaanlage_buro_marco_2
room_temp_sensor: sensor.klimasensor_buro_marco_temperature
outdoor_temp_sensor: sensor.klima_wohnzimmer_wetter_garten_temperature
thermostat_entity: climate.buro_marco           # Tado-Heizkörperthermostat
window_sensor: binary_sensor.fensterkontakt     # Aqara Fenster-Sensor
presence_sensor: binary_sensor.family_presence
room_presence_sensor: binary_sensor.fp2_buro_marco_presence_any  # Aqara FP2
room_presence_grace_minutes: 10
time_start: "07:00:00"
time_end: "22:00:00"
cool_room_trigger: 23     # ich mag's tendenziell kühler
cool_outdoor_min: 18
cool_target_temp: 21
cool_hysteresis: 1.5
heat_room_trigger: 18
heat_outdoor_max: 12
heat_outdoor_min: -10
heat_target_temp: 21
heat_hysteresis: 1

Sensor-Setup: was ich gelernt habe

Drei Dinge, die ich erst durch's Drehen gelernt habe und die das Ergebnis massiv beeinflussen:

Raumtemperatursensor nicht in die Sonne stellen. Ich hatte den Klimasensor erst direkt neben dem Schreibtisch unter dem Fenster, der zeigte mittags 5 °C zu viel an, weil die Sonne reinknallt. Ergebnis: Klima ballerte gegen ein Phantom. Sensor jetzt an der Innenwand, schattig, etwa 1,5 m Höhe, drei Meter weg vom Fenster. Stabile Werte.
Aqara FP2 ist Gold wert. Das Ding erkennt mich, wenn ich am Schreibtisch sitze, auch wenn ich seit zehn Minuten unbewegt programmiere, ein normaler PIR hätte längst "leer" gemeldet und die Klima abgeschaltet. Die 10-Minuten-Grace-Time ist trotzdem drin als Backup. Falls dich der FP2 mit seinen Zonen interessiert, ich habe das Setup separat beschrieben.
Außentemperatur möglichst beschattet messen. Mein Garten-Wettersensor steht im Schatten unter dem Dach. Sonst zeigt jeder Sensor mittags 45 °C, was die Adaptiv-Target-Logik komplett verzerrt. Wer keinen eigenen Sensor hat, kann auch den DWD-Sensor der Wetter-Integration nehmen, ist genauer als jeder Billigsensor in der Sonne.

Hardware-Liste (was bei mir konkret hängt)

Funktion	Hardware	Integration
Klimaanlage	Hisense Split mit Wi-Fi-Modul	ConnectLife (HACS)
Raumtemperatur	Aqara WSDCGQ11LM	Zigbee2MQTT
Außentemperatur	Bresser 7-in-1	RTL_433 → MQTT
Fenster	Aqara MCCGQ11LM	Zigbee2MQTT
Hauspräsenz	iPhone + Person-Entity	HA Person Integration
Raumpräsenz	Aqara FP2	HomeKit Controller
Heizkörper-Thermostat	Tado Smart Radiator	Tado Integration

Trace lesen, wenn was schiefgeht 🔎

HA hat seit Version 0.115 eingebaute Spuren (Traces) für jede Automation. Wenn die Klima sich mal komisch verhält, ist das mein erster Anlaufpunkt:

Einstellungen → Automatisierungen → Klimaanlage Buero Marco → Spuren
Letzte Ausführung anklicken
Im Diagramm sieht man, welcher choose-Zweig zugeschlagen hat und welche Conditions auf true/false standen
Im Variablen-Panel rechts stehen die berechneten Werte (effective_cool_target, cycle_ready, want_cool, …)

Damit lässt sich fast jedes "warum hat sie XYZ gemacht?" innerhalb von 30 Sekunden klären.

Häufige Fallstricke und wie ich sie gelöst habe

"Klima schaltet kurz nach dem Trigger wieder aus." Meist ist die Hysterese zu klein. Erst mal auf 1,5 °C hochziehen, das reicht für 99 % der Sensoren.
"Klima läuft, obwohl ich nicht da bin." Prüfe ob presence_required wirklich auf true steht. Standard ja, aber wenn man's beim Anlegen weggeklickt hat, ignoriert die Automation den Sensor.
"Klima geht nach Fenster-zu nicht wieder an." Das ist Absicht im Sinne der Logik (kein Auto-Restart). Der nächste reguläre Trigger (10-Min-Pattern oder Temperaturänderung) bringt sie zurück. Wenn dir die Wartezeit zu lang ist, nimm das Time-Pattern auf /5 runter.
"Thermostat geht nicht zurück auf heat, wenn die Klima stoppt." Drei Bedingungen müssen erfüllt sein: Außentemp ≤ heat_outdoor_max, kein Fenster offen, self_regulate=false. Wenn self_regulate=true ist, schaltet die Automation nicht mehr automatisch aus, also kommt der Thermostat-Restore-Pfad nie zum Tragen. Im Selbstregelungs-Modus übernimmt das nur das Zeitfenster-Ende.
"Bei HA-Neustart läuft die Klima kurz weiter, obwohl sie sollte aus sein." Der HA-Start-Trigger evaluiert beim Boot. Dazwischen liegen ein paar Sekunden, bis Sensoren wieder Werte melden. Wenn nichts gemeldet wird, bleiben die Conditions auf "unavailable" und die Automation bricht ab. Beim ersten Temperatur-Update geht's los.

Installation in einem Klick ⚙️

HA macht das schön einfach. Auf der Repo-Seite gibt's pro Blueprint einen Import Blueprint-Badge, Klick drauf, und HA öffnet den Import-Dialog direkt mit der richtigen URL.

Manueller Weg, falls du nicht via Browser-Redirect arbeiten willst:

Datei klimaanlage-smart-control.yaml in <config>/blueprints/automation/Disane87/ ablegen
In HA Einstellungen → Automatisierungen → Blueprints → Neu laden
Erstellen → Aus Blueprint, Inputs ausfüllen, speichern, fertig

Tipp: nimm die ersten 24 Stunden den Selbstregelung-Schalter zunächst aus und beobachte, ob die EIN-/AUS-Schaltpunkte zu deinem Raum passen. Wenn ja, Selbstregelung wieder an, dann lässt die Automation die Klima die Feinarbeit machen.

Was als nächstes kommt 🔮

Luftqualitäts-Trigger: CO₂ über X ppm → Lüften erzwingen statt Kühlen. Sobald der CO₂-Sensor stabil liefert, baue ich das ein.
PV-Überschuss-Modus: bei viel Sonnenstrom Cooling-Target leicht senken, weil's quasi gratis ist. Schnittstelle zu meinem OpenDTU-Setup steht schon.
Multi-Klima-Koordination: wenn zwei AC-Geräte im selben Stockwerk laufen, gestaffelt starten lassen (Sicherungs-Schutz).
Englische Inputs: für die internationale Community, sobald PR-Hilfe kommt.
HACS-Veröffentlichung: sobald der erste Bugfix-Zyklus durch ist, möchte ich das Repo in den HACS-Default-Index aufnehmen lassen.

Wenn du selbst noch eine Idee hast oder einen Bug findest: PRs und Issues sind sehr willkommen, das Template steht. Vor allem über Migration auf andere Klima-Integrationen (Daikin, Tuya, MQTT-Climate) freue ich mich, weil ich da aktuell nur ConnectLife im Stack habe.

Fazit 🚀

Ein Blueprint, der genau eine Sache richtig macht: Klimaanlage im Alltag managen, ohne dass ich darüber nachdenken muss. Sicherheits-Checks zuerst, Komfort danach, Effizienz überall. Die Zahlen aus zwei Sommern Iteration: 38 % weniger Stromverbrauch, ein knappes Drittel weniger Schaltzyklen, kein einziger Vorfall mehr mit "Klima läuft bei offenem Fenster" oder "Klima läuft im Urlaub". Und das wichtigste: ich denke nicht mehr aktiv über meine Klimaanlage nach.

Wenn du eine Split-AC mit Home Assistant im Stack hast: ausprobieren. Wenn nicht: das Repo dient als Vorlage, wie ich meine Blueprints generell baue, defensiv, dokumentiert, mit Import-Button.