Сценарий 'Пожарная тревога': отключение вентиляции, розеток

Урок 1 · Введение в протоколы автоматизации · 30 мин · theory

Архитектура сценария 'Пожарная тревога': от датчика до исполнителя

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

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

1. Источник события: Пожарные датчики

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

Дымовые (оптические): Реагируют на частицы дыма в воздухе.
Тепловые: Срабатывают при резком повышении температуры или достижении порогового значения.
Комбинированные: Совмещают в себе несколько технологий для повышения точности и снижения ложных срабатываний.

Для нашей платформы HI не имеет значения, какой именно тип датчика используется. Важно, что он подключен к модулю, способному передать его состояние в общую информационную шину. Чаще всего этот модуль транслирует сигнал о тревоге по протоколу MQTT, который является стандартом для IoT-коммуникаций на наших контроллерах. Таким образом, пожарный датчик является первоначальным триггером, запускающим всю цепочку событий.

2. Транспорт и маршрутизация: Протокол MQTT

Получив сигнал от датчика, модуль-передатчик формирует MQTT-сообщение и отправляет его на центральный MQTT-брокер, работающий на контроллере HI. На этом этапе критически важна надежность доставки.

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

> * QoS (Quality of Service) 0: "Отправил и забыл". Доставка не гарантируется. Неприемлемо для систем безопасности.

> * QoS 1: "Доставлено как минимум один раз". Сообщение будет доставлено, но возможны дубликаты. Это приемлемый минимум для сообщений о тревоге.

> * QoS 2: "Доставлено ровно один раз". Самый надежный уровень, исключающий потерю и дублирование. Рекомендуется для критически важных команд.

Сообщение о пожарной тревоге обязательно должно отправляться с уровнем QoS 1 или QoS 2. Это гарантирует, что даже при кратковременных сбоях в сети сигнал тревоги не будет потерян и в конечном итоге достигнет центрального контроллера.

3.Централизованная логика: Node-RED на контроллере HI

Контроллер HI, получив MQTT-сообщение, передает его в среду исполнения Node-RED. Именно здесь сосредоточен "мозг" всей системы автоматизации. Поток (flow) в Node-RED, подписанный на соответствующие MQTT-топики, принимает сообщение о тревоге и запускает каскад заранее запрограммированных действий. Это позволяет централизованно и гибко управлять реакцией системы, не зашивая логику в каждое оконечное устройство.

4. Исполнители: Реле и модули управления

Последним звеном в цепи являются исполнительные устройства. В нашем сценарии это:

Модуль управления приточной вентиляцией: Подключен к контроллеру по шине Modbus. Его задача — немедленно прекратить подачу свежего воздуха (кислорода) в помещение, чтобы замедлить распространение огня.
Реле управления розеточными группами: Это встроенные реле контроллера HI или внешние релейные модули, управляемые по MQTT. Их задача — обесточить некритичные потребители, чтобы предотвратить короткие замыкания в поврежденной проводке и снизить риск возгорания электроприборов.

Таким образом, полная цепочка выглядит так:

Датчик -> MQTT -> Node-RED -> Modbus/MQTT -> Исполнительные устройства

Эта архитектура обеспечивает надежность, масштабируемость и простоту обслуживания, так как вся сложная логика сосредоточена в одном месте (Node-RED), а взаимодействие между компонентами стандартизировано.

---

Получение сигнала 'Пожар' по MQTT: топики и структура payload

Первым практическим шагом в реализации нашего сценария является настройка Node-RED на прием и корректную обработку сигнала тревоги. Для этого мы будем использовать узел `mqtt in`.

ஸ்டாண்டர்டிசேஷன் MQTT-топиков

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

`project_name/location/class/device_id/property`

Пример: `myhome/floor1/safety/smoke_detector_01/status`
Пример для групповой подписки: `myhome/+/safety/+/status`

Такой подход позволяет нам с помощью одного узла `mqtt in`, настроенного на подписку с использованием wildcard (`+`), получать сигналы от всех пожарных датчиков в системе, независимо от их расположения.

Настройка узла `mqtt in`

Перетащите узел `mqtt in` на холст Node-RED.

Откройте его настройки. В поле `Topic` укажите топик для подписки, например, `hi/+/safety/+/alarm`. Это позволит ловить сигналы от всех датчиков безопасности.

Установите `QoS` в значение `1` или `2` для гарантии получения сообщения.

В поле `Server` выберите ваш локальный MQTT-брокер.

Анализ `msg.payload` и маршрутизация

После получения сообщения его необходимо проанализировать. Формат `msg.payload` от датчика может быть разным, но чаще всего это либо простое булево значение, либо JSON-объект.

| Формат `msg.payload` | Пример | Преимущества / Недостатки |

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

| Boolean | `true` | Простота. Но не несет дополнительной информации (какой датчик, когда сработал). |

| JSON (рекомендуемый) | ```json { "state": "ALARM", "source": "smoke_detector_living_room", "ts": 1678886400000 } ``` | Информативность. Содержит все необходимые данные для логирования и принятия решений. |

Вне зависимости от формата, следующим шагом является узел `Switch`, который будет выполнять роль фильтра. Он должен проверять `msg.payload` (или `msg.payload.state` для JSON) на значение, соответствующее тревоге (`true`, `"ALARM"`, `"ON"`). Сообщения, прошедшие проверку, отправляются дальше по цепочке для запуска исполнительных механизмов. Все остальные сообщения (например, `false` или `"OK"`) игнорируются или направляются на ветку "Отбой тревоги".

ASCII-схема потока:

           +-----------+    +-------------------------+    +----------------------------+
[mqtt in]--|  Function |----|         Switch          |----|  Дальнейшая логика тревоги |
           | (Парсинг) |    | (Проверка на "ALARM")   |    +----------------------------+
           +-----------+    +-------------------------+
                                        | (иначе)
                                        +---------------->  [Логика "Отбой тревоги"]

⚠️ Внимание: Использование Retain-флага для топиков тревоги может привести к ложному срабатыванию сценария после перезагрузки брокера или Node-RED. Если датчик отправил сообщение `"ALARM"` с флагом `retain`, это сообщение "залипнет" на брокере. Когда ваш контроллер или Node-RED перезапустится и снова подпишется на этот топик, он немедленно получит старое сообщение о тревоге и запустит сценарий, даже если реальной опасности уже нет. Рекомендуется отправлять статусы без флага `retain` и реализовывать механизм запроса текущего состояния устройств при старте системы.

---

Логика в Node-RED: Отключение приточной вентиляции по Modbus

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

Определение адресов и команд Modbus

Прежде чем настраивать Node-RED, необходимо изучить карту регистров Modbus-устройства, которое управляет вентиляцией. Чаще всего это релейный модуль (например, Wirenboard WB-MR6C) или напрямую частотный преобразователь. В документации нам нужно найти:

Slave ID (Unit ID): Уникальный адрес устройства на шине RS-485. Например, `45`.

Адрес регистра управления: Регистр, запись в который включает/выключает оборудование. Например, для реле это может быть Holding Register с адресом `128` (что в запросе будет `128`, если нумерация с 0, или `127`, если с 1 - см. документацию).

Значение для отключения: Обычно это `0`.

> ℹ️ Информация: Управление реле на модулях Wirenboard по Modbus часто осуществляется записью `1` (включить) или `0` (выключить) в соответствующий Holding Register (функция `0x06` или `0x10`).

Настройка потока в Node-RED

Для отправки команды мы используем узлы `Function` и `modbus-write` из палитры `node-red-contrib-modbus`.

Узел `Function`: Его задача — сформировать правильное сообщение для узла `modbus-write`. Он получает на вход сигнал тревоги и на выходе создает `msg` с параметрами для Modbus-команды.

Пример кода для узла `Function`:

// Сценарий: отключить вентиляцию. // Устройство: релейный модуль с Slave ID = 45. // Регистр: Holding Register 128 отвечает за реле №1. // Команда: записать значение 0. // Формируем payload для узла modbus-write. // value - это массив значений для записи. msg.payload = { 'value': 0, // Значение 0 для отключения 'fc': 6, // FC 6: Write Single Holding Register 'unitid': 45, // Slave ID нашего релейного модуля 'address': 128, // Адрес регистра 'quantity': 1 // Количество регистров для записи }; // Обновляем статус узла для визуальной диагностики node.status({ fill: "red", shape: "dot", text: "Отправка команды ОТКЛ вент." }); return msg;

Узел `modbus-write`: Этот узел принимает сформированное сообщение и отправляет его в шину RS-485.

* В настройках узла выберите предварительно сконфигурированный Modbus-клиент для вашей шины RS-485.

* Все остальные параметры (адрес, значение и т.д.) узел возьмет из `msg.payload`, который мы подготовили в предыдущем узле.

Важность обратной связи

После узла `modbus-write` необходимо добавить логику для обработки результата. Узел `modbus-write` имеет два выхода:

Верхний выход: Срабатывает при успешной отправке и получении подтверждения от устройства. Сообщение на этом выходе означает, что команда выполнена. Это событие необходимо залогировать.
Нижний выход: Срабатывает при ошибке (например, устройство не отвечает, ошибка CRC). Это критическая ситуация. Сигнал с этого выхода должен идти на узел `Catch` или в отдельный поток, который отправит аварийное уведомление администратору системы (например, через Telegram или SMS), так как ключевое действие по обеспечению безопасности не было выполнено.

ASCII-схема участка потока:

                             +-------------------+    +----------------+
[Сигнал "Тревога"] ---------> | Function          | -> | modbus-write   | ----> [Логирование успеха]
                             | (Формирование msg)|    +----------------+
                             +-------------------+           | (ошибка)
                                                           +--------------> [Уведомление об ошибке]

---

Отключение некритичных розеточных групп по MQTT

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

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

Стратегия выбора отключаемых групп

Ключевым моментом является создание "белого списка" — перечня потребителей, которые не должны отключаться ни при каких обстоятельствах.

> 📋 Типичные потребители в "белом списке":

> * Холодильники и морозильные камеры.

> * Сетевое оборудование (роутеры, коммутаторы).

> * Серверы, системы хранения данных (NAS).

> * Насосное оборудование (циркуляционные, скважинные насосы).

> * Системы охранной сигнализации и видеонаблюдения.

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

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

Для массового управления устройствами, которые общаются по MQTT (например, реле Wirenboard), мы можем использовать цикл в узле `Function`.

💡 Подсказка: Создайте глобальную переменную (global context) в Node-RED, содержащую массив MQTT-топиков для розеток, которые НЕ должны отключаться. Это упростит управление "белым списком" без редактирования самого потока.

Шаг 1. Определяем списки.

В узле `Function` (или при старте Node-RED) определим два массива:

`allSockets`: Полный список топиков управления для всех розеточных групп.

`whiteList`: "Белый список" критичных топиков.

Шаг 2. Формируем список на отключение.

С помощью простого кода отфильтруем первый список, исключив из него элементы второго.

Шаг 3. Отправляем команды.

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

Пример кода для узла `Function`:

// Этот код выполняется при получении сигнала "Тревога"

// Список ВСЕХ топиков управления розетками (control topic)
const allSockets = [
    "hi/devices/wb-mr6c_33/controls/K1",
    "hi/devices/wb-mr6c_33/controls/K2", // Кухня, розетки
    "hi/devices/wb-mr6c_33/controls/K3", // Гостиная, ТВ
    "hi/devices/wb-mr6c_34/controls/K1", // Спальня, розетки
    "hi/devices/wb-mr6c_34/controls/K2", // Холодильник
    "hi/devices/wb-mr6c_34/controls/K3"  // Сервер/Роутер
];

// "Белый список" - розетки, которые НЕ отключаем
const whiteList = [
    "hi/devices/wb-mr6c_34/controls/K2", // Холодильник
    "hi/devices/wb-mr6c_34/controls/K3"  // Сервер/Роутер
];

// Фильтруем список: получаем только те, что нужно отключить
const socketsToTurnOff = allSockets.filter(socket => !whiteList.includes(socket));

// Перебираем полученный список и для каждого формируем и возвращаем сообщение
// Node-RED отправит массив сообщений как последовательность отдельных сообщений
let messages = socketsToTurnOff.map(topic => {
    return {
        topic: topic + "/on", // Стандартный топик для отправки команды
        payload: "0" // Значение для отключения
    };
});

node.status({ fill: "red", shape: "dot", text: `Откл. ${messages.length} розеток` });

// Возвращаем массив сообщений. Каждое будет отправлено на выход узла.
return [messages];

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

Предотвращение пиковой нагрузки

Если вы отключаете большое количество реле одновременно, отправка десятков MQTT-сообщений в один момент может создать кратковременную пиковую нагрузку на сеть или MQTT-брокер. Чтобы этого избежать, после узла `Function` поставьте узел `Delay`. Настройте его в режим "Rate Limit" (ограничение скорости) и установите, например, `10 сообщений в секунду`. Это "растянет" отправку команд во времени, сделав процесс более плавным и надежным.

`[Function]` -> `[Delay (Rate Limit)]` -> `[mqtt out]`

---

Итоги и сценарий 'Отбой тревоги'

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

Обзор полной цепочки сценария

Триггер: Пожарный датчик обнаруживает дым или резкое повышение температуры и отправляет MQTT-сообщение (`"ALARM"`) с QoS 1/2.

Прием: Узел `mqtt in` в Node-RED, подписанный на топик `hi/+/safety/+/alarm`, получает сообщение.

Валидация: Узел `Switch` проверяет, действительно ли это сигнал тревоги, и отсеивает ложные или информационные сообщения.

Действие 1 (Modbus): Запускается ветка отключения вентиляции. Узел `Function` формирует команду для `modbus-write`, который отправляет `0` в регистр управления вентиляционной установкой. Результат выполнения логируется.

Действие 2 (MQTT): Запускается ветка отключения розеток. Узел `Function` генерирует список некритичных розеточных групп, формирует для них команды `OFF` и через узел `Delay` и `mqtt out` последовательно их обесточивает.

Важность тестирования

Аварийные сценарии должны регулярно тестироваться! Необходимо запланировать (например, раз в месяц) процедуру тестового запуска, которая имитирует сигнал тревоги и проверяет, что все исполнительные устройства корректно отработали. Результаты тестов должны автоматически логироваться.

Проектирование сценария 'Отбой тревоги'

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

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

Сценарий "Отбой тревоги" должен включать обязательное ручное подтверждение от ответственного лица. Реализовать это можно несколькими способами:

Виртуальная кнопка: В интерфейсе управления (например, Node-RED Dashboard или мобильное приложение) появляется кнопка "Сбросить тревогу", защищенная паролем.
Физическая кнопка: В помещении охраны или в электрощите устанавливается кнопка или ключевой переключатель, сигнал с которого приходит на дискретный вход контроллера HI.

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

Что дальше

В этом уроке мы заложили основу для системы безопасности. Следующими логичными шагами в ее развитии являются:

Система уведомлений: Настройка отправки SMS, Push-уведомлений или звонков ответственным лицам при срабатывании тревоги и, что не менее важно, при ошибках выполнения сценария (например, если не удалось отключить вентиляцию).
Журналирование (логирование): Создание в базе данных MySQL, доступной на контроллере HI, специальной таблицы для записи всех событий, связанных с безопасностью. Это позволит проводить детальный анализ инцидентов и контролировать работоспособность системы.
Интеграция с другими системами: Подключение сценария к системам контроля доступа (разблокировка эвакуационных выходов) и оповещения (включение сирен и световых табло).

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