Monitoring klingt für viele sofort nach großen Tools, komplexen Dashboards und stundenlanger Konfiguration. Lösungen wie Zabbix, Prometheus oder Grafana sind ohne Frage sehr leistungsfähig – für ein paar IoT-Geräte im Alltag jedoch oft schlicht überdimensioniert.
In diesem Beitrag zeige ich ein bewusst einfach gehaltenes Monitoring-Setup mit n8n. Ziel ist es nicht, jedes Detail zu überwachen, sondern schnell und zuverlässig zu erkennen, ob ein Gerät erreichbar ist – und bei Problemen informiert zu werden. Für viele Smart-Home- und IoT-Szenarien reicht genau das völlig aus.
Als Praxisbeispiel nutze ich Shelly-Geräte, da diese in vielen Haushalten im Einsatz sind und sich unkompliziert per HTTP prüfen lassen. Das gezeigte Konzept ist jedoch universell einsetzbar: Auch ESP32-Projekte, Raspberry Pis, Computer, Drucker oder andere Netzwerkgeräte lassen sich auf die gleiche Weise überwachen.
Das vorgestellte Monitoring kommt ohne zusätzliche Datenbanken, ohne Agenten und ohne komplexe Infrastruktur aus. Stattdessen nutzen wir die Stärken von n8n: übersichtliche Workflows, einfache Logik und eine kompakte Statusübersicht, die sich automatisch per E-Mail versenden lässt.
Wenn du ein leichtgewichtiges Monitoring suchst, das verständlich bleibt und trotzdem echten Mehrwert bietet, dann ist dieses Setup genau richtig für dich.
Hinweis zu n8n: n8n ist kein dauerhaft kostenlos nutzbares Automatisierungstool. Für die Cloud-Version fallen monatliche Kosten an. Aktuell liegt der Preis bei rund 30 € pro Monat. Dafür erhält man ein sehr mächtiges Werkzeug, mit dem sich weit mehr als nur einfache Automationen umsetzen lassen.
Für dieses Monitoring-Projekt verwende ich das Paket „Starter“, welches für meine aktuellen Workflows vollkommen ausreichend ist. Wenn du n8n zunächst ausprobieren möchtest, bietet der Anbieter eine 14-tägige Testphase an, in der sich alle Funktionen in Ruhe testen lassen.
Für wen ist dieser Artikel gedacht?
Dieser Artikel richtet sich an Leser, die ein einfaches Monitoring für IoT-, Smart-Home- oder Homelab-Projekte umsetzen möchten. Das gezeigte Setup eignet sich besonders für private Umgebungen und kleinere Installationen, bei denen es vor allem darum geht, die Erreichbarkeit von Geräten im Blick zu behalten.
Für große Infrastrukturen oder unternehmenskritische Systeme ist dieses Monitoring bewusst nicht ausgelegt.
Was n8n eigentlich ist – und was nicht
n8n ist kein klassisches Monitoring-Tool und auch keine fertige Smart-Home-Lösung. Es bringt weder vorgebaute Dashboards noch umfangreiche Zeitreihen-Auswertungen mit, wie man sie von Tools wie Zabbix oder Grafana kennt.
Stattdessen ist n8n ein Automatisierungswerkzeug. Es verbindet Trigger, Logik und Aktionen miteinander und eignet sich genau deshalb für individuelle Lösungen. Daten können abgefragt, bewertet, gespeichert und weiterverarbeitet werden – unabhängig davon, ob sie von IoT-Geräten, APIs oder Formularen stammen.
In diesem Beitrag wird n8n daher nicht als Monitoring-Tool eingesetzt, sondern als flexible Schaltzentrale. Das gezeigte Monitoring dient als praxisnahes Beispiel und lässt sich leicht auf eigene Ideen und Anwendungsfälle übertragen.
Warum Monitoring ein gutes Einstiegsbeispiel ist
Monitoring ist ein gutes Einstiegsbeispiel für n8n, weil du hier schnell verstehst, wie ein Workflow aufgebaut ist. Ein Gerät ist erreichbar oder eben nicht – genau diese einfache Logik lässt sich sehr gut abbilden und nachvollziehen.
An diesem Beispiel lernst du typische n8n-Bausteine kennen: zeitgesteuerte Abläufe, das Verarbeiten mehrerer Geräte, einfache Wenn-Dann-Entscheidungen und das Erzeugen einer Ausgabe, etwa in Form einer E-Mail. Das hilft dir, ein Gefühl dafür zu bekommen, wie n8n „denkt“.
Das Wichtigste dabei: Du lernst kein starres Monitoring-Rezept, sondern ein Prinzip. Sobald du den Aufbau verstanden hast, kannst du ihn leicht auf eigene Ideen übertragen – zum Beispiel auf andere Geräte, Dienste oder ganz andere Automatisierungen.
Genau deshalb eignet sich Monitoring so gut als Einstieg: Es ist überschaubar, praxisnah und zeigt dir, was mit n8n möglich ist, ohne dich mit unnötiger Komplexität zu überfordern.
Kurzer Abstecher: Shelly Cloud-Zugriff im Workflow
Für den in diesem Beitrag gezeigten Workflow nutze ich den Cloud-Zugriff von Shelly. Dafür werden zwei Informationen benötigt: die Server-URL der Shelly-Cloud sowie ein Auth-Key für den API-Zugriff.
Der Auth-Key dient ausschließlich für den Zugriff auf die Shelly-Cloud und nicht für den direkten lokalen Zugriff auf das Gerät. Über diesen Schlüssel kann anschließend mit einem zusätzlichen Parameter die jeweilige Geräte-ID angegeben werden. Erst durch diese Geräte-ID wird eindeutig festgelegt, welches Shelly-Gerät angesprochen wird.
Der Vorteil dieses Ansatzes liegt darin, dass die Geräte nicht direkt im lokalen Netzwerk erreichbar sein müssen. Der Zugriff erfolgt zentral über die Shelly-Cloud, was den Workflow vereinfacht und auch bei wechselnden IP-Adressen zuverlässig funktioniert.
Wichtig ist auch hier: Für das grundsätzliche Monitoring-Prinzip spielt es keine Rolle, ob der Zugriff lokal oder über die Cloud erfolgt. Entscheidend ist lediglich, dass ein definierter Endpunkt existiert, der den aktuellen Status des Geräts zurückliefert. Das gezeigte Vorgehen lässt sich daher problemlos auf andere APIs oder Geräte übertragen.
Im nächsten Abschnitt schauen wir uns an, wie der HTTP-Request im n8n-Workflow aufgebaut ist und welche Daten daraus weiterverarbeitet werden.
Der Monitoring-Workflow: Aufbau und Grundprinzip
Nachdem klar ist, warum Monitoring ein gutes Einstiegsbeispiel für n8n ist, steigen wir nun direkt in die Praxis ein.
Das Prinzip ist bewusst einfach: In einem festen Intervall wird geprüft, ob ein Gerät erreichbar ist. Dabei werden die Ergebnisse direkt ausgewertet und als Kennzahlen (Online, Offline, Verfügbarkeit) gespeichert. Ein separater Workflow erzeugt anschließend daraus einen übersichtlichen Report und verschickt ihn per E-Mail.
Damit die Abläufe klar getrennt sind, habe ich das Monitoring in zwei Workflows aufgeteilt. Workflow 1 läuft regelmäßig (bei mir einmal pro Stunde) und übernimmt die eigentliche Prüfung inklusive Berechnung und Fortschreibung der Kennzahlen. Workflow 2 startet einmal täglich um Mitternacht und hat nur eine Aufgabe: Aus den vorhandenen Daten eine HTML-Tabelle erzeugen und per E-Mail versenden.
Im nächsten Abschnitt starten wir mit Workflow 1 und schauen uns zuerst den Trigger an, der die regelmäßige Prüfung auslöst.
Monitoring-Daten in n8n speichern (Datatable vs. Datenbank)
Die Daten für das Monitoring speichere ich direkt in einer Datatable innerhalb von n8n. Für dieses Setup ist das vollkommen ausreichend und hält den gesamten Workflow übersichtlich und leicht wartbar.
Grundsätzlich ist n8n nicht auf eine bestimmte Speicherlösung festgelegt. Die gleichen Daten könnten ebenso in Google Sheets, einer externen Datenbank oder einem anderen Speichersystem abgelegt werden. n8n bringt dafür die passenden Schnittstellen bereits mit.
Für dieses Monitoring-Projekt habe ich mich bewusst für die interne Datatable entschieden. Sie lässt sich ohne zusätzlichen Aufwand nutzen, bietet eine einfache Struktur und reicht für eine überschaubare Anzahl an Geräten völlig aus. Gerade zum Einstieg oder für kleinere Setups ist das oft die pragmatischste Lösung.
Sollte das Monitoring später wachsen oder komplexere Auswertungen notwendig werden, kann die Datenspeicherung jederzeit ausgelagert werden. Der grundlegende Workflow bleibt dabei unverändert – lediglich die Speicherkomponente wird ausgetauscht.
Workflow 1: IoT-Geräte regelmäßig mit n8n überwachen
Der erste Workflow ist bewusst einfach aufgebaut und besteht aus wenigen, klaren Schritten. Ziel ist es, regelmäßig den Status aller hinterlegten Geräte zu prüfen und die entsprechenden Zähler fortzuschreiben.
Der Workflow startet über einen Cron-Trigger und wird in meinem Setup einmal pro Stunde ausgeführt. Anschließend werden alle Geräte aus der Datatable geladen und nacheinander verarbeitet.
Für jedes Gerät wird ein HTTP-Request ausgeführt, um den aktuellen Status abzufragen. Ist die Anfrage erfolgreich, wird der Online-Zähler erhöht. Schlägt der Request fehl, wird stattdessen der Offline-Zähler fortgeschrieben.
Nach der Statusauswertung werden die berechneten Werte für Online, Offline und Verfügbarkeit aktualisiert. Um die Shelly-Cloud nicht mit zu vielen Anfragen zu belasten, wartet der Workflow nach jedem Durchlauf kurz zwei Sekunden, bevor das nächste Gerät geprüft wird.
Im Blog habe ich den Workflow bewusst auf konzeptioneller Ebene beschrieben. Den vollständigen Aufbau inklusive aller Nodes, Einstellungen und typischer Stolperfallen zeige ich Schritt für Schritt im verlinkten YouTube-Video zu diesem Beitrag.
Workflow 2 – Report und E-Mail-Versand
Der zweite Workflow kümmert sich ausschließlich um die Aufbereitung und den Versand des Reports. Er greift dabei auf die bereits berechneten Daten aus dem ersten Workflow zurück und führt selbst keine Statusprüfungen oder Berechnungen mehr durch.

Der Workflow startet einmal täglich um Mitternacht über einen Cron-Trigger. Zunächst werden alle aktuellen Datensätze aus der Datatable geladen. Anschließend werden die einzelnen Einträge zu einem gemeinsamen Datensatz zusammengeführt, der als Grundlage für den Report dient.
Auf Basis dieser Daten wird eine HTML-Seite aufgebaut, die den aktuellen Status der überwachten Geräte übersichtlich in Tabellenform darstellt. Dieser HTML-Report wird anschließend direkt per E-Mail versendet, sodass der aktuelle Zustand aller Geräte automatisch im Postfach landet.
Auch hier gilt: Der konkrete Aufbau des HTML-Templates und die genaue Konfiguration des E-Mail-Versands sind bewusst ausgelagert. Die detaillierte Umsetzung zeige ich im begleitenden YouTube-Video zu diesem Beitrag.
Der Report als HTML-Seite mit JavaScript
Der tägliche Report wird nicht als einfache Text-E-Mail erzeugt, sondern als vollständige HTML-Seite. Dieses HTML-Template wird direkt im Workflow aufgebaut und anschließend als E-Mail-Inhalt versendet.
Der große Vorteil dabei: Innerhalb des HTML-Dokuments kann JavaScript verwendet werden. Dadurch lassen sich die gesammelten Monitoring-Daten dynamisch weiterverarbeiten und zum Beispiel automatisch als Tabelle darstellen. Änderungen am Layout oder an der Darstellung können später direkt im Template vorgenommen werden, ohne den eigentlichen Workflow anpassen zu müssen.
n8n übergibt die gesammelten Daten dabei als JSON-Struktur an das Template. Das JavaScript im HTML kümmert sich anschließend darum, diese Daten zu iterieren und in eine übersichtliche Tabelle zu rendern. Dieser Ansatz eignet sich nicht nur für Monitoring-Reports, sondern auch für viele andere Auswertungen und Statusübersichten.
<!DOCTYPE html>
<html>
<head>
<meta charset="UTF-8" />
<title>Shelly Monitoring</title>
<style>
table, th, td { border: 1px solid black; border-collapse: collapse; padding: 8px; }
table { width: 100%; margin: 20px 0; }
th { background-color: #42bcf5; color: white; }
tr:nth-child(even) { background-color: #f2f2f2; }
.container { background-color: #ffffff; padding: 16px; border-radius: 8px; }
h1 { color: #42bcf5; font-size: 24px; font-weight: bold; padding: 8px; }
h1, .date { text-align: center; }
.metaText{ font-size:14px; color:#333; line-height:1.5; max-width:800px; margin:0 auto 16px auto; }
.n8nHint{ font-size:13px; color:#555; max-width:800px; margin:0 auto; }
</style>
</head>
<body>
<div class="container">
<h1>Shelly Monitoring</h1>
<p class="date">{{ new Date().toLocaleDateString('de-de', { weekday:"long", year:"numeric", month:"short", day:"numeric"}) }}</p>
<p class="metaText">
Dieser Bericht zeigt den aktuellen Status meiner überwachten Shelly-Geräte.
Die Auswertung basiert auf regelmäßigen Verfügbarkeits-Checks und stellt dar,
wie oft ein Gerät erreichbar war bzw. nicht reagiert hat.
</p>
<center>
<table>
<thead>
<tr>
<th>Name</th>
<th>Raum</th>
<th>Online</th>
<th>Offline</th>
<th>Verfügbarkeit (in %)</th>
<th>Downtime (in %)</th>
</tr>
</thead>
<tbody>
{{ $json.data.map(device => `
<tr>
<td>${device.name}</td>
<td>${device.room}</td>
<td>${device.onlineTotal}</td>
<td>${device.offlineTotal}</td>
<td>${device.availabilityPercentage}</td>
<td>${device.downtimePercentage}</td>
</tr>
`).join('') }}
</tbody>
</table>
</center>
<p class="n8nHint">
Dieses Monitoring wurde mit <a href="https://n8n.io/" target="_blank">n8n</a> realisiert und dient als
praxisnahes Beispiel für einfache IoT-Überwachung ohne Cloud-Abhängigkeit.
</p>
<p style="font-size:13px; color:#555; max-width:800px; margin:8px auto 0 auto;text-align: center;">
Weitere technische Projekte, Automationen und IoT-Praxisbeispiele findest du auf meinem Blog:<br />
<a href="https://draeger-it.blog" target="_blank" style="color:#42bcf5; text-decoration:none;">
https://draeger-it.blog</a>
</p>
</div>
</body>
</html>
Versand des Reports per E-Mail
Der fertige HTML-Report wird im letzten Schritt per E-Mail versendet. Für den Versand nutze ich in meinem Setup einen E-Mail-Account bei all-inkl.com, da ich dort zusätzliche Postfächer unkompliziert anlegen kann. Der Versand erfolgt klassisch per SMTP.

Alternativ kann der Report genauso gut über Gmail verschickt werden. n8n unterstützt beide Varianten ohne Einschränkungen. Welcher Weg genutzt wird, ist am Ende eine Frage der persönlichen Vorlieben und der vorhandenen Infrastruktur.
Wichtig ist in beiden Fällen, dass die benötigten Zugangsdaten als Credentials in n8n hinterlegt werden. Diese werden global gespeichert und können anschließend in beliebigen Workflows wiederverwendet werden. Benutzername, Passwort oder OAuth-Zugangsdaten müssen somit nicht mehrfach gepflegt werden.
Die genaue Einrichtung der E-Mail-Zugänge – sowohl für all-inkl.com als auch für Gmail – zeige ich Schritt für Schritt im oben verlinkten YouTube-Video. Dort gehe ich auch auf typische Stolperfallen ein, etwa bei Authentifizierung oder SMTP-Einstellungen.
Fazit
Dieses Monitoring-Setup zeigt, dass es für viele IoT- und Smart-Home-Szenarien keine großen, komplexen Monitoring-Lösungen braucht. Mit n8n lässt sich bereits mit wenigen Bausteinen ein zuverlässiger Überblick über den Status der eigenen Geräte aufbauen.
Das gezeigte Beispiel mit Shelly-Geräten ist dabei nur ein Einstieg. Das zugrunde liegende Prinzip lässt sich problemlos auf andere Geräte, Dienste oder APIs übertragen. Entscheidend ist nicht das konkrete Gerät, sondern die Logik dahinter: prüfen, auswerten, speichern und reagieren.
n8n eignet sich für solche Aufgaben besonders gut, weil Workflows verständlich bleiben und sich flexibel anpassen lassen. Wer später mehr Anforderungen hat, kann das Setup schrittweise erweitern oder einzelne Komponenten austauschen, ohne alles neu denken zu müssen.
Für kleinere Setups, Homelabs oder eigene IoT-Projekte ist dieses Monitoring daher eine praxisnahe und wartbare Lösung. Wer hingegen detaillierte Langzeitdaten, umfangreiche Metriken oder komplexe Alarmierungen benötigt, ist mit spezialisierten Monitoring-Tools weiterhin besser beraten.
Häufige Fragen zum IoT-Monitoring mit n8n (FAQ)
Ist n8n für Monitoring geeignet?
n8n ist kein klassisches Monitoring-Tool, eignet sich aber sehr gut für einfache und individuelle Monitoring-Lösungen. Vor allem für IoT-, Smart-Home- und Homelab-Setups bietet n8n einen guten Kompromiss aus Übersichtlichkeit und Flexibilität.
Warum wird hier keine zeitbasierte Uptime berechnet?
In diesem Setup wird die Verfügbarkeit über erfolgreiche und fehlgeschlagene Prüfungen berechnet. Das ist einfacher umzusetzen und für viele Anwendungsfälle ausreichend. Eine exakte zeitbasierte Uptime würde eine deutlich komplexere Logik oder zusätzliche Datenspeicherung erfordern.
Kann ich statt Shelly auch andere Geräte überwachen?
Ja. Shelly dient in diesem Beitrag lediglich als Praxisbeispiel. Das Monitoring-Prinzip lässt sich auf ESP32-Projekte, Raspberry Pis, Drucker, Server oder andere Geräte mit HTTP- oder API-Zugriff übertragen.
Wie viele Geräte kann ich mit diesem Setup überwachen?
Für kleinere Setups mit einigen wenigen bis mehreren Dutzend Geräten ist dieses Monitoring problemlos geeignet. Bei sehr vielen Geräten oder kurzen Prüfintervallen sollte der Workflow entsprechend angepasst oder skaliert werden.
Kann ich die Daten auch extern speichern?
Ja. Statt der n8n-Datatable können die Monitoring-Daten auch in Google Sheets, einer Datenbank oder einem anderen Speichersystem abgelegt werden. Der Workflow lässt sich dafür leicht anpassen.
Wie werden die Reports versendet?
Der Report wird als HTML-E-Mail versendet. Dafür kann ein eigener SMTP-Account, wie z. B. bei all-inkl.com, oder alternativ ein Gmail-Konto genutzt werden.
Ist dieses Monitoring für den Produktiveinsatz geeignet?
Für private Projekte, Smart-Home-Setups und kleinere IoT-Umgebungen ist dieses Monitoring sehr gut geeignet. Für kritische Systeme mit hohen Verfügbarkeitsanforderungen sollten spezialisierte Monitoring-Lösungen eingesetzt werden.
Letzte Aktualisierung am: 18. Dezember 2025





