DeviceShelf Blog

Release-Verlauf

Jedes DeviceShelf-Release auf einer Seite — neuestes zuerst. Version aufklappen für die vollständigen Notes.

English

← Alle Beiträge

DeviceShelf 1.7.9 — ein Router, der dich abweist, sagt jetzt warum Bisher lag es bei jeder gescheiterten Router-Verbindung angeblich am Passwort, auch dort, wo kein Passwort je geholfen hätte. Die App unterscheidet die Fälle jetzt, und die vier Marken, die man erst freischalten muss, sagen das unter der Auswahl. Siebzehn Marken wurden gegen aufgezeichnete Antworten nachgeprüft. Schwellenwert-Prüfungen speichern beim Tippen, laufen schon beim ersten Takt nach einem Neustart und halten fest, was sie gemessen haben.

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.

DeviceShelf 1.7.8 — gesucht wird, was du eingetragen hast Ein Subnetz im Suchbereich-Feld änderte bisher gar nichts; auf dem Server konnte es sogar das eigene Netz ersetzen. Beides ist behoben, und die App sagt jetzt, wenn sie einen Teil des Bereichs verworfen hat. Alarme werden stummgeschaltet statt quittiert, das macOS-Fenster behält seine Symbolleiste im Bild, und beide Geräte-Drawer funktionieren per Tastatur und Screenreader. Der Beitrag holt außerdem 1.7.4 bis 1.7.7 nach, die der Liste eine Zeile pro Maschine beigebracht haben.

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.

DeviceShelf 1.7.3 — eine Geräteliste, und du wählst, wessen Netz sie zeigt Die Quellen-Pille in der Symbolleiste steuert jetzt die Geräteliste, statt auf einen zweiten Bildschirm zu springen. Häkchen bei der Suche dieses Rechners, bei beliebigen Collectors oder bei mehreren gleichzeitig; die Herkunft wird eine Spalte, nach der sich sortieren und filtern lässt. Die Sicherheitsanalyse folgt derselben Wahl und sagt, wie viele Geräte sie tatsächlich prüfen konnte.

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.

DeviceShelf 1.7.2 — Geräte im Server-Dashboard bearbeiten Das Server-Dashboard setzt jetzt Gerätetyp, Tags, Notiz, Favorit und Stummschaltung und sagt, auf welchem Rechner ein Container läuft. Umbenennen löscht Notiz und Typ-Override nicht mehr, und ein Rechner mit mehreren MAC-Adressen ist wieder eine Zeile.

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.

DeviceShelf 1.6.24 — Router-Import hält sich an den Scan-Bereich Geräte aus der Client-Tabelle des Routers oder per SNMP bleiben jetzt im konfigurierten Scan-Bereich, selbstvergebene 169.254.x-Adressen tauchen nicht mehr als dauerhaft offline geführte Geister auf, und die Testphase meldet sich ehrlich, bevor sie endet.

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.

DeviceShelf 1.6.23 — der Sync frisst keine Gerätenamen mehr Ein voller Re-Pull vom Server konnte frisch geschriebene Namen, Tags und Typen mit alten leeren Records überschreiben. Der Sync mergt jetzt revisionsbasiert statt zu ersetzen, und die Monitor-Liste lernt Sortieren und Filtern.

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.

DeviceShelf 1.6.22 — Anwesenheit, mit der Home Assistant etwas anfangen kann Der Export lieferte Anwesenheit als Binärsensor, den keine Person-Entität lesen kann. Jetzt kommen ein Device-Tracker, ein Problem-Sensor je überwachtem Check und die Messwerte jeder abgefragten Maschine dazu.

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.

DeviceShelf 1.6.21 — der Server spricht mit Home Assistant Die Server-Edition überträgt ihr Inventar jetzt an Home Assistant. Anwesenheit war nie der interessante Teil; zu wissen, dass gerade ein unbekanntes Gerät dazugekommen ist, schon.

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.

DeviceShelf 1.6.20 — Zugangsdaten, die bleiben Gespeicherte API-Token konnten durch eine Einstellung gelöscht werden, die nichts mit ihnen zu tun hatte. Der frühere Fix sicherte das Einstellungsformular ab, aber ein Dutzend Code-Pfade laufen gar nicht darüber.

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.

DeviceShelf 1.6.19 — der Alarm-Dialog, und was ein Server wirklich kann Die Alarm-Einstellungen eines gekoppelten Servers gingen nie auf. Beim Beheben kam ein leiserer Fehler zum Vorschein: Die App nahm an, jeder Server könne alles, und so sah eine fehlende Funktion aus wie eine vorhandene.

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.

DeviceShelf 1.6.18 — Tastatur, Screenreader und ein Satz Farben Die Geräteliste lässt sich ohne Maus bedienen und wird richtig vorgelesen, das Server-Dashboard hat einen Hellmodus, und alle drei Apps teilen sich dieselben Tokens.

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.

DeviceShelf 1.6.17 — ein Stummschalter, und Fehler, die sagen was los ist Ein Schalter legt alle Alarme eines Servers still, und Verbindungsfehler benennen endlich ihre Ursache.

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.

DeviceShelf 1.6.16 — Reparaturen am Alarm-Editor und härterer MCP-Endpunkt Fehlerbehebungen am Alarm-Editor aus 1.6.15 und ein Sicherheitsdurchgang durch den MCP-Endpunkt.

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 — Alarm-Einstellungen aus Desktop und Mobile Die wichtigsten Alarmregeln eines verbundenen Servers direkt aus Desktop und Mobile konfigurieren.

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 — klarere Remote-Ansichten und Server-Ersteinrichtung Zwischen reiner Serveransicht und sicherer kombinierter Ansicht wählen, Remote-Fehler verständlich anzeigen und beim macOS-Server URL und Token nach der Installation erhalten.

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 — zuverlässige Server-Erkennung und gespeicherter Scan-Bereich Die Server-Erkennung kommt jetzt mit veralteten oder nicht-standardmäßigen mDNS-Ports klar, gespeicherte Remote-URLs werden automatisch repariert, und Start-Scans respektieren Interface und Range.

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 — Server-Verlauf in jedem Client Desktop- und Mobile-Clients zeigen jetzt den vom DeviceShelf-Server gesammelten Verfügbarkeitsverlauf, Gerätenamen sind sauberer, und Server kündigen sich im LAN an.

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.

DeviceShelf 1.6.9 — IP-Zuweisungstyp, robustere KI-Identifikation Jedes Gerät zeigt jetzt, wie es zu seiner IP kam (statisch, DHCP oder reserviert), direkt vom Router. Die KI-Identifikation hält über alle Anbieter durch und folgt der App-Sprache, und ein Speichern der Einstellungen gefährdet die hinterlegten Secrets nicht mehr.

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.

DeviceShelf 1.6.7 — Fix fürs Einfrieren nach längerer Laufzeit Zwei Ressourcen-Leaks, die die App nach längerer Laufzeit hängen ließen und den Rechner auslasteten (vor allem bei aktivem Live-Monitoring), sind behoben.

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.

DeviceShelf 1.6.6 — Router-Marken, präzisere Identifikation, OpenAI-kompatible KI Die Router-Anbindung deckt jetzt 17 Marken ab, die Geräte-Identifikation stützt sich auf selbst gemeldete Signale, der KI-Assistent spricht mit jedem OpenAI-kompatiblen Endpunkt, und Einstellungen überstehen eine Neuinstallation.

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.

DeviceShelf 1.6.5 — Diagnose, die man lesen kann Die Diagnose-Werkzeuge und Geräteprüfungen werfen kein rohes JSON mehr aus, sondern zeigen lesbare Ergebnisse.

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.

DeviceShelf 1.6.4 — Ein Gerät, eine SLA-Zeile Ein Gerät konnte mehrfach im SLA-Report auftauchen, mit irreführenden Verfügbarkeitswerten. Behoben, und bestehende Daten verschmelzen beim ersten Start nach dem Update von selbst.

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.

DeviceShelf 1.6.3 — Dashboard-Umbau, Metrik-Verlauf und Disk-Voll-Prognose Das Server-Dashboard schrumpft von zehn auf sechs Tabs, die Einstellungen bekommen gruppierte Sektionen mit direkten Links, Infrastruktur-Metriken behalten eine Woche Verlauf, und Disks warnen, bevor sie volllaufen.

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.

DeviceShelf 1.6.2 — Windows-Installer wählt den Npcap-Build selbst install.exe mit vorhandenem Npcap starten, und der Server läuft mit Live-Bandbreite und aktivem ARP, ohne Handarbeit am Dienst.

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.

DeviceShelf 1.6.1 — Server-Versions-Fix für Windows und .deb Die Windows- und .deb-Server-Builds zeigten keine Version und boten nie Updates an. Behoben, und das Windows-Zip bekommt einen optionalen Npcap-Build mit Live-Bandbreite.

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.

DeviceShelf 1.6.0 — Container, Hypervisoren, Datenbanken und NAS-Zustand Der Server überwacht jetzt Docker-Container, Proxmox-Nodes und -Gäste, Datenbank-Dienste, NAS-Disk-/RAID-Zustand und Hardware-Temperaturen. Jeder Alarm lässt sich einzeln abschalten.

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.

DeviceShelf 1.5.15 — Neues Icon und ein echter Windows-Server-Installer Frisches Icon auf allen Plattformen, ein Statusflacker-Fix, gemerkte Scan-Einstellungen und ein echtes install.exe für den Server.

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.

DeviceShelf 1.5.14 — Englische Oberfläche und Router-Topologie Englisch ist jetzt die primäre Oberflächensprache, und die Topologie kann direkt vom UniFi- oder Router-Controller kommen.

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.

DeviceShelf 1.5.13 — Weniger, bessere Meldungen am Server Meldungs-Flut-Bremse für die Server-Edition, mehr Gleichstand mit dem Desktop, feinere Scan-Einstellungen.

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.

DeviceShelf 1.5.12 — Handy per QR koppeln Die mobile App per Scan mit Desktop oder Server verbinden — ohne URL und Token abzutippen.

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.

DeviceShelf 1.5.11 — Einstellungen, die bleiben Einstellungen speichern jetzt beim Tippen, und der Fingerbank-Schlüssel bekommt einen Test-Knopf.

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.

DeviceShelf 1.5.10 — Azure OpenAI als KI-Anbieter Azure OpenAI (Microsoft) steht jetzt als KI-Anbieter zur Wahl, in Desktop, Server und Mobile.

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.

DeviceShelf 1.5.9 — echte Gerätenamen in Benachrichtigungen, ein klarerer Verfügbarkeitsbericht und vereinheitlichte Server-Verwaltung Ein größeres Fix-Paket aus Nutzermeldungen über alle drei Apps hinweg: Benachrichtigungen und Live-Bandbreite zeigen echte Gerätenamen statt nackter IPs/MACs, Traceroute funktioniert jetzt auch auf Netzen, die es bisher blockierten, der Server-Verfügbarkeitsbericht bekommt Überschriften und eine Ausfallzeit-Anzeige, und die Server-Liste der Mobile-App ist zu einem Screen vereinheitlicht.

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.

DeviceShelf 1.5.8 — stabile Gerätenamen und ein Wake-on-LAN-Fix Zwei Desktop-Fixes: Gerätenamen fallen beim Hintergrund-Monitoring nicht mehr auf nackte IP-Adressen zurück, und Wake-on-LAN funktioniert auch auf Rechnern mit mehreren aktiven Netzwerk-Interfaces. Nur Desktop.

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.

DeviceShelf 1.5.7 — Geräteliste und Scan-Bereich aufgeräumt Drei Fixes aus Nutzerfeedback: ein Hinweis, wenn ein Filter alle Geräte ausblendet; die Scope-Anzeige oben folgt jetzt dem Bereichs-Dialog; und ein unplausibler Von/Bis-Bereich fragt vor dem Scan nach. Nur Desktop.

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.

DeviceShelf 1.5.6 — verständlichere Benachrichtigungen Zusammengefasste Meldungszeilen zeigen jetzt die Einzelereignisse mit Uhrzeit statt eines missverständlichen „wechselte Nד-Zählers; die SSID-Spalte in der Geräteliste entfällt. Beides geht auf Nutzerfeedback zurück.

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.

DeviceShelf 1.5.5 — ausführlichere MCP-Tool-Schemas, mehr Härtung MCP-Tools deklarieren jetzt Output-Schemas, Titel und Feld-Beschreibungen für klarere KI-Client-Ergebnisse, plus Sicherheits-Nachbesserung aus dem 1.5.4-Review. Additiv, keine Verhaltensänderungen.

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.

DeviceShelf 1.5.4 — Sicherheits- und Robustheits-Härtung Ein Härtungs-Durchgang mit 27 Fixes für Sicherheit und Robustheit: strengere API-Auth (deny-by-default, Brute-Force-Backoff, Role-Spoof-Schutz, Request-Timeouts), redigierte Benachrichtigungen und Härtung in Scanner, Storage, Syslog und Mobile. Keine Verhaltensänderungen.

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.

DeviceShelf 1.5.3 — der MCP-Server ist da Die Server-Edition liefert jetzt den MCP-Server: read-only, strikt lokaler Zugriff auf Live-Inventar und Monitoring für KI-Assistenten über das Model Context Protocol. Copy-Paste-Setup für Claude, Cursor, VS Code, Windsurf, Cline und Gemini CLI.

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.

DeviceShelf 1.5.2 — Versionsanzeige im Server, klareres E-Mail-Setup Ein kleines, server-fokussiertes Update. Das Dashboard zeigt die laufende Version, das E-Mail/SMTP-Setup ist klarer, und Backend-Meldungen der Desktop-App sind jetzt in allen sieben Sprachen lokalisiert.

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.

DeviceShelf 1.5.1 — Push-/Heartbeat-Monitore, HTTP-Keyword-Checks, Read-only-Zugriff, Uptime-Balken 1.5.1 erweitert die Server-Edition um Push-/Heartbeat-Monitore, HTTP-Keyword- und Status-Prüfungen, Retries pro Check, einen Read-only-Token, tägliche Uptime-Balken und ein JSON-Konfigurations-Backup. Der Desktop bekommt eigene Gerätetypen mit Auto-Erkennung und ein neues Icon-Set. Abwärtskompatibel.

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 — Schwellwert-Monitoring, Abhängigkeiten, Alarm-Lebenszyklus, Server-Anbindung 1.5 ergänzt Schwellwert-Checks (Ping, TCP, HTTP/JSON, SNMP), abhängigkeitsbasierte Alarm-Unterdrückung, einen Alarm-Lebenszyklus (Quittieren, Wartungsfenster, Ruhezeiten) und die Desktop-an-Server-Anbindung. Abwärtskompatibel.

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.

DeviceShelf 1.4.2 — Fingerbank-Geräteerkennung, ausführlichere Alerts & Update-Hinweis 1.4.2 bringt Fingerbank-gestützte Geräteerkennung, deutlich detailliertere Alerts (IP, Hersteller, Typ, OS, Ports) und einen Opt-in-Update-Hinweis, plus alles aus 1.4.1 (Offline-Geräte, Dashboard-Feinschliff, Desktop-SSH).

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.

DeviceShelf 1.4.0 — Live-Monitoring, Benachrichtigungen & eine Server-Beta Ein großer Release: Notification-Center, Auto-/Live-Scan, smartere Geräteliste, In-App-Rollback, ein Npcap-Hinweis unter Windows und viele Fixes. Plus die erste Beta der headless 24/7-Server-Edition.

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.

Netzwerk-Tipps und Produkt-Updates

Gelegentlich ein Guide, neue Features und Release-News, direkt in dein Postfach. Kein Spam, jederzeit abbestellbar.