Главная → Академия → Сценарии умного дома: режимы, состояния, приоритеты → SCN-SAFETY-003: Контроль датчиков дыма/газа

SCN-SAFETY-003: Контроль датчиков дыма/газа

Урок 1 · Сценарии умного дома: режимы, состояния, приоритеты · 30 мин · theory

Архитектура системы контроля дыма и газа

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

> ℹ️ Информация: Установка датчиков дыма и газа регулируется национальными и международными стандартами (например, EN 54, а также локальными строительными нормами и правилами). Всегда сверяйтесь с актуальной нормативной документацией перед проектированием и монтажом.

Классификация датчиков

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

Способы интеграции с контроллером HI

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

| Способ подключения | Преимущества | Недостатки | Тип сигнала |

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

| "Сухой контакт" | Простота, универсальность, совместимость с любыми пожарными панелями и датчиками с релейным выходом. | Низкая информативность (только "Норма" / "Тревога"). Невозможность удаленной диагностики и получения сервисных данных (запыленность, напряжение). | Дискретный вход (UI) контроллера HI. Сигнал: замыкание/размыкание цепи. |

| Цифровая шина RS-485 (Modbus RTU) | Высокая информативность: передача нескольких статусов ("Тревога Дым", "Тревога Газ", "Неисправность", "Тест"), сервисных данных. Возможность контроля целостности линии связи. | Требует более сложной настройки в Node-RED. Необходимость соблюдения правил монтажа шины (топология, терминирование). | Подключение к порту RS-485 контроллера HI. |

| Беспроводные шлюзы (Zigbee, Z-Wave) | Отсутствие проводов, простота монтажа в готовом ремонте. | Зависимость от батареек в датчиках, потенциальные помехи в радиоканале. Требуется дополнительный шлюз для преобразования протокола в MQTT. | Контроллер HI получает данные по MQTT от шлюза (например, Zigbee2MQTT). |

Для критически важных систем безопасности рекомендуемым методом является подключение по шине RS-485 (Modbus RTU), так как он обеспечивает наилучший баланс между информативностью, надежностью и возможностью контроля состояния самого датчика.

Централизованный подход и размещение

Контроллер HI выполняет роль центрального процессора безопасности. В отличие от автономных датчиков, которые могут только издавать звуковой сигнал, контроллер реализует комплексные сценарии:

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

    ---

    Интеграция датчиков по Modbus RTU (RS-485)

    Рассмотрим наиболее надежный и информативный способ интеграции — по промышленной шине RS-485 с использованием протокола Modbus RTU. Этот метод позволяет не только получать сигнал тревоги, но и контролировать исправность самого датчика и линии связи.

    > ⚠️ Внимание: Перед подключением любых устройств к порту RS-485 контроллера HI, убедитесь, что питание контроллера и блока питания датчиков полностью отключено. Неправильное подключение (переполюсовка, подача 230V) может необратимо повредить как порт контроллера, так и сам датчик.

    Подключение и опрос датчика по шине Modbus RTU выполняются аналогично тому, как мы это делали в уроке «Управление вентиляцией по уровню CO₂». Сосредоточьтесь на уникальных для датчика безопасности адресах регистров и Slave ID.

    Интерпретация ответа

    Узел `Modbus-Getter` при успешном опросе вернет массив булевых значений.

    Пример `msg` от узла `Modbus-Getter`: 
    {

      "_msgid": "a1b2c3d4.e5f6g7",
    

      "payload": [
    

        false,
    

        false,
    

        true,
    

        false
    

      ],
    

      "responseBuffer": {
    

        "data": [
    

          false,
    

          false,
    

          true,
    

          false
    

        ],
    

        "buffer": ""
    

      }
    

    }

    В данном примере `msg.payload` представляет собой массив, где каждый элемент соответствует состоянию одного дискретного входа (регистра). Согласно гипотетической карте регистров, это можно интерпретировать так:

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

    ---

    Логика обработки тревог в Node-RED

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

    Фильтрация дребезга и ложных срабатываний

    Кратковременные ложные срабатывания могут быть вызваны помехами на линии или внешними факторами (например, пар из ванной). Чтобы от них избавиться, используется узел `rbe` (Report by Exception).

  • Данные с узла `Modbus-Getter` поступают на узел `Function`, который извлекает только интересующий нас статус тревоги (например, `payload[0]`).
  • Далее сообщение поступает на узел `rbe`. Он пропускает сообщение дальше только в том случае, если его значение (`true` или `false`) отличается от предыдущего. Это отсекает поток одинаковых сообщений.
  • Для защиты от "дребезга контактов" (быстрого переключения `true/false/true`) можно использовать узел `trigger`, настроенный на отправку сигнала тревоги только после того, как состояние `true` удерживается в течение нескольких секунд.

    • Создание конечного автомата (State Machine)

    Для управления сложным состоянием системы безопасности идеально подходит паттерн "Конечный автомат" (FSM). Состояние хранится в контексте потока (flow context), что делает его доступным для всех узлов в рамках текущей вкладки.

    Определим возможные состояния:

    ASCII-схема потока: 
    [Modbus-Getter] -> [Function: Parse] -> [Switch: Event Type] --+-- ('alarm') --> [Change: Set State 'alarm_smoke'] -> [Link Out: To Actions]

                                                                   |
    

                                                                   +-- ('fault') --> [Change: Set State 'fault'] -> [Link Out: To Notifications]
    

                                                                   |
    

                                                                   +-- ('normal')--> [Change: Set State 'normal']
    Узел `Function: Parse`:

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

    /*

    Входящий msg.payload от Modbus-Getter: [false, true, false, false]
    

    [Тревога, Неисправность, Запыленность, Тест]
    

    */
    

    const status = msg.payload;
    

    let event = {
    

        type: "normal",
    

        source: "SENS-SMOKE-02", // ID датчика
    

        details: "All systems clear",
    

        ts: Date.now()
    

    };
    


    if (status[1] || status[2]) { // Неисправность или Запыленность
    

        event.type = "fault";
    

        event.details = "Sensor requires maintenance or is faulty.";
    

    }
    


    if (status[0]) { // Тревога
    

        event.type = "alarm_smoke";
    

        event.details = "Smoke detected!";
    

    }
    


    // Устанавливаем топик для дальнейшей маршрутизации
    

    msg.topic = "safety/event/" + event.type;
    

    msg.payload = event;
    


    // Сохраняем текущее состояние в контекст потока
    

    flow.set("safety_status_" + event.source, event.type);
    


    node.status({fill:"blue", shape:"dot", text: "State: " + event.type});
    

    return msg;
    Стандартизированный объект события `msg.payload`: 
    {

      "type": "alarm_smoke",
    

      "source": "SENS-SMOKE-02",
    

      "details": "Smoke detected!",
    

      "ts": 1678886400000
    

    }

    Такой стандартизированный формат позволяет легко обрабатывать события от разных типов датчиков в последующих сценариях. Узел `Switch` затем может маршрутизировать это сообщение в зависимости от `msg.payload.type` на соответствующий поток действий. Использование контекста потока (`flow.set`) позволяет в любой момент времени знать текущий статус каждого датчика, что полезно для логики агрегации и визуализации.

    ---

    Сценарии немедленного реагирования

    ценарии немедленного реагирования

    Как только система перешла в состояние `alarm_smoke` или `alarm_gas`, она должна выполнить ряд немедленных действий с наивысшим приоритетом, направленных на минимизацию ущерба и обеспечение безопасности людей.

    > 🔗 Связанный материал: Логика управления приоритетами подробно рассматривается в модуле COURSE-07-M02. Рекомендуется повторить урок об использовании глобального контекста для управления общим состоянием системы, что позволяет блокировать низкоприоритетные сценарии.

    Приоритет сценария "Пожар" и логика Hard Override

    Сценарий "Пожар" является сценарием наивысшего приоритета. При его активации в глобальную переменную контекста должно быть установлено соответствующее значение, например, `global.set("System.Mode", "EMERGENCY_FIRE")`.

    Для обеспечения надежной блокировки всех процессов внедряется механизм Hard Override — принудительное прерывание.

    Алгоритм реализации Hard Override:
  • Захват шины (Priority Lock): В момент активации сценария контроллер посылает широковещательную команду (Broadcast) на блокировку локального управления выключателями, чтобы исключить вмешательство пользователя.
  • Остановка таймеров: Скрипт-обработчик итерирует по всем активным программным таймерам (полив, задержки выключения света) и принудительно их очищает (`clearTimeout`).
  • Сброс очереди сообщений: Если в системе используется очередь (Queue), она немедленно очищается от всех команд, кроме команд безопасности.
  • Флаг прерывания: Все остальные сценарии (например, "Кино", "Ночь", "Уход") в своем начале должны проверять значение этой глобальной переменной. Если система в аварийном режиме, они не должны выполняться.
    • // Пример проверки в начале любого низкоприоритетного сценария

    const systemMode = global.get("System.Mode") || "normal";
    


    if (systemMode.startsWith("EMERGENCY")) {
    

        node.warn("Execution blocked by emergency mode: " + systemMode);
    

        return null; // Hard Override: Прекратить выполнение потока
    

    }
    

    //... остальная логика сценария

    Управление электропитанием

    Главная задача — обесточить объект, чтобы предотвратить короткие замыкания и возгорание электропроводки.

  • Отключение групп: Контроллер HI отправляет команды по Modbus или KNX на контакторы или автоматические выключатели с моторным приводом в главном распределительном щите.
  • Формирование команды: Поток Node-RED, получив событие `alarm_smoke`, формирует серию сообщений для узла `Modbus-Write` или `KNX-Write` для отключения всех групп розеток и освещения.
  • Исключения: Критически важно не отключать линии, питающие сам контроллер автоматизации, аварийное освещение, систему дымоудаления и оборудование связи (роутер, GSM-модем). Эти линии должны быть выделены в отдельную, неотключаемую группу.

    • Перекрытие газа

    При получении события `alarm_gas` (а также `alarm_smoke` для перестраховки), система должна немедленно перекрыть подачу газа.

    Управление вентиляцией

    Правильное управление воздушными потоками может замедлить распространение огня и дыма.

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

    Система оповещений и визуализация

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

    > 💡 Подсказка: Для критически важных оповещений используйте несколько независимых каналов. Например, комбинация из Push-уведомления (требует интернет-соединения) и SMS-сообщения (требует только сотовой связи через GSM-модем контроллера HI) значительно повышает надежность доставки тревоги.

    Многоканальные оповещения

    При событии `alarm_smoke` или `alarm_gas` поток Node-RED разветвляется и параллельно отправляет уведомления по всем доступным каналам.

    Пример `msg.payload` для узла Telegram с кнопками: 
    {

        "chatId": "YOUR_CHAT_ID",
    

        "type": "message",
    

        "content": "🔴 ВНИМАНИЕ! ПОЖАРНАЯ ТРЕВОГА! 🔴\n\nДатчик 'SENS-SMOKE-02' в Гостиной зафиксировал дым!",
    

        "options": {
    

            "parse_mode": "Markdown",
    

            "reply_markup": {
    

                "inline_keyboard": [
    

                    [
    

                        { "text": "🔇 Отключить сирену (на 5 мин)", "callback_data": "silence_siren_5m" },
    

                        { "text": "📞 Позвонить в службу 112", "callback_data": "call_112" }
    

                    ]
    

                ]
    

            }
    

        }
    

    }

    Нажатие на эти кнопки будет генерировать в Node-RED новое сообщение, которое можно обработать для выполнения соответствующего действия.

    Локальная сигнализация

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

  • Звуковая сигнализация: Одно из реле контроллера HI подключается к мощной сирене (12V). При тревоге поток Node-RED замыкает это реле.
  • Световая сигнализация: Для привлечения внимания и помощи людям с нарушениями слуха система может запустить световую сигнализацию. Это реализуется отправкой команд "включить на 100% яркости" и "мигать" по шинам DALI или KNX на все или ключевые группы света в доме.

    • Передача данных на UI

    Для отображения статуса на панелях управления (HMI, планшеты, смартфоны) используется MQTT как шина состояний.

  • Узел `Function`: Формирует JSON-объект с деталями статуса системы безопасности.
  • Узел `MQTT Out`: Публикует этот объект в строго определенный топик, на который подписан интерфейс пользователя.
    • Пример: 
        {

          "status": "alarm",
    

          "type": "smoke",
    

          "location": "Гостиная",
    

          "source_id": "SENS-SMOKE-02",
    

          "active_actions": ["power_off", "gas_off", "siren_on"],
    

          "timestamp": 1678886400000
    

        }

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

    ---

    Итоги и тестирование системы

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

    Концептуальная структура полного потока:

    `[Опрос датчиков по Modbus]` -> `[Парсинг и создание события]` -> `[Фильтрация и конечный автомат]` -> `[Проверка приоритета и установка глобального статуса]` -> `[Ветвление на потоки реагирования]`

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

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

    * Тестовая кнопка: Большинство профессиональных датчиков оснащены кнопкой для имитации срабатывания.

    * Тестовый газ: Использование специального аэрозоля ("тестовый газ для дымовых датчиков") позволяет проверить реакцию сенсора в условиях, близких к реальным.

    Чек-лист для пусконаладки

    Перед сдачей объекта инсталлятор должен пройти по следующему чек-листу:

  • [ ] Физические соединения: Проверена полярность A/B на шине RS-485, наличие терминального резистора, надежность всех клеммных соединений.
  • [ ] Адресация Modbus: Все датчики имеют уникальные Slave ID, адреса соответствуют конфигурации в Node-RED.
  • [ ] Опрос данных: Узел `Modbus-Getter` стабильно получает данные, в логах Node-RED нет ошибок связи.
  • [ ] Логика состояний: Имитация тревоги (тестовой кнопкой) корректно переводит конечный автомат в состояние `alarm`. Сброс тревоги на датчике возвращает систему в состояние `normal`.
  • [ ] Исполнительные устройства: Проверено фактическое срабатывание всех исполнительных механизмов при тестовой тревоге:

    • * Контакторы в щите отключают питание.

    * Газовый клапан закрывается.

    * Вентиляция отключается.

    * Сирена и световая сигнализация активируются.

  • [ ] Каналы оповещения: Тестовые Push- и SMS-сообщения успешно доставлены на телефон владельца.
  • [ ] Визуализация: Панель управления корректно отображает статус тревоги и его сброс.
  • [ ] Журналирование: События тревоги и сброса корректно записываются в журнал событий (Audit Trail), как было рассмотрено в предыдущих модулях.

    • Что дальше

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