Сторож на ESP32-CAM

Возникла следующая практическая задача: в ограниченном пространстве (узком коридоре, лестничном пролете или тамбуре), отследить активность, сделать фото пространства и уведомить пользователя, переслав фотографии в телеграм. При этом известно, что в месте наблюдения установлен бытовой датчик движения, который включает освещение.

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

В предыдущей части, посвященной созданию и развертыванию сервера для мониторинга семейства ESP устройств, был продемонстрирован опыт связывания популярных сервисов в объеме кластера Kubernetes. Были задействованы следующие сервисы:

• Firmware esp8266 / esp32 - прошивка микроконтроллеров, публикующая состояние микроконтроллеров на MQTT брокере, и получающая команды на изменение конфигурации.

• Mosquitto MQTT для реализации MQTT брокера, который принимает данные от семейства микроконтроллеров.

• Esp-server - ядро проекта, который при помощи клиентского приложения, посредством публичного API или посредством self-hosting web-админки мониторит и изменяет конфигурацию зарегистрированных микроконтроллеров.

• Клиентское приложение iOS - использует публичный API для первоначального конфигурирования esp устройств.

• Воркеры: kworker, ai-worker, hworker - внешние по отношению к esp-server сервисы, которые анализируют события Kafka, и соответствующим образом уведомляют пользователя (строят агрегированные таблицы изменения состояния микроконтроллеров, отслеживают аномальную активность, формируют webhook для уведомления внешних сервисов).

• Docker - в качестве хост-основы кластера на базе Minikube.

• Kafka - событийно-ориентированное хранилище.

• Kafdrop - Web интерфейс для мониторинга Kafka.

• Vector - для сопровождения протокола Prometheus.

• VictoriaMetrics - для сохранения временных рядов.

• Grafana - для графического отображения событий.

• Dashboard minikube - для административного управления Kubernetes.

• Скрипты деплоя и запуска кластера K8s.

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

• Hardware устройство на базе esp32-cam.

• Firmware esp32-cam устройства с несколькими базовыми сценариями.

• MinIO - файловое хранилище фотографий сделанных устройством esp32-cam.

• pworker - сервис, который извлекает уведомление о сохраненной фотографии из Kafka, и формирующий защищенную ссылку на фотографию к файловому хранилищу.

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

• телеграм-бот, демонстрирующий фотографии сделанные esp32-cam.

Общая схема передачи данных следующая:

Обсудим общую концепцию.

Если Вы только приступили к созданию Hardware устройства, то Вам, однозначно, покажется весь этот цирк неимоверно избыточным. Особенно, после упоминания Kubernetes. Но попробуйте задать себе вопрос, сколько времени и усилий будет потрачено Вами на реализацию функциональности за пределами Вашей зоны отвественности? Очевидно, что каждая новая фича требует погружение и разработки слоев от бизнес-логики (с чем, несомненно Вы легко справитесь), до публичного API и UI для управления Вашей бизнес-логикой сторонними пользователями. Время реализации растет экспоненциально. Это все, нужно потом еще конфигурировать, мониторить и управлять. И, в то же время, любой инженер знает состояние фонтана идей, которые хотелось бы реализовать в первую очередь. Использование промышленно - устоявшихся сервисов избавляет Вас от необходимости тратить время на разработку и отладку инженерных механизмов, тем самым позволяя посвятить себя творческим реализациям своих фантазий. А использование Kubernetes упрощает управление всем зоопарком - кластер запускается стартом одного единственного скрипта. К тому же, Вы вознаграждаетесь устойчивостью, ради которой Kubernetis и задумывался - у случае падения какого-либо сервиса — он будет автоматически перезапущен. А, потенциально, Вы можете масштабировать кластер на несколько независимых серверов в случае роста Вашего бизнеса и Ваши потребностей.

Такие компоненты как firmware, воркеры, клиент, esp-server и сценарии запуска - представлены в виде исходных кодов, которые Вы можете использовать "как есть" или модифицировать под свои нужды. Остальные сервисы - разработки сторонних производителей, которые приобрели репутацию промышленных стандартов, но, которые Вы можете использовать совершенно бесплатно и абсолютно легально. И, вместе с тем, не затрачивая времени на их отладку и обслуживание. На первый взгляд, сделать узкоспециализированный софт будет проще, но в действительности, такое решение окажется многократно дороже. Без сомнения, он будет меньше по объему, но многократно больше по стоимости и по приложенным усилиям.

Hardware

Esp32-cam отличается от своего собрата Esp32 количеством доступных контактов. И, почти все, задействованы в нашем проекте.

В данном случае, использовалась плата, которая имеет следующую схему пинов:

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

Для реализации "сторожа" задействованы следующие пины:

Право / лево - названо исходя из следующих соображений: если смотреть на модуль оптического датчика, то в нижней части платы имеется надпись "ESP32-CAM" в естественном (не перевернутом), положении.

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

У электронщика не вызывает удивления следующая информация, которая крайне необычна для разработчика ПО:

1. Необходим внешний источник питания 5V с силой тока не менее 1А. Поднятие WiFi и работа оптического датчика создает пиковую нагрузку, которая может приводить к перезагрузке устройства.

2. Так как используется внешнее питание, программатор подключается только RXD, TXD и GND (общий). DTR и 3V3 - не используются.

3. Нельзя использовать пины 3.3V и VCC микроконтроллера (и 3V3 программатора), так как они не обеспечивают нужную нагрузку.

4. При длительном хранении модуля ESP32-Cam защелка шины оптического датчика рассыхается, что приводит к невозможности его эксплуатации в силу механической деформации контактных площадок.

5. Для заливки прошивки на микроконтроллер, необходимо закоротить GPIO0 на GND, и дождаться начала заливки в Serial Monitor. Обратите внимание, что esp32 этого, как правило, не требует. Поэтому, если у Вас имеется опыт работы с esp32, но не было опыта с esp32-cam - здесь Вас ждет сюрприз. С обратной стороны платы, вверху слева, находится кнопка сброса, которую нужно нажать, для перевода платы в режим прошивки. При этом, нужно еще обеспечить соединение GPIO0 - GND. После завершения заливки GPIO0 следует отключить, после чего еще раз нажать на кнопку сброса (с обратной стороны микроконтроллера). Автор добавил к GPIO0 тактовую кнопку, которую удерживает до тех пор пока не начнется заливка. К сожалению, кнопка Reset не имеет выведенных пинов, поэтому, без подпайки невозможно подключить к ней тактовую кнопку.

6. Устройство заметно нагревается. Если есть возможность, используйте радиатор или медную пластину на текстолите для рассеивания избыточного тепла.

7. При постоянном включении оптического датчика (непрерывная фото / видео съемка) - оптический датчик выходит из строя за несколько часов. Автор убил модуль тремя часами непрерывного тестирования. При этом, esp32 остается в рабочем состоянии, но оптический датчик не подает признаки жизни.

Устройство не сохраняет информацию на флеш-карте, несмотря на то, что холдер имеется в наличии (с обратной стороны микроконтроллера), что дает возможность использовать GPIO14 для датчика освещенности.

GPIO4 - активирует лунно-белый светодиод, который можно использовать как фотовспышку. Имейте ввиду, что он вызывает нагрев и дает пиковое потребление мощности.

Firmware

Из-за ограничения на использование пинов, прошивка esp32 (из комплекта "Esp-monitor") была доработана. Исходный код размещен в каталоге firmware/esp32-cam.

Помимо изменения списка состояний задействованных пинов, отправляемых посредством MQTT от устройства к esp-server, были внесены следующие изменения:

• К перечню классов добавлены классы CameraManager (CoreCamera.cpp) и CaptureManager.

• Добавлена публикация в топик "photo" MQTT брокера.

• Добавлено чтение из сети и сохранение режима камеры в файле конфигурации.

• Добавлены три режима фотосъемки.

  • Снимок каждые 5 секунд

  • 3 снимка каждые 5 секунд

  • Снимок каждые 5 секунд в течение 20 секунд после активации устройства.

В целом, структура прошивки оставлена прежняя.

Чтобы избежать перегрева оптического датчика, фотография создается только в случае, если фоторезистор имеет минимальное сопротивление (достаточно света). Включение фотовспышки будет демаскировать устройство. Если такой подход Вас не устраивает, то, достаточно, закомментировать строчку проверки состояния фоторезистора в файле CoreCamera.cpp

if (capturer.isNight()) return nullptr;

esp-server

Исходный код сервера был расширен по следующим направлениям:

1) Добавлена поддержка файлового хранилища MinIO.

2) Добавлена обработка топика "photos", получение сериализированного изображения и отправка его в файловое хранилище MinIO.

3) Добавлена запись события в Kafka, топики "photos".

4) Добавлена секция конфигурации камеры в web-админку. Секция отображается только в том случае, если MDNS имя содержит суффикс "-cam".

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

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

pworker

pworker - новый компонент системы, который является посредником между Kafka и MinIO. Он отслеживает изменения топика "photos" Kafka, и если изменения обнаруживает, создает временную защищенную ссылку на созданный в файловой системе файл, и отправляет ее в N8n оркестратор, посредством HTTP Webhook. N8n скачивает бинарный файл из MinIO по внутренней сети Kubernetes (http://minio-service:9000), так как Telegram не может открыть внутренний presigned URL вида minio-service. Ссылка формируется таким образом, что может быть обработана только в указанный фрейм времени (в течение 15 минут) и только для указанного адреса хоста. Общая структура воркера такая же, как у других воркеров системы (kworker, ai-worker и hworker), и, соотвественно, может быть запущен во множестве экземпляров для разных семейств устройств, в случае если система будет масштабирована.

Deployment

Файл конфигурации infra.yaml был доработан таким образом, чтоб в систему инсталлировались third-party сервисы MinIO и N8n в момент первого запуска.

В скрипты запуска en-start-cluster и ru-start-cluster добавлены инструкции на запуск новых сервисов, и открытию их веб-админок по локальному (но внешнему для кластера) адресу. Так же добавлено открытие консольной сессии pworker.

MinIO

Представляет собой структурированное файловое хранилище. В целом, как и в любом древовидном файловом хранилище структура папок и файлов является произвольной. Однако, для улучшения доступа, все объекты записываются в рамках батчей ("batch"), которые представляют собой SSDN имена исходного устройства. Поэтому, если Вы оперируете несколькими камерами или устройствами, которые сохраняют файлы, то файлы можно будет легко найти по имени самого устройства, поскольку корень файловой системы будет соотвествовать SSDN имени. При помощи web-админки, файлы можно просмотреть или удалить.

Telegram

Понятно, что телеграм не входит в состав пакета "esp-monitor" даже в виде конфигурации, но в нем необходимо произвести определенные манипуляции, прежде чем рассматривать заключительный компонент "N8n". Telegram, в рамках данного проекта, выступает клиентским приложением, в которое пользователь получает информацию об активности со стороны "Сторожа". Для того, чтоб это стало возможным, необходимо проделать следующее:

1) При помощи BotFather (официального бота Telegram) создать телеграм-бота, который будет принимать фотографии. Для этого нужно:

1. В поиске телеграм вбить BotFather.

2. Войти в найденный чат @BotFather и стартовать бот.

3. Нажать кнопку "Start" внизу экрана.

4. При помощи команды /newbot создать нового бота, имя которого заканчивается на "_bot". Другие команды доступны при помощи команды /help.

5. При помощи кнопки "Open" (слева от поля ввода), открыть список созданных ботов.

6. Выбрать созданный бот и открыть меню конфигурации бота.

7. Скопировать и сохранить токен, размещенный в секретном поле в верхней части меню. Поле рядом с иконкой ключа.

2) При помощи бота "User Info" получить свой ID. Для этого нужно:

1. В поиске ввести userinfo. И Выбрать бот "User Info".

2. Нажать кнопку "Start" внизу экрана.

3. Получить список атрибутов текущего пользователя.

4. Скопировать и сохранить параметр id пользователя.

N8n

N8n - сервис, который позволяет создавать бесконечное количество сценариев автоматизации. Наш сценарий состоит в следующем:

1. Получить от pworker секретную ссылку на доступ к файлу.

2. Сделать HTTP GET-запрос для получения бинарных данных изображения.

3. Передать полученный файл в Telegram-bot.

В перспективе, можно добавить сценарии отправки фотографии на анализ в AI, и получить указания о действиях в соотвествии с определенной классификацией (поднять тревогу, включить энергооборудование, открыть замок и др.)

Сценарий уже сформирован, и находится в папке k8s (n8n-esp32-photo.json). Необходимо импортировать его при первом запуске N8n, после этого ввести сохраненные ранее параметры Telegram.

Для этого, после импорта сценария, нужно кликнуть по узлу "Telegram". Затем в поле Chat Id добавить id пользователя (с предыдущего шага). Вверху меню конфигурации найти кнопку, вызывающую меню с Credentials (в разных версиях N8n эта кнопка выглядит по-разному), и ввести полученный ранее токен. После этого закрыть меню, и в верхнем правом углу нажать кнопку Publish. Все, сценарий автоматизации будет доступен всегда после старта кластера.

Важное примечание по работе с n8n:

Начиная со свежих версий n8n, интерфейс использует концепцию среды разработки с разделением на черновик (Draft) и опубликованную версию (Published). Любые изменения, внесенные в UI, сохраняются как черновик и не будут обрабатывать реальные события от pworker до тех пор, пока вы не нажмете кнопку Publish в правом верхнем углу. Если кнопка активна, значит workflow зафиксирован в продакшене и готов принимать боевые Webhook-запросы.

Это сэкономит немало времени при отладке, так как по привычке многие ищут старый тумблер «Active» и не понимают, почему отредактированный сценарий не откликается на запросы.

Запуск кластера K8s

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

Установите Docker на компьютере, на котором будет разворачиваться кластер.

Запустите скрипт setup-k8s-cluster.sh Он выполнит все необходимые первичные настройки и загрузит последние версии бинарных компонентов. Дождитесь его завершения.

Запустите кластер при помощи скриптов en-start-cluster или ru-start-cluster.

Если Вы делаете это впервые - то необходимо отконфигурировать Telegram и N8n в соответствии с Вашими персональными настройками (см. раздел Telegram и N8n в данной статье).

Для повторного запуска (после перезагрузки hardware сервера) достаточно запустить сценарий запуска кастера en-start-cluster или ru-start-cluster и дождаться запуска всех сервисов.

В процессе отработки сценария запуска кластера, в браузере по-умолчанию открываются Web страницы следующих сервисов:

• Grafana

• Esp-server

• MinIO

• N8n

• Kafdrop

• Minikube

На старт каждого сервиса уходит определенное время, поэтому, до начала полноценной работы веб-страницы могут показывать пустое содержимое. Необходимо дождаться завершения процесса (не более 1 минуты). Процесс можно контролировать через Dashboard Minikube - когда все диаграммы станут полностью зелеными, можно обновить веб-страницы.

Если у Вас нет необходимости в мониторинге системы, то все открытые страницы можно безболезненно закрыть.

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

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

Подключение esp устройства.

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

1. Собрать и установить на iPhone/iPad iOS приложение. Задать в нем конфигурационные данные, и применить конфигурацию, пока устройство находится в режиме точки доступа. Конфигурационные данные сохраняются в приложении, поэтому, Вы можете быстро сконфигурировать множество устройств, по мере их активации. Исходный код находится в clients/iPhone.

2. Воспользоваться curl скриптом, расположенном в папке clients/curl. Внесите в него изменения в соответствии с Вашим вкусом. Для этого нужно предварительно переключить WiFi сеть на точку доступа самого устройства. Пароль точки доступа "1qazxsw2".

3. Воспользоваться клиентским приложением работы с REST API, например, Postman, выполнив POST запрос с параметрами, аналогичными тем, что указаны в curl-скрипте.

Заключение

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