Серия «Умный дом»

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

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

28 октября в 08:04 Frigate зарегистрировал событие с классом Bird и уверенностью 73%. На том же снимке вторая нейросеть, которой поручено описывать происходящее, совершенно спокойно написала, что собака находится в металлическом вольере и пытается выбраться. Получается, одна модель увидела птицу, вторая - собаку, а я увидел очередную причину потратить вечер на домашнюю инфраструктуру.

Причём это не единичная ошибка. За две недели нашлось 19 подобных событий: Frigate записывал объект как птицу, а вторая модель описывала собаку. Видимо, у меня там не просто двор, а секретный заповедник, где собаки успешно мимикрируют под пернатых.

С котами у системы тоже отдельные отношения. 5 ноября на одной из камер сначала появилось событие Bird, а через несколько секунд - Cat. В описании кошачьего события нейросеть сообщила, что видит двух кошек с разным окрасом, хотя детектор выделил только один объект. Возможно, вторая кошка была настолько хорошо замаскирована для нейросети-детектора, что её обнаружила только особо продвинутая модель. Хотя сидит она прямо на виду – приглядитесь к их кошачьему домику. А может, она просто пришла поесть, пока первая отвлекала внимание. Уличные коты вольные, мне пока докладывать не хотят чем занимаются.

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

Как оно вообще работает

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

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

Всё это работает локально, на моём домашнем сервере. Я не отправляю видео с камер в облако и не плачу за каждое распознавание. У сервера есть видеокарта RTX 3050 на 6 Гб видеопамяти, на которой крутится детектор объектов. Чтобы не заставлять её анализировать тяжёлое видео целиком, каждая камера отдаёт два потока: один для записи, второй, полегче, для распознавания. Компьютеру не обязательно смотреть фильм в 4K, чтобы ответить на вопрос, есть ли во дворе кот.

Сама система довольно шустрая и в обычных ситуациях справляется хорошо. Людей, машины, кошек и собак она обычно находит без особых проблем. Но иногда начинаются творческие интерпретации. И вот тут я особенно рад, что всё работает дома: семейные тайны не покидают локальную сеть.

Когда готовой кнопки нет

Помимо распознавания животных у меня была ещё одна задача: хотелось понимать, открыты или закрыты ворота навеса. Казалось бы, мелочь. Но готовой кнопки «Посмотреть на ворота и сказать, что с ними» в стандартном наборе Frigate нет.

Пришлось сделать отдельную маленькую модель, которая различает всего два состояния: «Ворота открыты» и «Ворота закрыты». Она смотрит не на весь кадр, а на небольшой участок изображения, где находятся ворота, и определяет, что там происходит. Результат передаётся в Home Assistant, где его уже можно использовать как обычный датчик.

У меня конечно есть отдельная автоматика, управляющая открытием и закрытием ворот на базе китайской Tuya, но к сожалению она периодически отваливается от Home Assistant, и микромодель на Frigate стала своеобразной страховкой.

Модель весит меньше мегабайта. Не гигабайта, не мегабайта с хвостиком, а меньше мегабайта. Вся эта нейросетевая магия помещается в файл размером с небольшую картинку. И, что особенно приятно, ворота она пока не путает ни с птицами, ни с кошками.

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

Домашний дата-центр имени котиков

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

Кстати, с диском уже есть определённые отношения. На момент последней проверки он был занят на 94%. Около 870 ГБ занимают видеозаписи, а ещё есть снимки и база событий. С августа система накопила больше двадцати тысяч событий. То есть коты и прочая живность не просто гуляют по участку, а активно производят контент. Причём абсолютно бесплатно для себя и за мой счёт по части хранения. Ни одного рекламного контракта, ни одной благодарности за использование образа. Только шерсть на всём подряд и растущий объём архива.

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

Электричество тоже организовано с запасом. Дом резервируется от однофазного дизельного генератора на 16 кВт с автоматическим вводом резерва, а сервер подключён через UPS. Когда пропадает электричество, сервер пережидает запуск генератора на батарее. Получается, что у котов есть собственный резервный источник питания для наблюдения за тем, как они ничего не делают. Не уверен, что они это ценят.

А чем, собственно, занимается инженер?

Когда начинаешь рассказывать обо всём этом человеку со стороны, довольно быстро замечаешь одну проблему. Можно сказать: «Я поставил камеры во дворе». И всё понятно. А можно начать объяснять про два потока, виртуализацию, локальные модели, классификаторы, серверы и мониторинг. И вот уже собеседник смотрит на тебя так, будто ты не камеры поставил, а случайно открыл портал в другое измерение. И порывается сбежать, если ты не успел его связать. Вот как Манишка ниже.

Хотя результат-то простой: камеры записывают видео, компьютер ищет животных и людей, а отдельная модель помогает понять, открыты ли ворота. Вся инженерная кухня остаётся за кадром. До тех пор, пока собака не становится птицей, а кошка - двумя кошками.

Кстати, с этой проблемой - как объяснить, чем вообще занимаются инженеры, - связан один интересный проект YADRO ко Дню инженера. В нём участвуют восемь сотрудников компании и их дети. Сначала дети своими словами рассказывают, чем, по их мнению, занимаются родители, а потом родители объясняют, что на самом деле входит в их работу.

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

YADRO разрабатывает российские серверы и системы хранения данных. То есть занимается оборудованием, на котором работают сервисы и хранятся данные. Со стороны можно сказать: «Ну, серверы делают». А за этой короткой фразой скрывается огромная работа инженеров, которые проектируют, собирают и обеспечивают надёжность всей этой техники.

У меня, конечно, не завод и не серверная платформа промышленного масштаба. Но сама суть знакома: есть задача, есть ограничения, есть оборудование и программное обеспечение, и всё это нужно заставить работать вместе. А потом ещё объяснить окружающим, почему оно вообще так устроено.

Если совсем просто

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

Впрочем, пусть пока так и остаётся. Главное, чтобы ворота закрывались, сервер не падал, коты не забивали диск своими фотосессиями, а птица не начинала лаять.

Всем добра и с прошедшим днем инженера!

P.S. О проекте YADRO ко дню инженера можно узнать подробнее тут. Зайдите, там правда интересно.

Реклама. ООО «КНС Групп», ИНН: 7701411241

У нас в доме стоит старенький электрокотёл, который верой и правдой отапливал дом еще с незапамятных времен. Котёл добротный – шесть трубчатых электронагревателей (ТЭНов) под чугунным боком, никаких тебе «умных» функций, только автоматы, с помощью которых включаются и отключаются тены. Конечно, ни о каком расписании или удаленном управлении речи не шло: либо включен и жарит на полную, либо ты мёрзнешь, если забыл вовремя щелкнуть выключателем. Хотелось комфорта и контроля – чтобы котёл сам поддерживал температуру, не сжигал лишнего электричества и, желательно, подружился с современными технологиями.

Решено – будем модернизировать дедушку-котёл! План такой: оснастить каждый из шести ТЭНов отдельным умным реле с датчиком, подключить их к Home Assistant, а логику управления запрограммировать в Node-RED. Звучит просто… в теории. Как это реализовывалось на практике – делюсь опытом, со всеми успехами, граблями и лайфхаками.

Оборудование

Для модернизации пригодились следующие компоненты:

• Электрокотёл – непосредственно отопительный котёл советского закала. Шесть нагревательных элементов суммарной мощностью около 18–20 кВт, подключенных по схеме звезды на три фазы (по двум ТЭН на фазу).

• Реле Sonoff PWR320D – умные Wi-Fi реле на DIN-рейку с током до 20 А (каждый спокойно тянет один 4-кВт ТЭН). У них есть встроенный мониторинг потребляемой мощности и небольшой экран. Таких понадобилось 6 штук – по одному на каждый ТЭН, чтобы иметь возможность управлять нагревателями индивидуально.

• Реле Sonoff THR320D Elite – умное Wi-Fi реле на DIN-рейку с током до 20 А и контролем температуры - потребуется собственно для контроля температуры и включения/выключения насоса отопления.

• Home Assistant – мозг умного дома (развернут на Proxmox VE на отдельной виртуальной машине в инсталляции HassOS). Через него реле Sonoff интегрируются в систему, и с его помощью можно получать показания и отправлять команды на наши нагреватели.

• Node-RED – визуальный редактор автоматизаций, установлен как дополнение к Home Assistant. В нем реализована логика работы котла: когда и сколько ТЭНов включать, исходя из температуры и прочих условий.

• Датчик температуры Sonoff DS18B20 – цифровой термометр, прикрепленный к трубе выхода горячей воды из котла. Он следит за температурой воды/теплоносителя, чтобы Node-RED знал, когда нагревать, а когда притормозить. Сам датчик подключен к Sonoff THR320D Elite.

• Удлинитель датчика температуры Sonoff DS18B20 на 5 метров – потребовался, чтобы дотянуть датчик до котла.

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

Подключение реле к Home Assistant

Начал модернизацию с самого очевидного: установка умных реле на котёл. Каждое реле Sonoff PWR320D разместил в электрощите рядом с автоматами. Подключение по электронике вышло относительно прямым: каждый тен отсоединил от старой схемы и завел через контакты своего Sonoff (фаза через реле, ноль общий). Таким образом, любое реле может включить или выключить питание конкретного нагревательного элемента. Шесть элементов – шесть независимых каналов нагрева. Перед окончательной сборкой проверил, что токи и сечения проводов соответствуют мощностям: ~4,5 кВт на ТЭН (~10 А) – реле рассчитаны на 20 А (кратковременно до 25 А), так что запас есть. Главное – затянуть винты клемм покрепче, чтобы ничего не грелось.

Далее – интеграция в Home Assistant. Реле Sonoff подключаются к домашней Wi-Fi сети и через облако eWeLink могут управляться со смартфона. Но мне нужен локальный и более гибкий контроль, поэтому я добавил их напрямую в Home Assistant.

Вариантов несколько: можно прошить альтернативную прошивку (Tasmota/ESPHome) или использовать готовый интеграционный компонент Sonoff LAN. Я пошёл по простому пути – использовал компонент, который позволил привязать реле в Home Assistant без танцев с бубном.

После нехитрых манипуляций все шесть устройств появились в системе: каждому присвоилось по сущности типа switch (переключатель) и набор датчиков (мгновенная мощность, напряжение, ток и счётчик кВтч). Естественно, сразу переименовал их в осмысленные названия – чтобы не потеряться в куче одинаковых «Sonoff Switch». Маркером подписал номера и на самих модулях в щитке, как видно на фото, для наглядности: куда какой провод идет.

Очень важно - реле ставятся обязательно ПОСЛЕ автоматов, без автоматов их ставить категорически запрещено!

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

Важный нюанс – датчик температуры. Поскольку изначально никакого электронного термометра в котле не было, пришлось исхитриться. Я использовал популярный герметичный цифровой датчик DS18B20. Но как его присобачить к старому баку, не врезая новых гильз? Решение народное: примотать датчик снаружи к трубопроводу как можно ближе к выходу котла, утеплив место замера. Немного вспененного полиэтилена, сверху чёрная изолента – и вот уже импровизированный термоколодец готов. Да, точность хуже, чем погружного датчика (показывает чуть ниже реальной температуры воды), зато установка без разгерметизации системы.

На этом железная часть закончена: котёл физически подключен к «умному» управлению. Теперь самое интересное – научить его работать автоматически по заданным правилам.

Node-RED и с чем его едят

Простейший способ управлять отоплением – использовать штатные автоматизации Home Assistant (например, интеграцию generic_thermostat). Но в нашем случае шесть нагревателей – система посложнее банального включения-выключения. Хотелось реализовать нечто более умное: например, при небольшом отклонении температуры включать не все сразу, а пару ТЭНов, чтобы не гонять котёл на полную, или поочередно задействовать разные элементы, чтобы ресурсы фаз расходовались равномерно. Для таких экспериментов идеально подошёл Node-RED – графический редактор сценариев, где можно накидать любые логические цепочки.

В Node-RED я создал отдельный поток автоматизации для котла. Общая логика: следить за температурой воды и помещений в доме и поддерживать её в диапазоне, включая нужное число ТЭНов. Общая схема реализованной автоматизации ниже.

Настройка Node-Red

Мы реализуем логику через поток Node-RED, состоящий из нескольких узлов (nodes).

Узел (node) в Node-RED — это блок, который выполняет конкретное действие.

Можно сказать, что узлы — это "кирпичики", из которых строится вся логика потока.

Каждый узел имеет:

• свою функцию (например, получить данные, сделать проверку, отправить команду),

• входы (куда приходят сообщения),

• выходы (куда узел отправляет обработанные сообщения).

Ниже таблица с используемыми в нашей автоматизации типов узлов (@SupportTech, а таблицы когда будут?)

Если описывать получившуюся картину крупными мазками - наша автоматизация делится на дневную и ночную, поскольку у нас двухтарифный счетчик отопления, и отопление работает в основном ночью (с 23.00 до 07.00)

Ночная ветка управления отоплением

Что происходит:

Каждые 5 минут происходит запуск проверки условий через inject-узел.
Проверяются следующие параметры:

• Время суток (должна быть ночь — с 23:00 до 07:00).

• Температура котла.

• Температура в спальне.

• Температура на кухне.

Подробно по шагам:

1. Проверка времени суток

• Узел Time Range Switch — определяет, сейчас ночь или день.

• Если ночь — запускается ночная логика (эта ветка).

2. Проверка температуры котла и помещений

• Узел Current State — получаем температуру котла.

• Если температура в спальне ≤ 25 °C и на кухне < 27 °C, запускается нагрев.

• Иначе ничего не делаем.

3. Проверка активной сессии

• Узел Function — если переменная heating_active == "true", значит уже идёт нагрев, повторно запускать не нужно.

  Функция используется следующая:

  if (flow.get("heating_active") === "true") {

  // Уже запущено, пропускаем

  return null;

  }

  return msg;

4. Какой нагрев запускать?

• Используем узел Switch — по текущей температуре котла:

  • Если ≤ 31 °C → включается группа 3.5 кВт ТЭНов.

  • Если между 31 °C и 60 °C → включается группа 2.7 кВт ТЭНов.

  • Если нет данных — отправляется уведомление в Telegram, и включается минимальная мощность.

5. Включение ТЭНов

• Сначала выключаются все ТЭНы (на всякий случай, чтобы исключить наложение сценариев). Используем узел call service, вызываем сервис switch.turn_off

• Затем с небольшой задержкой (5-10 секунд) ТЭНы включаются один за другим:

  • Для группы 3.5 кВт: три ТЭНа, фаза A → фаза B → фаза C.

  • Для группы 2.7 кВт: три ТЭНа, фаза A → фаза B → фаза C.

• После каждого включения ТЭНа проверяется его статус (узел current state) — если включение не произошло, повторяем попытку.

6. Завершение

• После успешного старта всех нужных ТЭНов устанавливается переменная heating_active = true. (узел change)

• Это защищает систему от повторного включения без необходимости.

Дневная ветка управления отоплением

Что происходит:

Каждые 5 минут происходит запуск проверки условий через inject-узел.
Проверяются:

• Время суток (должен быть день — с 07:00 до 23:00).

• Температура котла.

• Температура в спальне.

Подробно по шагам:

1. Проверка времени суток

• Узел Time Range Switch — определяет, что сейчас не ночь, а значит — день.

2. Проверка температуры котла

• Узел Current State — измеряется температура котла.

• Если температура котла < 60 °C — переходим к дальнейшей проверке мощности и температуры внутри помещений.

• Иначе ничего не делаем.

3. Проверка мощности котла

• Узел Current State — анализируется текущая мощность.

• Если мощность котла меньше 11 500 Вт — допустимо включить нагрев.
  Если мощность превышена — отопление не запускается.

4. Проверка температуры в спальне

• Узел Current State — замер температуры в спальне.

• Если температура ≤ 24.5 °C — начинаем дневную сессию нагрева.

5. Защита от повторного старта

• Узел Function — проверяем переменную heating_active. Функция та же, что и в ночном режиме.

• Если она уже установлена в "true" — отопление уже активно, повторный старт блокируется.

6. Последовательность действий

• Узел Change — устанавливаем переменную heating_active = true.

• Далее система:

  1. Выключает все ТЭНы.

  2. Выдерживает паузу (5 секунд).

  3. Включает один ТЭН мощностью 2.7 кВт на фазе B.

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

7. Завершение

• После включения ТЭНа больше действий нет.

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

Условия отключения отопления

Когда выполняется проверка:

• Каждые 60 секунд через inject-узел.

• А также в фиксированное время (ежедневно в 07:00 и в 23:00) через отдельные inject.

Что именно проверяется:

1. Температура котла

   • Если котёл нагрелся выше 60 °C, значит отопление нужно остановить, чтобы не перегреть систему.

2. Мощность котла

   • Если текущая суммарная мощность выше 11 500 Вт, это признак перегрузки.
     Система должна срочно отключить лишние ТЭНы, чтобы избежать перегрева или срабатывания автоматов.

3. Температура на кухне

   • Если на кухне температура превысила 27 °C — отопление останавливается как ненужное.

4. Температура в спальне

   • Если температура в спальне превысила 25.3 °C — отключаем нагрев, чтобы не перегреть комнату.

5. Температура в кабинете

   • Если в кабинете температура поднялась выше 26.5 °C — тоже выключаем обогрев.

Что происходит при выполнении любого условия:

• Узел Action node api-call-service:

  • Все шесть ТЭНов отключаются командой switch.turn_off.

• После выключения всех ТЭНов:

  • Через delay (10 секунд) устанавливается переменная heating_active = false.

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

Специальные выключения по расписанию:

• 07:00 каждый день — выключение всех ТЭНов в начале дня перед началом дневного режима.

• 23:00 каждый день — выключение всех ТЭНов перед началом ночного режима.

• Ручное выключение — можно отправить сигнал вручную через отдельный inject-узел.

Краткая суть:

Любое превышение температурных или мощностных порогов → полное отключение всех ТЭНов и остановка активной сессии нагрева.

После настройки всех узлов и дебага (о котором ниже) мне удалось добиться желаемого: котёл сам включается и отключается по заданному алгоритму. На панели Home Assistant я вижу текущую температуру и статус каждого из шести ТЭНов, а при желании могу вручную вмешаться – например, принудительно выключить некоторые, если нужно ограничить потребление, или наоборот, включить все, если вдруг резко похолодало.

Проблемы и грабли

Не всё шло гладко с первого раза. Поделюсь парочкой моментов, где пришлось попрыгать через грабли (и посмеяться потом):

• Ребалансировка фаз – не взлетела. Идея звучала круто: чтобы электроэнергия расходовалась равномерно по фазам, я задумал поочередно менять, какие ТЭНы включаются первым делом. Мол, в одном цикле греть фазой A, в следующем – фазой B и так далее, чтобы суммарно каждая фаза нагружалась одинаково. Node-RED я даже настроил что-то вроде кругового выбора: если надо включить только 1–2 нагревателя, он чередовал их между разными фазами. На практике же эта затея скорее усложнила сценарий, чем принесла пользу. Котёл-то в любом случае потребляет немало, и при длительной работе выравнивание получилось чисто символическим. Зато усложненный код начал временами чудить: то забывал включить какой-то элемент, то наоборот забывал вовремя выключить. В итоге, после пары холодных утра и тёплых ночей (когда автоматизация решила «передохнуть»), я убрал эту фичу и оставил логику попроще. Как говорится, не пытайтесь оптимизировать то, что и так работает – и всё будет хорошо. 🙂

• Отладка и внезапные баги. Писать логические цепочки на Node-RED было увлекательно, но первый блин вышел комом. Например, я создал цикл, в котором одна часть потока включала нагрев, а другая сразу его выключала из-за неправильно установленного условия гистерезиса. В результате котёл начал моргать: щёлкал реле туда-сюда каждую секунду, устроив настоящую светомузыку в щитке! Хорошо, вовремя заметил в логах аномалию (да и по звуку реле догадался) – быстренько исправил логику, введя задержки и скорректировав условия. Ещё один раз ошибся с именами сущностей в Home Assistant – Node-RED просто не смог включить отопление утром, потому что искал несуществующее имя устройства. Проснулся я в холодной комнате и понял, что умному дому тоже нужны проверки – после того случая добавил оповещение: если температура падает ниже критической и ничего не включилось, система шлёт мне тревожное уведомление. Теперь я сплю спокойно (и в тепле).

Конечно, были и мелочи: набивал шишки с настройками Node-RED Dashboard (планировал красивую панельку управления котлом – сделал, но потом понял, что ей почти не пользуюсь), долго возился с калибровкой датчика (пару градусов сдвига компенсировал в настройках), разбирался, как построить график потребления электроэнергии этими ТЭНами. Но то уже будни домашней автоматизации – не столько проблемы, сколько рабочие моменты, зато сейчас можно друзьям показывать графики и хвастаться, как “ИИ управляет котельной” 😉.

Выводы

Стоила ли игра свеч? Определенно, да – по крайней мере для такого любителя технологий, как я. Теперь у меня котёл не просто древний металлический бак, а часть умного дома: сам поддерживает комфортную температуру, я могу наблюдать за его работой из любого места (красота – лежишь вечером на диване, смотришь в телефон: температура воды 48°C, потребляемая мощность 5 кВт, – и никакого беготни в подвал!). Можно настроить расписание по времени или удаленно выключить котёл, если уехал на выходные. К тому же, я получил ценнейший опыт в Home Assistant и Node-RED, разобрался глубже в электрической части своего дома.

С точки зрения экономии денег – вопрос спорный. Сами по себе реле, датчики, контроллеры стоят денег и окупятся не сразу. Но определенная оптимизация получилась: котёл теперь не перегревает лишний раз воду, не молотит впустую всю ночь – а включается по потребности. Думаю, это снизит счета за электричество в долгосрочной перспективе. Плюс мониторинг показал, сколько реально киловатт он съедает – раньше-то мы этого даже не знали точно, а сейчас я вижу расход в кВт·ч в HA и могу проанализировать.

Что бы я улучшил теперь? Наверное, избавился бы от избыточной сложности. Шесть раздельных реле – гибко, но можно было обойтись и меньшим количеством ступеней нагрева. Возможно, стоило изначально использовать более мощные контакторы по фазам (3-фазные реле) и управлять ими через один-два Sonoff – схема была бы проще. Ещё из идей – добавить второй датчик температуры на обратку или в сам бак, чтобы контролировать перегрев точнее. Но это всё на будущее.

В целом же я доволен результатом: старый электрокотёл успешно проапгрейжен. Теперь он сочетает в себе надежность советского агрегата и удобство современного умного устройства. 🎉 Если у вас в подвале тоже скучает какой-нибудь раритет без мозгов – знайте, приделать ему «ум» своими руками вполне реально. Было бы желание, Wi-Fi и парочка свободных вечеров!

Совет для тех, кто хочет повторить наш путь

Система управления котлом, которую мы построили в Node-RED, — это довольно сложный проект. Он включает десятки условий, проверок, переключений, планировщиков, автоматических защит и оптимизаций. Чтобы прийти к такому уровню, потребовались опыт, время и множество итераций.

Поэтому совет для новичков:

👉 Начинайте с малого!

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

Лучше начать так:

• Сделайте простую схему: например, включить реле при температуре ниже 20°C и выключить выше 22°C.

• Добавьте проверку времени суток: греть только ночью.

• Потом — защиту от перегрева.

• Потом — балансировку нагрузок.

• И так далее...

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

И главное:

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

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

Если будут вопросы - пишите!

Буду рад, если поддержите мою деятельность рублем и накидаете ещё идей для новых статей)

• определяет объекты нейросетью YOLOv7 → быстро, open-source;

• семантический поиск (CLIP) — можно найти «красную машину» за секунду;

• через GenAI кидает кадры в LLaVA и получает короткое описание сцены.

Всё крутится локально: никакой утечки видео на чужие сервера и ноль абонплаты.

2. Железо и база

Что есть:

• Хост: Proxmox 8, в корпусе — AMD Ryzen 5 4600G, 32 Gb RAM, NVIDIA RTX 3050

• VM: Ubuntu 22.04, 6 vCPU / 16 GB RAM

• GPU passthrough: настроен по гайду на Хабре

• Сети: VM и камеры в одной подсети

• Камеры: любые с RTSP-потоком (у меня 6 штут Tapo C500)

3. Зачем нужен GPU passthrough?

Отдельно остановлюсь: почему я заморочился с пробросом GPU в VM, а не запустил всё на CPU или, скажем, на TPU (Coral)? Дело в том, что моя задача – тянуть обнаружение объектов в реальном времени на нескольких камерах и параллельно гонять тяжелую модель для описания.
Даже один поток 1080p с современным детектором (YOLOv7) может загрузить CPU на 100%, не говоря уж про генеративную модель с 13 миллиардами параметров (LLaVA 13B) – её на CPU вообще считать не будешь (за минуту никакого описания не дождешься). GPU же позволяет распараллелить эти задачи и выполняет их на порядки быстрее.

Таким образом, GPU passthrough — обязательный шаг, чтобы внутри VM иметь аппаратное ускорение. Он нужен, чтобы Frigate мог использовать CUDA/TensorRT для инференса нейросети, а ffmpeg – аппаратное декодирование/кодирование видео (NVDEC/NVENC). Без GPU моя затея с локальным AI-прислугой просто не взлетела бы.

Настройка прошла относительно спокойно: включил IOMMU в BIOS, в Proxmox добавил устройство hostpci0 (с указанием ID видеокарты), отключил эмулируемую VGA. Ubuntu внутри пришлось снабдить драйверами NVIDIA – после этого карта стала доступна, как если бы она была в обычном PC.

Примечание: в более простых сценариях можно было бы использовать USB-акселератор типа Google Coral TPU – Frigate тоже умеет, но у меня его нет, а вот 3050 просилась в бой. К тому же Coral даёт только обнаружение, а для LLaVA всё равно нужен бы был GPU или очень мощный CPU. Так что выбор очевиден.

4. Docker Compose: поднимаем Frigate и Ollama

Система в VM готова, теперь разворачиваем два основных сервиса в контейнерах: Frigate NVR и Ollama. Оба будут запускаться через Docker Compose — это удобно, чтобы они стартовали вместе и были связаны в одну сеть.

Я установил Docker Engine и docker-compose в Ubuntu (для опытных пользователей это тривиально: несколько команд, либо скрипт установки Docker от официального репозитория).
Предполагаю, что читатель уже умеет ставить Docker и Compose, поэтому опущу подробности apt-установки.

Перейдем сразу к Compose-файлу. Вот финальная версия моего docker-compose.yml (@SupportTech, когда будут уже нормальные код-сниппеты?!):

version: "3.9"

services:

frigate:

container_name: frigate

privileged: true # ← проще дать контейнеру весь /dev, чем перечислять /dev/nvidia*

restart: unless-stopped

image: blakeblackshear/frigate:0.15.0-tensorrt # ← нужная сборка с TensorRT под NVIDIA

deploy:

resources:

reservations:

devices: # ← “новый” способ подключить GPU (Compose v3 + nvidia-container-runtime)

- driver: nvidia

count: 1 # ← берём единственную RTX 3050

capabilities: [gpu]

shm_size: "2048mb" # ← увеличиваем /dev/shm, иначе Frigate будет ворчать

devices:

- /dev/dri/renderD128:/dev/dri/renderD128 # ← останется, если в хосте ещё есть iGPU; иначе убрать

volumes:

- /etc/localtime:/etc/localtime:ro

- ./config:/config

- ./storage:/media/frigate

- type: tmpfs

target: /tmp/cache # ← храним временные JPEG/embeddings в RAM → экономим SSD

tmpfs:

size: 1000000000 # 1 GB хватит 4–6 камерам 1080p

ports:

- "8971:8971" # ← новый веб-UI Frigate 0.15

- "5000:5000" # ← REST API + старый UI (по желанию)

- "8554:8554" # ← RTSP restream от go2rtc

- "8555:8555/tcp" # ← WebRTC сигнализация

- "8555:8555/udp" # ← WebRTC медиа-канал

environment:

FRIGATE_RTSP_PASSWORD: "PASSWORD" # ← чтобы не писать пароль в каждом URL

YOLO_MODELS: "yolov7-640" # ← Frigate подтянет и закэширует модель .onnx

ollama:

container_name: ollama

restart: unless-stopped

image: ollama/ollama

healthcheck:

test: ollama --version || exit 1 # ← простой чек, что CLI отвечает

entrypoint: /root/entrypoint.sh # ← твой скрипт автоподтяжки моделей

volumes:

- ./ollama/volume:/root/.ollama # ← сюда Ollama кладёт модели (сохранятся между рестартами)

- ./ollama/entrypoint.sh/root/entrypoint.sh

- /etc/localtime:/etc/localtime:ro

ports:

- "11434:11434" # ← API Ollama, Frigate будет стучаться сюда

environment:

OLLAMA_NUM_PARALLEL: "1" # ← не даём LLaVA жрать VRAM параллельными запросами

OLLAMA_MAX_QUEUE: "256"

deploy:

resources:

reservations:

devices:

- driver: nvidia

count: 1

capabilities: [gpu]

На что тут стоит обратить внимание:

• Образ Frigate:

  • я использую тег stable-tensorrt. Это сборка под amd64 с поддержкой NVIDIA GPU. В ней уже включены нужные библиотеки CUDA и TensorRT для аппаратного ускорения инференса. Обычный stable образ не умеет работать с TensorRT, имейте в виду.

• Привилегированный режим:

  • privileged: true: я включил для простоты, чтобы контейнер без препонов получил доступ к устройствам хоста.

• shm_size: 2048mb:

  • увеличиваем раздел общей памяти. Frigate хранит там кадры для обнаружения и прочие буферы. По умолчанию Docker даёт 64Мб, но с несколькими камерами в высоком разрешении этого мало. В 0.15 Frigate сам ругается, если /dev/shm маловат. Я поставил 2048 MB – у меня 6 камер, этого достаточно, при необходимости можно больше. Главное, чтобы не было переполнения, иначе Frigate может упасть или терять кадры.

• Tmpfs на /tmp/cache:

  • важный трюк. Frigate использует /tmp/cache для разных временных файлов (например, для отслеживания объектов, кадры для распознавания и т.п.). Монтируя туда tmpfs, мы удерживаем эти операции в RAM, что ускоряет работу и снижает износ диска. Рекомендация из документации, и действительно, нагрузка на диск резко упала после этого (SSD сказал спасибо). Я выделил 1 ГБ; в зависимости от числа камер и их разрешения можно увеличить или уменьшить.

• Порты:

  • 8971 – новый веб UI Frigate. Начиная с 0.15, интерфейс доступен только на защищенном (с авторизацией) порту.

  • 8554 – RTSP restream (от встроенного сервиса go2rtc). Через него я могу при желании подключаться VLC/телефоном к камерам через Frigate, не нагружая сами камеры множеством прямых коннектов. Удобно, хотя я пользуюсь в основном веб-интерфейсом.

  • 8555 (tcp и udp) – это порты для WebRTC. Frigate через go2rtc умеет раздавать видеопоток прямо в браузер по WebRTC, минуя RTSP. Это быстрее и экономит трафик, и обходится без плагинов.

• Переменные среды:

  • FRIGATE_RTSP_PASSWORD – я назначил пароль для RTSP, и в конфиге камер могу использовать шаблон ${FRIGATE_RTSP_PASSWORD}. Чтобы случайно не засветить пароли, удобнее вынести их в env. (Frigate поддерживает подстановку env-переменных в config.yml).

  • YOLO_MODELS: "yolov7-640" – переменная окружения для контейнеров Frigate, предназначенная исключительно для автоматической загрузки (и/или перекомпиляции) моделей YOLO при первом старте.

• Ollama:

  • Использую официальный образ ollama/ollama.

  • Порт 11434: это дефолтный порт REST API Ollama. Я его открыл наружу, хотя можно было не делать этого, если обращаться к модели только из Frigate. Frigate, работая в той же докер-сети, может достучаться до ollama:11434 без проброса на хост. Но мне для отладки хотелось иногда самому попробовать запросы к Ollama, поэтому порт пробросил.

  • Volume ollama-data на /root/.ollama: здесь хранятся модели, которые скачивает Ollama. Обязательно делаем volume, иначе при пересоздании контейнера вам придётся опять тянуть десятки гигабайт моделей 😅. С volume скачанные модели останутся. (Модели, кстати, он скачивает из интернета при первом запросе, имейте в виду).

Запустив docker-compose up -d, я проверил:

• Frigate успешно стартовал, в логах увидел, что он нашёл GPU (строка [INFO] Nvidia decoder initialized и что-то про TensorRT). Если бы он не увидел GPU, он либо упал бы с ошибкой, либо работал на CPU, что нам не подходит.

• Ollama запустился и слушает на 11434 – это можно проверить docker logs ollama или открыв http://<IP_ВМ>:11434 (он должен вернуть приветственное сообщение типа Ollama vX.X API).

Оба сервиса работают, но пока Frigate “пустой” – без конфигурации, а Ollama не знает, какую модель мы от него хотим. Пора заполнить конфиг Frigate и подготовить нейросети.

5. Настройка Frigate (config.yml)

Конфигурационный файл config.yml задаёт параметры Frigate: какие камеры подключать, как выполнять детекцию и пр. Рассмотрим минимальный рабочий конфиг под нашу задачу – одна камера с детекцией на GPU (YOLOv7-640):

model:

path: /config/model_cache/tensorrt/yolov7-640.trt # ← готовый движок TensorRT

input_tensor: nchw

input_pixel_format: rgb

width: 640

height: 640

semantic_search:

enabled: true # ← CLIP-embedding для «поиска по картинке/тексту»

model_size: large # large требует +VRAM; можно small, если упираемся в 8 ГБ

reindex: false # true = прогонит всё старое видео (долго)

genai:

enabled: true

provider: ollama

base_url: http://ollama:11434 # ← имя сервиса внутри docker-сети

model: llava # ← в entrypoint подтяни llava 13b или 7b

prompt: >-

Analyze the {label} in these images from the {camera} security camera...

object_prompts: # ← кастомные подсказки на каждый класс

person: Examine the main person in these images...

car: Observe the primary vehicle in these images...

dog: Describe the animal that you see on these images...

# и т. д. для cat, motorcycle, bicycle

detectors:

tensorrt: # ← имя детектора (ссылаемся на него ниже)

type: tensorrt

device: 0 # ← индекс GPU (у нас единственный)

detect:

enabled: true

width: 1920 # ← фактическое разрешение DETECT-потока!

height: 1080

stationary:

interval: 50

threshold: 50

motion:

threshold: 40

contour_area: 25

improve_contrast: true

lightning_threshold: 0.8

birdseye:

enabled: true

mode: motion # ← режим «мозаика» по событиям движения

ffmpeg:

hwaccel_args: preset-nvidia-h264 # ← NVDEC + zero-copy → быстро и без CPU

output_args:

record: -f segment -segment_time 10 -segment_format mp4 -reset_timestamps 1 -strftime 1 -c:v copy -c:a aac

record:

enabled: true

retain:

days: 30

mode: motion

sync_recordings: true

alerts:

retain:

days: 90

detections:

retain:

days: 90

objects:

track:

- person

- car

- motorcycle

- bird

- cat

- dog

go2rtc:

streams:

Backyard:

- rtsp://login:password@192.168.99.37:554/stream1

- ffmpeg:Backyard#video=h264#hardware

cameras:

Backyard:

enabled: true

ffmpeg:

inputs:

- path: rtsp://tapocamera:tapocamera@192.168.99.37:554/stream1

input_args: preset-rtsp-generic

roles: [detect]

motion:

mask: # ← полигоны, где движение игнорируем

- 0.002,0.042,0.32,0.045,0.321,0.004,0.001,0.002

# … (остальные координаты урезал для краткости)

Что тут важно:

• detectors – указываем, что используем детектор типа tensorrt (Nvidia TensorRT) под именем nvidia. Параметр device: 0 означает использовать первый GPU (если у вас несколько видеокарт, можно указать соответствующий индекс). Frigate автоматически подхватит CUDA/TensorRT, если контейнер запущен правильно.

• model – путь и параметры модели. Мы нацелились на YOLOv7-640, поэтому путь указывает на файл yolov7-640.trt (который сгенерируется в директории /config/model_cache/tensorrt внутри контейнера). Параметры width/height должны совпадать с размером сети (640x640). Остальные настройки (input_tensor, pixel_format) стандартны для YOLO моделей (формат входного тензора nchw и rgb). Если вы решите использовать другую модель (например, yolov7-tiny-416), не забудьте здесь поменять пути и размеры.

• cameras – секция с описанием камер. В примере добавлена одна камера cam1.

  • ffmpeg.inputs – список потоков для этой камеры. Указан RTSP URL основного потока (stream1). У большинства IP-камер RTSP-поток формата rtsp://<user>:<password>@<ip>:554/<название_потока>. В некоторых камерах основной поток – H.264, в других – H.265. В нашем примере указан пресет preset-nvidia-h264 для аппаратного декодирования H.264 на GPU Nvidia. Если ваша камера выдает H.265, замените на preset-nvidia-h265 (RTX 3050 аппаратно поддерживает и тот, и другой кодек). Роли detect и record означают, что мы используем один и тот же поток и для детекции объектов, и для записи. (При наличии у камеры второго, субпотока низкого разрешения, можно отправлять его на детектор, а основной – только на запись. Для простоты здесь оба роли на одном потоке.)

  • detect – параметры детекции для этой камеры. Важно указать реальное разрешение видеопотока (width и height), чтобы Frigate знал, какого размера кадры ожидать. Параметр fps ограничивает скорость анализа – 5 кадров/с обычно достаточно для уверенного определения движения и объектов, не тратя лишние ресурсы. Если поставить слишком высокий fps, будете зря грузить и GPU, и CPU (обработка видео).

  • record – включает запись видео. В данном случае настроена непрерывная запись только при движении (так работает Frigate по умолчанию при включенном режиме recordings с events): при обнаружении события он сохранит сегмент видео, начиная за pre_capture секунд до события и заканчивая через post_capture секунд после. Мы сохраняем записи 7 дней (параметр retain.days). Длительность и поведение записей можно гибко менять, но выходят за рамки данной статьи.

  • snapshots – включает сохранение снимков с обнаруженными объектами. Frigate сделает и сохранит кадр с пометкой (рамкой) каждого события. Также храним 7 дней для примера.

После прописывания конфигурации, сохраняем config.yml и перезапускаем контейнер Frigate (docker compose restart frigate). Зайдите в веб-интерфейс (порт 5000) – там должна появиться ваша камера. Если всё сделано правильно, поток видео будет идти плавно, а при появлении в кадре людей, машин или других объектов – они выделятся рамками с подписью класса и процентом уверенности. Также в разделе Events начнут появляться записи с событиями движения.

objects:

track:

- person

- car

- cat
- dog

6. Первые грабли: ошибки и уроки

Как ни старайся, а без косяков настройка не обходится. Расскажу о своих “граблях” – возможно, сберегу чьи-то нервы:

• Грабли №1:
  Забытый драйвер NVIDIA. Я так увлёкся пробросом GPU, что при первом запуске контейнеров увидел в логах Frigate: "no CUDA capable device found". Оказалось, внутри Ubuntu я не доустановил драйвер (думал, в образе Frigate уже всё есть – но образ-то видит только /dev/nvidia*, а драйвер – это модуль ядра!). Пришлось экстренно ставить apt install nvidia-headless-525 и перезапускать VM. После этого nvidia-smi появился, и Frigate успешно подхватил GPU. Вывод: не забываем про драйвер в гостевой ОС.

• Грабли №2:
  Неправильный образ Frigate. Сначала по привычке потянул blakeblackshear/frigate:stable (обычный). Он, конечно, запустился, но тут же завалил CPU – ведь модель детекции работала на процессоре. Я-то ждал, что GPU поможет, ан нет – нужно же tensorrt версия! Ошибка быстро нашлась, контейнер переключил на stable-tensorrt, но потерял час на скачивание нового образа (~6 ГБ). Вывод: используйте правильный тег образа для вашего ускорителя.

• Грабли №3:
  Мало памяти. Я сперва дал VM только 4 ГБ RAM, думал “для Linux хватит”. И правда, Frigate себе брал ~500 МБ, ffmpeg чуть, да система ~1Гб – норм. Но стоило включить semantic_search, как память улетела в своп. Модель CLIP (даже small) + база данных + кэш – жрали около 6 ГБ. Добавил до 12 ГБ – стало лучше, но при старте LLaVA всё равно подпёрло. В итоге 16 ГБ — впритык, но хватает (пиково видел 12 ГБ usage при описании сразу нескольких кадров). Вывод: не жалейте RAM, лучше с запасом.
  Если у вас 8 ГБ или меньше – или не включайте эти фичи, или готовьтесь к тормозам.

• Грабли №4:
  Долгая генерация описаний. Первые попытки с LLaVA 13B иногда не давали результата: событие проходит, а описания нет. Оказалось, таймаут 60 сек и конкурентные запросы. Если, например, 3 события одновременно, Frigate кидает 3 запроса, а Ollama (по умолчанию) обрабатывает их последовательно. В результате последний может не уложиться в минуту и Frigate его бросит. Решение простое: я ограничил частоту детекций (FPS 5, плюс задержка между детектами по настройкам Frigate), и в реальной жизни редко более 1 объекта сразу появляется. Так что проблема минимизировалась.
  Вывод: не перегружайте GenAI запросами, это не real-time штука.

  Конечно, были еще мелочи, но перечислил основные, над которыми повозился. К счастью, сообщество Frigate активное: многие вопросы находил на Github Discussions и Reddit. Стоило погуглить ошибку – почти всегда кто-то уже спрашивал, и либо автор (Blake Blackshear), либо другие пользователи помогали с советом.

Краткий чек-лист по настройке для Лиги Лени

Ниже я свёл основные шаги и настройки в короткий список. Если решитесь повторить подобное у себя, пройдитесь по чек-листу – всё ли учтено:

1. Proxmox и железо: убедиться, что включен IOMMU/VT-d в BIOS. Прописать в /etc/default/grub нужные опции (intel_iommu=on или amd_iommu=on). Добавить видеокарту в vfio (в Proxmox /etc/modprobe.d/blacklist.conf добавить blacklist nouveau и blacklist nvidia, а в /etc/modules загрузить модули vfio). Перезапустить хост.

2. Создание VM: UEFI BIOS (OVMF), Machine type q35, vga: none, добавить устройство PCIe (GPU и связанный с ним аудиоконтроллер). Дать достаточное RAM (не меньше 8 ГБ, лучше 16). CPU type host, cores – по потребности. Диск – побольше под видео или подмонтировать сетевой/NAS.

3. Установка гостевой ОС: Поставить Ubuntu 22.04 (или Debian 12) внутри VM. Обновить систему. Установить NVIDIA драйвер (рекомендуемый проприетарный). Проверить nvidia-smi.

4. Установка Docker: Поставить Docker engine и docker-compose plugin. Настроить nvidia-container-toolkit (sudo apt install nvidia-container-toolkit && sudo nvidia-ctk runtime configure && sudo systemctl restart docker).

5. Подготовка Docker Compose: Создать docker-compose.yml с двумя сервисами – frigate и ollama (см. пример выше). Убедиться, что указан правильный image для Frigate (stable-tensorrt) и runtime: nvidia для обоих. Настроить volume и порты. Добавить tmpfs и shm.

6. Конфиг Frigate: Написать config.yml. Обязательные секции: detectors (указать type: tensorrt), model (путь к файлу .trt модели и размеры), cameras (вставить RTSP ссылки, роли, параметры детектора, объекты, маски и т.д. как нужно). При необходимости – mqtt (если использовать MQTT), detect общие настройки (например, максимальное количество одновременно отслеживаемых объектов, я не менял, по дефолту ок).

7. Запуск Compose: docker-compose up -d. Проверить логи: docker logs frigate -f – должны появиться сообщения о старте, подключении камер, инициализации детектора без ошибок. docker logs ollama -f – убедиться, что API запущен (может висеть в ожидании запросов).

8. Первый тест: Зайти в веб-интерфейс Frigate – http://<IP_VM>:8971. Создать пользователя/пароль (первый запуск). Увидеть камеры (должны отображаться превью потоков). Помахать рукой в зону видимости – убедиться, что событие фиксируется, появляется bounding box "person" на видео.

9. Проверка AI-описаний: Открыть вкладку Explore в UI Frigate. Найти последнее событие с объектом, посмотреть – появляется ли под ним текстовое описание. Если нет – проверить docker logs frigate на наличие ошибок GenAI (возможно, проблема с подключением к Ollama).

10. Оптимизация: Поправить пороги, маски, fps, если слишком много/мало срабатываний. Оценить загрузку: nvidia-smi – посмотреть, сколько памяти занято, нагрузка (Decoder, Encoder, Compute). docker stats – нет ли контейнеров с зашкаливающим CPU (в идеале CPU низкий, GPU берёт нагрузку).

11. Оповещения: Настроить желаемый способ уведомлений – MQTT, Home Assistant, Telegram-бот или просто email. Для Telegram: создать бот через BotFather, получить токен, написать скрипт (либо использовать готовые интеграции, например, Home Assistant Notify).

12. Резерв: Настроить автозапуск Compose при перезагрузке (можно через restart: unless-stopped уже сделано, но сам Docker должен стартовать; на Ubuntu это по умолчанию). Резервное копирование конфигов и, возможно, базы Frigate (файл frigate.db – содержит события и embeddings).

13. Мониторинг: Желательно настроить мониторинг дискового пространства (чтобы видеоархив не переполнил диск). Frigate умеет удалять по retain настройкам, но на всякий случай.

14. Обновление: Следить за апдейтами Frigate. Например, подписаться на релизы в GitHub или форум. Обновлять образ и конфиг по необходимости.

Фух, внушительный список. Но когда делаешь по шагам, всё не так страшно.

Выводы

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

Конечно, за всё платим ресурсами: RTX 3050 не скучает – где-то 50–60% её вычислительной мощи постоянно в деле (детекция + AI). Электричество тоже тратится, но я посчитал: в простой мой сервер потребляет ~50 Вт, под нагрузкой ~120 Вт. За возможности, которые я получил, меня это устраивает.

Зато никакой абонентской платы сервисам и никаких проблем с приватностью. Все видеоданные остаются дома, в зашифрованном хранилище. Да и просто это было весело – настроить кучу технологий воедино: Docker, AI, FFmpeg, MQTT, etc.

Что дальше? Буду играться с более продвинутыми моделями (может попробую YOLO-NAS – хвалят за точность). Также подумываю прикрутить распознавание лиц (есть же локальные модели типа InsightFace), но это уже другая история. Frigate пока распознаёт только тип объектов, а не кто именно. Но с помощью дополнений и Home Assistant можно и это реализовать, если очень надо.

Буду благодарен за ваше участие, и планирую писать ещё =)

Например, в следующей статье могу рассказать об автоматическом управлении котлом отопления через Home Assistant и Node-Red.

Картинка для затравки:

P.S.

Т.к. на пикабу до сих пор не прикрутили нормальных код-сниппетов, прикрепляю репозиторий c конфигами из статьи.

Будут вопросы - задавайте, отвечу по мере возможности =)

Ну ладно, шутки шутками, а давайте всё же попробую.

Итак, начнем с общей информации для тех, кто не в теме. Что за звери этот Mi Home и кто такой Home Assistant? И зачем что-то куда-то перетаскивать?

Mi Home - это такое приложение от компании Xiaomi, в которое можно добавлять различные устройства умного дома от Xiaomi же. Этих устройств компания наплодила вагон и маленькую тележку, отличаются невысокой ценой и, внезапно, вполне достойным качеством. Тут вам и датчики дыма, и умный свет, и увлажнители с пылесосами и ещё черт знает что с хвостиком.

Стоит при этом всё это вполне разумных денег. Ну, имхо конечно же.

Процесс взаимодействия с умным домом Xiaomi происходит следующим образом - вы покупаете, например, робот-пылесос. Скачиваете приложение Mi Home на свой телефон, следуете нехитрой инструкции и вуаля - ваш пылесос резко умнеет, и умеет уже убираться по расписанию, убирать зоны квартиры и разве что кофе вам в постель с утра не приносит.

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

ВСЕ ваши умные девайсы за редким исключением смотрят во внешнюю сеть, чтобы взаимодействовать с серверами Xiaomi, что само по себе является не очень-то приятным фактом.

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

Чтобы решить эту проблему умные люди, собравшись с мыслями и покурив документацию на девайсы (а где-то и отреверсив прошивки девайсов) начали писать своё, открытое ПО для умного дома - а именно, Home Assistant, Domoticz и ещё кучу всяких разных. Суть этих решений заключается как раз в том чтобы отвязать ваши умные девайсы от злобных китайских серверов и управлять ими вне зависимости от того доступны они или нет.

Рассказывать я буду на примере своего "умного дома". И рассказывать именно про Home Assistant, потому что именно его и удалось успешно запилить.

Итак, что имеем на старте.

22 умных девайса, а именно: робот-пылесос, два шлюза Xiaomi, пачку разных лампочек, 3 датчика движения, датчик протечки и датчик дыма, датчики температуры и влажности. А также 2 увлажнителя и умную розетку для обогревателя. В Mi Home это выглядит как-то так:

Собственно, процесс добавления девайсов в приложение обычно не вызывает особых вопросов и отдельно его освещать я не буду.

Чтобы начать втаскивать всё это хозяйство в Home Assistant, вам понадобится:

1. Базовое знакомство с linux. Всё конфигурирование (по крайней мере основное) Home Assistant сводится к редактированию его конфиг-файла. Вас не должны пугать такие слова как docker, shell, daemon, логи и т д.

2. Наличие raspberry pi 3 b+ либо Intel Nuc. На самом деле, подойдет любой свободный ПК дома, но учтите, что он должен быть включен 24/7, и желательно иметь на борту встроенный Bluetooth.

3. Карточка microSD для Raspberry Pi 3b+. Крайне желательна побыстрее по скорости. Тут уж смотрите сами.

4. Wifi-роутер. У меня mikrotik hap ac v2, возможно будете использовать другой, но роутер должен быть. И он должен поддерживать 2.4 ГГц wifi.

5. Наличие Xiaomi Gateway 2. Нужен если планируете использовать датчики Xiaomi же, и прочие девайсы умного дома работающие по протоколу Zigbee.

Обратите внимание, что нужна именно вторая версия. Шлюз Aqara не подойдет, он не умеет переключаться в dev mode. Выглядит как-то так:

6. Наличие прямых рук и умения искать в гугле. Серьезно, искать в гугле - очень пригодится.

Итак, с чего бы начать. Наверное с настройки Raspberry Pi. Для сокращения размеров статьи я буду приводить ссылки на имеющуюся документацию в сети, по которой я сам проводил настройку.

Шаг 1.

Вы купили несколько девайсов, и купили Raspberry Pi 3b+. Для начала нужно установить на него операционную систему Raspbian 10. Вот этот гайд довольно неплохо описывает процесс. Вкратце - скачиваете NOOBS образ для Raspberry, заливаете его на SD карту и вставляете в девайс. По сути это вся установка ОС. Гайд немного устарел, поэтому качайте последние версии, у меня стоит Raspbian 10.

Шаг 2.

Конфигурирование установленной ОС. Как минимум вам понадобится docker для того чтобы завести на нём Home Assistant. Заходите по SSH на IP адрес Raspberry Pi, делаете sudo su и далее следуете этому гайду. Учтите, что архитектура Raspberry Pi armhf, в гайде есть места для сниппетов, где надо выбирать целевую архитектуру. У меня помнится были какие-то танцы с бубном при установке докера, но с помощью п.6 требований (умение гуглить, помните, да?) всё решилось)

Шаг 3

Установка непосредственно Home Assistant. Тут в принципе ничего сложного нет, но нужно повнимательнее читать документацию и делать всё строго по гайдам. По ссылке github-репозиторий со скриптами установки. По сути установка сводится к банальной команде:

curl -sL https://raw.githubusercontent.com/home-assistant/supervised-... | bash -s -- -m raspberrypi3-64

Ждём с полчаса, после чего пробуем зайти по адресу http://RASPBERRY_IP:8123

Если получилось, то нам удалось установить Home Assistant.

Шаг 4

URL с портом - некрасиво. Давайте поставим nginx? Делается это так:

sudo apt update
sudo apt install nginx-full

После чего надо проследовать в директорию /etc/nginx/sites-available и создать там файл hassio с вот таким содержимым (когда на пикабу можно будет вставлять код сниппеты?):

map $http_upgrade $connection_upgrade {

default upgrade;

'' close;

}

server {

listen 80;

client_max_body_size 32M;

large_client_header_buffers 4 16k;

location / {

proxy_pass http://127.0.0.1:8123;

proxy_set_header Host $host;

proxy_http_version 1.1;

proxy_set_header X-Forwarded-For $proxy_add_x_forwarded_for;

proxy_set_header Upgrade $http_upgrade;

proxy_set_header Connection $connection_upgrade;

}

access_log /var/log/nginx/access.log;

error_log /var/log/nginx/error.log crit;

}

ln -s /etc/nginx/sites-available/hassio /etc/nginx/sites-enabled/
systemctl restart nginx

После этих операций можно будет уже заходить на вебморду Home Assistant по URL http://RASPBERRY_IP (без порта в конце!)

Собственно, после входа home assistant предложит вам изменить имя пользователя/пароль по умолчанию, не забудьте сделать это.

Дико извиняюсь, но устал я что-то набивать эту простыню текста, продолжу завтра-послезавтра. Сегодня мы более-менее научились настраивать Raspberry Pi и худо-бедно установили на него home assistant)

Во второй части рассмотрим настройку шлюза Xiaomi, добавление его в Home Assistant и расскажу для чего там может понадобится паяльник. При условии, конечно, что эта статья зайдет)