Сценарии для дома: Защита от протечек

Урок 2 · Основы умного дома · 30 мин · theory

Это Часть 1/2: Содержание урока.

id: COURSE-01-M05-L03
title: "Сценарии для дома: Защита от протечек"
level: foundation
tags:
  - MQTT
  - Node-RED
  - Wirenboard
  - Датчик протечки
  - Шаровый кран с электроприводом
  - Автоматизация
  - MQTT-топики
  - wb-mwac
  - wb-mr6c
  - Безопасность
  - Сценарии
prerequisites:
  - COURSE-01-M03-L02 # Основы Node-RED: Switch и Change
  - COURSE-01-M02-L01 # Что такое сигнал, событие, состояние
version: 1.1
status: published

## COURSE-01-M05-L03 | Введение в системы защиты от протечек

Автоматическая система защиты от протечек — один из наиболее востребованных и критически важных сценариев в современной автоматизации зданий. Последствия даже незначительной протечки воды могут быть катастрофическими: от повреждения отделки и мебели до затопления соседей снизу, что влечет за собой значительные финансовые и временные затраты. Внедрение автоматизированной системы позволяет не просто информировать о проблеме, а мгновенно и автономно её локализовать, минимизируя ущерб.

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

Датчик протечки: Сенсорное устройство, которое обнаруживает наличие воды на контролируемой поверхности (пол в санузле, под раковиной, рядом со стиральной машиной).
Шаровый кран с электроприводом: Исполнительное устройство, которое физически перекрывает подачу воды в системе водоснабжения. Состоит из стандартного шарового крана и электродвигателя (привода), который поворачивает шток крана по команде от контроллера.
Контроллер: "Мозг" системы. В нашем случае это контроллер на базе Linux/Node-RED, который получает сигналы от датчиков и отправляет команды на исполнительные устройства.

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

Обнаружение: Датчик протечки, установленный в потенциально опасной зоне, фиксирует появление воды. Его электрические характеристики изменяются.
Сигнал: Датчик немедленно передает сигнал тревоги на контроллер. В случае с проводными датчиками — это замыкание/размыкание "сухого контакта". В случае с беспроводными — отправка радиосообщения.
Принятие решения: Контроллер получает сигнал. Запущенный на нем сценарий (в нашем случае — flow в Node-RED) анализирует событие.
Исполнение: Контроллер отправляет электрическую команду на реле, которое управляет шаровым краном с электроприводом.
Локализация: Электропривод поворачивает кран в закрытое положение, полностью перекрывая подачу воды в соответствующем контуре (например, на вводе в квартиру). Весь процесс занимает от 5 до 20 секунд.

Сравнение типов датчиков:

Проводные датчики (например, отечественные SWF 4.1, Gidrolock WSP):
    *   Принцип работы: Два или более электродов на основании. При попадании воды между электродами происходит замыкание цепи (резко падает сопротивление).
    *   Плюсы:
        *   Высочайшая надежность: Нет батареек, которые могут сесть; нет проблем с радиосигналом.
        *   Низкая стоимость: Сами датчики очень дешевы.
        *   Простота: По сути, это два проводника. Ломаться практически нечему.
    *   Минусы:
        *   Сложность монтажа: Требуют прокладки кабеля от датчика до контроллера, что легко сделать на этапе ремонта, но сложно в уже готовом интерьере.

Беспроводные датчики (Zigbee, Z-Wave, LoRaWAN):
    *   Принцип работы: Аналогичный проводному (электроды на корпусе), но сигнал об обнаружении воды передается по радиоканалу на соответствующий шлюз или напрямую на контроллер.
    *   Плюсы:
        *   Простота установки: Можно разместить где угодно без прокладки проводов. Идеально для готовых объектов.
    *   Минусы:
        *   Зависимость от батареи: Требуют периодической замены элементов питания. Пропуск момента замены делает датчик бесполезным.
        *   Надежность радиоканала: Возможны помехи, "мертвые зоны", которые могут помешать доставке сигнала тревоги.
        *   Более высокая стоимость: Сам датчик и необходимый для него радиомодуль/шлюз стоят дороже.

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

Выбор и подключение оборудования на базе нашего контроллера

Рассмотрим типовую конфигурацию на базе оборудования Wirenboard, которое полностью совместимо с нашим контроллером и его философией.

1. Подключение проводных датчиков

Для подключения множества проводных датчиков идеально подходит модуль WB-MWAC. Хотя его основное назначение — работа с RFID-считывателями по протоколу Wiegand, его входы (A, B, C, D) могут быть сконфигурированы как универсальные дискретные входы типа "сухой контакт".

Схема подключения:
Датчик протечки имеет два вывода.
Один вывод подключается к клемме `GND` на модуле WB-MWAC.
Второй вывод подключается к одной из клемм входа, например, `Input A`.

В веб-интерфейсе контроллера необходимо зайти в настройки модуля WB-MWAC и для порта, к которому подключен датчик, выставить "Тип устройства" (Device Type) в значение "Discrete input (dry contact)". После сохранения настроек в системе появится соответствующий MQTT-топик, который будет менять свое значение с `0` на `1` при обнаружении протечки.

2. Выбор и подключение шаровых кранов с электроприводом

> ⚠️ Внимание: Крайне важно правильно подобрать блок питания для шаровых кранов. Несоответствие напряжения или мощности может привести к выходу из строя как привода, так и управляющего реле контроллера. Большинство приводов потребляют значительный ток в момент поворота (до 1А и выше).

Ключевые параметры при выборе крана:

Напряжение питания: Самые распространенные — 12В DC, 24В DC и 220В AC. Для низковольтных систем автоматизации предпочтительны краны на 12/24В, так как это безопаснее и позволяет запитать всю систему (контроллер, реле, приводы) от одного источника бесперебойного питания (ИБП).
Тип управления:
    *   2-х проводное управление: Самый простой тип. Подали питание — кран начал закрываться (или открываться). Сняли питание — он вернулся в исходное положение (обычно с помощью пружины). Не очень надежно и энергозатратно.
    *   3-х проводное управление: Наиболее распространенный и надежный вариант. Имеет три провода: "общий" (GND или N), "открыть" и "закрыть". Для открытия подается питание на один управляющий провод, для закрытия — на другой. В конечных положениях привод сам отключает двигатель.
Состояние по умолчанию:
    *   Нормально-открытые (НО/NO): Без питания кран открыт.
    *   Нормально-закрытые (НЗ/NC): Без питания кран закрыт. Для систем защиты от протечек рекомендуется использовать НЗ краны. В случае полного обесточивания объекта (например, сработал автомат защиты или вышел из строя ИБП), такой кран сам перекроет воду.

3. Управление кранами с помощью реле

Для управления 3-х проводным краном на 12/24В идеально подходят релейные модули, такие как WB-MR6C (6 реле) или WB-MRM2-mini (2 реле). Нам потребуется два реле на один кран.

Схема подключения 3-х проводного крана (12В) к WB-MR6C:

Источник питания +12В подключается к клемме `+V` релейного модуля.
`Общий` провод крана подключается к `GND` источника питания.
Провод крана `Открыть` подключается к выходу одного реле (например, `K1`).
Провод крана `Закрыть` подключается к выходу другого реле (например, `K2`).

Таким образом, для открытия воды мы кратковременно (на 20-30 секунд) включаем реле `K1`, а для закрытия — реле `K2`.

После физического подключения и подачи питания, в веб-интерфейсе контроллера появятся соответствующие устройства и их MQTT-топики для управления.

Интеграция с Node-RED через MQTT

Как мы уже знаем из предыдущих уроков, взаимодействие всех компонентов нашей платформы строится на протоколе MQTT. Node-RED выступает в роли клиента, который подписывается на топики с данными (от датчиков) и публикует сообщения в топики для управления (реле).

Структура MQTT-топиков контроллера Wirenboard стандартизирована:
`/devices/{device_id}/controls/{control_id}`

`{device_id}` — уникальное имя устройства, например `wb-mwac_25` или `wb-mr6c_49`.
`{control_id}` — имя конкретного элемента управления, например `Input 1` или `K1`.

1. Подписка на топики датчиков

Чтобы получать состояние датчика протечки, подключенного к первому входу модуля `wb-mwac_25`, мы используем узел `mqtt in` в Node-RED со следующими настройками:
Topic: `/devices/wb-mwac_25/controls/Input 1`
Output: `a string`

При замыкании контактов датчика водой узел сгенерирует сообщение (msg), в котором `msg.payload` будет содержать строку `'1'`. Когда вода высохнет — `'0'`.

2. Отправка команд на управление реле

Для управления реле, к которому подключен привод крана, используется узел `mqtt out`. Чтобы активировать первое реле на модуле `wb-mr6c_49`, нужно опубликовать сообщение со значением `1` в топик, который включает это реле.

Topic: `/devices/wb-mr6c_49/controls/K1/on`
Payload: `1`

Управляющий топик с суффиксом `/on` принимает любое значение для публикации; важен сам факт публикации. Node-RED позволяет использовать `mqtt out` и с базовым топиком `/devices/wb-mr6c_49/controls/K1`, передавая в `msg.payload` значение `'1'` или `'0'`. Оба подхода рабочие.

Контракт сообщения (Message Contract):

Датчик протечки -> Node-RED:

json

{

"topic": "/devices/wb-mwac_25/controls/Input 1",

"payload": "1",

"qos": 0,

"retain": true,

"_msgid": "..."

}

    Где `payload: "1"` означает "протечка", а `payload: "0"` — "сухо".

Node-RED -> Реле крана:

json

{

"topic": "/devices/wb-mr6c_49/controls/K2/on",

"payload": "1",

"_msgid": "..."

}

    Это сообщение отправит команду на включение реле `K2` (закрытие крана).

Создание базового сценария в Node-RED

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

🔗 Связанный материал: Логика работы с узлами `switch` и `change` подробно разбиралась в модуле 'Основы Node-RED'. См. `COURSE-01-M03-L02`.

Пример простого потока (flow):

[Датчик 1 (mqtt in)] ----\

>---- [Проверка на "1" (switch)] ----> [Закрыть краны (change)] ----> [Реле кранов (mqtt out)]

[Датчик 2 (mqtt in)] ----/


Пошаговое создание:

Добавьте узлы `mqtt in`: Создайте по одному узлу для каждого датчика протечки.
    *   `mqtt in` (Датчик Санузел): `Topic: /devices/wb-mwac_25/controls/Input 1`
    *   `mqtt in` (Датчик Кухня): `Topic: /devices/wb-mwac_25/controls/Input 2`

Добавьте узел `switch`: Соедините выходы обоих узлов `mqtt in` со входом узла `switch`. Этот узел будет фильтровать сообщения. Нам интересна только ситуация, когда пришла `'1'`.
    *   Property: `msg.payload`
    *   Rule: `is equal to` -> `1` (строка)

Добавьте узел `change`: Соедините выход узла `switch` со входом узла `change`. Этот узел сформирует команды для закрытия обоих кранов (ХВС и ГВС). Предположим, за закрытие отвечают реле `K1` и `K2`. Мы создадим две команды.
    *   Rules:
        1.  `Set` `msg.payload` `to` `1`
        2.  `Set` `msg.topic` `to` `/devices/wb-mr6c_49/controls/K1/on`
    > 💡 Подсказка: Чтобы отправить вторую команду, можно либо использовать второй узел `change` и `mqtt out`, либо (более элегантно) продублировать сообщение в узле `function` и изменить `msg.topic` для второй копии. Для начала, простой вариант с двумя ветками после `switch` является приемлемым.

Добавьте узлы `mqtt out`: После узла `change` разместите узел `mqtt out`. Он опубликует сформированное сообщение.
       Topic: оставьте пустым, т.к. топик задается в `msg.topic` узлом `change`*.

Пример скелета Flow в формате JSON:

json

[

{

"id": "c1f7b2a3.e049d",

"type": "mqtt in",

"name": "Датчик протечки (Санузел)",

"topic": "/devices/wb-mwac_25/controls/Input 1",

"broker": "...",

"x": 150,

"y": 400,

"wires": [

[

"e5d8a9b2.1c2f18"

]

{

"id": "e5d8a9b2.1c2f18",

"type": "switch",

"name": "Протечка?",

"property": "payload",

"propertyType": "msg",

"rules": [

{

"t": "eq",

"v": "1",

"vt": "str"

}

"checkall": "true",

"repair": false,

"outputs": 1,

"x": 350,

"y": 420,

"wires": [

[

"a1b2c3d4.5e6f78"

]

{

"id": "a1b2c3d4.5e6f78",

"type": "change",

"name": "Подготовить команду ЗАКРЫТЬ КРАН ХВС",

"rules": [

{

"t": "set",

"p": "topic",

"pt": "msg",

"to": "/devices/wb-mr6c_49/controls/K1/on",

"tot": "str"

{

"t": "set",

"p": "payload",

"pt": "msg",

"to": "1",

"tot": "str"

}

"x": 590,

"y": 400,

"wires": [

[

"f9e8d7c6.b5a432"

]

{

"id": "f9e8d7c6.b5a432",

"type": "mqtt out",

"name": "Отправить команду на реле",

"topic": "",

"broker": "...",

"x": 850,

"y": 420,

"wires": []

}

]

Для управления вторым краном (ГВС) от узла `switch` делается аналогичная ветка, но с `msg.topic` для реле `K2`.


Продвинутые функции: уведомления и сервисный режим

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

1. Мгновенные уведомления

Владелец должен немедленно узнать о происшествии. Для этого в наш flow добавляется ветка для отправки уведомлений.
От выхода узла `switch` (который сработал на `'1'`) сделайте еще одно соединение к новому узлу `change` или `function`.
В этом узле сформируйте текст сообщения, например: "ВНИМАНИЕ! Протечка в санузле! Вода перекрыта."
Отправьте это сообщение с помощью специализированных узлов для Telegram, Push-уведомлений (например, через Pushover) или на email.

> 💡 Подсказка: Для надежности, реализуйте два канала уведомлений. Например, push-уведомление и email. Это повысит шансы на своевременное получение сигнала тревоги, если один из каналов будет недоступен.

2. "Сервисный режим" (режим уборки)

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

Логика реализации:

Создайте виртуальный переключатель. Самый простой способ — использовать узлы из `node-red-dashboard` (`ui_switch`). Этот переключатель будет записывать свое состояние (`true`/`false`) в глобальную переменную (контекст).
Настройте узел `ui_switch`:
    *   On-Payload: `true`
    *   Off-Payload: `false`
    *   Соедините его выход с узлом `change`, который будет устанавливать глобальную переменную: `Set` `global.leak_protection_disabled` `to` `msg.payload`.
Добавьте проверку в основной flow. В самом начале нашего сценария защиты от протечек, сразу после узлов `mqtt in`, поставьте узел `switch`, который проверяет значение этой глобальной переменной.
    *   Property: `global.leak_protection_disabled`
    *   Rule 1: `is false` -> идет на выход 1 (подключен к остальной логике)
    *   Rule 2: `is true` -> идет на выход 2 (никуда не подключен, сообщение отбрасывается)

Теперь, перед уборкой, пользователь может в интерфейсе активировать "Сервисный режим", и ложных сработок не будет. Важно не забыть его отключить. Можно добавить таймер, который автоматически отключает этот режим через час.

3. Логика сброса аварии

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

Создайте новый flow, который подписывается на те же топики датчиков.
Используйте узел `switch` для проверки на `msg.payload == '0'`.
Важный момент: Нельзя просто открывать кран, как только один датчик "просох". Нужно убедиться, что все датчики сухие. Это требует более сложной логики, например, с сохранением состояний всех датчиков в контексте.
Простой и надежный вариант — ручной сброс аварии. Создайте кнопку в интерфейсе ("Открыть воду / Сброс аварии"), которая отправит команды на открытие кранов (включит реле, отвечающие за открытие, на 20-30 секунд). Это гарантирует, что пользователь лично убедился в устранении проблемы перед возобновлением водоснабжения.

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

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

Ключевые выводы:

Надежность превыше всего: Для систем безопасности предпочтительны проводные решения.
Используйте стандартные компоненты: Комбинация контроллера, модулей Wirenboard и открытого протокола MQTT дает гибкую и масштабируемую систему.
Node-RED — мощный инструмент: Позволяет визуально программировать сложную логику, интегрировать уведомления и создавать пользовательские интерфейсы для управления.

Лучшие практики и рекомендации:

Регулярное тестирование: Не реже, чем раз в 6 месяцев, проводите полное тестирование системы. Имитируйте протечку (смоченной в воде тканью коснитесь контактов датчика) и убедитесь, что:
    *   Приходит уведомление.
    *   Краны физически закрываются (проверьте, что вода не течет из смесителя).
    *   Работает логика сброса аварии.
Бесперебойное питание (ИБП): Вся система (контроллер, модули ввода-вывода, приводы кранов) должна быть подключена к источнику бесперебойного питания. Система бесполезна, если она обесточена в момент аварии.
Документирование: Заведите документ (или запись в системе управления проектами), где будут указаны:
    *   Электрическая схема подключения кранов и датчиков.
    *   Список MQTT-топиков для каждого датчика и реле управления кранами.
    *   Скриншоты или экспорт JSON-кода ваших потоков Node-RED с комментариями.
    *   Инструкция для конечного пользователя по использованию сервисного режима и сбросу аварии.

Тщательно спроектированная и задокументированная система защиты от протечек — это гарантия спокойствия для вас и ваших клиентов.

---
Что дальше?

В следующем уроке мы рассмотрим еще один важный аспект безопасности и комфорта — сценарии имитации присутствия и охранные функции.
🔗 Следующий урок: `COURSE-01-M05-L04 | Сценарии для дома: Охранные функции и имитация присутствия`

Это Часть 2/2: Практические задания, тест и runbook.

---

COURSE-01-M05-LAB01: Создание базового сценария защиты от протечек

Цель: Научиться создавать в Node-RED минимально рабочий поток (flow) для автоматического перекрытия одного крана при срабатывании одного датчика протечки.

Оборудование (виртуальное или физическое):
Контроллер с Node-RED.
Узел `mqtt in` для имитации датчика протечки.
Узел `mqtt out` для имитации реле крана.
Узел `debug` для отслеживания сообщений.

Задание:
Создайте поток, который подписывается на MQTT-топик `home/livingroom/floor/water_sensor`.
При получении в этом топике сообщения со значением `LEAK_DETECTED`, поток должен отфильтровать это событие.
После фильтрации поток должен сформировать новое сообщение для управления реле.
Новое сообщение должно быть опубликовано в топик `home/valves/main_water/set`.
Контракт управляющего сообщения: `msg.payload` должен быть JSON-объектом вида `{"state": "CLOSE", "trigger_id": "c1f7b2a3"}`. Значение `trigger_id` должно быть ID сообщения, инициировавшего событие.

Скелет потока (ASCII):

[Inject (имитация)] -> [mqtt out (на датчик)]

[mqtt in (датчик)] -> [switch (проверка 'LEAK_DETECTED')] -> [change (формирование команды)] -> [mqtt out (реле)] -> [debug]


Чек-лист выполнения:
[ ] Создан узел `mqtt in` с топиком `home/livingroom/floor/water_sensor`.
[ ] Создан узел `switch`, который пропускает сообщения только если `msg.payload` равен `LEAK_DETECTED`.
[ ] Создан узел `change` или `function`, который устанавливает `msg.topic` в `home/valves/main_water/set`.
[ ] Тот же узел `change` или `function` формирует `msg.payload` в формате JSON `{"state": "CLOSE", "trigger_id": ...}`.
[ ] Создан узел `mqtt out`, который отправляет сформированное сообщение.
[ ] При имитации протечки в узле `debug` видно корректное управляющее сообщение.

Рубрика оценивания:
3 балла (неудовлетворительно): Поток не работает или не соответствует заданию.
6 баллов (удовлетворительно): Поток работает, но контракт сообщения для реле не соблюден (например, отправляется простая строка вместо JSON).
10 баллов (отлично): Поток полностью соответствует заданию, все топики и контракты сообщений корректны.

---

COURSE-01-M05-LAB02: Усложнение сценария: Сервисный режим и уведомления

Цель: Модифицировать базовый сценарий, добавив в него сервисный режим и отправку уведомлений, что делает систему пригодной для реальной эксплуатации.

Оборудование:
Поток, созданный в `LAB01`.
Узел `ui_switch` из `node-red-dashboard` (если доступен) или два узла `inject` для имитации включения/выключения сервисного режима.
Узел `function` для имитации отправки уведомления.

Задание:
Добавьте в интерфейс (или сымитируйте) переключатель "Сервисный режим".
Состояние этого переключателя должно сохраняться в глобальной переменной `global.water_protection_service_mode` (`true`/`false`).
Модифицируйте основной поток так, чтобы он не срабатывал, если `global.water_protection_service_mode` равен `true`.
Добавьте в поток новую ветку, которая после обнаружения протечки (и если сервисный режим выключен) формирует текстовое сообщение и выводит его в `debug`. Текст сообщения: `ALARM! Water leak detected at {topic}! Trigger ID: {id}`. `{topic}` и `{id}` должны быть взяты из исходного сообщения от датчика.
Добавьте ручной сброс аварии: создайте кнопку (узел `inject`), которая отправляет в топик `home/valves/main_water/set` команду `{"state": "OPEN"}`.

Чек-лист выполнения:
[ ] Реализован механизм установки глобальной переменной `global.water_protection_service_mode`.
[ ] Основной поток блокируется, если переменная `global.water_protection_service_mode` равна `true`.
[ ] При срабатывании в `debug` выводится корректно сформированное сообщение о тревоге.
[ ] Реализована кнопка для ручного открытия крана после устранения аварии.
[ ] Вся логика работает корректно при последовательном тестировании: штатный режим -> тревога -> сервисный режим -> попытка тревоги (блокируется) -> отключение сервисного режима -> сброс аварии (открытие крана).

Рубрика оценивания:
3 балла: Реализована только одна из новых функций (либо сервисный режим, либо уведомление).
6 баллов: Реализованы и сервисный режим, и уведомление, но есть ошибки в логике (например, неверно читается глобальная переменная).
10 баллов: Все пункты задания выполнены корректно, логика надежна и предсказуема.

---

COURSE-01-M05-QUIZ: Тест по модулю "Защита от протечек"

Инструкция: Выберите один правильный вариант ответа.

Какое основное преимущество проводных датчиков протечки перед беспроводными?
    a) Проще в установке
    b) Не требуют прокладки кабеля
    c) Выше надежность из-за отсутствия батарей и радиопомех
    d) Работают только с Zigbee

Какой тип шарового крана с электроприводом наиболее предпочтителен для системы безопасности?
    a) Нормально-открытый (НО) на 220В
    b) Нормально-закрытый (НЗ) на 12/24В
    c) С ручным управлением без привода
    d) Любой, это не имеет значения

Для чего в сценарии Node-RED используется узел `switch` сразу после `mqtt in` от датчика?
    a) Для отправки команды на реле
    b) Для фильтрации сообщений (например, чтобы реагировать только на '1')
    c) Для переключения питания контроллера
    d) Для форматирования полезной нагрузки (payload)

Что такое "Сервисный режим" в контексте защиты от протечек?
    a) Режим, в котором система постоянно отправляет тестовые уведомления
    b) Полное отключение контроллера от сети
    c) Временное отключение автоматического срабатывания для проведения уборки
    d) Режим автоматического открытия кранов каждые 24 часа

Для управления одним 3-х проводным краном "открыть/закрыть" сколько реле обычно требуется?
    a) Одно
    b) Два
    c) Три
    d) Ни одного, кран подключается напрямую к контроллеру

Какой MQTT-топик используется для отправки команд на включение реле в Wirenboard?
    a) `/devices/wb-mr6c_49/controls/K1`
    b) `/devices/wb-mr6c_49/controls/K1/on`
    c) `/devices/wb-mr6c_49/status`
    d) `/devices/wb-mr6c_49`

Почему критически важно подключать систему защиты от протечек к ИБП (UPS)?
    a) Чтобы экономить электроэнергию
    b) Чтобы система могла работать и перекрыть воду даже при отключении электричества в здании
    c) Этого требуют правила пожарной безопасности
    d) ИБП защищает от короткого замыкания

Как лучше всего реализовать сброс аварии и открытие кранов после протечки?
    a) Автоматически, как только датчик покажет '0'
    b) По таймеру, через 1 час после срабатывания
    c) Посредством ручной команды от пользователя (кнопка в интерфейсе)
    d) Система сама откроет краны при перезагрузке контроллера

Вы хотите, чтобы при срабатывании любого из трех датчиков (кухня, санузел 1, санузел 2) перекрывались оба крана (ХВС и ГВС). Как это эффективнее всего реализовать в Node-RED?
    a) Создать три отдельных, не связанных друг с другом потока.
    b) Соединить выходы трех узлов `mqtt in` (от датчиков) ко входу одного узла `switch`.
    c) Подписать один узел `mqtt in` на три топика сразу.
    d) Подключить все датчики к одному входу контроллера.

Что является "контрактом сообщения" для датчика протечки в нашем примере?
    a) Физический кабель, соединяющий датчик и контроллер.
    b) Формат данных (`'1'` - протечка, `'0'` - сухо), которые он отправляет.
    c) Напряжение питания датчика.
    d) Гарантийные обязательства производителя.

---

Мини-runbook: Если не работает защита от протечек

| Симптом                                       | Возможная причина                                               | Действия по диагностике и устранению                                                                                                                                                             |
| --------------------------------------------- | --------------------------------------------------------------- | ------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------------ |
| Датчик не реагирует на воду               | 1. Проблема с подключением. 
2. Неверная настройка входа. | 1. Проверьте физическое подключение провода от датчика к клеммам контроллера. 
2. В веб-интерфейсе убедитесь, что тип входа установлен в "сухой контакт". 
3. Замкните вход пинцетом, проверьте реакцию в MQTT. |
| Датчик сработал, но кран не закрылся      | 1. Ошибка в логике Node-RED. 
2. Проблема с реле или приводом. | 1. Откройте Node-RED. С помощью узла `debug` посмотрите, доходит ли сообщение от `switch` до `mqtt out`. Проверьте правильность MQTT-топика и payload. 
2. Вручную в веб-интерфейсе включите реле. Слышен ли щелчок? Подается ли напряжение на привод? |
| Кран не закрывается даже при ручном включении реле | 1. Нет питания на приводе крана. 
2. Неисправен привод или реле. | 1. Проверьте блок питания, к которому подключены приводы. Проверьте предохранители.
2. Мультиметром измерьте напряжение на выходе реле в момент его включения. Если напряжение есть, проблема в приводе. Если нет — в реле.          |
| Система срабатывает во время уборки (ложная тревога) | Не активирован или не реализован "Сервисный режим".         | 1. Перед уборкой активируйте "Сервисный режим" в интерфейсе. 
2. Если режима нет, обратитесь к `LAB02` и реализуйте его.                                                                              |
| После устранения протечки вода не включается | Не реализована или не используется логика сброса аварии.       | 1. Убедитесь, что все датчики сухие (значение '0' в MQTT). 
 2. Нажмите кнопку "Сброс аварии" / "Открыть воду" в интерфейсе. 
3. Если кнопки нет, обратитесь к `LAB02` для ее реализации.                               |