ESP32-C3 als Server-Watchdog: Überwachung, Wake-on-LAN und automatische Wiederherstellung

Wie ich meinen Debian-Heimserver mit einem eigenständigen Mikrocontroller überwache, warum der Watchdog direkt an der FRITZ!Box hängt und welche Grenzen Wake-on-LAN nach einem Stromausfall hat.

Ein selbst gehosteter Server übernimmt im Alltag viele Aufgaben. Bei mir laufen darauf unter anderem Nextcloud, verschiedene Docker-Dienste, DNS-Funktionen und Monitoring. Solange alles funktioniert, ist das unauffällig. Fällt jedoch der gesamte Server aus, sind auch die darauf betriebenen Überwachungsdienste möglicherweise nicht mehr erreichbar.

Deshalb habe ich eine zusätzliche, einfache Überwachung außerhalb des Servers aufgebaut: einen Watchdog auf Basis eines ESP32-C3. Der Mikrocontroller prüft selbstständig, ob der Server erreichbar ist. Bei einem Ausfall kann er ein Wake-on-LAN-Signal senden und eine Benachrichtigung auslösen.

Warum ein externer Watchdog?

Mit Uptime Kuma lassen sich Webseiten und Dienste zuverlässig überwachen. Läuft die Monitoring-Instanz aber auf demselben Rechner wie die überwachten Anwendungen, entsteht eine Abhängigkeit: Ist der ganze Rechner ausgeschaltet, kann er auch keine eigenen Warnmeldungen mehr versenden.

Ein externer Watchdog löst diese Abhängigkeit teilweise auf. Der ESP32-C3 besitzt seine eigene Firmware und führt die Prüfungen unabhängig vom Debian-Betriebssystem aus. Er benötigt dafür nur Strom und eine funktionierende lokale Netzwerkverbindung.

Der Watchdog soll vor allem drei Aufgaben übernehmen:

• einen nicht erreichbaren Server frühzeitig erkennen,
• automatisch einen definierten Wiederanlaufversuch per Wake-on-LAN auslösen,
• den Ablauf für die spätere Fehlersuche protokollieren.

Er ist kein Ersatz für Backups, eine unterbrechungsfreie Stromversorgung oder eine saubere Fehleranalyse. Sein Nutzen liegt in der zusätzlichen Kontroll- und Reaktionsebene.

Die eingesetzte Hardware

Die Lösung besteht aus einem ESP32-C3, einem kompakten Mikrocontroller mit WLAN. Zusätzliche Relais oder eine direkte elektrische Verbindung zum Server sind für die aktuelle Umsetzung nicht erforderlich.

Der ESP hängt mit seiner Stromversorgung direkt am USB-Anschluss meiner FRITZ!Box. Dadurch benötigt er kein separates USB-Netzteil. Über WLAN ist er mit dem lokalen Netzwerk verbunden und kann den per Ethernet angeschlossenen Debian-Server überprüfen.

Der grundsätzliche Aufbau ist überschaubar:

FRITZ!Box ───── Ethernet ───── Debian-Heimserver
    │
    └── USB-Stromversorgung
          │
       ESP32-C3
          │
          └── WLAN: TCP-Prüfungen, Status und Wake-on-LAN

Die USB-Versorgung hat eine praktische Besonderheit: Nach einem Stromausfall startet der ESP zusammen mit der FRITZ!Box neu. Sobald WLAN wieder verfügbar ist, kann er den Server erneut prüfen. Gleichzeitig ist das eine klare Grenze: Fällt die FRITZ!Box aus oder startet ihr WLAN nicht, ist auch die Überwachung eingeschränkt. Der Aufbau besitzt keine eigene Notstromversorgung.

Welche Prüfungen führt der Watchdog durch?

Internetverbindung

Zunächst kontrolliert der ESP, ob ein externes Ziel über TCP erreichbar ist. Damit kann er eine Störung des Internetzugangs von der lokalen Server-Erreichbarkeit unterscheiden.

Wichtig ist dabei: Ein Internetausfall soll die lokale Kontrolle des Servers nicht verhindern. Auch ohne funktionierenden Internetzugang kann die Verbindung zwischen ESP und Server geprüft werden, sofern das Heimnetz weiterläuft.

Debian-Server

Für den eigentlichen Serverstatus versucht der ESP, eine TCP-Verbindung zum konfigurierten SSH-Port des Debian-Servers aufzubauen. Erhält er eine Antwort, gilt der Server für diese Prüfung als erreichbar.

Bleibt die Antwort aus, zählt der Watchdog aufeinanderfolgende Fehlversuche. Nach definierten Schwellenwerten kann er Wake-on-LAN auslösen. Eine Wartezeit zwischen den Versuchen verhindert unnötig häufige Wiederholungen.

Eine wichtige Einschränkung: Ein nicht erreichbarer SSH-Port bedeutet nicht zwangsläufig, dass der gesamte Rechner ausgeschaltet ist. Auch ein gestörter SSH-Dienst oder eine Netzwerkstörung kann dieselbe Reaktion auslösen. Deshalb erfolgt die Bewertung nicht anhand eines einzelnen Fehlversuchs.

Anwendungen über Uptime Kuma

Ist der Server erreichbar, prüft der Watchdog zusätzlich den Status ausgewählter Dienste über die vorhandene Uptime-Kuma-Statusseite. Dafür kann er den konfigurierten Web-Endpunkt und bei Bedarf einen lokalen Zugriff verwenden.

Im geplanten Wartungsfenster werden Dienstprüfungen ausgesetzt, soweit dies in der Firmware vorgesehen ist. So führen absichtlich gestoppte Container nicht zu unnötigen Dienstalarmen. Die Prüfung, ob der Server selbst erreichbar ist, bleibt davon getrennt.

Wake-on-LAN: Ein automatischer Startversuch

Wake-on-LAN, kurz WOL, ist ein Verfahren, bei dem ein Netzwerkgerät durch ein spezielles Datenpaket geweckt werden kann. Dieses sogenannte Magic Packet enthält wiederholt die Hardwareadresse des Zieladapters.

Mein Watchdog versendet bei Bedarf mehrere solcher Pakete über das lokale Netzwerk. Das passiert sowohl automatisch nach einer festgelegten Zahl von Fehlversuchen als auch über einen manuellen Auslöser in der lokalen Weboberfläche.

Zusätzlich existiert eine Power-Recovery-Funktion: Nach dem Neustart des ESP kann der Watchdog in einem begrenzten Zeitfenster gezielt versuchen, einen nicht erreichbaren Server zu wecken. Das ist besonders für Situationen gedacht, in denen Router und Watchdog nach einer Stromunterbrechung wieder hochfahren, der Server jedoch ausgeschaltet bleibt.

Dabei gilt: Ein erfolgreich an den Netzwerkstack übergebenes UDP-Paket ist kein Empfangsnachweis. Ob der Server wirklich gestartet wurde, lässt sich erst durch eine spätere erfolgreiche Erreichbarkeitsprüfung feststellen.

Was der Test nach einem Stromausfall gezeigt hat

Im Oktober 2026 war mein Debian-Server nach einem mutmaßlichen Stromausfall nicht mehr erreichbar. Er blieb ausgeschaltet, bis ich ihn manuell startete. Das war der Anlass, die Ereignisaufzeichnung im ESP-Watchdog auszubauen.

Anschließend habe ich den Fehler kontrolliert nachgestellt: Die Stromversorgung des Mini-PCs wurde vollständig abgeschaltet und später wiederhergestellt. Der Watchdog erkannte den fehlenden Server und löste sowohl automatische als auch manuelle WOL-Versuche aus. Das Ereignisprotokoll dokumentierte dabei jeweils erfolgreiche UDP-Sendevorgänge. Der Mini-PC startete dennoch nicht automatisch.

Die Diagnose zeigte außerdem, dass Wake-on-LAN im laufenden Debian auf dem verwendeten Ethernet-Adapter aktiviert war und die konfigurierte Hardwareadresse übereinstimmte. Damit ließ sich die Fehlersuche eingrenzen, aber noch nicht abschließen.

Ein wesentlicher Unterschied ist der Betriebszustand: Ein normal heruntergefahrener Rechner kann sich bei Wake-on-LAN anders verhalten als ein Gerät, das zuvor vollständig von der Netzspannung getrennt war. Ob das Mainboard nach Rückkehr der Spannung einen WOL-Start zulässt, hängt unter anderem von den BIOS-/UEFI-Einstellungen und der Standby-Versorgung der Netzwerkkarte ab.

Für einen zuverlässigen 24/7-Betrieb ist deshalb zusätzlich eine geeignete Einstellung wie „Power On after AC Loss“ sinnvoll, sofern die Hardware diese unterstützt. Der automatische Wiederanlauf nach vollständiger Netztrennung ist bei meinem Aufbau bislang noch nicht erfolgreich nachgewiesen.

Ereignislogging: Was passiert im Fehlerfall?

Die aktuelle Firmware führt ein kompaktes Ereignisprotokoll im Flash-Speicher des ESP32-C3. Dafür wird LittleFS verwendet. Statt jeden erfolgreichen Prüfzyklus aufzuzeichnen, dokumentiert die Software hauptsächlich Zustandswechsel und relevante Aktionen.

Zu den protokollierten Ereignissen gehören:

• Neustarts des ESP und deren technische Ursache,
• Aufbau und Verlust der WLAN-Verbindung,
• Wechsel des Internet- und Serverstatus,
• Start und Ende der Power-Recovery-Phase,
• WOL-Versuche und deren UDP-Sendeergebnis,
• spätere Erreichbarkeit des Servers nach einem WOL-Versuch,
• Zeitsynchronisierung und relevante Wartungszustände.

Das Protokoll ist größenbegrenzt und wird zwischen zwei Dateien rotiert. Es bleibt über einen gewöhnlichen Neustart des ESP hinweg erhalten und lässt sich über die lokale Weboberfläche als Textdatei herunterladen.

Diese Aufzeichnung ist für die Fehlersuche deutlich nützlicher als ein einzelner Zähler. Sie beantwortet nicht nur, ob der Watchdog aktiv war, sondern auch wann er welchen Zustand erkannt und welche Maßnahme er eingeleitet hat.

Lokale Kontrolle und Benachrichtigungen

Der Watchdog stellt eine einfache Weboberfläche im Heimnetz bereit. Dort sind unter anderem der aktuelle Zustand, die Erreichbarkeit des Servers, Fehlversuche, die Anzahl der WOL-Sendevorgänge und der Status der Power-Recovery-Funktion sichtbar. Ein manueller WOL-Versuch kann ebenfalls ausgelöst werden.

Die Benachrichtigung erfolgt bei definierten Ereignissen über Telegram. Das ist für die Erreichbarkeit von unterwegs praktisch, bedeutet aber auch, dass technische Statusinformationen an einen externen Dienst übertragen werden. Telegram ist für den lokalen Watchdog-Betrieb nicht grundsätzlich erforderlich, sondern dient als zusätzlicher Meldeweg.

Datenschutz und Sicherheit

Der ESP benötigt keine personenbezogenen Nutzungsprofile. Das Ereignisprotokoll dient der technischen Fehleranalyse und enthält hauptsächlich Zeitpunkte, Zustände, Netzwerkdiagnosen und Aktionsmeldungen. Solche Informationen können dennoch Rückschlüsse auf die eigene Infrastruktur zulassen.

Deshalb veröffentliche ich weder produktive Zugangsdaten noch interne Adressen, Gerätekennungen, Tokens oder vollständige Konfigurationsdateien. Zugangsdaten für WLAN und Benachrichtigungen gehören getrennt vom öffentlich beschriebenen Programmcode verwaltet.

Die Weboberfläche der aktuellen Firmware besitzt keine eigene Anmeldung. Sie sollte daher ausschließlich über ein vertrauenswürdiges lokales Netz beziehungsweise einen abgesicherten Fernzugang erreichbar sein und nicht öffentlich über eine Portfreigabe bereitgestellt werden. Das ist insbesondere wichtig, weil darüber ein manueller WOL-Aufruf möglich ist.

Das lokale Ereignislog ist größenbegrenzt, aber nicht als vertraulicher Langzeitspeicher ausgelegt. Telegram-Benachrichtigungen sollten auf notwendige technische Angaben beschränkt bleiben. Wie lange Telegram selbst Nachrichten verarbeitet oder aufbewahrt, liegt nicht in der Kontrolle des Mikrocontrollers.

Was der Watchdog nicht leisten kann

Trotz der zusätzlichen Überwachung gibt es klare Grenzen:

• Kein Strom, keine Kontrolle: Ohne Versorgung des ESP ist kein Monitoring möglich.
• Abhängigkeit vom lokalen Netzwerk: Ohne funktionierendes WLAN oder Weiterleitung im Heimnetz kann WOL scheitern.
• Keine garantierte Einschaltfunktion: Ein Magic Packet ersetzt keine kompatible BIOS-/UEFI-Konfiguration.
• Kein vollständiger Hardwarezustand: Eine TCP-Prüfung liefert keinen sicheren Nachweis für den elektrischen Zustand oder die allgemeine Gesundheit des Servers.
• Keine Datensicherung: Der Watchdog schützt keine Dateien und ersetzt kein Backup- oder Wiederherstellungskonzept.

Fazit

Der ESP32-C3 ergänzt meinen Debian-Server um eine unabhängige Überwachung, die sich mit wenig Hardware umsetzen lässt. Die Stromversorgung über den USB-Anschluss der FRITZ!Box hält den Aufbau kompakt. Die Kombination aus TCP-Prüfungen, Uptime-Kuma-Auswertung, Wake-on-LAN und lokalem Ereignislog ermöglicht eine nachvollziehbare Fehlerdiagnose.

Der praktische Test hat zugleich die wichtigste Grenze gezeigt: Ein versendetes WOL-Paket ist noch kein erfolgreich gestarteter Server. Gerade nach vollständiger Stromtrennung müssen auch die Firmware-Einstellungen und die Stromversorgung der Netzwerkkarte passen.

Der Watchdog bleibt deshalb eine zusätzliche Schutzschicht – neben geeigneten BIOS-Einstellungen, regelmäßigen Backups und einer funktionierenden Serverüberwachung.