Release-Verlauf

Zyxels Endkunden-Router sprechen weder TR-064 noch SNMP. Betroffen sind die Reihen AX/DX/EX/PX, VMG/EMG/PMG und die Mobilfunkgeräte LTE/NR/FWA. Wer so eine Box als Gateway hat, bekam von der Router-Anbindung bisher nichts: keine Namen aus der DHCP-Tabelle, keine Geräte aus anderen VLANs, keine MAC für ein Gerät, das der Scan nur über eine Antwort kennt.

Sie sprechen stattdessen eine eigene JSON-Schnittstelle. Der neue Provider liest darüber die Client-Tabelle des Routers, inklusive der Angabe, ob eine Adresse eine gewöhnliche Lease ist, eine feste Reservierung, oder vom Gerät selbst gesetzt. Das ist nach UniFi die zweite Marke, die an echter Hardware nachgemessen ist statt nur gegen dokumentierte API-Formen: eine FWA505 mit Firmware V1.60. Die übrige Familie spricht dieselbe Schnittstelle, ist von uns aber nicht angefasst worden. Das gehört dazugesagt.

Eine Sitzung, und was passiert, wenn man sie nicht zurückgibt

Diese Boxen führen genau eine Admin-Sitzung. Wer sie belegt und nicht wieder freigibt, nimmt dem Besitzer das eigene Router-Menü weg, bis der Untätigkeits-Timer abläuft.

Beim Bauen sind wir da zweimal hineingelaufen. Der Abmelde-Aufruf funktioniert nur als POST. Als GET antwortet er freundlich mit „erfolgreich" und lässt die Sitzung stehen. Und unsere Anfragen brachen nach zwei Sekunden ab, während die Kiste bei etwa jedem fünften Login länger braucht, um überhaupt die Verbindung anzunehmen. Der Abbruch verhinderte nicht, dass die Sitzung entstand. Wir sahen nur ihren Schlüssel nie und konnten sie nicht mehr schließen. Beides ist behoben, gemessen über zwölf Runden hintereinander.

Der Test sagt jetzt, was los ist

Damit hängt die zweite Änderung zusammen. Wenn ein Router keine weitere Anmeldung zulässt, meldete der Einstellungs-Dialog „keine Geräteliste — Zugangsdaten prüfen". In dieser Lage war daran jedes Wort falsch. Die Box hatte geantwortet, das Passwort stimmte, und der Nutzer wurde auf die Suche nach einem Fehler geschickt, den es nicht gab.

Der Test fragt den Provider jetzt nach dem Grund, bevor er urteilt, und kennt einen neuen Zustand dafür: Router besetzt, in der Weboberfläche abmelden. In allen sieben Sprachen, auf Desktop, Server und Handy. Der Anlass war Zyxel. Betroffen war die Logik für alle Marken, deren Erkennung ohne Anmeldung auskommt.

KI-Erkennung zeigt, dass sie läuft

Die KI-Identifikation prüft das Gerät erst selbst ab und fragt dann das Modell. Das dauert ein paar Sekunden. In dieser Zeit zeichnet die App die Geräte-Schublade bei jedem Scan-Ereignis neu, und die Fortschrittsanzeige verschwand dabei mitsamt dem gesperrten Knopf. Es sah aus wie ein Klick, der nichts tut. Also klickte man erneut und bezahlte das Modell zweimal.

Die Anzeige überlebt das Neuzeichnen jetzt, ein zweiter Klick während eines laufenden Aufrufs wird ignoriert, und die Zeile steht dort, wo auch die Antwort erscheint.

Auf dem Handy gibt es außerdem einen Knopf, der die Weboberfläche eines Geräts öffnet, wenn ein Web-Port offen ist. Dieselbe Adressregel wie auf dem Desktop, damit beide nicht an verschiedene Stellen schicken.

Die Hilfe-Ansicht begann bisher mit „Was ist DeviceShelf?". Wer das liest, hat die App installiert, meistens bezahlt, und weiß sehr genau, was sie ist. Was er in dem Moment wollte, in dem er auf Hilfe geklickt hat, war eine Antwort auf ein konkretes Scheitern: Der Scan zeigt nichts, die Live-Bandbreite ist ausgegraut, die Lizenz aktiviert sich nicht.

Hilfe dort, wo das Problem ist

Diese Antworten stehen jetzt da, wo das Problem auftaucht. Die Bandbreiten-Einstellung verlinkt ihre eigene Einrichtungs-Anleitung, wenn Npcap oder BPF-Zugriff fehlen. Die leere Geräteliste verlinkt die Fehlerbehebungs-Seite. Der Lizenzkasten verlinkt die Aktivierungs-Anleitung. Jeder Link öffnet den Website-Abschnitt für genau diese Situation, in der Sprache der App.

Die Hilfe-Ansicht selbst wurde ein kompakter Hub: wie man scannt, was die Tiefen-Analysen tun, welche Funktionen erhöhte Rechte brauchen, wie die Aktivierung läuft, dazu eine Linkliste zu den Anleitungen. Die Broschüren-Karten sind raus.

Neu dort: ein Diagnose-Knopf. Er kopiert Version, System, Lizenzstatus und ob Paket-Mitschnitt verfügbar ist, damit eine Support-Mail mit Fakten beginnt statt mit einer Fragerunde. Gesendet wird nichts; er füllt die Zwischenablage, mehr nicht. Die App bleibt telemetriefrei. Die Hilfe-Links tragen eine schlichte URL-Markierung, damit wir auf der Website sehen, welches Hilfe-Thema genutzt wird, ohne dass die App irgendetwas meldet.

Beim Verdrahten des Knopfs fiel auf: Die Diagnose hätte auf Builds ohne einkompilierten Paket-Mitschnitt behauptet, er sei vorhanden, denn die Prüfung fragte nur nach der Npcap-Laufzeit, und die ist außerhalb von Windows immer „ja". Sie fragt jetzt beides ab, einkompiliert und Laufzeit.

Der MCP-Endpunkt und IPv6

Der MCP-Endpunkt der Server-Edition prüft den Origin-Header, bevor eine Browser-Seite mit ihm sprechen darf. Diese Prüfung hatte keinen Test, und beim Schreiben der Tests kam ein echter Defekt heraus: Auf einer Dual-Stack-Maschine löst localhost zuerst nach ::1 auf, der Browser schickt Origin: http://[::1]:port — und die Erlaubnisliste kannte nur 127.0.0.1. Derselbe Zugriff ging über IPv4 durch und scheiterte über IPv6. Behoben, mit weiterhin striktem Vergleich, damit http://[::1].attacker.example weiter abgewiesen wird. Der Test war gegen den ungefixten Stand rot, bevor er gegen den Fix grün war.

Das macOS-Hilfemenü hat außerdem direkte Einträge für Einrichtungs-Anleitung, Fehlerbehebung und Support bekommen, und die Windows-Herausgeber-Warnung, die Ubuntu-.deb-Falle und die anderen üblichen Erstlauf-Hürden stehen jetzt auf einer Seite, auf die die App verlinkt.

Port 9100 heißt bei Druckern JetDirect und ist kein Protokoll, das Fragen beantwortet, sondern eine Annahmestelle: Was dort ankommt, wird gedruckt. DeviceShelf hat auf diesen Port eine PJL-Abfrage geschickt, um das Modell zu erfahren. Bei Druckern, die PJL an dieser Stelle nicht auswerten, landet die Abfrage als Auftrag in der Warteschlange.

Gemeldet hat es ein Nutzer mit einem Kyocera ECOSYS M6635cidn: eine Seite Zeichenmüll je Scan-Zyklus, einen Tag lang, auf seine Kosten an Papier und Toner.

Zwei Schreiber, nicht einer

Die PJL-Abfrage war der offensichtliche Teil. Der größere saß daneben. Die Diensterkennung lief mit ihrer gesamten Plugin-Liste über denselben Port: ein HTTP-GET, ein Redis-PING, ein TLS-Hello, jedes davon eine mögliche Seite Papier. Nachgemessen im Test sind das 40 Verbindungen pro Port, gegenüber einer einzigen Nachricht der PJL-Sonde.

Beide sind jetzt gesperrt, und zwar an der Stelle, durch die jede Abfrage muss, nicht an der einzelnen Fundstelle. Betroffen sind 9100, 9101 und 9102, derselbe Kanal auf Geräten mit mehreren Anschlüssen, sowie 515, wo LPD aus fehlerhafter Eingabe genauso bereitwillig einen Auftrag erzeugt.

Nicht gesperrt ist 631. Dort spricht IPP über HTTP, und eine Anfrage ist dort eine Frage und kein Auftrag.

Was die Erkennung das kostet

Ob der Port offen ist, stellt DeviceShelf weiterhin fest; das ist ein echtes Signal und erfordert kein einziges gesendetes Byte. Als Drucker erkannt werden die Geräte über das Portmuster, SNMP, mDNS, IPP und den Hersteller der MAC-Adresse. Verloren geht das exakte Modell bei Druckern, die es ausschließlich über PJL herausgeben. Dafür eine Seite zu drucken, ist den Preis nicht wert.

Dieselbe Klasse von Fehler hatten wir schon einmal: Bis 1.9.2 riet die Diensterkennung auf Port 22 Zugangsdaten und trug sich damit in fremde Anmeldeprotokolle ein. Die Trennlinie ist beide Male dieselbe: Beantwortet ein Port Fragen, oder nimmt er Arbeit entgegen?

Nachtrag zum Test

Der erste Regressionstest deckte nur die PJL-Sonde ab. Ein Review vor der Auslieferung wies darauf hin, dass die zweite Sperre damit ungetestet blieb; nachgestellt stimmte das: Löscht man sie, bleibt die gesamte Suite grün. Der Test horcht jetzt real auf einem Port und zählt Verbindungen, mit einer Gegenprobe, die verhindert, dass eine Null etwas beweist, das gar nicht stattgefunden hat.

Ein Scan fragt alle Adressen des Subnetzes gleichzeitig ab. Auf einem geteilten Medium ist das ein Stoß, der eine ohnehin ausgelastete Verbindung über die Kante schieben kann. WLAN gehört dazu, eine Funkstrecke zwischen zwei Access Points, Powerline. Bisher hörte in diesem Fall nichts auf.

Gemessen im eigenen Heimnetz: 23 Sekunden nach Beginn einer Dauerlast antwortete das Gateway nicht mehr. Der Scan lief weitere 40 Minuten. Das verlängert einen Ausfall, statt ihn zu lindern. Und es ist der schlimmere Teil des Problems: nicht der einzelne Scan, sondern dass niemand ihn stoppt.

Ein laufender Scan beobachtet jetzt das Gateway und bricht ab, wenn es rund zehn Sekunden gar nicht mehr antwortet. Die Bremse ist nur scharf, wenn das Gateway vorher geantwortet hat: Viele Router beantworten Pings an sich selbst grundsätzlich nicht, und dort würde eine bedingungslose Bremse jeden Scan abwürgen. Das wäre der schlimmere Fehler. Sie greift in jeder Intensitätsstufe. Bisher konnte sich nur die adaptive Stufe zurücknehmen, und die war nicht die Voreinstellung.

Zur Einordnung: Nach einer Korrektur an der Funkkonfiguration desselben Netzes richtete dieselbe Last nichts mehr an. Der Scan war der Auslöser auf einem schon gesättigten Kanal, nicht die alleinige Ursache. Eine Software, die fremde Netze abfragt, sollte trotzdem merken, wenn sie eines davon gerade umbringt.

Eine Einstellung, die nichts tat

In der Server-Edition saßen drei Fehler an derselben Stelle.

Vor jedem Scan liest der Dienst seine Einstellungen neu. Dabei las er die Scan-Intensität aus dem Feld der Desktop-App, während er ringsum seine eigenen Felder liest. Beide Editionen teilen sich eine Einstellungsdatei; auf einer reinen Server-Installation ist das Desktop-Feld leer, also fiel die Drossel bei jedem Durchgang auf die Normalwerte zurück. Wer „schonend“ wählte, um eine empfindliche Leitung zu schützen, bekam sie nie. Das Dashboard zeigte weiter „schonend“, während gemessen 128 statt 32 gleichzeitige Proben liefen.

Derselbe Block kopierte außerdem eine veraltete Liste von Schaltern. Ausgerechnet die schweren Sonden fehlten darin: die tiefe Diensterkennung, die für einen einzigen unklaren Port rund 30 Verbindungen öffnet, und der TLS-Fingerabdruck mit zehn weiteren. Genau das, was die schonende Stufe abschalten soll.

Und die Funktion, die eine Intensität anwendet, nannte sich im eigenen Quelltext maßgeblich für alle Stufen, räumte aber ein Feld nur in einem Zweig auf. Ein Wechsel weg von der adaptiven Stufe blieb adaptiv.

Statt die Kopierliste zu ergänzen, wird die Intensität jetzt direkt auf die laufenden Optionen angewandt. Eine Liste, die auseinanderlaufen kann, ist damit weg.

Die Voreinstellung wechselt

Eine Server-Installation, die nie eine Stufe gewählt hat, scannt ab 1.9.9 adaptiv statt normal. Ein unbeaufsichtigter Sammler läuft alle paar Minuten, rund um die Uhr, in einem Netz, das ihm niemand beschrieben hat. Die adaptive Stufe misst das Gateway, während sie arbeitet, und nimmt sich zurück, wenn das Medium leidet. Eine selbst gewählte Stufe bleibt unangetastet, auch ein ausdrückliches „normal“.

Für die Desktop-App ändert sich die Voreinstellung nicht. Dort sitzt jemand davor und löst den Scan selbst aus.

Kleinigkeit am Rande

Ein nicht erreichbarer Host schreibt keine Zeile mit dem Wort „FATAL“ mehr ins Protokoll. Ein Durchlauf trifft dutzende leere Adressen, und die verwendete Ping-Bibliothek meldete jede einzelne so, während sie weiterlief. In einem Server-Protokoll standen davon 115.000 Zeilen aus drei Wochen.

Ein Nutzer formulierte es als Gefühl: „Im Server ist die Erkennung von Namen nicht so gut, ich sehe oft nur die IP-Adresse." Gefühle über Software treffen meist das Symptom und selten die Ursache, also wurde zuerst gezählt. In seinem eigenen Netz, 99 Geräte: 37 Zeilen trugen eine nackte Adresse als Titel, und 30 davon gehörten zu Geräten, die der Scan längst nach Hersteller und Typ bestimmt hatte. Jeder Dell. Jeder Brother. Das QNAP.

Die offensichtliche Hälfte war die Leiter, die aus einem Gerät einen Zeilentitel macht. Desktop-App und Handy benutzen dieselbe seit Langem: der eigene Name zuerst, dann der saubere Name des Geräts selbst, dann das Modell, dann Hersteller plus Typ. Und nur für ein Gerät, das gar nichts preisgibt, ein stabiles „Unbekannt (0B7B)" nach der Endung seiner MAC-Adresse. Das Server-Dashboard hörte beim Hostnamen auf und schrieb die Adresse hin. Jetzt geht es die ganze Leiter, und es schneidet dabei die lokale DNS-Zone ab: „udr7.local" heißt schlicht udr7.

Die andere Hälfte war schwerer zu sehen, weil sie sich hinter einem Feld versteckte, das gefüllt aussah. Der Scanner bestimmt die strukturierten Namensteile eines Geräts, während er es anreichert. Alles, was diese Anreicherung überspringt, bekommt sie nie: was beim Start aus dem Speicher kommt, Geräte, die die Anreicherung ausgelassen hat, und Zeilen, deren Name erst später aus ARP oder der Client-Liste des Routers eintrifft. Die Desktop-App rechnet diese Teile beim Ausliefern eines Geräts immer neu. Es ist eine Zeile, im eigenen Quelltext als Sicherheitsnetz beschrieben. Der Server hatte kein Gegenstück und lieferte deshalb aus, was die letzte Anreicherung zufällig hinterlassen hatte. Gemessen: Das Feld war bei 6 von 99 Geräten gesetzt statt bei 56, und „udr7.local" gehörte zu den Geräten, die er als namenlos auslieferte. Jetzt rechnet er sie bei jeder Änderung neu, auch für die Geräte, die während des allerersten Scans einzeln hereinkommen.

Was nicht zurückkommt, ist ein Name, den der Scanner absichtlich verworfen hat. Ein mDNS-Gerät, das mit seiner eigenen MAC-Adresse als Hostname antwortet, sagt einem nicht, wie es heißt, und diese Zeichenkette hinzuschreiben ist schlechter als zu schweigen; solche Geräte erscheinen weiterhin nach Hersteller und Typ. Dafür gibt es einen eigenen Test, denn ein Neuberechnen ist genau die Art Änderung, die so etwas stillschweigend wiederbeleben würde.

Nach der Änderung bleibt in demselben Netz keine nackte Adresse übrig: 92 Zeilen tragen einen echten Namen, sieben lauten „Unbekannt" mit der MAC-Endung. Genau das steht einem Gerät zu, das weder Namen noch Hersteller preisgibt.

Das Release bringt ein zweites Stück Nachholarbeit. Wenn die KI ein Gerät identifiziert, füllen Desktop-App und Handy die Felder, die man leer gelassen hat: Name, Tags, Kommentar, Typ. Sie fassen nie an, was man selbst getippt hat, und sie tun es nur, wenn das Modell sich sicher nennt. Der Server gab die Antwort zurück und ließ jedes Feld leer. Wer dasselbe Gerät im Dashboard identifizierte, stand danach mit einer unbenannten Zeile da. Jetzt füllt er sie, und die Entscheidung darüber, was wann geschrieben werden darf, liegt an einer gemeinsamen Stelle statt in einer Kopie je App. Anders bleiben zwei Umsetzungen beim Wort „sicher" nicht ehrlich. Das Dashboard zeigt die gefüllten Werte in dem Moment, in dem sie geschrieben werden, statt erst beim nächsten Scan, der in einem ruhigen Netz Minuten entfernt sein kann.

Das Release von gestern hat dem Installer beigebracht zu warten. Warten ist aber nur die halbe Arbeit: Er muss es auch sagen. Dieselbe Person startete das Update erneut, sah „Preparing (stopping any previous version) ..." und danach knapp eine Minute lang gar nichts, und brach ab. Zweimal, bis sie es durchlaufen ließ. Ein Installer, der fünfundvierzig Sekunden verstummt, sieht genauso aus wie einer, der abgestürzt ist.

Jetzt meldet er alle fünf Sekunden, wie lange er schon wartet und wie lange er zu warten bereit ist. Auch die Stopp-Anfrage selbst hat eine Obergrenze bekommen. deviceshelf-server -service stop blockiert, bis der Dienstmanager antwortet, und ein Server, der mitten im Scan feststeckt, antwortet nie. Das Wartebudget begann also erst nach einem bereits unbegrenzten Warten. Beide Enden sind jetzt begrenzt, und erst das gibt dem Schritt einen schlimmsten Fall, den man benennen kann.

Darunter lag die eigentliche Ursache. Das Stoppen des Dienstes wartete darauf, dass der laufende Scan sich abwickelt, und ein Portscan läuft weit länger als die dreißig Sekunden, die Windows einem Dienst für die Antwort auf eine Stopp-Anfrage einräumt. Danach verweigert der Dienstmanager jede weitere Steuerungsmeldung. Genau daran sind die Updates gescheitert. Der Dienst sichert seinen Zustand jetzt und lässt nach acht Sekunden los. Gemessen auf der Maschine, von der die Meldung kam, mit absichtlich laufendem Scan: dreizehn Sekunden für das ganze Update gegen einen aktuellen Server, sechsundvierzig gegen einen alten, und die ganze Zeit über kommentiert.

Die dritte Meldung betraf das Dashboard. Nach einem Start zeigte es nichts, bis der komplette Scan durch war. In einem gut gefüllten Netz ist das eine Minute und mehr leerer Bildschirm, und direkt nach einer Installation liest sich das als Produkt, das nicht funktioniert. Der erste Scan eines Prozesses schiebt Geräte jetzt in die Liste, während er sie findet, und trägt das Netz gleich mit, so wie die Desktop-App es immer schon gemacht hat. Sechsundfünfzig Geräte nach 1,6 Sekunden statt nichts für zwei Minuten.

Die vierte ist älter und leiser. Ein Gerät, das auf ARP antwortet, aber weder auf Ping noch auf einen der geprüften Ports, galt dem vollen Scan als anwesend und dem Dreißig-Sekunden-Präsenztest als abwesend. Zwei Urteile, die sich dauerhaft widersprechen, ergeben ein Gerät, das dauerhaft flappt: zweiunddreißig Ereignisse in achtzig Minuten für einen LG-Fernseher im Standby. Der Präsenztest stellt jetzt dieselbe Frage wie der Scan, also bleiben ein Fernseher im Standby, ein schlafender Drucker und alles hinter einer Firewall, die ICMP verwirft, da, wo sie hingehören. Echte Abwesenheiten sind unberührt: Was auf keiner der beiden Ebenen antwortet, wird weiterhin offline gemeldet.

Für die Desktop-App gibt es eine Kleinigkeit. In der Kopfzeile konnte „Nicht gescannt" über einer Liste mit hundert Geräten stehen, weil sie das Netz nur aus einem laufenden Scan-Ereignis lernte und nie beim Backend nachfragte, das es längst kannte. Jetzt fragt sie nach. Und wenn wirklich nichts nachzufragen ist, sagt die Zeile stattdessen, was stimmt: Die Liste ist die gespeicherte, und diese App hat noch selbst nichts gescannt.

Ein Nutzer meldete, die Installation des Windows-Servers mache „immer wieder Probleme", mit dem Protokoll als Beleg: Der Dienst könne zurzeit keine Steuerungsmeldungen annehmen, der Dienst sei zum Löschen markiert, und das Kopieren scheitere, weil die Datei von einem anderen Prozess verwendet werde. Drei Fehler hintereinander, eine Ursache.

Der Installer bat den Dienst zu stoppen, überging die Antwort und kopierte die neue Binary sofort. Nur stoppt der Dienst nicht auf bloße Bitte. Ein Scan in Arbeit hält ihn zehn Sekunden und länger in STOP_PENDING, Windows lehnt in dieser Zeit weitere Steuerbefehle ab, und die laufende Abbildung sperrt die Datei. Also scheiterte das Update am letzten Schritt — nachdem die Dienst-Registrierung schon entfernt war: keine funktionierende Installation, und ein Dienstname, den Windows weiterhin als halb gelöscht führt.

Jetzt wartet er. Der Stopp wird angefordert, dann prüft der Installer im Sekundentakt bis zu 45 Sekunden lang, ob die Binary wirklich beschreibbar ist, und macht erst dann weiter. Hängt der Dienst tatsächlich fest, wird der Prozess beendet — dasselbe, was ein Administrator von Hand täte —, und wenn selbst das die Datei nicht freigibt, bricht der Installer ab und sagt es: Eine halb geschriebene Server-Binary ist schlimmer als ein Update, das man nach einem Neustart noch einmal startet. Kopieren und Installieren werden mehrfach versucht, weil Windows Dateisperre und gelöschten Dienstnamen erst kurz nach dem Prozessende freigibt. Die Deinstallation hatte dieselbe Lücke und bekommt dieselbe Behandlung.

Dahinter versteckte sich die zweite Hälfte. Der Token, den der Installer am Ende anzeigte, war oft nicht der Token des Dienstes: deviceshelf-server -token durchsucht das Profil des aufrufenden Nutzers vor dem des Dienstes. Auf jeder Maschine, auf der jemand den Server einmal von Hand gestartet hat, wurde dieser alte Token als „dein Token" präsentiert — und er versagt von jedem anderen Gerät im Netz. Derselbe Fehlgriff ließ die Token-Rettung beim Update stillschweigend einen Wert mit sich selbst vergleichen, das Sicherheitsnetz griff also nie. Der Installer liest jetzt zuerst die Token-Datei des Dienstes.

Nachgewiesen auf der Maschine, die die Meldung ausgelöst hat: mit absichtlich laufendem Scan geht das Update durch, und der am Ende angezeigte Token authentifiziert tatsächlich.

Das gestrige Release hörte auf, einen einzelnen verlorenen Ping als Ausfall zu werten. Ein Tag Testen gegen ein echtes Netz zeigte: Das war nur die halbe Geschichte.

Die 30-Sekunden-Probe hatte Geduld gelernt, der volle Scan nicht: Ein Gerät, das aus einer einzigen Sweep-Runde fiel, galt weiterhin sofort als offline. Und aus einer Runde zu fallen ist leicht: Der Test-Pi hier trägt 24 virtuelle Geräte und wird aggressiv gescannt, und er „ging" an einem Nachmittag 31-mal „offline". Das Ereignis-Log verriet es: offline um 14:22:19, online um 14:22:24. Fünf Sekunden. Es gab nie eine Abwesenheit, nur eine verpasste Runde.

Beide Pfade speisen jetzt einen gemeinsamen Zähler. Eine verpasste Sweep-Runde zählt als ein unbeantworteter Check, die Probe eine halbe Minute später darf ihr widersprechen, und erst eine Serie begründet eine Abwesenheit. Ein wirklich verschwundenes Gerät wird trotzdem in etwa neunzig Sekunden erkannt, weil scheiternde Proben auf dieselbe Serie einzahlen. Das Ereignis-Log nennt Anzahl und letzten Check („no answer to 3 consecutive checks; last: full scan") — wer seine Alarme untersucht, liest den Grund, statt ihn zu raten.

Wie viele Checks eine Serie ausmachen, entscheidest du jetzt selbst: Sofort (einer), Standard (drei), Tolerant (sechs). Das gilt global in den Alarm-Einstellungen und pro Gerät in seiner Detailansicht, wo „Wie globale Einstellung" der Standard ist. Die zickige Kamera bekommt Tolerant, die USV Sofort, der Rest erbt. Unter den beiden Reglern rechnet das Dashboard ihren gemeinsamen Effekt vor („Meldung frühestens ~90 s, nachdem das Gerät zuletzt geantwortet hat"), denn zwei Einstellungen, die beide nach „wie schnell" klingen, lesen sich wie Konkurrenten, bis die Rechnung sichtbar ist.

Auch die Benachrichtigungen verschwenden ihre Worte nicht mehr. Der Push über ein Gerät, das sein Besitzer „Einerda" genannt hatte, stellte es als „Raspberry Pi Trading Ltd" vor. Die Namensleiter befragte jeden gemessenen Namen, nur den des Nutzers nie, und der hat überall sonst Vorrang. Der Nachrichtentext wiederholte den Titel, statt die Adresse zu ergänzen. Und die Zusammenfassung nach einem Dienst-Neustart listete fünfundvierzig Alarme als „ERROR:" mit je einer rohen MAC. Alle drei sprechen jetzt wie der Rest des Produkts: zuerst dein Name für das Gerät, im Text die Fakten, die der Titel nicht tragen kann, und Level nur dort, wo eine Warnung sich wirklich von einem Fehler unterscheidet.

Eines noch, das Testern auffallen wird: Die Geräte-Detailansicht im Dashboard speichert jede Änderung sofort, wie es die Desktop-App und die Einstellungen-Seite immer getan haben. Der Speichern-Knopf ist weg, und mit ihm die Frage, ob noch etwas ungespeichert war.

Eine Nutzer-Mail brachte zwei Meldungen, und beide stellten sich als echt heraus.

Sein Brother MFC-J497DW weckte alle fünf Minuten sein Display, genau dann, wenn der DeviceShelf-Server seinen Scan ausführte. Die Ursache ist die SNMP-Frage, die der Scan jedem Gerät stellt. Die meiste Hardware beantwortet sie still; manche Drucker nehmen sie zum Anlass aufzuleuchten. Es gab keinen Weg, ein Gerät davon auszunehmen.

Jetzt gibt es ihn. Jedes Gerät hat einen Schalter in seiner Detailansicht: von aktiven Scans ausnehmen. Ist er gesetzt, schickt DeviceShelf diesem Gerät nichts mehr. Keinen Portscan, keine SNMP-Frage, keine direkten Namensabfragen. Passive Erkennung und der Präsenz-Ping bleiben, das Gerät steht also weiter in der Liste und wird weiter überwacht. Es wird nur nicht mehr ausgefragt.

Die erste Fassung dieses Schalters hatte ein Loch, und allein hätte ich es nicht gefunden. Eine unabhängige Prüfung der Änderung fiel darüber, dass die Namensauflösung schon startet, während der Scan noch läuft, in einem Moment, in dem eine Zeile zwar eine Adresse hat, aber noch keine MAC. Ein Schalter, der an der MAC hängt, konnte dort nie greifen, und der Drucker wäre über genau diesen Pfad doch gefragt worden. Der Ausschluss greift jetzt zusätzlich über die zuletzt bekannte Adresse. Und ein Test beobachtet die Leitung; er schlägt fehl, sobald ein ausgenommenes Gerät eine Frage bekommt.

Die zweite Meldung: sein Unraid-Server, rund um die Uhr in Betrieb, ging in ntfy immer wieder offline und kam zurück. Der Mechanismus war beschämend einfach. Zwischen den vollen Scans pingt der Server bekannte Geräte alle 30 Sekunden, und ein einziger unbeantworteter Ping (750 Millisekunden Geduld, ein Versuch) zählte mit den Standardeinstellungen als Ausfall. Eine Maschine, die ICMP kurz hintanstellt, oder ein WLAN-Sprung, der ein Paket verliert, erzeugte genau das Muster aus seiner Mail. Eine Abwesenheit braucht jetzt drei Fehlversuche in Folge. Ein einzelner verlorener Ping verschmutzt die Verfügbarkeits-Statistik nicht mehr. Und jedes Offline-Ereignis nennt, wie es festgestellt wurde, „missed full scan" oder „no reply to 3 probes". Sollte danach noch etwas flattern, sagt das Ereignis-Log, wo man suchen muss.

Beim Absichern mit Tests kam ein dritter Defekt ans Licht: Den Schalter „Benachrichtigungen stummschalten" pro Gerät bietet das Dashboard seit jeher an. Der Server speicherte ihn und ignorierte ihn im Moment der Zustellung; stummgeschaltete Geräte meldeten trotzdem. Das ist behoben, mit der Semantik, die man erwartet: Der Eintrag in der Zeitleiste, der Alarmzustand und der Ausfall-Datensatz bleiben. Stummgeschaltet ist das Pushen, nicht die Überwachung.

Außerdem in 1.9.4: Die Icon-Suche funktioniert jetzt in jeder Sprache über den vollen Satz, und die Auswahl lässt sich nach Gruppen durchblättern statt nur durchsuchen. Eigene Icons und eigene Gerätetypen erreichen das Server-Dashboard und das Telefon, selbst angelegte Typen stehen vor den eingebauten. Eine Maschine mit zwei Netzwerkkarten ist eine Zeile statt zwei, und ein selbst zugewiesener Typ überlebt dieses Zusammenfassen. Der Server schreibt seine Ablage mit der halben CPU-Last. Eine laufende Paketaufzeichnung stoppt von selbst, wenn niemand zusieht.

Ein Nutzer meldete sich mit vier Gerätetypen, für die er kein Icon fand: Mähroboter, Saugroboter, Kaffeemaschine, Thermomix. Nebenbei erwähnte er, dass Tablet und Smartphone dasselbe Bild zeigen.

Ich nahm an, die Icons existierten nicht, und fing an, den Aufwand für eine Upload-Funktion zu schätzen. Sie existierten. Der Satz besteht aus Tabler und Fluent, beide MIT-lizenziert, und allein Tabler hat 5130 Icons — von denen 56 eingebunden waren. Die Datei, die sie hält, trägt im Kopf „AUTO-GENERATED", und nichts im Repository konnte sie erzeugen. Ein Icon hinzuzufügen hieß, 2,3 MB minifiziertes JSON von Hand zu bearbeiten, also hat es nie jemand getan.

Den Bauschritt gibt es jetzt. Der Satz umfasst 2107 Icons, die Datei wuchs um 0,3 MB, weil die farbige Hälfte sie ohnehin dominiert. Saugroboter, Mähroboter, Kaffeemaschine und Küchengerät sind eingebaute Gerätetypen in allen sieben Sprachen, auf Desktop, Server und Telefon. „Tablet" zeigte bisher auf ein Notizbuch 📓 — daher die Verwechslung mit dem Handy; beide haben jetzt Icons, die tatsächlich diese Geräte zeigen.

Drei Dinge verweigert der Generator, jedes wegen eines Fehlers, der sonst still passiert:

Kein Icon darf verschwinden. Ein selbst angelegter Gerätetyp speichert den Namen des Icons. Fiele es aus dem Satz, stünde in dieser Zeile ein leeres Kästchen — Daten auf dem Rechner des Nutzers, die wir nicht sehen und nicht migrieren können. Jedes Icon, das im Satz war, bleibt darin, auch gegen den Filter. Entfernt Upstream eines, bricht der Bau ab und nennt es, statt die Lücke auszuliefern.

Markenlogos bleiben draußen. Firmenzeichen sind eine rechtliche Frage, die wir nicht beantwortet haben, und vierhundert davon in die App zu packen ist genau das, worum es bei dieser Frage geht. Nebenbei vergifteten sie die Suche: „cup" traf eine Automarke.

Der sofort geladene Teilsatz wird mitgeführt. Der volle Satz lädt bei Bedarf; ein Icon, auf das ein eingebauter Typ zeigt, muss im kleinen, sofort geladenen Teil liegen — sonst zeigt jedes Gerät dieses Typs ein leeres Feld, bis man zufällig den Typ-Manager öffnet. Genau das hatte mein erster Versuch ausgeliefert, und nichts hat gewarnt. Dafür gibt es jetzt einen Test.

Barrierefreiheit als Bedingung

Von hier geht nichts mehr raus, ohne EN 301 549 Kapitel 11 zu bestehen — die Norm, auf die der European Accessibility Act und das deutsche BFSG verweisen und die WCAG 2.1 Stufe AA wörtlich übernimmt. Jede Ansicht, hell und dunkel, dazu das Detailfenster, 200 % Zoom, die Rechts-nach-links-Fassung, die Erreichbarkeit jeder Ansicht per Tastatur und ein sichtbarer Fokusring.

Der erste Lauf fand 21 echte Barrieren. Sechzehn davon kritisch: Schalter und Auswahllisten, die ein Screenreader als „Ankreuzfeld" ansagte, ohne jeden Hinweis worauf — in den Einstellungen, im Netzwerk, bei der Bandbreite, in der Diagnose. Wer einen Screenreader nutzt, konnte diese Bedienelemente nicht verwenden, und ich wusste es nicht.

Fünf waren Kontrastfehler, darunter weißer Text auf der Akzentfarbe mit 3,2:1 im dunklen Thema, wo 4,5:1 nötig sind. Behoben auf Ebene der Farbtokens statt pro Element, damit es in beiden Themen hält.

Die Prüfung wäre um ein Haar als Feigenblatt ausgeliefert worden. Sie stellte das Thema über einen Wert ein, den die App gar nicht liest — die dunkle Hälfte maß also helle Farben und meldete dieselben vier Befunde doppelt. Jetzt setzt sie, was die App wirklich liest, und sichert das Ergebnis zu, damit daraus nicht wieder unbemerkt ein Doppellauf wird.

Und sie sagt bei jedem Lauf, was sie nicht kann: Automatische Regeln erreichen etwa ein Drittel der echten Barrieren. Ob eine Beschriftung aussagekräftig ist, ob die Vorlesereihenfolge Sinn ergibt, ob eine Meldung zum richtigen Zeitpunkt kommt — dafür braucht es einen Menschen mit Tastatur und Screenreader. Ein Drittel, gemessen an jeder Ansicht vor jeder Auslieferung, ist erheblich mehr wert als ein guter Vorsatz. Dasselbe wie barrierefrei ist es nicht.

Ein Netzwerk-Scanner hat ein Versprechen zu halten: er schaut, er fasst nicht an. DeviceShelf hat dieses Versprechen gebrochen, und ich sage offen, wie.

Die Diensterkennung nutzt fingerprintx. Dessen SSH-Modul hört nicht beim Banner auf, das ein Server von sich aus sendet. Um zu melden, ob Passwort-Anmeldung aktiviert ist, versucht es eine echte Anmeldung als admin/admin und schiebt eine Tastatur-interaktive Runde nach, in der es jede Rückfrage mit password beantwortet. DeviceShelf hat das gegen jeden Port 22 im Netz laufen lassen, bei jedem Scan.

Was das gekostet hat, gemessen an einem Raspberry Pi im Labor: 146 bis 237 Einträge Failed password for admin pro Stunde, rund um die Uhr, von einer einzigen laufenden Kopie. OpenSSH 9.8 antwortet darauf mit Sperren pro Quelladresse und weist den scannenden Rechner ab — man wird also vom eigenen Scanner aus dem eigenen Gerät ausgesperrt. Genau das ist mir dreimal passiert, während ich der Sache nachging, und ich habe zweimal den Pi verdächtigt, bevor ich bei uns nachgesehen habe. Jedes Angriffserkennungssystem und jedes fail2ban liest diese Einträge als Brute-Force-Versuch, und zwar zu Recht.

Das Modul ist jetzt namentlich gesperrt. Die SSH-Erkennung bleibt, und dieser Unterschied ist der eigentliche Punkt: Ein Server nennt seine Version unaufgefordert, bevor sich irgendwer angemeldet hat. Zu lesen, was ein Gerät von sich aus preisgibt, ist Fingerprinting. Ein Passwort zu senden, um das niemand gebeten hat, ist Raten. Nur das Erste gehört in einen Scanner.

Wer 1.9.1 oder älter einsetzt: bitte aktualisieren. Wenn ein Gerät angefangen hat, den eigenen Rechner abzuweisen, ist das vermutlich der Grund.

Die Menüleiste

Auf macOS standen dort die Buchstaben „DS" in einem festen Feld, und das Symbol konnte nichts außer das Fenster öffnen. Jetzt zeigt es, wofür ein Blick da ist: wie viele Geräte gefunden wurden und wie viele online sind, wie alt der letzte Scan ist, und was ein DeviceShelf Server auf diesem Rechner gerade tut — samt der Adresse, unter der er antwortet.

Es startet und stoppt diesen Server auch. Auf macOS läuft der Server als Systemdienst mit KeepAlive: ihn in der Aktivitätsanzeige zu beenden bringt gar nichts, launchd startet ihn innerhalb einer Sekunde neu. Es funktioniert nur launchctl bootout system/com.deviceshelf.server mit Administratorrechten, und das ist kein Wissen, das eine Anwendung voraussetzen darf. Der Knopf erledigt es über den üblichen Systemdialog, und der Befehl steht daneben für alle, die lieber tippen.

Das Schließen des Fensters versteckt es nun und lässt die App hinter dem Symbol weiterlaufen — die übliche Anordnung auf macOS und die einzige, die ein Menüleisten-Symbol überhaupt sinnvoll macht. In den Einstellungen gibt es dafür eine Auswahl, und eine Option, DeviceShelf beim Anmelden zu starten.

Geräte, die der Scan sieht, aber nicht anfassen kann

Ein Gerät in einem anderen Subnetz, im Gastnetz oder hinter einem WLAN-Repeater beantwortet einen Ping, hinterlässt aber keinen ARP-Eintrag — es kam also ohne MAC-Adresse an. Alles, was man einem Gerät anhängen kann, wird über die MAC gespeichert: der eigene Name, die Notiz, die Tags, der Favorit, die Stummschaltung, Wake-on-LAN, die Verfügbarkeitshistorie. Ohne MAC war so ein Gerät dauerhaft nicht bearbeitbar, und nichts sagte warum.

Der Router kennt diese MAC — sie steht in der Client-Liste, die DeviceShelf ohnehin liest. Sie wird jetzt übernommen, zusammen mit dem Namen, auf Desktop und Server. Die Telefon-App macht das seit ihrem ersten Tag, weil iOS überhaupt nicht ARPen kann; die beiden anderen ziehen nach. Wo auch so keine MAC zu finden ist, sagen App und Dashboard jetzt, was fehlt und was es beschaffen würde.

Barrierefreiheit als Bedingung

Nichts wird mehr ausgeliefert, ohne EN 301 549 Kapitel 11 zu bestehen — die Norm, auf die der European Accessibility Act und das deutsche BFSG verweisen und die WCAG 2.1 Stufe AA übernimmt. Jede Ansicht, hell und dunkel, dazu das Detailfenster, 200 % Zoom, die Rechts-nach-links-Fassung und die Erreichbarkeit per Tastatur.

Der erste Lauf fand 21 echte Barrieren. Sechzehn davon kritisch: Schalter und Auswahllisten, die ein Screenreader als „Ankreuzfeld" ansagte, ohne jeden Hinweis worauf — in den Einstellungen, im Netzwerk, bei der Bandbreite, in der Diagnose. Fünf waren Kontrastfehler, darunter weißer Text auf der Akzentfarbe mit 3,2:1 im dunklen Thema. Alles behoben.

Die Prüfung sagt bei jedem Lauf, was sie nicht kann: Automatische Regeln erreichen etwa ein Drittel der echten Barrieren. Ob ein Name aussagekräftig ist, ob die Vorlesereihenfolge Sinn ergibt, ob eine Meldung zum richtigen Zeitpunkt kommt — dafür braucht es weiterhin einen Menschen mit Tastatur und Screenreader. Aber ein Drittel, gemessen an jeder Ansicht vor jeder Auslieferung, ist deutlich mehr wert als ein guter Vorsatz.

Außerdem

Die Switch-Topologie liest die Forwarding-Tabelle vor dem CDP-Durchlauf. Auf einem TP-Link Omada SG2008P ist der SNMP-Agent nach dem CDP-Durchlauf etwa vier Sekunden lang nicht antwortfähig, und das Auslesen der Tabelle lief bisher genau in dieses Fenster: 45 Einträge, wenn zuerst gelesen wird, null danach.

Die Update-Prüfung läuft weiter, während die App offen ist, und kennzeichnet ein Update als dringend, wenn es das ist. Eine Version wie diese sollte nicht darauf warten, dass jemand die App neu startet.

Jedes Gerät, das eine Adresse anfordert, sagt dabei, welche DHCP-Optionen es haben will, und in welcher Reihenfolge. Apple fragt anders als Windows, und eine Lampe fragt vier Optionen ab, wo ein Mac dreizehn abfragt. DeviceShelf schreibt diese Liste seit Langem mit. Gelesen hat sie nur nie jemand: Der Fingerabdruck ging zu Fingerbank, falls du das eingeschaltet hattest, und sonst nirgendwohin. Jetzt wird er auf deinem Rechner ausgewertet, gegen Regeln, die in der App stecken.

Am meisten gewinnt dabei ausgerechnet das Gerät, das bisher gar nichts hergab. Ein Handy mit privater WLAN-Adresse hat eine MAC, die keinem Hersteller gehört. Die übliche Abfrage liefert also nichts, und daran änderte sich auch nach dem zehnten Scan nichts. Seine DHCP-Anfrageliste sagt trotzdem: Apple.

Zahlen dazu, denn ohne sie ist so eine Behauptung wertlos. Im Repository liegen jetzt 91 echte Geräte als Testfälle, aufgenommen in Netzen, die mir gehören, und anonymisiert: Handys, Notebooks, Router, Access Points, ein Switch, zwei NAS, Kameras, Lautsprecher, ein Fernseher, ein Kühlschrank, Drucker, IoT-Bridges, Server. Jeder Fall enthält, was tatsächlich beobachtet wurde, und dort, wo ich es unabhängig belegen konnte, was das Gerät wirklich ist. Gegen diese Sammlung gemessen stieg der richtig erkannte Gerätetyp von 30 auf 43 von 43 beurteilten, und die 11 Fehlzuordnungen sind verschwunden. Der Hersteller stimmt bei 32 von 33 statt bei 21 und ist überhaupt bei 83 der 91 Geräte bekannt statt bei 71. Der Produktname stimmt bei 20 von 32 statt bei 10.

Hinter diesen Zahlen stecken Dinge, die schlicht falsch waren. Mein eigener Mac war ein Lautsprecher, weil er AirPlay anbietet und die Regel für Audio vor der Regel für Dateifreigabe lief. Access Points, die AP heißen, waren Router. Beide Bose-Boxen waren „Web-Geräte", weil ihr einziger offener Port ein Webserver ist. Ein Samsung-Kühlschrank war ein Fernseher. Ein Windows-Rechner, der einen Drucker freigibt, war selbst ein Drucker. Zwei eufy-Kameras waren allgemeine Smart-Home-Geräte, obwohl sie ihre Modellnummer nennen.

Die Regeln, die das beheben, lesen dreierlei: die DHCP-Anfrageliste samt Vendor Class, die Namen und Modellangaben, die Geräte über mDNS und SSDP veröffentlichen, und SNMP-Produktmuster unterhalb der Hersteller-Arcs, die wir schon kannten. Jede Regel nennt ihre Quelle, ihre Lizenz und das Datum, an dem sie dazukam. Eine Regel, die nur einen Herstellerpräfix vorweisen kann, wird beim Laden abgewiesen, denn eine OUI benennt einen Chiphersteller und kein Gerät. Nichts davon stammt aus Fingerbank, Satori oder Nmap. Die alte FingerBank-Datenbank ist zwar offene Daten, aber ihre Lizenz knüpft Pflichten an alles, was daraus abgeleitet wird. Deshalb liegt sie auf Eis, bis das sauber geprüft ist, statt still verwendet zu werden.

Eine Netzverbindung kommt dadurch nicht hinzu. Die Regeln sind fest in das Programm eingebaut, die Auswertung ist ein Textvergleich, und Fingerbank bleibt genau das, was es war: aus, solange du keinen Schlüssel einträgst, und selbst dann nur, wenn du danach fragst. Den Schlüssel zu speichern löst nichts aus.

Das Handy liest dieselbe Regeldatei. Wörtlich dieselbe, ins App-Bundle kopiert, abgesichert durch einen Test, der fehlschlägt, sobald die beiden sich um ein Byte unterscheiden. Was dort nicht geht, ist der DHCP-Teil, weil ein Handy den DHCP-Verkehr anderer Geräte nicht mitlesen kann, und die SNMP-Produktabfrage. Das steht so in der Feature-Matrix, statt beschönigt zu werden.

Zwei kleinere Dinge fallen früher auf. Die Geräteliste filtert nach online, offline oder allen und merkt sich deine Wahl. Und die Ausfallliste im Gerätefenster ist nach Tagen gruppiert: Vorher war sie eine einzige durchlaufende Reihe nackter Uhrzeiten, „Down 02:51" sagte also nichts darüber, welche Nacht gemeint war, und ein flatterndes Gerät erzeugte hunderte Zeilen. Jetzt zeigt sie die letzten dreißig nach Datum gruppiert und sagt, wie viele ältere sie weggelassen hat.

Eine Korrektur, die erst mit der Zeit auffällt: Der Server hat einen von Hand gesetzten Gerätetyp überschrieben, sobald frische DHCP-Daten eintrafen. Er stellt deine Wahl jetzt wieder her, so wie der Desktop es immer schon getan hat.

Ein Scan hat bisher die ganze Liste weggeworfen und neu aufgebaut. Der Bildschirm wurde leer, füllte sich wieder, und was dieses eine Mal nicht antwortete, war spurlos verschwunden. Der größte Teil eines Netzes ist von Scan zu Scan derselbe, also bleibt die Liste jetzt stehen und wird im Lauf aktualisiert. Was ein abgeschlossener Durchlauf abgetastet hat, ohne etwas zu hören, wird als offline markiert, und diese Zeile bleibt. So kann die Liste sagen „war da, ist es gerade nicht", statt sie still fallenzulassen. Wer wieder antwortet, ist wieder online.

Drei Dinge tut sie absichtlich nicht. Ein Scan beurteilt nur die Adressen, die er tatsächlich abgetastet hat. Ein Bereichs-Scan über ein Subnetz sagt also nichts über ein Gerät in einem anderen. Ein abgebrochener Scan beurteilt gar nichts: er hat einen unbekannten Teil seines Bereichs geprüft, und das als „alles andere ist weg" zu lesen, würde die halbe Liste ausgrauen. Und ein Gerät, das nach einer neuen DHCP-Lease von einer anderen Adresse antwortet, hinterlässt an der alten keine Geisterzeile. Sonst stünde eine Maschine zweimal da, einmal offline an einer Adresse, an der nichts mehr ist.

Das Sortieren funktioniert wieder. Nach Adresse wurde als Text sortiert, und da steht .100 vor .9. Schlimmer noch: die Ordnung war nicht vollständig. Zeilen, die die gewählte Spalte gleich nannte, kamen in der Reihenfolge heraus, die die Sortierung zufällig hinterließ, und die ändert sich, sobald man eine Quelle ein- oder ausschaltet. Bei einer langen Liste verwürfelte sie sich sichtbar ohne Anlass. Jeder Vergleich endet jetzt auf etwas, das pro Zeile eindeutig ist. Auf dem Handy kommt dazu, was es nie hatte: aufsteigend und absteigend, über Neustarts gemerkt, mit der Richtung für den Screenreader und gespiegeltem Symbol, damit man sie sieht, ohne das Menü zu öffnen.

Zeilen wechseln auch nicht mehr die Adresse. Eine Maschine, die auf mehreren eigenen Adaptern antwortet, ist eine Zeile. Welche ihrer Adressen die behielt, entschied die Reihenfolge, in der die Geräte zufällig ankamen: auf dem Desktop zufällig, auf dem Handy vom Scan abhängig. Dasselbe unveränderte Netz antwortete also mal „der Mac ist hier" und mal „dort". Weil die Liste nach Adresse geführt wird, ist das eine verschwindende und eine woanders auftauchende Zeile. Die Zusammenfassung sagt jetzt ausdrücklich, welche Adressen eine Zeile aufgenommen hat, es muss also nichts geraten werden, und ein Gerät, das eine dieser Adressen übernimmt, bekommt sofort eine eigene Zeile, statt zu warten.

Zeilen ohne Favoriten-Stern fluchten wieder mit dem Rest. Geräte, die ein Collector gemeldet hat, haben hier nichts umzuschalten und bekommen an der Stelle des Sterns einen Platzhalter. Der war neunzehn Pixel schmaler als der Stern, wodurch Symbol und Name jeder solchen Zeile zu weit links standen.

Das Server-Dashboard wählt sein Gateway jetzt nach Adresse statt nach dem, dessen Prüfung zuerst fertig war. Diese Wahl entscheidet, ob die Hosts hinter einem Router, der für sie ARP beantwortet, eigene Zeilen bekommen. Dasselbe Netz konnte also von Takt zu Takt eine andere Zeilenzahl zeigen, und noch eine andere als der Desktop.

Dahinter: Desktop, Server und Handy tragen je eine eigene Kopie dieser Regeln, und die waren auseinandergelaufen, ohne dass ein einziger Test rot wurde, weil nichts sie miteinander verglich. Zwei gemeinsame Beschreibungen liegen jetzt im Repository, und jede Laufzeit prüft sich in ihrer eigenen Testsuite gegen dieselbe Datei. Wo die beiden Clients absichtlich abweichen, ist die Abweichung aufgeschrieben und wird ebenfalls geprüft. Eine Regel, die absichtlich abweicht und nicht festgehalten ist, sieht genauso aus wie eine, die abgedriftet ist.

Das Handy braucht jetzt iOS 15. Apple nimmt ab Frühjahr 2027 nichts darunter mehr an, und es jetzt zu tun kostet die wenigsten Menschen. Heraus fällt nur Hardware, die kein iOS 15 bekommen kann: iPhone 6, 6 Plus, 5s, iPad Air 1, iPad mini 2. Alles ab iPhone 6s bleibt dabei.

Ein Router, der dich abweist, sagt jetzt warum. Der Verbindungstest hatte für jeden Fehlschlag dieselbe Antwort, und die nannte zuerst das Passwort. Das schickte Leute in die falsche Richtung: Ein GL.iNet-Besitzer hat sein Passwort zweimal geändert, aber sein OpenWrt gibt die Schnittstelle, mit der wir reden, überhaupt nicht her. Kein Passwort hätte je funktionieren können. Nicht erreichbar, keine Schnittstelle, abgewiesen, keine Daten und keine passende Marke sind jetzt verschiedene Antworten. OpenWrt liefert seine eigene Diagnose, die übrigen Marken fallen auf eine Erreichbarkeitsprüfung zurück, die immerhin „gar keine Antwort“ von „hat geantwortet und nein gesagt“ trennt. Eine geratene Diagnose wäre schlimmer als eine ehrliche grobe.

Vier Marken muss man am Router erst freischalten, und die Auswahl sagt das jetzt an Ort und Stelle: ubus bei OpenWrt, ein API-Schlüssel statt des Kontopassworts bei UniFi, der Schalter für Anwendungen in der FRITZ!Box, www-ssl bei MikroTik. Die anderen dreizehn zeigen nichts statt eines leeren Kastens. Auch der Hilfetext verkauft die Funktion nicht länger unter Wert und verspricht keine Switch-Ports mehr für jede Marke, weil nur UniFi sie meldet. Was du bekommst: Geräte, die die Suche gar nicht erreicht (schlafende Telefone, alles hinter einer Firewall, andere VLANs), die Namen aus der DHCP-Tabelle des Routers, und ob eine Adresse geliehen oder fest reserviert ist.

Das Telefon sagt dasselbe mit denselben Worten. Es hat einen eigenen Router-Client und einen eigenen Katalog, also antwortete es weiterhin auf jeden Fehlschlag mit „prüfe die Zugangsdaten oder den Router-Typ". Wer beide Geräte in der Hand hält, hätte über einen Router zwei verschiedene Geschichten gehört.

Von allen siebzehn Marken liegen jetzt aufgezeichnete Antworten vor, die durch die Go- und die Dart-Umsetzung gleichermaßen laufen, und das hat drei Defekte zutage gefördert. Ein Peplink-Client, der nicht verbunden ist, zählt nicht mehr als anwesend. Ein Netgear-Gerät, dessen MAC sich nicht lesen lässt, verschwindet nicht mehr aus der Liste. Und ein UniFi-Controller auf Network 9.x meldet den Switch-Port, den er tatsächlich benutzt, statt des Feldes, das ältere Firmware verwendete.

Schwellenwert-Prüfungen verhalten sich jetzt wie jede andere Einstellung. Bisher lagen sie nach jedem Neustart ein ganzes Überwachungsintervall still. Bei einem Takt von fünfzehn Minuten heißt das: fünfzehn Minuten eine Prüfung, die scharf aussieht, nichts misst und den Alarm nicht auslösen kann, für den es sie gibt. Außerdem hatten sie einen Speichern-Knopf, den sonst nichts hat, sodass eine getippte, aber nicht bestätigte Änderung verworfen wurde, ausgerechnet dort, wo eine verlorene Änderung heißt, dass ein Alarm still aufhört hinzusehen. Die Felder speichern jetzt, sobald du sie verlässt, und die Statuszeile wird einem Screenreader vorgelesen.

Eine Prüfung hält auch fest, was sie gemessen hat. Vorher wurde das Ergebnis ausgewertet und weggeworfen, also stand in der Zeile für immer ein Strich mit grauem Balken, und als Status kam „up“, egal was gemessen wurde. Und in der Überwachungsliste gibt sich eine Prüfung nicht mehr als Gerät aus: Jemand fragte nach einem Gerät namens „Test“, das es in keinem Netz gibt. Eine Prüfung auf localhost saß zwischen wlan0 und einem NAS, mit Gerätesymbol und ohne jede Kennzeichnung. Prüfungen haben jetzt eine eigene Gruppe, ein eigenes Symbol und ihre Art neben dem Namen, als Text, weil Farbe allein weder einen Screenreader-Nutzer noch jemanden mit Farbsehschwäche erreicht.

Desktop und Server sind 1.7.9, die mobilen Apps 1.3.9. Vorhandene Lizenzen gelten weiter, an den Datenformaten hat sich nichts geändert.

Eingetragene Bereiche werden endlich durchsucht. Ein Subnetz im Suchbereich-Feld bewirkte bisher gar nichts: Der Lauf war nach Sekunden vorbei und fand nichts, ohne jeden Hinweis, dass das Feld ignoriert worden war. Auf dem Server hatte dieselbe Einstellung den umgekehrten Defekt: Ein eingetragener Bereich ersetzte das eigene Netz der Maschine, statt dazuzukommen. Wer ein geroutetes Subnetz eintrug, nahm dem Server damit das Netz weg, in dem er selbst steht. Beides ist behoben. Und wenn ein Bereich zu groß ist oder einen Eintrag enthält, der sich nicht lesen lässt, sagt die App das und nennt, was sie verworfen hat, statt stillschweigend weniger zu durchsuchen als bestellt.

Das Fenster scrollt nicht mehr. Auf macOS konnte die Symbolleiste über den oberen Rand hinausfahren, mitsamt dem Suchen-Knopf, und es gab keinen Scrollbalken, der sie zurückgeholt hätte. Das Dashboard fragt außerdem nicht mehr nach einem Login, das du längst eingetippt hast.

Alarme werden jetzt stummgeschaltet statt quittiert. Ein stummgeschalteter Alarm verlässt die Liste, statt darin liegen zu bleiben, es gibt ein Alle-stummschalten, und die Liste sortiert sich nicht mehr um, während du darin arbeitest. Beide Geräte-Drawer nehmen Tastatureingaben an und lesen sich für einen Screenreader korrekt vor, und beim Schließen kehrt der Fokus zu der Zeile zurück, aus der du gekommen bist.

Zwischen 1.7.3 und dieser Version gingen vier Punktreleases ohne Beitrag raus, alle mit demselben Thema: eine Maschine, eine Zeile. 1.7.4 fragt Geräte nach ihrem eigenen Namen, sodass ein Telefon mit privater WLAN-Adresse oder ein Laptop mit abgeschalteter Freigabe einen Namen zeigt statt einer nackten Adresse, und die OS-Spalte sagt iOS, iPadOS, macOS, tvOS oder Android, wo sie vorher alles in einen Topf warf. 1.7.5 bis 1.7.7 falten die mehreren Adressen einer Maschine in eine einzige Zeile (ein Rechner mit virtuellen Maschinen, ein NAS, das von seinen Container-Schnittstellen antwortet), und zwar egal, wer das Gerät gesehen hat: die lokale Suche, ein Collector oder beide. Deine Namen, Kommentare und Tags überstehen das Falten, und eine Maschine in deinem eigenen Netz behält Wake-on-LAN und ihre übrigen Aktionen auch dann, wenn ein Collector sie zusätzlich meldet.

Desktop und Server sind 1.7.8, die mobilen Apps 1.3.8. Vorhandene Lizenzen gelten weiter, an den Datenformaten hat sich nichts geändert.

Bisher gab es zwei Gerätetabellen. Die eine hatte konfigurierbare Spalten, Filter, Favoriten und Sortierung und zeigte die Suche dieses Rechners. Die andere steckte in der Remote-Ansicht, hatte sieben feste Spalten und keine Aktionen, und ein Klick auf die Quellen-Pille brachte dich dorthin. Ab 1.7.3 gibt es eine Tabelle. Die Pille ist eine Reihe von Schaltern: die Suche dieses Rechners, jeder eingerichtete Collector, jede Kombination daraus, und ab acht Einträgen kommt ein Suchfeld dazu. Die Wahl tauscht die Zeilen an Ort und Stelle, jede Zeile trägt ihre Herkunft mit, und diese Herkunft ist eine Spalte, nach der sich sortieren und filtern lässt. Schaltest du die letzte Quelle ab, fällt die Liste auf die lokale Suche zurück, statt leer und unerklärt dazustehen. Ein Gerät, das ein Collector gemeldet hat, bleibt nur zum Ansehen: Aufwecken, Ports prüfen oder eine Verbindung aufbauen würde das treffen, was diese Adresse in deinem eigenen Netz belegt, nicht den Rechner, über den du gerade liest.

Die Sicherheitsanalyse folgt derselben Wahl. Sie hatte weiterhin „die Geräte" beim Backend abgefragt, also die Suche dieses Rechners, während die Liste längst auf einen Collector zeigte. Ein Bericht über das eine Netz stand über einer Liste aus dem anderen, ohne dass jemand die beiden auseinanderhalten konnte. Zwei Zahlen in ihrer Zusammenfassung stimmten außerdem nicht. „Geräte mit Portdaten" ließ jeden Hinweis gelten, einen mDNS-Dienstnamen oder ein Zertifikat eingeschlossen. Ein Gerät, dessen Ports nie jemand geprüft hatte, zählte also trotzdem als Gerät mit Portdaten, und eine Null las sich wie Pech, obwohl die ehrliche Antwort war, dass niemand hingeschaut hatte. Portgeprüfte Geräte werden jetzt getrennt gezählt, und die Ansicht sagt, warum es keine gibt. Und der Risiko-Score fiel, sobald du einen Collector dazunahmst, weil dessen Geräte nie auf Ports untersucht worden waren und im Nenner mitliefen, als wären sie sauber zurückgekommen. Mehr von deinem Netz anzusehen kann es nicht sicherer machen, deshalb werden ungeprüfte Geräte als übersprungen ausgewiesen, statt die Zahl stillschweigend zu schönen.

Auf dem Server las sich „Update verfügbar" gleich, ob eine Version nur eine Beschriftung geradezog oder ob die Fassung, die bei dir läuft, defekt ist. 1.7.2 ist genau der Fall: Diese Version brachte eine CVE-Datenbank mit, der das ganze Jahr 2025 fehlte, meldete dadurch weniger Funde und sah gesünder aus, als sie war. Das Manifest trägt dieses Urteil jetzt in zwei unabhängigen Feldern: wie sehr die neue Version zählt, und welche Installationen darunter einen bekannten Defekt haben. Der Hinweis sagt, welcher der beiden Fälle vorliegt. Das Update-Panel bot bisher docker compose pull mit einer Fußnote fürs .deb, womit das macOS-.pkg und der Windows-Dienst ganz ohne Befehl dastanden. Der Server ermittelt jetzt aus dem, was jedes Paket hinterlässt, wie er installiert wurde, und zeigt den einen Befehl, der passt. Die Push-Benachrichtigung nutzt dieselbe Logik, denn wer sie über ntfy liest, hat kein Dashboard vor sich.

Auf iPhone und iPad passierte beim Druck auf „Suchen" ohne WLAN gar nichts. Der Startpfad kehrte bei fehlendem Netz stillschweigend zurück, der Knopf ließ sich also endlos drücken, ohne Meldung, ohne Fehler, ohne sichtbare Änderung. Die App hält jetzt fest, warum eine Suche nicht starten konnte, sagt, dass es kein lokales Netz zu durchsuchen gibt, und bietet einen neuen Versuch an; die Kopfzeile sagt es schon vor dem Tippen. Auch ein Suchbereich ohne Adressen wird gemeldet, statt einfach still zu enden. Beide Apps zeigen jetzt auch an, wessen Daten auf dem Bildschirm stehen: das lokale Netz oder den Namen des Collectors samt Verbindungszustand.

Desktop und Server sind 1.7.3, die mobilen Apps 1.3.3. Vorhandene Lizenzen gelten weiter, an den Datenformaten hat sich nichts geändert.

Bisher konnte das Server-Dashboard ein Gerät nur umbenennen. Alles andere, was man festhalten möchte, wurde gespeichert, synchronisiert und angezeigt, ließ sich aber nur in der Desktop-App eintragen: den Gerätetyp, wenn die Erkennung danebenliegt, Tags, eine Notiz, eine Markierung als Favorit, stummgeschaltete Benachrichtigungen. 1.7.2 bringt das alles in den Gerätebereich des Dashboards. Virtuelle Geräte bekommen zusätzlich eine Host-Auswahl. Bei einem Container hinter NAT verrät nichts im Netzwerk, auf welchem Rechner er läuft, also ist die Aussage eines Menschen die einzige Antwort, die es gibt; der Server hat eine solche Aussage längst befolgt und konnte sie nur nirgends entgegennehmen.

Ein Gerät im Dashboard umzubenennen löschte bisher seine Notiz und seinen Typ-Override. Das Dashboard schickte nur den neuen Namen, der Server las die fehlenden Felder als geleerte, und die Metadaten-Synchronisierung trug diese Löschung an alle anderen Clients weiter. Der Endpunkt ändert jetzt Feld für Feld: ein weggelassenes Feld bleibt unangetastet, ein ausdrücklich geleertes ist eine bewusste Löschung. Zwei verwandte Fehler kamen dabei mit heraus. Die Aussage über den Host eines Containers lag unter einer anders geschriebenen Kennung als Name und Typ desselben Geräts, weshalb das Vergessen des Geräts das eine entfernte und das andere stehen ließ. Und eine unlesbare Adresse am Host-Endpunkt wurde übernommen wie geschickt, passte danach zu nichts und meldete trotzdem Erfolg.

Die Geräteliste wiederholt sich nicht mehr. Ein NAS, das über seine eigene Netzwerkkarte und dazu ein paar Container-Schnittstellen antwortet, füllte das Dashboard mit fast identischen Zeilen, weil der Server das rohe Inventar pro Adresse auslieferte und nur die Desktop-App sie zusammenfasste. Dieselbe Zusammenfassung läuft jetzt auch auf dem Server, ausschließlich beim Lesen. Verfügbarkeit, Alarme und Verlauf bleiben pro Adresse geführt, wo sie hingehören.

Und die Checkboxen im Dashboard wachsen beim ersten Klick nicht mehr.

Mit hinterlegtem Router-Login liest DeviceShelf die Client-Tabelle des Routers und ergänzt Geräte, die der lokale Scan nicht gesehen hat. Dieser Import hat den eingestellten Scan-Bereich bisher ignoriert. Ein WLAN-Client ohne DHCP-Adresse konnte deshalb mit seiner selbstvergebenen 169.254.x-Adresse in der Liste stehen: unerreichbar, 0 % Uptime, zuerst gesehen am Unsinns-Datum 01/01/1. 1.6.24 begrenzt den Import auf das, was die Scan-Einstellungen tatsächlich abdecken. Ist ein Bereich oder eine Interface-Auswahl konfiguriert, werden nur Hosts innerhalb dieses Rahmens übernommen. Ohne konfigurierten Bereich zählt jedes private LAN, an dem der Rechner hängt; Setups mit mehreren Netzen behalten also ihr zweites Segment.

Schrott-Adressen fliegen jetzt in allen Import-Pfaden raus. Selbstvergebenes Link-Local (169.254.x, fe80::), Loopback, Multicast oder 0.0.0.0 können in der Client-Tabelle eines Routers oder in per SNMP gelesenen ARP-Tabellen stehen. Ein echtes Gerät ist keine davon. Dazu kommt: Der Monitor pingt übernommene Adressen aktiv an, ein falsch meldendes Gerät konnte Probes also auf Adressen lenken, die nie Ziel sein sollten. Dieselben Adressklassen blockt der Server für SNMP-Ziele schon länger; jetzt sind sie auch für übernommene Hosts gesperrt, auf Desktop wie Server. Importierte Geräte bekommen außerdem einen echten Zuerst-gesehen-Zeitstempel.

Bestehende Geister-Einträge aus früheren Versionen werden nicht automatisch gelöscht. Einmal entfernen, dann kommen sie nicht wieder.

Die Desktop-App warnt jetzt, bevor die Testphase abläuft. An den letzten zwei Testtagen erscheint ein wegklickbarer Hinweis mit Kauf-Link; vorher stand der einzige Kaufhinweis in den Einstellungen. Der Text der Ablauf-Anzeige wurde dabei korrigiert: Nach der Testphase stoppt auf dem Desktop nur das Scannen, und genau das steht jetzt auch dort, samt Hinweis, dass gesammelte Daten auf dem Rechner bleiben.

Wenn die Desktop-App Geräte-Metadaten mit einem Server synchronisiert, lasen bestimmte Ereignisse den kompletten Record-Feed des Servers neu ein: Sync aktivieren, einen Server neu hinzufügen, eine Server-Neuinstallation. Die Desktop-App übernahm jeden Record aus diesem Feed unverändert. Ein Record, der älter war als die letzten Änderungen, trug leere Felder, und diese leeren Felder ersetzten, was man selbst oder die KI-Identifikation gerade eingetragen hatte. Der KI-Ergebnistext blieb erhalten, weil er nicht Teil des Syncs ist. Name, Tags, Typ und Notiz dagegen nicht. Von außen sah es so aus, als würde die App nach einem Neustart oder Rescan die Beschriftungen vergessen.

Der neu gebaute Pull-Pfad kommt bewusst ohne Uhren aus, denn der Vergleich von Wanduhr-Zeitstempeln über Maschinengrenzen ist der klassische Weg, auf dem Sync-Systeme Daten verlieren. Die Desktop-App merkt sich jetzt, welche Server-Revision sie bereits gesehen hat, und überspringt erneut zugestellte Records komplett; ein Cursor-Reset trägt keine neue Information und kann nichts mehr anfassen. Zusätzlich hält sie pro Server fest, welche lokale Änderung zuletzt bestätigt wurde. Hat der lokale Stand Änderungen, die ein Server nie gesehen hat, wird ein gezogener Record feldweise gemergt statt ersetzt: Eingereihte Änderungen bleiben unberührt, ein nicht-leerer lokaler Name schlägt einen alten leeren und wird zum Server zurückgepusht, und nur echt neuere Server-Werte werden übernommen. Ein absichtliches Leeren auf einem anderen Client kommt weiterhin durch, weil es mit einer neueren Revision eintrifft.

Zwei kleinere Löcher sind dabei mit zugegangen. Ein Sync-Konflikt fror die betroffene Änderung bisher ein, bis man das Feld erneut anfasste; konfliktbehaftete Änderungen setzen jetzt auf der aktuellen Server-Revision neu auf und versuchen es erneut, mit einer Obergrenze, damit ein fehlerhafter Server sie nicht endlos kreisen lässt. Und ein vorübergehender Fehler beim Lesen der gespeicherten Serverliste führt nicht mehr dazu, dass eine Änderung die ausgehende Warteschlange stillschweigend verpasst.

Der Fix liegt vollständig auf der Desktop-Seite. Server brauchen kein Update; die 1.6.23-Server-Builds existieren nur für gleiche Versionsnummern.

Unabhängig davon lässt sich die Monitoring-Liste jetzt sortieren und filtern. Geräte mit Problemen stehen standardmäßig oben, und ab sechs Einträgen erscheinen ein Suchfeld, Sortier-Optionen (Name, Verfügbarkeit, Typ) und ein Nur-Offline-Filter. Das gilt für den lokalen Monitor genauso wie für Remote-Server-Ansichten.

Der Home-Assistant-Export in 1.6.21 veröffentlichte jedes Gerät als Binärsensor. Das gibt ehrlich wieder, was der Scan gemessen hat, und auf einem Dashboard ist es genau richtig. Steuern lässt sich damit nichts: Home Assistant verknüpft nur einen device_tracker mit einer Person. Aus „das Telefon antwortet im Netz“ wurde also nie „sie ist zu Hause“, und keine der Anwesenheits-Automationen, die Leute ohnehin haben, konnte etwas damit anfangen.

Jedes exportierte Gerät bekommt jetzt zusätzlich einen Tracker. Beide lesen dasselbe Zustands-Topic, können sich also nicht widersprechen, und source_type sagt, dass die Anwesenheit aus dem Netzwerk stammt und nicht aus GPS. Der Binärsensor bleibt für Dashboards und Vorlagen.

Die zweite Lücke waren Dienste. Home Assistant kann feststellen, ob eine Maschine auf einen Ping antwortet, aber nicht, ob die Datenbank darauf gesund ist. Deshalb läuft bei vielen ein zweites Uptime-Werkzeug daneben. Jeder aktive Check wird jetzt zu einem Problem-Sensor, der denselben Alarmzustand liest, der auch die Benachrichtigung auslöst. Was in HA rot wird, ist das, was alarmiert, und keine zweitverwertete Einschätzung.

Dazu die Zahlen, die der Server ohnehin sammelt. Jede per SNMP abgefragte Maschine erscheint als eigenes Gerät mit CPU, Arbeitsspeicher, Platte, Temperatur und Lüfter; Docker-Container teilen sich ein Gerät mit je einem Laufend-Sensor. „Sag mir Bescheid, wenn die NAS-Platte über 90 % geht“ ist damit eine Zwei-Zeilen-Automation und ohne den Sensor schlicht unmöglich.

In die Frage, was passiert, wenn eine Quelle verstummt, ist einige Sorgfalt geflossen, denn die naheliegende Umsetzung ist zerstörerisch. Eine leere Liste ist mehrdeutig: Ein abgeschaltetes Docker und ein Socket, der einen Zyklus lang nicht antwortet, kommen beide als null Container an. Behandelt man den zweiten Fall als „es gibt keine“, verschwinden die Entitäten aus der Registry von Home Assistant und kehren eine Minute später als neue zurück. Die Namen, die du vergeben hast, die zugewiesenen Bereiche und die Dashboard-Karten, die darauf zeigen, sind dann weg. Quellen melden jetzt, ob sie überhaupt berichtet haben, und eine, die geschwiegen hat, behält, was sie veröffentlicht hat.

Dasselbe gilt für eine fehlgeschlagene Abfrage. Die SNMP-Schicht meldet minus eins für jeden Messwert, wenn eine Maschine in eine Zeitüberschreitung läuft. Diese Messwerte auszulassen hätte bei jedem Aussetzer CPU, Speicher, Platte, Temperatur und Lüfter gelöscht, samt aufgezeichneter Historie, ausgerechnet den Plattensensor, für den es die Funktion gibt. Ein einmal veröffentlichter Sensor bleibt jetzt bestehen; die Lücke reist als Null-Wert mit, und Home Assistant zeigt sie als „unbekannt“ statt als plausible Zahl.

Wird die Zustandsüberwachung abgeschaltet, verschwinden die Host-Entitäten, statt einzufrieren. Eine Entität, die nicht mehr ausgewertet wird, aber weiter ihren letzten Wert meldet, ist schlimmer als gar keine, weil ihr nichts anzusehen ist.

Die Server-Edition kann jetzt veröffentlichen, was sie findet. Sie nutzt dafür das MQTT-Discovery-Protokoll von Home Assistant, es ist also auf der HA-Seite nichts zu installieren außer der MQTT-Integration und einem Broker. Kein Add-on, keine eigene Integration, kein HACS-Release.

Eine echte Home-Assistant-Integration zu schreiben wäre die naheliegende und die schlechtere Lösung gewesen. Sie hätte eine Python-Komponente und einen Review-Zyklus bedeutet, und darunter hätte sie trotzdem einen Transportweg gebraucht. Discovery ist der vorgesehene Weg für einen fremden Dienst, Entities beizusteuern. Der Dienst schreibt retained JSON, und Home Assistant baut die Entities daraus.

Jedes übertragene Gerät kommt als ein HA-Gerät an. Es trägt einen Connectivity-Sensor sowie IP und Latenz als Diagnosewerte, dazu Hersteller, Modell, Gerätetyp, Betriebssystem, Erst- und Letztsichtung und die offenen Ports als Attribute. Home Assistant weiß längst, ob ein Telefon zu Hause ist; Anwesenheit allein wäre also ein dünner Grund für diese Arbeit gewesen. Die Attribute sind der Teil, den es nicht selbst herleiten kann. Das Event-Entity ebenso: Der Server feuert new_device, device_online, device_offline und new_port, jeweils mit MAC, IP, Name und Hersteller. Eine Automation kann endlich darauf reagieren, dass ein unbekanntes Gerät ins Netz kommt. Keine Anwesenheitserkennung verrät das je.

Nicht jeder Host wird übertragen. Favoriten und Infrastruktur schon, also Gateway, Router, Switches, Access Points, Firewalls, NAS-Systeme, Server und Drucker. Alles andere wartet auf ein ausdrückliches Ja, Gerät für Gerät. Ein /24 mit 150 Hosts erzeugte sonst beim ersten Verbinden mehrere hundert Entities, die meisten davon die kurzlebigen Zufalls-MACs, durch die moderne Telefone rotieren. Das ist Rauschen. Eine Integration, die jemandem die Entity-Liste flutet, fliegt noch am selben Abend wieder runter.

Die Buchführung dahinter ist wichtiger, als sie klingt. Discovery-Payloads und Zustände sind retained, damit Home Assistant sich nach einem Neustart sofort wieder füllt statt bis zum nächsten Scan leer zu bleiben, und sie werden nur dann neu geschrieben, wenn sich tatsächlich etwas geändert hat. Fällt ein Gerät aus der Übertragung, wird seine retained Config geleert; genau so löscht Home Assistant ein Entity, statt es als dauerhaft nicht verfügbar zurückzulassen. Der Kollektor hinterlegt ein Last Will, ein Absturz blendet seine Entities also aus, statt sie auf einem veralteten „zu Hause" einfrieren zu lassen. Ein ausgefallener Broker wird protokolliert und sonst ignoriert. Der Scan und alle anderen Alarmkanäle laufen weiter.

Es hat sich gelohnt, das gegen ein echtes Home Assistant zu testen und nicht nur gegen einen Broker. Zwei Fehler zeigten sich nirgends sonst. Ein NAS mit zwei Netzwerkkarten ergab zwei Geräte gleichen Namens, und Home Assistant hängte stillschweigend ein _2 an, was niemandem sagt, welche Karte gemeint ist; kollidierende Namen tragen jetzt die letzten vier Hex-Stellen ihrer MAC. Der zweite Fehler war feiner. Wir hatten object_id an jedem Entity gesetzt, und es wird schlicht ignoriert, sobald die Nachricht einen benannten Geräteblock enthält, denn Home Assistant bildet die Entity-ID stattdessen aus Geräte- und Entity-Namen. Es trotzdem mitzuschicken versprach eine Kontrolle, die wir nicht hatten, also ist es raus.

Einrichtung, Topic-Aufbau und ein paar Automations-Beispiele stehen im Home-Assistant-Leitfaden.

Manche Nutzer fanden nach einem Update leere API-Token vor, trugen sie neu ein, und erlebten dasselbe später wieder. Dafür gab es schon einmal einen Fix, und der reichte nicht.

Zwei Dinge kamen zusammen. Der sichere Speicher wird beim Start einmal gelesen, und dieses Lesen kann scheitern: ein Schlüsselbund, der dem frisch signierten Programm den Zugriff noch nicht erlaubt hat, oder eine Datei, in die eine zweite Instanz gerade schreibt. Das Ergebnis war „nichts da“, und das ist von „nie etwas gespeichert“ nicht zu unterscheiden. Also zeigte das Formular leere Felder, und die Zugangsdaten wirkten verloren.

Verloren waren sie nicht. Aber die leeren Werte standen nun im Speicher, und damit fing das zweite Problem an. Das Einstellungsformular lässt Geheimnis-Felder weg, die niemand angefasst hat — das war der frühere Fix. Nur laufen ein Dutzend Stellen im Code gar nicht über das Formular. Sie lesen die Einstellungen, ändern einen Schalter und schreiben alles zurück:

cfg := store.Settings() cfg.SyslogEnabled = true store.SetSettings(cfg)

Jedes Geheimnis in dieser Struktur war eine leere Zeichenkette, und das Speichern schrieb diese Leere in den Speicher durch. Syslog einzuschalten löschte die API-Schlüssel. Die AI-Zustimmung ebenso. Die neu eingetragenen Zugangsdaten waren beim nächsten Mal dann wirklich weg, und genau deshalb kam das Problem nach dem Fix immer wieder.

Der Schutz sitzt jetzt dort, wo geschrieben wird, statt im Formular. Ein nicht-leerer Wert wird immer geschrieben. Ein leerer Wert nur dann, wenn sich dieses Geheimnis beim Start auch lesen ließ. So sieht ein bewusstes Leeren des Feldes aus. Ist das Lesen gescheitert, wird das Löschen verweigert, denn eine gewollte Löschung ist von einem Wert, den wir nie gesehen haben, nicht zu unterscheiden.

Darunter sind die beiden Fälle nicht länger derselbe Fall: Ein Lesefehler wird als Fehler gemeldet, statt zu „nicht gefunden“ zu verflachen. Die Einstellungen nutzen das. Ein Feld, dessen Wert nicht gelesen werden konnte, ist schreibgeschützt und sagt „konnte nicht gelesen werden, bleibt gespeichert“, mit der Bitte, es nicht neu einzutragen. Ein Neustart der App behebt es, und jetzt sagt die App das auch.

Behoben ist außerdem ein Fehler aus der Kompatibilitätsarbeit in 1.6.19: Die Liste der Remote-Server wartete auf die Fähigkeitsprüfung jedes Servers, bevor sie überhaupt etwas zeichnete. Ein Server, der gerade nicht erreichbar war, etwa während seines eigenen Updates, ließ die Liste dadurch mehrere Sekunden leer.

Die Alarm-Einstellungen eines gekoppelten Servers scheiterten immer mit „Server-Alarme konnten nicht geladen werden“, egal wie gesund der Server war. Die Ursache lag in der Brücke zwischen Go-Backend und Oberfläche: Eine gebundene Methode darf einen Wert und einen Fehler zurückgeben, und Wails reicht den zweiten Wert nur weiter, wenn er tatsächlich ein Fehler ist. Unserer war ein Statuscode, also eine schlichte Zeichenkette, und wurde verworfen. Die Oberfläche erwartete ein Paar, bekam ein einzelnes Objekt, und die Ausnahme daraus erschien als jene Meldung. Der Aufruf liefert jetzt einen Wert, der beides trägt, und ein Test weist jede gebundene Methode mit der alten Form zurück.

Der Fix legte etwas Leiseres frei. Ein Server, der eine Einstellung noch nicht kennt, meldet sie nicht als fehlend. Er lässt das Feld einfach weg, und der Client liest seinen Standardwert. Sichtbar wurde das am Schalter, der alle Alarme stumm schaltet: Bei einem Server, der das nicht kann, zeigte die App ein leeres Kästchen. Nichts schlug fehl. Der Schalter tat nur nichts und sah dabei aus wie ein Schalter, der aus ist.

Clients und Server klären deshalb jetzt vorab, was sie können. Ein Server beantwortet einen Handshake mit seiner Version und der Liste der Funktionen, die er versteht, und die App richtet sich nach dieser Liste, statt aus einer Versionsnummer zu raten. Was der Server nicht nennt, wird ausgeblendet statt angeboten; der Stummschalter erscheint nur dort, wo er auch wirkt. Ein Server, der zu alt ist, wird als solcher benannt, samt der benötigten Version, statt einen Aufruf nach dem anderen scheitern zu lassen. Server, die älter als der Handshake sind, werden über ihre Version eingeordnet; die Grenzen dafür stammen aus den Release-Tags, die die jeweilige Funktion tatsächlich enthalten.

Der Handshake braucht kein Token, wie der Versions-Endpunkt daneben, denn Kompatibilität muss sich vor dem Koppeln prüfen lassen. Er meldet nur, was der Build versteht, nie wie die Installation konfiguriert ist. Das bleibt hinter dem Token.

Zwei Kleinigkeiten. Die Schaltfläche für die Einstellungen in einer Server-Zeile nutzte ein Zahnrad-Emoji, das auf hellem Grund als winziger grauer Fleck ankam; jetzt ist es ein richtiges Symbol. Und die Update-Prüfung verlas sich bei Vorabversionen: Ein Versionsteil mit angehängtem Zusatz wurde als Null gelesen, 1.6.19-rc1 verglich sich also wie 1.6.0, und eine ältere Ausgabe hätte als neuer erscheinen können. Derselbe Parser-Fehler steckte an drei Stellen und ist jetzt eine Funktion.

Auf dem Telefon startet ein Zug nach unten in der Geräteliste einen neuen Scan. Zieht man, während schon einer läuft, hängt er sich an statt ihn abzubrechen, und die Anzeige dreht sich, bis der Durchlauf wirklich fertig ist.

Die Geräteliste war nur mit der Maus bedienbar. Auf dem Desktop war eine Zeile ein einfaches div mit Klick-Handler, der Favoritenstern ein span, die Sortier-Kopfzeilen weder fokussierbar noch angesagt. Mit der Tastatur kam man bis zur Seitenleiste und zum Filter, dann war Schluss. Im Server-Dashboard dasselbe in Tabellenform.

Beides ist behoben. Der Gerätename ist ein echter Knopf mit gesprochener Zusammenfassung, der Stern meldet seinen Zustand, Kopfzeilen sortieren mit Enter oder Leertaste, und hinter der Farbe des Statuspunkts steht jetzt Text. Auf dem Server überlebt eine fokussierte Zeile ein Live-Update, statt einen zurück an den Seitenanfang zu werfen.

Die Flutter-App hatte überhaupt keine Semantik-Annotationen. VoiceOver und TalkBack lasen eine Zeile als lose Bruchstücke in Layout-Reihenfolge vor (Titel, dann jedes Badge, dann jeden Port-Chip), während Statuspunkt, Gateway-Badge und Stern gar nichts sagten. Eine Zeile ist jetzt ein Satz: Name, Gateway oder eigenes Gerät, Adresse, Hersteller, Anzahl offener Ports, dazu die Warnungen, die vorher nur ein Symbol waren. Tag-Chips bleiben einzeln erreichbar, denn ein Tipp darauf filtert die Liste. Das Einblenden neuer Geräte entfällt, wenn das System weniger Bewegung verlangt.

Die blasseste Textfarbe fiel in beiden Themen durch den WCAG-AA-Kontrast: 2,24:1 im hellen, 3,71:1 im dunklen, bei geforderten 4,5:1. Betroffen ist Text, der Portanzahlen und Zeitstempel trägt. Sie allein anzuheben hätte sie mit der nächsten Stufe verschmelzen lassen, also wanderte die ganze Staffelung gemeinsam und behielt ihre Abstufung.

Das Server-Dashboard gab es bisher nur dunkel. Es folgt jetzt dem Betriebssystem, mit einem Auto/Hell/Dunkel-Wähler neben der Sprachauswahl. Wer einen hellen Desktop nutzt, merkt den Unterschied beim nächsten Laden.

Darunter waren die drei Oberflächen auseinandergelaufen. Der Server pflegte ein eigenes Stylesheet mit anderen Namen für dieselben Farben, und die Flutter-App verwendete im Dunkelmodus die hellen Markenfarben, wo die Web-Oberflächen jeden Ton aufhellen. Sie teilen sich jetzt einen dokumentierten Satz Tokens.

Zwei Fehler kamen bei der Arbeit ans Licht. Im Server hatte die Ports-Spalte keine Mindestbreite, ein Gerät mit fünf offenen Ports erzeugte also eine fünfzeilige Zeile mit mitten im Wort umgebrochenem Namen. Sichtbar war das für jeden mit aktivem Portscan. Und die Liste auf dem Handy sortierte sich bei jedem Neuaufbau um, weil Darts Sortierung nicht stabil ist und Zeilen mit gleichem Schlüssel nichts hatten, was den Gleichstand auflöst.

Die Gerätezeile auf dem Handy ist außerdem umgezogen: Adresse und Antwortzeit stehen am rechten Rand, der Hersteller in der Zeile unter dem Namen.

Die Einzelschalter aus 1.6.15 deckten nur fünf Geräte-Ereignisse ab. Für Zertifikatsablauf, Domain-Ablauf, WAN-Erreichbarkeit, Host-Ressourcen und eigene Checks gab es gar keinen, „der Server soll aufhören mich zu benachrichtigen" war aus den Apps also nicht machbar. Jetzt gibt es einen Hauptschalter, der alles stummschaltet, was der Server verschickt. Erkennung und Protokollierung laufen weiter, nur die Zustellung hört auf.

Verbindungsfehler waren auf eine bestimmte Art unbrauchbar. Ein abgelehnter Token wurde als „Server nicht erreichbar, offline, anderes Netz oder von einer Firewall geblockt" gemeldet. Das liess Leute in ihrem Netzwerk suchen statt bei ihrem Token. Jeder Fall benennt sich jetzt selbst: Token abgelehnt, kein DeviceShelf unter dieser Adresse, Sperre nach zu vielen Fehlversuchen, Zeitüberschreitung, oder tatsächlich offline.

Dahinter steckte etwas Schlimmeres. Scheiterte die erste Anfrage an einen Server, wiederholte der Client sie auf benachbarten Ports desselben Hosts und speicherte bei Erfolg diese Adresse. Gedacht war das für einen Server, der den Port gewechselt hat, es lief aber auch bei abgelehntem Token. Auf einer Maschine mit zwei Servern (dem installierten und einem von Hand gestarteten Build, was durchaus üblich ist) konntest du am Ende die Geräteliste des anderen Servers ansehen, während dein Token still falsch war. Die Wiederholung läuft jetzt nur noch, wenn gar nichts geantwortet hat.

Der macOS-Installer hatte drei rauhe Kanten. Er wartete nicht, bis der alte Dienst gestoppt war, der neue konnte also mit ihm um den Port rennen. Die Zugangsdatei auf dem Schreibtisch nannte fest Port 8088, statt den tatsächlich verwendeten zu lesen. Und sie war deutsch, unabhängig von deiner Sprache. Alle drei sind behoben, und wenn vor der Installation schon etwas auf dem Port lauschte, steht das in der Datei.

Die Serverliste zeigt ausserdem die Version jedes Servers. Zwei Server auf einer Maschine waren vorher nicht auseinanderzuhalten. So kam die Verwirrung um die Ports überhaupt zustande.

Kleinkram: Der WLAN-Berechtigungsknopf unter macOS tat nichts, weil CoreLocation seinen Dialog nicht für einen Location-Manager ohne Delegate anzeigt. In der mobilen App behauptete ein 404 von jedem beliebigen Endpunkt, der Server unterstütze die Alarm-Einstellungen nicht, auch wenn die richtige Antwort war, dass dort gar kein DeviceShelf sitzt.

Der Alarm-Editor aus 1.6.15 hatte vier Fehler. Speichern funktionierte genau einmal pro App-Start, weil der Desktop-Dialog seinen Speichern-Knopf nach einem erfolgreichen Schreibvorgang deaktiviert liess. Änderte jemand die Regeln anderswo, antwortete die Versionsprüfung des Servers mit 409, und der Dialog schickte weiterhin dieselbe veraltete Version. Damit kam kein weiterer Speichervorgang mehr durch. Ein geleertes Zahlenfeld schrieb 0, statt den Wert unangetastet zu lassen, und aus „offline nach 0 Minuten“ wurde ein Alarm beim ersten verpassten Scan. Ausserdem kam der Desktop-Dialog ohne Übersetzungen, alle sahen deutsche Beschriftungen.

Alle vier sind behoben. Mobile und Desktop benennen einen Versionskonflikt jetzt als solchen, und der Desktop lädt die Regeln neu, damit der nächste Speichervorgang durchgeht.

Der MCP-Endpunkt hat einen Sicherheitsdurchgang bekommen. Von Geräten gemeldeter Text erreicht einen KI-Assistenten über mehrere Werkzeuge, und die Infrastruktur-Werkzeuge reichten ihn ungefiltert weiter, besonders den SNMP-sysName, den jedes Gerät im Netz selbst setzen kann. Diese Zeichenketten laufen jetzt durch denselben Filter wie Hostnamen und Banner. Über MCP angelegte Monitor-Checks müssen auf eine private, Loopback- oder Link-Local-Adresse zeigen, so wie es die Scan-Werkzeuge längst verlangen. Ein Assistent, der ein Gerät umbenennt oder einen Check bearbeitet, verwirft nicht mehr die Felder, um die ihn niemand gebeten hat, und ein Heartbeat-Monitor behält sein Push-Token.

Browser-basierte MCP-Clients konnten sich überhaupt nicht verbinden: Der CORS-Preflight trägt keinen Autorisierungs-Header und wurde deshalb abgewiesen, bevor er den Endpunkt erreichte. Ein Schrägstrich zu viel in der URL lieferte Dashboard-HTML mit Status 200, was Clients als ungültiges JSON meldeten. Beides ist behoben, und die Sperre nach wiederholt falschen Token schickt jetzt Retry-After, statt einen im Unklaren zu lassen, ob auch das korrigierte Token falsch ist.

Konfigurations-Exporte enthalten keine Benachrichtigungsziele mehr.

DeviceShelf 1.6.15 macht die wichtigsten Alarmregeln eines verbundenen Servers aus Desktop und Mobile erreichbar.

Über die Alarm-Einstellungen lassen sich Meldungen für neue Geräte, Online-/Offline-Wechsel, neue Ports und mobile Präsenz aktivieren oder deaktivieren. Zusätzlich können Offline-Schwelle, Port-Bestätigungen, Sammelmeldungen, E-Mail-Abstände, Ruhezeiten und Zeitzone angepasst werden.

Ziele, Zugangsdaten und bestehende Benachrichtigungskanäle bleiben auf dem Server. Die Apps erhalten nur den Konfigurationsstatus, niemals SMTP-, Webhook- oder Apprise-Geheimnisse. Versionsprüfungen verhindern, dass parallele Änderungen überschrieben werden.

DeviceShelf 1.6.14 macht Remote-Server in Desktop, Mobile und der selbst gehosteten Server-Edition verständlicher.

Remote-Server haben jetzt eine klare Ansichtsauswahl. Mit Nur Server-Geräte bleibt die lokale Geräteliste vollständig außen vor. Mit Server + lokale Geräte entsteht eine gemeinsame Ansicht. Diese Ansicht ist lesend und überschreibt keine lokalen Daten.

Remote-Fehler sind verständlicher. Eine Text-Fehlerseite von einem älteren oder nicht erreichbaren Endpunkt wird nicht mehr als verwirrender JSON-Parsing-Fehler angezeigt. Optionale Remote-Bereiche bleiben sichtbar, wenn ein einzelner Endpunkt fehlt.

Das macOS-Server-Paket erklärt den ersten Zugriff. Nach der Installation öffnet es eine Zugangsinformation mit lokaler Dashboard-URL, LAN-URL und persistentem Token. Updates behalten Serverdaten und Token bei.

Die Veröffentlichung enthält außerdem die aktuelle Server-Überwachung und die plattformübergreifenden Ansichten aus der Server-Anleitung.

DeviceShelf 1.6.11 behebt zwei praktische Probleme, die in echten Netzwerken aufgetaucht sind.

Die Remote-Server-Erkennung vertraut veralteten Ports nicht mehr blind. Ein DeviceShelf-Server kann auf einem anderen Port laufen als dem alten Standard. Die Desktop-App liest jetzt den per mDNS/Bonjour angekündigten Port, prüft ihn gegen die Server-API, bevor sie ihn anzeigt, und fällt auf bekannte funktionierende Ports zurück, wenn die Ankündigung veraltet ist.

Gespeicherte Remote-Server-URLs reparieren sich selbst. Wenn eine gespeicherte Server-Adresse auf den richtigen Host, aber den falschen Port zeigt, probiert DeviceShelf denselben Host auf bekannten DeviceShelf-Ports. Antwortet einer korrekt, wird die gespeicherte URL aktualisiert, statt dich mit einer toten manuellen Konfiguration stehen zu lassen.

Start-Scans respektieren den gewählten Scan-Bereich. Wenn du ein bestimmtes Interface oder eine bestimmte Range gespeichert hast, nutzt der erste Scan nach dem App-Start diesen Scope jetzt sofort. Er fällt nicht mehr zuerst auf “alle Interfaces scannen” zurück.

Update: über den Desktop-Updater, den neuen Installer oder ein Server-Update, wenn du LAN-Erkennung nutzt.

DeviceShelf 1.6.10 macht einen verbundenen DeviceShelf-Server in den Clients sichtbarer und nützlicher.

Server-Verfügbarkeitsverlauf in Desktop und Mobile. Wenn du dich mit einem DeviceShelf-Server verbindest, kann jedes Gerät jetzt den dort gesammelten Monitoring-Verlauf zeigen: Uptime-Balken, Antwortzeit-Chart und Ausfallliste. Zeiträume, in denen der Monitor selbst aus war, werden separat markiert, sodass sie nicht als Downtime gezählt werden.

Sauberere Namen und weniger Duplikate. Gerätenamen sind weniger zugemüllt. Echte Hostnamen haben Vorrang vor IP- und MAC-Fallbacks, Router-Suffixe wie .local und .localdomain werden entfernt, wenn sie keinen Mehrwert bringen, und die Zusammenführung vermeidet doppelte Zeilen für dasselbe Gerät zuverlässiger.

Server-Erkennung im LAN. DeviceShelf-Server kündigen sich im lokalen Netzwerk an, sodass Desktop- und Mobile-App sie finden können, ohne dass du die Adresse manuell eintippst.

Update: über den Desktop-Updater, den neuen Mobile-Build oder beim Server mit docker compose pull && docker compose up -d, dem .deb, dem Windows-Zip oder dem GHCR-Image.

Ein kleineres Release: eine neue Spalte, ein Bündel Zuverlässigkeitsarbeit auf der KI-Seite und ein Datensicherheits-Fix.

Wie jedes Gerät zu seiner IP kam. Geräte tragen jetzt einen Zuweisungstyp, gelesen aus der Lease-Tabelle des Routers: statisch, DHCP oder eine DHCP-Reservierung. Das beantwortet, was der Scan allein nicht sieht: Ist die Adresse fest, oder kann sie beim nächsten Lease wandern? Desktop, Server und Mobile zeigen es.

Robustere KI-Identifikation. Im Identifikations-Panel rutschte gelegentlich rohes JSON durch, wenn ein Modell seine Antwort in Prosa verpackte, einen Code-Zaun setzte oder mitten drin abbrach. Das ist vorbei: Die Antwort wird für jeden Anbieter gleich geparst, und eine abgeschnittene liefert trotzdem ein sauberes Ergebnis. Der Text folgt jetzt der App-Sprache statt der Standardsprache des Modells. Bei einem sicheren Treffer werden Name, Tags, Typ und Kommentar eines Geräts befüllt, sofern sie leer sind, nur die leeren, nie über eine eigene Eingabe hinweg. Von älteren Versionen gespeicherte Ergebnisse, die eine kaputte „(— · niedrig)"-Zeile zeigten, werden jetzt korrekt dargestellt. Und die Namensauflösung für KI-Aufrufe fällt über mehrere öffentliche Resolver zurück, sodass ein einzelner blockierter oder umgeleiteter die Anfrage nicht mehr kippt.

Ein Speichern der Einstellungen konnte Secrets löschen. Nach einem fehlgeschlagenen Lesen aus dem sicheren Speicher konnte das Speichern der Einstellungen ein hinterlegtes Secret (etwa einen API-Schlüssel) mit einem leeren Wert überschreiben. Behoben: Ein fehlgeschlagenes Lesen lässt keinen leeren Wert mehr an die Stelle des vorhandenen treten.

Update: docker compose pull && docker compose up -d, das neue .deb/.rpm, das Windows-Zip oder das Desktop-Update. Details im Server-Guide.

Wer DeviceShelf ein paar Stunden laufen ließ, dem wurde es träge und der Rechner fing an, unter Last zu geraten, am deutlichsten mit aktivem Live-Monitoring. 1.6.7 behebt die zwei Ursachen.

Der aktive ARP-Scan hat pro Durchlauf ein Packet-Capture-Handle und eine Goroutine geleakt. Im Live-Modus ist das ein Durchlauf alle 5 Sekunden, also stapelte sich das, bis macOS keine Capture-Deskriptoren mehr hatte. Der Scan nutzt jetzt einen begrenzten Read, der das Handle immer freigibt, sodass sich nichts mehr ansammelt.

Auch das Präsenz-Logging hat den kompletten Store einmal pro Gerät bei jedem Scan-Durchlauf auf die Platte geschrieben (mit zwei fsyncs). Das ist ein I/O-Sturm, der mit der Gerätezahl und der Store-Datei selbst wächst und die Platte mit der Zeit sättigt. Diese Schreibvorgänge werden jetzt gebündelt, sodass ein volles Netzwerk sie nicht mehr überlastet.

Update: docker compose pull && docker compose up -d, neues .deb, Windows-Zip oder das Desktop-Update.

Vier größere Änderungen diesmal, dazu die üblichen Fixes.

Router-Gerätelisten von jeder Marke. Als wir die Router-Anbindung eingeführt haben, sprach sie nur UniFi. Mit 1.6.6 lesen Desktop und Server die Geräteliste aus 17 Router- und Controller-Familien: FRITZ!Box und generisches TR-064, UniFi, Netgear, Linksys, ASUS, TP-Link, D-Link, MikroTik, FortiGate, Omada, OPNsense, pfSense, Peplink, OpenWrt, Synology SRM sowie ein generischer SNMP-Fallback. Der Router kennt aus seiner DHCP-/ARP-Tabelle ohnehin jedes Gerät. So tauchen auch Hosts auf, die ein lokaler Scan nicht erreicht (andere VLANs, schlafende Geräte), samt der vom Router vergebenen Namen. In den Einstellungen gibt es eine Marken-Auswahl (automatisch erkennen oder eine Marke fest wählen), und ein Test-Knopf meldet, welche geantwortet hat und wie viele Geräte gefunden wurden. Die Mobile-App bekommt die Auswahl als Nächstes. UniFi ist die Marke, die wir gegen echte Hardware geprüft haben; die übrigen sind gegen die dokumentierte API des jeweiligen Herstellers gebaut und scheitern kontrolliert, sodass ein Fehlgriff nichts liefert und keinen Scan stört.

Präzisere Geräte-Identifikation. Die Klassifikation richtet sich jetzt danach, was ein Gerät über sich selbst meldet (seine mDNS-, UPnP- und SNMP-Signale), statt aus dem Namen zu raten. Eine lokale Fingerprint-Datenbank (Recog) gleicht offline ab, und eine Reihe von Fehlgriffen ist weg: ein Mac, der AirPlay anbietet, ist ein Computer und kein Lautsprecher; Docks, NAS-Geräte und Mesh-Knoten bekommen das richtige Label; ein unbekanntes Gerät zeigt zumindest seinen Hersteller. Herstellernamen werden jetzt auch für Geräte aus den kleineren IEEE-Blöcken MA-M und MA-S korrekt aufgelöst.

Ein OpenAI-kompatibler KI-Anbieter. Der KI-Assistent kann jetzt jeden OpenAI-artigen Endpunkt ansprechen: ein lokales vLLM oder LM Studio oder ein privates Gateway. Bei lokalen Endpunkten entfällt die Cloud-Zustimmung, weil nichts dein Netzwerk verlässt.

Einstellungen überstehen eine Neuinstallation. Deine Konfiguration wird zusätzlich außerhalb der Konfigdatei gespiegelt, sodass ein gelöschter Konfig-Ordner oder eine Neuinstallation dich nicht mehr bei null anfangen lässt.

Ebenfalls in diesem Release: Die E-Mail-Alarm-Sektion des Servers hat jetzt einen Test-Knopf mit direktem SMTP-Ergebnis, die Savebar der Einstellungen bestätigt wieder zuverlässig „Gespeichert ✓", und ein Hinweis stellt klar, dass die Meldungen eines Scan-Durchlaufs als eine gebündelte E-Mail ankommen. Der Scan-Dialog merkt sich die gewählte Schnittstelle ohne vorherigen Scan, und die Sprachkataloge sind wieder vollständig.

Fingerbank-Hinweis für Bestandsnutzer: Automatische Abfragen sind jetzt optional. Wer Fingerbank bereits mit dem passiven DHCP-Listener nutzt, muss den neuen Haken für die automatische Abfrage einmal setzen. Bis dahin schickt DeviceShelf von sich aus keine Fingerprints mehr.

Update: docker compose pull && docker compose up -d, neues .deb, Windows-Zip oder das Desktop-Update. Details im Server-Guide.

Ein kleiner Stachel ist raus. Die Netzwerk-Diagnose (Ping, Traceroute, DNS, Speedtest) und der Bereich Geräteprüfungen zeigten bisher die rohe API-Antwort als JSON. Jetzt liest sich das wie ein Ergebnis: Der Speedtest zeigt ↓ 18,1 Mbit/s · ↑ 71,6 Mbit/s · Latenz 179 ms · Jitter 88 ms, Ping zeigt Antworten, Verlust und min/ø/max, Traceroute listet nummerierte Hops, und die SSH-Key-, SMB-, Traffic-, HTTP- und Zugangsprüfungen bekommen je eine lesbare Zeile. Was die Oberfläche nicht kennt, fällt weiter auf formatiertes JSON zurück, damit nie etwas leer bleibt.

Update: docker compose pull && docker compose up -d, neues .deb, Windows-Zip oder das Desktop-Update.

Falls dein SLA-Report dasselbe Gerät drei- oder viermal zeigte — eine Zeile nahe 100 %, die anderen nahe 0 % und der Gesamtwert im Keller: Dieses Update ist für dich.

Die Ursache war subtil: Unsere Discovery-Pfade schrieben dieselbe MAC-Adresse in unterschiedlichen Formaten. ARP und SNMP lieferten Kleinbuchstaben, das DHCP-Fingerprinting Großbuchstaben, und jede Schreibweise wurde eine eigene Geräte-Identität mit eigenem Verfügbarkeits-Verlauf. Die Phantom-Identitäten sammelten dann bei jedem Scan, der sie nicht „sah", einen Offline-Messpunkt. Daher die Fast-0%-Zeilen.

Ab 1.6.4 schreibt jeder Pfad ein kanonisches Format, der Speicher normalisiert alles, was ihn erreicht, und eine einmalige Migration verschmilzt die bereits fragmentierte Historie: Verfügbarkeits-Verläufe werden tageweise summiert, Namen und Metadaten bleiben erhalten. Kein manuelles Aufräumen nötig; der Report stimmt nach dem ersten Start wieder.

Update: docker compose pull && docker compose up -d, neues .deb, Windows-Zip oder das Desktop-Update. Details im Server-Guide.

Wir haben das Server-Dashboard durch ein richtiges Usability-Review geschickt und umgebaut, was es beanstandet hat.

Navigation. Sechs Tabs statt zehn: Topologie, Diagnose und Bandbreite stecken jetzt in einer Netzwerk-Ansicht, Syslog gehört zu Infrastruktur, und der KI-Assistent ist ein Drawer, der sich aus jeder Ansicht öffnen lässt, statt eine fast leere eigene Seite zu sein.

Einstellungen. Aus einer langen Spalte wurden fünf gruppierte Sektionen (Allgemein, Scannen & Erkennung, Alarme & Benachrichtigungen, Checks & Monitore, Status-Seite) mit fixierter Sektions-Navigation. Jede Sektion ist direkt verlinkbar, und die leeren Zustände in der App nutzen genau diese Links: Statt „Docker-Überwachung ist aus, der Socket nicht gemountet oder es gibt keine Container" nennt die Seite die eine Ursache, die wirklich zutrifft, und wo sie sich beheben lässt.

Weniger Fallen. Schwellwert-Felder zeigen beim Tippen eine Live-Interpretation („→ Alarm aus", „→ Standard: 90 %", „→ erbt die Host-Schwelle"). Ein sauberer Security-Report zeigt einen Haken statt einer grünen „0 /100". Die Bandbreiten-Ansicht bietet in Builds ohne Paketmitschnitt keinen Start-Knopf mehr an. Und das Telefon-Layout funktioniert jetzt; vorher konnte ein Tipp auf einen rechten Tab die ganze Seite ins Leere schieben.

Neu seit dem gestrigen 1.6.0. Infrastruktur-Metriken (Host-CPU/RAM/Disk/Temperatur, Proxmox-Nodes) behalten rund sieben Tage Verlauf, gezeichnet als Sparklines mit 24h/7d-Umschalter. Auf dem Disk-Verlauf sitzt eine Disk-Voll-Prognose: eine Trendlinie, die warnt, wenn ein Volume innerhalb des eingestellten Horizonts voraussichtlich vollläuft (Standard 14 Tage, einzeln abschaltbar wie jeder andere Alarm). Bei flachen oder zappeligen Daten bleibt sie still.

Außerdem in diesem Release: ein hartes Timeout für macOS-Keychain-Aufrufe, damit ein blockierter Berechtigungsdialog den Server nie mehr aufhalten kann.

Update: docker compose pull && docker compose up -d, neues .deb oder den Windows-Installer erneut ausführen. Details im Server-Guide.

Dritter und letzter Schnitt des Tages. 1.6.1 legte die optionale deviceshelf-server-pcap.exe ins Windows-Zip, aber das Dienst-Binary musste man noch von Hand tauschen. Das sollte niemand müssen. Jetzt prüft install.exe, ob Npcap installiert ist, und installiert dann automatisch den Build mit Paketmitschnitt. Es reicht, den Installer über eine bestehende Installation laufen zu lassen; er ist zugleich der Updater.

Kein Npcap? Dann bleibt es beim Standard-Build, der überall läuft. Die Bandbreiten-Karte im Dashboard erklärt den Windows-Weg jetzt ebenfalls.

Update: das Windows-Zip neu laden und install.exe erneut ausführen. Docker und .deb sind nicht betroffen.

Kleiner Patch direkt auf das heutige 1.6.0. Die Windows- und .deb-Builds des Servers kamen ohne eingestempelte Versionsnummer, deshalb zeigte der Dashboard-Header keine an und die Update-Prüfung hielt nichts je für neuer. Docker war nicht betroffen. Beide Builds tragen ihre Version jetzt wieder.

Das Windows-Zip enthält außerdem ein zweites Binary: deviceshelf-server-pcap.exe. Wer Npcap installiert hat, startet dieses statt des Standards und bekommt auch unter Windows Live-Bandbreite pro Gerät und aktiven ARP-Scan. Ohne Npcap startet es nicht; die Standard-deviceshelf-server.exe läuft weiterhin überall.

Update: das Windows-Zip neu laden oder das neue .deb installieren; Docker-Nutzer können diesen Patch überspringen.

Die Server-Edition bekommt einen neuen Infrastruktur-Tab und überwacht deutlich mehr als Geräte.

• Docker-Container. Socket read-only mounten (oder DEVICESHELF_DOCKER setzen), und es gibt Alarme, wenn ein laufender Container ausfällt, in einer Restart-Schleife hängt oder sein Healthcheck fehlschlägt. Ein Container, der beim Serverstart schon gestoppt war, alarmiert nie.
• Proxmox VE. Nodes und Gäste, über einen read-only API-Token (Rolle PVEAuditor). Alarme, wenn ein Node offline geht, eine laufende VM oder ein LXC stoppt oder die CPU-/RAM-Last eines Nodes zu hoch steigt.
• NAS-Zustand. Bei Synology, QNAP und TrueNAS liest der SNMP-Durchlauf jetzt den Disk-, RAID- und Pool-Status des Herstellers. Ein Volume kann halb leer sein und trotzdem sterben; genau das fällt jetzt auf.
• Temperatur und Lüfter. Hardware-Sensoren über SNMP (ENTITY-SENSOR und LM-SENSORS), mit Temperatur-Alarm ab einstellbarer Grenze.

Die Checks können vier neue Typen: MySQL/MariaDB, PostgreSQL, SQL Server und Redis. Jeder spricht das Wire-Protokoll der Datenbank, ein offener Port reicht also nicht. Es muss wirklich eine Datenbank antworten. Und weil die Probe keine Zugangsdaten braucht, werden auch keine gespeichert. Auch die Desktop-App kann diese Checks anlegen.

Schwellwerte sind jetzt einzeln schaltbar: 0 eintragen schaltet einen Alarm ab, ein leeres Feld nimmt den Standard. Proxmox-Node-Grenzen können die Host-Grenzen erben oder von ihnen abweichen.

Für Grafana-Nutzer liefert /metrics Gauges für alles Neue, inklusive deviceshelf_docker_api_up und deviceshelf_pve_api_up. Damit lässt sich während eines API-Ausfalls ein Live-Wert von einem veralteten unterscheiden.

Update: docker compose pull && docker compose up -d oder apt install ./deviceshelf-server_1.6.0_*.deb. Details im Server-Guide.

Neues App-Icon auf macOS, Windows und Linux. Außerdem behoben: ein Statusflackern, bei dem ein Gerät mitten im Scan zwischen „Aktiv" und Leerlauf sprang — und deine Scan-Tiefe und der UDP-Dienste-Schalter überstehen jetzt einen Neustart.

Auf der Server-Seite bringt die Windows-Edition ein echtes install.exe und uninstall.exe statt der Batch-Dateien, die Windows gern blockierte — Doppelklick, Nachfrage bestätigen, fertig. Und den Dashboard-Token liest du auf jeder Plattform, Windows, Docker oder .deb, mit deviceshelf-server -token.

Zwei größere Änderungen. Die Oberfläche ist jetzt Englisch-zuerst über Desktop, Server und Mobile — die anderen Sprachen bleiben, Englisch ist nur die Basis, aus der sie entstehen.

Und die Topologie verlässt sich nicht mehr auf SNMP- oder LLDP-Raterei. Zeig DeviceShelf auf deinen UniFi- oder Router-Controller, und es liest direkt von dort, welches Gerät an welchem Access Point oder Switch-Port hängt. Ein Test-Knopf bestätigt die Verbindung, bevor du dich darauf verlässt.

Die 24/7-Server-Edition kann fluten, wenn sich viel auf einmal ändert. Dieses Release bringt die Bremsen: Meldungen niedriger Priorität sammeln sich zu einer Zusammenfassung, statt einzeln einzutrudeln, Alarme werden nach Schweregrad geroutet, damit die dringenden auffallen, und ein kurzes Flackern piept dich nicht mehr eine Sekunde später als offline-dann-online an.

Dazu kamen mehr Desktop-Funktionen in den Server, und die Scan-Einstellungen am Desktop steuern jetzt feiner, wie tief ein Scan geht.

Einen Rechner oder Server in die mobile App aufzunehmen hieß bisher: Adresse und Zugangs-Token von Hand aufs Handy übertragen. Jetzt zeigen Desktop und Server einen QR-Code — in der App scannen, fertig.

Gleiche Sicherheit: Der Token authentifiziert die Verbindung weiterhin, du tippst ihn nur nicht mehr ab.

Eine Runde Persistenz-Fixes. Wer einen API-Schlüssel eintippte oder ein Feld änderte und dann den Tab wechselte, bevor das Feld den Fokus verlor, konnte die Änderung verlieren. Einstellungen speichern jetzt beim Tippen — auf dem Weg nach draußen geht nichts mehr verloren.

Wenn wir schon dabei waren: Der Fingerbank-Schlüssel hat jetzt einen Test-Knopf. Direkt dort prüfen, ob er funktioniert, statt später zu merken, dass das Geräte-Fingerprinting stillschweigend aus war.

Beim KI-Berater bringst du seit jeher deinen eigenen Schlüssel mit: lokal, optional, standardmäßig aus, wahlweise mit Anthropic, OpenAI, OpenRouter, Mistral, Groq, Gemini oder lokal über Ollama. Neu dazu: Azure OpenAI (Microsoft). Endpoint deiner Azure-Ressource, Deployment-Name, Azure-Key eintragen, fertig. In Desktop, Server und Mobile.

Eine Einschränkung noch: Gemeint ist Azure OpenAI, nicht die M365-Copilot-Lizenz. Die Copilot-Oberfläche in Word oder Teams ist keine API, die sich ansprechen lässt; einbinden kannst du den Azure-OpenAI-Zugang deiner Firma.

Diesmal ein größeres Paket, alles aus Nutzermeldungen. Desktop, Server und Mobile bekommen echte Änderungen.

Desktop

• Online-/Offline-Meldungen zeigen den echten Gerätenamen. Wenn ein Gerät wieder online ging oder offline fiel, konnte die Meldung die nackte IP ("Wieder online: 192.168.1.197") oder sogar die rohe MAC-Adresse zeigen. Damit lässt sich nichts anfangen. Die Namensauflösung folgt jetzt derselben Kette wie schon die Geräteliste: bekannter Name, dann der aus der MAC ermittelte Hersteller (verfügbar, sobald das Gerät überhaupt gesehen wurde), erst als letzter Ausweg die Adresse selbst.
• Live-Bandbreite flackert nicht mehr. Bei fast untätigen Geräten ist der Durchsatz größtenteils Messrauschen, wodurch sich die Liste bei fast jeder Aktualisierung neu sortiert hat. Ein Balken blitzte für einen Durchlauf auf und verschwand gleich wieder. Zeilen sortieren jetzt nach kumuliertem Traffic statt nach dem Momentanwert, und die Zahlen jedes Geräts werden vor der Anzeige geglättet. Geräte ohne aufgelösten Hostnamen zeigen jetzt außerdem ihren Hersteller statt einer doppelt angezeigten nackten IP.
• Traceroute funktioniert jetzt auch auf Netzen, die es bisher stillschweigend blockierten. Der klassische UDP-basierte Sondierungsmodus wird von vielen Firewalls, VPNs und NATs komplett verworfen — jeder Hop lief in ein Timeout mit 100 % Verlust, selbst bei einwandfreier Verbindung. Traceroute nutzt jetzt dieselben ICMP-Echo-Sonden wie ein normaler Ping, die dort durchkommen, wo der alte Modus versagte.
• Ping, DNS-Lookup und Traceroute sind jetzt mit einem funktionierenden Ziel vorausgefüllt (1.1.1.1 / google.com), sodass sich die Grundverbindung mit einem Klick prüfen lässt.
• Der DHCP-Fingerprinting-Hinweis widerspricht sich nicht mehr selbst. Die Warnung "braucht Admin-Rechte" blieb bisher auch dann sichtbar, wenn die Funktion längst erfolgreich aktiviert war und lief.
• Zwei reine Einstellungs-Bugs sind ebenfalls behoben: Bei einer bestehenden Installation konnte der Portscan nach einem Update ohne erkennbaren Grund still ausgeschaltet bleiben. Und die Namensauflösung (Hostname/Hersteller) konnte die bereits bekannten offenen Ports eines Geräts löschen, und damit die Schnellzugriff-Buttons für SSH/VNC/RDP, sobald dieser Durchlauf zufällig keinen frischen Portscan enthielt.

Server

• Der SLA-/Verfügbarkeitsbericht erklärt sich jetzt selbst. Die Geräte-/Checks-Tabellen hatten überhaupt keine Spaltenüberschriften: drei Spalten roher Zahlen, ohne jede Beschriftung. Jetzt gibt es eine echte Kopfzeile mit Hover-Erklärungen zu jeder Spalte.
• Die Prozentzahl kommt jetzt mit einer konkreten Dauer. "94,6 %" zwingt einen erst zum Kopfrechnen; jede Zeile zeigt jetzt zusätzlich eine ungefähre Ausfallzeit ("~1h 20min offline") direkt neben der farbcodierten Prozentzahl.
• Geräte-Zeilen zeigen den Hersteller statt nur die IP, wenn kein Hostname bekannt ist. Das ist derselbe Rückfall, den die Desktop-App schon nutzt.
• Die Tages-Verfügbarkeits-Heatmap kollabiert nicht mehr zu einem bedeutungslosen einfarbigen Block, wenn der Zeitraum des Berichts auf 24 h steht; sie zeigt immer genug Tage, um lesbar zu bleiben.

Mobile

"Remote-Server" (eine gespeicherte Liste, reine Ansicht) und "Sync" (LAN-Suche, ein gemeinsamer Zugangscode) überschnitten sich bisher, ohne voneinander zu wissen. Beide sind jetzt ein Screen. Jeder DeviceShelf-Server oder Desktop, mit dem du dich verbindest, ist ein gespeicherter Eintrag mit eigenem Namen, eigener Adresse und eigenem Zugangscode; die LAN-Suche fügt neue Server derselben Liste hinzu, statt einen separaten Ablauf zu starten. Für jeden gespeicherten Server kannst du entweder seine eigene, reine Ansicht öffnen oder seine vollständige Geräteliste (MAC, Hersteller) in deinen lokalen Scan übernehmen. Das behebt auch eine echte Einschränkung: Bei zwei Servern im Netz gab es bisher keine Möglichkeit, jedem seinen eigenen Zugangscode zu geben.

Zwei Fixes in der Desktop-App, beide aus Nutzermeldungen.

• Gerätenamen bleiben beim Auto-Scan stehen. Bei eingeschaltetem Hintergrund-Monitoring sprang die Geräteliste immer wieder auf nackte IP-Adressen zurück, besonders im Live-Modus mit seinen Durchläufen alle rund 5 Sekunden. Hostname, MAC, Hersteller, Betriebssystem: alles weg, bis die Anreicherung wieder nachkam. Die Ursache: Jeder Durchlauf prüft zuerst nur, wer erreichbar ist, und meldet die Geräte dabei ohne jede Identität. Dieses nackte Ergebnis überschrieb das bekannte. Ab 1.5.8 bleibt eine einmal aufgelöste Identität über die Scan-Durchläufe erhalten und wird nur noch durch einen neueren aufgelösten Wert ersetzt, nie durch einen leeren. Das gilt in der Geräteliste genauso wie in Exporten und in der Remote-API. Messwerte wie Online-Status und Ping aktualisieren sich weiterhin bei jedem Durchlauf. Und wird eine IP an ein anderes Gerät neu vergeben, verwirft DeviceShelf die alte Identität, statt sie zu übernehmen.
• Wake-on-LAN funktioniert jetzt auch mit mehreren Netzwerk-Interfaces. Das Magic Packet ging bisher über einen Socket ohne Broadcast-Berechtigung raus. Das kann das System schlicht ablehnen, und auf Rechnern mit mehreren aktiven Interfaces (etwa WLAN plus VM-Bridges) konnte das Paket zudem über das falsche Interface laufen. Jetzt geht es als Directed Broadcast über jedes aktive Interface raus; das Zielgerät bekommt es also unabhängig davon, in welchem Netz es hängt. Schlägt der Versand fehl, zeigt die App eine übersetzte Meldung statt eines rohen Netzwerkfehlers.

Die Server-Edition bekommt 1.5.8 nur, damit die Versionsnummern gleichziehen; am Server ändert sich nichts. Einstellungen, Daten und Monitore bleiben erhalten.

Ein kleines Folge-Update zu 1.5.6, alle drei Punkte kamen aus Nutzerfeedback.

• Filter, der alles ausblendet, sagt es jetzt. Bisher zeigte die Geräteliste eine leere Tabelle, wenn ein Suchbegriff oder der Favoriten-Stern alle gefundenen Geräte wegfilterte — das las sich wie „Scan hat nichts gefunden“, obwohl die Zähler oben weiter alle Geräte meldeten. Jetzt steht dort ein Hinweis („‚ei‘ blendet alle 32 Geräte aus“) mit einem Button, der Suche und Favoriten-Filter zurücksetzt.
• Scope-Anzeige folgt dem Dialog. Der Bereich oben links spiegelte nur den zuletzt gelaufenen Scan und änderte sich erst beim nächsten. Wählst du jetzt im Bereichs-Dialog ein anderes Interface oder tippst einen anderen Von/Bis-Bereich, springt die Anzeige sofort mit. Brichst du ab, geht sie auf das echte Netz zurück.
• Warnung vor unplausiblem Bereich. Ein Von/Bis über zwei Netze hinweg (etwa 192.168.1.1 bis 10.37.129.254), ein umgekehrter oder ein sehr großer Bereich löste bisher stillschweigend einen langsamen Scan durchs falsche Netz aus — bis zu 65534 Adressen. Jetzt fragt ein Dialog erst nach; ein normaler Bereich im eigenen Subnetz scannt weiterhin ohne Nachfrage.

Die Server-Edition bekommt 1.5.7 nur, damit die Versionsnummern gleichziehen; am Server ändert sich nichts. Einstellungen, Daten und Monitore bleiben erhalten.

Ein kleines Folge-Update zu 1.5.5, angestoßen durch Nutzerfeedback.

• Klarere Sammel-Benachrichtigungen. Mehrere Meldungen desselben Geräts innerhalb von 10 Minuten werden weiterhin zu einer Zeile zusammengefasst. Das Badge heißt jetzt aber „N Meldungen“ statt „wechselte Nד — Letzteres klang, als hätte die IP gewechselt. Und die Zeile listet jedes Einzelereignis mit Uhrzeit: Offline, Wieder online, Port geöffnet oder geschlossen, IP geändert. Was passiert ist, steht direkt in der Meldung; die Details muss man dafür nicht mehr öffnen.
• SSID-Spalte entfernt. Die optionale Spalte in der Geräteliste konnte technisch nur das WLAN des Scan-Rechners zeigen, in jeder Zeile denselben Wert: Per LAN-Scan lässt sich nicht ermitteln, über welche SSID ein fremdes Gerät eingebucht ist. Für Nutzer sah das aus, als zeige die Spalte schlicht nichts an. Der eigene WLAN-Name steht weiterhin in der Kopfleiste und der Netzwerk-Ansicht.

Die Server-Edition bekommt 1.5.6 nur, damit die Versionsnummern gleichziehen; am Server ändert sich nichts. Einstellungen, Daten und Monitore bleiben erhalten.

Ein kleines additives Folge-Update zu 1.5.4.

• Ausführlichere MCP-Tool-Schemas. Jedes MCP-Tool deklariert jetzt ein Output-Schema, einen lesbaren Titel und Beschreibungen pro Feld. KI-Clients (Claude, Cursor, VS Code usw.) zeigen klarere, strukturierte Ergebnisse und wählen das richtige Tool ohne Raten. Rein additiv; bestehende Verbindungen laufen unverändert weiter.
• Mehr Härtung. Eine Nacharbeit, die Review-Lücken aus dem 1.5.4-Security-Sweep schließt: API-Auth, Benachrichtigungen und der Mobile-Export-Pfad.

Keine Verhaltensänderungen. Einstellungen, Daten und Monitore bleiben erhalten.

1.5.4 ist ein gezielter Sicherheits- und Robustheits-Durchgang: 27 Fixes, keine neuen Features, keine Verhaltensänderungen.

API & Auth (Server-Edition)

• Deny-by-default. Der Token-Guard nutzt jetzt eine Allowlist: nur die statische Dashboard-Shell ist öffentlich; /api/*, /metrics und /mcp verlangen alle einen Token. (Die frühere Blocklist musste private Pfade aufzählen und hätte /mcp einmal fast ohne Auth ausgeliefert.)
• Brute-Force-Backoff. Nach wiederholten fehlgeschlagenen Auth-Versuchen von einer IP kommen weitere Anfragen für eine kurze Sperre auf 429, ein Bearer-Token lässt sich so nicht online erraten.
• Role-Spoof-Schutz. Der X-DS-Role-Header wird aus eingehenden Anfragen entfernt und nur vom Guard gesetzt, ein Client kann sich nicht als admin ausgeben.
• Request-Timeouts. Read-/Header-/Idle-Timeouts schützen vor Slowloris-artigem Verbindungshalten (der SSE-Dashboard-Feed ist ausgenommen).
• Warnung bei schwachem Token beim Start, wenn der API-Token kürzer als 24 Zeichen ist.

Der Rest

• Benachrichtigungen redigieren Secrets aus den Payloads, und der Sende-Pfad ist defensiver.
• Härtung in Scanner (Ping, UPnP), Store, Syslog-Empfänger und SNMP-Discovery, plus ein Safe-Goroutine-Wrapper, damit ein Hintergrund-Panic den Server nicht umwirft.
• Mobile: sichereres Desktop-Sync-Parsing und Export.

Empfohlenes Update. Einstellungen, Daten und Monitore bleiben unverändert.

Der im Preview gezeigte MCP-Server ist jetzt in der Server-Edition verfügbar.

• Worum es geht. DEVICESHELF_MCP_ENABLE=true setzen, und ein KI-Assistent kann dein Netzwerk in natürlicher Sprache abfragen: „was ist online?“, „welche Zertifikate laufen bald ab?“, „was ist verwundbar?“ — beantwortet aus deinen eigenen Daten. 14 Read-only-Tools (Inventar, Monitoring, Security-Übersicht in einem Aufruf) plus geführte Prompts.
• Strikt lokal, read-only. Der Endpoint läuft in deinem Server, hinter demselben Bearer-Token, nur im LAN erreichbar. Kein Cloud-Connector. Schreibaktionen (Umbenennen, Bestätigen, Scan) bleiben aus, außer du setzt DEVICESHELF_MCP_ALLOW_ACTIONS; von Geräten gemeldete Strings gelten als nicht vertrauenswürdig.
• Jeder Agent lässt sich verbinden. Copy-Paste-Setup für Claude Code, Claude Desktop, Cursor, VS Code (Copilot), Windsurf, Cline und Gemini CLI steht auf der Server-Seite. Die meisten verbinden sich nativ über Streamable HTTP; ChatGPT braucht einen öffentlichen HTTPS-Tunnel, weil es in der Cloud läuft.
• Lizenz. In jeder bezahlten Lizenz enthalten und während der 7-Tage-Testphase nutzbar.

Die Desktop-App ist unverändert gegenüber 1.5.2.

Ein kleines, abwärtskompatibles Folge-Update zu 1.5.1:

• Server: Der Dashboard-Header zeigt jetzt die laufende Version (dazu ein öffentlicher /api/version-Endpoint).
• Server: Das E-Mail/SMTP-Setup ist klarer. Gängige Anbieter (Gmail, Yahoo, Outlook, iCloud …) werden automatisch erkannt, und ein neuer Hilfeabschnitt erklärt das nötige App-Passwort.
• Desktop: Alle Status- und Fehlermeldungen aus dem Backend sind jetzt in allen sieben Sprachen lokalisiert.

Monitore, Einstellungen und Daten bleiben unverändert.

1.5.1 baut auf der Monitoring-Basis von 1.5 auf, vor allem in der headless Server-Edition, und bringt die Geräteverwaltung im Desktop ein gutes Stück weiter.

Server-Edition

• Push-/Heartbeat-Monitore. Ein neuer Check-Typ für Jobs, die sich „melden“ sollen: Ein Cronjob, Backup oder Skript schickt nach Plan ein POST an eine private /api/push/<token>-URL. Kommt innerhalb des eingestellten Fensters kein Heartbeat, geht der Monitor auf down und alarmiert. Ideal für Dinge, die ein Port-Check nicht sieht.
• HTTP-Keyword- und Status-Prüfungen. HTTP-Checks können jetzt einen exakten Status-Code verlangen (z. B. 200 oder 401 für einen auth-geschützten Endpunkt) und prüfen, ob der Antwort-Body einen Text enthält — oder nicht enthält. Eine Seite, die schnell lädt, aber einen Fehler zeigt, zählt nicht mehr als „up“.
• Retries vor Alarm. Jeder Check kann N Fehlversuche in Folge verlangen, bevor er alarmiert. Ein einzelner Aussetzer weckt dich also nicht.
• Read-only-Zugriffstoken. Setze einen zweiten, schreibgeschützten Token (DEVICESHELF_API_VIEWER_TOKEN) für reinen Lesezugriff, wahlweise über die API (nur GET) oder als read-only Dashboard. Jede Änderung braucht weiterhin den vollen Token.
• Tägliche Verfügbarkeits-Balken. Die Berichte zeigen jetzt einen Balken pro Tag für jedes Gerät und jeden Check, neben den SLA-Prozenten.
• Konfigurations-Backup. Exportiere Einstellungen und Monitore als JSON-Datei (ohne Passwörter oder Token) und spiele sie auf demselben oder einem anderen Server zurück.
• REST-API-Dokumentation. Die komplette Server-API ist jetzt dokumentiert, inklusive der neuen Endpunkte.

Desktop

• Eigene Gerätetypen mit Auto-Erkennung für Switches, Access Points und Firewalls, durchsuchbarer Typ-Auswahl, einem aufgefrischten farbigen Icon-Set und einem Notiz-Tooltip pro Zeile beim Überfahren.

Fixes

• Der farbige linke Akzent-Balken an den Dashboard-Cards ist entfernt (kosmetisch).
• Die Server-Timeline beschriftet Monitor-Check-Ereignisse jetzt korrekt, statt einen rohen Schlüssel zu zeigen.

Kompatibilität

Abwärtskompatibel; keine Breaking Changes. Bestehende Konfiguration und Daten bleiben erhalten. Die neuen Check-Optionen und der Read-only-Token sind opt-in, ein Update löst also von selbst keine neuen Benachrichtigungen aus.

DeviceShelf 1.5 ergänzt Monitoring über die reine Erreichbarkeit hinaus. Die Änderungen:

Neu in 1.5

• Schwellwert-Checks. Checks pro Gerät mit Warn- und Fehler-Schwellen definieren. Unterstützte Typen: Ping-Latenz, TCP-Port-Erreichbarkeit, HTTP/HTTPS-Status (optional mit Vergleich eines Werts aus einer JSON-Antwort per Dot-Path) und SNMP-Werte.
• Abhängigkeiten. Ein Check kann von einem übergeordneten Gerät abhängen (z. B. Switch oder Gateway). Ist das übergeordnete Gerät aus, werden die Alarme der abhängigen Checks unterdrückt. Ein Ausfall weiter oben erzeugt so einen Alarm statt einen pro nachgelagertem Gerät.
• Alarm-Lebenszyklus.
• Quittieren: einen bekannten Alarm als gesehen markieren, damit er nicht erneut benachrichtigt.
• Wartungsfenster: geplante Zeiträume, in denen Checks keine Alarme auslösen.
• Ruhezeiten: wiederkehrende Zeiträume, in denen keine Push-Benachrichtigungen gesendet werden.
• Desktop-an-Server-Anbindung. Die Desktop-App kann sich mit einem oder mehreren Headless-DeviceShelf-Servern verbinden und deren Inventar, Subnetz, Online-Status, Timeline und Alarme lesen sowie Alarme aus der Ferne quittieren.

Kompatibilität

Abwärtskompatibel; keine Breaking Changes. Bestehende Konfiguration und Daten bleiben erhalten. Checks sind opt-in (du legst sie an), das Update löst also von sich aus keine neuen Benachrichtigungen aus.

Ein gezieltes Folge-Update zum großen 1.4.0-Release: Die Erkennung wird treffsicherer, Alerts sagen mehr, und Updates lassen sich bequemer prüfen.

✨ Neu in 1.4.2

• Fingerbank-Geräteerkennung. Geräte werden jetzt über ihren DHCP-Fingerprint via Fingerbank identifiziert. Das heißt: bessere Treffer bei Hersteller, Typ und OS, besonders bei IoT-Geräten.
• Ausführlichere Alerts. Alert-Texte schreiben jetzt alles aus: IP, Hersteller, Gerätetyp, OS, offene Ports und den Fingerbank-Treffer. Eine Benachrichtigung sagt dir, was passiert ist, ohne dass du die App öffnen musst.
• Opt-in-Update-Hinweis. Ein „Jetzt prüfen“-Button (und ein optionaler Check beim Start) sagt dir, wenn eine neue Version da ist. Installiert wird nie automatisch; das entscheidest du.

Außerdem seit 1.4.0 (mit 1.4.1 ausgeliefert)

• Offline-Geräte bleiben sichtbar in der Liste, statt zu verschwinden.
• Dashboard-Feinschliff: Auto-Save, ein Favicon, eine klarere WAN-Erklärung und ein Live-Status-Fix.
• Desktop: SSH-Login und Scan-Range-Fixes.

🖥 Server-Edition (Beta)

Der 1.4.2-Server bringt dasselbe passive DHCP-Fingerprinting (lauscht auf UDP-Port 67). Da der Container bewusst als nicht-privilegierter Benutzer läuft, braucht das Binden dieses niedrigen Ports eine eng begrenzte Capability: NET_BIND_SERVICE (kein Root, kein NET_ADMIN, nur das Öffnen niedriger Ports). Ohne sie läuft der Server normal weiter, nur die DHCP-/Fingerbank-Identifikation entfällt.

Ergänze deine Compose um --cap-add NET_BIND_SERVICE und zieh :1.4.2. Alle Schritte stehen in der Server-Installationsanleitung. Es ist eine Beta — Bug-Reports & Feature-Requests sind sehr willkommen.

Update laden

Aktualisiere direkt in der App (oder klick auf Nach Updates suchen) oder hol dir 1.4.2 auf deviceshelf.app. Wie immer: local-first, keine Telemetrie, kein Konto.

1.4.0 ist groß. Hier ist alles, was neu ist und behoben wurde, dazu die erste öffentliche Beta der Server-Edition.

✨ Neu

• Notification-Center. Eine Glocke in der Toolbar sammelt, was sich geändert hat, während du woanders hingeschaut hast: Geräte kommen und gehen, Ports öffnen sich, Alerts feuern.
• Auto-/Live-Scan. Einschalten, und DeviceShelf behält dein Netzwerk durchgehend im Blick. Alle paar Sekunden frisch, statt auf einen manuellen Scan zu warten.
• Smartere Geräteliste. Nach jeder Spalte sortieren, per RDP mit einem Klick verbinden, und Port-Gating, damit ein Scan genau das tut, was du willst.
• In-App-Rollback. Du brauchst den vorherigen Build? Geh direkt in der App auf eine frühere Version zurück.
• Npcap-Hinweis unter Windows. Der Windows-Installer weist jetzt darauf hin, wenn Npcap gebraucht wird (für die Live-Bandbreite pro Gerät), mit direktem Link.
• Local-API-Token-UX. Einrichten und Nutzen des Local-API-Tokens ist einfacher und klarer.

🐛 Behoben

• Fingerbank-Rate-Limit. Die Geräte-Identifikation läuft nicht mehr ins Rate-Limit des Anbieters.
• Scan-Range-/CIDR-/Speicher-Fixes. Eigene Bereiche und CIDR-Eingaben werden korrekt geparst, und das Speichern ist zuverlässig.

🖥 Die Server-Edition geht in die Beta

Die headless 24/7-Server-Edition erscheint mit 1.4.0 zum ersten Mal: durchgehende Überwachung ohne GUI, die du in Docker laufen lässt (oder als .deb installierst, jetzt in der CI gebaut), auf einem Linux-Rechner oder einer VM. Sie ist von deiner bestehenden Lizenz abgedeckt. Gleicher Schlüssel, kein Aufpreis.

Das ist eine Beta. Rechne mit ein paar Ecken und Kanten. Wenn dir ein Fehler begegnet oder du dir ein Feature wünschst, schreib uns — dein Feedback entscheidet, wohin es als Nächstes geht. Abonniere unten, um dranzubleiben.

Update laden

Aktualisiere direkt in der App oder hol dir 1.4.0 auf deviceshelf.app. Wie immer: local-first, keine Telemetrie, kein Konto.