Первое сопряжение микроконтроллерного устройства с сетью — процесс захватывающий, однако превращается в сущий кошмар, когда его необходимо масштабировать на десятки или сотни узлов. Массовое развертывание парка однотипных контроллеров поглощает часы рутинного конфигурирования — время, которое инженеру хотелось бы посвятить более интеллектуальным и творческим задачам.
Для оптимизации этого процесса был создан легковесный 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, гибко адаптируемые под любые задачи — от простых сенсоров до узлов сложной автоматизации.

Первичная инициализация и 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 проекта.
Ключевые аспекты эксплуатации:
-
Bootstrap: При первом включении ESP создает точку доступа
192.168.4.1. После получения POST-запроса с параметрами контроллер перезагружается и подключается к целевой Wi-Fi сети и MQTT-брокеру. -
Hard Reset: В случае сбоя конфигурации предусмотрен физический сброс: удержание кнопки, подключенной к пину
D4, в течение 3+ секунд. -
Идентификация (SSDP name): Уникальный идентификатор устройства. Если поле оставить пустым, имя генерируется на базе MAC-адреса. Возможно переопределение метода
createMacAddress()для использования временных меток. -
MQTT_ROOT: При использовании публичных брокеров (например,
test.mosquitto.org) важно указывать уникальный UUID в качестве корня, чтобы исключить коллизии топиков.
Развитие функционала
Изначально предполагался статичный импорт настроек через CSV-файлы, но практика показала необходимость оперативного внесения правок.
Важный архитектурный нюанс: ESP-устройства функционируют независимо от сервера — они общаются исключительно с MQTT-брокером. Сервер, в свою очередь, выступает в роли «диспетчера», обрабатывающего топики согласно конфигурации
.env.
Обмен данными строится на двух топиках:
-
— публикация текущих статусов пинов./ /state -
— прием управляющих команд./ /action
Для оптимизации трафика установлена частота передачи 1 Гц (настраиваемо). Устройство считается «в сети», если от него поступали сообщения в течение последней минуты.
Безопасность и интерфейс
Регистрация девайсов автоматизирована: при обнаружении нового сообщения в топике сервер автоматически вносит устройство в БД.
Для защиты административного контура реализована авторизация, аналогичная Linux-системам: параметры доступа задаются через токен xtoken в конфигурационном файле сервера. Тот, кто владеет доступом к серверному конфигу, получает полный контроль над системой.
Функционал администратора:
-
Мониторинг детальной информации (аптайм, история обновлений).
-
Масштабируемая фильтрация устройств по MDNS/SSDP.
-
Интеграция списков оборудования через .csv.
-
Удаленное конфигурирование параметров устройств в режиме реального времени.

Ярусы развертывания (Deploy Tiers)
Проект поддерживает пять уровней масштабируемости инфраструктуры:
|
Tier |
Инфраструктура |
|---|---|
|
Tiny |
Базовый: только |
|
Small |
Добавление локального приватного MQTT-брокера. |
|
Medium |
Внедрение Apache Kafka, Kafdrop и специализированных обработчиков (kworker, ai-worker, hworker). |
|
Large |
Система мониторинга: Vector, VictoriaMetrics, Grafana. |
|
Huge |
Полный стек, развернутый в оркестраторе Kubernetes. |
Docker против Kubernetes
Для развертывания доступны два пути:
-
docker— охватывает ярусы от Tiny до Large. -
k8s— включает манифесты для кластера Minikube.
Kubernetes идеален для высокой доступности и автоматического самовосстановления, однако требует определенных знаний для настройки. Docker предоставляет унифицированные образы (amd64, arm64, arm), обеспечивая простоту запуска на чем угодно — от мощных ПК до плат Raspberry Pi.
Аналитика данных (Medium+)
При использовании яруса Medium, esp-server транслирует все события в шину Kafka, что позволяет вести долгосрочное логирование. В проекте предусмотрены три типа обработчиков (воркеров):
-
kworker: Агрегация данных и визуализация состояний.
-
ai-worker: Потоковый анализ данных с помощью ИИ для детекции аномалий.
-
hworker: Передача результатов обработки во внешние бизнес-процессы (например, n8n).
Такая модульная архитектура позволяет горизонтально масштабировать нагрузку в зависимости от количества событий.
Осциллограмма и мониторинг (Large+)
Связка Vector + VictoriaMetrics + Grafana позволяет превратить поток данных с пинов в полноценную инженерную телеметрию. Это дает возможность отслеживать дребезг контактов, строить графики переходных процессов и настраивать алертинг в реальном времени.
Начало работы
-
Убедитесь, что установлен Docker.
-
Скопируйте
my.env.exampleв.envв соответствующих директориях и укажите необходимые учетные данные. -
Запустите нужный ярус:
docker compose -f deploy/docker/[tier].yaml up -d.
Репозиторий и документация
Проект активно развивается, документация покрывает все этапы настройки и архитектурные решения.


_0_large.jpg)