Hotelautomation · Oracle Opera · Mews PMS · KNX-Gateway · PMS-Integration · 10 Min. Lesezeit

Hotel PMS zu KNX: Check-In/Out-Automatisierung über Fidelio und Opera Gateways

Die Verbindung eines Hotel-Property-Management-Systems mit KNX verwandelt Check-in und Check-out in automatisierte Gebäudemanagement-Ereignisse. Ein Gast, der an der Rezeption eincheckt, kann innerhalb von Sekunden ein Begrüßungsszenario, HLK-Komfortmodus und TV-Standby in seinem Zimmer auslösen – ohne zusätzliches Personal. Die richtige Integrationsarchitektur erfordert ein Verständnis sowohl des PMS-Ereignismodells als auch des KNX-Gruppenadressschemas.

Übersicht über PMS-Systeme

Property-Management-Systeme (PMS) sind das betriebliche Rückgrat eines Hotels – sie verwalten Reservierungen, Check-in/Check-out, Zimmerzuweisung, Abrechnung, Haushaltsaufgaben und Berichte. Für die KNX-Integration ist die relevante Fähigkeit die PMS-Event-API: ein Mechanismus, über den das PMS Raumzustandsänderungsereignisse sendet, die Middleware abonnieren kann.

PMS-System	Marktsegment	Integrations-API	KNX-Gateway-Optionen
Oracle Opera Cloud	4–5 Sterne, Ketten	Opera REST API v3 + Webhooks	Loytec LIOR-800, benutzerdefinierte Node.js-Middleware
Mews PMS	Cloud-nativ, Boutique/Lifestyle	Mews Webhooks API (REST)	Home Assistant + KNX-Integration, benutzerdefinierte Middleware
Apaleo	Europäische Boutique, Aparthotels	Apaleo Open API (REST)	Benutzerdefinierte Middleware, Zapier + KNX-Bridge
Micros Fidelio (Legacy)	Weit verbreitet, Stadthotels	FIAS (Fidelio Interface API Specification) — TCP-Socket	HMS Anybus, dediziertes FIAS-KNX-Gateway
Protel Air	Europäische unabhängige Hotels	Protel Webhooks + REST	Benutzerdefinierte Node.js- oder Python-Middleware

FIAS vs. REST: Ältere Micros Fidelio-Installationen verwenden FIAS – ein proprietäres TCP-Socket-Protokoll mit einem textbasierten Nachrichtenformat. Moderne Oracle Opera Cloud verwendet eine standardmäßige REST-API mit JSON-Webhooks. Bei der Integration mit einer älteren Fidelio-Installation wird ein dedizierter FIAS-Parser in der Middleware-Schicht benötigt. Neuinstallationen sollten für einen saubereren API-Zugriff auf Oracle Opera Cloud oder Mews standardisieren.

PMS-zu-KNX-Integrationsmethoden

Für die Hotel-PMS-zu-KNX-Konnektivität werden vier verschiedene Integrationsarchitekturen verwendet. Die Wahl hängt vom PMS-API-Typ, der Hotelgröße, der Verfügbarkeit der IT-Infrastruktur und den internen technischen Fähigkeiten für die laufende Wartung ab.

1. Dediziertes PMS-KNX-Gateway

Hardware-Gateway-Gerät (z. B. Loytec LIOR-800) mit integrierter Opera/Fidelio-Schnittstelle. Verbindung zum PMS über FIAS oder REST; Ausgabe von KNX-Telegrammen über KNXnet/IP. Verwaltung über Web-UI. Am besten geeignet für 4–5-Sterne-Hotels, die eine unterstützte Einzelanbieterlösung mit SLA benötigen.

Vorteile: Vom Anbieter unterstützt, zentraler Konfigurationspunkt

Nachteil: Höhere Kosten (2.000–8.000 €); proprietär; eingeschränkte Flexibilität

2. Benutzerdefinierte Node.js/Python-Middleware

Selbst gehosteter Server (Linux-VM oder Raspberry Pi) mit Middleware, die PMS-Webhooks abonniert, Raumnummern auf KNX-Gruppenadressen abbildet und KNX-Telegramme über KNXnet/IP-Socket sendet (node-red-contrib-knx oder knx-Python-Bibliothek). Am flexibelsten; geringste Kosten.

Vorteile: Volle Kontrolle; niedrige Kosten; jede PMS-API unterstützt

Nachteil: Erfordert Entwicklung und laufende Wartung; kein Anbietersupport

3. Home Assistant + PMS-Webhook-Integration

HA auf lokalem Server installiert mit konfigurierter KNX-Integration. PMS-Webhooks POST an HA-Webhook-URL. HA-Automatisierung extrahiert room_id, ordnet KNX-GA-Block zu, löst KNX-Szene aus. Praktisch für Mews und Apaleo; erfordert öffentlichen HTTPS-Endpunkt (Cloudflare Tunnel oder dedizierte IP).

Vorteile: Kein benutzerdefinierter Code; HA KNX-Integration gut gewartet; GUI-Konfiguration

Nachteil: HA-Updates können Automatisierungen unterbrechen; nicht für große Hotels geeignet

4. KNX Virtual / BMS-Middleware

Gebäudemanagementsystem (BMS)-Plattform (z. B. Siemens Desigo CC, ABB Ability) mit PMS-Connector-Modul. PMS-Ereignisse gelangen in das BMS; BMS verwaltet KNX über KNXnet/IP-Treiber. Unternehmensgerecht; geeignet für große Hotelketten mit vorhandener BMS-Infrastruktur.

Vorteile: Unternehmensgerecht; vollständige BMS-Integration; Energiemanagement

Nachteil: Hohe Kosten; erfordert BMS-Expertise; für unabhängige Hotels überdimensioniert

Oracle Opera Check-in Ereignisablauf

Oracle Opera Cloud löst bei jedem Gastlebenszyklus-Ereignis einen Webhook aus. Das Check-in-Ereignis enthält die Zimmernummer, den Gastnamen, das Anreisedatum und den zugewiesenen Zimmertyp. Die Middleware empfängt dieses Ereignis und übersetzt es in KNX-Telegramme für das zugewiesene Zimmer.

Opera Check-in Webhook → KNX-Fluss

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

Check-out-Sequenzautomatisierung

Das Check-out-Ereignis löst eine vollständige Zimmerabschaltsequenz aus. Alle gastspezifischen Einstellungen werden gelöscht, die Energielasten werden minimiert, und das Haushaltssystem erhält eine Benachrichtigung, dass das Zimmer für die Reinigung bereit ist.

Check-out KNX-Telegrammsequenz

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)

Frühes Check-out-Handling: Wenn ein Gast vor der geplanten Zeit auscheckt, löst Opera das Check-out-Ereignis sofort aus. Die Middleware muss gleichzeitige Raumzustände verwalten – wenn die Karte noch eingesteckt ist, wenn das Check-out-Ereignis eintrifft, zeigt der Raumcontroller Anwesenheit = 1 vom Kartenschalter an, aber das PMS sagt, der Raum ist frei. Das PMS-Check-out-Ereignis sollte Priorität haben: Die Middleware sendet den Economy-Sollwert unabhängig vom Kartenschalterzustand, und die Rezeption weist den Gast an, die Karte an der Rezeption abzugeben.

Weckruf-Integration

Im PMS geplante Weckrufe können eine KNX-gesteuerte, allmähliche Lichtszene im Zimmer auslösen. Dies ist gastfreundlicher als ein Telefonwecker und ermöglicht es dem Gast, die Weckzeit direkt im Opera-Gastportal oder an der Rezeption einzustellen.

KNX-Weckrufsequenz

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 mit Home Assistant

Mews ist ein cloud-natives PMS mit einer gut dokumentierten REST-API und einem Webhook-System. Es ist das bevorzugte PMS für Boutique- und Lifestyle-Hotels. Die Integration mit Home Assistant bietet einen No-Code-Weg zur KNX-Raumautomation für kleinere Immobilien ohne dedizierten 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&apos;s Encrypt SSL

Space-ID-Zuordnung: Mews verwendet eine UUID-basierte space_id für Zimmer, keine lesbare Zimmernummer. Erstellen Sie einen HA-Helfer (input_select oder template sensor), der Mews-Space-UUIDs auf Zimmernummern abbildet. Für 50 Zimmer ist dies eine einmalige Konfiguration; aktualisieren Sie die Zuordnung, wenn Zimmer umnummeriert oder Spaces in Mews umstrukturiert werden.

Raumstatus-Rückmeldung an das PMS

Die Integration ist nicht einseitig: Änderungen des KNX-Raumzustands sollten das PMS aktualisieren, um dem Reinigungspersonal und der Rezeption Echtzeit-Raumstatus bereitzustellen. Dies schließt den Kreislauf zwischen dem physischen Raum und dem Betriebssystem.

KNX-Ereignis	Gruppenadresse	PMS-Aktion
DND aktiviert	GA 10/Raum/1 = 1	Opera room status → 'Do Not Disturb'; housekeeping task blocked
Bitte-nicht-stören aufgehoben	GA 10/room/1 = 0	Opera room status → 'Available for housekeeping'
Zimmer-aufräumen aktiviert	GA 10/room/2 = 1	Opera housekeeping task created: 'Make Up Room — room XXX'
MUR gelöscht	GA 10/room/2 = 0	Opera-Housekeeping-Aufgabe entfernt oder als erledigt markiert
Zimmer frei (Karte entfernt)	GA 10/room/0 = 0	Optional: PMS note 'Guest left room' (not formal check-out)
Energie über Schwellwert	Energie GA täglich kWh	Opera Gästekonto: Energiezuschlag-Eintrag (falls Richtlinie zutrifft)

Middleware KNX-Listener — Gruppenmonitor

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.

Raumweise Energiemessung für Gastabrechnung

Einige Hotelbetreiber berechnen Gästen den Stromverbrauch über einer Standardzulage, insbesondere bei Langzeitaufenthalten oder Service-Apartments. KNX-verbundene Energiezähler auf Raumebene machen dies ohne separate Unterzähler-Infrastruktur praktikabel.

Raumweise Energiemessung einrichten

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-Resilienz und Failsafe-Design

Die PMS-KNX-Middleware muss widerstandsfähig gegen Netzwerkunterbrechungen, PMS-Ausfälle und Serverneustarts sein. Ein Raum, der während einer Netzwerkstörung im Sparmodus verharrt, während ein Gast anwesend ist, stellt ein erhebliches Betriebsproblem dar.

Anforderungen an die Ausfallsicherheit

Middleware läuft als systemd-Dienst – automatischer Neustart bei Absturz
PMS-Webhook-Wiederholung: Bei Middleware-Ausfall reiht Opera die Anfragen ein und wiederholt sie
Lokaler KNX-Kartenschalter überschreibt PMS-Zustand (Karte eingelegt = immer Komfort)
Watchdog: Wenn 60 Minuten kein PMS-Heartbeat, sende Komfort an alle belegten Räume
Zustandspersistenz: Middleware speichert Raumzustände bei jeder Änderung in SQLite
Beim Neustart: letzten bekannten Zustand wiederherstellen und an KNX senden

Ausfallsichere Regel – Karten-Schalter Priorität

Der Karten-Schalter-Eingang am SCN-RT55P ist ein lokaler Hardware-Eingang – er ist nicht von Middleware oder Netzwerkverbindung abhängig. Fällt die Middleware aus, steuert der Karten-Schalter die Anwesenheit und HVAC-Energiesparumschaltung weiterhin lokal in ETS6. Das bedeutet, dass ein Gast aufgrund eines Softwarefehlers nie in einem kalten Raum zurückgelassen wird. PMS-Befehle werden über die lokale Karten-Schalter-Logik gelegt, nicht an deren Stelle.

Solutions

Technologies

Knowledge

Company