SCN-SAFETY-001: Защита от протечки (перекрытие воды, оповещение)

• `hi/main_pipe/water_valve/set`: Командный топик. Отправка сюда `CLOSE` или `OPEN` инициирует действие.
• `hi/main_pipe/water_valve/state`: Статусный топик. Сюда кран (или логика управления им) сообщает свое текущее состояние (`CLOSED`, `OPEN`, `TRANSITIONING`).

Контракт сообщения (Payload)

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

{
  "value": true,
  "ts": 1678886400321,
  "sensor_id": "leak_sensor_bathroom_01",
  "location": "Санузел, 1 этаж"
}

• `value`: Основное значение, `true` для протечки.
• `ts`: Временная метка в формате Unix epoch (ms) для точного определения времени события.
• `sensor_id`: Уникальный идентификатор датчика.
• `location`: Человекочитаемое описание места установки.

Использование флага Retain и QoS

• Retain Flag (Флаг удержания):

* Не применять: Для топиков событий, таких как `.../leak/state`. Если сообщение о протечке будет "удержанным", то после перезагрузки контроллера система может ложно сработать на старое событие. Событие "протечка" должно обрабатываться только в реальном времени.

• Quality of Service (Качество обслуживания):

* QoS 0 или 1: Может использоваться для телеметрии от датчиков. Потеря одного сообщения о состоянии `false` (нет протечки) не является критичной.

Соблюдение этих правил создает надежный информационный фундамент для реализации логики сценария.

---

Практикум: Создание потока автоматизации в Node-RED

Теперь, когда аппаратная часть подключена и MQTT-архитектура спроектирована, мы можем приступить к созданию потока (flow) в Node-RED, который реализует логику сценария SCN-SAFETY-001.

> 🔗 Связанный материал: Логика опроса Modbus-устройств и публикации их состояний в MQTT подробно рассмотрена в модуле по протоколам. В данном уроке мы предполагаем, что данные с датчиков уже поступают в нужные MQTT-топики.

                // Входной сигнал от любого датчика протечки
[MQTT In] --+-->[RBE]--+-->[Function: Формирование команд]--+-->[MQTT Out: Закрыть кран]
hi/+/+/leak/state     |      (только при изменении)        |
                      |                                    +-->[Link Out: На унив. оповещатель]
                      |
                      +-->[Debug]  (для отладки)

Пошаговая реализация

* Server: Выберите ваш MQTT-брокер.

* Topic: Укажите `hi/+/+/leak/state`. Использование wildcards (`+`) позволяет этому узлу слушать все датчики протечки в системе, независимо от их расположения.

* QoS: `1`.

* Output: `a parsed JSON object`.

* Этот узел пропускает сообщение только в том случае, если его `msg.payload.value` отличается от предыдущего. Это ключевой элемент для предотвращения "дребезга" (flapping) и отправки десятков команд, если датчик остается мокрым.

* Mode: `block if value is the same`.

* Property: `msg.payload.value`.

* Подключите его сразу после `MQTT In`. Он будет пропускать только первое сообщение с `{"value": true}` и первое последующее сообщение с `{"value": false}`.

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

* Name: `Авария! Закрыть воду и оповестить`.

* Outputs: `2`.

* Код:

    // Получаем входящее сообщение от датчика

    const leak_msg = msg.payload;

    // Проверяем, что это действительно событие протечки
    if (leak_msg.value === true) {
        // --- Выход 1: Команда на закрытие крана ---
        const valve_command = {
            topic: "hi/main_pipe/water_valve/set",
            payload: "CLOSE", // Команда, понятная логике управления краном
            qos: 2,
            retain: false 
        };

        // --- Выход 2: Сообщение для универсального логгера/оповещателя (урок M08) ---
        const alert_msg = {
            payload: {
                level: "CRITICAL",  // Уровень тревоги для системы оповещений
                event_id: "SCN-SAFETY-001-LEAK",
                message: `ПРОТЕЧКА! Место: ${leak_msg.location || 'Неизвестно'}. Датчик: ${leak_msg.sensor_id}. Вода перекрыта.`,
                context: { // Дополнительные данные для логов
                    sensor_id: leak_msg.sensor_id,
                    location: leak_msg.location,
                    timestamp: leak_msg.ts
                }
            }
        };

        // Выдаем два независимых сообщения на разные выходы
        return [valve_command, alert_msg];
    }

    // Если пришло сообщение {"value": false}, ничего не делаем
    return null;
    

* Подключите к первому выходу узла `Function`.

* Этот узел получит уже полностью сформированное сообщение (с `topic`, `payload`, `qos`) и просто отправит его брокеру. Настройки в самом узле не требуются.

* Подключите ко второму выходу узла `Function`.

* В его настройках укажите ссылку на узел `Link In` вашего универсального потока логирования и оповещений (см. урок M08). Это позволяет не дублировать логику отправки уведомлений в каждом сценарии, а использовать единый, централизованный компонент. Он сам решит, как и куда отправить `CRITICAL` оповещение — в Telegram, по email или включить сирену.

После развертывания этого потока система готова к работе. Любое срабатывание датчика приведет к мгновенному закрытию воды и отправке уведомления через централизованную систему.

---

Итоги и расширение функционала

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

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

Идеи для расширения функционала

Базовый сценарий можно и нужно развивать для повышения удобства и надежности:

• Ручное управление: Добавьте на объекте физическую кнопку "Перекрыть всю воду" и "Открыть воду". Её нажатие будет публиковать соответствующую команду в MQTT-топик `.../water_valve/set`.
• Звуковое оповещение: Параллельно с push-уведомлением активируйте сирену, подключенную к одному из реле контроллера, для привлечения внимания людей, находящихся на объекте.
• Автоматическое открытие: Создайте логику, позволяющую автоматически открыть краны после устранения аварии. Например, после того как все датчики протечки в течение 10 минут показывают состояние `false`, можно отправить команду `OPEN`.
• Интеграция с режимами: Свяжите сценарий с глобальными режимами объекта. Например, при активации режима "Отпуск", система может принудительно перекрывать воду, даже без сигнала о протечке, для превентивной защиты. При возвращении из отпуска вода будет автоматически подана.

Что дальше

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