Stromausfall im Urlaub: Was er mir über mein Home-Assistant-Setup beigebracht hat

Es gibt diesen Moment, in dem man aus dem Urlaub zurückkommt, die Haustür aufmacht und merkt: Irgendwas stimmt nicht. Bei uns war es die Stille: Keine Automation reagierte, die App fand Home Assistant nicht, und auch sonst tat das Haus nichts von dem, was es normalerweise von allein erledigt.

Die Ursache war schnell gefunden: Während wir weg waren, wurden an der Straße Wartungsarbeiten erledigt und der Strom für 3 Stunden abgestellt. Der Server ist danach zwar wieder hochgefahren – aber Home Assistant nicht. Damit war im Grunde das ganze Smart Home tot, und ich hatte es aus der Ferne nicht mitbekommen.

Das war ärgerlich, aber auch lehrreich. Hier ist, was ich daraus gelernt und seitdem geändert habe.

Fehler 1: Die VM startet nicht von selbst

Home Assistant läuft bei mir als Home Assistant OS in einer virtuellen Maschine auf meinem Heimserver. Das hat viele Vorteile, auf die ich in einem eigenen Artikel eingehe. Einen Nachteil habe ich an diesem Tag aber schmerzhaft gelernt: Eine VM startet nach einem Neustart des Hosts nicht automatisch, nur weil sie vorher lief.

Die Lösung ist ein einziger Befehl:

virsh autostart homeassistant

Damit merkt sich der Server, dass diese VM beim Hochfahren des Hosts automatisch gestartet werden soll. Ob das aktiv ist, seht ihr mit virsh dominfo homeassistant in der Zeile „Autostart“. Klingt trivial – und genau deshalb hatte ich es nie eingestellt. Beim Einrichten hatte ich die VM immer von Hand gestartet, und der Server lief danach einfach monatelang durch.

Fehler 2: Niemand merkt, wenn es klemmt

Der Autostart allein hätte mir nicht gereicht. Was, wenn die VM zwar startet, Home Assistant darin aber hängt? Oder wenn der Start aus einem anderen Grund scheitert? Das Schlimmste an dem Ausfall war nicht der Ausfall selbst, sondern dass ich nichts davon wusste.

Deshalb gibt es jetzt einen kleinen Watchdog. Das ist ein Shell-Skript, das als systemd-Dienst beim Booten des Servers startet. Es wartet zunächst 30 Sekunden, damit alles in Ruhe hochfahren kann, und prüft dann bis zu fünf Minuten lang, ob die Weboberfläche von Home Assistant antwortet. Klappt das nicht, schaut das Skript nach, ob die VM überhaupt läuft. Ist sie aus, startet es sie. Läuft sie, antwortet aber nicht, bekomme ich eine dringende Nachricht, dass ich selbst nachsehen muss. In jedem Fall landet eine Push-Nachricht auf meinem Handy – auch wenn alles gut gegangen ist.

Stark vereinfacht sieht die Logik so aus:

#!/bin/bash
sleep 30
for i in $(seq 1 30); do
  if curl -sf "$HA_URL" > /dev/null; then
    curl -d "Home Assistant ist nach dem Neustart erreichbar" "$NTFY_URL"
    exit 0
  fi
  sleep 10
done
if [ "$(virsh domstate homeassistant)" != "running" ]; then
  virsh start homeassistant
  curl -d "HA-VM lief nicht und wurde gestartet" "$NTFY_URL"
else
  curl -H "Priority: urgent" -d "VM läuft, HA antwortet nicht" "$NTFY_URL"
fi

Für die Push-Nachrichten nutze ich ntfy, das bei mir selbst gehostet läuft. Die App gibt es für Android und iOS, und eine Nachricht verschickt man mit einem simplen HTTP-Aufruf. Das Schöne daran: Der Watchdog hängt nicht von Home Assistant ab. Genau das ist wichtig – die Benachrichtigung, dass Home Assistant nicht läuft, kann ja schlecht von Home Assistant selbst kommen.

Seitdem bekomme ich nach jedem Neustart des Servers eine kurze Nachricht. Kommt die falsche oder gar keine, weiß ich, dass ich mich kümmern muss.

Fehler 3: Netzwerk-Stolperfallen beim Booten

Beim Durchgehen des Bootvorgangs sind mir noch ein paar Dinge aufgefallen, die im normalen Betrieb nie auffallen, nach einem Kaltstart aber Ärger machen.

Der Server wartet auf ein Netzwerk, das es nicht gibt. Mein Server hängt über eine Netzwerkbrücke im LAN, damit die VM eine eigene Adresse im Heimnetz bekommt. Der Dienst systemd-networkd-wait-online wartet beim Booten standardmäßig darauf, dass alle Schnittstellen online sind. Bei einer Bridge-Konfiguration mit zusätzlichen virtuellen Schnittstellen kann das ewig dauern oder in einen Timeout laufen. Abhilfe schafft ein Override, das nur auf die Bridge wartet:

[Service]
ExecStart=
ExecStart=/usr/lib/systemd/systemd-networkd-wait-online --interface=br0:routable

Das legt ihr mit sudo systemctl edit systemd-networkd-wait-online.service an. Den Namen der Bridge müsst ihr natürlich an euer System anpassen.

Dienste streiten sich um denselben Port. Ein anderer Dienst auf dem Server wollte beim Start einen Port belegen, den nach dem Neustart schon das VPN für sich beansprucht hatte. Im laufenden Betrieb war das nie aufgefallen, weil die Startreihenfolge zufällig immer gepasst hatte. Die Lösung war, den Dienst nur noch an die LAN-Adresse zu binden statt an alle Schnittstellen.

Kaputte Pfade in systemd-Diensten. Zwei meiner kleinen Hilfsdienste starteten nicht mehr, weil ich die Skripte beim Aufräumen der Ordnerstruktur verschoben, die systemd-Units aber nicht angepasst hatte. Solange der Dienst lief, merkte man davon nichts – erst beim nächsten Boot.

Bei der Gelegenheit habe ich auch gleich alte Reste entfernt: Bevor Home Assistant in die VM umgezogen ist, lief es bei mir in Docker. Container und Images davon lagen noch herum und hätten im schlimmsten Fall parallel gestartet.

Der nächste Schritt: eine USV

Die Fixes sorgen dafür, dass nach einem Stromausfall alles wieder von selbst hochkommt. Noch besser wäre, wenn der Server einen kurzen Ausfall gar nicht erst mitbekommt. Deshalb plane ich eine kleine USV, zum Beispiel die APC Back-UPS BX750MI-GR. Für kurze Unterbrechungen von Sekunden bis wenigen Minuten ist so ein Gerät genau gedacht.

Bevor ich eine USV kaufe, will ich aber wissen, was dranhängen soll und wie viel Leistung das zieht. Dafür messe ich den Verbrauch der Geräte, die später an der USV hängen sollen, mit einem Shelly Plug S Gen3, der den Verbrauch direkt in Home Assistant liefert. Aus der gemessenen Leistung und der Kapazität der USV lässt sich grob abschätzen, wie lange der Akku durchhält. Wichtig dabei: Die VA-Angabe auf der Verpackung ist nicht die Wattzahl, und die realistische Laufzeit steht meist in einer Tabelle im Datenblatt des Herstellers.

Mindestens genauso wichtig wie die USV selbst ist, dass der Server bei längeren Ausfällen sauber herunterfährt, bevor der Akku leer ist. Dafür ist Network UPS Tools (NUT) das Mittel der Wahl, und Home Assistant hat eine fertige NUT-Integration. Damit lässt sich zum Beispiel eine Benachrichtigung schicken, sobald die USV auf Batterie umschaltet.

Was ihr aus meinem Fehler mitnehmen könnt

• Prüft den Autostart eurer VMs und Container. Bei Docker heißt das Stichwort restart: unless-stopped, bei libvirt virsh autostart.
• Baut eine Benachrichtigung, die unabhängig von Home Assistant ist. Sonst erfahrt ihr von einem Ausfall erst, wenn ihr davorsteht.
• Testet einen Kaltstart bewusst. Einfach mal den Server herunterfahren, Stecker ziehen, wieder einstecken und schauen, was passiert. Lieber an einem ruhigen Sonntag als während des Urlaubs.
• Denkt an eine USV, wenn euer Smart Home wirklich wichtige Dinge steuert.

Fazit

Der Stromausfall hat mir gezeigt, dass mein Setup im Alltag zwar gut lief, aber nie darauf ausgelegt war, sich nach einem Problem selbst zu erholen. Die Fixes waren am Ende überschaubar: ein Autostart-Befehl, ein kleines Watchdog-Skript, ein paar Korrekturen an systemd. Aber genau diese Kleinigkeiten entscheiden, ob euer Smart Home nach einem Ausfall einfach weiterläuft oder tagelang stillsteht. Die USV kommt als Nächstes.