Hallo zusammen,
ausgelöst hat das der Thread Smart Plug auf Stromausfall prüfen. Der ist inzwischen gelöst — ich war mit meiner Zusammenfassung schlicht zu spät. Weil die Frage aber regelmäßig wiederkommt und die Antwort ziemlich verstreut ist, stelle ich sie hier trotzdem hin: sortiert, mit fertigen Automationen zum Einsetzen, für den Nächsten, der danach sucht.
Herstellerneutral — Zigbee2MQTT, ZHA, Matter, Z-Wave, Shelly, Tasmota. Überall dort, wo es eine Leistungs- oder Temperatur-Entität gibt.
Drei Fragen, nicht eine
„Hat mein Gefrierschrank noch Strom?“ klingt nach einer Frage, sind aber drei. Wer sie vermischt, dreht sich im Kreis:
| Frage | Antwort |
|---|---|
| Ist mein Essen noch kalt? | Ebene 1 — Temperatursensor im Gerät |
| Ist der Zwischenstecker tot? | Ebene 2 — Herzschlag-Überwachung |
| Ist er per Funk erreichbar? | Ebene 3 — Verfügbarkeit |
Fast alle fangen bei Ebene 3 an, weil „Gerät nicht verfügbar“ nach der offensichtlichen Antwort klingt. Sie ist aber die langsamste, die am meisten Konfiguration braucht — und die einzige der drei, die überhaupt nichts darüber aussagt, ob das Essen auftaut.
Ein toter Zwischenstecker kann seinen eigenen Ausfall nicht melden.
Alles, was du über ihn erfährst, erfährst du daraus, dass er schweigt — und Schweigen ist ein langsames, mehrdeutiges Signal. Ein batteriebetriebener Temperatursensor im Gerät redet dagegen weiter, auch bei totalem Stromausfall.
Ebene 1 — Temperatur (die verlässlichste)
Ein Batterie-Temperatursensor für ein paar Euro in die Truhe legen. Er ist die einzige Ebene, die gleichzeitig
- einen kompletten Hausstromausfall überlebt (Batterie),
- einen defekten Kompressor bemerkt (Strom liegt an, gekühlt wird trotzdem nicht),
- einen offen stehenden Deckel verrät,
- und die Frage beantwortet, um die es eigentlich geht.
Die Temperatur zeigt dabei, dass etwas nicht stimmt, nicht was. Ein defekter Kompressor und ein offen stehender Deckel sehen im Verlauf ähnlich aus — wer die Ursache automatisch unterscheiden will, braucht dafür zusätzliche Sensoren, etwa am Türkontakt. Für die Frage „muss ich jetzt hin?“ reicht das Symptom.
Laufende Kosten, die gern übersehen werden: Kälte drückt die Batteriespannung, und ein Funkprotokoll, das eine Verbindung hält, verbraucht deutlich mehr als eines, das nur in Intervallen sendet. In der Truhe kommt beides zusammen — weiter unten im Thread wird von 50 % Restkapazität nach drei Tagen berichtet. Deutlich sparsamer sind BLE-Fühler, die nur Advertising-Pakete senden (die „Flower Care“-Bauart aus dem Pflanzenbereich); bei mir halten die CR2032-Zellen darin mehrere Monate im Kühlschrank. Der Empfänger steht dann außerhalb des Geräts — Shellys ab Gen3 können BLE-Sensoren direkt einsammeln und weiterreichen, ein ESP32 mit Tasmota oder ESPHome genauso. Nebeneffekt: kein Kabel durch die Türdichtung.
Zwei Fallen: Erstens das Vorzeichen — du willst gewarnt werden, wenn es zu warm wird, also above. Zweitens die Wartezeit: ohne for: bekommst du bei jedem Abtauzyklus und jedem Türöffnen einen Fehlalarm. Und Warnungen, die zu oft grundlos kommen, werden irgendwann weggewischt.
alias: 🧊 Gefriertruhe zu warm
description: >
Meldet, wenn die Temperatur 30 Minuten lang über -15 °C liegt.
Die 30 Minuten überbrücken Abtauzyklen und Türöffnen.
triggers:
- trigger: numeric_state
entity_id: sensor.gefriertruhe_temperatur # ← anpassen
above: -15
for:
minutes: 30
conditions: []
actions:
- action: notify.mobile_app_DEIN_HANDY # ← anpassen
data:
title: 🧊 Gefriertruhe wird warm
message: >-
Seit 30 Minuten über -15 °C, aktuell
{{ states('sensor.gefriertruhe_temperatur') }} °C.
Strom, Deckel und Gerät prüfen.
data:
ttl: 0
priority: high
mode: single
Für den Kühlschrank dasselbe mit above: 10.
Und die Entwarnung gleich mit — ohne sie weißt du aus dem Urlaub nie, ob es sich erledigt hat
alias: 🧊 Gefriertruhe wieder kalt
triggers:
- trigger: numeric_state
entity_id: sensor.gefriertruhe_temperatur
below: -17
for:
minutes: 15
conditions: []
actions:
- action: notify.mobile_app_DEIN_HANDY
data:
title: ✅ Gefriertruhe wieder kalt
message: >-
Aktuell {{ states('sensor.gefriertruhe_temperatur') }} °C.
mode: single
Ebene 2 — Herzschlag (schnell, sagt dir das Warum)
Hier scheitern die meisten Versuche, und zwar aus einem konkreten Grund: ein toter Stecker verrät sich auf zwei Arten, und die üblichen Rezepte fangen immer nur eine davon.
| Was passiert | Übliches Rezept | Warum es klemmt |
|---|---|---|
Er wird irgendwann unavailable |
Trigger auf unavailable |
Kommt erst nach dem Timeout des Funksystems — oft viel später als erwartet (siehe Ebene 3) |
| Oder er sendet einfach nichts mehr | „Wert hat sich X Minuten nicht geändert“ | Fehlalarm, sobald ein Gerät im Leerlauf wirklich konstant bleibt |
Sauberer ist last_reported: der Zeitstempel der letzten Meldung, unabhängig davon, ob sich der Wert dabei geändert hat. Damit fragt man direkt „wann habe ich zuletzt etwas gehört?“, statt es aus dem Wert zu erraten.
Der Vorlagen-Helfer fasst beide Ausfallarten zu einem Signal zusammen:
Einstellungen → Geräte & Dienste → Helfer → Anlegen → Vorlage → Template für einen binären Sensor
Name:Gefriertruhe Stecker stumm· Geräteklasse:problem
{% set s = states.sensor.gefriertruhe_leistung %}
{{ s is none
or s.state in ['unavailable', 'unknown']
or (now() - s.last_reported).total_seconds() > 900 }}
900 Sekunden sind 15 Minuten; bei einem Gerät, das selten sendet, entsprechend höher. Der Helfer rechnet sich von selbst jede Minute neu, weil now() darin vorkommt. Die Automation dazu ist dann trivial — Trigger auf to: "on".
Ebene 3 — Verfügbarkeit (und warum sie scheinbar nie auslöst)
Wenn du auf unavailable triggerst und nichts passiert, ist meistens nicht die Automation schuld, sondern die Wartezeit:
| Gerätetyp in Zigbee2MQTT | Standard-Timeout | heißt im Alltag |
|---|---|---|
| aktiv (netzbetrieben) | 10 min | vertretbar |
| passiv (Batterie) | 1500 min | 25 Stunden |
Wird ein Zwischenstecker fälschlich als passiv geführt, wartest du einen ganzen Tag auf die Meldung — und hältst deine Automation völlig zu Recht für kaputt.
# Zigbee2MQTT · configuration.yaml
availability:
enabled: true
active:
timeout: 10 # Minuten, netzbetrieben
passive:
timeout: 1500 # Minuten, Batterie
# pro Gerät übersteuerbar:
devices:
'0x00124b00xxxxxxxx':
friendly_name: Gefriertruhe
availability:
timeout: 5
Ebene 2 braucht das übrigens gar nicht — last_reported funktioniert unabhängig von dieser Einstellung.
Dashboard
Die Sammelwarnung erscheint nur, wenn tatsächlich etwas nicht stimmt. Ein Dashboard, auf dem im Regelfall nichts blinkt, wird auch gelesen.
Karte zum Einsetzen (Rohkonfigurationseditor)
type: vertical-stack
cards:
- type: conditional
conditions:
- condition: or
conditions:
- condition: numeric_state
entity: sensor.gefriertruhe_temperatur
above: -15
- condition: state
entity: binary_sensor.gefriertruhe_stecker_stumm
state: 'on'
card:
type: markdown
content: >
# ⚠️ Gefriertruhe prüfen
Temperatur: {{ states('sensor.gefriertruhe_temperatur') }} °C ·
Leistung: {{ states('sensor.gefriertruhe_leistung') }} W
- type: entities
title: Gefriertruhe
entities:
- entity: sensor.gefriertruhe_temperatur
name: Temperatur
- entity: sensor.gefriertruhe_leistung
name: Leistung
secondary_info: last-changed
- entity: binary_sensor.gefriertruhe_stecker_stumm
name: Stecker stumm
- type: history-graph
hours_to_show: 48
entities:
- sensor.gefriertruhe_temperatur
Der Wert, der hier am meisten leistet, ist die Zeile „zuletzt gemeldet vor“ — dafür reicht secondary_info: last-changed.
Wenn du nur eine Sache umsetzt
- Nimm Ebene 1. Ein Batterie-Temperatursensor kostet wenig, misst das, worum es wirklich geht, und funktioniert unabhängig von Funkprotokoll, Hersteller und Stromnetz. Das ist eine Entscheidung für Verlässlichkeit, nicht für Tempo: bei geschlossener Truhe steigt die Temperatur langsam, dort meldet Ebene 2 früher. Ebene 1 meldet dafür auch den Fall, in dem Strom und Netz völlig in Ordnung sind und trotzdem nicht mehr gekühlt wird — den meldet sonst keine Ebene. Wer beides will, kombiniert 1 und 2.
- Setze
for:auf mindestens 30 Minuten. Fehlalarme sind der schnellste Weg, eine Warnung wertlos zu machen. - Baue die Entwarnung mit ein.
- Prüfe, an wen die Benachrichtigung geht. Eine Warnung auf einem Handy im Flugmodus hilft niemandem.
Voraussetzungen und Grenzen
Braucht Home Assistant 2024.8 oder neuer wegen last_reported. Alle Entitätsnamen in den Beispielen sind Platzhalter und müssen angepasst werden.
Ehrlich zur Reichweite: keine dieser Ebenen ersetzt eine USV. Fällt der Strom im ganzen Haus aus, ist auch Home Assistant weg und verschickt gar nichts mehr — dann meldet sich Ebene 1 erst, wenn alles wieder läuft. Für den Fall, um den es hier geht (ein FI oder eine Sicherung für einen Teilbereich fliegt raus, der Stecker wird versehentlich gezogen, das Gerät gibt auf), reicht es.
Danke
Die Bausteine stammen größtenteils aus dem verlinkten Thread — @Osorkon für den Ansatz über die ausbleibende Leistungsänderung, @Baxxy für die konkreten Z2M-Timeout-Werte, und @UweGausO, der mit dem Temperatursensor in der Truhe nebenbei die beste Antwort selbst gefunden hat. Ich habe das nur sortiert und an einer Stelle (last_reported) etwas robuster gemacht.
