PMS alberghiero a KNX: Automazione check-in/out tramite gateway Fidelio e Opera
Collegare un sistema di gestione della proprietà alberghiera a KNX trasforma il check-in e il check-out in eventi automatizzati di gestione dell'edificio. Un ospite che effettua il check-in alla reception può attivare una scena di benvenuto, la modalità comfort HVAC e lo standby TV nella sua camera in pochi secondi – senza ulteriori azioni del personale. Per ottenere un'architettura di integrazione corretta è necessario comprendere sia il modello degli eventi PMS che lo schema degli indirizzi di gruppo KNX.
Panoramica dei sistemi PMS
I sistemi di gestione della proprietà (PMS) sono la spina dorsale operativa di un hotel – gestiscono prenotazioni, check-in/out, assegnazione camere, fatturazione, compiti di pulizia e reportistica. Per l'integrazione KNX la capacità rilevante è l'API degli eventi PMS: un meccanismo tramite il quale il PMS trasmette eventi di cambiamento di stato della camera a cui il middleware può iscriversi.
| Sistema PMS | Segmento di mercato | API di integrazione | Opzioni gateway KNX |
|---|---|---|---|
| Oracle Opera Cloud | 4–5 stelle, catene | Opera REST API v3 + webhooks | Loytec LIOR-800, middleware Node.js personalizzato |
| Mews PMS | Cloud-native, boutique/lifestyle | API Webhooks Mews (REST) | Home Assistant + integrazione KNX, middleware personalizzato |
| Apaleo | Boutique europea, aparthotel | Apaleo Open API (REST) | Middleware personalizzato, bridge Zapier + KNX |
| Micros Fidelio (legacy) | Ampiamente installato, hotel cittadini | FIAS (Fidelio Interface API Specification) — socket TCP | HMS Anybus, gateway FIAS-KNX dedicato |
| Protel Air | Hotel indipendenti europei | Protel Webhooks + REST | Middleware personalizzato Node.js o Python |
FIAS vs REST: Le installazioni Micros Fidelio più vecchie usano FIAS — un protocollo socket TCP proprietario con un formato di messaggio testuale. Il moderno Oracle Opera Cloud utilizza una API REST standard con webhook JSON. Quando si integra con un'installazione Fidelio legacy, è necessario un parser FIAS dedicato nel livello middleware. Le nuove installazioni dovrebbero standardizzarsi su Oracle Opera Cloud o Mews per un accesso API più pulito.
Metodi di integrazione PMS-KNX
Quattro distinte architetture di integrazione sono utilizzate per la connettività PMS-KNX negli hotel. La scelta dipende dal tipo di API del PMS, dalle dimensioni dell'hotel, dalla disponibilità dell'infrastruttura IT e dalle capacità tecniche interne per la manutenzione continua.
1. Gateway PMS-KNX dedicato
Apparecchio gateway hardware (es. Loytec LIOR-800) con interfaccia Opera/Fidelio integrata. Si collega al PMS tramite FIAS o REST; emette telegrammi KNX tramite KNXnet/IP. Gestito tramite interfaccia web. Ideale per strutture 4–5 stelle che richiedono una soluzione supportata monofornitore con SLA.
Vantaggi: Supportato dal fornitore, punto di configurazione singolo
Svantaggio: Costo più elevato (€2.000–8.000); proprietario; flessibilità limitata
2. Middleware Node.js/Python personalizzato
Server auto-ospitato (VM Linux o Raspberry Pi) che esegue middleware che si abbina ai webhook PMS, mappa i numeri delle stanze agli indirizzi di gruppo KNX e invia telegrammi KNX tramite socket KNXnet/IP (node-red-contrib-knx o libreria knx Python). Il più flessibile; costo più basso.
Vantaggi: Controllo completo; costo basso; qualsiasi API PMS supportata
Svantaggio: Richiede sviluppo e manutenzione continua; nessun supporto del fornitore
3. Home Assistant + integrazione webhook PMS
HA installato su server locale con integrazione KNX configurata. Webhook PMS POST all'URL webhook HA. L'automazione HA estrae room_id, mappa al blocco GA KNX, attiva la scena KNX. Pratico per Mews e Apaleo; richiede endpoint HTTPS pubblico (Cloudflare Tunnel o IP dedicato).
Vantaggi: Nessun codice personalizzato; integrazione HA KNX ben mantenuta; configurazione GUI
Svantaggio: Gli aggiornamenti HA possono rompere le automazioni; non adatto per grandi hotel
4. KNX Virtual / middleware BMS
Piattaforma di sistema di gestione dell'edificio (BMS) (es. Siemens Desigo CC, ABB Ability) con modulo connettore PMS. Gli eventi PMS entrano nel BMS; il BMS gestisce KNX tramite driver KNXnet/IP. Di livello enterprise; adatto per grandi catene alberghiere con infrastruttura BMS esistente.
Vantaggi: Di livello enterprise; integrazione BMS completa; gestione energetica
Svantaggio: Costo elevato; richiede competenze BMS; eccessivo per hotel indipendenti
Flusso eventi check-in Oracle Opera
Oracle Opera Cloud attiva un webhook a ogni evento del ciclo di vita dell'ospite. L'evento di check-in contiene il numero della camera, il nome dell'ospite, la data di arrivo e il tipo di camera assegnato. Il middleware riceve questo evento e lo traduce in telegrammi KNX per la camera assegnata.
Webhook check-in Opera → flusso 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 comfortAutomazione sequenza check-out
L'evento di check-out attiva una sequenza completa di spegnimento della camera. Tutte le impostazioni specifiche dell'ospite vengono cancellate, i carichi energetici sono ridotti al minimo e il sistema di pulizie riceve una notifica che la camera è disponibile per la pulizia.
Sequenza telegrammi KNX di 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)
Gestione check-out anticipato: Se un ospite effettua il check-out prima dell'orario previsto, Opera attiva immediatamente l'evento di check-out. Il middleware deve gestire stati simultanei della camera — se la carta è ancora inserita quando arriva l'evento di check-out, il controller della camera mostrerà presenza = 1 dall'interruttore della carta, ma il PMS dice che la camera è libera. L'evento di check-out del PMS deve avere la priorità: il middleware invia il setpoint economico indipendentemente dallo stato dell'interruttore della carta, e la reception istruisce l'ospite a lasciare la carta alla reception.
Integrazione sveglia
Le sveglie programmate nel PMS possono attivare una scena di illuminazione graduale controllata da KNX nella stanza. È più accogliente di una sveglia telefonica e consente all'ospite di impostare l'ora del risveglio direttamente nel portale ospiti Opera o alla reception.
Sequenza KNX della sveglia
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)Integrazione webhook PMS Mews con Home Assistant
Mews è un PMS nativo cloud con un'API REST e un sistema di webhook ben documentati. È il PMS preferito per hotel boutique e lifestyle. L'integrazione con Home Assistant fornisce un percorso senza codice per l'automazione delle camere KNX per strutture più piccole senza un server middleware dedicato.
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 SSLMappatura Space ID: Mews utilizza un space_id basato su UUID per le camere, non un numero di camera leggibile. Crea un helper HA (input_select o template sensor) che mappa gli UUID degli spazi Mews ai numeri di camera. Per 50 camere è una configurazione una tantum; aggiorna la mappatura se le camere vengono rinumerate o gli spazi vengono ristrutturati in Mews.
Feedback dello stato della camera al PMS
L'integrazione non è unidirezionale: i cambiamenti di stato della stanza KNX devono aggiornare il PMS per fornire al personale delle pulizie e alla reception lo stato della camera in tempo reale. Questo chiude il cerchio tra la stanza fisica e il sistema operativo.
| Evento KNX | Indirizzo di gruppo | Azione PMS |
|---|---|---|
| DND attivato | GA 10/stanza/1 = 1 | Opera room status → 'Do Not Disturb'; housekeeping task blocked |
| NPD cancellato | GA 10/room/1 = 0 | Opera room status → 'Available for housekeeping' |
| MUR attivato | GA 10/room/2 = 1 | Opera housekeeping task created: 'Make Up Room — room XXX' |
| MUR cancellato | GA 10/room/2 = 0 | Compito di housekeeping Opera rimosso o contrassegnato come completato |
| Camera libera (carta rimossa) | GA 10/room/0 = 0 | Optional: PMS note 'Guest left room' (not formal check-out) |
| Energia sopra la soglia | Energia GA giornaliera kWh | Foglio conto ospite Opera: voce di sovrapprezzo energetico (se applicabile) |
Middleware KNX listener — monitor gruppi
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.Misurazione energetica per stanza per fatturazione ospite
Alcuni operatori alberghieri addebitano agli ospiti il consumo di elettricità oltre una franchigia standard, in particolare per soggiorni lunghi o appartamenti con servizi. I contatori energetici collegati KNX a livello di stanza rendono ciò pratico senza infrastruttura di sottocontatori separata.
Configurazione misurazione energetica per stanza
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.Resilienza del middleware e design fail-safe
Il middleware PMS-KNX deve essere resiliente a interruzioni di rete, downtime del PMS e riavvii del server. Una stanza che rimane in modalità economia durante un'interruzione di rete mentre un ospite è presente è un problema operativo significativo.
Requisiti di resilienza
- Il middleware viene eseguito come servizio systemd — riavvio automatico in caso di crash
- Ritentativo webhook PMS: se il middleware è giù, Opera accoda e riprova
- Interruttore locale scheda KNX sovrascrive lo stato PMS (scheda inserita = sempre comfort)
- Watchdog: se nessun heartbeat PMS per 60 min, invia comfort a tutte le stanze occupate
- Persistenza dello stato: il middleware salva gli stati delle stanze su SQLite ad ogni modifica
- Al riavvio: ripristina l'ultimo stato noto e reinvia a KNX
Regola fail-safe – priorità dell'interruttore a scheda
L'ingresso dell'interruttore a scheda sul SCN-RT55P è un ingresso hardware locale – non dipende dal middleware né dalla connettività di rete. Se il middleware si guasta, l'interruttore a scheda controlla comunque la presenza e la commutazione economica HVAC localmente in ETS6. Ciò significa che un ospite non viene mai lasciato in una stanza fredda a causa di un guasto software. I comandi PMS sono sovrapposti alla logica locale dell'interruttore a scheda, non al posto di essa.
Hai bisogno di un'integrazione PMS-KNX progettata e messa in servizio per il tuo hotel?
Progettiamo quadri KNX per hotel con middleware di integrazione PMS, configurazione webhook Opera e Mews, misurazione energetica per stanza e documentazione completa di messa in servizio – pronti per la consegna al tuo team IT.
Richiedi un preventivo →