Умный дом

Всем привет. Хочу поделиться своим опытом, как я подружил вызывную панель Hikvision со штатным видеодомофоном, Asterisk и обычной DECT-трубкой через Keenetic.

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

В итоге всё заработало именно так, как хотелось. Но по пути пришлось разбираться с Private SIP Hikvision, нестандартной регистрацией indoor extension, анализировать PCAP и отдельно ловить проблему с RTP-портами.

Что у меня за оборудование

Домофония:

вызывная панель Hikvision DS-KV6113-PE1(C) — 192.168.1.76;

штатный видеодомофон HiWatch VDP-H3212W — 192.168.1.192.

Телефония:

роутер Keenetic / Netcraze Ultra NC-1812;

DECT-модуль и обычные беспроводные трубки;

основная трубка первого дома — внутренний номер 101.

Сервер:

мини-ПК CHUWI HeroBox на Intel N100;

8 ГБ RAM;

Proxmox VE;

Asterisk запущен отдельно в LXC 100;

версия Asterisk 22.10.1;

IP Asterisk — 192.168.1.95.

Сам сервер у меня используется не только для телефонии. На нём отдельно живут Home Assistant и Frigate, поэтому я изначально не хотел ставить Asterisk прямо на Proxmox-хост.

Логика простая: каждый сервис в своём контейнере или VM. Если я что-то сломаю, экспериментируя с телефонией, Home Assistant, видеонаблюдение и сам Proxmox продолжают работать.

Почему я не стал переводить панель в обычный SIP

Самый очевидный вариант — включить на панели Standard SIP и зарегистрировать её напрямую в Asterisk.

Но мне хотелось не заменить штатную систему Hikvision, а дополнить её.

То есть сохранить:

штатный вызов на VDP-H3212W;

видео с панели;

видео ещё до ответа;

родное открытие замка;

всю внутреннюю логику Hikvision.

И параллельно добавить обычную DECT-трубку.

Поэтому Standard SIP на панели я оставил выключенным.

Именно это решение потом и привело к более интересному варианту — подключить Asterisk не как SIP-сервер для панели, а как дополнительную indoor extension Hikvision.

Почему пришлось лезть в PCAP

На этом этапе стало понятно, что обычным SIP здесь всё не ограничивается.

Панель продолжала прекрасно звонить на штатный VDP-H3212W, но Asterisk этот вызов не видел. Через Home Assistant можно было поймать событие нажатия кнопки и отдельно заставить Asterisk позвонить на 101, но это был просто дополнительный звонок — без нативного аудио с панели.

Такой вариант меня не устраивал.

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

И тут выяснилось, что у Hikvision внутри своя довольно интересная схема.

Реальные внутренние SIP-номера у меня оказались такие:

Вызывная панель: 10010100000

VDP-H3212W: 10010110001

А сама панель использует не только обычный SIP-порт 5060, но ещё и собственный private SIP proxy на 5065.

Штатный вызов выглядел примерно так:

DS-KV6113

192.168.1.76:5060

|

v

Hikvision Private SIP

192.168.1.76:5065

|

v

VDP-H3212W

192.168.1.192:5060

То есть внутри это действительно SIP, но со своей логикой, XML-сообщениями, Digest-аутентификацией и довольно нетипичным поведением.

Именно по PCAP стало понятно, что правильнее не пытаться насильно превращать саму панель в обычный SIP-телефон, а встроиться в родную архитектуру Hikvision.

Следующая находка оказалась ключевой: Asterisk можно зарегистрировать как indoor extension у штатного видеодомофона.

Как Asterisk стал indoor extension Hikvision

У VDP-H3212W есть возможность зарегистрировать дополнительное внутреннее устройство.

В моём случае Asterisk зарегистрирован как:

10000000005

То есть итоговая логика получилась такая:

DS-KV6113

|

v

VDP-H3212W

|

+--> indoor extension 10000000005

|

v

Asterisk

|

v

Keenetic / DECT 101

Для регистрации пришлось использовать отдельный Python-скрипт, потому что обычного SIP REGISTER оказалось недостаточно: Hikvision ждёт дополнительный XML-блок с данными устройства.

Пример XML:

<regXML>

<version>V2.0.0</version>

<regDevName>Asterisk</regDevName>

<regDevSerial>Q12345678</regDevSerial>

<regDevMacAddr>00:0c:29:12:12:12</regDevMacAddr>

</regXML>

После Digest-аутентификации регистрация проходит нормально:

REGISTER

401 Unauthorized

REGISTER + Authorization

200 OK

После этого VDP начинает отправлять вызов на Asterisk.

На Asterisk входящий вызов попадает в отдельный context и дальше уходит на DECT 101.

Пример dialplan:

[hikvision-indoor-in]

exten => 10000000005,1,NoOp(Hikvision indoor call)

same => n,Progress()

same => n,Set(CALLERID(num)=105)

same => n,Set(CALLERID(name)=Gate)

same => n,Dial(PJSIP/101,40)

same => n,Hangup()

На этом этапе трубка уже начала звонить.

Но дальше началась самая неприятная часть — звук.

Почему сначала был односторонний звук

Hikvision в моём случае упорно использовал для аудио порт:

UDP 9654

В SDP панели было:

m=audio 9654 RTP/AVP 0 8 101

То есть PCMU, PCMA и DTMF.

Проблема в том, что Asterisk по умолчанию выбирает для RTP случайный порт из своего диапазона.

Например:

10516

14112

17510

Но Hikvision при этом всё равно отправлял аудио на:

192.168.1.95:9654

Получалось так:

101 -> Asterisk -> панель

работает,

а:

панель -> Asterisk -> 101

не работает.

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

Первый фикс

На endpoint Hikvision я зафиксировал RTP-диапазон:

rtp_port_start=9654

rtp_port_end=9656

После этого Asterisk начал реально слушать порт 9654, и звук с панели появился.

Но тут проявилась вторая проблема.

У меня было включено:

rtp_symmetric=yes

Asterisk увидел входящий RTP и решил отправлять ответный звук на адрес источника медиапакетов.

В итоге голос с трубки уходил не на саму панель 192.168.1.76, а на VDP 192.168.1.192.

Хотя в SDP было явно указано:

c=IN IP4 192.168.1.76

m=audio 9654

Финальный фикс

Рабочая комбинация получилась такой:

rtp_port_start=9654

rtp_port_end=9656

rtp_symmetric=no

direct_media=no

После этого Asterisk:

принимает аудио панели на 9654;

не переучивает адрес назначения;

отправляет обратный RTP туда, куда указано в SDP, то есть на саму панель 192.168.1.76:9654.

И наконец получился нормальный двусторонний разговор.

Что получилось в итоге

Сейчас схема работает полностью так, как я изначально хотел.

При нажатии кнопки на калитке:

штатный VDP-H3212W продолжает звонить как раньше;

одновременно звонит обычная DECT-трубка 101;

вызов можно принять на трубке;

звук работает в обе стороны;

разговор держится стабильно;

клавишей # на DECT-трубке открывается замок калитки.

То есть обычная беспроводная трубка фактически стала полноценной аудиотрубкой домофона, при этом штатная Hikvision-система не была сломана и продолжает работать в своём родном режиме.

Почему Home Assistant я не использовал для самого разговора

Home Assistant у меня тоже установлен и Hikvision с ним интегрирован.

Он отлично подходит для автоматизаций: можно ловить нажатие кнопки, отправлять уведомления, включать свет, показывать камеру, делать объявление через Алису и так далее.

Но для самого разговора HA здесь не нужен.

Через HA я мог сделать только такую логику:

Нажали кнопку

|

v

Home Assistant

|

v

Asterisk

|

v

DECT 101

Трубка бы звонила, но родной аудиопоток Hikvision туда не попадал бы.

Поэтому сам разговор реализован на уровне SIP/RTP, а Home Assistant оставлен для будущей автоматизации.

Почему вообще выбрал Asterisk

У меня два дома на одном участке, находятся примерно в 15 метрах друг от друга.

Поэтому дальше хочется сделать уже нормальную домашнюю телефонию:

Дом 1

|

+--> DECT 101

Дом 2

|

+--> свой внутренний номер

Калитка

|

+--> нужные трубки

+--> видеодомофон

+--> уведомления

Плюс хочется связать всё это с Home Assistant, Frigate, камерой у калитки, Алисой и телевизором.

И вот здесь Asterisk оказался гораздо интереснее любой закрытой аппаратной мини-АТС: всю логику можно менять программно.

Что бы я посоветовал тем, кто захочет повторить

Самый полезный вывод из всей этой истории — не пытаться угадывать, как Hikvision работает внутри.

Сначала лучше снять PCAP штатного рабочего вызова и посмотреть:

INVITE

SDP

RTP

MESSAGE

Digest

реальные номера устройств

реальные IP и порты

У меня именно анализ пакетов показал, куда Hikvision на самом деле отправляет звук и почему стандартные настройки Asterisk не работали.

Особенно важными оказались:

rtp_port_start=9654

rtp_port_end=9656

rtp_symmetric=no

direct_media=no

Без первого фикса Asterisk слушал не тот RTP-порт.

Без второго — отправлял голос не на панель, а на VDP.

Что дальше

Следующий этап — подключить второй дом и уже нормально развести внутреннюю нумерацию.

После этого хочу добавить:

звонок с калитки

|

+--> VDP

+--> DECT

+--> Home Assistant

+--> уведомление на телефон

+--> Алиса

+--> камера на ТВ

Пока главное уже сделано — родной Hikvision работает, DECT работает, двусторонний звук есть, замок открывается с трубки.

Если кому-то будет интересно, могу отдельным постом выложить уже полностью готовые конфиги Asterisk, регистрацию indoor extension и примеры SIP/RTP-логов.

Может, кому-то с таким же Hikvision это сэкономит пару вечеров с Wireshark :)

Продолжаем делать дом удобнее.

Мониторинг подключения воды. Наш, Ватериус. Работает. Только вот инструкция подключения... Слейте бачок унитаза. Почему именно унитаза? Зачем? Сливать полностью? Ну можно было написать - пролейте 5 литров? Только сильно потом я нашел зачем. Если за 10мин самонастройки ватериус поймал один импульс - счетчик определяется как 10л/имп. Если больше - 1л/имп. В остальном все очень удобно, на дашборде видно сколько там сейчас. Прощай галерея фото счетчиков в телефоне.

Динреечное реле.

Встает под двухрядную гребенку почти ровно.

Это не первое подобное у меня, но только сейчас я понял, зачем тут 2 "одинаковые" настройки - ограничение тока и ограничение мощности. Релюха заменила обычный автомат 25А. Ограничение тока работает точно как работал автомат - защита проводов от КЗ. А вот ограничение мощности я перенастроил.
Это реле ХА использует как монитор включения плиты. Если кошки залезут куда не надо. Такое уже было. При появлении тока выше 1А автоматика выдает предупреждение и ждет нажатие кнопки. Если не нажать - через 30сек плита выключается принудительно. В планах добавить датчик присутствия, но это сейчас не важно.

Важно то, что телеметрия медленная. Оно срабатывало, но иногда через 10 секунд, иногда через минуту. Сами мозги релюхи не инициируют связь с ХА при изменении значений. Мониторил с роутера. А вот включение аларма на 200Вт принудительно выпихивает телеметрию на сервер. Скорость реакции стабилизировалась на минимуме.

Со вторым реле проще, там телеметрия собирает значения за 5 минут и если среднее превышает 1КВт - будет сообщение. Вскипятить чайник система не ругается, кондей на 1,5КВт - сообщение будет через 10мин. Хелпер filter - lowpass.

Привет, мир!
Это инженерный блог компании «ВсяАвтоматика». По какой-то тактике, которая у нас есть и которой мы будем придерживаться, мы (в больше степени лично я), решили рассказать наконец-то всему миру в общем и вам в частности чем мы вообще занимаемся каждый будний день с 9:00 до 18:00 вот уже 8 лет. Или около того…
А занимаемся мы (только не удивляйтесь сильно) автоматикой. В основном автоматизацией систем отопления в частных загородных домах. Реже, к сожалению, автоматизацией и диспетчеризацией коммерческих и промышленных объектов.
Основной «продукт» - шкаф автоматики. Например, вот такой:

Или вот такой:

Разные в общем. Как по внешнему виду, так и по задачам, которые они решают.
К сути.

Шкаф автоматики – это не наше изобретение. Как сущности, им наверное уже лет 126. Но к нашим шкафам автоматики мы, не читая инструкций и мануалов, пришли своим опытом и своими руками и мозгами, путем проб и ошибок. Не смотря на то, что у многих в нашей команде есть высшее образование, у некоторых даже техническое и не одно, многие решения, утвержденные ГОСТами, ТРТСами и ПУЭ, стали нами реализовываться далеко не сразу.

С какого… или иначе говоря, почему вообще мы начали делать шкафы автоматики?

В далеком уже 2017-18 году наш спецотряд по автоматизации занимался установкой систем, как говорят, «умного» дома. В 99,9…% случаев тогда мы использовали ectoControl. Выглядело это чудо устройство в тогдашней ревизии вот так:

Этот «модем», представляющий из себя центральный хаб всей системы, имел на своем борту три встроенных реле с возможностью подключения дополнительных блоков по 10 реле и различных датчиков, типа температуры, протечки, газа и т.д.
В целом встроенных трех реле вполне хватало для управления примитивными котельными в «бабушкатниках». Монтировать устройство можно было (да и сейчас можно) прямо на стену, не заморачиваясь с щитком или боксом.
Если трех встроенных реле было недостаточно, устанавливался блок расширения на дополнительных 10 реле. Тогда вот такой:

Собственно, отсутствующие тогда вкус к технической эстетике и насмотренность, давали право также монтировать это устройство прямо на стену. Но где же тогда порылась собака и откуда появилась шальная идея собирать какие-то «шкафы» автоматики?
А весь вопрос был в программных ограничениях самого контроллера. Его программы управления были, как это называется в терминологии самого ectoControl, одноконтурными. Т.е. каждое реле, управляемое своей программой, никак не было, не могло быть и более того на тот момент (как считалось) не хотело быть связано с другими реле и программами. Нам это не нравилось, так как приводило к серьезным ограничениям и допущениям. А так же ограничивало нашу зону работы – фактически, мы могли работать только в «бабушатниках» с простыми системами отопления. Пусть на более интересные объекты с хотя бы тремя контурами отопления был нам заказан.  
Допустим, в котельной частного дома было четыре объекта управления: котел, насос контура отопления 1 этажа, насос контура отопления 2 этажа и насос загрузки бойлера косвенного нагрева (далее БКН). Учитывая интровертность программ управления, все эти четыре объекта управлялись и работали по своим датчикам, никак не учитывая желания друг друга. Иначе говоря, котле грел теплоноситель не потому, что этого хотели контура отопления или контур загрузки БКН, а потому что ему сказали греть теплоноситель. Или, например, контура отопления 1 и 2 этажа и знать не знали, что в момент включения контура загрузки БКН, им вообще-то следует выключиться, повинуясь принципу «приоритета БКН», а не продолжать молотить, будучи ведомыми запросами лукавых датчиков температуры воздуха.
Пободное функционирование автоматики отопления не-пра-виль-но-е. Да, пром. контроллеры решили бы данную задачу на раз-два-три, но, напомню, мы работали в сегменте ИЖС. Там такие контроллеры не проходили (да и сейчас не проходят) ни по цене, ни по юзерфрендливости, ни по функционалу, который у пром.автоматики избыточен для ИЖС. А в 2018 н один доступный на рынке РФ «бытовой» контроллер умного дома с подобными задачами нормально справится не мог. По крайней мере мы так думали.
И вот для решения подобных задач и была привнесена в нашу работу великая релейная логика. Тоже, если что, не наше изобретение. Тут руку приложили славные предки, коим в отсутствии микропроцессоров, приходилось на этой релейной логике собирать и запускать вообще все.
Собственно вот пример одного из первых шкафов автоматики в нашем исполнении:

Количество шакалов на фото превышает все мыслимые пределы – прошу не серчать. Архивные фото по уважительной причине лени не нашел. Использовал скрины из архивного видео.

Чего удалось добиться?
С применением релейной логики мы обошли программные ограничения контроллера и заставили котел работать только тогда, когда работал один из контуров. Как это работало?

QF – автомат
W1.х – реле ectoControl
KL – промежуточное реле
xt – клеммы

Кстати, первые несколько лет шкафы мы собирали без схем и без маркировки кабеля, ибо зачем? Шкафы примитивные, однотипные и вряд ли придется что-то когда-то в них переделывать. Так мы думали тогда. Спойлер: мы ошибались. Но об этом в другой раз.

Что видно (я надеюсь, что видно) из схемы.

Реле W1.1-1.3 используются в программах ectoControl и в нужный момент подтягивают катушки промежуточных реле KL1-3. Те, в свою очередь, одной группой контактов подают напряжение на клеммы, а второй группой контактов замыкают «сухой» контакт котла.
Таким образом, котел греет теплоноситель только тогда, когда есть «запрос» от какого-то контура.

Кроме того, KL3, отвечающее за насос загрузки БКН, снимает напряжение с KL1-2, когда этот самый БКН «загружается». Вот и «приоритет БКН» подъехал.

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

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

А пока все. И так длиннопост получился.

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

На связи.