Удаленный мониторинг электросети на ESP32, MQTT и Linux-сервере

Удаленный мониторинг электросети можно построить из безопасного измерительного модуля, ESP32, MQTT-брокера и Linux-сервера, который хранит показатели и отправляет уведомления. Контроллер получает напряжение, ток, мощность или накопленную энергию, передает телеметрию по MQTT, а сервер сохраняет историю и строит графики просадок, отключений и роста нагрузки.

ESP32 нельзя подключать к сети 220 В напрямую. Между сетевой частью и GPIO должен стоять готовый изолированный измерительный модуль, счетчик с цифровым интерфейсом либо бесконтактный трансформатор тока. Самодельные неизолированные делители, макетные платы и монтаж в электрощите без квалификации здесь неуместны: ошибка в измерительной части не должна нарушать электрическую изоляцию или работу защитной автоматики.

Какие события должна фиксировать система мониторинга

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

Одного текущего значения мало. Если техника перезагрузилась ночью, утром на экране снова будут привычные 228–232 В, а событие уже потеряно. Поэтому сервер должен сохранять минимум, максимум, время выхода за порог и момент восстановления. Отдельно стоит передавать RSSI Wi-Fi, uptime ESP32, счетчик перезапусков и статус измерительного модуля. Фраза специалиста здесь простая: «нет телеметрии» и «нет напряжения» — разные аварии.

До покупки оборудования задайте для каждой метрики единицу измерения, период опроса, частоту публикации и условие тревоги. Это покажет требуемый набор данных и нагрузку на базу.

Безопасная архитектура: от измерительного модуля до сервера

ESP32 должен получать сведения о сети только через изолированный измерительный узел или безопасный цифровой интерфейс. Рабочая цепочка выглядит так: электросеть → измерительный модуль → ESP32 → Wi-Fi или Ethernet → MQTT-брокер → обработчик → база данных → Grafana и уведомления.

В роли измерительного узла используют готовый счетчик с RS-485 и Modbus RTU, изолированный модуль с UART, импульсный выход электросчетчика или трансформатор тока. RS-485 задает физический интерфейс, а Modbus — протокол обмена; сами по себе они не гарантируют гальваническую развязку. Изоляция должна быть предусмотрена счетчиком или преобразователем и подтверждена документацией. Контроллер читает безопасный сигнал, проверяет данные и передает их на сервер.

До заказа модуля стоит нарисовать всю цепочку и отметить точки отказа: питание измерителя, ESP32, Wi-Fi, брокер, обработчик и диск. Так проще заранее увидеть, где система потеряет данные при отключении питания или связи.

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

Как выбрать датчик или измерительный модуль

Готовые цифровые измерительные модули

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

RS-485 позволяет отнести измеритель от ESP32, а Modbus RTU — читать данные как регистры. Если в документации нет карты регистров, описания изоляции, параметров порта и схемы подключения, модуль лучше отсеять до монтажа, а не разбирать протокол уже в щите.

Бесконтактное измерение тока

Трансформатор тока удобен, когда провод нельзя разрывать или требуется только оценка нагрузки. Он охватывает один проводник и отделяет измерительную часть от силовой, но подключать его нужно по документации конкретной модели: для некоторых типов опасен разомкнутый вторичный контур. Сам по себе датчик не дает напряжение, коэффициент мощности и активную энергию; потребуются дополнительные измерения и калибровка.

Что проверить до покупки

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

Настройка ESP32: опрос, фильтрация и публикация данных

Считывание и проверка показаний

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

Напряжение и мощность обычно публикуют раз в несколько секунд, накопленную энергию — заметно реже. Частота зависит от минимальной длительности события, которое нужно поймать. Интервал 10 секунд не покажет просадку длиной две секунды, зато не создаст поток из десятков тысяч записей за сутки. Сначала определяют нужную детализацию графика, потом выставляют частоту записи — не наоборот.

Формат MQTT-сообщений

Единый JSON удобен для согласованного набора параметров с одним временем измерения, а отдельные топики — для простых подписок. Практичный вариант: телеметрия в JSON, доступность и события отдельно. Для регулярных показаний часто хватает QoS 0. QoS 1 снижает риск потери, но допускает повторную доставку, поэтому обработчик должен отбрасывать дубли по идентификатору устройства и времени измерения.

{
  "voltage": 229.4,
  "current": 1.82,
  "power": 397,
  "energy": 12.74,
  "frequency": 50.0,
  "rssi": -61,
  "uptime": 86420,
  "status": "ok"
}

home/power/main/telemetry
home/power/main/status
home/power/main/event
home/power/main/availability

В сообщение стоит добавить идентификатор устройства, версию прошивки, синхронизированный через NTP timestamp, uptime и счетчик перезапусков. Эти поля упрощают разбор разрывов и странных значений.

Поведение при потере Wi-Fi

Контроллер должен переживать перезапуск роутера и остановку брокера без ручного вмешательства. Типичный сбой: Wi-Fi уже вернулся, а MQTT-клиент остался в старом состоянии, поэтому сеть и брокер восстанавливают независимыми циклами. При неожиданном разрыве брокер публикует заранее заданное Last Will-сообщение offline; после подключения ESP32 отправляет retained-статус online. Зависание контролирует watchdog.

Если потеря истории критична, ESP32 буферизует измерения и отправляет их после восстановления связи. Каждой записи нужен исходный timestamp, иначе сервер примет старые показатели как новые.

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

Где разместить MQTT-брокер и как развернуть Mosquitto

Локальный компьютер, мини-сервер или удаленный Linux-сервер

MQTT-брокер лучше размещать там, где он сможет работать круглосуточно и независимо от пользовательского компьютера. Домашний ПК удобен для теста, но после выключения мониторинг останавливается. Мини-ПК, NAS или Raspberry Pi не зависят от рабочего места, однако остаются связанными с домашним питанием и интернетом.

Удаленный Linux-сервер принимает данные от нескольких объектов и продолжает хранить историю, даже если домашний компьютер выключен. Для системы, которая собирает телеметрию постоянно, брокер, базу и панель можно разместить на отдельном сервере; ориентиры по конфигурации Linux-сервера собраны на сайте UkrLine. При выборе важнее не запас процессора, а стабильность, резервное копирование, свободное место под базу и возможность закрыть лишние порты.

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

Установка и базовая проверка Mosquitto

sudo apt update
sudo apt install mosquitto mosquitto-clients
sudo systemctl enable --now mosquitto
sudo systemctl status mosquitto

После установки сначала проверяют брокер локально, не открывая порт наружу:

mosquitto_sub -h 127.0.0.1 -t 'home/power/#' -v

Во втором терминале публикуют тест:

mosquitto_pub -h 127.0.0.1 -t 'home/power/test' -m 'online'

Если подписчик получил сообщение, базовая цепочка работает. Состояние сервиса смотрят через systemctl status mosquitto, журнал — через journalctl -u mosquitto, слушающие порты — командой ss -lntp. Основная конфигурация находится в /etc/mosquitto/mosquitto.conf, дополнительные фрагменты удобно хранить в /etc/mosquitto/conf.d/.

Системный сервис и сетевой доступ

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

Как хранить показатели и строить графики

MQTT передает сообщения, но не заменяет базу данных для долговременной истории. Брокер может удерживать последнее retained-сообщение, однако он не предназначен для запросов вида «покажи минимальное напряжение за неделю» или «сравни потребление по дням».

Обработчик MQTT-сообщений

Для небольшого проекта удобна цепочка Mosquitto → Telegraf или Node-RED → InfluxDB → Grafana. Python-сервис с PostgreSQL сложнее, но дает полный контроль над валидацией JSON, дублями и журналом ошибок.

Обработчик запускают как systemd-сервис либо контейнер с политикой автоперезапуска. Если mosquitto_sub показывает сообщения, а график пуст, датчик уже ни при чем: проверяют обработчик, очередь записи и журнал базы. Логи должны различать ошибку payload, отказ базы, потерю соединения и дубль.

База временных рядов

Запись раз в секунду дает 86 400 точек в сутки на один поток. Для нескольких параметров и устройств объем быстро растет, поэтому заранее задают retention policy, агрегацию старых данных и резервное копирование. Для подробной диагностики можно хранить сырые значения неделю, минутные агрегаты — несколько месяцев, часовые — дольше.

Полезно хранить timestamp ESP32 и время приема сервером: их разница показывает задержку, работу буфера и проблемы часов.

Панель Grafana

На панели достаточно вывести напряжение, ток, мощность, энергию, время последней связи и статус узла. Графики минимума и максимума полезнее декоративных индикаторов. Результат проверяют просто: новое MQTT-сообщение появляется в базе, график обновляется, временная зона совпадает с реальной, а перезапуск обработчика не создает дыр и дублей.

Уведомления об отключении, скачках и пропаже контроллера

Пороговые события

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

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

Контроль отсутствия телеметрии

Если ESP32 обесточен, сервер обнаруживает отключение по отсутствию heartbeat, а не по сообщению «питание пропало»: контроллер не успеет его отправить. Сервер запоминает время последней телеметрии и формирует тревогу, когда превышено предельное время ожидания.

Метод имеет ограничение: одинаково выглядит полное отключение электричества, потеря Wi-Fi, зависание ESP32 и обрыв интернета. Разделить причины помогают Last Will, RSSI перед обрывом, счетчик загрузок после восстановления, доступность других устройств и резервное питание роутера с ESP32.

Защита от ложных срабатываний

Тест уведомлений проводят управляемо: останавливают публикацию MQTT, отключают Wi-Fi, подают тестовое значение за пределами порога и возвращают систему в норму. Для каждого случая должно прийти одно сообщение о начале и одно о восстановлении.

Защита MQTT и проверка стабильности всей системы

Пароли, ACL и закрытый анонимный доступ

Публичный MQTT-брокер нельзя оставлять без аутентификации и разграничения топиков. Для начала отключают анонимный доступ, создают отдельные учетные записи и задают ACL. Один ESP32 должен публиковать только в собственную ветку, а панель мониторинга — читать только нужные топики.

sudo mosquitto_passwd -c /etc/mosquitto/passwd power-node
sudo systemctl restart mosquitto
sudo journalctl -u mosquitto -n 50

Ключ -c используют только при первом создании файла паролей; при добавлении следующих пользователей его убирают, иначе файл можно перезаписать. В конфигурации задают allow_anonymous false, password_file и acl_file.

user power-node
topic write home/power/main/#

После перезапуска подключение без логина должно отклоняться, а пользователь — не иметь возможности публиковать в чужую ветку.

TLS и сетевые ограничения

Для доступа через интернет применяют TLS, VPN либо listener, ограниченный firewall. Открывать незашифрованный порт всему миру ради удобства ESP32 — плохая практика. TLS требует DNS-имени, корректного сертификата и времени на контроллере; без синхронизации NTP проверка сертификата может ломаться после перезагрузки.

Firewall проверяют через ufw status или nft list ruleset, порты — через ss -lntp, TLS — через openssl s_client. Базы и служебные панели не публикуют наружу без отдельной защиты.

Финальная диагностика

Готовую систему проверяют не по красивому графику, а по контролируемым отказам. После перезагрузки Linux Mosquitto, обработчик, база и Grafana должны запуститься автоматически. ESP32 обязан переподключиться, Last Will — корректно отработать, а алерт — прийти один раз без потока дублей.

1. Нет данных от ESP32 — проверить питание, Wi-Fi, RSSI и Serial Monitor.
2. ESP32 подключен, но MQTT пуст — проверить DNS, порт, логин, TLS и имя топика.
3. Сообщение видно в mosquitto_sub, но его нет в базе — смотреть журнал обработчика.
4. Запись есть, но график пуст — проверить источник Grafana, запрос и диапазон времени.
5. График работает, но нет алерта — проверить порог, длительность, cooldown и канал отправки.
6. Есть случайные разрывы — сопоставить по времени логи ESP32, Mosquitto, обработчика и сети.

Перед постоянной эксплуатацией стоит пройти практический чек-лист:

• ESP32 электрически отделен от сети безопасным измерительным модулем.
• Диапазон измерения соответствует реальной нагрузке, а показания сравнены с контрольным прибором.
• Ошибки датчика не превращаются в нули, а публикуются отдельным статусом.
• В MQTT передаются timestamp, uptime, RSSI, статус и счетчик перезапусков.
• Настроены Last Will, heartbeat и автоматическое переподключение.
• Mosquitto включен в автозапуск, а анонимный доступ отключен.
• ACL ограничивает публикацию и чтение топиков.
• Публичный трафик защищен TLS или VPN, firewall пропускает только нужные соединения.
• Обработчик запускается через systemd или restart policy контейнера.
• Для базы заданы политика хранения, резервное копирование и контроль свободного диска.
• Проверены отключение Wi-Fi, брокера, датчика и питания; после восстановления система работает без ручного перезапуска.

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