Сценарии для гостиниц: Логика ключ-карты

Введение в автоматизацию гостиниц: логика картоприемника

> ℹ️ Информация: Картоприемник является "точкой входа" для большинства сценариев в номере. От его надежной интеграции зависит работа всей системы автоматизации.

Автоматизация в гостиничном секторе преследует три взаимосвязанные цели: повышение комфорта для гостя, достижение максимального энергосбережения для отеля и оптимизация операционных процессов для персонала. Центральным элементом, запускающим большинство автоматических действий в номере, является картоприемник (Card Holder). Это простое на вид устройство служит главным триггером, который сообщает системе автоматизации о присутствии или отсутствии человека в помещении.

Система оперирует несколькими ключевыми статусами номера, которые определяют ее поведение:

• "Гость в номере" (Occupied): Карта гостя вставлена в картоприемник. Система переходит в активный режим: включается приветственное освещение, климат-контроль устанавливает комфортную температуру, активируются розетки для бытовых приборов.
• "Номер пуст" (Unoccupied / Away): Карта извлечена. Система переходит в режим энергосбережения: все освещение и ненужные потребители отключаются, а климатическая система переводится в экономичный режим с расширенным температурным диапазоном (например, 18-26°C).
• "Уборка" (Service / Housekeeping): Статус активируется, когда в картоприемник вставлена карта персонала. Логика может отличаться: например, принудительное включение всего света на 100% для удобства уборки и блокировка мультимедийных систем.
• "Не беспокоить" (Do Not Disturb - DND): Активируется гостем с помощью отдельной кнопки. Этот статус имеет высший приоритет и может блокировать определенные действия (например, сигнал дверного звонка) и информировать персонал через внешние индикаторы или систему управления отелем.

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

| Компонент | Пример на платформе HI | Роль в системе |

| :--- | :--- | :--- |

| Контроллер | Контроллер HI на базе Linux (Debian) | Центральный мозг системы. Выполняет всю логику в Node-RED. |

| Картоприемник | Modbus-картоприемник (например, от Zennio, VDA, Tense) | Определяет наличие карты и, опционально, ее тип (гость/персонал). |

| Исполнительные устройства | Встроенные реле и внешние модули (Modbus, DALI) | Управляют освещением, розетками, шторами, клапанами на радиаторах. |

| Панель управления | Кнопочные панели с входами "сухой контакт" или по шине KNX/Modbus | Позволяют гостю управлять светом, климатом и активировать режимы DND. |

| Шины данных | RS-485, DALI, CAN | Обеспечивают надежную связь контроллера с периферийными устройствами на объекте. |

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

---

Интеграция Modbus-картоприемника с контроллером

> 💡 Подсказка: Перед монтажом на объекте всегда проверяйте работоспособность картоприемника "на столе" с помощью USB-RS485 адаптера и Modbus-утилиты (например, QModMaster). Это сэкономит часы отладки в полевых условиях.

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

Физическое подключение

Кабель: Используйте экранированную витую пару (например, UTP Cat.5e), чтобы минимизировать влияние электромагнитных помех от силовых линий.

Подключение к контроллеру: Подключите провода к соответствующим клеммам порта RS-485 на контроллере HI. Строго соблюдайте полярность: проводник `A` картоприемника к клемме `A` контроллера, `B` — к `B`. Перепутанная полярность — одна из самых частых причин отказа связи.

Питание: Подайте на картоприемник питание (обычно 12V или 24V DC), соблюдая полярность (+V и GND).

Терминирование: Если картоприемник является последним или единственным устройством на шине RS-485, необходимо активировать на нем или установить внешний согласующий резистор (терминатор) на 120 Ом. Это предотвратит отражение сигнала и обеспечит стабильную связь, как было рассмотрено в уроке по стандартам схем подключения.

Настройка Modbus-сканера в контроллере

На контроллере HI за опрос Modbus-устройств отвечает служба `wb-mqtt-serial`. Ее конфигурация находится в файле `/etc/wb-mqtt-serial.conf`.

Изучите карту регистров: Найдите в документации к вашему картоприемнику его карту регистров Modbus. Вам нужно знать как минимум:

* Slave ID устройства (адрес на шине, например, `15`).

* Параметры порта: скорость (Baud Rate), четность (Parity), стоп-биты. (чаще всего `9600 8N1`).

* Адрес регистра, хранящего статус наличия карты.

* Тип регистра (Holding, Input, Coil, etc.).

Типовая карта регистров может выглядеть так:

| Адрес Регистра | Название | Тип | Описание |

| :--- | :--- | :--- | :--- |

| 100 | Card Present | Holding Register | `1` = Карта вставлена, `0` = Карта извлечена |

| 101 | Card Type | Holding Register | `1` = Гость, `2` = Персонал, `3` = Мастер |

| 102 | DND Status | Coil | `1` = Режим "Не беспокоить" активен |

Отредактируйте конфигурационный файл: Добавьте в `/etc/wb-mqtt-serial.conf` блок, описывающий ваше устройство.

sudo nano /etc/wb-mqtt-serial.conf

Добавьте в конец файла следующий JSON-блок, адаптировав его под ваше устройство.

{
    "path": "/dev/ttyRS485-1",
    "baud_rate": 9600,
    "parity": "N",
    "data_bits": 8,
    "stop_bits": 1,
    "devices": [
        {
            "name": "Room_101_Card_Holder",
            "id": 15,
            "channels": [
                {
                    "name": "Card_Present",
                    "reg_type": "holding",
                    "address": 100,
                    "type": "switch",
                    "readonly": true
                },
                {
                    "name": "Card_Type",
                    "reg_type": "holding",
                    "address": 101,
                    "readonly": true
                }
            ]
        }
    ]
}

Перезапустите службу, чтобы применить изменения:

sudo systemctl restart wb-mqtt-serial

Проверка в MQTT

После перезапуска службы `wb-mqtt-serial` начнет опрашивать картоприемник и публиковать его состояния в MQTT. Вы можете проверить это с помощью утилиты `mqtt-sub`.

mqtt-sub -v -t '/devices/Room_101_Card_Holder/controls/#'

Теперь, когда вы вставляете и вынимаете карту, вы должны видеть в консоли следующие сообщения:

• При вставке карты: `/devices/Room_101_Card_Holder/controls/Card_Present 1`
• При извлечении карты: `/devices/Room_101_Card_Holder/controls/Card_Present 0`

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

---

Логика состояний в Node-RED: сценарии "Добро пожаловать" и "Никого нет"

> ⚠️ Внимание: Всегда используйте задержку (30-60 секунд) перед активацией сценария "Никого нет". Гость может случайно вынуть и снова вставить карту. Мгновенное отключение света и климата вызовет негативный опыт.

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

Создание потока

Входной узел `mqtt in`: Добавьте на холст узел `mqtt in` и настройте его на подписку на топик состояния картоприемника: `/devices/Room_101_Card_Holder/controls/Card_Present`.

Узел `switch` для маршрутизации: Сразу после `mqtt in` разместите узел `switch`. Он будет направлять поток в зависимости от значения `msg.payload`. Настройте его со следующими правилами:

* Правило 1: `msg.payload` == `1` (тип: string) -> выход 1 (Сценарий "Добро пожаловать")

* Правило 2: `msg.payload` == `0` (тип: string) -> выход 2 (Сценарий "Никого нет")

Сценарий "Добро пожаловать" (Карта вставлена)

Эта ветка логики отвечает за создание комфортной атмосферы при входе гостя.

Формирование команд: После выхода 1 узла `switch` добавьте несколько узлов `change` для формирования команд управления. Каждый узел будет создавать сообщение для конкретного исполнительного устройства.

Пример 1: Включение приветственного света (группа на реле)

* Узел `change`: `Set msg.payload` to `1` (string).

* Узел `mqtt out`: `Topic` = `/devices/wb-mr6c_45/controls/K1/on`

Пример 2: Установка комфортной температуры на термостате (Modbus)

* Узел `change`: `Set msg.payload` to `22` (string).

* Узел `mqtt out`: `Topic` = `/devices/room_thermostat_23/controls/Setpoint/on`

Пример 3: Включение группы розеток

* Узел `change`: `Set msg.payload` to `1` (string).

* Узел `mqtt out`: `Topic` = `/devices/wb-mr6c_45/controls/K2/on`

Для удобства эти команды можно объединить, отправив одно сообщение в узел `function`, который сгенерирует и отправит несколько MQTT-сообщений.

Сценарий "Никого нет" (Карта извлечена)

Эта ветка реализует логику энергосбережения после ухода гостя.

Узел `trigger` для задержки: Это ключевой элемент сценария. После выхода 2 узла `switch` добавьте узел `trigger`.

* Send: `nothing`.

* Then wait for: `30 seconds`.

* Then send: `the latest msg`.

*Handling

...** `Extend delay if new message arrives`.

Эта конфигурация означает, что если гость вынул и снова вставил карту в течение 30 секунд, таймер на отключение сбросится, и ничего не произойдет. Если же в течение 30 секунд новых сообщений не было, узел `trigger` пропустит исходное сообщение (`msg.payload` = `0`) дальше по потоку.

Формирование команд на отключение: После узла `trigger` добавьте узлы `change` и `mqtt out` для выключения всех потребителей.

Пример 1: Выключение всего света

* Узел `change`: `Set msg.payload` to `0` (string).

* Узел `mqtt out` 1: `/devices/wb-mr6c_45/controls/K1/on`

* Узел `mqtt out` 2: `/devices/dimmer_12/controls/Brightness/on`

Пример 2: Перевод климата в режим "Эконом"

* Узел `change`: `Set msg.payload` to `18` (string).

* Узел `mqtt out`: `/devices/room_thermostat_23/controls/Setpoint/on`

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

---

Расширенные сценарии: режим "Уборка" и интеграция с PMS

> 🔗 Связанный материал: Принципы построения отказоустойчивой MQTT-архитектуры подробно рассмотрены в модуле по сетевым протоколам: COURSE-01-M02-L04.

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

Идентификация карты персонала и режим "Уборка"

Если ваш картоприемник (как в нашем примере настройки `wb-mqtt-serial.conf`) способен определять тип карты, вы можете создать специальный режим "Уборка".

Расширьте логику в Node-RED: Вместо простого `switch` на `0` и `1` создайте более сложную проверку.

* Подпишитесь на топик типа карты: `mqtt in` на `/devices/Room_101_Card_Holder/controls/Card_Type`.

* Сохраняйте тип карты в переменную контекста (`flow.card_type`).

* Когда приходит сообщение о вставке карты (`Card_Present` = `1`), проверьте значение `flow.card_type`.

Создайте отдельную ветку логики:

* Если `flow.card_type == 2` (персонал), активируйте сценарий "Уборка".

* Действия сценария "Уборка":

* Включить все группы света на 100%.

* Полностью открыть шторы.

* Отключить телевизор и аудиосистему.

* Отправить MQTT-сообщение в систему управления отелем (PMS) о том, что в номере началась уборка.

Интеграция с Property Management System (PMS)

Эффективная гостиница — это единый информационный организм. Локальная автоматизация номера должна "общаться" с верхнеуровневой системой управления отелем. MQTT — идеальный протокол для такой интеграции.

Проектирование MQTT-архитектуры: Создайте четкую и масштабируемую структуру топиков для обмена статусами.

Топик для статуса номера (от контроллера к PMS):

* `Topic`: `/hotel/floor_1/room_101/status`

* `Payload` (JSON):

    {

        "presence": "occupied", 
        "dnd_active": false,
        "service_request": false,
        "window_open": true,
        "timestamp": 1678886400000
    }
    

Возможные значения для `presence`: `occupied` (гость в номере), `away` (номер пуст), `service` (уборка).

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

Обратная связь от PMS (от PMS к контроллеру): Система PMS также может отправлять команды в номер.

Топик для команд управления номером:

* `Topic`: `/hotel/floor_1/room_101/command`

* `Payload` (JSON):

    {

        "command": "check-out",
        "lock_card_holder": true,
        "timestamp": 1678890000000
    }
    

Получив такое сообщение, контроллер в номере 101 может заблокировать работу картоприемника. Даже если гость после выселения попытается вставить свою карту, свет не включится. Это повышает безопасность и предотвращает несанкционированное нахождение в номере. Другие команды могут включать `pre-heat` (предварительный прогрев номера до заезда гостя) или `panic` (активация тревоги).

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

---

Итоги и обзор практического применения

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

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

📋 Ключевые понятия, которые мы освоили:

• Полный цикл реализации логики ключ-карты: от физического подключения Modbus RTU устройства к контроллеру HI до разработки программной логики.
• Набор ключевых узлов Node-RED для решения этой задачи: `mqtt in`, `switch`, `trigger` для надежной задержки, `change` и `mqtt out` для отправки команд.
• Важность правильно спроектированной и документированной структуры MQTT-топиков, которая является фундаментом для масштабируемости системы и ее дальнейшей интеграции с PMS.
• Понимание того, что конечный результат — энергоэффективность для отеля и комфорт для гостя — достигается только за счет слаженной совместной работы аппаратной части (контроллер, реле, датчики) и программной логики, реализованной инженером.

Реализация сценариев "Добро пожаловать", "Никого нет" и "Уборка" является обязательным навыком для любого инженера, работающего с объектами в сфере гостеприимства.

Что дальше

Освоив логику присутствия в номере, мы можем расширить ее применение. В следующем уроке мы рассмотрим, как интегрировать систему контроля доступа (СКУД) для общих зон (фитнес, спа, парковка) и управлять правами доступа для гостевых карт непосредственно из PMS, используя контроллер HI как шлюз между IT-инфраструктурой отеля и оборудованием СКУД.