Каталог Поиск 0 Сравнить 0 Закладки 0 Корзина Войти
Каталог
105082, Москва, ул. Фридриха Энгельса, 75с21, БЦ Бауманский ИТКОЛ
Пн - Пт: с 09-00 до 18-00 Сб: с 10-00 до 18-00 Вс: выходной
Страницы: 1 2 След.
RSS
Unifi Protect API или оповещения о движении через API?, UniFi Protect
 
Радуюсь Unifi Protect и его будущему. Два быстрых вопроса:  
1) Есть ли API для Protect? Хотелось бы узнать, можно ли программно вытягивать изображения и видео из Protect.  
2) Есть ли возможность, чтобы движение запускало HTTP GET-запрос к другому веб-ресурсу? Моя сейчас ужасная обычная IP-камера так делает, и это помогает мне запускать другие части моей системы безопасности.
 
После того как другие просили это больше пяти лет назад, ты правда думаешь, что у Unifi это до сих пор в приоритете?!
 
Локальный MQTT API (или хотя бы HTTP) был бы отличным решением. Пожалуйста, сделайте эту функцию приоритетной!
 
Киваю. Тут, по сути, я тоже особо не спорю… если работает — значит работает. Конечно, всегда есть какие-то шероховатости. **И** я никак не могу положиться на систему, которая сознательно не хочет создавать надежное место для интеграции. Я говорю о чем-то вроде этого **ПОЛНОСТЬЮ ГИПОТЕТИЧЕСКОГО СЛУЧАЯ, КОТОРЫЙ АБСОЛЮТНО НЕ ПРОИСХОДИЛ** (серьёзно, это просто «соломенный муж» для наглядного примера. Я ни в коем случае не утверждаю, что UBNT так поступали):

«О, мы выпилили часть системы, через которую вы раньше ловили события. Сейчас через этот канал идут только старые данные событий… ничего нового. Мы ещё несколько месяцев назад перешли на новый конвейер событий и постепенно отключаем функции от старого. Вот почему за последние N месяцев вы видите сокращение количества триггеров событий».

Такие ситуации случаются по мере развития технологий… когда правая рука не знает, что делает левая, могут случаться неприятности. Официальная поддержка и обещание таковы: если что-то меняется, при безопасности — максимально заранее предупреждают, а если не критично с точки зрения безопасности — дают заблаговременное оповещение, чтобы интеграторы успели это учесть и внедрить разумные решения в дальнейшем. Без этого невозможно узнать, когда что-то, от чего ты зависишь, меняют без предупреждения… И такие изменения не всегда выглядят сразу резко и заметно — чтобы сразу бросалось в глаза и поднимало подозрения.

Вот о чём я и говорю, хотя, возможно, мог бы выразиться более грамотно… *пожимает плечами*
 
Чёрт побери! Я сейчас просматриваю твою документацию! Думаю, завтра утром обязательно с этим поиграю... Что-то подсказывает, что я полностью погружусь в это, буду экспериментировать и смотреть, что можно настроить и использовать для развертываний. Огромное тебе спасибо за это!!!!! Отличная работа!!
 
Я случайно наткнулся на это и, учитывая, что проект стартовал 6 лет назад, надеялся увидеть побольше активности в комментариях на страницах...  
**Скриншот элементов Home Assistant ниже для G4 Pro Doorbell и G5 Pro**  

Мне нравится, что Home Assistant отлично интегрируется с Protect, позволяя включать и выключать все функции и настройки камер/домофона/всех частей Protect. Плюс к тому, он может использовать объекты Protect в качестве сенсоров: движение, обнаружение человека, животного, машины, дым, огонь, плач ребенка, CO2 и всякое такое. У меня настроено много автоматизаций, например, если на G4 Pro Doorbell обнаруживается человек и входная дверь заперта, мои устройства Google Home говорят: «К кому-то кто-то приближается к двери!» — затем переключаются на видеопоток с домофона и на экранах телевизоров в углу появляется миниатюра с лицом человека и оповещение, и это происходит независимо от того, что я смотрю в данный момент.  

Я пытался разобраться, как именно это интегрируется в Protect. У меня отдельный локальный аккаунт с именем и паролем, изолированный только для Protect в моём UNVR, так что не уверен, происходит ли постоянный парсинг данных или есть какая-то кастомная интеграция с интерфейсом. Может, это что-то вроде Python-скрипта, который логинится, имитирует HTTPS-сессию и просто читает/кликает/вводит что-то виртуально.  

Но Я ОЧЕНЬ ХОЧУ ПОЛНОЦЕННЫЙ API НАБОР ДЛЯ PROTECT!!! Сейчас это базовый минимум для ВСЕГО софта, почти у каждого свои кодинг и автоматизации.  

Когда Unifi Video закрыли (RIP *слезы*), думалось, что новая платформа Protect, написанная с нуля, будет иметь хоть какую-то базовую API-интеграцию уже на старте. Даже если бы это был Swagger, REST, я бы и на SOAP согласился.  

Простой API-скрипт сильно помог бы при настройке новых офисов или замене/добавлении камер у клиентов. Было бы классно иметь скрипт, который подключается к API, чтобы быстро настраивать или менять конфигурацию — приехал, подключил, запустил скрипт и ушёл.  

Например, у меня мог бы быть подготовленный файл CSV/список с такими данными, как название камеры, MAC-адрес (можно просканировать с коробки каждой камеры перед установкой и с помощью камеры телефона автоматом вытащить MAC и подставить в таблицу — у меня есть кастомная настройка для этого), IP, параметры записи, настройки на экране, базовые функции камеры и т.п.  

После того, как все новые камеры установлены и заменили старые, я запускаю скрипт, который принимает камеры в систему и, чтобы изменить только нужные, проверяет MAC-адреса из CSV и применяет к ним заданные параметры. Если камера меняется, скрипт автоматически отключает старую.  

В больших системах очень неудобно вручную менять IP на Protect VLAN, перезагружать камеры, заходить в Protect после того, как NVR увидит новый IP, настраивать параметры записи и тестировать.  

Также круто было бы иметь скрипты и прямое использование API в таких системах, как SIEM, ITSM, SCCM, мониторинг здоровья сети/системы, безопасность для управления доступом и прочим.  

Я понял, что мне очень нравится строить автоматизации, которые выполняют все рутинные задачи последовательно, используя CSV или таблицы для организации данных. Там можно пользоваться формулами, например, CONCATENATE или автозаполнением, идеально при настройке IP-сетей, где нужно просто прибавлять цифру в конце, делать вычисления и макросы на VBA (да, старой школы), а потом сохранять в CSV, чтоб сохранялись только данные в ячейках. Оригинал таблицы храню для правок и повторного сохранения.  

Но лично для моего дома хотелось бы иметь полный API-набор, чтобы самому создавать кастомные функции и даже запускать уведомления, проверки состояния и прочее.  

 
 
 
Было бы здорово подробнее разобраться с этой функцией webhook. У меня дома все камеры Unifi Protect, но я всё ещё пользуюсь несколькими камерами Ring и видеозвонком Ring, потому что они позволяют интегрироваться с моими умными устройствами. Я использую Sharptools и webhook для автоматизации в умном доме. Если бы видеозвонок и камеры Unifi могли делать webrequest (webhook), я бы полностью отказался от Ring во всех семи местах и перешёл бы на Unifi Protect. 100%.
 
В контексте SMB/SOHO я считаю, что Protect подходит отлично, и пара секунд задержки между обнаружением и срабатыванием вебхука — это вполне нормально. Потеря 1 пакета из 5000 тоже, скорее всего, не критична. Я не пытаюсь ставить UDMPSE в корпоративные сети, я использую его в офисах, других небольших предприятиях или в дорогих домах, где дюжина нормальных камер и вебхук будут идеальны. Сейчас я на самом деле использую Synology Surveillance Station для обработки триггеров событий — это отдельный процесс, который захватывает RTSP-поток с NVR. Просто на объекте под рукой есть системы Synology, так что легко использовать их для разных задач.
 
@rebelwireless ТАК-ССЫЛАЕТСЯ... :) Настоящий «слон в комнате» — это обязательства. Как магазин, который заставляет дело работать там, где резина встречается с дорогой для клиентов, нужно оценить, можно ли доверять той интеграции, которую внедряешь. UI постоянно заявлял: «Это не то, чему мы готовы посвятить себя»... Это сообщение нужно менять. Я с тобой согласен, в итоге всё БУДЕТ просто... Это же не космическая наука. Но для этого потребуется повышение уровня зрелости. И это **ХОРОШАЯ ВЕЩЬ**. Это уровень зрелости, которого так не хватает защитной линейке. Ты бы доверил маршрутизатору, который тихо и случайно теряет один пакет из 5000... и при этом ответ производителя был бы: «Да нам кажется, что это не такая проблема, чтобы тратить время и силы на разбирательства и исправления»? Лично у меня от этого не появится уверенности... Защитная линия занимает критическую позицию в смешении ML/AI/реального мира. Защитная линия — это КАНАЛ для других компонентов, будь то физические или виртуальные, передающих сигнал о том, что в реальном мире произошло событие, которое нужно зафиксировать. Это не сообщение, которое может быть потеряно... Так что да, webhook действительно просто реализовать... как и API, если честно... Но обязательство обеспечить надёжный поток сигналов, на который можно положиться, гораздо важнее. Webhook/API — это уже детали реализации на базе обещания надёжности. Я понимаю, как жертвуются «быстро», «дёшево» и «качественно»... Это обещание не обязательно должно быть «в реальном времени»... Погрешность в 1-3 секунды — более чем разумно... 10 секунд — уже предел... Какое бы время задержки вы ни выбрали, камеры должны буферизовать на устройстве примерно в 2 раза дольше, чтобы компенсировать такую же задержку при обработке и передаче команды... Так что всё складывается... Но всё же это выполнимо, и, по моим предположениям, всё это можно реализовать даже на оборудовании начиная с г3... В любом случае, парадигма действительно должна измениться... И я искренне на это надеюсь, потому что жалко видеть такое классное оборудование, загнанное в угол из-за отсутствия ответственного подхода руководства. Оборудование может это сделать... Просто я не вижу в организации желания показать, что им не всё равно... UBNT — ПОЖАЛУЙСТА — ваши клиенты не являются нереалистичными... (по крайней мере, *я не считаю, что мы требуем слишком многого*) Поделитесь своим мнением... и помогите нам сделать вашу платформу по-настоящему успешной. Если вы думаете, что мы требуем слишком многого — объясните, почему вы так считаете...
 
@UI-Team Расширение Unifi Protect в более широкую экосистему действительно требует хотя бы вебхуков, и это была бы относительно простая задача (я читал о реверс-инжиниринге protect на github хjdhjd). Так что реализация вебхука по триггеру, похожему на то, как UCRM отправляет вебхуки при изменениях в сервисе, была бы очень хорошим началом. Потом — API.

Подумайте так: у вас есть прожектор, освещающий парковку, но вы хотите включать его только когда появляется человек или машина, а не из-за насекомых. Это, по сути, и есть идея AI-функций в камерах. Когда камера обнаруживает человека (или любое другое событие), она отправляет вебхук с типом обнаружения на нужный адрес, а дальше интегратору дело – что с этим делать. Это может означать, например, замыкание реле, чтобы включить прожектор на основе детекции камеры. Аналогично, можно срабатывать от датчика воды или открытия двери и, например, перекрывать воду через электроприводный клапан.

Ubiquiti не может решить все сценарии, и некоторые из них — редкостные, на которые не продашь достаточно много управляемых клапанов, чтобы сыграть на этом рынке. Поэтому, если мы используем protect, мы оказываемся лишены таких возможностей.

Не раз именно это заставляло меня выбирать другое решение.

Раньше я довольно критично относился к видеосистемам UI, но нынешняя система protect на самом деле очень хороша, и её главный недостаток — отсутствие опций интеграции с вещами «вне сферы unifi».
 
@UI-Team — вы создаёте видеоплатформу, с которой другие пытаются интегрироваться. Если нет официального, поддерживаемого API, на который downstream интеграции могли бы надежно опираться, они не смогут гарантировать, что всё будет работать стабильно. API — это обещание. Если вы хотите, чтобы организации вкладывались в ваше решение, крайне важно предоставить им надёжную основу для работы. Реверс-инжиниринг подходит для незначительных вещей. Неожиданные поломки раздражают, но не несут серьёзных последствий. В категории, к которой относится protect line, это просто недопустимо. Я настоятельно призываю вас пересмотреть это решение. Помогите вашему сообществу — оно поможет вам.
 
MQTT и полноценная поддержка HomeKit для UniFi Protect: homebridge-unifi-protect. Реверс-инжиниринговая библиотека API UniFi Protect: unifi-protect. Она обеспечивает полный телеметрический сбор событий и многое другое. Честно говоря: обе написаны мной.
 
Плюс один.
 
API существует, так что данные можно опрашивать (хотя для движения это особо не подходит), но можно также настроить WebSockets, чтобы код или приложение сразу узнавали, когда что-то происходит. Я использую и то, и другое для своего драйвера Hubitat. Однако упоминания выше касаются того, что этот API не «официальный» и не полностью документирован. По крайней мере, с сетевой частью есть понимание и официальная секция, где можно проверить её элементы. А вот с Protect всё обстоит иначе (пока что, возможно, в будущем это изменится). Так что Ubiquiti может поменять это в любой момент.
 
Это просто невероятно. Вложили кучу времени в новые камеры и навороченный интерфейс, а с основным — ни шагу вперёд. Такая простая и базовая функция. Просто URL, который срабатывает при движении. Ничего больше. Только что купил кучу Protect Stuff, теперь пытаюсь понять, как с его помощью включать свет в саду. Уже жалею о покупке. Честно, в шоке.
 
Сейчас я ищу подходящую систему камер для дома, сада и зданий здесь. Важно, чтобы её можно было подключить к системе сигнализации и контроллеру освещения. У меня есть несколько продуктов от unifi, которые работают отлично. Поэтому сначала я посмотрел на продукты unifi. Но очень жаль, что нет официального API для подключения к другим системам. В таком случае придётся использовать продукты другого бренда :(
 
Вау, серьезно, нет никакого официального способа подключиться к чему-то, кроме приложения? Ну почему так? Я хочу запускать свою систему оповещений при разных событиях и так далее. Сложно ли было бы реализовать простой WebHook как альтернативу push- и email-уведомлениям? Это решило бы примерно 80% необходимых функций и при этом было бы легко использовать и понять, как это работает. Если бы в этом WebHook была ссылка на изображение — это решило бы следующие 10%, а сам видеопоток — последние 10%. Пожалуйста... Меня еще немного расстраивает, что нет поддержки Apple HomeKit. Я понимаю, что можно понадеяться на Homebridge и прочие ухищрения, но если так, то зачем вообще покупать продукты Unifi? Можно было бы просто поставить какие-то пакеты для linux-маршрутизатора, но я выбрал профессиональный продукт, потому что не хочу больше возиться с этим. Так почему оно не работает из коробки с самой популярной системой домашней автоматизации? Я хочу, чтобы свет в доме включался, когда кто-то ходит вокруг дома. Также хотелось бы включать уведомления с помощью геозон и расписания (или по триггеру HomeKit, например, который я запускаю, когда ложусь спать...). Пожалуйста...
 
Я не говорю, что это плохое устройство... Я лишь отмечаю, что учитывая, в какой «зоне чувствительности» эти девайсы находятся в окружении, ни в коем случае нельзя просто **НАДЕЯТЬСЯ**, что UBNT будет вести себя стабильно. Нельзя гарантировать, что API не изменится без предупреждения, а значит, всё, что построено на нем, тоже не может на это рассчитывать. Отсутствие надежного API и полное нежелание UBNT сотрудничать с пользователями для создания устойчивого и предсказуемого решения будет и дальше тормозить распространение платформы... Есть и другие причины, но именно такое поведение ярко показывает разрыв между производителем и тем, что действительно нужно юзерам. ¯\_(ツ)_/¯
 
Согласен, было бы лучше, чтобы это было «официально». Похоже, я пропустил этот момент в обсуждении. Учитывая некоторые API, для которых у меня есть драйверы, мне кажется, что с Ubiquiti работать гораздо удобнее.
 
Наличие API в общем-то не особо важно, потому что UBNT четко дала понять, что будет изменять его по своему усмотрению, без предупреждений, без уведомлений об устаревании и без учета тех, кто пытается обратным способом его разобрать для своих целей… Вот именно поэтому этот топик и появился — чтобы попытаться убедить UBNT сделать (и соблюдать) обещание по API. Мне совсем не нравится идея разрабатывать интеграцию, от которой я завишу, а потом внезапно терять функционал или видеть резкие изменения в каком-нибудь исправлении багов. Без гарантии стабильности от UBNT мы пытаемся построить дворец на зыбучих песках… и это, честно говоря, небезопасно. Представьте, что motion API меняется (опять же) именно в ту ночь, когда в ваш дом врываются… это было бы просто кошмарно. Если, конечно, вы доживете, чтобы пожаловаться на такие изменения, то, скорее всего, ответ UBNT (судя по предыдущим реакциям) будет такой: это нестандартный приватный API, который не предназначен и не подходит для использования конечными пользователями… Я не пытаюсь быть занудой, просто хочу подчеркнуть невероятный риск, который мы берем на себя, полагаясь на то, что производитель неоднократно заявлял и демонстрировал — API может меняться резко и без предупреждений.
Страницы: 1 2 След.
Читают тему (гостей: 1)