Automatización hotelera · Oracle Opera · Mews PMS · Pasarela KNX · Integración PMS · 10 min de lectura

PMS hotelero a KNX: Automatización de check-in/out mediante pasarelas Fidelio y Opera

Conectar un sistema de gestión de propiedades hoteleras a KNX convierte el check-in y el check-out en eventos automatizados de gestión del edificio. Un huésped que se registra en la recepción puede activar una escena de bienvenida, el modo confort HVAC y el modo de espera del televisor en su habitación en cuestión de segundos – sin ninguna acción adicional del personal. Para lograr una arquitectura de integración correcta, es necesario comprender tanto el modelo de eventos del PMS como el esquema de direcciones de grupo KNX.

Resumen de sistemas PMS

Los sistemas de gestión de propiedades (PMS) son la columna vertebral operativa de un hotel: manejan reservas, check-in/out, asignación de habitaciones, facturación, tareas de limpieza e informes. Para la integración KNX, la capacidad relevante es la API de eventos PMS: un mecanismo mediante el cual el PMS transmite eventos de cambio de estado de la habitación a los que el middleware puede suscribirse.

Sistema PMS	Segmento de mercado	API de integración	Opciones de gateway KNX
Oracle Opera Cloud	4–5 estrellas, cadenas	Opera REST API v3 + webhooks	Loytec LIOR-800, middleware Node.js personalizado
Mews PMS	Nativo en la nube, boutique/lifestyle	API de Webhooks de Mews (REST)	Home Assistant + integración KNX, middleware personalizado
Apaleo	Boutique europeo, aparthoteles	Apaleo Open API (REST)	Middleware personalizado, puente Zapier + KNX
Micros Fidelio (heredado)	Ampliamente instalado, hoteles urbanos	FIAS (Fidelio Interface API Specification) — socket TCP	HMS Anybus, gateway FIAS-KNX dedicado
Protel Air	Hoteles independientes europeos	Protel Webhooks + REST	Middleware personalizado Node.js o Python

FIAS vs REST: Las instalaciones más antiguas de Micros Fidelio utilizan FIAS — un protocolo de socket TCP propietario con un formato de mensaje basado en texto. El moderno Oracle Opera Cloud utiliza una API REST estándar con webhooks JSON. Al integrarse con una instalación Fidelio heredada, se necesita un analizador FIAS dedicado en la capa de middleware. Las nuevas instalaciones deberían estandarizarse en Oracle Opera Cloud o Mews para un acceso a API más limpio.

Métodos de integración PMS a KNX

Se utilizan cuatro arquitecturas de integración distintas para la conectividad PMS-KNX hotelera. La elección depende del tipo de API del PMS, el tamaño del hotel, la disponibilidad de infraestructura de TI y la capacidad técnica interna para el mantenimiento continuo.

1. Gateway PMS-KNX dedicado

Dispositivo gateway de hardware (p. ej., Loytec LIOR-800) con interfaz Opera/Fidelio integrada. Se conecta al PMS mediante FIAS o REST; emite telegramas KNX a través de KNXnet/IP. Gestionado mediante interfaz web. Mejor para propiedades de 4–5 estrellas que requieren una solución compatible de un solo proveedor con SLA.

Ventajas: Compatible con el proveedor, punto único de configuración

Desventaja: Costo más alto (€2.000–8.000); propietario; flexibilidad limitada

2. Middleware personalizado Node.js/Python

Servidor autoalojado (VM Linux o Raspberry Pi) que ejecuta middleware que se suscribe a los webhooks del PMS, asigna números de habitación a direcciones de grupo KNX y envía telegramas KNX a través del socket KNXnet/IP (node-red-contrib-knx o biblioteca knx Python). El más flexible; costo más bajo.

Ventajas: Control total; bajo costo; cualquier API PMS compatible

Desventaja: Requiere desarrollo y mantenimiento continuo; sin soporte del proveedor

3. Home Assistant + integración de webhook PMS

HA instalado en servidor local con la integración KNX configurada. Webhooks PMS POST a la URL del webhook de HA. La automatización de HA extrae room_id, mapea al bloque GA KNX, dispara la escena KNX. Práctico para Mews y Apaleo; requiere endpoint HTTPS público (Cloudflare Tunnel o IP dedicada).

Ventajas: Sin código personalizado; integración HA KNX bien mantenida; configuración GUI

Desventaja: Las actualizaciones de HA pueden romper automatizaciones; no apto para hoteles grandes

4. KNX Virtual / middleware BMS

Plataforma de sistema de gestión de edificios (BMS) (p. ej., Siemens Desigo CC, ABB Ability) con módulo conector PMS. Los eventos PMS ingresan al BMS; el BMS gestiona KNX mediante el controlador KNXnet/IP. De nivel empresarial; adecuado para grandes cadenas hoteleras con infraestructura BMS existente.

Ventajas: De nivel empresarial; integración BMS completa; gestión energética

Desventaja: Alto costo; requiere experiencia en BMS; excesivo para hoteles independientes

Flujo de eventos de check-in de Oracle Opera

Oracle Opera Cloud dispara un webhook en cada evento del ciclo de vida del huésped. El evento de check-in contiene el número de habitación, el nombre del huésped, la fecha de llegada y el tipo de habitación asignado. El middleware recibe este evento y lo traduce en telegramas KNX para la habitación asignada.

Webhook de check-in de Opera → flujo 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

Automatización de la secuencia de check-out

El evento de check-out desencadena una secuencia completa de apagado de la habitación. Se borran todos los ajustes específicos del huésped, se minimizan las cargas energéticas y el sistema de limpieza recibe una notificación de que la habitación está disponible para la limpieza.

Secuencia de telegramas KNX de check-out

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)

Manejo de check-out anticipado: Si un huésped realiza el check-out antes de la hora prevista, Opera dispara el evento de check-out inmediatamente. El middleware debe manejar estados simultáneos de la habitación — si la tarjeta aún está insertada cuando llega el evento de check-out, el controlador de la habitación mostrará presencia = 1 desde el interruptor de tarjeta, pero el PMS dice que la habitación está vacante. El evento de check-out del PMS debe tener prioridad: el middleware envía el punto de consigna económico independientemente del estado del interruptor de tarjeta, y la recepción indica al huésped que deje la tarjeta en recepción.

Integración de llamada de despertador

Las llamadas de despertador programadas en el PMS pueden activar una escena de iluminación gradual controlada por KNX en la habitación. Esto es más amigable para el huésped que una alarma telefónica y permite al huésped configurar la hora de despertar directamente en el portal de huéspedes Opera o en recepción.

Secuencia KNX de llamada de despertador

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)

Integración del webhook PMS Mews con Home Assistant

Mews es un PMS nativo de la nube con una API REST y un sistema de webhooks bien documentados. Es el PMS preferido para hoteles boutique y de estilo de vida. La integración con Home Assistant proporciona una ruta sin código para la automatización de habitaciones KNX para propiedades más pequeñas sin un servidor middleware dedicado.

Webhook 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&apos;s Encrypt SSL

Mapeo de Space ID: Mews utiliza un space_id basado en UUID para las habitaciones, no un número de habitación legible. Cree un helper de HA (input_select o template sensor) que asigne los UUID de espacios de Mews a números de habitación. Para 50 habitaciones, es una configuración única; actualice el mapeo si las habitaciones se renumeran o los espacios se reestructuran en Mews.

Retroalimentación del estado de la habitación al PMS

La integración no es unidireccional: los cambios de estado de la habitación KNX deben actualizar el PMS para proporcionar al personal de limpieza y a la recepción el estado de la habitación en tiempo real. Esto cierra el ciclo entre la habitación física y el sistema operativo.

Evento KNX	Dirección de grupo	Acción PMS
DND activado	GA 10/habitación/1 = 1	Opera room status → 'Do Not Disturb'; housekeeping task blocked
DND cancelado	GA 10/room/1 = 0	Opera room status → 'Available for housekeeping'
MUR activado	GA 10/room/2 = 1	Opera housekeeping task created: 'Make Up Room — room XXX'
MUR borrado	GA 10/room/2 = 0	Tarea de housekeeping de Opera eliminada o marcada como completada
Habitación libre (tarjeta retirada)	GA 10/room/0 = 0	Optional: PMS note 'Guest left room' (not formal check-out)
Energía por encima del umbral	Energía GA diaria kWh	Cuenta de huésped Opera: entrada de recargo energético (si aplica la política)

Middleware KNX listener — monitor de grupos

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.

Medición de energía por habitación para facturación de huéspedes

Algunos operadores hoteleros cobran a los huéspedes por el consumo de electricidad por encima de una asignación estándar, particularmente para huéspedes de larga estancia o apartamentos con servicios. Los medidores de energía conectados por KNX a nivel de habitación hacen esto práctico sin infraestructura de submedición separada.

Configuración de medición de energía por habitación

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.

Resiliencia del middleware y diseño a prueba de fallos

El middleware PMS-KNX debe ser resistente a interrupciones de red, caídas del PMS y reinicios del servidor. Una habitación que se queda en modo económico durante un corte de red mientras hay un huésped presente es un problema operativo significativo.

Requisitos de resiliencia

El middleware se ejecuta como servicio systemd — reinicio automático en caso de fallo
Reintento de webhook PMS: si el middleware está caído, Opera pone en cola y reintenta
Interruptor local de tarjeta KNX anula el estado PMS (tarjeta insertada = siempre confort)
Watchdog: si no hay heartbeat del PMS durante 60 min, enviar confort a todas las habitaciones ocupadas
Persistencia de estado: el middleware guarda los estados de las habitaciones en SQLite en cada cambio
Al reiniciar: restaurar el último estado conocido y reenviar a KNX

Regla a prueba de fallos – prioridad del interruptor de tarjeta

La entrada del interruptor de tarjeta en el SCN-RT55P es una entrada de hardware local – no depende del middleware ni de la conectividad de red. Si el middleware falla, el interruptor de tarjeta sigue controlando la presencia y la conmutación económica HVAC localmente en ETS6. Esto significa que un huésped nunca queda en una habitación fría debido a una falla de software. Los comandos PMS se superponen a la lógica local del interruptor de tarjeta, no en lugar de ella.

Guías relacionadas

Automatización hotelera

Controlador de habitación de hotel KNX: programación MDT SCN-RT55 e integración PMS

Automatización hotelera

Cableado del lector de tarjetas de hotel: detección de presencia RFID y lógica de puerta KNX

Solutions

Technologies

Knowledge

Company