Hotel PMS to KNX: Check-In/Out Automation via Fidelio and Opera Gateways
Connecting a hotel property management system to KNX turns check-in and check-out into automated building management events. A guest checking in at the front desk can trigger a welcome scene, HVAC comfort mode and TV standby in their room within seconds — without any additional staff action. Getting the integration architecture right requires understanding both the PMS event model and the KNX group address scheme.
PMS systems overview
Property management systems (PMS) are the operational backbone of a hotel — they handle reservations, check-in/out, room assignment, billing, housekeeping tasks and reporting. For KNX integration the relevant capability is the PMS event API: a mechanism by which the PMS broadcasts room state change events that middleware can subscribe to.
| PMS system | Market segment | Integration API | KNX gateway options |
|---|---|---|---|
| Oracle Opera Cloud | 4–5 star, chains | Opera REST API v3 + webhooks | Loytec LIOR-800, custom Node.js middleware |
| Mews PMS | Cloud-native, boutique/lifestyle | Mews Webhooks API (REST) | Home Assistant + KNX integration, custom middleware |
| Apaleo | European boutique, aparthotels | Apaleo Open API (REST) | Custom middleware, Zapier + KNX bridge |
| Micros Fidelio (legacy) | Widely installed, city hotels | FIAS (Fidelio Interface API Specification) — TCP socket | HMS Anybus, dedicated FIAS-KNX gateway |
| Protel Air | European independent hotels | Protel Webhooks + REST | Custom Node.js or Python middleware |
FIAS vs REST: older Micros Fidelio installations use FIAS — a proprietary TCP socket protocol with a text-based message format. Modern Oracle Opera Cloud uses a standard REST API with JSON webhooks. When integrating with a legacy Fidelio installation, a dedicated FIAS parser is needed in the middleware layer. New installations should standardise on Oracle Opera Cloud or Mews for cleaner API access.
PMS to KNX integration methods
Four distinct integration architectures are in use for hotel PMS-to-KNX connectivity. The choice depends on the PMS API type, the size of the hotel, IT infrastructure availability and in-house technical capability for ongoing maintenance.
1. Dedicated PMS-KNX gateway
Hardware gateway appliance (e.g., Loytec LIOR-800) with built-in Opera/Fidelio interface. Connects to PMS via FIAS or REST; outputs KNX telegrams via KNXnet/IP. Managed via web UI. Best for 4–5 star properties requiring a supported, single-vendor solution with SLA.
Pro: Vendor-supported, single point of configuration
Con: Higher cost (€2,000–8,000); proprietary; limited flexibility
2. Custom Node.js/Python middleware
Self-hosted server (Linux VM or Raspberry Pi) running middleware that subscribes to PMS webhooks, maps room numbers to KNX group addresses, and sends KNX telegrams via KNXnet/IP socket (node-red-contrib-knx or knx Python library). Most flexible; lowest cost.
Pro: Full control; low cost; any PMS API supported
Con: Requires development and ongoing maintenance; no vendor support
3. Home Assistant + PMS webhook integration
HA installed on local server with the KNX integration configured. PMS webhooks POST to HA webhook URL. HA automation extracts room_id, maps to KNX GA block, fires KNX scene. Practical for Mews and Apaleo; requires public HTTPS endpoint (Cloudflare Tunnel or dedicated IP).
Pro: No custom code; HA KNX integration well-maintained; GUI configuration
Con: HA updates can break automations; not suitable for large hotels
4. KNX Virtual / BMS middleware
Building management system (BMS) platform (e.g., Siemens Desigo CC, ABB Ability) with PMS connector module. PMS events enter the BMS; BMS manages KNX via KNXnet/IP driver. Enterprise-grade; suited for large hotel chains with existing BMS infrastructure.
Pro: Enterprise-grade; full BMS integration; energy management
Con: High cost; requires BMS expertise; overkill for independent hotels
Oracle Opera check-in event flow
Oracle Opera Cloud fires a webhook on each guest lifecycle event. The check-in event contains the room number, guest name, arrival date and assigned room type. Middleware receives this event and translates it into KNX telegrams for the assigned room.
Opera check-in webhook → KNX flow
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 comfortCheck-out sequence automation
The check-out event triggers a complete room shutdown sequence. All guest-specific settings are cleared, energy loads are minimised, and the housekeeping system receives notification that the room is available for cleaning.
Check-out KNX telegram sequence
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)
Early check-out handling: if a guest checks out before the scheduled time, Opera fires the check-out event immediately. The middleware must handle concurrent room states — if the card is still inserted when the check-out event arrives, the room controller will show presence = 1 from the card switch but the PMS says the room is vacant. The PMS check-out event should take priority: the middleware sends the economy setpoint regardless of card switch state, and the front desk instructs the guest to leave the card at reception.
Wake-up call integration
Wake-up calls scheduled in the PMS can trigger a KNX-controlled gradual lighting scene in the room. This is more guest-friendly than a phone call alarm and allows the guest to set a wake-up time directly in the Opera guest portal or at reception.
Wake-up call KNX sequence
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 webhook integration with Home Assistant
Mews is a cloud-native PMS with a well-documented REST API and webhook system. It is the preferred PMS for boutique and lifestyle hotels. Integration with Home Assistant provides a no-code path to KNX room automation for smaller properties without a dedicated middleware server.
Mews webhook → 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 SSLSpace ID mapping: Mews uses a UUID-based space_id for rooms, not a human-readable room number. Create a HA helper (input_select or template sensor) that maps Mews space UUIDs to room numbers. For 50 rooms this is a one-time configuration; update the mapping if rooms are renumbered or spaces are restructured in Mews.
Room state feedback to PMS
The integration is not one-way: KNX room state changes should update the PMS to provide housekeeping staff and front desk with real-time room status. This closes the loop between the physical room and the operational system.
| KNX event | Group address | PMS action |
|---|---|---|
| DND activated | GA 10/room/1 = 1 | Opera room status → 'Do Not Disturb'; housekeeping task blocked |
| DND cleared | GA 10/room/1 = 0 | Opera room status → 'Available for housekeeping' |
| MUR activated | GA 10/room/2 = 1 | Opera housekeeping task created: 'Make Up Room — room XXX' |
| MUR cleared | GA 10/room/2 = 0 | Opera housekeeping task removed or marked complete |
| Room vacant (card removed) | GA 10/room/0 = 0 | Optional: PMS note 'Guest left room' (not formal check-out) |
| Energy above threshold | Energy GA daily kWh | Opera guest folio: energy surcharge entry (if policy applies) |
Middleware KNX listener — group monitor
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.Per-room energy metering for guest billing
Some hotel operators charge guests for electricity consumption above a standard allowance, particularly for long-stay or serviced apartment guests. KNX-connected energy meters at room level make this practical without separate sub-metering infrastructure.
Per-room energy metering setup
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 resilience and failsafe design
PMS-to-KNX middleware must be resilient to network interruptions, PMS downtime and server restarts. A room that gets stuck in economy mode during a network outage while a guest is present is a significant operational problem.
Resilience requirements
- Middleware runs as systemd service — auto-restart on crash
- PMS webhook retry: if middleware down, Opera queues and retries
- Local KNX card switch overrides PMS state (card in = comfort always)
- Watchdog: if no PMS heartbeat for 60 min, send comfort to all occupied rooms
- State persistence: middleware saves room states to SQLite on every change
- On restart: restore last known state and re-send to KNX
Failsafe rule — card switch priority
The card switch input on the SCN-RT55P is a local hardware input — it does not depend on middleware or network connectivity. If the middleware fails, the card switch still controls presence and HVAC economy switching locally in ETS6. This means a guest is never left in a cold room due to a software failure. PMS commands are overlaid on top of the local card switch logic, not instead of it.
Need PMS-KNX integration designed and commissioned for your hotel?
We design hotel KNX panels with PMS integration middleware, Opera and Mews webhook configuration, per-room energy metering and full commissioning documentation — ready for handover to your IT team.
Request a quote →