Видеонаблюдение входной двери. Как сделать так, чтобы вы увидели то, что нужно?

05 октября 2019, 13:03

Эта статья будет не совсем про оборудование. И не совсем про настройку (хотя без нее не обойтись). Статья о личном опыте вандалозащищенной системы контроля входной двери у вашей квартиры.

Причем защита от вандалов будет заключаться в том, что вы в любом случае узнаете, кто вам что-либо подпортил.

Одновременно с этим нужно понимать, что это решение является довольно сложным и исходит из принципа "я слепила из того что было" (с).

Камера видеонаблюдения

Камера может быть любой, но должна соответствовать некоторым условиям (дальше вы поймете почему):

  • поддержка RTSP,
  • поддержка ONVIF,
  • желательно, чтобы камера была оснащена возможностью получения снапшотов (статических картинок с изображением).

Начнем по порядку.

RTSP (Real Time Streaming Protocol) - базовый протокол передачи видеоизображения, который используется в большинстве систем домашней автоматизации, включая Apple HomeKit.

ONVIF (Open Network Video Interface Forum) - это также протокол, который используется для того, чтобы различные вендоры, выпускающие разнообразные устройства, могли взаимодействовать между собой по неким стандартизированным правилам.

Наличие возможности получения снапшота с камеры исключает один из промежуточных этапов в моем решении и облегчает всю систему на порядок.

Есть камеры, которые соответствуют всем трем условиям, к тому же умеют выдавать видеопоток в "умирающем" уже протоколе MJPEG (Motion JPEG), который, по сути, представляет из себя последовательность картинок в формате JPEG, передаваемых с частотой 25 кадров в секунду. Самый удобный протокол для Home Assistant, например, но кроме как для отображения видеопотока в реальном времени, без перекодировки, его больше врядли получится как-то использовать.

А теперь разберемся с тем, какие камеры у меня есть и какие у них особенности.

1600x_image.png?1570060936

Какая-то модель SatVision

Digma DiVsion 100 - самая универсальная камера из всех. Она из коробки умеет выдавать MJPEG, RTSP, ONVIF и снапшоты. И все это она делает одновременно! С точки зрения удобства работы с ней - великолепна. С точки зрения надежности - сомнительно. Слот для MicroSD умер через неделю. Но так как он мне был без надобности, меня это не смутило. А в целом - больше года непрерывной работы, причем в довольно экстремальных условиях принудительного отключения питания в то время, когда я нахожусь дома. То есть, как минимум несколько раз в день ее отключают в довольно грубой форме от электричества. Digma DiVision 200 таких издевательств не выдержала и сдохла через три месяца использования. Так что тут как повезет, я полагаю.

Xiaomi Xiaofang - тот самый дешевый китайский кубик, который довольно легко перепрошивается и интегрируется в любую систему домашней автоматизации. Легенда практически. Умеет выдавать RTSP и снапшот. ONVIF, несмотря на запросы пользователей, пока недоступен. К тому же, у меня стоит настройка перезагрузки камеры через каждые три часа, иначе она может зависнуть. Причем команду отдает умный дом, сама она этого делать не умеет.

Satvision - китайская камера, которая популярна в определенных кругах специалистов в области монтажа систем видеонаблюдения. Модель не помню, но они, в основном, однотипные. Управляется исключительно через Internet Explorer. Никаким другим браузером вы на ее веб интерфейс не попадете. Умеет выдавать RTSP или MJPEG (или тот или другой, одновременно не получится). Работает через протоколы XM, HIK (нативный протокол HikVision) и ONVIF. Тоже только один из вариантов одновременно. Причем RTSP поток с камеры вы сможете выдернуть только в том случае, если она работает в режиме ONVIF, и это, естественно, нигде не описано. С точки зрения надежности - великолепна. Интегрируется куда угодно, работает с чем угодно, и опыт массовой установки этих камер показал, что они работают очень стабильно. Снапшот вы с нее не получите, от слова никак. Ну только если ставить ее в режим MJPEG и потрошить картинки. Но это вообще не вариант.

Первые две стоят в квартире. Купольная установлена в подъезде и смотрит на коридор и дверь в квартиру (на скрине в правом нижнем углу). Ради нее, в общем то, все и затевалось, остальные так, эксперимента ради.

1600x_image.png?1570060938

Система хранения видеозаписей

Я долго думал, как мне реализовать систему хранения видеоархива. Причем одним из критериев отбора выступала доступность решения по цене и эксплуатации. В итоге я остановился на довольно бюджетном видеорегистраторе Besder Mini NVR, который поддерживает подключение до 8 IP камер в формате FullHD.

Правда у него есть особенность - он не умеет принимать простые RTSP потоки с камер. Но к нему прекрасно подключаются камеры с помощью ONVIF протокола. Причем это особенность многих регистраторов, поэтому при выборе модели надо на это обращать пристальное внимание.

И, естественно, он умеет отдавать RTSP поток каждой подключенной камеры. Правда пришлось выпрашивать его у продавца, но они спокойно выдают требуемое по запросу. На всякий случай вот RTSP строка для конкретно этой модели:

# Первый канал
rtsp://IP_адрес_регистратора:554/user=логин&password=пароль&channel=1&stream=0.sdp?real_stream
# Второй канал
rtsp://IP_адрес_регистратора:554/user=логин&password=пароль&channel=2&stream=0.sdp?real_stream
# Далее по аналогии

Облачное видеонаблюдение

Есть же еще облако - скажете вы. И будете правы. Но зная "любовь" участников нашего сообщества к ежемесячным платежам за что-либо, я подумал о полностью автономном решении, которое можно реализовать при таких исходных данных.

К тому же, облачные решения тоже не так просты, как могло бы показаться. Во-первых, для того, чтобы информация сохранялась в облако, кроме того что вам нужно купить место в этом облаке, камера должна это облако поддерживать "из коробки". Только в этом случае, вам не придется настраивать доступ до ваших камер из внешнего интернета. А это умеют лишь определенные модели камер с определенными прошивками, перечень которых у каждого облака разный. И ценники иногда негуманные.

Многие китайские камеры уже идут с поддержкой облачных сервисов и управляются через приложение XMEye и подобные ему (Google Play, Apple Store). Но в основном это используется для удаленного управления и просмотра архива на регистраторе извне.

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

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

Умный дом

Он у меня работает на Hass.io, установленный в Docker. Как его устанавливать - можете прочитать в моей же статье.

В него интегрирована умная кнопка дверного звонка, о которой я уже писал, через Xiaomi Gateway, с включенным режимом разработчика. Это позволяет использовать штатную функцию дверного звонка на шлюзе Xiaomi, и одновременно использовать данные с датчика в автоматизациях Home Assistant.

Также в умный дом интегрированы все три камеры. Причем Digma 100 - в режиме MJPEG, а две остальные - с использованием компонента Stream. Этот компонент позволяет не перекодировать RTSP видеопоток на сервере умного дома и транслировать его в режиме HLS, который перекладывает задачу перекодирования на ваш браузер или клиента. Что позволяет, в свою очередь, не заниматься "танцами с бубном" при установке FFMpeg с аппаратным ускорением на сервер, а это значит, что камеры спокойно будут работать даже на Raspberry Pi 3 B+.

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

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

Соответственно, перед умным домом стоит задача:

  • отправлять мне в Telegram фото человека, который позвонил в звонок;
  • отправлять мне короткие видеофрагменты записей с камер в коридоре и из квартиры,  если сработал датчик открытия двери в мое отсутствие.
И, в принципе, это все реализуемо штатными средствами Home Assistant, если бы не парочка НО.

Во-первых, для отправки фото в Telegram при нажатии кнопки дверного звонка нужен снапшот. И именно камера, установленная в коридоре, его выдавать не умеет.

Но знатоки Home Assistant могут сказать, что есть команда camera.snapshot, почему не воспользоваться ей? Не получается. Скорее всего потому, что все камеры, которые используются с компонентом Stream, прописываются как Generic, данная команда, вероятно, использует параметр still_image_url, который как раз и является снапшотом, который не умеет делать эта камера. Замкнутый круг.

Это не точно, но при попытке использовать эту команду, я всегда получал файл размером 17 байт, в котором было пусто. Такие дела...

Во-вторых, опыты эксплуатации отправки коротких видео при открытии двери показали, что ввиду задержек при выполнении команды camera.record в Home Assistant, и не смотря на настройку записывать в файл предыдущие 10 секунд видео до сработки триггера, я все равно получал видеофрагмент, показывающий закрывающуюся дверь. То есть никаких людей я не видел. Только "убегающий хвост" гипотетического злоумышленника. Он, конечно, попал бы на камеру из квартиры, которая смотрит на входную дверь, но ее роль выполняет Xiaomi Xiaofang, и если бы она перезагружалась в момент открытия двери - мы бы вообще ничего не получили. Можно поставить Digma мониторить дверь - скажете вы, и опять будете правы. Но вдруг она сдохнет?

Запись более коротких фрагментов тоже ничего не дала. На старт записи это никак не влияло.

Поэтому мы получаем ситуацию, при которой самая стабильная камера из всех не выдает то, что нужно вообще. А ведь для ее установки потребовалось сверлить огромную дыру в стене. И что? Напрасно?

Решение

И в этот момент я вспомнил про свои эксперименты интеграции камер в Home Assistant в те времена, когда не было компонента Stream и использовался FFmpeg. В штатном режиме они знатно тормозили и этим невозможно было нормально пользоваться.

Тогда я решил эту проблему с помощью MotionEye, установленного на Rock64, у которого прекрасно работало аппаратное ускорение декодирования FFmpeg и система выдавала вполне приемлемый MJPEG поток, который прекрасно интегрировался в Home Assistant. Но одновременно с этим, MotionEye мог выдавать и снапшоты, причем для этого ему и декодирование не требовалось. Поэтому, по моим предположениям, можно было его использовать только для получения снапшотов без дополнительной нагрузки на сервер.

Причем MotionEye есть в виде аддона для Hass.io. Его я и установил. И столкнулся с другой проблемой.

Дело в том, что мой HA установлен с использованием SSL через Let's Encrypt. А аддоны в текущей версии Home Assistant работают в режиме Ingress интеграции. С точки зрения удобства использования - это великолепно, но в итоге мы получаем ссылку на снапшот из аддона в виде:

https://адрес_нашего_сервера.duckdns.org:8123/api/и_очень_много_символов

И ввиду особенностей межсетевого взаимодействия между контейнерами Hass.io, подобного рода ссылка с внешним адресом (даже если она резолвится как локальный адрес) не воспринимается Home Assistant, как рабочая. То есть он не может получить картинку по этой ссылке. Вообще. Соответственно, в Telegram мы ничего не получаем.

Окей - сказал я. У нас же Hass.io установлен в докер. Давайте поставим MotionEye как отдельный контейнер с помощью Docker-Compose. Сказано - сделано.

Добавляем в docker-compose.yml следующую настройку:

motioneye:
  container_name: motioneye
  image: ccrisan/motioneye:master-amd64
  restart: always
  volumes:
    - ./motioneye:/motioneye
  ports:
    - 8765:8765

Если у вас малина, то image будет выглядеть как:

ccrisan/motioneye:master-armhf

А если у вас нет docker-compose, то можно воспользоваться методом установки в Docker, описанном в штатной инструкции MotionEye.

В общем и целом, в итоге мы получаем таки работающий MotionEye и работающую ссылку на снапшот, которую видит Home Assistant и может отправлять в Telegram.

1600x_image.png?1570088292

Ссылку на URL снапшота можно взять в разделе Video Streaming. Причем сам раздел должен быть неактивен. Нам же не нужно, чтобы MotionEye перекодировал видео и "жрал" ресурсы сервера.

В итоге моя конфигурация выглядит следующим образом:

automations.yaml

#######################################
# Дверной звонок
#######################################
- id: Doorbell_Telegram_Door
  alias: Doorbell_Telegram_Door
  initial_state: True
  trigger:
    platform: state
    entity_id: binary_sensor.датчик_открытия_работающий_как_дверной_звонок
    to: 'on'
  action:
    - service: script.turn_on
      entity_id:
        - script.camera_tg_doorbell
    - delay: 00:05
# delay нужен для защиты от людей, 
# которые любят много раз подряд нажимать кнопку

#######################################
# Отправка видео при открытии входной двери
#######################################

- id: Camera_Video_Telegram_Door
  alias: Camera_Video_Telegram_Door
  initial_state: True
  trigger:
    platform: state
    entity_id: binary_sensor.датчик_открытия_на_входной_двери
    to: 'on'
  action:
    - service: script.turn_on
      entity_id:
        - script.camera_tg_koridor
        - script.camera_tg_hall
        
# В автоматизации нет проверки на то дома я или нет
# Это сделано для тестов, но вы можете добавить и 
# эту проверку

scripts.yaml

camera_tg_doorbell:
  sequence:
    - service: telegram_bot.send_photo
      data:
        target: !secret telegram_bot_chat_id
        url: !secret camera_koridor_pic
        caption: "Звонят в дверь !!!"

# camera_koridor_pic - ссылка Snapshot URL из MotionEye

camera_tg_koridor:
  sequence:
    - service: notify.telegram
      data:
        message: "Начало записи в Коридоре"
    - service: camera.record
      data_template:
        entity_id: camera.koridor
        filename: "/config/www/video_captures/snapshot_koridor.mp4"
        lookback: 10
        duration: 20
    - delay: 00:00:40
    - service: telegram_bot.send_video
      data_template:
        target:
         - !secret telegram_bot_chat_id
        file: "/config/www/video_captures/snapshot_koridor.mp4"
        caption: "Коридор"
    - service: notify.telegram
      data:
        message: "Видео из коридора отправлено"

camera_tg_hall:
  sequence:
    - service: notify.telegram
      data:
        message: "Начало записи видео из зала"
    - service: camera.record
      data_template:
        entity_id: camera.hall
        filename: "/config/www/video_captures/snapshot_hall.mp4"
        lookback: 5
        duration: 15
    - delay: 00:00:30
    - service: telegram_bot.send_video
      data_template:
        target:
         - !secret telegram_bot_chat_id
        file: "/config/www/video_captures/snapshot_hall.mp4"
        caption: "Комната"
    - service: notify.telegram
      data:
        message: "Видео из зала отправлено"

# camera.koridor - ссылка на RTSP поток канала регистратора
# на который подключена камера в подъезде
# camera.hall - ссылка на RTSP поток камеры Xiaofang которая
# смотрит на входную дверь в квартире

Использование скриптов, вместо прямых последовательностей напрямую в автоматизации, связаны с необходимостью одновременной записи видео с двух камер. Ведь человек заходит в одну и ту же дверь и нам надо получить два параллельных видео с двух камер. А автоматизации выполняются последовательно и поэтому, если бы мы все указали в автоматизации, то сначала бы записался файл с коридорной камеры, потом отправился, а потом начал бы записываться файл с камеры в квартире. Это больше минуты разницы между событиями.

Задержки, указанные в скриптах при записи видео, необходимы для того, чтобы системе хватило времени сохранить файл перед отправкой его через Telegram. Причём их длительность может быть вычислена исключительно опытным путем.

Причем тем же опытным путем было выявлено, что если MotionEye работает в штатной настройке, то мы получаем, при нажатии кнопки звонка, картинку из прошлого. В среднем, отставание было в районе 8 секунд.

1600x_image.png?1570066366

Для того, чтобы это отставание исключить, нужно просто в настройках камеры MotionEye снизить частоту кадров (Frame Rate) в разделе Video Device, до минимального значения 2. Тогда мы получаем моментальную картинку при сработке триггера нажатия кнопки звонка.

Но проблема с тем, что мы, при открытии двери, получаем видео с закрывающейся дверью и не видим, кто к ней подошел, осталась не решенной. Поэтому сработку по датчику открытия двери можно оставить только для камеры, установленной в квартире, а для камеры,  установленой в подъезде, этот вариант не подходит.

У меня даже возникала мысль установить в подъезд датчик движения, который будет запускать запись видео. Но этот вариант я исключил, потому что соседи напротив очень часто ходят туда-сюда, и количество срабатываний, не относящихся к делу, было бы запредельное.

В Home Assistant ведь есть собственный алгоритм определения движения на изображении с камеры - скажете вы. А он работает только в режиме FFmpeg и не может использоваться в режиме Stream.

Поэтому я решил изучить раздел MotionEye, относящийся к определению движения в кадре. У него есть даже определение зоны, в которой необходимо мониторить движение. Правда в отличие от большинства встречавшихся мне вариантов настройки маски, у MotionEye необходимо отмечать зоны, в которых не надо определять движение. Мышкой маркируются красным именно те участки, где не требуется определение движения.

1600x_image.png?1570066368

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

1600x_image.png?1570066367

Во-первых, надо еще поиграться с настройками Motion Gap и Minimum Motion Frames.

Motion Gap - это промежуток в секундах, который система ждет после прекращения предыдущей сработки на движение, и перед началом новой. Требуется для того, чтобы снизить частоту срабатываний при интенсивном движении. Так как у меня там не бегают по коридорам толпы людей, устанавливается параметр в 5 секунд.

Minimum Motion Frames - параметр, указывающий количество кадров, изменений в которых достаточно для того, чтобы понять, что происходит движение. Так как нам нужна скорость реакции, то цифра тоже маленькая и равняется 5 кадрам. Учитывая, что у нас скорость видео равняется 2 кадрам в секунду, то сработка случится через полторы секунды от начала движения.

Так вот, меня удивил перечень способов уведомления о движении. E-Mail, Webhook и shell команды на выбор, при начале движения или после его окончания. Но, как оказалось, вариант с Webhook вполне работоспособный.

Достаточно отправить запрос в виде:

https://адрес_вашего_Home_Assistant.duckdns.org:8123/api/webhook/абракадабра

с методом POST.

В automations.yaml необходимо прописать:

- id: Camera_Video_Telegram_Motion_Door
  alias: Camera_Video_Telegram_Motion_Koridor
  initial_state: True
  trigger:
    platform: webhook
    webhook_id: абракадабра
  action:
    - service: script.turn_on
      entity_id:
        - script.camera_tg_koridor

Где в обоих настройках надо указать любую одинаковую последовательность из английских букв и цифр, длиной не менее 8 символов.

Все это позволяет нам с помощью програмного датчика движения MotionEye обнаруживать движение и начинать запись микрофрагмента для отправки в телеграм, когда кто-то только подошел к нашей двери.

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

И даже если они вырубят мне все электричество в квартире, я все равно увижу, кто это был. Потому что на вскрытие щитка тоже потребуется время, за которое система успеет отправить мне видео.

Выводы

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

Но, в свою очередь, описание этой боли и те "грабли", на которые я наступил, должны помочь вам более осознанно подходить к выбору тех же камер или регистратора, для создания своей системы безопасности, которая будет иметь намного меньше возможных точек отказа и будет работать намного стабильнее.

Опять же, эта статья описывает неповоротливость и несовершенство Open Source систем автоматизации.

Любителям кричать направо и налево что Node-Red крутой, и на нем это делается на раз два - добро пожаловать в клуб авторов :))) 

У вас есть все шансы убедить всех читателей, путем написания собственной статьи по данному кейсу и реализации его в Node-Red или в какой-то другой системе.

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

Но мой вариант тоже имеет право на существование. По крайней мере, в качестве тестового. Да и для тех, у кого нет iPhone или iPad, он ближе. К тому же, я могу как картинку, так и изображение с камер, проигрывать через Chromecast на любом Android устройстве, которое это поддерживает. Например, в некоторых случаях у меня выводится изображение с камер на мой Android TV, что очень удобно.

В любом случае, толька вам решать, как лучше создавать удобную именно вам систему собственной безопасности. Моя задача - лишь помочь в этом.


Все новости мира умных домов - t.me/SprutAI_News

Остались вопросы? Мы в Telegram - t.me/soprut

Хочешь умный дом но нет времени разбираться?
Посмотри примеры работ и выбери себе интегратора.
  1. (Brain)
    (Brain) 9 дней назад

    У меня старые камеры от Dlink (dcs-5220) и я подозреваю, что они видели Ленина на броневике и защищали Ф. Дзержинского.
    Так вот они спокойно подсели на платформу ffmpeg и по rtsp транспорту отправляют мне снапшоты через pushover филигранно и безукоризненно.
    Я прям очень сильно удивляюсь, что это все работает, но это факт )

    • Виталий Никольский (bigmanekb)

      Нука нука поподробнне :) конфиг, систему, настройки в студию :))))

      • (Brain)
        (Brain) отредактировано 9 дней назад

        Да запросто )

        camera.yaml

        - platform: ffmpeg
          name: camera_vhod
          input: -rtsp_transport tcp -i rtsp://192.168.1.10/live.sdp
          
        - platform: ffmpeg
          name: camera_lev
          input: -rtsp_transport tcp -i rtsp://192.168.1.11/live.sdp
          
        - platform: ffmpeg
          name: camera_prav
          input: -rtsp_transport tcp -i rtsp://192.168.1.12/live.sdp
          
        - platform: ffmpeg
          name: camera_sad
          input: -rtsp_transport tcp -i rtsp://192.168.1.13/live.sdp

        автоматизация звонка

        - alias: Zvonok
          initial_state: true
          trigger:
            - platform: state
              entity_id:
                - binary_sensor.door_window_sensor_158d0001a99a5b
              to: 'off'
          condition:
            - condition: state
              entity_id: input_boolean.zvonok
              state: 'on'    
          action:
            - service: xiaomi_aqara.play_ringtone
              data:
                gw_mac: 7811DCB8CB42
                ringtone_id: 10
                ringtone_vol: 10
            - service: xiaomi_aqara.play_ringtone
              data:
                gw_mac: 7C49EB88B0B1
                ringtone_id: 10
                ringtone_vol: 10
            - service: xiaomi_aqara.play_ringtone
              data:
                gw_mac: 7811DCDEBC9C
                ringtone_id: 10
                ringtone_vol: 10
            - service: xiaomi_aqara.play_ringtone
              data:
                gw_mac: 7811DCB8D6F5
                ringtone_id: 10
                ringtone_vol: 3
            - service: xiaomi_aqara.play_ringtone
              data:
                gw_mac: 7811DCB8FB72
                ringtone_id: 10
                ringtone_vol: 10
            - service: input_boolean.turn_off
              entity_id: input_boolean.zvonok
            - delay: 00:00:10
            - service: input_boolean.turn_on
              entity_id: input_boolean.zvonok
            - service: camera.snapshot
              data:
                entity_id: camera.camera_vhod
                filename: "/config/tmp/camera_zvonok.jpg"
        #    - delay: 00:00:03
            - service: notify.pushover
              data:
                title: "Внимание!"
                message: "Вам звонят в дверь"
                data:
                  attachment: "/config/tmp/camera_zvonok.jpg" 
        • (Brain)
          (Brain) отредактировано 9 дней назад
          Комментарий был удален
        • Виталий Никольский (bigmanekb)

          поигрался я с pushover в общем. Классная тема, правда на заблокированном экране так и не смог получить от нее фотку. Приходится разблокировать и идти в уведомление. А хотелось бы сразу фотку на залоченном телефоне видеть. 

          Телега так тоже не умеет, поэтому я и в поиске пока.

          А само решение у тебя вполне. Правда для НА уже без надобности ffmpeg пользовать, хотя без него snapshot работать не будет, но можно сделать как у меня :) зато в интерфейсе НА будет нормальное плавное полноформатное отображение видеопотоков.

          • (Brain)
            (Brain) 9 дней назад

            ffmpeg использую исключительно для снапшота.
            А в HA мне видео не нужно. Просто стоит отдельный мак-мини, который работает с камерами и архивирует потоки.

  2. (maikl)
    (maikl) 7 дней назад

    Это ужасно.. ужасно что такая продвинутая и соверменная система как ХА не имеет готового решения такой простой в общем то задачи.
    Да что там говорить. Даже локальную озвучку на блютус колонку никакими штатными средствами не сделать.
    Вроде с ХомКит задача видео проще да? 
    Но что делать всем тем кто не хочет в рабство к Эпл? Или не может)
     

К списку статей

Скидки для сообщества

MI-DOM

+7 977 282-80-53
Промокод:
SPRUTAI
Размер скидки:
5%

Интернет-магазин yourhomekit.ru

+7 914 550-51-11
Промокод:
SPRUT-BLG
Размер скидки:
8%
Cамый большой ассортимент в России аксессуаров Apple HomeKit

Похожие статьи

04 сентября 2018, 12:14
Интеграция RGB ленты на ESP8266 с прошивкой tasmota в систему HomeBridge (HomeKit)
09 ноября 2018, 20:54
Кейс создания умного дома без каких либо прокладок в виде Raspberry pi
15 октября 2018, 09:05
Прошивка для Sonoff c нативным HomeKit
15 ноября 2018, 09:42
Способы автоматизации механических ворот
27 октября 2018, 12:20
Нативный Термостат для котла на ESP8266 с поддержкой Apple HomeKit
15 ноября 2018, 13:11
Xiaomi Mi Remote 360 добавляем Apple HomeKit
01 октября 2018, 07:43
Нативный HomeKit на ESP8266
15 июня 2018, 12:13
Охранная система в гараж на ESP8266 с интеграцией в Apple HomeKit
24 августа 2018, 12:18
Пошаговая установка HomeAssistant
27 августа 2018, 10:14
Интегрируем ХА в HomeKit