How the hotel PMS and the guest room control system exchange events: welcome and all-off scenes, room status back to the PMS, energy reports — and how an integration is debugged and accepted.
Discuss Your PMS IntegrationPMS integration keeps the hotel management system and the rooms in sync: check-in triggers the welcome scene, check-out switches everything off, housekeeping and engineering see live room status — without anyone re-typing it.
The PMS remains the single source of truth for reservations; the room control system is the executor and the sensor network. Every HOTEKEY RCU reports to HOTEKEY Cloud, and the cloud exchanges events with the PMS — so a front-desk action or a room sensor can each set off the correct downstream scene.
HOTEKEY integrates with the mainstream hospitality PMS platforms — including Opera / Fidelio class systems and chain-hotel APIs — over TCP/IP or serial links, with the interface parameters agreed per property.
Integration is protocol-level, not brand-level: the cloud side exposes standard events (reservation change, room status, service request) and maps them to the PMS interface in use. For chain properties the chain's own API is used; for independent hotels the property's PMS vendor supplies the interface document and HOTEKEY completes the mapping.
Three event families flow: reservation events (check-in / check-out / room move) drive room scenes; room status events (do-not-disturb, make-up-room, maintenance) flow from the rooms back to the PMS; and energy data accumulates into per-room reports.
Typical check-in flow: the PMS posts the check-in, the cloud pushes a welcome scene to the RCU — selected lights on, AC to the default setpoint, curtains open. Check-out posts an all-off scene and flags the room for housekeeping. Staff never duplicate entries in two systems.
Check the interface parameters first (IP address, port, protocol type — TCP/IP or serial), then the room-number mapping between the PMS and the room control platform; most go-live sync failures are a mapping or parameter mismatch, not a broken link.
Debug sequence: 1) confirm the network path and that the PMS server accepts connections from the cloud integration; 2) verify the protocol parameters against the interface document; 3) test one room end-to-end (check-in → welcome scene → status back); 4) audit the room-number mapping table for the remaining rooms — duplicated or shifted room numbers are the most frequent fault on multi-building properties.
Yes. Linked with self check-in kiosks and smart locks, the same integration supports unattended operation: the guest completes check-in, receives an authorised card or mobile key, and the room prepares itself on first entry.
On first unlock the RCU recognises the authorised card and runs the welcome scene; the PMS sees the occupied status without front-desk action. The same event chain supports remote pre-conditioning — the front desk can start the AC before an arriving guest reaches the room.
Integration is accepted with a written test matrix: every event type (check-in, check-out, DND, make-up-room, service call) is triggered in both directions on sample rooms, then on a full floor, before the whole property goes live.
Handover includes the interface parameter sheet, the room-number mapping table, and the scene configuration backup — the three documents any future engineer needs to modify the integration safely. A reference deployment is the hotel PMS integration project in Mongolia, delivered with the local integrator.
Smart Hotel Solution · Guest Room Control System · RCU Troubleshooting Guide · Contact HOTEKEY