Всем привет. В принципе речь пойдёт о системе СКУД, видеонаблюдении и системе отслеживания показаний датчиков в одном стакане. Кому тема не интересна думаю и читать не стоит, только зря потратите время.
Да, сейчас много решений «на любой фломастер и кошелёк», но в одной системе одного нет, в другой — другого, в третьей — вроде есть всё, но так «склеено», что пользоваться больно.
Начать, наверное, надо вообще с простого вопроса: с чего вдруг автор решил так заморочиться, чтобы объединить всё это в одно?
В одно прекрасное утро приходит ко мне руководитель и говорит, что «у нас всё как-то несерьёзно». Бабки-охранницы, открывающие ворота, открытые двери — иди куда хочешь, бери что хочешь. Камеры — уже с прошлого века, регистратор такой, что, кажется, ещё динозавров снимал. А мы, говорит, ребята серьёзные, производство как-никак. И вот тебе, говорит, задача:
Нужно внедрить СКУД, чтобы и на территорию, и в здание без пропуска не попасть.
Камер должно стать больше, и совсем плохие заменить.
Датчики температуры восстановить — чтобы работали и записывали данные, которые всегда можно было посмотреть и при необходимости собрать отчёт.
И всё это должно быть отражено на схеме территории и помещений: где что стоит, где происшествия, чтобы всё это — как новогодняя ёлка. Глянул — и сразу увидел, где проблема.
Наверное, самое главное: всё должно быть локальным настолько, что даже датчики, которые «в приложении через интернет», в случае отвала этого самого интернета всё равно продолжили бы работать. Вот прям чтобы обрыв внешней связи не превращал объект в тыкву.
И почесав репу, я полез в интернет…
Не буду пересказывать полностью, сколько времени я потратил и сколько у какой системы плюсов и минусов — не стоит сейчас задача сравнивать, а то будет много букв. Просто тезисно, как оно ощущалось по факту:
Если нужно, чтобы прям СКУД — то забудь про датчики.
Если нужно видеонаблюдение и смотреть, кто ходил в курилку, а кто нет — то можно «СКУД + камеры». Но тогда теряешь нормальную схему и датчики.
Если нужно «умный дом» и красивые датчики — то легко, но «промышленное» видеонаблюдение и нормальный контроль доступа уже как-то мимо кассы.
Если нужно «всё сразу» — либо это огромный дорогущий комбайн от вендора, либо «давайте мы вам допилим под вас», и дальше звучит сумма, от которой хочется уйти в отпуск… лет на пять.
По итогу: полноценного «СКУД + Видеонаблюдение + Датчики + Схема» в одном месте, чтобы это было адекватно по деньгам и при этом работало локально, я не нашёл. А если идти к производителям с просьбой доработать продукт, то суммы получались заоблачные. И самое обидное — не то, что дорого, а то, что ты всё равно привязываешься к чужой логике, чужим ограничениям и чужому «так задумано».
И тут я вспомнил, что лет 10 назад, когда я ещё занимался созданием сайтов, был у меня проект простенького видеорегистратора с веб-мордой и схемой, на которую можно было наносить камеры. Тогда это было сделано «по приколу» и чтобы работало. И вот я подумал: а почему бы не попробовать добавить туда связку СКУД и датчиков?
Что я хотел получить (простыми словами)
Я сформулировал для себя картинку результата:
Открываю веб-страницу — вижу схему объекта (территория, здания, помещения).
На схеме отмечены двери, турникеты/ворота, камеры, датчики.
Любое событие — сразу видно: дверь открылась, проход по карте, тревога, движение по камере, температура улетела, датчик отвалился.
Могу нажать на точку на схеме и провалиться: «показать живую камеру», «показать архив», «показать историю датчика», «кто входил/выходил».
И всё это работает локально, без обязательного интернета. Интернет — это бонус для удалённого доступа, а не «пуповина».
И тогда стало понятно: если делаю сам, то нужен не «комбайн», а нормальная архитектура, где каждая часть делает своё, и где всё можно заменить без боли.
Техническая основа, на которой в итоге вырос EAS
Я не буду делать вид, что сразу всё идеально спроектировал. Нет. Сначала было «чтобы работало», потом «чтобы не ломалось», потом «чтобы можно было поддерживать». Но базовые решения в итоге получились такими:
Сервер: обычный Ubuntu-сервер на объекте (без облаков и магии), всё крутится как сервисы.
API и логика: Python + FastAPI (по сути — быстрый веб-движок), запуск через uvicorn, управление через systemd. Это удобно: сервис поднялся, упал — поднялся, логируется нормально, обновляется аккуратно.
База данных: PostgreSQL. Потому что нужна надёжность, нормальные индексы, понятные транзакции и чтобы потом не плакать, когда данных станет много.
Видеопотоки: отдельная штука для камеры — go2rtc. Он берёт RTSP от камер и отдаёт нормально в веб (HLS/WebRTC), и не надо городить зоопарк плееров и костылей.
Датчики и интеграции: чтобы не изобретать велосипед с «умным домом», используется Home Assistant как слой интеграций (он умеет говорить с кучей датчиков/хабов). EAS забирает оттуда сущности, состояние, события и складывает в свою БД.
Веб-интерфейс: админка — обычный web UI (без сложного SPA-фреймворка ради фреймворка). Главная идея — чтобы мог открыть в браузере хоть с ноутбука охраны, хоть с планшета, и оно работало быстро.
Если по-честному, этот набор технологий не «самый модный», а самый практичный. Мне не нужно было впечатлять конференцию. Мне нужно было, чтобы на объекте это не разваливалось и чтобы любой адекватный инженер мог потом разобраться.
Как я разделил задачу на части
Когда пытаешься сделать «и СКУД, и видео, и датчики, и схему», мозг начинает кипеть. Поэтому я разделил всё на несколько подсистем.
1) Схема (план объекта)
Это центр интерфейса. По сути, это «панель ситуации»: точки на плане, состояния, подсветки, быстрые переходы. Схема не должна быть музейной картинкой — она должна быть рабочей.
2) Видеонаблюдение
Тут важны две вещи:
живой просмотр (желательно без «у меня не открывается, потому что в браузере не тот плагин»),
архив (чтобы можно было быстро промотать и найти момент).
И вот тут очень быстро выясняется, что «просто подключить камеры» — это детский сад. Камеры разные, RTSP иногда капризный, сеть иногда не идеальная, а пользователю всё равно надо «чтобы работало». Поэтому go2rtc стал прям спасением: он берёт на себя роль «прокладки» между камерами и браузером.
3) Датчики
С датчиками похожая история: легко получить показания, сложно сделать так, чтобы потом этим можно было пользоваться. Важны:
история за период,
отчёты,
фильтрация мусора (технические метрики, которые пользователю не нужны),
и самое важное — нормальные имена, которые человек дал датчику, и чтобы они были везде: в списках, графиках, отчётах, выгрузках.
4) СКУД
СКУД — штука «про ответственность»: кто, куда, когда. Здесь нельзя «приблизительно». Нужны события, журнал, привязки, роли, точки доступа, и чтобы это не зависело от «а интернет есть?».
И вот на этом месте я окончательно понял: если система будет завязана на облако — это будет постоянная боль. У охраны нет задачи разбираться, «почему не работает». У них задача — чтобы ворота открывались тем, кому надо, и чтобы на объект не заходили те, кому не надо.
Почему «локально-сперва» — это необходимость
Требование «чтобы без интернета продолжало работать» многим кажется странным, пока не поживёшь на производстве.
Интернет может лечь. Провайдер может «что-то там …..». Роутер может «устать». Электрики могут «поиграть с автоматами». И если в этот момент у тебя СКУД или камеры превращаются в кирпич — это не техническая проблема, это уже организационная.
Поэтому принцип был такой:
всё критичное работает локально;
удалённый доступ — это сверху, как дополнительная возможность;
а данные хранятся так, чтобы потом можно было поднять отчёт «за вчера», «за месяц», «до инцидента», «после инцидента».
Как это всё начало собираться в EAS
Идея «взять старый веб-видеорегистратор и допилить» не быстро превратилась в нормальный проект. Потому что когда начинаешь добавлять СКУД и датчики, выясняется, что:
нужна единая модель объекта (помещения, зоны, точки на плане),
нужна единая система пользователей и прав доступа,
нужна нормальная база и индексация,
нужна админка, в которой можно всё это поддерживать не через консоль,
нужен механизм обновления, чтобы можно было развивать систему, не превращая каждое обновление в «в ночь с пятницы на субботу молимся».
Так и появился EAS (Enterprise Automation System) — по сути, локальная система, которая объединяет видео, события, датчики и логику объекта в одном месте.
И самое интересное, что на бумаге всё звучит просто. А на практике начинается: «вот эта камера почему-то отдаёт не тот RTSP», «вот этот датчик шлёт странные сущности», «вот тут время на сервере уехало», «вот тут график не рисуется», «вот тут отчёт нужен в Excel», «вот тут люди хотят на схеме видеть всё сразу».
Но именно из этих мелочей и рождается нормальная система. Не из презентаций и лозунгов, а из того, что охранник нажал — и оно сработало. Инженер открыл — и понял, что происходит. Руководитель посмотрел — и увидел картину объекта.
На этом, пожалуй, закончу и так очень много букв. Текст прогнал через deepseek так как такой объем самому вычитывать после написания просто лень. В следующих статьях постараюсь углубится и рассказать, как это выглядело изнутри.
Думаю, это будет полезно тем, кто решит так же заморочится и позволит не наступать на грабли используя мой опыт.
