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

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

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

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

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

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

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

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

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

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

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

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

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

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 и потрошить картинки. Но это вообще не вариант.

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

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

Я долго думал, как мне реализовать систему хранения видеоархива. Причем одним из критериев отбора выступала доступность решения по цене и эксплуатации. В итоге я остановился на довольно бюджетном видеорегистраторе 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 фото человека, который позвонил в звонок;отправлять мне короткие видеофрагменты записей с камер в коридоре и из квартиры,  если сработал датчик открытия двери в мое отсутствие.

Во-первых, для отправки фото в 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.

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

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 секунд.

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

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

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

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

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

Так вот, меня удивил перечень способов уведомления о движении. 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, что очень удобно.

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

rtsp://IP_адрес_регистратора:554/user=логин&password=пароль&channel=1&stream=0.sdp?real_stream