Интеграция PMS отеля с KNX: автоматизация заезда/выезда через шлюзы Fidelio и Opera
Подключение системы управления отелем к KNX превращает заезд и выезд в автоматические события управления зданием. Когда гость регистрируется на стойке, в его номере за секунды запускается сценарий приветствия, включается комфортный режим HVAC и телевизор — без дополнительных действий персонала. Чтобы правильно построить интеграцию, нужно понимать как модель событий PMS, так и схему групповых адресов KNX.
Обзор систем PMS
Системы управления отелем (PMS) — это операционная основа отеля: они обрабатывают бронирования, заезд/выезд, назначение номеров, выставление счетов, задачи горничных и отчетность. Для интеграции с KNX важна возможность PMS транслировать события изменения состояния номера, на которые может подписаться промежуточное ПО.
| Система PMS | Рыночный сегмент | API интеграции | Варианты KNX шлюзов |
|---|---|---|---|
| Oracle Opera Cloud | 4–5 звезд, сети | Opera REST API v3 + вебхуки | Loytec LIOR-800, собственное Node.js ПО |
| Mews PMS | Облачная, бутик/лайфстайл | Mews Webhooks API (REST) | Home Assistant + интеграция KNX, собственное ПО |
| Apaleo | Европейские бутик-отели, апарт-отели | Apaleo Open API (REST) | Пользовательское промежуточное ПО, мост Zapier + KNX |
| Micros Fidelio (устаревшая) | Широко распространены, городские отели | FIAS (Fidelio Interface API Specification) — TCP-сокет | HMS Anybus, выделенный шлюз FIAS-KNX |
| Protel Air | Независимые европейские отели | Protel Webhooks + REST | Пользовательское промежуточное ПО на Node.js или Python |
FIAS против REST: Старые установки Micros Fidelio используют FIAS — проприетарный протокол TCP-сокетов с текстовым форматом сообщений. Современный Oracle Opera Cloud использует стандартный REST API с JSON-вебхуками. При интеграции с устаревшей установкой Fidelio требуется специальный парсер FIAS в промежуточном слое. Новые установки следует стандартизировать на Oracle Opera Cloud или Mews для более чистого доступа к API.
Методы интеграции PMS с KNX
Для подключения PMS отеля к KNX используются четыре различные архитектуры интеграции. Выбор зависит от типа API PMS, размера отеля, наличия ИТ-инфраструктуры и технических возможностей для постоянного обслуживания.
1. Выделенный шлюз PMS-KNX
Аппаратный шлюз (например, Loytec LIOR-800) со встроенным интерфейсом Opera/Fidelio. Подключается к PMS через FIAS или REST; выдает KNX-телеграммы через KNXnet/IP. Управляется через веб-интерфейс. Лучше всего подходит для отелей 4–5 звезд, требующих поддерживаемого решения от одного поставщика с SLA.
Плюсы: Поддерживается производителем, единая точка конфигурации
Минусы: Более высокая стоимость (€2,000–8,000); проприетарность; ограниченная гибкость
2. Пользовательское промежуточное ПО на Node.js/Python
Самодельный сервер (Linux VM или Raspberry Pi) с middleware, который подписывается на вебхуки PMS, сопоставляет номера комнат с групповыми адресами KNX и отправляет телеграммы KNX через сокет KNXnet/IP (node-red-contrib-knx или библиотека knx на Python). Максимальная гибкость, минимальная стоимость.
Плюсы: Полный контроль; низкая стоимость; поддержка любого PMS API
Минусы: Требует разработки и постоянного обслуживания; без вендорской поддержки
3. Home Assistant + интеграция вебхуков PMS
HA установлен на локальном сервере с настроенной интеграцией KNX. Вебхуки PMS отправляют POST-запросы на URL вебхука HA. Автоматизация HA извлекает room_id, сопоставляет с блоком групповых адресов KNX и запускает сцену KNX. Практично для Mews и Apaleo; требуется публичная HTTPS-точка (Cloudflare Tunnel или выделенный IP).
Плюсы: Без кода; интеграция HA с KNX хорошо поддерживается; настройка через GUI
Минусы: Обновления HA могут сломать автоматизации; не подходит для крупных отелей
4. KNX Virtual / BMS middleware
Платформа системы управления зданием (BMS) (например, Siemens Desigo CC, ABB Ability) с модулем подключения PMS. События PMS поступают в BMS, которая управляет KNX через драйвер KNXnet/IP. Корпоративный уровень; подходит для крупных гостиничных сетей с существующей инфраструктурой BMS.
Плюсы: Корпоративный уровень; полная интеграция BMS; управление энергопотреблением
Минусы: Высокая стоимость; требует экспертизы BMS; избыточно для независимых отелей
Поток события заезда Oracle Opera
Oracle Opera Cloud отправляет вебхук при каждом событии жизненного цикла гостя. Событие заезда содержит номер комнаты, имя гостя, дату прибытия и назначенный тип номера. Middleware получает это событие и преобразует его в телеграммы KNX для назначенной комнаты.
Вебхук заезда Opera → поток KNX
1. Guest checks in at reception → Opera processes check-in
2. Opera fires POST to middleware webhook:
{
"event": "reservation.check_in",
"room_number": "101",
"guest_name": "Schmidt, Klaus",
"arrival": "2026-06-05T14:00:00Z"
}
3. Middleware receives event:
a. Parse room_number → "101"
b. Map to KNX GA block: main=10, sub=101
c. Build KNX telegram sequence:
→ GA 10/101/5 DPT 18.001 = 0x01 (scene 1: Welcome)
— Lights 70%, blinds 50%, HVAC comfort
→ GA 10/101/4 DPT 9.001 = 21.0 (comfort setpoint)
→ GA 10/101/0 DPT 1.002 = 1 (presence flag: room assigned)
4. KNX IP gateway (KNXnet/IP):
Receives tunnelling request from middleware
Forwards telegram onto KNX TP bus → room 101
5. MDT SCN-RT55 in room 101:
Receives scene 1 telegram → executes welcome scene
Receives setpoint telegram → switches HVAC to comfortАвтоматизация последовательности выезда
Событие выезда запускает полную последовательность отключения номера. Все настройки гостя сбрасываются, энергопотребление минимизируется, а система горничной получает уведомление, что номер готов к уборке.
Последовательность телеграмм KNX при выезде
Opera check-out event → middleware → KNX: GA 10/101/5 DPT 18.001 = 0x02 (scene 2: Eco — lights off) GA 10/101/4 DPT 9.001 = 18.0 (economy setpoint — winter) GA 10/101/1 DPT 1.001 = 0 (DND cleared) GA 10/101/2 DPT 1.001 = 0 (MUR cleared) GA 10/101/0 DPT 1.002 = 0 (presence flag: room vacant) Blind control: Blind GA send position 50% (UV protection, neutral) TV: KNX switch actuator GA → TV standby OFF telegram Housekeeping notification: Middleware → housekeeping system API: room 101 vacated Housekeeping app shows room 101 as "Ready for cleaning" (alternatively: KNX GA to housekeeping BMS panel)
Обработка раннего выезда: если гость выезжает раньше запланированного времени, Opera немедленно отправляет событие выезда. Middleware должна обрабатывать одновременные состояния комнаты — если карта всё ещё вставлена, когда приходит событие выезда, контроллер комнаты покажет присутствие = 1 от карточного выключателя, но PMS говорит, что комната свободна. Событие выезда из PMS должно иметь приоритет: middleware отправляет экономичный уставку независимо от состояния карточного выключателя, а стойка регистрации просит гостя оставить карту на ресепшене.
Интеграция звонков-будильников
Звонки-будильники, запланированные в PMS, могут запускать управляемую KNX сцену постепенного освещения в номере. Это более удобно для гостя, чем будильник по телефону, и позволяет гостю установить время пробуждения прямо в портале Opera или на стойке регистрации.
Последовательность KNX для звонка-будильника
Guest requests 07:30 wake-up via Opera guest portal
Opera scheduled task: 07:30:00 → wake-up event for room 101
Middleware receives event at 07:29:50 (10s pre-run buffer):
t+0:00 → GA 10/101/6 DPT 1.001 = 1 (wake-up trigger)
Room display shows: "Good morning — 07:30"
HVAC switches to comfort setpoint (21°C)
t+0:30 → Lighting scene: 10% warm white (gentle start)
t+1:30 → Lighting scene: 30% warm white
t+3:00 → Lighting scene: 60% cool white (fully awake)
t+5:00 → Blind position: 30% (gentle morning light)
Phone call (optional):
Parallel to KNX: middleware triggers PBX phone call to room
(Opera can do this natively — keep as backup)
Wake-up confirmation to PMS:
GA 10/101/6 DPT 1.001 = 0 after 10 minutes
(or: guest acknowledges on room display → GA → middleware → Opera)Интеграция вебхуков Mews PMS с Home Assistant
Mews — это облачная PMS с хорошо документированным REST API и системой вебхуков. Она предпочтительна для бутик-отелей и отелей в стиле лайфстайл. Интеграция с Home Assistant позволяет автоматизировать номера через KNX без программирования для небольших объектов, где нет выделенного сервера middleware.
Вебхук Mews → Home Assistant → KNX
1. Mews Operations → Settings → Webhooks
→ Add webhook: https://your-ha-instance.domain.com/api/webhook/mews_checkin
→ Events: reservation.check_in, reservation.check_out
2. Home Assistant configuration.yaml:
homeassistant:
packages: !include_dir_named packages/
3. packages/hotel_automation.yaml:
automation:
- alias: "Mews Check-In to KNX"
trigger:
platform: webhook
webhook_id: mews_checkin
action:
- variables:
room: "{{ trigger.json.space_id | default('') }}"
- service: knx.send
data:
address: "10/{{ room }}/5"
payload: 1 # Welcome scene
type: "scene"
- service: knx.send
data:
address: "10/{{ room }}/4"
payload: 21.0
type: "temperature"
4. Public HTTPS endpoint:
Cloudflare Tunnel → HA instance (no port forwarding)
OR: Dedicated public IP with Let's Encrypt SSLСопоставление ID помещений: Mews использует UUID-based space_id для номеров, а не читаемый номер комнаты. Создайте вспомогательный элемент HA (input_select или template sensor), который сопоставляет UUID номеров Mews с номерами комнат. Для 50 номеров это разовая настройка; обновите сопоставление при перенумерации или реструктуризации помещений в Mews.
Обратная связь состояния номера в PMS
Интеграция не односторонняя: изменения состояния номера через KNX должны обновлять PMS, чтобы предоставить горничным и стойке регистрации актуальную информацию. Это замыкает цикл между физическим номером и операционной системой.
| Событие KNX | Групповой адрес | Действие в PMS |
|---|---|---|
| DND активирован | GA 10/room/1 = 1 | Opera room status → 'Do Not Disturb'; housekeeping task blocked |
| DND снят | GA 10/room/1 = 0 | Opera room status → 'Available for housekeeping' |
| MUR активирован | GA 10/room/2 = 1 | Opera housekeeping task created: 'Make Up Room — room XXX' |
| Карта извлечена | GA 10/room/2 = 0 | Задача housekeeping удалена или отмечена выполненной |
| Номер свободен (карта извлечена) | GA 10/room/0 = 0 | Optional: PMS note 'Guest left room' (not formal check-out) |
| Энергопотребление выше порога | Суточное энергопотребление GA, кВт·ч | Гостевой счёт Opera: запись о надбавке за энергию (если применяется) |
Прослушиватель KNX middleware — монитор групп
Middleware subscribes to all GA 10/*/1 (DND status GAs)
using KNXnet/IP group monitor (knx library group_listen):
knx.Group.listen('10/*/1', (msg) => {
const room = extractRoom(msg.destination); // e.g., "101"
if (msg.value === 1) {
operaApi.updateRoomStatus(room, 'DND');
} else {
operaApi.updateRoomStatus(room, 'CLEAN');
}
});
Similarly for GA 10/*/2 (MUR) and GA 10/*/0 (presence).
Run middleware as a systemd service for automatic restart.Покомнатный учёт энергии для выставления счетов гостям
Некоторые отели взимают с гостей плату за электроэнергию сверх нормы, особенно для длительного проживания или апартаментов. Счётчики энергии с KNX на уровне номера делают это возможным без отдельной инфраструктуры субучёта.
Настройка покомнатного учёта энергии
Hardware: Carlo Gavazzi EM110 single-phase MID meter
— DIN rail, Modbus RTU RS485 output
— Accuracy class 1 (MID approved for billing)
— One meter per room at floor distribution board
Interface: Modbus/KNX gateway (e.g., Zennio KLIC-DD or
ABB M2M-WEB-HQ Modbus gateway)
— Poll EM110 register 40097 (kWh active energy) every 15 min
— Write to KNX GA 10/room/10 DPT 14.058 (energy, kWh)
Middleware energy billing logic:
— Read GA 10/room/10 daily at 00:00 (snapshot)
— Calculate daily consumption: today − yesterday
— If daily kWh > 5 kWh threshold:
→ Opera folio entry: "Energy supplement: X kWh × €0.30"
— Monthly report: sum per room per stay
Note: EN 62056 DLMS/COSEM metering is NOT required at
room level — Modbus MID meter is sufficient for hotel
energy billing at the sub-metering level. DLMS/COSEM
is required for utility grid metering only.Отказоустойчивость и безопасность middleware
Middleware PMS-KNX должна быть устойчива к сбоям сети, простою PMS и перезагрузкам серверов. Номер, застрявший в экономичном режиме при сбое сети, пока гость находится внутри, — серьёзная эксплуатационная проблема.
Требования к отказоустойчивости
- Middleware работает как systemd-сервис — автостарт при сбое
- Повтор webhook PMS: если middleware недоступен, Opera ставит в очередь и повторяет
- Локальный KNX-выключатель по карте имеет приоритет над PMS (карта вставлена = всегда комфорт)
- Watchdog: если нет heartbeat от PMS в течение 60 мин, отправить комфорт во все занятые номера
- Сохранение состояний: промежуточное ПО записывает состояния номеров в SQLite при каждом изменении
- При перезапуске: восстановление последнего известного состояния и повторная отправка в KNX
Правило отказоустойчивости — приоритет карточного выключателя
Вход карточного выключателя на SCN-RT55P — это локальный аппаратный вход, не зависящий от промежуточного ПО или сети. Если промежуточное ПО выходит из строя, карточный выключатель по-прежнему управляет присутствием и экономичным режимом HVAC локально в ETS6. Это гарантирует, что гость никогда не останется в холодном номере из-за сбоя программного обеспечения. Команды PMS накладываются поверх локальной логики карточного выключателя, а не заменяют её.
Нужна разработка и настройка интеграции PMS-KNX для вашего отеля?
Мы проектируем гостиничные KNX-щиты с промежуточным ПО для интеграции PMS, настройкой вебхуков Opera и Mews, пономерным учётом энергии и полной документацией — готовые к передаче вашей IT-команде.
Запросить расчёт →