Wie du Home Assistant selbstheilend machst – Nie wieder "Gerät nicht verfügbar"

Automatisierung
, , ,
1

Wie du Home Assistant selbstheilend machst – Nie wieder „Gerät nicht verfügbar“!

Wir alle kennen das: Ein Gerät oder eine Entität in Home Assistant geht plötzlich auf „nicht verfügbar“. Das nervt, vor allem wenn es häufiger passiert. Aber keine Sorge, in diesem Beitrag zeige ich dir, wie du Home Assistant mit einer Selbstheilungsfunktion ausstattest. Nie wieder manuelles Neuladen! :tada:

Warum Selbstheilung?

In einem Smart Home gibt es viele Schnittstellen und Integrationen – und manchmal hängt sich etwas auf. Das passiert z.B. bei Bewegungsmeldern oder wenn eine Integration wie Shelly oder HACS kurzzeitig ausfällt. Statt ständig manuell nachzuladen, kannst du eine Automatisierung einrichten, die solche Probleme automatisch behebt.

Der Plan:

Wir richten eine Automatisierung ein, die erkennt, wenn eine Entität „nicht verfügbar“ ist. Sobald das passiert, wird die Integration neu geladen – und schon funktioniert alles wieder.

Schritt-für-Schritt-Anleitung zur Selbstheilung:

  1. Gehe zu Automatisierungen:

    • Einstellungen > Automatisierungen & Szenen > Automatisierung erstellen.

  2. Erstelle einen Auslöser:

    • Wähle „Entität“ aus.
    • Zustand: „nicht verfügbar“.
    • Beispiel: Bewegungsmelder in der Garderobe.

  3. Keine Bedingung notwendig:

    • Dieser Schritt kann übersprungen werden.

  4. Füge eine Aktion hinzu:

    • Aktionstyp: „Dienst ausführen“.
    • Dienst: homeassistant.reload_config_entry.
    • Wähle die betroffene Integration oder das Gerät aus.

  5. Speichern und Testen:

    • Speichere die Automatisierung und teste sie mit dem Button „Ausführen“.

Was passiert im Hintergrund?

Sobald ein Gerät „nicht verfügbar“ wird, triggert die Automatisierung den Neustart der entsprechenden Integration. Dadurch werden die betroffenen Geräte wieder geladen – alles ohne dein Zutun.

Erweiterte Anwendung: Selbstheilung für HACS und andere Integrationen

Diese Methode funktioniert nicht nur für Standard-Geräte wie Shelly, sondern auch für HACS-basierte Integrationen. Wenn sich z.B. eine Karte oder ein Sensor häufig aufhängt, kannst du denselben Prozess anwenden.

Fazit: Nie wieder Frust mit Home Assistant!

Mit dieser Selbstheilung wird dein Home Assistant noch smarter. Keine manuelle Intervention mehr, keine Ausfälle – einfach ein stabiles und zuverlässiges System. Schau dir unser Video an, um die Einrichtung im Detail zu sehen, und hinterlasse uns ein Like. Deine Automatisierung freut sich! :wink:

Hier der Link zum Video: https://youtu.be/gEgUd6T0Nvo

1
11280×720 118 KB

9 „Gefällt mir“
2

Interessante Ausführung. Das werde ich mal vertiefen.
Mehrmals musste ich beobachten, dass zB. ein oder beide Zigbee2MQTT Add-on nicht mehr laufen oder das Network UPS Tool für meine USV sich abgemeldet hat.
Das passiert sehr selten, aber 1x ist schon zu viel.
Warum das geschieht, weiß ich noch nicht, denn dafür gibt es ja den Watchdog in den Add-on.
In Node-Red habe ich dafür Flows erstellt, welche die Add-on gezielt überwachen und neu starten. Nebenbei gibt’s auch Meldungen dafür auf’s Handy.

1 „Gefällt mir“
3

Hmm, also ich würde bei diesem Vorgehen aber nicht unbedingt von einem stabilen, zuverlässigen System sprechen. Es wäre wesentlich besser das Problem ausfindig zu machen, welches zum „nicht verfügbar“ führt und dieses dann beseitigen. Außerdem ist bei deiner Idee immer zu bedenken, dass beim Neustart der jeweiligen Integration dann alle Geräte dieser Integration von einem kurzen Ausfall betroffen wären.

2 „Gefällt mir“
4

Das ist korrekt seb🙂,
aber wir dürfen nicht vergessen, dass Home Assistant kein kommerzielles System ist und somit auf die Entwicklung von fast nur freiwilligen Personen angewiesen ist.
Da können sich hier und da mal Fehler einschleichen :+1:

Da hilft es einfach sowas zu haben bis es stabil wird :sweat_smile:

2 „Gefällt mir“
5

Da hast du natürlich recht. Irgendwann werde ich herausfinden, warum sich diese Add-on trotz Watchdog abmelden.
Dazu muss ich sagen, in den letzten Wochen ist kein Ausfall mehr geschehen.
Aber es scheint ja garnicht so ungewöhnlich zu sein, das mal ein Add-on abschmiert. Sonst gäbe es den eingebauten Watchdog ja nicht, oder?

1 „Gefällt mir“
6

Obwohl HA kein kommerzielles System ist und hoffentlich dank der Foundation nie wird, bin ich aus meiner Erfahrung der Meinung, dass HA super läuft. Bei manchen kommerzielles Systemen, zB. aus der Automatisierungstechnik in der Industrie läuft längst nicht alles „rund“.
Und diese Systeme muss man zum Teil für viele T€ kaufen.

1 „Gefällt mir“
7

Wollte ja eigentlich nur sagen, dass eine gründliche Fehlersuche und Behebung in vielen Fällen die besser Wahl wäre. Natürlich ist der vorgeschlagene Weg auch gangbar.

3 „Gefällt mir“
8

@seb hat schon recht. Vorallem bei Zigbee Geräten, wenn da dann mqtt neu gestartet wird, sind direkt mal knapp 100 Geräte und mehr kurzzeitig nicht mehr verfügbar und bekommen auch einen falschen Status.

Jetzt mal weiter gedacht, könnte das nicht sogar auch in einer Endlosschleife landen? :thinking:

3 „Gefällt mir“
9

Eigentlich ist das Thema bei mir nicht so heiß, da es sehr selten passiert und in den letzten Wochen gar nicht mehr. Wenn es wieder geschieht, werde ich mich mal etwas intensiver mit den Protokollen beschäftigen. Evtl. hat ja irgendein Update das „Mini-Problem“ bei mir schon beseitigt und es passiert nie wieder.

@maxe Danke für Deinen Beitrag.
kannst Du mir bitte den Begriff „Endlosschleife“ in diesem Zusammenhang etwas näher erläutern?

1 „Gefällt mir“
10

Moin maxe - ja interessanter Gedanke, den man dabei auf jeden Fall nicht vergessen sollte. Ich würd auf jeden Fall einen Helfer benutzen und hochzählen lassen und bei 3 oder so mir ne Nachricht zukommen lassen. Auch ne kleine Pause bis die Entität zur Verfügung stehen „könnte“ wäre bestimmt nicht schlecht^^ Aber das Thema vergügbarkeit ist ein heikles Thema bis zur Hochverfügbarkeit und schon würden wir wieder bei sowas wie Proxmox landen oder mindestens 2x die gleiche Hardware, wobei da wieder ein Loadbalancer fehlen würde…

@Schorch - Endlosschleifen passieren, wenn man nur einen Zustand überprüft und keine Sicherungen einbaut. Hier ich starte immer wieder, weil die Entität nciht mehr verfügbar ist etc. Da gibt es halt soviel mehr zu beachten, dass es schon fast Kopfschmerzen machen kann :innocent: :sweat_smile:

lg, Jörg

2 „Gefällt mir“
11

Mein Gedanke war: du überwachst mehrere Zigbee Geräte. Eins ist nun „nicht verfügbar“. MQTT wird durch die Automatisierung neu gestartet. Dadurch verändert sich die Zusände aller anderen Zigbee Geräte auch. Evtl. bekommt dadurch ein anderes überwachtes Gerät den Zustand „nicht verfügbar“ und MQTT wird wieder neu gestartet (=Endlosschleife)

War aber nur ein theoretischer Gedanke von mir.

2 „Gefällt mir“
12

Evtl. habe ich mich unklar ausgedrückt, oder hier etwas falsch verstanden.
Es meldet sich bei mir nicht EIN Gerät ab, woraufhin ich MQTT neu starte und alle anderen Geräte für den Zeitraum mit in den Abgrund ziehe.

Es ist so, dass eines meiner Zigbee2MQTT Add-on selbsttätig stoppt und dadurch alle betroffenen Geräte an diesem Koordinator blind und taub werden.

Ich habe mehrere SMLIGHT SLZB-06 (ohne M) Koordinatoren im Einsatz, welche ich übrigens auf Jörg’s Inspiration in einem seiner YT-Videos für mich entdeckt habe.
@Smartrev Jörg, danke nochmal dafür!

1 „Gefällt mir“
13

Hallo,
das Video hatte ich mir bereits schon mal angeschaut.
Allerdings hatte ich die dort angesprochenen Problematiken (noch) nicht.

Ich habe dafür das Problem, dass - warum auch immer - die sogenannte Authentifizierung für meine FritzBox abgelaufen ist.

Fritz1
Fritz1796×255 22.2 KB

Das passiert manchmal lediglich alle Wochen mal, aber genauso kann das mehrfach täglich vorkommen. Ich muss dann Benutzer und Passwort (oft mehrfach hintereinander) eingeben, bis ich die Meldung bekomme, dass die Konfiguration wieder i.O. ist.

Eine Einschränkung o.ä. der Funktionalität konnte ich nicht feststellen, wenn die Authentifizierung abgelaufen ist und das System mit dieser „Reparaturmeldung“ weiter läuft, aber für irgendwas muss der korrekte Status ja nun mal gut sein…

Jetzt habe ich mal gesucht - eine Entität, die im Fehlerfall den Zustand ändert habe ich nicht gefunden und das Gerät selbst ist ja auch weiterhin verfügbar…

Wie komme ich da weiter, um diese lästige, wiederkehrende Authentifizierung automatisieren zu können?

Freue mich über Tipps und Hilfe, danke.

1 „Gefällt mir“
14

Komplett ausfallende Integrationen hatte ich bislang eher selten.
IPP (Drucker) ist immer dann nicht verfügbar, wenn der Drucker ausgeschaltet ist - also erwartbar.
Früher, als ich noch die Tuya-Integration genutzt habe, gab es mal Probleme mit nicht-Verfügbarkeiten, die hatte ich ähnlich wir oben beschrieben überwacht und dann die Intergration neu geladen.

Manchmal hab ich allerdings das Problem, dass ein Zigbbee-Gerät einen Befehl nicht bekommt, vermutlich ist mein Zigbee-Netz (>130 Geräte) manchmal ein bisschen „voll“, allen Optimierungsversuchen zum Trotz.
Und damit dann die Lampe (oder ähnliches) doch geschaltet wird, nutze ich die Integration Retry, die den Befehl solange schickt, bis er erfolgreich ist. Natürlich mit einer maximalen Anzahl von Versuchen und steigenden Wartezeiten zwischen den Versuchen.

1 „Gefällt mir“
15

Danke für den Bericht :slight_smile:
dieses Verhalten konnte ich während den Tests leider nicht feststellen.

Was ich nur einmal hatte bis jetzt war, dass ein Repeater nicht mehr verfügbar war in Home Assistant aber das lag nicht an diesem Video oder Methode.