Modbus → MQTT: как подключить промышленное оборудование к умному дому

На любом более-менее серьёзном объекте рано или поздно появляется оборудование, которое говорит на Modbus: адаптеры кондиционеров, приточно-вытяжные установки, счётчики, модули реле, датчики температуры и влажности, контроллеры котлов. Умный дом при этом живёт на MQTT. Два мира стоят рядом и друг друга не понимают — ровно эту стену и убирает мост Modbus → MQTT.

Ниже разберём, как устроены оба протокола, что именно делает мост и как настроить связку без единого конфиг-файла — на примере нашей бесплатной программы modbus2mqtt.

Что такое Modbus и шина RS-485

Modbus — открытый промышленный протокол, появившийся ещё в 1979 году и ставший де-факто стандартом для датчиков, реле, счётчиков и приводов. Работает он по схеме «мастер — слейв»: ведущее устройство опрашивает ведомые по их адресам и читает или записывает значения в регистры. Регистров четыре вида:

• Holding — регистры хранения, чтение и запись (уставки, режимы, целевая температура);
• Input — входные регистры, только чтение (измерения);
• Coil — дискретные выходы, чтение и запись (включить/выключить);
• Discrete — дискретные входы, только чтение (состояние контакта).

Передаётся Modbus чаще всего двумя способами. Modbus RTU — по последовательной шине RS-485: одна витая пара, к которой шлейфом подключаются десятки устройств, с настройками скорости, чётности и стоп-битов. Modbus TCP — поверх Ethernet, обычно на порту 502, либо через Ethernet-шлюз в режиме RTU-over-TCP, когда «сырые» RTU-кадры заворачиваются в TCP-соединение.

Важная особенность RS-485: на шине один мастер, и запросы идут строго по очереди. Нельзя опросить два устройства одновременно — можно только быстрее. Отсюда все практические ограничения: чем длиннее список регистров и чем ниже скорость, тем реже обновляются значения.

Что такое MQTT и почему умный дом живёт на нём

MQTT — лёгкий протокол обмена сообщениями по модели «издатель — подписчик», созданный для интернета вещей. Устройства не общаются напрямую: они публикуют значения в именованные топики на центральном сервере — MQTT-брокере, — а другие подписываются на эти топики и получают обновления мгновенно. Именно на MQTT построены Home Assistant, Node-RED, OpenHAB и наши контроллеры умного дома.

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

Зачем нужен мост и что он делает

Мост Modbus → MQTT переводит один мир в другой. Его работа складывается из четырёх шагов, и понимать их полезно даже если настраивать всё будете мышкой:

1. Опрос. Программа циклически читает регистры устройств. Внутри одного шлюза запросы идут строго последовательно — один мастер на шине, — а разные шлюзы опрашиваются параллельно. Период опроса задаётся для устройства целиком или для отдельного регистра.
2. Декодирование. «Сырой» регистр превращается в понятное значение по формуле значение = raw × множитель + смещение с учётом типа данных (int16, uint16, int32, float, string), порядка слов и байт и битовых масок.
3. Публикация. Значение уходит в топик вида {базовый}/{префикс устройства}/{ключ}. Флаг retain заставляет брокер хранить последнее значение и сразу отдавать его новым подписчикам — дашборд не будет пустым до следующего опроса.
4. Обратные команды. У каналов «чтение/запись» есть командный топик {топик}/set: то, что туда отправлено, немедленно встаёт первым в очередь и записывается в устройство. Управление получается практически мгновенным, а не «через полный цикл опроса».

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

Как настраивается: три шага в браузере

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

Шаг 1. Шлюз. Описывается соединение с шиной: TCP-адрес Ethernet-шлюза (Modbus TCP или RTU-over-TCP) либо локальный последовательный порт /dev/ttyUSB0 со скоростью, чётностью, стоп-битами и таймингами. Шлюзов может быть несколько — например, одна шина в щите на первом этаже, другая в котельной.

Шаг 2. Устройство. Выбирается готовый шаблон из библиотеки или создаётся своё с ручным описанием регистров. Указывается slave-адрес и MQTT-префикс, под которым устройство появится в топиках.

Шаг 3. Брокер. Вводятся адрес MQTT-брокера, порт, логин и пароль, TLS, базовый топик и правила retain. После включения публикации значения сразу уходят в топики, а команды — обратно в устройства.

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

Библиотека готовых устройств

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

В библиотеке больше тридцати устройств, среди них:

• Климат: адаптеры кондиционеров ONOKOM GR-1 / HR-1, адаптер Haier YCJ-A002, приточно-вытяжная установка GTC;
• Реле и диммеры: Wiren Board WB-MR6C и WB-MR6CU, 16-канальное реле RS-485 с командными регистрами, WB-MDM3, WB-LED, шлюз WB-DALI3;
• Датчики: РЭЛСИБ ДВТ-05.RS, мультидатчик WB-MSW v.4, модули DS18B20 и AHT20 на RS-485;
• Отопление и аналог: контроллеры ectoControl (OpenTherm, eBus, Navien), аналоговые выходы WB-MAO4.

Дашборд и отладка

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

Для отладки есть терминал Modbus: живой лог обмена с HEX-кадрами, длительностью каждого запроса и ошибками. Когда устройство «молчит», именно он отвечает на главный вопрос — доходит ли запрос вообще, отвечает ли слейв с ошибкой или ответ приходит, но декодируется не так. Без такого инструмента отладка новой железки превращается в гадание.

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

Практические советы по шине

Несколько вещей, которые экономят время на объекте:

• Адресация. Slave-адреса на шине должны быть уникальны. Два устройства с одинаковым адресом дают «плавающие» ответы, которые выглядят как случайные сбои связи.
• Скорость и период опроса. На 9600 бод длинный список регистров опрашивается заметно дольше, чем на 115200. Если значения обновляются с задержкой — сначала посмотрите на число включённых параметров, потом на скорость.
• Терминаторы и топология. RS-485 — это шлейф, а не звезда. Согласующие резисторы ставятся на концах линии; «ветки» и лишние терминаторы дают ошибки CRC, особенно на длинных линиях.
• Порядок слов и байт. Для 32-битных значений производители используют разный порядок. Если температура вместо 23,5 показывает нечто астрономическое — почти наверняка дело в нём, а не в датчике.
• Масштабы. Многие устройства отдают температуру целым числом ×10 или ×100. Множитель и смещение как раз для этого: сырое значение 235 превращается в 23,5 °C.

Установка

Программа ставится одним .deb-пакетом как системный сервис на Debian, Ubuntu и производные, включая Raspberry Pi и другие одноплатники. Есть сборки под amd64, arm64 и armhf, внешних зависимостей нет — данные хранятся в SQLite рядом. Рекомендуемый способ — подключить APT-репозиторий, тогда обновления приходят вместе с системой:

curl -fsSL https://repo.um-d.ru/elx-repo.gpg | sudo tee /usr/share/keyrings/elx-repo.gpg >/dev/null
echo "deb [signed-by=/usr/share/keyrings/elx-repo.gpg] https://repo.um-d.ru stable main" \
  | sudo tee /etc/apt/sources.list.d/elx.list
sudo apt update && sudo apt install elxmodbusmqtt -y

После установки сервис стартует сам, веб-интерфейс открывается на http://localhost:8080. Состояние и логи смотрятся обычными средствами systemd: systemctl status elxmodbusmqtt и journalctl -u elxmodbusmqtt -f.

Интеграция с умным домом

Поскольку данные публикуются в стандартный MQTT-брокер, любое промышленное Modbus-оборудование становится частью умного дома. Home Assistant подхватывает топики через MQTT-интеграцию, Node-RED строит на них сценарии, наши контроллеры и мобильное приложение видят их как обычные устройства. Типичная связка на объекте выглядит так: шина RS-485 с оборудованием → modbus2mqtt на объектовой машине → локальный MQTT-брокер → сценарии, дашборды и приложение.

Такой мост особенно выручает там, где нужно подружить «взрослое» инженерное оборудование с жилым интерфейсом: приточка, тепловые узлы, счётчики, промышленные реле в щите. Оно уже стоит, оно уже умеет Modbus — не хватало только переводчика.

Итог

modbus2mqtt — бесплатная программа без ограничений, которую можно использовать в том числе в коммерческих проектах: ставить на объектах заказчиков, в щитах и на собственных серверах. Она снимает с интегратора самую скучную часть работы — опрос, декодирование и публикацию — и оставляет ему то, ради чего всё затевалось: сценарии и удобство жильцов.

Скачать программу, посмотреть скриншоты всех разделов и библиотеку устройств можно на modbus2mqtt.ru. Остальные наши бесплатные инструменты собраны на странице «Полезное».