Kennst du das? Eine Automation läuft seit Monaten absolut zuverlässig. Und plötzlich: Nichts. Zwei Nächte hintereinander feuert sie einfach nicht. Du schaust ins Logbuch: Kein Fehler. Du öffnest den Editor: Das Template leuchtet unschuldig grün, es gibt keine Warnung, alles sieht aus wie immer. Und trotzdem passiert – exakt gar nichts. Genau um diese fiesen, stillen Fehler geht es heute. Wir schauen uns nicht die komplexe Template-Logik an, sondern die unscheinbaren kleinen Fallen, in denen dein Code zwar syntaktisch fehlerfrei ist, dir aber trotzdem lautlos um die Ohren fliegt, sobald ein Sensor mal zickt.
Das dazugehörige Video mit allen Beispielen live in Home Assistant findest du hier:
Der Ausgangspunkt: Das trügerisch perfekte Template
Nehmen wir eine absolute Standard-Automation. Sie prüft alle 15 Minuten, ob die Außentemperatur unter 10 Grad liegt, und ballert dann die Heizung im Esszimmer auf gemütliche 21 Grad:
Du magst Home Assistant? Dann abonniere kostenlos meine Beiträge mit Tipps, Tricks und Anleitungen rund um Home Assistant:
Garantiert kein Spam, keine Werbung und immer mit Abmelde-Link, solltest du es dir anders überlegen!
automation:
- alias: "Heizung nach Außentemperatur"
trigger:
- platform: time_pattern
minutes: "/15"
condition:
- condition: template
value_template: >
{{ states('sensor.gw1100a_outdoor_temperature') | float < 10 }}
action:
- service: climate.set_temperature
target:
entity_id: climate.thermostat_esstisch
data:
temperature: 21
Wo ist der Haken? Nicht in der Logik. Der Haken ist die stillschweigende Hoffnung, dass sensor.gw1100a_outdoor_temperature immer brav eine Zahl liefert. Kurzer Realitätscheck: Willkommen im Smart Home! Sensoren hängen, das Zigbee-Netz hat Schluckauf (unavailable) oder Home Assistant wurde gerade neu gestartet und wartet noch auf den ersten Wert (unknown). Und genau in diesem Moment, wenn dein Template plötzlich versucht, mit einem Text statt einer Zahl zu rechnen, stirbt die Automation einen stillen Tod.
(Kurzer Hinweis am Rande: Die Automation oben ist absichtlich simpel gehalten. In der Praxis baust du deine Heizungssteuerung vermutlich etwas smarter. Aber hier geht es uns ja nackt um die Template-Fehler, ohne viel Rauschen drumherum.)
Der Türsteher: has_value
has_value ist dein wichtigstes Werkzeug für zuverlässige Templates. Es fungiert quasi als Türsteher und prüft, ob eine Entität überhaupt einen brauchbaren Wert hat, bevor der Code anfängt, damit zu jonglieren.
Ohne diese Absicherung sieht das Ganze so aus:
{# Ohne Absicherung – bricht bei "unavailable" gnadenlos ab #}
{{ states('sensor.gw1100a_outdoor_temperature') | float < 10 }}
{# Mit Absicherung über has_value #}
{% if has_value('sensor.gw1100a_outdoor_temperature') %}
{{ states('sensor.gw1100a_outdoor_temperature') | float < 10 }}
{% else %}
Sensor liefert aktuell keinen gültigen Wert
{% endif %}
Ist der Sensor unavailable, wirft die erste Zeile einen Fehler und die Automation bricht sofort ab. Die untere Variante checkt erst die Lage. Fehlt der Wert, springt das Template elegant in den else-Zweig. Das ist der feine Unterschied zwischen einer Automation, die blind auf die Technik vertraut, und einer, die auf Ausfälle vorbereitet ist.
(Die Entität sensor.gw1100a_outdoor_temperature stammt übrigens von meiner eigenen Ecowitt-Wetterstation. Beim Nachbauen setzt du hier natürlich einfach deinen eigenen Sensor ein!)
Das eingebaute Sicherheitsnetz: default
Mit default kannst du fast jeder Wertabfrage ein kleines Sicherheitsnetz verpassen. Statt das Template im Fehlerfall einfach crashen zu lassen, definierst du einen Fallback-Wert:
{# Ohne Fallback – Ergebnis ist "unavailable" und damit unbrauchbar #}
{{ states('sensor.gw1100a_humidity') | float }}
{# Mit Fallback über default #}
{{ states('sensor.gw1100a_humidity') | float(default=50) }}
Wenn der Sensor aussteigt, spuckt die obere Zeile einen Fehler aus. Die untere Variante liefert dank default=50 stattdessen stoisch die Zahl 50 zurück, mit der Home Assistant sauber weiterrechnen kann.
Ist das die perfekte Lösung? Natürlich nicht, ein erfundener Fallback-Wert ersetzt keine echte Messung. Aber die Automation läuft weiter! Welchen Fallback du wählst, hängt extrem vom Kontext ab. Bei Luftfeuchtigkeit sind 50 % ein neutraler Mittelwert. Bei anderen Sensoren wählst du vielleicht bewusst einen Wert, der dafür sorgt, dass die betroffene Automation in diesem Durchlauf einfach gar nichts macht.
Die Stolperfalle mit den Einheiten: float und int
Manche Geräte meinen es etwas zu gut mit uns und liefern ihre Werte nicht als nackte Zahl, sondern klatschen direkt noch die Einheit als Text hinten dran – zum Beispiel "23.5 °C" statt einfach 23.5. Wenn du versuchst, so einen String (also eine Zeichenkette) direkt in eine mathematische Rechnung zu werfen, knallt es unweigerlich:
{# Ohne Absicherung – String mit Einheit lässt sich nicht direkt umwandeln #}
{{ "23.5 °C" | float }}
{# Mit Absicherung über float(default=...) #}
{{ "23.5 °C" | float(default=0) }}
Die Kombination aus float(default=0) fängt den Crash zumindest ab. Klar, im echten Leben musst du den String vorher vermutlich noch bereinigen und die Einheit abschneiden, um an den echten Wert zu kommen. Aber der wichtige Takeaway hier: Das Problem ist in diesem Fall nicht, dass ein Wert fehlt (wie bei Punkt 1 und 2), sondern dass er im falschen Format vorliegt. Checkt also immer erst mal den rohen Sensorwert in den Entwicklerwerkzeugen, bevor ihr ihn blind in ein Template zimmert.
Der Listen-Filter: is_numer und select
Wenn du gleich mehrere Sensoren auf einmal durch den Code jagen willst, hast du vermutlich wenig Lust, für jeden einzelnen eine eigene has_value-Abfrage zu schreiben. Hier kommt is_number in Kombination mit dem select-Filter ins Spiel:
{# Ohne Absicherung #}
{% set werte = [
states('sensor.gw1100a_humidity'),
states('sensor.feuchtigkeitssensor_third_reality_soil_moisture'),
states('sensor.gw1100a_outdoor_temperature')
] %}
{{ werte | map('float') | list }}
{# Mit Absicherung über select und is_number #}
{% set werte = [
states('sensor.gw1100a_humidity'),
states('sensor.feuchtigkeitssensor_third_reality_soil_moisture'),
states('sensor.gw1100a_outdoor_temperature')
] %}
{{ werte | select('is_number') | map('float') | list }}
Was passiert hier? Wir sammeln zuerst die aktuellen Werte von drei Sensoren (Luftfeuchte, Bodenfeuchte, Außentemperatur) in einer Liste. Im ersten Block jagen wir gnadenlos ein map('float') über alle Einträge. Ist auch nur ein einziger Sensor gerade unavailable, bricht die komplette Umwandlung ab. Ergebnis: Nichts geht mehr. Im zweiten Block schalten wir select('is_number') dazwischen. Das filtert die Liste im Vorfeld: Es kommen nur die Werte durch, die wirklich eine gültige Zahl sind. Wenn jetzt der Bodensensor spinnt, geht nur dieser eine Wert verloren. Die anderen beiden kommen sicher durch und werden normal verarbeitet.
Fazit: Macht die Schutzschicht zur Gewohnheit
Das eigentliche Problem sitzt meistens gar nicht in der großen Logik unserer Automationen, sondern in genau dieser einen Lücke: Wir vergessen schlicht, was passiert, wenn die Technik mal für fünf Minuten nicht mitspielt. Gerade bei Batterie-Sensoren, die selten senden, oder bei wackeligen Funkstrecken ist das kein Ausnahmefall, sondern Alltag.
Gewöhnt euch einfach an, eine kleine Schutzschicht als Standard um eure Templates zu bauen. Bei jeder Entität kurz überlegen: Was passiert hier eigentlich, wenn das Ding gerade unavailable oder unknown ist? Ein kurzes has_value, ein schnelles default – das kostet beim Tippen drei Sekunden mehr, erspart euch aber die nervige Fehlersuche, wenn eine Automation plötzlich stumm bleibt, ohne dass irgendwo ein Hinweis auftaucht.
Dieser Beitrag ist übrigens der Auftakt zu einer kleinen Reihe über die typischen Stolpersteine und Besonderheiten bei Templates in Home Assistant. Da kommt also noch mehr!
Produktempfehlungen
