Автоматизация отеля · Oracle Opera · Mews PMS · KNX шлюз · Интеграция PMS · 10 мин чтения

Интеграция PMS отеля с KNX: автоматизация заезда/выезда через шлюзы Fidelio и Opera

Подключение системы управления отелем к KNX превращает заезд и выезд в автоматические события управления зданием. Когда гость регистрируется на стойке, в его номере за секунды запускается сценарий приветствия, включается комфортный режим HVAC и телевизор — без дополнительных действий персонала. Чтобы правильно построить интеграцию, нужно понимать как модель событий PMS, так и схему групповых адресов KNX.

Обзор систем PMS

Системы управления отелем (PMS) — это операционная основа отеля: они обрабатывают бронирования, заезд/выезд, назначение номеров, выставление счетов, задачи горничных и отчетность. Для интеграции с KNX важна возможность PMS транслировать события изменения состояния номера, на которые может подписаться промежуточное ПО.

Система PMSРыночный сегментAPI интеграцииВарианты KNX шлюзов
Oracle Opera Cloud4–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 = 1Opera room status → 'Do Not Disturb'; housekeeping task blocked
DND снятGA 10/room/1 = 0Opera room status → 'Available for housekeeping'
MUR активированGA 10/room/2 = 1Opera housekeeping task created: 'Make Up Room — room XXX'
Карта извлеченаGA 10/room/2 = 0Задача housekeeping удалена или отмечена выполненной
Номер свободен (карта извлечена)GA 10/room/0 = 0Optional: 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-команде.

Запросить расчёт →
Загрузка ...
Наверх