Сценарий 'Протечка воды': отключение насосов и розеток в мокрой зоне

Цели, задачи и компоненты сценария «Протечка»

🔗 Связанный материал: Для полного понимания принципов 'Safe-State' рекомендуется изучить урок COURSE-06-M07-L01 «Концепция 'Safe-State': что это и зачем нужно».

Сценарий «Протечка» является одним из наиболее критически важных элементов системы автоматизации, нацеленным на предотвращение значительного материального ущерба и минимизацию рисков, связанных с поражением электрическим током. В отличие от сценариев комфорта, его главная задача — не удобство, а немедленное приведение системы в заранее определённое безопасное состояние (Safe-State) при обнаружении аварийной ситуации.

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

Ключевые понятия и задачи

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

• Мокрая зона: Это не просто ванная комната или санузел, а спроектированная и задокументированная область на объекте, где существует повышенный риск протечки воды. К таким зонам относятся: санузлы, кухни (в области посудомоечной машины и мойки), котельные, постирочные, зоны установки бойлеров и насосных станций.
• Критическая нагрузка: Это перечень электрооборудования, которое должно быть немедленно отключено при обнаружении протечки в соответствующей "мокрой зоне".

Перечень типового отключаемого оборудования:

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

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

Электрические водонагреватели (бойлеры): Отключение питания предотвращает риск короткого замыкания при попадании воды на электрические компоненты.

Розеточные группы в "мокрой зоне": Как правило, это розетки, расположенные на высоте до 50 см от уровня пола в кухнях, санузлах и котельных.

Логическая цепочка сценария

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

Обнаружение (Физический уровень): Датчик протечки, установленный в самой низкой точке "мокрой зоны", фиксирует наличие воды. Он замыкает или размыкает свой "сухой контакт".

Сигнал на контроллер (Уровень ввода-вывода): Сигнал от датчика поступает на один из универсальных входов `UI` контроллера. Внутренний драйвер контроллера (например, `wb-mqtt-serial` для оборудования Wiren Board) преобразует это физическое событие в цифровое сообщение.

Публикация в MQTT (Транспортный уровень): Контроллер публикует сообщение об изменении состояния датчика в соответствующий MQTT-топик на встроенном MQTT-брокере. Это сообщение становится доступным для всех подписчиков в системе.

Обработка логики (Логический уровень): Node-RED, подписанный на этот топик, получает сообщение. Поток (flow) анализирует его содержимое и, согласно заложенной логике, формирует управляющие команды для исполнительных устройств.

Отправка команд (Транспортный уровень): Node-RED публикует команды на отключение в MQTT-топики, ассоциированные с нужными реле.

Исполнение (Уровень вывода-вывода): Релейные модули (например, Modbus-реле `wb-mr6c` или актуаторы шины KNX через соответствующий шлюз), подписанные на свои топики, получают команды и физически размыкают силовую цепь, обесточивая критическую нагрузку.

Этот сценарий является прямой реализацией концепции 'Safe-State', рассмотренной нами ранее. Система автономно, без участия человека, переходит в безопасное состояние, предотвращая развитие аварии.

---

Архитектура MQTT-топиков и настройка оборудования

Правильно спроектированная архитектура MQTT-топиков — это фундамент масштабируемой и легко обслуживаемой системы. Стандартизированные и семантически понятные имена топиков позволяют любому инженеру быстро разобраться в логике работы системы, даже не видя потоков в Node-RED.

💡 Подсказка: Используйте флаг `retained` для MQTT-сообщений, отражающих состояние реле (например, `/devices/wb-mr6c_25/controls/K1`). Это позволит новым подписчикам (например, панелям визуализации HMI или мобильным приложениям) при подключении к брокеру сразу же получить актуальный статус устройства, а не ждать следующего его изменения. Для командных топиков (например, `.../on`) использование `retained` флага является плохой практикой.

1. Выбор и настройка датчиков протечки

На платформе HI для обнаружения протечек могут использоваться как проводные, так и беспроводные датчики.

• Проводные датчики (рекомендуемый вариант): Например, `SWF 4.1`. Они подключаются к универсальным входам `UI` модуля расширения входов-выходов (например, `WB-MWAC`) или напрямую к входам контроллера.

* Принцип работы: Два электрода. При замыкании их водой, состояние входа контроллера меняется.

* MQTT-топик состояния: Драйвер `wb-mqtt-serial` автоматически создаст топик. Его структура будет выглядеть так:

        /devices/wb-mwac_8/controls/Digital_Input_1

        

Где `wb-mwac_8` — это ID модуля расширения, а `Digital_Input_1` — номер входа, к которому подключен датчик.

* Сообщения: В топик будет приходить значение `1` при обнаружении протечки и `0` при её отсутствии.

• Беспроводные датчики (Zigbee/LoRaWAN): Используются в местах, куда сложно или невозможно проложить провод. Например, Zigbee-датчик протечки от Aqara.

* Принцип работы: Аналогичен проводному, но сигнал передается по радиоканалу на Zigbee-шлюз (например, `zigbee2mqtt`).

* MQTT-топик состояния: Структура топика будет зависеть от настроек шлюза. Типичный пример для `zigbee2mqtt`:

        zigbee2mqtt/leak_sensor_bathroom_1

        

* Сообщения: Полезная нагрузка (`msg.payload`) обычно представляет собой JSON-объект.

        {

          "battery": 100,
          "voltage": 3000,
          "water_leak": true, 
          "linkquality": 90
        }
        

В этом случае в Node-RED нам нужно будет анализировать не весь `payload`, а конкретное поле `msg.payload.water_leak`.

2. Конфигурация исполнительных устройств

Для отключения нагрузки используются релейные модули. Рассмотрим `Wiren Board WB-MR6C` как типовой пример Modbus-реле.

• Назначение: Каждое реле в модуле должно быть сопоставлено с конкретной нагрузкой (например, `K1` — розетки в ванной, `K2` — насосная станция).
• MQTT-топик управления: Для управления реле используется специальный топик с суффиксом `/on`.

    /devices/wb-mr6c_25/controls/K1/on
    

Где `wb-mr6c_25` — ID Modbus-устройства, а `K1` — номер реле.

• Управляющие сообщения:

* Для отключения реле в этот топик необходимо отправить сообщение со значением `0`.

* Для включения реле — сообщение со значением `1`.

• MQTT-топик состояния: Модуль также публикует свое текущее состояние в топик без суффикса `/on`:

    /devices/wb-mr6c_25/controls/K1
    

На этот топик подписываются панели HMI для отображения статуса.

3. Проектирование иерархии MQTT-топиков

Для сложных объектов рекомендуется использовать собственную, более осмысленную иерархию топиков, создавая "виртуальные" устройства в Node-RED. Это делается с помощью промежуточных потоков, которые перепубликуют сообщения из "сырых" системных топиков в стандартизированные.

| Плохая структура (зависимая от оборудования) | Хорошая структура (семантическая) |

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

| `/devices/wb-mwac_8/controls/Digital_Input_1` | `myhome/floor1/bathroom/sensors/water_leak` |

| `/devices/wb-mr6c_25/controls/K1/on` | `myhome/floor1/bathroom/sockets/control` |

| `zigbee2mqtt/leak_sensor_kitchen` | `myhome/floor1/kitchen/sensors/water_leak` |

| `/devices/wb-mr6c_25/controls/K2/on` | `myhome/common/pumps/water_supply_station/control` |

Преимущества хорошей структуры:

• Независимость от оборудования: Если вы замените датчик Wiren Board на Zigbee-датчик, вам нужно будет изменить только один небольшой поток-адаптер в Node-RED, а вся основная логика, подписанная на семантический топик `myhome/floor1/bathroom/sensors/water_leak`, останется без изменений.
• Читаемость и поддержка: Топик сам по себе описывает, за что он отвечает. Это упрощает отладку и расширение системы.
• Гибкое управление: Можно легко отключить все розетки на первом этаже, отправив одну команду в топик с использованием wildcards (`myhome/floor1/+/sockets/control`).

---

Реализация логики в Node-RED

Теперь, когда архитектура топиков спроектирована и оборудование настроено, перейдем к созданию потока в Node-RED, который реализует ядро сценария «Протечка».

Задача: При получении сообщения о протечке из топика датчика, немедленно отправить команды на отключение в топики реле, управляющих насосом и розетками в "мокрой зоне".

Построение потока (Flow)

Ниже представлена ASCII-схема и пошаговое описание простого, но эффективного потока для данной задачи.

// Flow: Water Leak Safe-State
// Listens for a leak sensor signal and de-energizes critical loads.

[mqtt in]──────────────────[switch]─┬─(is leak: '1')──[change]─┬─[mqtt out] (to Pump Relay)
(sensor topic)             (check payload)│                    (set OFF cmd) │
                                          └─(is normal: '0')─(do nothing)  ├─[mqtt out] (to Sockets Relay)
                                                                           │
                                                                           └─[function]───[telegram sender]
                                                                             (format msg)  (send notification)

1. Узел `mqtt in`: Подписка на датчик

Это точка входа нашего сценария.

• Настройка:

* Server: Выберите ваш локальный MQTT-брокер (обычно `localhost:1883`).

* Topic: Укажите топик вашего датчика протечки. Для начала используем системный топик: `/devices/wb-mwac_8/controls/Digital_Input_1`.

* QoS: `2` — для максимальной гарантии доставки сигнала.

* Output: `a parsed JSON object` (если датчик отправляет JSON) или `a string` (если `0`/`1`). Для стандартных датчиков Wiren Board это будет строка.

2. Узел `switch`: Анализ сигнала

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

• Настройка:

* Property: `msg.payload`.

* Правила (Rules):

1. `==` (string) `1` → выход 1 (обнаружена протечка)

2. `==` (string) `0` → выход 2 (норма, протечки нет)

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

3. Узел `change`: Формирование команды на отключение

Когда с узла `switch` приходит сигнал о протечке, нам нужно подготовить команду для реле. Мы будем использовать один узел `change` для создания универсальной команды, а уже узлы `mqtt out` направят её по нужным адресам.

• Настройка:

* Правила (Rules):

* `Set` `msg.payload` `to` (string) `0`.

> ℹ️ Информация: Мы устанавливаем `msg.payload` в строку `'0'`, так как именно это значение команда `/on` для реле Wiren Board интерпретирует как "выключить". Это сообщение будет отправлено всем подключенным к выходу этого узла `mqtt out` узлам.

4. Узлы `mqtt out`: Отправка команд на реле

К выходу узла `change` мы подключаем столько узлов `mqtt out`, сколько групп нагрузки нам нужно отключить.

• Узел `mqtt out` для насоса:

* Server: `localhost:1883`.

* Topic: `/devices/wb-mr6c_25/controls/K2/on`.

* QoS: `2`.

* Retain: `false`.

• Узел `mqtt out` для розеток ванной:

* Server: `localhost:1883`.

* Topic: `/devices/wb-mr6c_25/controls/K1/on`.

* QoS: `2`.

* Retain: `false`.

Теперь, как только датчик пришлет `1`, `switch` направит поток, `change` сформирует команду `0`, и эта команда будет одновременно отправлена в топики управления реле насоса и розеток, мгновенно их обесточивая.

5. Пример кода для узла `function` (уведомление):

Этот узел подключается после `change` и перед узлом отправки в Telegram (`telegram sender`). Его задача — создать человекочитаемый текст сообщения.

// Входящий msg уже содержит payload '0' от узла change.
// Мы можем добавить в него информацию о том, какой датчик сработал,
// если настроили узел mqtt in на отправку topic в msg.topic.

const topics = {
    "/devices/wb-mwac_8/controls/Digital_Input_1": "Ванная, 1 этаж",
    "/devices/wb-mwac_8/controls/Digital_Input_2": "Кухня, посудомойка"
};

let location = topics[msg.topic] || "Неизвестное место";

// Формируем объект для узла telegram sender
msg.payload = {
    chatId: "YOUR_CHAT_ID", // Замените на ваш ID чата с ботом
    type: "message",
    content: `🚨 ВНИМАНИЕ: Протечка воды! 🚨\n\nМесто: ${location}\n\nКритические нагрузки (насосы, розетки) были автоматически отключены. Требуется проверка на объекте.`
};

return msg;

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

---

Уведомления, сброс тревоги и ручное управление

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

⚠️ Внимание: Убедитесь, что логика сброса тревоги не создает зацикливания. Например, если сигнал с датчика протечки все еще активен (вода не убрана), попытка ручного включения питания должна быть заблокирована системой, чтобы не вызвать немедленное повторное аварийное отключение и не отправлять дублирующие уведомления.

1. Интеграция PUSH-уведомлений

Как мы видели в предыдущем разделе, отправка уведомлений является неотъемлемой частью сценария. Самый распространенный способ — использование Telegram-бота.

Установите палитру `node-red-contrib-telegrambot`.

Создайте нового бота в Telegram через `@BotFather` и получите токен.

В Node-RED создайте узел конфигурации `telegram bot`, указав в нем полученный токен.

Используйте узел `telegram sender` в связке с узлом `function`, который формирует текст сообщения (см. пример в предыдущей секции).

2. Логика хранения и сброса состояния тревоги

Простая логика "датчик сработал -> отключили" имеет недостаток: что произойдет, когда вода высохнет и датчик отправит `0`? Система не должна автоматически включать обратно потенциально опасные розетки. Включение должно быть осознанным действием пользователя.

Для этого вводится понятие состояния тревоги, которое хранится в контексте потока (flow context).

Установка состояния тревоги: В ветке потока, где обрабатывается протечка (после `switch`), добавьте узел `change` для установки переменной контекста:

* `Set` `flow.water_alarm_status` `to` (string) `ALARM`.

Защита от авто-включения: Теперь нам нужен механизм, который позволит включить реле обратно, но только вручную.

3. Реализация ручного управления и сброса

Создадим отдельный небольшой поток для обработки ручного сброса тревоги с панели HMI (например, iRidium или Home Assistant).

• Шаг 1: Создание MQTT-топика для сброса.

В HMI создается кнопка "Сброс тревоги по протечке". При нажатии она публикует сообщение, например, `1`, в специальный топик: `myhome/alarms/water_leak/reset`.

• Шаг 2: Поток сброса в Node-RED.

// Flow: Manual Water Alarm Reset

[mqtt in]─────────────────[switch]──────────────[function]──────────────────┬─[mqtt out] (to Pump Relay)
(reset topic)        (is alarm active?)    (check sensor status)            │ (send ON cmd)
                                                                            ├─[mqtt out] (to Sockets Relay)
                                                                            │
                                                                            └─[change] (reset alarm state)

`mqtt in`: Подписывается на топик `myhome/alarms/water_leak/reset`.

`switch`: Проверяет, находится ли система в состоянии тревоги.

* Property: `flow.water_alarm_status`.

* Правило: `==` `ALARM`. Если тревоги нет, ничего не делаем.

`function` "Проверить датчик": Это ключевой узел, который предотвращает включение питания, если протечка не устранена. Он должен прочитать текущее значение с датчика.

    // Получаем текущее состояние датчика из контекста,

    // которое обновляется в другом потоке.
    // Предполагается, что отдельный поток пишет состояние датчика в flow.leak_sensor_bathroom_1
    let sensor_state = flow.get("leak_sensor_bathroom_1");

    if (sensor_state === '1') {
        // Протечка еще активна! Блокируем сброс.
        node.warn("Попытка сброса тревоги при активной протечке!");

        // Можно отправить уведомление пользователю об ошибке.
        msg.payload = {
            chatId: "YOUR_CHAT_ID",
            type: "message",
            content: "❌ Ошибка: Невозможно включить питание. Датчик все еще фиксирует протечку."
        };
        // Отправляем на отдельный выход, подключенный к telegram sender.
        return [null, msg]; 
    }

    // Если датчик в норме ('0'), формируем команду на включение.
    msg.payload = '1';
    return [msg, null];
    

`mqtt out`: Отправляют команду `'1'` (включить) в топики управления реле.

`change` "Сброс статуса": После успешного включения реле, сбрасываем состояние тревоги.

* `Set` `flow.water_alarm_status` `to` (string) `NORMAL`.

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

---

Итоги и лучшие практики

В этом уроке мы разработали комплексный сценарий "Safe-State" для обнаружения и реагирования на протечку воды. Мы прошли весь путь: от физического подключения датчика и проектирования архитектуры MQTT до реализации логики в Node-RED и создания механизма безопасного сброса тревоги.

Краткий обзор сценария

Датчик протечки фиксирует аварию и передает сигнал на контроллер.

Контроллер публикует состояние датчика в MQTT-топик.

Node-RED получает сообщение, анализирует его и мгновенно отправляет команды на отключение реле, управляющих насосами и розетками в "мокрой зоне".

Одновременно пользователю отправляется PUSH-уведомление с деталями аварии.

Система переходит в состояние тревоги (`flow.water_alarm_status = 'ALARM'`), блокируя любое автоматическое включение питания.

После устранения протечки пользователь нажимает кнопку "Сброс" в HMI.

Node-RED проверяет, что датчик больше не фиксирует воду, и только после этого включает питание и сбрасывает состояние тревоги в `NORMAL`.

Лучшие практики внедрения и эксплуатации

• Периодическое тестирование: Не реже одного раза в квартал проводите имитацию протечки (смочив контакты датчика чистой водой), чтобы убедиться в работоспособности всей цепочки — от датчика до отключения реле и получения уведомления.
• Документирование: Всегда ведите актуальную карту MQTT-топиков и прикладывайте к проекту Node-RED схемы и описания потоков. Это сэкономит часы при последующем обслуживании или модернизации.
• Интуитивный интерфейс HMI: Кнопки управления аварийными сценариями в панели визуализации должны быть четко обозначены, иметь защиту от случайного нажатия и предоставлять пользователю обратную связь (например, менять цвет при активации тревоги).
• Физический "последний рубеж": Напоминайте заказчику, что автоматика — это важный, но не единственный уровень защиты. Наличие легкодоступных ручных шаровых кранов для перекрытия воды является обязательным элементом надежной системы.

Сравнение со сценарием «Пожарная тревога»

Сравнивая данный сценарий со сценарием «Пожарная тревога», рассмотренным в уроке `COURSE-06-M07-L02`, можно выявить общие архитектурные паттерны реализации 'Safe-State':

| Критерий | Сценарий «Протечка» | Сценарий «Пожарная тревога» | Общий паттерн |

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

| Триггер | Датчик протечки (`1`/`0`) | Пожарный извещатель (сухой контакт, шлейф) | Сигнал от специализированного датчика аварии. |

| Основное действие | Отключение насосов и розеток в "мокрых зонах" | Отключение вентиляции, опасных розеток, разблокировка СКУД | Групповое отключение/переключение критической нагрузки. |

| Хранение состояния | `flow.context` (`ALARM`/`NORMAL`) | `flow.context` (`FIRE_ALARM`/`NORMAL`) | Использование конечного автомата (FSM) на базе контекста. |

| Сброс тревоги | Ручной, с проверкой состояния датчика | Ручной, с проверкой состояния пожарного шлейфа | Только ручное подтверждение после устранения угрозы. |

| Уведомление | PUSH-уведомление в Telegram | PUSH-уведомление, сирена | Многоканальное оповещение персонала/владельца. |

Этот анализ показывает, что принципы построения отказоустойчивых аварийных сценариев универсальны. Освоив данный паттерн, вы сможете эффективно реализовывать любые системы безопасности на платформе HI.

Что дальше

В следующем уроке мы рассмотрим более сложные сценарии 'Safe-State', включающие управление климатическим оборудованием и интеграцию с системами бесперебойного питания (ИБП) для обеспечения максимальной надежности объекта.