PMS hôtelier vers KNX : Automatisation check-in/out via passerelles Fidelio et Opera
Connecter un système de gestion hôtelière à KNX transforme le check-in et le check-out en événements automatisés de gestion du bâtiment. Un client qui s'enregistre à la réception peut déclencher une scène d'accueil, le mode confort CVC et la veille TV dans sa chambre en quelques secondes – sans action supplémentaire du personnel. Pour obtenir une architecture d'intégration correcte, il faut comprendre à la fois le modèle d'événements PMS et le schéma d'adresses de groupe KNX.
Aperçu des systèmes PMS
Les systèmes de gestion immobilière (PMS) sont la colonne vertébrale opérationnelle d'un hôtel – ils gèrent les réservations, l'enregistrement/le départ, l'attribution des chambres, la facturation, les tâches de ménage et les rapports. Pour l'intégration KNX, la capacité pertinente est l'API d'événements PMS : un mécanisme par lequel le PMS diffuse des événements de changement d'état de chambre auxquels un middleware peut s'abonner.
| Système PMS | Segment de marché | API d'intégration | Options de passerelle KNX |
|---|---|---|---|
| Oracle Opera Cloud | 4–5 étoiles, chaînes | Opera REST API v3 + webhooks | Loytec LIOR-800, middleware Node.js personnalisé |
| Mews PMS | Natif cloud, boutique/lifestyle | API Webhooks Mews (REST) | Home Assistant + intégration KNX, middleware personnalisé |
| Apaleo | Boutique européenne, aparthotels | API ouverte Apaleo (REST) | Middleware personnalisé, pont Zapier + KNX |
| Micros Fidelio (hérité) | Largement installé, hôtels de ville | FIAS (Fidelio Interface API Specification) — socket TCP | HMS Anybus, passerelle FIAS-KNX dédiée |
| Protel Air | Hôtels indépendants européens | Protel Webhooks + REST | Middleware personnalisé Node.js ou Python |
FIAS vs REST : Les anciennes installations Micros Fidelio utilisent FIAS — un protocole socket TCP propriétaire avec un format de message textuel. Le moderne Oracle Opera Cloud utilise une API REST standard avec des webhooks JSON. Lors de l'intégration avec une installation Fidelio héritée, un analyseur FIAS dédié est nécessaire dans la couche middleware. Les nouvelles installations devraient se standardiser sur Oracle Opera Cloud ou Mews pour un accès API plus propre.
Méthodes d'intégration PMS vers KNX
Quatre architectures d'intégration distinctes sont utilisées pour la connectivité PMS-KNX hôtelière. Le choix dépend du type d'API PMS, de la taille de l'hôtel, de la disponibilité de l'infrastructure informatique et des capacités techniques internes pour la maintenance continue.
1. Passerelle PMS-KNX dédiée
Appareil passerelle matérielle (par ex., Loytec LIOR-800) avec interface Opera/Fidelio intégrée. Se connecte au PMS via FIAS ou REST ; émet des télégrammes KNX via KNXnet/IP. Géré via interface web. Idéal pour les établissements 4–5 étoiles nécessitant une solution supportée mono-fournisseur avec SLA.
Avantages : Prise en charge par le fournisseur, point de configuration unique
Inconvénient : Coût plus élevé (2 000–8 000 €) ; propriétaire ; flexibilité limitée
2. Middleware personnalisé Node.js/Python
Serveur auto-hébergé (VM Linux ou Raspberry Pi) exécutant un middleware qui s'abonne aux webhooks PMS, mappe les numéros de chambre aux adresses de groupe KNX et envoie des télégrammes KNX via socket KNXnet/IP (node-red-contrib-knx ou bibliothèque knx Python). Le plus flexible ; le moins coûteux.
Avantages : Contrôle total ; faible coût ; toute API PMS prise en charge
Inconvénient : Nécessite du développement et une maintenance continue ; pas de support fournisseur
3. Home Assistant + intégration webhook PMS
HA installé sur un serveur local avec l'intégration KNX configurée. Webhooks PMS POST vers l'URL du webhook HA. L'automatisation HA extrait room_id, mappe au bloc GA KNX, déclenche la scène KNX. Pratique pour Mews et Apaleo ; nécessite un point de terminaison HTTPS public (Cloudflare Tunnel ou IP dédiée).
Avantages : Aucun code personnalisé ; intégration KNX HA bien maintenue ; configuration GUI
Inconvénient : Les mises à jour HA peuvent casser les automatismes ; ne convient pas aux grands hôtels
4. KNX Virtual / middleware BMS
Plateforme de système de gestion technique du bâtiment (BMS) (p. ex. Siemens Desigo CC, ABB Ability) avec module connecteur PMS. Les événements PMS entrent dans le BMS ; le BMS gère KNX via le pilote KNXnet/IP. Niveau entreprise ; adapté aux grandes chaînes hôtelières disposant d'une infrastructure BMS existante.
Avantages : Niveau entreprise ; intégration BMS complète ; gestion de l'énergie
Inconvénient : Coût élevé ; nécessite une expertise BMS ; excessif pour les hôtels indépendants
Flux d'événements check-in Oracle Opera
Oracle Opera Cloud déclenche un webhook à chaque événement du cycle de vie du client. L'événement d'enregistrement contient le numéro de chambre, le nom du client, la date d'arrivée et le type de chambre attribué. Le middleware reçoit cet événement et le traduit en télégrammes KNX pour la chambre attribuée.
Webhook d'enregistrement Opera → flux 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 comfortAutomatisation de la séquence de départ
L'événement de départ déclenche une séquence complète d'extinction de la chambre. Tous les paramètres spécifiques au client sont effacés, les charges énergétiques sont minimisées et le système de ménage reçoit une notification indiquant que la chambre est prête à être nettoyée.
Séquence de télégrammes KNX de départ
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)
Gestion du départ anticipé : Si un client part avant l'heure prévue, Opera déclenche immédiatement l'événement de départ. Le middleware doit gérer les états simultanés de la chambre — si la carte est toujours insérée lorsque l'événement de départ arrive, le contrôleur de chambre affichera présence = 1 depuis l'interrupteur de carte, mais le PMS indique que la chambre est vacante. L'événement de départ du PMS doit avoir la priorité : le middleware envoie le point de consigne économique quel que soit l'état de l'interrupteur de carte, et la réception demande au client de laisser la carte à la réception.
Intégration du réveil
Les réveils programmés dans le PMS peuvent déclencher une scène d'éclairage progressive contrôlée par KNX dans la chambre. C'est plus convivial qu'une alarme téléphonique et permet au client de régler l'heure du réveil directement dans le portail client Opera ou à la réception.
Séquence KNX de réveil
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)Intégration du webhook PMS Mews avec Home Assistant
Mews est un PMS natif cloud avec une API REST et un système de webhooks bien documentés. C'est le PMS préféré pour les hôtels boutiques et lifestyle. L'intégration avec Home Assistant offre un chemin sans code vers l'automatisation des chambres KNX pour les petits établissements sans serveur middleware dédié.
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's Encrypt SSLCorrespondance des Space ID : Mews utilise un space_id basé sur UUID pour les chambres, pas un numéro de chambre lisible. Créez un helper HA (input_select ou template sensor) qui fait correspondre les UUID d'espace Mews aux numéros de chambre. Pour 50 chambres, c'est une configuration unique ; mettez à jour la correspondance si les chambres sont renumérotées ou si les espaces sont restructurés dans Mews.
Retour d'état de la chambre au PMS
L'intégration n'est pas unidirectionnelle : les changements d'état de la pièce KNX doivent mettre à jour le PMS pour fournir au personnel d'entretien et à la réception l'état de la chambre en temps réel. Cela ferme la boucle entre la pièce physique et le système opérationnel.
| Événement KNX | Adresse de groupe | Action PMS |
|---|---|---|
| DND activé | GA 10/chambre/1 = 1 | Opera room status → 'Do Not Disturb'; housekeeping task blocked |
| NPD annulé | GA 10/room/1 = 0 | Opera room status → 'Available for housekeeping' |
| MUR activé | GA 10/room/2 = 1 | Opera housekeeping task created: 'Make Up Room — room XXX' |
| MUR effacé | GA 10/room/2 = 0 | Tâche de ménage Opera supprimée ou marquée comme terminée |
| Chambre libre (carte retirée) | GA 10/room/0 = 0 | Optional: PMS note 'Guest left room' (not formal check-out) |
| Énergie au-dessus du seuil | Énergie GA quotidienne kWh | Compte client Opera : entrée de supplément énergétique (si la politique s'applique) |
Middleware écouteur KNX — moniteur de groupe
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.Comptage d'énergie par chambre pour facturation client
Certains opérateurs hôteliers facturent aux clients la consommation d'électricité au-dessus d'une allocation standard, en particulier pour les clients de longue durée ou les appartements avec services. Les compteurs d'énergie connectés KNX au niveau de la chambre rendent cela pratique sans infrastructure de sous-comptage séparée.
Configuration du comptage d'énergie par chambre
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.Résilience du middleware et conception sécurisée
Le middleware PMS-KNX doit être résistant aux interruptions réseau, aux pannes PMS et aux redémarrages de serveur. Une pièce qui reste en mode économique pendant une panne réseau alors qu'un client est présent constitue un problème opérationnel majeur.
Exigences de résilience
- Le middleware s'exécute en tant que service systemd — redémarrage automatique en cas de crash
- Réessai du webhook PMS : si le middleware est hors service, Opera met en file d'attente et réessaie
- Interrupteur local de carte KNX remplace l'état PMS (carte insérée = confort toujours)
- Watchdog : si pas de heartbeat PMS pendant 60 min, envoyer confort à toutes les chambres occupées
- Persistance d'état : le middleware sauvegarde les états des chambres dans SQLite à chaque changement
- Au redémarrage : restaurer le dernier état connu et le renvoyer à KNX
Règle de sécurité – priorité de l'interrupteur à carte
L'entrée de l'interrupteur à carte sur le SCN-RT55P est une entrée matérielle locale – elle ne dépend pas du middleware ni de la connectivité réseau. Si le middleware tombe en panne, l'interrupteur à carte contrôle toujours la présence et la commutation économique HVAC localement dans ETS6. Cela signifie qu'un invité n'est jamais laissé dans une chambre froide à cause d'une défaillance logicielle. Les commandes PMS sont superposées à la logique locale de l'interrupteur à carte, pas à sa place.
Besoin d'une intégration PMS-KNX conçue et mise en service pour votre hôtel ?
Nous concevons des armoires KNX pour hôtels avec middleware d'intégration PMS, configuration de webhooks Opera et Mews, comptage d'énergie par chambre et documentation complète de mise en service – prêtes à être remises à votre équipe IT.
Demander un devis →