Практика: Диагностика по сценарию
Введение: Сценарий "Свет не включается по датчику движения"
Добро пожаловать в практический урок по диагностике! Теория важна, но настоящее мастерство инженера проявляется "в поле", когда система ведет себя не так, как ожидалось. Сегодня мы разберем один из самых распространенных сценариев неисправности в умном доме: свет в помещении перестал автоматически включаться по сигналу от датчика движения. Наша цель — не просто исправить проблему, а сделать это системно, быстро и профессионально.
> 🔗 Связанный материал: Этот урок является практическим применением методологии, описанной в уроках по системному подходу к диагностике и мини-ранбукам (COURSE-01-M08-L02, L03, L04, L05). Убедитесь, что вы изучили их, так как мы будем строго следовать изложенным там принципам.
Вспомним нашу пятишаговую методологию диагностики, которая является основой для поиска любой неисправности:
Мы будем последовательно проходить через все эти шаги, чтобы локализовать и устранить проблему. Пропуск даже одного шага может привести к неверным выводам и часам потерянного времени.
Постановка практической задачи
Проблема: В коридоре коттеджа установлен датчик движения, который должен включать основное освещение на 5 минут. Клиент сообщает, что несколько дней назад всё работало, но сейчас свет не загорается при входе в коридор. Ручное включение с выключателя (если он есть) или из приложения работает исправно. Описание тестового стенда (типовая конфигурация):- Контроллер: Wirenboard 7 (Linux Debian). Это мозг нашей системы.
- Датчик движения: Стандартный ИК-датчик (PIR) с выходом типа "сухой контакт". Подключен к дискретному входу `DI1_IN` модуля `wb-gpio` контроллера.
- Исполнительный модуль: Релейный модуль `Wirenboard WB-MR6C`, подключенный к контроллеру по шине RS-485. Его ID на шине — `42`.
- Нагрузка: Светильник в коридоре, подключенный к первой клеммной паре (`K1`) релейного модуля `WB-MR6C`.
- Логика: Сценарий автоматизации реализован в Node-RED на контроллере Wirenboard.
Наша задача — пройти по всем пяти шагам, чтобы найти "слабое звено" в этой цепи.
---
Применение Runbook: Шаги 1-2 (Питание и Сеть)
Первое и самое главное правило инженера: никогда не начинайте отладку сложной логики, не убедившись в работоспособности базовой инфраструктуры.
Шаг 1: Проверка физического питания
Подойдите к электрощиту, где установлен контроллер и модули.
В нашем случае, предположим, все светодиоды горят зеленым. Питание в норме. Переходим к сети.
Шаг 2: Проверка сети и служб
# Замените 192.168.1.42 на IP-адрес вашего контроллера
ping 192.168.1.42
Если пинги проходят (вы видите ответы `64 bytes from ...`), сеть в порядке. Если нет — проверяйте Ethernet-кабель, настройки Wi-Fi или сетевой коммутатор.
ssh root@192.168.1.42
Успешное подключение подтверждает, что контроллер не только в сети, но и его ОС работает корректно.
# Проверка статуса MQTT-брокера
systemctl status mosquitto
# Проверка статуса драйвера оборудования
systemctl status wb-mqtt-serial
В выводе обеих команд ищите строку `Active: active (running)`. Если одна из служб неактивна (`inactive` или `failed`), это и есть корень проблемы. Попробуйте перезапустить ее командой `systemctl restart <имя_службы>`.
> 💡 Подсказка: Используйте встроенную утилиту `wb-health` в консоли Wirenboard для быстрой комплексной проверки состояния системы, включая нагрузку на процессор, свободное место и статус сервисов. Это может сэкономить время на проверке каждой службы по отдельности.
Предположим, на шагах 1 и 2 мы не нашли проблем. Все оборудование запитано, контроллер в сети, службы работают, Node-RED подключен к брокеру. Значит, проблема глубже.
---
Применение Runbook: Шаг 3 (Проверка Входа)
Теперь мы должны сфокусироваться на самом начале нашего сценария — на датчике движения. Поступает ли от него сигнал в систему?
На этом шаге мы игнорируем логику и выход. Нам важно лишь одно: видит ли контроллер срабатывание датчика.
* Перейдите на вкладку Devices.
* В списке устройств найдите `wb-gpio` (это встроенные входы/выходы контроллера).
* Найдите в списке контрол `DI1_IN`.
* Попросите кого-нибудь помахать рукой перед датчиком движения. Значение `DI1_IN` в интерфейсе должно меняться с `0` на `1` (или наоборот).
Если значение меняется — отлично, физическое подключение в порядке, и драйвер видит сигнал. Если нет — проблема в кабеле от датчика до контроллера, в самом датчике или в его подключении к клеммам. Проверьте схему подключения, как было рассмотрено в предыдущих уроках.
# Слушаем топик, в который драйвер wb-gpio публикует состояние входа DI1
mosquitto_sub -v -t '/devices/wb-gpio/controls/DI1_IN'
Ключ `-v` позволяет видеть и топик, и его значение. Теперь терминал "зависнет" в ожидании сообщений. Снова имитируйте движение перед датчиком.
* Ожидаемый результат: В терминале появляется строка:
`/devices/wb-gpio/controls/DI1_IN 1` — в момент обнаружения движения.
Через некоторое время, когда датчик "успокоится":
`/devices/wb-gpio/controls/DI1_IN 0`
* Если сообщения не появляются: Это подтверждает, что проблема находится "до" MQTT. То есть либо физическое подключение, либо драйвер `wb-gpio` не настроен или не работает. Вернитесь к шагу 1 и проверке схем.
* Если сообщения появляются: Поздравляем, вы успешно завершили Шаг 3! Вы доказали, что входной сигнал доходит до логического уровня системы (MQTT-брокера). Теперь мы можем с уверенностью сказать: проблема не в датчике и не в его подключении. Она либо в логике, либо в выходе.
> ⚠️ Внимание: Распространенная ошибка — инверсия сигнала. Убедитесь, что в логике Node-RED вы правильно обрабатываете значения '0' и '1', которые присылает датчик. Иногда '0' может означать 'сработка' (если датчик с NC-контактом, а не NO). Всегда проверяйте это на этапе отладки входа.
---
Применение Runbook: Шаг 4 (Проверка Логики в Node-RED)
Мы доказали, что при движении в топик `/devices/wb-gpio/controls/DI1_IN` прилетает `"1"`. Но почему не включается свет? Проблема в "мозгах" — в потоке Node-RED.
На этом шаге мы изолируем и тестируем только логику, от входа `mqtt in` до выхода `mqtt out`.
Изоляция и анализ потока
[mqtt in] -> [switch] -> [trigger] -> [function] -> [mqtt out]
* Перетащите узел `debug` на холст.
* Подключите его выход к выходу узла `mqtt in`, который слушает топик датчика.
* Перетащите еще один `debug` и подключите его ко входу узла `mqtt out`, который отправляет команду на реле.
* Нажмите красную кнопку Deploy.
Теперь, когда датчик сработает, вы увидите сообщения в панели отладки (справа).
* Отладка входа: Видите ли вы сообщение от первого `debug` узла после срабатывания датчика? `msg.payload` должен быть равен строке `"1"`. Если нет, проверьте, правильно ли указан топик в узле `mqtt in`.
* Отладка выхода: Если на входе сигнал есть, но до второго `debug` узла (перед `mqtt out`) сообщение не доходит, значит, оно "теряется" где-то в середине — в узлах логики.
Анализ логических узлов
Пройдемся по цепочке, имитируя работу:
- Узел `mqtt in`: Пришло сообщение `msg.payload = "1"`.
- Узел `switch`: Часто используется для фильтрации. Например, он может пропускать дальше только `"1"` и игнорировать `"0"`. Проверьте его настройки. Может быть, он настроен на число `1`, а не на строку `"1"`? Это частая ошибка.
- Узел `trigger`: Этот узел обычно используется для создания задержки (включить свет, подождать 5 минут, выключить). Проверьте его настройки. Может, задержка стоит 0 секунд? Или он настроен отправлять не тот сигнал?
- Узел `function`: Если в потоке есть узел `function`, это самое вероятное место для ошибки. Откройте его. Проверьте код. Возможно, там написано `if (msg.payload === true)` вместо `if (msg.payload == "1")`. JavaScript строго различает типы, и строка `"1"` не равна булевому `true`.
Имитация входного сигнала
Чтобы не бегать каждый раз к датчику, можно имитировать его сигнал прямо в Node-RED.
Вы только что вручную "сымитировали" срабатывание датчика. Теперь смотрите на панель отладки и ищите, где прерывается цепочка сообщений. Создайте второй `inject` с `payload = "0"` для имитации выключения. Это позволяет отладить всю логику за пару минут, не вставая со стула.
// Пример ошибочной логики в узле function:
// Ожидает число, а приходит строка "1"
if (msg.payload === 1) {
// Этот код никогда не выполнится
msg.payload = "1";
return msg;
}
// Правильная логика:
// Приводим payload к числу или сравниваем со строкой
if (Number(msg.payload) === 1) {
// Этот код выполнится
msg.payload = "1"; // команда на включение
return msg;
}
Предположим, мы нашли ошибку: в узле `switch` было сравнение с числом `1`, а не строкой `"1"`. Мы это исправили, развернули. Теперь при нажатии на `inject` сообщение доходит до `debug` узла перед `mqtt out`. Шаг 4 пройден!
---
Применение Runbook: Шаг 5 (Проверка Выхода)
Итак, мы убедились, что логика Node-RED теперь корректно формирует команду на включение реле. Узел `mqtt out` пытается отправить сообщение. Но свет по-прежнему не горит. Финальный рубеж — исполнительное устройство.
> ⚠️ Внимание: Работы с силовыми клеммами реле должны проводиться только при полностью обесточенном щите. Соблюдайте технику безопасности при работе с высоким напряжением.
* Откройте вкладку Devices.
* Найдите в списке наш релейный модуль (`wb-mr6c_42`).
* Найдите контрол первого реле (`K1`). Рядом с ним будет переключатель.
* Нажмите на этот переключатель.
Что должно произойти? Вы должны услышать отчетливый щелчок реле внутри модуля, а свет в коридоре — включиться.
* Если реле щелкает, и свет включается: Поздравляем, физика в порядке! Реле и лампочка исправны. Это означает, что проблема в MQTT-команде, которую отправляет Node-RED. Проверьте топик в узле `mqtt out`. Он должен быть `/devices/wb-mr6c_42/controls/K1/on`, а payload должен быть `1`.
* Если реле щелкает, но свет НЕ включается: Это означает, что само реле работает, но есть проблема в силовой цепи после реле. Возможно, перегорела лампочка, отошел провод в клемме светильника, или сработал автомат защиты этой группы освещения. Проблема локализована в зоне ответственности электрика.
* Если реле НЕ щелкает: Проблема либо в модуле реле, либо в его связи с контроллером по RS-485.
# Отправляем команду "1" (включить) в топик .../on первого реле
mosquitto_pub -t '/devices/wb-mr6c_42/controls/K1/on' -m '1'
Выполнив эту команду в SSH-консоли, вы должны услышать щелчок реле. Если по этой команде щелчок есть, а из Node-RED нет, значит вы на 100% уверены, что ошибка в настройках узла `mqtt out` в вашем потоке. Сравните топик из команды и топик в узле — они должны совпадать до последнего символа.
Частая ошибка — отправить команду в топик состояния (`/devices/wb-mr6c_42/controls/K1`), а не в топик управления (`/devices/wb-mr6c_42/controls/K1/on`).
В нашем сценарии, допустим, мы выяснили, что `mosquitto_pub` включает свет, а логика Node-RED — нет. Мы открыли узел `mqtt out` и увидели опечатку в MQTT-топике: `.../control/K1/on` вместо `.../controls/K1/on`. Исправляем опечатку, нажимаем Deploy. Проблема решена.
---
Резюме: От Гипотезы к Решению
Давайте проследим наш путь. Мы начали с общей проблемы "свет не включается" и системно, шаг за шагом, сужали круг поиска.
| Шаг | Действие / Инструмент | Возможная причина | Статус в нашем сценарии |
| :-- | :-------------------- | :---------------- | :---------------------- |
| 1 | Визуальный осмотр | Нет питания на оборудовании. | OK |
| 2 | `ping`, `ssh`, `systemctl` | Контроллер не в сети, службы не работают. | OK |
| 3 | `mosquitto_sub`, Web UI | Датчик неисправен, обрыв кабеля, неверный MQTT топик. | OK |
| 4 | Node-RED `debug`, `inject` | Ошибка в логике (неверный тип данных, условие). | Нашли ошибку! |
| 5 | `mosquitto_pub`, Web UI | Реле неисправно, опечатка в топике, проблема в силовой цепи. | Нашли вторую ошибку! |
Как видите, в нашем вымышленном, но очень реалистичном примере, проблема оказалась комплексной: ошибка в логике сравнения и опечатка в топике управления. Если бы мы начали хаотично "тыкать" в Node-RED, не проверив сначала входной сигнал, мы бы потратили гораздо больше времени.
Этот практический урок закрепляет главную идею модуля: диагностика — это не магия, а системный процесс. Последовательное применение пятишагового ранбука позволяет гарантированно найти причину любой неисправности в связке "вход -> логика -> выход". Этот навык отличает профессионального инсталлятора от любителя и является основой для сдачи надежных и легко обслуживаемых объектов.
Что дальше
В следующем уроке мы завершим модуль, рассмотрев финальный этап — подготовку и подписание актов выполненных работ и создание исполнительной документации для сдачи объекта клиенту. Вы научитесь правильно документировать результаты своей работы, включая диагностические карты, которые мы научились составлять сегодня.