Sonnenschutz mit Home Assistant: 12 Automationen gegen die Sommerhitze

von Patrick · · 7 Min. Lesezeit · Automation

Dieser Artikel enthält Affiliate-Links. Kaufst du darüber, bekomme ich eine kleine Provision – für dich ändert sich am Preis nichts. Mehr dazu


In einem früheren Artikel habe ich euch gezeigt, wie meine Rollladen morgens und abends nach Helligkeit fahren. Das ist die Grundsteuerung. Im Sommer hat mir das aber nicht gereicht: Wenn nachmittags die Sonne voll auf die Küchenfenster knallt, ist es egal, wie hell es draußen ist – entscheidend ist, ob die Sonne gerade in dieses Fenster scheint und ob es draußen überhaupt warm genug ist, dass sich Abdunkeln lohnt.

Daraus ist ein eigenes System geworden: zwölf Automationen, die nur für den Sonnen- und Hitzeschutz zuständig sind. Hier erzähle ich euch, wie das aufgebaut ist und an welchen Stellen ich mir anfangs selbst ein Bein gestellt habe.

Die Idee: Fassaden statt einzelner Fenster

Statt jedes Rollo einzeln zu behandeln, habe ich die Fenster nach Himmelsrichtung in vier Gruppen eingeteilt: Nordwest, Nordost, Südost und Südwest. Jede Gruppe bekommt einen Azimut-Bereich, also den Winkelbereich der Sonne, in dem sie tatsächlich auf diese Fassade scheint. Den Azimut liefert Home Assistant ohne zusätzliche Hardware über das Attribut azimuth der Entität sun.sun.

Grob sieht das bei mir so aus:

  • Nordwest (Bad, Abstellraum, ein Kinderzimmer, WC): Sonne zwischen etwa 230° und 340°
  • Nordost (das andere Kinderzimmer): etwa 0° bis 130°
  • Südost (Wohnzimmer, Balkon): etwa 80° bis 220°
  • Südwest (Küche): etwa 170° bis 310°

Die Bereiche überlappen sich bewusst ein Stück, weil die Sonne ein Fenster nicht erst trifft, wenn sie exakt senkrecht davorsteht. Die Werte habe ich nicht ausgerechnet, sondern ein paar Tage lang beobachtet und dann nachjustiert. Ein Kompass-App-Blick auf die Hauswand hilft beim Start enorm.

Zwei Fenster habe ich übrigens bewusst ausgenommen: die Terrassentür, weil da ständig jemand rein und raus will, und das Schlafzimmer. Dort war mir die Automatik unterm Strich zu viel – das Rollo bleibt smart, wird aber nur noch von Hand bzw. von der normalen Morgen-/Abend-Steuerung bewegt.

Zwei Stufen: Solar-Modus und Hitze-Modus

Die eigentliche Logik hat zwei Stufen.

Diagramm: Sonnenstand und Außentemperatur steuern Solar-Modus ab 25 Grad und Hitze-Modus ab 32 Grad; eine Manuell-Sperre pausiert die Automation für ein von Hand bewegtes Rollo. Die Logik hinter den zwölf Sonnenschutz-Automationen.

Solar-Modus ab 25 °C: Ist es draußen wärmer als 25 °C und steht die Sonne im Azimut-Bereich einer Gruppe, fahren deren Rollos auf 50 %. Nicht ganz zu – ich will ja nicht im Dunkeln sitzen – aber genug, um die direkte Einstrahlung zu brechen. Verlässt die Sonne den Bereich, fahren die Rollos wieder auf.

Hitze-Modus ab 32 °C: An richtig heißen Tagen reicht es nicht, nur die gerade besonnte Seite abzuschatten. Dann gehen alle automatisierten Rollos auf 50 %, egal wo die Sonne steht. Ein eigener Helfer (input_boolean) merkt sich, dass der Hitze-Modus aktiv ist. Solange er an ist, halten sich die Solar-Automationen raus, damit sich die beiden Modi nicht gegenseitig die Rollos wegziehen.

Daraus ergeben sich die zwölf Automationen: je vier zum Aktivieren und Deaktivieren des Solar-Modus (eine pro Fassade), je eine für Hitze an und aus, eine, die manuelle Eingriffe erkennt, und eine, die morgens alle Sperren zurücksetzt. Damit ich die zwölf nicht zwischen meinen anderen Automationen suchen muss, haben sie in Home Assistant alle das Label „Sonnenschutz“. Das ist ein kleines Detail, aber beim Debuggen Gold wert: Filter auf das Label, und man sieht alles auf einen Blick.

Hysterese: Der Fehler, den jeder einmal macht

In der ersten Version hat der Solar-Modus beim Unterschreiten von 25 °C sofort wieder aufgemacht. Klingt logisch, war in der Praxis aber furchtbar: An Tagen, an denen die Temperatur um 25 °C herumpendelte, fuhren die Rollos gefühlt alle paar Minuten rauf und runter.

Die Lösung heißt Hysterese. Aktiviert wird bei über 25 °C, deaktiviert aber erst bei unter 23 °C. Verlässt die Sonne dagegen den Azimut-Bereich, geht es sofort wieder auf, denn dann gibt es keinen Grund mehr zum Abschatten. Beim Hitze-Modus ist es genauso: an bei 32 °C, aus erst unter 30 °C und wenn die Sonne weg ist.

Ein vereinfachtes Beispiel für eine Fassade sieht so aus:

alias: "Sonnenschutz: SW-Fenster – Solar aktivieren"
triggers:
  - trigger: time_pattern
    minutes: "/5"
  - trigger: numeric_state
    entity_id: sensor.aussentemperatur
    above: 25
conditions:
  - condition: numeric_state
    entity_id: sensor.aussentemperatur
    above: 25
  - condition: state
    entity_id: sun.sun
    state: above_horizon
  - condition: numeric_state
    entity_id: sun.sun
    attribute: azimuth
    above: 170
    below: 310
  - condition: state
    entity_id: input_boolean.sonnenschutz_hitzeschutz_aktiv
    state: "off"
  - condition: state
    entity_id: input_boolean.sonnenschutz_kuche_manuell
    state: "off"
actions:
  - action: cover.set_cover_position
    target:
      entity_id: cover.rollo_kuche
    data:
      position: 50
mode: single

Der Zeit-Trigger alle fünf Minuten sorgt dafür, dass die Automation auch dann greift, wenn die Temperatur schon lange über 25 °C liegt und die Sonne erst später in den Azimut-Bereich wandert. Abends gibt es zusätzlich eine Sperre: Ab dem Abend fährt der Sonnenschutz gar nichts mehr, damit er sich nicht mit der normalen Abendsteuerung in die Quere kommt.

Home-Assistant-Automationsliste mit Suchbegriff Sonnenschutz: Hitzeschutz aktivieren (32 °C), Hitzeschutz deaktivieren (unter 30 °C), Manuell-Sperren zurücksetzen, Manuelle Öffnung erkennen und Solar-Aktivierung für das NE-Fenster

Die Manuell-Sperre: Respekt vor dem Menschen

Der wichtigste Teil jeder Rollo-Automation ist für mich nicht das Runterfahren, sondern das Nicht-Runterfahren. Wenn jemand im Wohnzimmer das Rollo bewusst hochgezogen hat, weil er rausschauen will, darf die Automation das nicht fünf Minuten später wieder zunichtemachen.

Deshalb hat jedes automatisierte Rollo einen eigenen Sperr-Helfer. Wird es manuell hochgefahren, geht die Sperre an und bleibt bis zum nächsten Morgen aktiv. Eine eigene Automation setzt alle Sperren morgens wieder zurück. Fährt jemand ein Rollo manuell weiter runter, ist das ohnehin kein Problem: Das Auto-Öffnen greift nur, wenn das Rollo noch ungefähr auf der Position steht, die die Automation selbst gesetzt hat (zwischen 40 und 60 %). Steht es tiefer, hat jemand es bewusst so gewollt, und es bleibt, wie es ist.

Knifflig war die Frage: Woran erkennt Home Assistant überhaupt, dass ein Mensch das Rollo bewegt hat? Meine erste Version hat das rein über die Position geraten: Wenn das Rollo von etwa 50 % auf über 60 % springt, war es wohl ein Mensch. Das ging öfter schief, als mir lieb war.

Inzwischen nutze ich den Kontext des Zustandswechsels. Jede Änderung in Home Assistant hat einen context:

  • Ist context.user_id gesetzt, kam der Befehl von einer Person, zum Beispiel über die App oder das Dashboard. Das ist eindeutig manuell.
  • Ist context.parent_id gesetzt, wurde die Änderung von einer Automation ausgelöst. Die ignoriere ich.
  • Ist beides leer, war es meist ein physischer Wandtaster. Nur in diesem Fall greift noch die alte Positions-Heuristik als Rückfallebene.

Seit dieser Umstellung stimmt die Erkennung deutlich besser. Ein Nebeneffekt, den ihr kennen solltet: Direkt nach der Umstellung standen bei mir noch ein paar Sperren aus der alten Logik auf „an“. Die habe ich nicht händisch zurückgesetzt, sondern einfach bis zum nächsten Morgen-Reset gewartet.

Kleine Stolperfallen aus der Praxis

Ein paar Dinge, die mich Zeit gekostet haben:

  • Helfer-Namen genau prüfen. Home Assistant leitet die Entity-ID beim Anlegen aus dem Anzeigenamen ab, nicht aus einer internen ID. Ich hatte in einem Setup-Skript eine falsche Entity-ID stehen und war zwischenzeitlich überzeugt, meine Automationen würden auf einen nicht existierenden Helfer zeigen. Am Ende war es genau umgekehrt – das Skript war falsch, nicht die Automationen.
  • Alte Automationen aufräumen. Ich hatte vorher schon einzelne Sonnenschutz-Regeln für Küche und Wohnzimmer. Die liefen parallel weiter und haben die neuen Automationen gestört, bis ich sie gelöscht habe.
  • Einen Temperatursensor draußen, nicht drinnen. Ich nutze die Außentemperatur meiner Ecowitt-Wetterstation. Mit der Innentemperatur würde der Schutz erst greifen, wenn es schon zu spät ist.

Wer noch keine smarten Rollladen hat: Man braucht dafür keine bestimmte Marke. Wichtig ist nur, dass der Aktor die Position in Prozent melden und anfahren kann. Ein Shelly 2PM Gen3 im Rollladenmodus kann das zum Beispiel auch.

Fazit

Der Sonnenschutz ist für mich die Automation, die im Sommer am meisten spürbaren Unterschied macht. Die Räume heizen sich deutlich weniger auf, und ich muss nicht mehr mittags durchs Haus laufen und Rollos runterlassen. Der Schlüssel war nicht die Grundidee „Sonne da, Rollo runter“, sondern die Details drumherum: Fassaden-Gruppen mit sauberem Azimut, eine Hysterese gegen das Flackern und eine Manuell-Erkennung, die den Menschen ernst nimmt. Wenn ihr das nachbauen wollt, fangt mit einer einzigen Fassade an und beobachtet ein paar sonnige Tage lang, bevor ihr den Rest ergänzt.

Die Geräte aus diesem Artikel

Ecowitt GW1100A Wetterstation mit 7-in-1-Außensensor
Mein Gerät

Ecowitt GW1100A Wetterstation mit 7-in-1-Außensensor

Liefert mir die Außentemperatur, auf der der komplette Sonnen- und Hitzeschutz aufbaut. Läuft lokal und ohne Cloud-Zwang.

Kommentare

Fragen, Ergänzungen oder eigene Erfahrungen? Ich freue mich über deinen Kommentar. Zum Kommentieren brauchst du ein kostenloses GitHub-Konto.

Beim Laden werden Daten an GitHub übertragen. Mehr dazu in der Datenschutzerklärung.