Сценарий 'Протечка воды': отключение насосов и розеток в мокрой зоне
Цели, задачи и компоненты сценария «Протечка»
🔗 Связанный материал: Для полного понимания принципов 'Safe-State' рекомендуется изучить урок COURSE-06-M07-L01 «Концепция 'Safe-State': что это и зачем нужно».
Сценарий «Протечка» является одним из наиболее критически важных элементов системы автоматизации, нацеленным на предотвращение значительного материального ущерба и минимизацию рисков, связанных с поражением электрическим током. В отличие от сценариев комфорта, его главная задача — не удобство, а немедленное приведение системы в заранее определённое безопасное состояние (Safe-State) при обнаружении аварийной ситуации.
Основная цель сценария — мгновенно обесточить оборудование, контакт которого с водой может привести к катастрофическим последствиям. Это включает в себя как предотвращение коротких замыканий, так и защиту дорогостоящей техники и отделки помещений от затопления.
Ключевые понятия и задачи
📋 Ключевые понятия:
- Мокрая зона: Это не просто ванная комната или санузел, а спроектированная и задокументированная область на объекте, где существует повышенный риск протечки воды. К таким зонам относятся: санузлы, кухни (в области посудомоечной машины и мойки), котельные, постирочные, зоны установки бойлеров и насосных станций.
- Критическая нагрузка: Это перечень электрооборудования, которое должно быть немедленно отключено при обнаружении протечки в соответствующей "мокрой зоне".
Логическая цепочка сценария
Реализация сценария представляет собой последовательную цепочку событий, проходящую через несколько уровней системы автоматизации. Понимание этой цепочки критически важно для проектирования и диагностики.
Этот сценарий является прямой реализацией концепции '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.
* 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` — номер реле.
- Управляющие сообщения:
* Для включения реле — сообщение со значением `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`: Подписка на датчик
Это точка входа нашего сценария.
- Настройка:
* 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`: Анализ сигнала
Этот узел выполняет роль диспетчера, направляя поток в зависимости от полученного сообщения.
- Настройка:
* Правила (Rules):
1. `==` (string) `1` → выход 1 (обнаружена протечка)
2. `==` (string) `0` → выход 2 (норма, протечки нет)
В базовом сценарии мы обрабатываем только первый выход. Второй выход можно использовать для логики сброса, которую мы рассмотрим в следующей секции.
3. Узел `change`: Формирование команды на отключение
Когда с узла `switch` приходит сигнал о протечке, нам нужно подготовить команду для реле. Мы будем использовать один узел `change` для создания универсальной команды, а уже узлы `mqtt out` направят её по нужным адресам.
- Настройка:
* `Set` `msg.payload` `to` (string) `0`.
> ℹ️ Информация: Мы устанавливаем `msg.payload` в строку `'0'`, так как именно это значение команда `/on` для реле Wiren Board интерпретирует как "выключить". Это сообщение будет отправлено всем подключенным к выходу этого узла `mqtt out` узлам.
4. Узлы `mqtt out`: Отправка команд на реле
К выходу узла `change` мы подключаем столько узлов `mqtt out`, сколько групп нагрузки нам нужно отключить.
- Узел `mqtt out` для насоса:
* Topic: `/devices/wb-mr6c_25/controls/K2/on`.
* QoS: `2`.
* Retain: `false`.
- Узел `mqtt out` для розеток ванной:
* 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-бота.
2. Логика хранения и сброса состояния тревоги
Простая логика "датчик сработал -> отключили" имеет недостаток: что произойдет, когда вода высохнет и датчик отправит `0`? Система не должна автоматически включать обратно потенциально опасные розетки. Включение должно быть осознанным действием пользователя.
Для этого вводится понятие состояния тревоги, которое хранится в контексте потока (flow context).
* `Set` `flow.water_alarm_status` `to` (string) `ALARM`.
3. Реализация ручного управления и сброса
Создадим отдельный небольшой поток для обработки ручного сброса тревоги с панели HMI (например, iRidium или Home Assistant).
- Шаг 1: Создание MQTT-топика для сброса.
- Шаг 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)
* Property: `flow.water_alarm_status`.
* Правило: `==` `ALARM`. Если тревоги нет, ничего не делаем.
// Получаем текущее состояние датчика из контекста,
// которое обновляется в другом потоке.
// Предполагается, что отдельный поток пишет состояние датчика в 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];
* `Set` `flow.water_alarm_status` `to` (string) `NORMAL`.
Таким образом, мы создали надежный двухуровневый механизм: система автоматически реагирует на аварию, но возврат в рабочее состояние требует ручного вмешательства и подтверждения, что опасность миновала.
---
Итоги и лучшие практики
В этом уроке мы разработали комплексный сценарий "Safe-State" для обнаружения и реагирования на протечку воды. Мы прошли весь путь: от физического подключения датчика и проектирования архитектуры MQTT до реализации логики в Node-RED и создания механизма безопасного сброса тревоги.
Краткий обзор сценария
Лучшие практики внедрения и эксплуатации
- Периодическое тестирование: Не реже одного раза в квартал проводите имитацию протечки (смочив контакты датчика чистой водой), чтобы убедиться в работоспособности всей цепочки — от датчика до отключения реле и получения уведомления.
- Документирование: Всегда ведите актуальную карту 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', включающие управление климатическим оборудованием и интеграцию с системами бесперебойного питания (ИБП) для обеспечения максимальной надежности объекта.