Ein Heimnetz-Dashboard auf dem Raspberry Pi – von der Idee zum Dauerbetrieb

Wer im Haushalt 20 bis 50 Netzwerkgeräte hat – Repeater, Kameras, Sensoren, Shelly-Steckdosen – verliert schnell den Überblick. Genau dafür ist in den letzten Tagen ein eigenes Heimnetz-Dashboard entstanden: eine schlanke Node.js-Anwendung, die alle Geräte erfasst, beschriftet und steuerbar macht.

Das Agent-Modell

Das Prinzip ist ein Agent-Modell. Ein Agent scannt das lokale Netz per nmap, ergänzt Hersteller (MAC-Lookup), Hostnamen und Web-Erreichbarkeit und schickt das Inventar an einen kleinen Server. Dieser speichert alles in einfachen JSON-Dateien, kümmert sich um den Login und liefert das Dashboard aus – bewusst nur mit Node-Standardmodulen, ohne Framework-Ballast.

Dashboard-Features

Im Dashboard lässt sich jedes Gerät mit Name, Standort, Raum und Typ beschriften, gruppiert nach Standort, mit Live-Ping-Ampel, Volltextsuche, „Geprüft/Kontrollieren"-Status und einer eigenen iPhone-Ansicht. Neu dazugekommen: Export der Tabelle als CSV oder PDF per Knopfdruck. Für die vorhandenen Shelly-Geräte gibt es eine eigene Steuerseite mit An/Aus, Status und sequenziellem Firmware-Update.

Dauerbetrieb auf dem Raspberry Pi

Seit Kurzem läuft der Code auf einem Raspberry Pi 4, sauber als systemd-Dienste. Der PC muss nicht mehr laufen. Weil ein Pi bei Hitze drosselt, zeigt das Dashboard jetzt Temperatur, CPU-Last und RAM an und pausiert Scan und Ping automatisch, sobald 70 °C erreicht werden – für 15 Minuten, bis es wieder kühler ist.

Datensicherheit & Zuverlässigkeit

Ein wichtiges Thema war Datensicherheit: Nach einem Vorfall mit verlorenen Labels schreibt der Server jetzt atomar, führt Inventare per Union-Merge zusammen (beschriftete Geräte gehen nie verloren) und legt automatische Backups an. Ergänzend sichert ein wöchentlicher Cron-Job vier rotierende Versionen des kompletten Stands.

Lernpunkte

Nebenbei habe ich einiges über tückische Bugs gelernt – etwa Escape-Sequenzen in Template-Literals, die ganze Skripte lahmlegen können. Aus einer kleinen Idee ist so ein verlässliches Werkzeug für den Alltag geworden.

Deployment in fünf Schritten (die geplanten „Buckets")

Der Weg vom Windows-PC zum 24/7-Betrieb auf dem Raspberry Pi lief bewusst in kleinen, prüfbaren Schritten – jeder Bucket wurde vor dem nächsten bestätigt und gegen Kriterien getestet.

1. Raspberry Pi OS Lite flashen — headless mit SSH + fixer IP

OS Lite (64-bit) wird mit dem Raspberry Pi Imager auf die microSD geschrieben – ganz ohne Monitor und Tastatur. Über die Imager-Voreinstellungen (Zahnrad) werden Hostname (***), Benutzer (***) samt Passwort und die SSH-Aktivierung (Passwort-Auth) direkt eingebrannt. Alternativ legt man auf der Boot-Partition eine cloud-init-user-data an mit ssh_pwauth: true und runcmd: systemctl enable --now ssh. Eine feste IP holt man am robustesten über eine DHCP-Reservierung im Router (MAC → ***.***.***.***) statt über statische Konfiguration am Pi. Der erste Boot dauert etwas (Dateisystem wird vergrößert); danach genügt ssh ***@***.***.***.***.

2. Node.js + nmap installieren

Nach dem ersten Login zuerst sudo apt update && sudo apt install -y nmap. Für ein aktuelles Node (LTS v20) das NodeSource-Repo einbinden: curl -fsSL https://deb.nodesource.com/setup_20.x | sudo bash -, dann sudo apt install -y nodejs. Kontrolle mit node -v und nmap --version. Wichtig: nmap braucht root, um im lokalen Subnetz per ARP MAC-Adressen zu sehen (-sn). Die Anwendung selbst kommt ohne npm-Pakete aus – nur Node-Standardmodule – daher entfällt jedes npm install.

3. server/ + agent/ kopieren — Config auf Linux/localhost anpassen

Die Ordner wandern per scp -r server agent ***@***.***.***.***:~/netzdash/ auf den Pi. In server/config.json stehen Port 3000, der Zugangs-Code (***) und der agentToken (***, langer Zufallswert – muss in beiden Configs identisch sein). In agent/config.json wird das Subnetz auf ***.***.***.0/24 gesetzt, der Windows-nmapPath entfällt (Linux findet nmap im PATH) und vpsEndpoint zeigt auf http://localhost:3000/api/inventory. Die JSON-Daten (data.json, hostnames.json, standort_regeln.json, shelly_devices.json) kommen mit, damit Labels und Regeln erhalten bleiben.

4. systemd-Dienste einrichten

netzdash-server.service startet den Server dauerhaft: ExecStart=/usr/bin/node /home/***/netzdash/server/server.js, User=***, Restart=always. Der Scan läuft getrennt: netzdash-agent.service als Type=oneshot mit User=root (wegen nmap), getaktet von netzdash-agent.timer (OnUnitActiveSec=10min, Persistent=true). Nach sudo systemctl daemon-reload werden Server-Dienst und Timer per enable --now aktiviert. Der frühere Windows-Autostart wird abgeschaltet. Logs verfolgt man live mit journalctl -u netzdash-server -f.

5. Testen

Das Dashboard ist unter http://***.***.***.***:3000 erreichbar, Login mit dem Code ***. Den Agent einmalig anstoßen: sudo systemctl start netzdash-agent.service, danach journalctl -u netzdash-agent prüfen. Erfolgskriterien: Geräte erscheinen in der Tabelle, die Ping-Ampel wird grün/rot, der Zähler im Kopf stimmt, und systemctl status zeigt für beide Dienste active. Ab hier läuft alles ohne PC – der Pi scannt, speichert und liefert das Dashboard eigenständig aus.

Live-Werte direkt in der Geräteliste.

Der Server fragt alle Shellys im Hintergrund regelmäßig ab und zeigt in der iPhone-Ansicht pro Gerät:
- aktuelle Leistung in Watt
- Gerätetemperatur
Gerät EIN: leuchtet gelb – man sieht auf einen Blick, was gerade läuft. Ein hoher Verbrauch (ab 100 W) und heiße Geräte (ab 80 °C) werden rot hervorgehoben.

Schalten - Überwachen - Verbrauch und Temperatur im Blick – alles an einem Ort. Besonders praktisch am Handy: ein kurzer Blick genügt, um zu sehen, welche Verbraucher gerade Strom ziehen und ob ungewöhnlich viel Leistung anliegt.