Сценарии для офиса: Климат и вентиляция

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

Введение: Специфика офисного климат-контроля

> ℹ️ Информация: Согласно санитарным нормам (например, ГОСТ 30494-2011), уровень CO2 в помещениях с постоянным пребыванием людей не должен превышать 800-1000 ppm. Превышение этого порога ведет к усталости, головным болям, снижению концентрации внимания и, как следствие, падению общей продуктивности сотрудников на 15-30%.

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

Ключевые отличия офисных климатических систем:

Масштаб и зонирование: Офис представляет собой сложную среду с зонами разного назначения и плотности людей: шумные open-space, тихие кабинеты, переговорные комнаты с переменным количеством участников, серверные. Каждая зона требует своего подхода к вентиляции и кондиционированию.
Высокая плотность людей: В отличие от дома, в офисе на ограниченной площади концентрируется большое количество людей, каждый из которых является источником тепла, влаги и углекислого газа.
Требования к качеству воздуха: Основным показателем качества воздуха в офисе является не только температура, но и уровень концентрации CO2 (углекислого газа). Именно этот параметр напрямую влияет на самочувствие и работоспособность персонала.
Динамика нагрузки: Нагрузка на климатические системы меняется в течение дня. Утреннее прибытие сотрудников, совещания в переговорных, обеденный перерыв и уход вечером — все это должно учитываться автоматикой.

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

Уровень CO2: Основной триггер для активации приточно-вытяжной вентиляции.

Температура: Входной параметр для управления системами кондиционирования (фэнкойлами) и отопления.

Влажность: Важный параметр комфорта. Слишком сухой воздух (<30%) вызывает дискомфорт слизистых, слишком влажный (>60%) способствует росту плесени и может ощущаться как духота.

Аппаратная база для реализации

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

Контроллер HI (Linux/Node-RED): Выступает в роли центрального логического устройства и Modbus-шлюза. Он собирает данные и отправляет команды.
Датчики с интерфейсом RS-485: Для мониторинга CO2, температуры и влажности в офисных пространствах оптимально использовать промышленные датчики с интерфейсом Modbus RTU по шине RS-485. Этот интерфейс обеспечивает высокую помехоустойчивость и позволяет подключать десятки устройств на одну двухпроводную линию длиной до 1200 метров. Типичный пример — датчик WB-MSW3.
Исполнительные устройства: Управление вентиляцией чаще всего сводится к замыканию реле, которое подает питание на привод вентиляционной установки или на переключатель скоростей вентилятора. Для этого используются встроенные релейные выходы контроллера.

Такая архитектура позволяет создать надежную, масштабируемую и централизованно управляемую систему климат-контроля.

---

Практика: Интеграция датчиков CO2 через Modbus RTU

> ⚠️ Внимание: При подключении нескольких Modbus-устройств на одну шину RS-485 критически важно обеспечить уникальность адресов (Slave ID) для каждого устройства, а также правильное терминирование линии (установка резистора 120 Ом на физически первом и последнем устройствах в шине). Дублирование адресов приведет к коллизиям и полной неработоспособности шины.

Первый и самый важный шаг в автоматизации вентиляции — получение достоверных данных об уровне CO2. В этом разделе мы настроим интеграцию Modbus-датчика с нашим контроллером. Для примера будем использовать условный датчик "Sensor CO2" с адресом `25`.

Шаг 1: Физическое подключение

Подключите датчик к шине RS-485 контроллера, соблюдая полярность: клемма `A` датчика к клемме `A` контроллера, клемма `B` к `B`. Используйте кабель "витая пара".

Подайте питание на датчик, как указано в его документации (обычно 12V или 24V DC).

Установите уникальный Slave ID на датчике. В нашем примере это `25`. Адрес выставляется либо DIP-переключателями на корпусе, либо программно.

Шаг 2: Настройка Modbus-устройства в веб-интерфейсе Wirenboard

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

Перейдите в веб-интерфейс контроллера в раздел `Configs` -> `Hardware Modules Configuration`.

Выберите порт, к которому подключен датчик, например, `/dev/ttyRS485-1`. Убедитесь, что параметры порта (скорость, четность) соответствуют настройкам датчика (стандартно — `9600 8N1`).

Нажмите кнопку `Add device` и выберите из списка шаблон вашего датчика. Если шаблона нет, его можно создать вручную.

В настройках устройства укажите его Modbus address (Slave ID) — `25`.

После сохранения конфигурации контроллер начнет периодически опрашивать датчик.

Шаг 3: Проверка получения данных в MQTT

Главное преимущество такого подхода в том, что контроллер абстрагирует нас от сложностей протокола Modbus. Он опрашивает регистры и публикует их значения в легко читаемые MQTT-топики.

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

`/devices/{имя_устройства}/controls/{имя_параметра}`

Для нашего датчика, который мы назвали `co2_sensor_office`, топики будут такими:

`/devices/co2_sensor_office/controls/co2` — уровень CO2 в ppm.
`/devices/co2_sensor_office/controls/temperature` — температура в °C.
`/devices/co2_sensor_office/controls/humidity` — относительная влажность в %.

Чтобы проверить получение данных:

Используйте любой MQTT-клиент (например, `MQTT Explorer` или узел `mqtt in` в Node-RED).

Подпишитесь на топик с `wildcard`: `/devices/co2_sensor_office/controls/#`.

Вы должны увидеть сообщения, приходящие с интервалом в несколько секунд.

Пример сообщения (`msg`), которое мы получим в Node-RED, подписавшись на топик `/devices/co2_sensor_office/controls/co2`:

{
    "topic": "/devices/co2_sensor_office/controls/co2",
    "payload": "957",
    "qos": 0,
    "retain": true,
    "_msgid": "a1b2c3d4.5e4d3c"
}

> ℹ️ Информация: Обратите внимание, что `payload` приходит в виде строки. Перед выполнением математических сравнений в Node-RED его необходимо будет преобразовать в число с помощью функции `parseInt()` или узла `change`.

Теперь, когда у нас есть стабильный поток данных об уровне CO2 в MQTT, мы можем переходить к созданию логики управления.

---

Практика: Логика управления вентиляцией в Node-RED

> 💡 Подсказка: Используйте узел `rbe` (Report by Exception) сразу после узла `mqtt in`, чтобы поток срабатывал только при реальном изменении значения CO2, а не по таймеру опроса Modbus-устройства. Это значительно снижает нагрузку на систему и упрощает логику, избавляя от обработки дублирующихся значений.

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

Шаг 1: Создание базового потока

Перетащите на поле узел `mqtt in`. Настройте его на подписку на топик с данными CO2:

* Server: Ваш MQTT-брокер.

* Topic: `/devices/co2_sensor_office/controls/co2`

* Output: `a parsed JSON object` (если брокер отправляет JSON) или `a string` (как в нашем примере).

* Name: `CO2 Office Level`

Добавьте узел `rbe` (находится в секции `function`). Он будет пропускать сообщение дальше только если `msg.payload` изменился. Соедините выход `mqtt in` с входом `rbe`.

Добавьте узел `switch` для проверки пороговых значений. Назовите его `Check CO2 Thresholds`. Настройте его следующим образом (предварительно убедившись, что `msg.payload` преобразован в число):

* Property: `msg.payload`

* Правило 1: `>` (is greater than) `900` (Number) -> `Включить вентиляцию`

* Правило 2: `<` (is less than) `750` (Number) -> `Выключить вентиляцию`

Заметьте, что порог выключения (`750 ppm`) ниже порога включения (`900 ppm`). Этот зазор называется гистерезис. Он нужен для того, чтобы система не "дребезжала" — не включала и не выключала вентилятор многократно, когда уровень CO2 колеблется около одного значения (например, 899-901 ppm).

Добавьте два узла `change`, по одному на каждый выход из `switch`.

* Первый (для включения): `Set` `msg.payload` to `1` (Number).

* Второй (для выключения): `Set` `msg.payload` to `0` (Number).

Добавьте узел `mqtt out`. Настройте его на управление реле вентилятора.

* Server: Ваш MQTT-брокер.

* Topic: `/devices/my_relay_module/controls/relay_1/on` (замените на реальный топик вашего реле).

* Name: `Ventilation Relay Control`

Соедините выходы обоих узлов `change` с входом `mqtt out`.

Шаг 2: Реализация гистерезиса через контекст (более надежный метод)

Метод с двумя порогами в `switch` прост, но не самый надежный. Более правильный подход — использовать конечный автомат (FSM), храня состояние системы в контексте.

Создадим `function` узел вместо `switch`:

// Получаем текущее значение CO2 и преобразуем в число
const co2 = parseInt(msg.payload);

// Пороги для включения и выключения
const THRESHOLD_ON = 900;
const THRESHOLD_OFF = 750;

// Получаем текущее состояние вентиляции из контекста потока.
// Если его нет, считаем, что вентиляция выключена (false).
let isVentilationOn = flow.get('ventilationState') || false;

// Основная логика state-машины
if (!isVentilationOn && co2 > THRESHOLD_ON) {
    // Условие для ВКЛЮЧЕНИЯ: система была выключена И CO2 превысил верхний порог
    msg.payload = 1; // Команда для реле "Включить"
    flow.set('ventilationState', true); // Сохраняем новое состояние
    node.status({ fill: "green", shape: "dot", text: "ON, CO2=" + co2 });
    return msg;

} else if (isVentilationOn && co2 < THRESHOLD_OFF) {
    // Условие для ВЫКЛЮЧЕНИЯ: система была включена И CO2 опустился ниже нижнего порога
    msg.payload = 0; // Команда для реле "Выключить"
    flow.set('ventilationState', false); // Сохраняем новое состояние
    node.status({ fill: "red", shape: "dot", text: "OFF, CO2=" + co2 });
    return msg;
}

// Если ни одно из условий не выполнено, ничего не делаем.
node.status({ fill: "grey", shape: "ring", text: "Standby, CO2=" + co2 });
return null; // Останавливаем поток, чтобы не отправлять лишних команд

Этот код нужно вставить в `function` узел, который ставится после `rbe`. Выход этого узла подключается напрямую к `mqtt out`. Такой подход является каноническим для управления любыми инерционными системами.

---

Продвинутые сценарии: Интеграция с расписанием и присутствием

> 🔗 Связанный материал: Принципы работы с датчиками движения и построения сценариев на основе расписаний подробно рассмотрены в предыдущих уроках этого модуля: `COURSE-01-M05-L05 Управление освещением` и `COURSE-01-M05-L06 Энергосбережение`.

Базовый сценарий управления по CO2 эффективен, но не экономичен. Вентиляция будет работать ночью или в выходные, если в помещении по какой-то причине повысится уровень CO2 (например, из-за неисправности). Объединив данные из разных подсистем, мы можем создать гораздо более интеллектуальный и экономный сценарий.

Энергосбережение: отключение в нерабочее время

Самое простое усложнение — добавить проверку на рабочее время.

Установите в палитру Node-RED узел `node-red-contrib-time-range-switch`.

Поместите его в поток перед логикой проверки CO2.

Настройте его на пропуск сообщений только в рабочее время, например, с 08:00 до 19:00 с понедельника по пятницу.

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

Зональное управление по присутствию

Этот сценарий особенно важен для переговорных комнат.

Задача: Если в переговорной начинается совещание (сработал датчик присутствия mmWave), необходимо не дожидаться роста CO2, а превентивно включить вентиляцию на среднюю скорость. Если же CO2 все равно растет и превышает порог — включить максимальную.
Реализация:

1. Состояние датчика присутствия (есть люди / нет людей) хранится в переменной контекста, например, `flow.get('meetingRoomPresence')`.

2. Логика в `function` узле объединяет несколько условий: ЕСЛИ `presence == true` И `co2 < 800`, то включить скорость 1. ЕСЛИ `co2 > 800`, то включить скорость 2. ЕСЛИ `presence == false`, то выключить вентиляцию.

Комплексная логика «И»

Идеальный сценарий для open-space выглядит так:

Включить вентиляцию только ЕСЛИ (`Уровень CO2 > 900 ppm`) И (`В офисе есть люди`) И (`Сейчас рабочее время`)

В Node-RED это реализуется с помощью `function` узла, который проверяет несколько переменных, хранящихся в контексте:

// Пример логики внутри function узла
const co2 = parseInt(msg.payload);

// Получаем флаги из других потоков (которые устанавливают их в контекст)
const isWorkingHours = flow.get('isWorkingHours') || false;
const isOfficeOccupied = flow.get('isOfficeOccupied') || false;

if (co2 > 900 && isWorkingHours && isOfficeOccupied) {
    // ... логика включения ...
    return msg;
} else {
    // ... логика выключения ...
    return msg;
}

Связь со смежными системами

Продвинутая автоматизация подразумевает взаимодействие систем.

Пример: На летний период в офисе работает центральная система кондиционирования. При ее включении нежелательно, чтобы система вентиляции открывала окна для проветривания, так как это приведет к огромным энергопотерям.
Решение: Контроллер должен знать состояние кондиционера (например, через "сухой контакт" от него или по Modbus). В логике Node-RED добавляется еще одна проверка: `flow.get('isAcActive')`. Если кондиционер работает (`true`), то сценарий проветривания через окна блокируется, и активируется только приточно-вытяжная установка с рекуперацией.

---

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

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

Краткий обзор созданного сценария:

Мы интегрировали промышленный датчик CO2 с интерфейсом Modbus RTU, используя контроллер как шлюз в MQTT.

Создали в Node-RED поток, который получает данные по MQTT и принимает решение об управлении вентиляцией.

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

Рассмотрели способы усложнения сценария для повышения энергоэффективности и комфорта путем интеграции с расписанием, датчиками присутствия и смежными инженерными системами.

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

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

Реализация: На информационной панели (например, созданной в iRidium, как было рассмотрено в курсах по визуализации) разместите кнопку `Вентиляция: Авто / Вкл / Выкл`.
Логика: Когда пользователь выбирает "Вкл" или "Выкл", автоматический сценарий должен быть заблокирован на определенное время (например, на 1 час), после чего система вернется в режим "Авто". Это дает пользователю контроль, но предотвращает ситуацию, когда вентиляцию случайно оставили включенной на все выходные.

Чек-лист для сдачи проекта по автоматизации вентиляции

Перед сдачей системы Заказчику убедитесь, что все пункты выполнены:

[ ] Физический монтаж: Датчики установлены в репрезентативных местах (вдали от окон и вентиляционных решеток, на высоте ~1.5 м). Адреса Modbus-устройств уникальны и задокументированы.

[ ] Получение данных: Данные со всех датчиков стабильно поступают в MQTT. Значения адекватны.

[ ] Работа автоматики: Система корректно включает и выключает вентиляцию при искусственном повышении/понижении CO2 (например, подышав на датчик). Гистерезис работает, "дребезг" отсутствует.

[ ] Интеграция с расписанием: Сценарий корректно отключается в нерабочее время и выходные.

[ ] Ручное управление: Интерфейс ручного управления реализован, работает и имеет приоритет над автоматикой. Система возвращается в авто-режим по таймеру.

[ ] Журналирование: Все события (включение/выключение, смена режимов) и ошибки записываются в системный журнал, как было рассмотрено в уроке `COURSE-01-M02-L04`.

[ ] Инструктаж Заказчика: Проведен инструктаж для ответственного персонала о том, как работает система и как пользоваться ручным управлением.

Что дальше

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