10.11.2025 06:12
Razumdom 23 2900 Источник

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

Поэтому, мы решили создать DRM88ER – интернет-реле "Разумный дом", которое решает эту проблему довольно изящно — просто собрав MODBUS, MQTT и WEB в одном устройстве за 14 500 рублей. Посмотрим, что из этого получилось.

Почему промышленный IoT до сих пор головная боль

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

Датчики/исполнители → MODBUS RTU по RS-485

Контроллеры → MODBUS TCP через Ethernet

SCADA системы → Проприетарные протоколы

Облачные сервисы → MQTT/HTTP

Пользователи → WEB/мобильные приложения

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

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

DRM88ER собирает все протоколы в одной коробке

Единое регистровое пространство

Ключевая особенность DRM88ER — все интерфейсы работают с едиными MODBUS-регистрами:

Физические I/O ←→ MODBUS Registers ←→ Все протоколы связи

↓                          ↓                                   ↓

8 входов            IR/DI/HR/Coils           MQTT/TCP/RTU/WEB/REST

8 выходов            (единая карта)           (параллельный доступ)

Это означает, что команда из MQTT мгновенно отражается в MODBUS TCP, а изменение состояния входа одновременно доступно через все интерфейсы.

Практический пример мультипротокольного мониторинга

Рассмотрим мониторинг температуры в серверной с резервированием каналов связи:

Python • Мультипротокольный мониторинг температуры

# Чтение через MODBUS TCP
from pymodbus.client.sync import ModbusTcpClient

client = ModbusTcpClient('192.168.1.100')
result = client.read_input_registers(11, 1, unit=1)
temperature = result.registers[0] / 10

# Публикация в MQTT
import paho.mqtt.client as mqtt

mqtt_client = mqtt.Client()
mqtt_client.connect("iot.company.com", 1883)
mqtt_client.publish("factory/server-room/temperature", 
                   temperature, qos=1, retain=True)

# REST API для корпоративных систем
import requests

requests.post("https://api.company.com/sensors/data", 
              json={"temperature": temperature, "source": "drm88er"})

# WEB-интерфейс доступен из коробки по http://192.168.1.100

Кейс — умная насосная станция

Рассмотрим внедрение DRM88ER на насосной станции водоснабжения с 4 насосами, частотными преобразователями и облачным мониторингом.

Архитектура решения
Архитектура решения

Программирование логики управления

Встроенный язык сценариев позволяет реализовать алгоритм управления без внешнего ПЛК:

DRM88ER Script • Каскадное управление насосами

# Каскадное управление насосами
0: MB_IN SlaveID=10; Func=IR; Reg=1; Result=IR20; Period=1000ms # Опрос датчика давления
1: MB_IN SlaveID=11; Func=IR; Reg=1; Result=IR21; Period=1000ms # Опрос общего расхода
2: IR30 = (IR20 - 400) * IR21 / 1000 # Расчет требуемой производительности
3: IF IR30 > 0 AND IR30 <= 250 THEN GOSUB 10    # 1 насос
4: IF IR30 > 250 AND IR30 <= 500 THEN GOSUB 20  # 2 насоса
5: IF IR30 > 500 AND IR30 <= 750 THEN GOSUB 30  # 3 насоса
6: IF IR30 > 750 THEN GOSUB 40                  # 4 насоса
   # MQTT топики публикуются автоматически:
   # factory/pumps/pressure → IR20
   # factory/pumps/flow → IR21
   # factory/pumps/power → IR30
5: GOTO 0
# Подпрограммы управления насосами
10: MB_OUT SlaveID=1; Func=HR; Reg=1; Value=IR30; Period=500ms # Подпрограммы управления насосами
11: RETURN

Что получилось в итоге

Результат превзошел ожидания. Во-первых, энергопотребление упало на 23% — алгоритм каскадного управления оказался намного эффективнее ручного включения насосов. Во-вторых, внедрение заняло всего 2 дня вместо обычных 2-3 недель с классическими ПЛК — просто потому что не пришлось настраивать кучу отдельных устройств.

А еще, сэкономили около 60 000 рублей на оборудовании, не покупая отдельные MODBUS-шлюзы, MQTT-клиенты и промышленные контроллеры. А главное — теперь все управляется из одного места, будь то веб-интерфейс, SCADA или мобильное приложение через MQTT.

Ключевое

  • ✅ Мультипротокольность — одно устройство заменило 4 разных компонента

  • ✅ Встроенные сценарии — алгоритм управления работает локально, без зависимости от сети

  • ✅ Режим Modbus Master — DRM88ER сам опрашивает датчики и управляет частотниками

  • ✅ Облачная интеграция — данные автоматически попадают в систему мониторинга

  • ✅ Отказоустойчивость — при сбое одного протокола работают остальные

RGB-освещение

Рассмотрим конкретный кейс из дока устройства – управление RGB-диммером DDL84R и мониторинг датчика MSU44RL через MQTT-интерфейс DRM88ER.

Архитектура MQTT-решения

Состав системы:

  • DRM88ER — центральный MQTT-контроллер (адрес 34)

  • MSU44RL — датчик освещенности (адрес 1)

  • DDL84R — RGB-диммер для управления освещением (адрес 2)

  • MQTT брокер — облачный или собственный сервер

? Все устройства (DRM88ER, MSU44RL, DDL84R) — разработка компании "Разумный дом"

Краткий обзор устройств экосистемы

MSU44RL — специализированный датчик освещенности с интерфейсом RS-485 MODBUS RTU. Компактный корпус, высокая точность измерений и простое подключение делают его идеальным для систем автоматического освещения.

DDL84RP — 4-канальный RGBW диммер с ШИМ-выходами 7А×24В на канал. Поддерживает частоту от 10Гц до 4кГц, имеет 8 входов для датчиков, встроенные сценарии, RTC и таймеры для сложной логики управления освещением.

Настройка MQTT-топиков

DRM88ER автоматически создает структурированные топики для публикации и подписки:

MQTT • Структура топиков DRM88ER

# Структура топиков MQTT
(Корневая тема)/(Клиент)/(Компонент)
# Примеры топиков для публикации (от DRM88ER в облако):
factory/sensors/light          # Освещенность с датчика
factory/lighting/status        # Состояние освещения
# Примеры топиков для подписки (команды в DRM88ER):
factory/lighting/red/set       # Управление красным каналом
factory/lighting/green/set     # Управление зеленым каналом
factory/lighting/blue/set      # Управление синим каналом

Конфигурация Modbus Master в DRM88ER

Для работы с внешними устройствами DRM88ER настраивается в режиме Modbus Master:

DRM88ER Script • Modbus Master конфигурация

# Автоматический опрос датчика освещенности MSU21+L
1: MB_IN SlaveID=1; Func=IR; Reg=19; Count=1; Result=IR30; Period=1000ms   # Читаем освещенность каждую секунду   # Результат сохраняется в IR30
# Управление диммером DDL84R  
2: MB_OUT SlaveID=2; Func=HR; Reg=1; Value=IR33; Period=500ms  # RED
3: MB_OUT SlaveID=2; Func=HR; Reg=2; Value=IR34; Period=500ms  # GREEN  
4: MB_OUT SlaveID=2; Func=HR; Reg=3; Value=IR35; Period=500ms  # BLUE

Интеграция с MQTT Explorer

Для тестирования и отладки используется MQTT Explorer — удобный инструмент для работы с топиками:

Команды управления через MQTT:

Установка яркости красного:

Топик: factory/lighting/red/set Значение: 512 (0-1023, где 1023 = 100%)

Чтение освещенности:

Топик: factory/sensors/light Формат: {"value": 850, "unit": "lux", "timestamp": 1640995200}

Преобразование данных и суффиксы

DRM88ER работает с целыми числами, но поддерживает автоматическое преобразование через суффиксы:

DRM88ER • Настройка суффиксов и преобразований

# Настройка суффиксов в WEB-интерфейсе
Освещенность: суффикс "1;lux"  → значение 850 отображается как 850 lux
Яркость:      суффикс "0.1;%"   → значение 512 отображается как 51.2%
# Эти же коэффициенты применяются к MQTT-топикам автоматически

Практическая ценность MQTT-интеграции

Какие возможности это открывает? Интеграция с облачными системами — данные можно передавать в любые внешние системы через MQTT-брокеры. Мобильные уведомления настраиваются через Telegram или Push-notifications за пару минут. Голосовое управление через Алису или Google Assistant можно подключить через внешние интеграции. Удаленный доступ работает из любой точки мира через MQTT-подключение. ?

Преимущества мультипротокольного подхода

Экономическая эффективность

Один DRM88ER заменяет несколько специализированных устройств:

Классическое решение

Стоимость

DRM88ER

Стоимость

MODBUS RTU/TCP шлюз

8 000₽

Встроено

0₽

MQTT клиент

12 000₽

Встроено

0₽

WEB-сервер

5 000₽

Встроено

0₽

Программируемый контроллер

15 000₽

Встроено

0₽

ИТОГО

40 000₽

DRM88ER

14 500₽

Отказоустойчивость

При использовании нескольких протоколов система становится более устойчивой:

Python • Отказоустойчивый сбор данных

def robust_data_collection():
    """Отказоустойчивый сбор данных"""
    
    # Приоритет 1: MODBUS TCP
    try:
        return read_modbus_tcp('192.168.1.100', register=11)
    except Exception as e:
        logger.warning(f"MODBUS TCP недоступен: {e}")
        
        # Приоритет 2: REST API
        try:
            return read_rest_api('192.168.1.100', '/inputir.json?A=11&B=1')
        except Exception as e:
            logger.warning(f"REST API недоступен: {e}")
            
            # Приоритет 3: кэшированное значение из MQTT
            return get_cached_mqtt_value('factory/sensors/temperature')

Сравнение с промышленными решениями

Параметр

DRM88ER

Siemens SIMATIC IoT2050

Schneider EcoStruxure

Цена

14 500₽

~80 000₽

~60 000₽

MODBUS из коробки

Да

Требует настройки

Да

MQTT нативно

Да

Через Node-RED

Да

WEB-интерфейс

Готовый

Разработка

Готовый

Время внедрения

1-2 дня

1-2 недели

3-5 дней

Техподдержка

На русском

Переводная

Переводная

Взгляд в будущее

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

Что показал этот опыт?

Во-первых, унификация интерфейсов действительно упрощает архитектуру — вместо множества устройств получается одно универсальное.

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

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

Комментарии (23)


  1. Litemanager_remoteadmin
    10.11.2025 06:18
    #29087590

    Экономия конечно значительная получилась, выглядит очень перспективно, для освещения в магазине или на предприятиях и т д


  1. Sfinx88
    10.11.2025 06:18
    #29087632

    Статья сгенерирована с помощью ChatGPT. Вы настолько не уважаете потенциальных покупателей?


    1. EmCreatore
      10.11.2025 06:18
      #29088372

      А мне нравятся статьи от DeepSeek. Кратко и по делу. Без этой графоманской воды.

      Спасибо автору за ссылку на IOT2050.
      Довольно необычный дивайс для Сименса.
      Это не ПЛК с входами-выходами. Это шлюз для ардуинщиков!

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

      Кстати, в этот шлюз можно вставить самые навороченные и при этом дешевые 5G модемы с алика, в нем есть слот для SIM карты.
      В этот же шлюз можно втавить терабайтные карты памяти и накапливать данные за всю жизнь работы всей системы.

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

      А у автора получился недоделанный ПЛК. Шлюзом он не может быть по определению. В условиях мировой кибервойны это будет просто первой целью для атаки и мамкиных хакеров. Тут даже HTTP не защищен. Где-нить в европах за продажу такого дивайса фирму бы прикрыли.
      А ведь могли бы сделать нормально. Случись теперь что с этими насосами будут явные признаки саботажа.


      1. Razumdom Автор
        10.11.2025 06:18
        #29091286

        А что должно быть у доделанного ПЛК? Напишите, может быть доделаю.
        Шлюзом он не является и любые данные на любые протоколы не передает. Это мультипротокольный модуль Интернета вещей.
        До банковского уровня защиты далеко, но HTTP имеет защиту MD5 с логином и паролем, MQTT с логином и паролем, даже ModbusTCP с перечнем разрешенных адресов.
        Мамкины хакеры не залезут, только хорошо обученные папкины.


        1. tklim
          10.11.2025 06:18
          #29091812

          но HTTP имеет защиту MD5 с логином и паролем, MQTT с логином и паролем.

          заканчивался 2025 год, а шутка “The S in IoT stands for security”  все так же не шутка.

          Надеюсь, у вас ethernet коммуникация реальзована на отдельном от управляющего контроллера?


        1. nafikovr
          10.11.2025 06:18
          #29097596

          А что должно быть у доделанного ПЛК?

          IEC 61131

          HTTP имеет защиту MD5 с логином и паролем

          HTTP? вы серьезно?


          1. Razumdom Автор
            10.11.2025 06:18
            #29100044

            Когда я писал язык для сценариев, я взял за основу язык IL (список инструкций) из ГОСТ МЭК 61131-7. Инструкции сценариев и ещё много других элементов соответствуют этому ГОСТу. Так что именно нужно доделать?
            Защита конечно не банковского уровня, но попробуйте её взломать. И это с учетом целесообразности действий. Устройство предназначено для мониторинга и управления климатикой и не передаёт личные банковские данные.
            Это похоже на массивную железную дверь с десятью замками, но закрытую на щеколду. Попробуйте её открыть, а если откроете, увидите только термометр в этой комнате. Для сложного шифрования нужен мощный процессор, а здесь небольшой микроконтроллер.


            1. nafikovr
              10.11.2025 06:18
              #29100438

              Инструкции сценариев и ещё много других элементов соответствуют этому ГОСТу. Так что именно нужно доделать?

              Если речь о языках, то там их 5 и все должны поддерживаться. Но как бы речь не только о языках. Как минимум все сценарии по обеспечению надежности


        1. EmCreatore
          10.11.2025 06:18
          #29100050

          Начнем с того что ваш контроллер к облакам и IoT не имеет никакого отношения.
          Ни одни облака не позволят подключиться к себе без TLS 2.0 минимума.
          Что вам мешало реализовать TLS?
          Не разобрались в API ESPэшек?
          Или тот же интерпретатор LUA или Python что мешало интергрировать?
          Помяти не хватило? Выбрали самый дешевый микроконтроллер в семействе?

          Хотя конечно есть WiFi роутеры с VPN туннелем, и можно утверждать, что трафик защищен если он идет от дивайса чисто по WiFi с WPA3
          Но тогда надо предупреждать пользователей, что за дешевым контроллером, должен еще стоять дорогущий специализированный роутер.


          1. Razumdom Автор
            10.11.2025 06:18
            #29100590

            Конечно наше устройство не облако и не имеет к нему отношение. Устройство лишь передает в облачный MQTT брокер публикации. И конечно использует условия брокера, TLS подключение, соответствующий порт. Специально залез в программу и посмотрел, в стеке LWIP используется ALTCP_TLS.
            Остальным системам диспетчеризации ничего не мешает использовать протоколы ModbusTCP или REST API или др.
            На интерпретатор LUA памяти хватило бы, но вопрос, кто на нем будет писать программу? Устройство ориентировано на интеграторов, а не программистов. Я даже назвал это Сценарии или Скрипты, а не программа.
            Использование микроконтроллера вместо микропроцессора это вопрос целесообразности для выполнения конкретной задачи.
            Это устройство использует Ethernet, причем здесь WiFi? С WiFi тоже есть устройства, собранные на ESP32, но здесь о них речь не идет.


            1. EmCreatore
              10.11.2025 06:18
              #29100714

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


    1. RazzleDazzle
      10.11.2025 06:18
      #29091200

      Комментарий и ник Sfinx88 сгенерированы с помощью ChatGPT. 
      А Razumdom - реальные пацаны из Тулы.
      У меня их реле бойлером 5 лет управляет


    1. AlexeySerge
      10.11.2025 06:18
      #29091202

      Как вы определили, что это сгенерированный контент? И как вы определили, что это именно ChatGPT? А какая конкретно модель ChatGPT?


  1. alex_Cl
    10.11.2025 06:18
    #29087884

    Красиво сравнили себе с siemens по стоимости, а как с надёжностью ? Расскажите подробнее про электрическую развязку входов и выходов. В прошлом мне приходилось ремонтировать плк Siemens. Так вот они очень сильно упарываплись на развязке оных. Не ленились даже отдельные преобразователи питания ставить с развязкой через трансы. У Вас на плате ничего подобного не наблюдаю. Так что думаю таком сравнении по стоимости если доля лукавства.


    1. Razumdom Автор
      10.11.2025 06:18
      #29091414

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


      1. alex_Cl
        10.11.2025 06:18
        #29093220

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


        1. Razumdom Автор
          10.11.2025 06:18
          #29096428

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


  1. sav13
    10.11.2025 06:18
    #29089112

    Легко конкурировать с Сименсом, который ушел с рынка. Как планируете конкурировать с китайцами?

    У них полно таких железок по цене 2-4круб. У того же Ebyte.


    1. Razumdom Автор
      10.11.2025 06:18
      #29091340

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


  1. trofimovilua
    10.11.2025 06:18
    #29091418

    перспективное реле


    1. tklim
      10.11.2025 06:18
      #29091792

      новое слово в классификации реле. Переключает контакты, смотря в завтрашний день?


  1. Polos
    10.11.2025 06:18
    #29095626

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

    Лирика, теперь по делу.

    Какую нагрузку в RPS выдерживает железка?
    Сколько парметров(тегов) способна переварить всего?
    Есть ли deadband?
    Планируется ли поддержка opcua?
    Умеет ли буферизировать?


    1. Razumdom Автор
      10.11.2025 06:18
      #29100154

      Отвечу как понял вопросы.
      Устройство может отвечать на запрос по сети только одного клиента. Микроконтроллер не сервер и данные клиента не сохраняет. Если будет одновременно 10 запросов от разных клиентов, то устройство застрянет. Если нужно много клиентов, тогда нужно использовать облачный сервис.
      Параметров ровно столько, сколько заложено функций, не больше не меньше. Есть массив для переменных разного типа, можно их использовать.
      Задержка в локальной сети будет единицы миллисекунд и на глаз незаметна. Микроконтроллер работает на частоте 168МГц, но он не загружен множеством задач, ответит сразу.
      Когда всплывает слово OPC, сразу подразумевается использование сервера, даже не ПК, тем более не микроконтроллера. Нет. Только конкретные пртоколы.
      Конечно, все действия из разных интерфейсов производятся с внутренними регистрами, т.е. памятью. А это и есть буфер.