Мини-Runbook: Шаг 3 (Проверка входа)
Введение в проверку входов
> 🔗 Связанный материал: Этот урок является логическим продолжением урока COURSE-01-M08-L02, где мы убедились в работоспособности питания и сетевой инфраструктуры контроллера.
После того как мы подтвердили, что контроллер включен и доступен по сети, следующим логическим шагом в диагностике является проверка входов. В контексте систем автоматизации, входы — это глаза и уши нашей системы. Они преобразуют физические события из реального мира в цифровые сигналы, которые может обработать контроллер.
📋 Ключевые понятия:
- Сухой контакт (Dry Contact): Простейший тип входа, представляющий собой замыкание или размыкание электрической цепи без внешнего напряжения. Типичные примеры: настенные кнопочные выключатели, герконы на дверях и окнах, релейные выходы датчиков движения. Контроллер сам подает небольшое напряжение на вход для определения его состояния.
- Дискретный вход (Discrete Input): Вход, который может находиться только в двух состояниях: включено/выключено, 0/1, `true`/`false`. Сухие контакты являются частным случаем дискретных входов.
- Аналоговый вход (Analog Input): Вход, способный измерять непрерывный диапазон сигнала, например, напряжение (0-10В) или ток (4-20мА). Используется для подключения датчиков с плавно изменяющимися показаниями (датчики освещенности, уровня CO2, давления).
Шаг 3 нашего мини-ранбука (Mini-Runbook) заключается в проверке полной цепочки прохождения сигнала: от физического воздействия до появления соответствующей информации в нашей системе логики на Node-RED. Эта цепочка выглядит следующим образом:
Важность пошаговой проверки этой цепочки невозможно переоценить. Если кнопка не включает свет, причина может быть на любом из этих четырех этапов. Методично проверяя каждый шаг, мы быстро и точно локализуем неисправность. Например, если при нажатии кнопки мы видим изменение статуса в веб-интерфейсе контроллера, но не получаем MQTT-сообщение, значит, проблема кроется в конфигурации MQTT-драйвера, а не в физическом подключении кнопки. Такой подход экономит часы рабочего времени на объекте.
---
Секция 1: Диагностика на уровне контроллера (Wirenboard)
Первый и самый важный шаг — убедиться, что контроллер физически "видит" событие на входе. Для платформы на базе Wirenboard самым быстрым способом сделать это является использование его веб-интерфейса.
> 💡 Подсказка: Веб-интерфейс Wirenboard — это Источник Истины (Source of Truth) для состояния аппаратных входов и выходов. Если статус меняется здесь, значит, физическое подключение и базовый драйвер работают корректно. Любые дальнейшие проблемы следует искать на программном уровне (MQTT, Node-RED).
Пошаговая проверка через веб-интерфейс
Диагностика через консоль
В некоторых случаях, например, при отсутствии доступа к веб-интерфейсу или для получения более детальной информации, можно использовать консольные утилиты.
# Подключитесь к контроллеру по SSH
ssh root@
# Запустите утилиту диагностики
wb-diag-tool -g
Эта команда выведет подробный отчет о конфигурации оборудования, включая список всех распознанных модулей расширения и их состояние. Это полезно для подтверждения, что, например, Modbus-модуль дискретных входов в принципе определяется на шине RS-485.
Чтобы в реальном времени отслеживать значения, которые публикуются в MQTT (о чем мы поговорим в следующей секции), можно использовать утилиту `mosquitto_sub`. Однако на самом первом этапе, когда мы проверяем именно аппаратную часть, веб-интерфейс является наиболее наглядным и достаточным инструментом.
---
Секция 2: Мониторинг MQTT-сообщений
После того как мы убедились, что контроллер видит изменение состояния входа, следующий шаг — проверить, публикуется ли это событие в MQTT. MQTT — это центральная нервная система нашей платформы, и любое событие должно быть отражено в ней.
Драйверы Wirenboard автоматически публикуют состояние каждого канала в свой уникальный MQTT-топик. Структура этих топиков строго стандартизирована, что делает их предсказуемыми.
Структура MQTT-топиков для устройств Wirenboard
Общий формат топика: `/devices/
- `/devices/`: Стандартный префикс.
- `
`: Уникальное имя устройства, например `wb-gpio` для встроенных I/O или `wb-mdm3_23` для внешнего Modbus-модуля с адресом 23. - `/controls/`: Стандартный разделитель.
- `
`: Имя конкретного канала, например `Input 1`.
Пример: топик для первого входа на модуле `wb-mdm3` с адресом 23 будет: `/devices/wb-mdm3_23/controls/Input 1`.
Состояние этого входа публикуется в данный топик. Чтобы получать команды управления (например, для реле), используется суффикс `/on`, т.е. `/devices/wb-mdm3_23/controls/K1/on`.
Практика мониторинга
Для отслеживания сообщений мы можем использовать два основных инструмента: консольную утилиту `mosquitto_sub` или графический клиент MQTT Explorer.
Подключитесь к контроллеру по SSH и выполните команду, подставив ваш топик:
# Подписаться на топик конкретного входа
# Флаг -v выводит топик перед сообщением
mosquitto_sub -v -t '/devices/wb-gpio/controls/Input 5'
Теперь, когда вы нажмете кнопку, подключенную к пятому входу, в консоли вы увидите:
/devices/wb-gpio/controls/Input 5 1
А когда отпустите:
/devices/wb-gpio/controls/Input 5 0
Это является неопровержимым доказательством того, что сигнал успешно прошел аппаратный уровень и был опубликован в MQTT-брокере.
Это более наглядный способ. Запустите MQTT Explorer на своем ПК и подключитесь к MQTT-брокеру на контроллере. Вы увидите все дерево топиков. При срабатывании входа вы в реальном времени увидите, как подсвечивается нужный топик и меняется его значение.
Использование Wildcards для массового мониторинга
Часто бывает необходимо отслеживать сразу несколько входов. Для этого используются wildcards (маски):
- `+` (плюс): Заменяет один уровень в иерархии топиков.
- `#` (решетка): Заменяет ноль или более уровней в иерархии (работает только в конце топика).
| Задача | Команда `mosquitto_sub` | Пояснение |
| -------------------------------------------------- | ---------------------------------------------------------- | ------------------------------------------------------------------------------ |
| Мониторить все каналы модуля `wb-gpio` | `-t '/devices/wb-gpio/controls/+'` | Мы получим сообщения от `Input 1`, `Input 2`, и т.д., но не от других модулей. |
| Мониторить канал `Input 1` на всех устройствах | `-t '/devices/+/controls/Input 1'` | Полезно, если у нас много однотипных модулей. |
| Мониторить вообще всё в системе (опасно!) | `-t '/#'` | Выводит все MQTT-сообщения. Используйте для общей диагностики, но будьте готовы к потоку данных. |
Если на этом этапе вы не видите MQTT-сообщений, при том что в веб-интерфейсе Wirenboard статус меняется, проблема скорее всего в работе системного сервиса `wb-mqtt-gpio` или `wb-mqtt-serial`. Проверьте его статус и логи: `systemctl status wb-mqtt-gpio` и `journalctl -u wb-mqtt-gpio`.
---
Секция 3: Отладка в Node-RED
Финальный этап проверки — убедиться, что MQTT-сообщение доходит до нашего сценария в Node-RED. Это самый простой этап, если предыдущие два были пройдены успешно.
Проблема на этом шаге почти всегда связана с ошибкой в конфигурации узла `mqtt in` (неправильный топик, неверные настройки брокера) или с неправильной обработкой полученных данных.
Создание базовой отладочной цепочки
Самый надежный способ проверить получение данных — создать простейший поток:
`[mqtt in]` -> `[debug]`
* Перетащите узел `mqtt in` на поле.
* Дважды кликните по нему.
* Server: Выберите или настройте подключение к вашему MQTT-брокеру. Для локального брокера это обычно `localhost:1883`.
* Topic: Укажите точный топик, который вы отслеживали на предыдущем шаге, например, `/devices/wb-gpio/controls/Input 5`.
* QoS: `0` или `1`.
* Output: `a utf8-string`.
* Нажмите `Done`.
* Перетащите узел `debug` и соедините его с выходом узла `mqtt in`.
* Дважды кликните по нему.
* Output: Измените значение с `msg.payload` на `complete msg object`. Это критически важно, так как позволяет видеть не только само значение, но и топик, QoS и другие полезные свойства сообщения.
* Нажмите `Done`.
* Нажмите красную кнопку `Deploy` в правом верхнем углу.
* Перейдите на вкладку отладки (с иконкой жука) справа.
* Теперь активируйте ваш вход (нажмите кнопку). В окне отладки вы должны увидеть JSON-объект, представляющий полученное сообщение.
Пример объекта `msg` в окне отладки:
{
"_msgid": "a1b2c3d4.5e4d3c",
"payload": "1",
"topic": "/devices/wb-gpio/controls/Input 5",
"qos": 0,
"retain": false
}
Если вы видите это сообщение, значит, ваша цепочка диагностики завершена успешно! Сигнал дошел от физической кнопки до вашей логики в Node-RED. Если сообщения нет, перепроверьте топик и настройки брокера в узле `mqtt in`.
> ⚠️ Внимание: Обращайте внимание на тип данных. По умолчанию узел `mqtt in` выдает `payload` в виде строки (string, "0" или "1"). Для корректной работы дальнейшей логики (например, в узле `switch` при проверке `msg.payload === 1`) может потребоваться явное преобразование типов. Это можно сделать в узле `function` (`msg.payload = parseInt(msg.payload);`) или в узле `change`, настроив правило для преобразования в число (number). Это одна из самых частых ошибок новичков.
---
Секция 4: Особенности протоколов KNX и Modbus
Хотя конечная цель у нас всегда одна — получить сообщение в MQTT, начальный этап диагностики для промышленных протоколов, таких как KNX и Modbus, имеет свои особенности. Сигнал сначала должен быть обработан соответствующим шлюзом.
Диагностика входов KNX
В системах KNX устройства общаются друг с другом напрямую через шину, используя групповые адреса (Group Address, GA). Например, настенный кнопочный выключатель при нажатии отправляет телеграмму с определенным значением (например, `1`) в конкретный групповой адрес (например, `1/1/1`).
Таким образом, цепочка для KNX выглядит длиннее:
`Физическое нажатие` -> `Телеграмма в шине KNX` -> `KNX/IP шлюз` -> `Сервис-мост` -> `MQTT-сообщение` -> `Node-RED`.
Искать проблему нужно последовательно на каждом из этих этапов.
Диагностика входов Modbus
Для Modbus-устройств, подключенных по шине RS-485, ситуация иная. В отличие от KNX, устройства здесь "пассивны" (Slave) и не отправляют данные сами. Контроллер (Master) должен их периодически опрашивать.
Пример конфигурации для опроса модуля WB-MDM3 с адресом 23:
{
"device_type": "WB-MDM3",
"device": {
"name": "wb-mdm3_23",
"id": "wb-mdm3_23",
"slave_id": "23",
"channels": [
{
"name": "Input 1",
"reg_type": "input",
"address": "12",
"type": "switch"
},
{
"name": "Input 2",
"reg_type": "input",
"address": "13",
"type": "switch"
}
]
}
}
Здесь мы говорим сервису `wb-mqtt-serial` опрашивать регистры `12` и `13` на устройстве с адресом `23` и публиковать их состояние в MQTT-топики `/devices/wb-mdm3_23/controls/Input 1` и `/devices/wb-mdm3_23/controls/Input 2`.
Ключевой вывод: независимо от базового протокола, наша цель — добиться появления предсказуемого сообщения в MQTT. Первый шаг диагностики всегда должен быть адаптирован к специфике этого протокола: для Wirenboard — веб-интерфейс, для KNX — ETS Group Monitor, для Modbus — проверка конфигурации `wb-mqtt-serial.conf`.
---
Итоги и следующие шаги
В этом уроке мы детально разобрали Шаг 3 нашего диагностического ранбука — проверку физических входов. Мы научились системно подходить к этому процессу, проверяя всю цепочку прохождения сигнала.
Ключевые моменты для закрепления:
- Трёхэтапный процесс верификации: Любой вход проверяется последовательно на трёх уровнях:
2. Уровень MQTT: Публикуется ли событие в MQTT-брокере? (`mosquitto_sub`, MQTT Explorer).
3. Уровень логики: Доходит ли MQTT-сообщение до Node-RED? (Узел `debug`).
- Диагностика "снизу вверх": Такой методичный подход от физики к логике позволяет быстро локализовать неисправность и не тратить время на "гадание". Если не работает кнопка, сначала проверьте кабель, а не переписывайте сценарий в Node-RED.
Этот урок дал вам в руки надежный инструмент для диагностики "чувствительной" части вашей системы автоматизации. Вы больше не будете беспомощно смотреть на неработающий выключатель, а будете точно знать, что и в какой последовательности нужно проверить.
Что дальше:В следующем уроке мы перейдем к Шагу 4: Проверка выхода. Мы научимся управлять исполнительными устройствами — реле, диммерами, приводами. Мы разберем обратную цепочку: как команда из Node-RED проходит через MQTT и заставляет физическое устройство выполнить действие в реальном мире.