Главная → Академия → Датчики и входы: нормализация сигналов → Pull vs Push: модели получения данных от датчиков

Pull vs Push: модели получения данных от датчиков

Урок 2 · Датчики и входы: нормализация сигналов · 30 мин · theory

Введение в модели получения данных

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

Это модели получения данных, которые определяют, кто является инициатором обмена информацией: контроллер или само периферийное устройство.

> 📋 Ключевые понятия:

> Модель Pull (Опрос): Контроллер (Master) активно и периодически запрашивает* (pulls) данные с устройства (Slave).

> Модель Push (Подписка/Уведомление): Устройство (Publisher) самостоятельно отправляет* (pushes) данные контроллеру (Subscriber) при возникновении события.

Чтобы понять разницу, представьте себе простую бытовую аналогию.

Выбор между этими моделями напрямую влияет на три важнейших аспекта вашей системы:

  • Отзывчивость: Как быстро система автоматизации отреагирует на событие, например, на нажатие кнопки.
  • Нагрузка на сеть/шину: Какой объем трафика генерирует система. Избыточный трафик на шине RS-485 или в сети Ethernet может привести к задержкам и потере данных.
  • Производительность контроллера: Насколько сильно загружен центральный процессор контроллера постоянными запросами и обработкой ответов.

    • Осознанный выбор модели в зависимости от типа задачи (критичное управление или фоновый мониторинг) отличает профессионального инсталлятора от новичка.

    ---

    Модель Pull (Опрос): активный запрос данных

    Модель Pull, или опрос (polling), является классическим и наиболее распространенным подходом в промышленной автоматизации. В этой модели контроллер выступает в роли «хозяина» (Master или Client), а оконечные устройства — в роли «ведомых» (Slave или Server).

    Принцип работы предельно прост и строг:

  • Контроллер по внутреннему таймеру (например, каждые 500 мс) решает, что ему необходимо получить данные от устройства с адресом X.
  • Он формирует и отправляет на шину данных или по сети специальный пакет-запрос: "Устройство X, сообщи мне значение из твоего регистра Y".
  • Устройство X, получив запрос, считывает значение из своей памяти и отправляет пакет-ответ контроллеру.
  • Контроллер получает ответ, обрабатывает его и ждет следующего тика таймера, чтобы повторить цикл.

    • Важно понимать, что устройство никогда не инициирует связь первым. Оно всегда находится в пассивном режиме ожидания запроса.

    Типичные протоколы, использующие Pull-модель:

    Преимущества модели Pull

    Недостатки модели Pull

    Высокая латентность (задержка): Самый главный недостаток. Если событие (например, нажатие кнопки, подключенной к Modbus-модулю) произошло сразу после очередного опроса, система узнает о нем только при следующем* опросе. Если интервал опроса равен 1 секунде, то средняя задержка реакции составит 0.5 секунды, а максимальная — целую секунду. Для управления освещением это может быть неприемлемо.

    > ⚠️ Внимание: Слишком частый опрос (низкий интервал) может перегрузить как шину данных (например, RS-485), так и центральный процессор контроллера HI. Всегда ищите баланс между скоростью реакции и системной нагрузкой. Начинайте с больших интервалов (5-10 секунд) и постепенно уменьшайте их, контролируя стабильность системы.

    ---

    Модель Push (Подписка): асинхронные уведомления

    Модель Push, или событийная модель, работает по прямо противоположному принципу. В этой архитектуре устройства становятся активными участниками процесса. Они сами принимают решение об отправке данных.

    Принцип работы основан на паттерне "Издатель-Подписчик" (Publisher-Subscriber):

  • При запуске системы контроллер "подписывается" на интересующие его события от устройств. Он как бы говорит: "Устройство Y, если у тебя изменится состояние кнопки, пожалуйста, сообщи мне об этом".
  • Контроллер переходит в режим пассивного прослушивания. Он ничего не отправляет и не тратит ресурсы на генерацию запросов.
  • Устройство Y самостоятельно отслеживает свое состояние. В момент, когда происходит событие (кнопку нажали), оно формирует и отправляет контроллеру сообщение-уведомление.
  • Контроллер немедленно получает это сообщение и запускает соответствующий сценарий автоматизации (например, включает свет).

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

    Типичные протоколы, использующие Push-модель:

    Преимущества модели Push

    Недостатки модели Push

    > 💡 Подсказка: В Node-RED используйте узел RBE (Report-by-Exception), чтобы отфильтровывать дублирующиеся сообщения от "болтливых" устройств, работающих по модели Push. Этот узел пропускает сообщение только в том случае, если его значение (`msg.payload`) отличается от предыдущего. Это базовый приём для защиты от "шторма сообщений".

    ---

    Практика в Node-RED: Pull (Modbus) vs Push (MQTT)

    Давайте наглядно увидим разницу между двумя моделями, создав два простых потока в среде Node-RED на контроллере HI. Для этого нам понадобится сторонний Modbus-модуль с дискретным входом и любое устройство, способное отправлять MQTT-сообщения (например, смартфон с MQTT-клиентом или другая система).

    Поток 1: Pull-модель через Modbus

    Задача: Каждые 2 секунды опрашивать состояние дискретного входа №1 (адрес регистра 0) на Modbus-модуле с ID=1. Создание потока:
  • Возьмите узел `Inject` и настройте его на автоматический запуск каждые `2` секунды. Это наш таймер для опроса.
  • Добавьте узел `Modbus-Read` (в некоторых версиях он может называться `Modbus-Getter`).
  • В настройках узла `Modbus-Read` создайте или выберите сервер, указав параметры вашей шины RS-485 (порт, скорость, как было рассмотрено ранее).
  • Заполните параметры запроса:

    • * `Unit-ID`: `1` (адрес нашего модуля на шине)

    * `FC`: `FC 2: Read Discrete Inputs` (чтение дискретных входов)

    * `Address`: `0` (адрес первого входа)

    * `Quantity`: `1` (читаем состояние одного входа)

  • Соедините выход узла `Inject` со входом `Modbus-Read`.
  • Подключите узел `Debug` к выходу `Modbus-Read`, чтобы видеть результат.
    • Схема потока (ASCII): 
    [Inject: every 2s] ----> [Modbus-Read: UnitID=1, Addr=0] ----> [Debug]

    После развертывания потока вы увидите в панели отладки, что каждые 2 секунды появляется новое сообщение, даже если вы ничего не делаете с входом на Modbus-модуле.

    Пример `msg.payload` от узла Modbus: 
    {

        "value": [
    

            0
    

        ],
    

        "fc": 2,
    

        "unitid": 1,
    

        "address": 0,
    

        "quantity": 1,
    

        "bad_data": false
    

    }

    Здесь `"value": [0]` означает, что контакт на входе разомкнут. Если его замкнуть, значение изменится на `[1]`, но сообщения все равно будут приходить строго каждые 2 секунды.

    Поток 2: Push-модель через MQTT

    Задача: Мгновенно реагировать на нажатие виртуальной кнопки в MQTT-клиенте. Создание потока:
  • Возьмите узел `mqtt in` из палитры.
  • В его настройках создайте или выберите сервер, указав адрес вашего MQTT-брокера (часто это сам контроллер, `localhost:1883`).
  • Заполните параметры подписки:

    • * `Topic`: `hi/devices/living_room/button/state` (это адрес, по которому кнопка будет публиковать свое состояние)

    * `QoS`: `1` (гарантирует доставку сообщения)

  • Подключите узел `Debug` к выходу `mqtt in`.
    • Схема потока (ASCII): 
    [mqtt in: topic="hi/.../button/state"] ----> [Debug]

    После развертывания потока в панели отладки будет полная тишина. Никаких сообщений не появляется. Теперь откройте ваш MQTT-клиент, подключитесь к брокеру и опубликуйте в топик `hi/devices/living_room/button/state` сообщение `"ON"`.

    В ту же секунду в панели отладки Node-RED появится одно-единственное сообщение.

    Пример `msg.payload` от MQTT-кнопки:

    Простой вариант:

    "ON"

    Более сложный, информативный вариант:

    {

      "click": "single",
    

      "ts": 1678886500000,
    

      "source": "mobile-app-user1"
    

    }

    Визуальное сравнение в панели Debug

    Этот простой эксперимент наглядно демонстрирует фундаментальное различие в поведении и эффективности двух моделей.

    ---

    Сводка и гибридные подходы

    Выбор между Pull и Push — это не выбор между "хорошим" и "плохим", а инженерное решение, основанное на требованиях конкретной задачи. Ниже приведена сравнительная таблица, которая поможет вам сделать правильный выбор.

    | Критерий | Модель Pull (Опрос) | Модель Push (Подписка) |

    | ------------------------------ | ---------------------------------------------------- | ------------------------------------------------------- |

    | Инициатор связи | Контроллер | Устройство |

    | Типичный протокол | Modbus RTU/TCP, HTTP GET | MQTT, KNX, Zigbee, Z-Wave |

    | Латентность (Задержка) | Высокая (равна интервалу опроса) | Минимальная (определяется скоростью сети) |

    | Эффективность сети | Низкая (постоянный избыточный трафик) | Высокая (трафик только по событию) |

    | Сложность отслеживания | Низкая (контроллер всегда знает статус) | Выше (требуется механизм сохранения последнего состояния) |

    | Типичное применение | Мониторинг некритичных параметров (температура, влажность, показания счетчиков), работа с устаревшим оборудованием. | Управление освещением, кнопки, датчики движения, системы безопасности, тревожные уведомления. |

    Рекомендации по выбору

    * Вы работаете с оборудованием, которое не поддерживает Push (большинство Modbus-устройств).

    * Вам нужно получать данные, которые меняются медленно и предсказуемо (например, температура в помещении, уровень воды в баке).

    * Латентность в несколько секунд не является критичной.

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

    * Требуется мгновенная реакция системы (кнопки, датчики движения, охранные датчики).

    * Важна высокая эффективность и экономия пропускной способности сети.

    * Вы строите современную, масштабируемую систему на базе MQTT или аналогичных протоколов.

    Гибридные модели: лучшее из двух миров

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

  • Pull-компонент: Контроллер опрашивает счетчик раз в 5 минут, чтобы снимать текущие показания потребления (кВт*ч). Это некритичная задача, и частый опрос не нужен.
  • Push-компонент: У счетчика есть дискретный выход "Авария", который замыкается при превышении установленной мощности. Этот выход подключен к дискретному входу контроллера HI, который генерирует мгновенное внутреннее push-событие.

    • Таким образом, мы получаем и плановый сбор данных, и мгновенную реакцию на важное событие, используя сильные стороны обеих моделей. Другой пример — опрос (Pull) MQTT-устройства раз в минуту для контроля его онлайн-статуса (heartbeat), но получение мгновенных уведомлений (Push) о его рабочих событиях.

    > 🔗 Связанный материал: Более сложные техники обработки потоков данных, включая узлы `trigger` и `debounce` для защиты от дребезга контактов и построения сложной логики на основе событий, будут рассмотрены в модуле `COURSE-06-M02: Продвинутые потоки в Node-RED`.

    Что дальше

    В этом уроке вы изучили фундаментальные различия между Pull и Push моделями получения данных. Вы научились выбирать подходящую модель для решения конкретных задач автоматизации и реализовали базовые примеры в Node-RED. Теперь вы можете осознанно подходить к проектированию потоков данных, создавая не просто работающие, а по-настоящему эффективные и отзывчивые системы. В следующем уроке мы перейдем к анализу самих данных и методам их нормализации.