Каталог Поиск 0 Сравнить 0 Закладки 0 Корзина Войти
Каталог
105082, Москва, ул. Фридриха Энгельса, 75с21, БЦ Бауманский ИТКОЛ
Пн - Пт: с 09-00 до 18-00 Сб: с 10-00 до 18-00 Вс: выходной
Страницы: 1 2 След.
RSS
Камеры UniFi Protect постоянно отключаются после последнего обновления, UniFi Protect
 
Привет всем, я столкнулся с повторяющейся проблемой в своей системе UniFi Protect после обновления на последнюю версию прошивки. Несколько моих камер периодически отключаются, а затем переподключаются через несколько минут. Это происходит множество раз в день, из-за чего трансляция в реальном времени и запись событий становятся ненадёжными.

Вот мои параметры системы для справки:
UniFi Protect Version: 3.1.17
UniFi OS Console: Dream Machine Pro (UDM-Pro)
Camera Models: G4 Bullet и G4 Dome
Network: Проводная сеть Ethernet, все камеры подключены через коммутатор UniFi 24-Port PoE Switch

Что я уже пробовал:
Перезагрузил как UDM-Pro, так и коммутатор.
Проверил питание PoE и сетевое соединение — всё выглядит стабильно.
Перезагрузил одну камеру и повторно добавил её; проблема вернулась через несколько часов.
Посмотрел логи — ничего необычного, кроме сообщений "camera disconnected".

Заметил ли кто-нибудь подобное поведение после недавнего обновления Protect? Может быть, это проблема с прошивкой или согласованием PoE? Буду очень благодарен за любую информацию или временное решение.

Спасибо заранее за помощь! – Alex
 
Это интересно, потому что со мной произошло противоположное. Оригинальный жёсткий диск на моём ck+ вышел из строя, и я заменил его на SSD всего несколько месяцев назад. Проблема с камерами, которые всё время отключаются, началась вскоре после этого, хотя я не могу точно сказать, когда именно.
 
Хотел также отчитаться и сказать, что последний релиз protect, похоже, разрешил эту проблему — у меня не было ни одного отключения камеры с момента обновления две недели назад.
 
Похоже, эти проблемы наконец-то решены в версии 4.75.66. Это влияло на 5 G3 Flex'ов, и пока что всё выглядит лучше.
 
У меня была такая же проблема с несколькими камерами — видеопоток постоянно отключался и переподключался каждые 5-8 минут, и это происходило весь день напролет. Никаких изменений в оборудовании не было, поэтому я подумал, что дело в ПО. Пробовал разные версии прошивки, включая EA. Ничего не помогало. Потом обнаружился сбой SSD, и его пришлось менять. Установил новый диск — проблема решена. С тех пор ни одного отключения. Старому было около 4 лет. Похоже, регистратор просто не мог работать стабильно без исправного «мозга».
 
Привет всем. Я уже давно работаю с поддержкой Unifi Tech. У меня тоже отключались камеры с тремя точками. Началось, кажется, в ноябре. Долгая история коротко: после множества изменений настроек и полного сброса, техподдержка попросила меня включить EA early release для Protect. Оказалось, что несколько моих камер нуждались в обновлении. После того как я обновил их все, с камерами всё в порядке. Больше не отключаются. Клянусь, я проверил тысячу раз, что они актуальны. Видимо, ошибся. Я немного боялся это писать, потому что не хочу накликать беду на свою систему. Надеюсь, это поможет вам!🙂
 
У меня тоже самое, это длится уже месяцы с всего лишь ТРЕМЯ камерами G5 Flex… Нагрузка точно не проблема. Очень разочаровывает.

UniFi 5.0.16
Network 10.2.105
Protect 7.0.104
 
Я уже почти год борюсь с этой проблемой. Моя система состоит из UNVR с двумя дисками по 16 ТБ, UDM SE Pro Max и коммутатора на 24 порта с POE. Я проверил всю конфигурацию сети и убедился, что RSTP не вызывает никаких проблем. У меня работает примерно 21 камера — микс G6, G4 и G3. Основные проблемы именно с G3 и G4 камерами, а G6 PTZ вообще не подвержена сбоям. Камеры отключаются на 15-20 секунд, светодиод на камере становится белым, как будто она переподключается или что-то в этом роде, и в ленте времени постоянные разрывы в течение дня. Я искренне надеюсь, что эта проблема когда-нибудь решится, и надеюсь, что это не способ заставить людей покупать новые камеры, ведь мои G6 камеры не страдают от этого — это просто выглядит странно.

Protect 7.0.94
UNVR 5.0.16
 
Вернулось! Настройка работала всего 3 дня.
 
Служба поддержки предложила, что этот выпуск Early Access может помочь, так как снижает нагрузку на CPU: https://community.ui.com/releases/UniFi-OS-Dream-Machines-5-1-5/2ce01950-b418-44b0-a7e9-4db2e4a742ef

Однако я не готов его проверять (и рискую ещё больше дестабилизировать свою систему), тем более что в комментариях упоминаются проблемы с обновлением на эту версию.
 
Я столкнулся с той же проблемой на Stacked NVR-Pros. После обновления прошивки постоянно появляются предупреждения об отключении. Я заметил, что основной NVR показывает Protect 7.0.94 UniFi OS 5.0.16, а дополнительный NVR показывает Protect 5.3.38 UniFi OS 4.1.11. Это нормально?
 
Сброс будильников до заводских настроек, а затем их переустановка на мои параметры сработала для меня хотя бы на день. Не уверен, связаны ли проблемы с мониторингом будильников с проблемами Java. Надеюсь, это останется стабильным.

Чтобы сбросить будильники в UniFi Protect, откройте Alarm Manager в левом нижнем углу панели управления, где вы можете удалять отдельные пользовательские будильники, редактировать расписание или использовать кнопку "Reset" для восстановления всех настроек до заводских значений по умолчанию.
 
Последняя версия Protect 7.0.88 кажется нормальной — за неделю не было ни одного сбоя. В любом случае я также заменил жёсткий диск.
 
В зависимости от того, как ты отслеживаешь загруженность процессора, iowait может не учитываться, так как в этом случае процессор не выполняет работу, а ожидает данные с накопителя. Утилита командной строки top выводит это в отдельной колонке. Пару дней с отключённой непрерывной записью — и SSD стабилизировался (хотя, очевидно, это не решение проблемы). Всё указывает на проблемы с хранилищем.
 
Странно, но я только что получил кучу оповещений об отключении камер. Вход в UDM через приложение прошёл нормально (я на работе, поэтому прямого доступа нет). CPU на UDM работает на 16%, память на 92%. Все камеры показывают время работы 6 дней (перезагрузил всю сеть на прошлых выходных). Вход в Protect через приложение прошёл без проблем, все камеры отображаются (1 G5 Bullet и 3 G3 Flex) — всё работает как надо, и оповещения прекратились. Обычно в такой ситуации оба приложения (Protect и Network) полностью зависают!
2tb Rust 5400 Seagate Drive
 
CK2+ работал стабильно целый день без отключений на исходном жестком диске в сравнении с SSD без кэша, что для меня выглядит странно, но явно указывает на то, что в моём случае проблема связана с хранилищем. Учитывая, что конфигурация SSD работала нормально более года и начала глючить одновременно с остальными участниками ветки, похоже, что Unifi что-то изменили в приложении, что вызвало проблему, а отключения — это симптом того, что хранилище уже работало на пределе своей доступной ёмкости. Я отключил постоянную запись на пару камер, чтобы снизить постоянную нагрузку на SSD, завтра отчитаюсь, поможет ли это.
 
Да, процессоры скачут на 100% нагрузки (в моём случае iowait), когда это происходит, и веб-интерфейс становится очень тормозным и практически неработающим. SSH-подключения тоже занимают очень много времени. Я не думаю, что это отключение камер само по себе или что-то связанное с сетью, я довольно уверен, что на хосте Protect происходит что-то, что перегружает планировщик хранилища и блокирует систему настолько, что отключение камер — это просто симптом этого.
 
Я следил за комментарием от поддержки Ubiquiti, в котором упоминалось, что высокая нагрузка на процессор может быть причиной отключения камер. Я не знаю, что именно дает сбой (и почему так часто). Ваше устройство потребляет много CPU в момент отключения? Моё предположение такое: есть какой-то heartbeat, который при значительной нагрузке не обрабатывается достаточно быстро, чтобы удовлетворить требования системы, и хост воспринимает это как отключение.
 
Я не видел отчета о сбое в моем случае, но похоже, что он пытается записать дампы сбоев на диск, что может вызывать проблему. ace.jar — это сетевая консоль, насколько я знаю, поэтому она не должна напрямую отключать камеры в случае краша.
 
root@UniFi-CloudKey-Gen2-Plus:~# iostat -x 1
Linux 3.18.44-ui-qcom (UniFi-CloudKey-Gen2-Plus)   03/11/26      _aarch64_    (8 CPU)

avg-cpu:  %user   %nice %system %iowait  %steal   %idle
          9.41    0.73    9.12    0.82    0.00   79.92

Device              r/s     rkB/s   rrqm/s  %rrqm r_await rareq-sz      w/s      wkB/s   wrqm/s  %wrqm w_await wareq-sz       d/s      dkB/s   drqm/s  %drqm d_await dareq-sz      f/s f_await  aqu-sz  %util
mmcblk0            5.29    193.43    24.01  81.95    2.91    36.57     6.54     61.25     5.65  46.36    7.48     9.36     0.00     0.00     0.00   0.00    0.00     0.00     0.00    0.00    0.06   1.43
mmcblk0rpmb        0.00     0.01     0.00   0.00    0.00     4.00     0.00     0.00     0.00   0.00    0.00     0.00     0.00     0.00     0.00   0.00    0.00     0.00     0.00    0.00    0.00   0.00
mtdblock0          0.01     0.37     0.00   0.00   74.50    48.00     0.00     0.00     0.00   0.00    0.00     0.00     0.00     0.00     0.00   0.00    0.00     0.00     0.00    0.00    0.00   0.06
sda                0.30     5.47     0.00   0.88   23.68    18.31    18.35   3855.13     10.93  37.33   55.51   210.06     0.00     0.00     0.00   0.00    0.00     0.00     0.00    0.00    1.03  11.73

Если я буду доступен в следующий раз, когда произойдёт сбой, я это попробую. Однако я не думаю, что проблема именно в Protect — это crash-reporter, который потребляет огромное количество ресурсов системы при сбое чего-либо. Crash-reporter — это не то, что я запускал через консоль. Java-поток crash-reporter выполняет очень много бесполезной работы (делает что-то в течение многих минут).
Страницы: 1 2 След.
Читают тему (гостей: 1)