Esp-Monitor: архитектура и развертывание собственной IoT-платформы для ESP-микроконтроллеров

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

Для оптимизации этого процесса был создан легковесный Open Source сервис с рабочим названием «esp-monitor».

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

Одним из самых востребованных и бюджетных решений (стоимостью около $2) является Wemos D1 Mini на чипе ESP8266. Высокая производительность, надежность и обширная экосистема периферии сделали его стандартом в индустрии DIY и системах умного дома.

Тем не менее, процедура их настройки крайне неудобна: наличие только Wi-Fi модуля «на борту» вынуждает каждый раз заниматься кропотливой отладкой подключения к беспроводной сети.

Попытки решить эту задачу через проброс портов (port forwarding) обычно заводят в тупик по ряду причин:

  • требуются административные привилегии в сети роутера;

  • необходимо поддерживать уникальные доступы к устройствам, находящимся за NAT;

  • отсутствует централизованное управление — с каждым узлом приходится взаимодействовать индивидуально;

  • возникают серьезные риски для безопасности инфраструктуры.

Более элегантный подход — использование внешнего MQTT-брокера. Устройство инициирует исходящее соединение, транслирует свое состояние и ожидает управляющих команд.

MQTT (Message Queuing Telemetry Transport) — легковесный двунаправленный протокол для передачи данных. В отличие от тяжеловесных WebSockets, он не требует постоянного «удержания» канала, что делает его эталонным выбором для IoT. Брокер можно развернуть на любом микрокомпьютере, в облаке или воспользоваться публичными бесплатными серверами.

Архитектура Esp-Server

Сервис управления esp-server реализован на Go с использованием SQLite в качестве базы данных. Он легко разворачивается в Docker-контейнерах или компилируется под любую современную ОС (Windows, Linux, macOS).

Система обеспечивает централизованное управление конфигурациями: от параметров Wi-Fi, MDNS и SSDP до настроек MQTT-подключений. Основную логику работы конечного устройства инженер может реализовать стандартными средствами MQTT.

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

Esp-Monitor: архитектура и развертывание собственной IoT-платформы для ESP-микроконтроллеров
Схема взаимодействия компонентов через MQTT-брокер.

Первичная инициализация и API

Взаимодействие с esp-server реализовано через REST API и интуитивно понятный веб-интерфейс.

Для сопряжения микроконтроллеров можно задействовать нативное iOS-приложение (исходники в открытом доступе). Оно позволяет передать конфигурационные параметры на устройство в режиме точки доступа одним нажатием. При этом для владельцев Android-устройств или при необходимости автоматизации предусмотрен универсальный способ через cURL-запрос (POST):

Bash

curl -X POST 192.168.4.1:80/config \
  -H "Content-Type: application/json" \
  -d '{
  "WIFI_SSID": "",
  "WIFI_PASS": "wi-fi pass",
  "MDNS": "",
  "SSDP": "SSDP name",
  "HTTP_PORT": "80",
  "MQTT_HOST": "",
  "MQTT_PORT": "1883",
  "MQTT_USER": "",
  "MQTT_PASS": "",
  "MQTT_ROOT": ""
  }'

Примеры запросов доступны в директории ./clients/curl проекта.

Ключевые аспекты эксплуатации:

  1. Bootstrap: При первом включении ESP создает точку доступа 192.168.4.1. После получения POST-запроса с параметрами контроллер перезагружается и подключается к целевой Wi-Fi сети и MQTT-брокеру.

  2. Hard Reset: В случае сбоя конфигурации предусмотрен физический сброс: удержание кнопки, подключенной к пину D4, в течение 3+ секунд.

  3. Идентификация (SSDP name): Уникальный идентификатор устройства. Если поле оставить пустым, имя генерируется на базе MAC-адреса. Возможно переопределение метода createMacAddress() для использования временных меток.

  4. MQTT_ROOT: При использовании публичных брокеров (например, test.mosquitto.org) важно указывать уникальный UUID в качестве корня, чтобы исключить коллизии топиков.

Развитие функционала

Изначально предполагался статичный импорт настроек через CSV-файлы, но практика показала необходимость оперативного внесения правок.

Важный архитектурный нюанс: ESP-устройства функционируют независимо от сервера — они общаются исключительно с MQTT-брокером. Сервер, в свою очередь, выступает в роли «диспетчера», обрабатывающего топики согласно конфигурации .env.

Обмен данными строится на двух топиках:

  • //state — публикация текущих статусов пинов.

  • //action — прием управляющих команд.

Для оптимизации трафика установлена частота передачи 1 Гц (настраиваемо). Устройство считается «в сети», если от него поступали сообщения в течение последней минуты.

Безопасность и интерфейс

Регистрация девайсов автоматизирована: при обнаружении нового сообщения в топике сервер автоматически вносит устройство в БД.

Для защиты административного контура реализована авторизация, аналогичная Linux-системам: параметры доступа задаются через токен xtoken в конфигурационном файле сервера. Тот, кто владеет доступом к серверному конфигу, получает полный контроль над системой.

Функционал администратора:

  • Мониторинг детальной информации (аптайм, история обновлений).

  • Масштабируемая фильтрация устройств по MDNS/SSDP.

  • Интеграция списков оборудования через .csv.

  • Удаленное конфигурирование параметров устройств в режиме реального времени.

Веб-интерфейс администратора
Веб-интерфейс администратора

Ярусы развертывания (Deploy Tiers)

Проект поддерживает пять уровней масштабируемости инфраструктуры:

Tier

Инфраструктура

Tiny

Базовый: только esp-server + внешний MQTT-брокер.

Small

Добавление локального приватного MQTT-брокера.

Medium

Внедрение Apache Kafka, Kafdrop и специализированных обработчиков (kworker, ai-worker, hworker).

Large

Система мониторинга: Vector, VictoriaMetrics, Grafana.

Huge

Полный стек, развернутый в оркестраторе Kubernetes.

Docker против Kubernetes

Для развертывания доступны два пути:

  1. docker — охватывает ярусы от Tiny до Large.

  2. k8s — включает манифесты для кластера Minikube.

Kubernetes идеален для высокой доступности и автоматического самовосстановления, однако требует определенных знаний для настройки. Docker предоставляет унифицированные образы (amd64, arm64, arm), обеспечивая простоту запуска на чем угодно — от мощных ПК до плат Raspberry Pi.

Аналитика данных (Medium+)

При использовании яруса Medium, esp-server транслирует все события в шину Kafka, что позволяет вести долгосрочное логирование. В проекте предусмотрены три типа обработчиков (воркеров):

  • kworker: Агрегация данных и визуализация состояний.

  • ai-worker: Потоковый анализ данных с помощью ИИ для детекции аномалий.

  • hworker: Передача результатов обработки во внешние бизнес-процессы (например, n8n).

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

Осциллограмма и мониторинг (Large+)

Связка Vector + VictoriaMetrics + Grafana позволяет превратить поток данных с пинов в полноценную инженерную телеметрию. Это дает возможность отслеживать дребезг контактов, строить графики переходных процессов и настраивать алертинг в реальном времени.

Начало работы

  1. Убедитесь, что установлен Docker.

  2. Скопируйте my.env.example в .env в соответствующих директориях и укажите необходимые учетные данные.

  3. Запустите нужный ярус: docker compose -f deploy/docker/[tier].yaml up -d.

Репозиторий и документация

Проект активно развивается, документация покрывает все этапы настройки и архитектурные решения.

 

Источник

Читайте также