Диагностика в Node-RED: ноды Debug и Log
Введение в диагностику в Node-RED
> 🔗 Связанный материал: Этот урок является практическим продолжением урока "Методология поиска неисправностей: от ПО к аппаратуре". Прежде чем винить "железо", необходимо на 100% убедиться, что программное обеспечение отправляет корректные команды и правильно интерпретирует ответы.
Любая пусконаладка на объекте — это процесс итеративного поиска и устранения неисправностей. Ситуация, когда "реле щелкает, но не работает", является классическим примером, где проблема может скрываться как в аппаратной, так и в программной части. Методология "от ПО к аппаратуре", которую мы рассмотрели ранее, предписывает в первую очередь исключить ошибки в логике управления. Для этого в арсенале инженера автоматизации на платформе HI существуют мощные встроенные инструменты, и главный из них — среда Node-RED.
В этом уроке мы сосредоточимся на двух основных инструментах программной диагностики:
Освоение этих инструментов — критически важный навык. Он позволяет быстро локализовать проблему: если вы видите в отладчике, что из потока выходит правильная команда (например, `msg.payload` содержит `true`), но реле не переключает нужную нагрузку, то с высокой вероятностью проблема находится на уровне физического подключения, конфигурации реле или неисправности самой нагрузки. И наоборот, если команда не формируется или имеет неверный формат, вы можете исправить это на программном уровне, не вставая из-за компьютера и не вскрывая электрический щит. Эффективная диагностика экономит часы, а иногда и дни работы на объекте.
---
Нода Debug: Ваш основной инструмент отладки
Нода Debug — это фундаментальный и наиболее часто используемый узел для диагностики потоков в Node-RED. Ее основная задача — перехватить объект сообщения (`msg`) в любой точке потока и вывести его содержимое на боковую панель отладки в редакторе. Это позволяет "заглянуть внутрь" системы и понять, какие данные передаются между узлами.> 📋 Ключевые понятия:
> * Объект `msg`: Основная единица передачи данных в Node-RED. Это JavaScript-объект, который "течет" от узла к узлу.
> * `msg.payload`: Стандартное свойство объекта `msg`, в котором обычно содержатся основные данные (значение датчика, команда для реле и т.д.).
> * Боковая панель отладки (Debug sidebar): Область в правой части редактора Node-RED, куда выводятся все сообщения от нод Debug.
Детальная настройка ноды Debug
Двойной щелчок по ноде Debug открывает окно ее настроек, где доступны ключевые опции:
* `msg.payload` (по умолчанию): Отображает только содержимое свойства `payload`. Это самый частый сценарий использования, когда вам нужно быстро проверить основное значение.
* `complete msg object`: Отображает весь объект `msg` целиком, со всеми его свойствами (`payload`, `topic`, `_msgid` и любыми другими, которые были добавлены в потоке). Это критически важно для комплексной отладки, когда проблема может быть не в `payload`, а, например, в неправильно установленном `topic`.
* Выражение (Expression): Позволяет указать путь к любому свойству внутри объекта `msg`. Например, если у вас сложный объект `msg.payload = {"device": "thermostat", "data": {"temperature": 23.5}}`, вы можете указать в поле `msg.payload.data.temperature`, чтобы видеть только значение температуры. Это помогает избавиться от "шума" при отладке.
* `debug window` (по умолчанию): Сообщения выводятся на боковую панель в редакторе.
* `system console`: Сообщения дублируются в системную консоль, из которой был запущен Node-RED. На контроллере HI это можно увидеть, подключившись по SSH и выполнив команду `journalctl -f -u nodered.service`. Полезно для отладки проблем, связанных с запуском или падением Node-RED.
* `node status`: Выводит данные под нодой в самом редакторе (первые 32 символа). Удобно для быстрого мониторинга без открытия боковой панели.
Наконец, справа на самой ноде есть кнопка-квадратик. Она позволяет временно включить или выключить ноду без ее удаления из потока. Когда нода выключена (кнопка становится прозрачной), она перестает перехватывать и выводить сообщения. Это чрезвычайно полезно, чтобы "заглушить" отладочный вывод, когда проблема найдена, но вы не хотите удалять саму ноду на случай, если она понадобится в будущем.
---
Практикум: Отслеживание сообщения для диагностики реле
Давайте на практическом примере разберем, как с помощью ноды Debug выявить одну из самых частых ошибок при управлении реле — отправку команды в неверном формате.
> 💡 Подсказка: Всегда давайте осмысленные имена нодам Debug. Например, "Debug: команда НА реле" и "Debug: обратная связь ОТ реле". Это позволит мгновенно ориентироваться в отладочном выводе, особенно когда в потоке несколько отладочных узлов.
Создание тестового потока
Ваша схема должна выглядеть так:
+----------+ +--------------------+
[Inject] ---+---> | Debug | | Debug: До Function |
| +----------+ +--------------------+
|
| +----------+ +----------------------+
+---> | Function | ---> | Debug |
+----------+ | Debug: После Function |
+----------------------+
Анализ правильной и неправильной команды
Этап 1: Формирование корректной команды
// Имитируем получение команды "ON"
msg.payload = "ON";
// Корректная логика: преобразуем команду в boolean
// Большинство нод для управления реле ожидают true/false
if (msg.payload === "ON") {
msg.payload = true; // Правильный тип: boolean
} else {
msg.payload = false;
}
return msg;
Вы увидите два сообщения:
- От "Debug: До Function": `ON` (тип: string).
- От "Debug: После Function": `true` (тип: boolean).
Пример вывода в панели Debug:
// Сообщение от "Debug: До Function"
{
"payload": "ON",
"topic": "",
"_msgid": "a1b2c3d4.123456"
}
// Сообщение от "Debug: После Function"
{
"payload": true,
"topic": "",
"_msgid": "a1b2c3d4.123456"
}
Это правильное поведение. Физический узел управления реле, получив `msg.payload = true`, корректно сработает.
Этап 2: Имитация распространенной ошибки
Теперь давайте смоделируем ошибку. Начинающий инженер может попытаться отправить команду как строку.
// Имитируем получение команды "ON"
msg.payload = "ON";
// НЕПРАВИЛЬНАЯ логика
if (msg.payload === "ON") {
msg.payload = "true"; // Ошибка! Тип: string, а не boolean
} else {
msg.payload = "false";
}
return msg;
Теперь вывод от "Debug: После Function" будет выглядеть иначе:
// Сообщение от "Debug: После Function" (с ошибкой)
{
"payload": "true",
"topic": "",
"_msgid": "e5f6g7h8.789012"
}
Визуально в панели Debug вы увидите значение `true` в кавычках: `"true"`. Это и есть ключ к разгадке! Физический узел управления реле, скорее всего, не поймет команду `"true"` (строка) и проигнорирует ее. При этом реле на контроллере может щелкнуть (если узел управления реагирует на любое входящее сообщение), но внешнее устройство (например, контактор) не сработает. Нода Debug однозначно показывает, что проблема находится в ноде `Function`, которая формирует команду неверного типа.
---
Продвинутое логирование: Нода node-red-contrib-log
Возможностей ноды `Debug` достаточно для интерактивной отладки в реальном времени. Но что делать, если проблема "плавающая", возникает раз в сутки или в момент, когда вы не подключены к системе? Просто смотреть в панель отладки не получится. Для таких случаев необходимо персистентное логирование — запись событий в файл на диске контроллера для последующего анализа.
Для этой задачи мы используем сторонний модуль `node-red-contrib-log`. Он значительно расширяет возможности стандартного логирования.
> ⚠️ Внимание: Бесконтрольное логирование может быстро исчерпать дисковое пространство контроллера HI. Всегда используйте ротацию логов и не логируйте без необходимости в промышленных инсталляциях. Рекомендуемый путь для хранения лог-файлов на контроллере HI: `/var/log/node-red/`. Эта директория обычно имеет правильные права доступа и предназначена для логов приложений.
Обзор возможностей `node-red-contrib-log`
- Запись в файл: Основная функция. Нода может создавать лог-файл и дописывать в него сообщения из потока.
- Ротация логов: Автоматическое управление размером лог-файлов. Можно настроить максимальный размер файла (например, 5 МБ) и количество хранимых архивных копий. Когда файл достигает лимита, он переименовывается (например, в `app.log.1`), а запись продолжается в новый пустой файл. Это предотвращает переполнение диска.
- Запись в Syslog: Возможность отправлять логи в системный журнал Linux (syslog), что позволяет централизованно управлять ими стандартными средствами ОС.
- Уровни логирования: Нода поддерживает стандартные уровни важности сообщений, что позволяет структурировать лог и фильтровать его при анализе:
* `ERROR`: Произошла ошибка, требующая внимания (например, не удалось прочитать данные с Modbus-устройства).
* `WARN`: Предупреждение о потенциальной проблеме (например, значение датчика вышло за "нормальные" пределы).
* `INFO`: Информационное сообщение о штатном событии (например, "Включен свет в гостиной").
* `DEBUG`: Детальная отладочная информация.
* `TRACE`: Максимально подробная информация для низкоуровневой отладки.
Использование разных уровней позволяет при анализе лога быстро отфильтровать только ошибки (`grep ERROR hi-actuators.log`) или, наоборот, восстановить полную хронологию событий.
---
Практикум: Настройка записи событий в лог-файл
Давайте настроим поток, который будет фиксировать все команды на управление освещением в отдельный лог-файл.
Шаг 1: Установка ноды `node-red-contrib-log`
Шаг 2: Создание и настройка потока логирования
// msg.payload от Inject содержит "ON" или "OFF"
let command = msg.payload;
let state = (command === "ON") ? "включен" : "выключен";
// Формируем осмысленное сообщение для записи в лог
msg.payload = `Свет в гостиной ${state}. Команда от пользователя 'admin'.`;
// Задаем уровень логирования. INFO - для штатных событий.
msg.level = "info";
return msg;
* Level: Установите `Default` (по умолчанию). Это значит, что уровень будет браться из свойства `msg.level`. Если `msg.level` не задан, будет использован уровень, выбранный в этом поле.
* Target: Выберите `File` (Файл).
* File: Укажите путь к файлу лога. Для контроллера HI используйте: `/var/log/node-red/hi-actuators.log`.
* Format: Выберите `JSON` или `text`. Для начала `text` проще для чтения.
* Rotation: Настройте ротацию. Например: `size: 5MB`, `count: 3`. Это означает, что лог будет храниться в файлах по 5 МБ, и система будет хранить 3 старых архива.
Шаг 3: Проверка работы
tail -f /var/log/node-red/hi-actuators.log
[2023-10-27T10:30:15.123Z] [info] Свет в гостиной включен. Команда от пользователя 'admin'.
[2023-10-27T10:30:20.456Z] [info] Свет в гостиной выключен. Команда от пользователя 'admin'.
Теперь у вас есть персистентный журнал всех важных событий системы. Если заказчик сообщит, что "вчера вечером свет сам выключился", вы сможете открыть этот файл и точно установить, была ли в это время команда от системы, и если да, то чем она была инициирована.
---
Резюме и лучшие практики
Правильный выбор инструмента для диагностики — залог быстрой и эффективной пусконаладки. Ноды `Debug` и `Log` не взаимозаменяемы, а дополняют друг друга, решая разные задачи.
Сравнительная таблица: Debug vs. Log
| Критерий | Нода Debug | Нода Log (`node-red-contrib-log`) |
| ------------------------- | ------------------------------------------------ | ----------------------------------------------------------------- |
| Назначение | Интерактивная отладка в реальном времени | Долгосрочный мониторинг, анализ "пост-фактум" |
| Хранение данных | Временно, в оперативной памяти (в браузере) | Постоянно (персистентно) в файле на диске контроллера |
| Доступ к данным | Только при открытом редакторе Node-RED | В любой момент через SSH или доступ к файловой системе |
| Влияние на систему | Минимальное (если вывод не слишком интенсивный) | Создает дисковые операции (I/O), требует управления размером файла |
| Основной сценарий | "Почему этот узел не работает прямо сейчас?" | "Что происходило в системе вчера в 23:05?" |
| Типичное использование | В процессе разработки и активной пусконаладки | На стабильно работающей системе для аудита и поиска редких сбоев |
Финальный чек-лист программной диагностики
Столкнувшись с проблемой "реле щелкает, но не работает", пройдитесь по этому списку, используя ноду `Debug` на выходе из вашего потока управления:
Только после того, как вы с помощью этих инструментов на 100% убедились, что из Node-RED выходит абсолютно корректная команда в нужное время, есть смысл переходить к диагностике аппаратной части, как было описано в предыдущих уроках.