How to Specify a KNX Hotel Guest Room Management System
Specify a KNX hotel GRMS with occupancy states, PMS boundaries, HVAC priorities, room I/O schedules, offline behavior, and mock-up acceptance tests.
A useful KNX hotel GRMS specification starts with room behavior, not a list of touchscreens. It must say how the room responds to a guest, a housekeeper, an open window, a lost network connection, and a checkout message that arrives late.
GRMS means guest room management system. In this context it coordinates room lighting, comfort control, shading, and service indications. The property management system, or PMS, supplies hotel-operating information; it is not a reliable real-time detector of whether somebody is in bed.
If the tender only says “occupancy-based energy saving,” two bidders can submit quite different systems and both claim compliance. The following structure makes those differences visible before purchase.
Separate the room’s three kinds of state
Start with three variables: commercial status, physical occupancy, and service status. Do not compress them into one occupied/unoccupied bit.
| State family | Example values | Authoritative source | What it must not imply |
|---|---|---|---|
| Commercial | Checked in, checked out, out of service | PMS or approved hotel workflow | Checked in does not mean physically present |
| Occupancy | Present, absent, uncertain | Defined room sensor and door logic | No movement does not prove an empty bed |
| Service | DND, make up room, cleaning in progress | Guest control and housekeeping workflow | DND is not a room-vacancy signal |
Zennio’s hotel solutions documentation describes occupancy-linked climate and lighting control alongside PMS and access-control integration. That establishes a useful division of functions; it does not supply a universal state machine for every hotel.
Ask the operator to approve a state table. Who can clear a make-up-room request? Does checkout reset DND immediately, or only after staff acknowledgement? Can reception override a guest temperature preference? These are operating decisions that an ETS programmer should not have to invent on site.
Write the sleeping-guest test first
A motion timeout is an especially poor starting point for a bedroom. Define an occupancy strategy using the actual detector coverage, door events, and any approved key or access signals. Then test the uncertain cases.
For a proposed door-assisted strategy, a door opening could initiate a departure-assessment window rather than immediately declaring vacancy. Subsequent detected presence retains occupied status. A silent room after a qualifying door sequence may transition to absence after an agreed delay. The exact algorithm must come from the selected controller’s application and the hotel’s risk tolerance.
It still needs a two-person test: one guest leaves while another sleeps. It also needs a bathroom test, a door held open by housekeeping, and a sensor fault. A latch based on past presence can protect comfort but may waste energy if it never clears. A short timeout can save energy while failing the room’s primary purpose. Document the chosen compromise.
| Mock-up scenario | Required outcome to agree | Evidence to capture |
|---|---|---|
| Guest remains still in bed | No unwanted blackout or aggressive HVAC setback | State log and witnessed room behavior |
| One of two guests leaves | Remaining guest keeps agreed comfort and controls | Door and detector event sequence |
| Housekeeping enters a checked-out room | Defined cleaning mode, with controlled expiry | Access/service event and mode feedback |
| Door contact becomes unavailable | Fault indicated; conservative occupancy fallback | Disconnected-input test |
| Guest selects sleep scene | Lights follow the scene; occupancy logic does not undo it | Scene command, output states, later sensor events |
“Conservative” should mean something specific here: for example, retain the occupied comfort band and flag the faulty input until maintenance intervenes. It should not mean silently treating every fault as permanent occupancy.
Describe one room completely before multiplying it
Use a room-type schedule, with separate rows for standard rooms, suites, accessible rooms, and interconnecting rooms. Count physical loads, not icons on a display.
| Item | Information needed in the GRMS schedule | Common scope gap |
|---|---|---|
| Bedside lighting | Circuit, dimming method, minimum usable level, scene membership | Both bedside lamps accidentally share one control channel |
| Curtains | Motor interface, travel direction, stop behavior, maintenance access | An open/close icon is supplied without motor compatibility |
| Fan coil | Valve type, fan interface, changeover source, condensate/protection boundary | “HVAC compatible” hides an unpriced gateway |
| Guest controls | Location, language, nighttime brightness, feedback | A master-OFF button disconnects an excluded socket |
| DND/MUR indication | Inside command, corridor indication, staff acknowledgement | A request disappears before housekeeping sees it |
| Door/window inputs | Contact type, cable route, fault interpretation | Normally open/closed semantics are unspecified |
Keep minibar, essential outlets, emergency lighting, and statutory safety systems outside casual “all off” logic. The responsible electrical and life-safety designers must define those boundaries. A room automation interface is not a substitute for a required protective or alarm system.
Give HVAC an explicit priority order
Consider a cooling request while the balcony door is open and reception has just changed the room to checked out. Which instruction wins?
A proposed priority list is equipment protection first, then approved maintenance control, then window/door comfort interlocks, then room operating mode, then the guest’s permitted adjustment. The mechanical designer must confirm that order for the actual plant. Humidity control, frost protection, condensate alarms, and minimum equipment operating times may require different treatment.
Specify a permissible setpoint range, not only a default temperature. State whether the displayed number is a guest preference or the controller’s effective setpoint. If they differ, label the interface clearly. A guest should not see 21°C while an unexplained override is holding the room at 26°C.
Window opening should use an agreed delay and recovery sequence. A contact chattering in the wind should not repeatedly switch a compressor. For related design questions, see the KNX HVAC zoning guide.
Make PMS integration a small, owned contract
Exchange the minimum operational data needed. Room number, check-in/check-out state, a defined service request, and acknowledgement may be enough; guest names and reservation details usually add privacy exposure without improving a lighting scene.
| Interface detail | Specify before ordering |
|---|---|
| Room identity | Mapping between PMS room ID, GRMS room ID, and KNX address structure |
| Delivery behavior | Event or polling, retry policy, duplicate handling, timestamps |
| Stale data | Timeout, visible quality flag, and fallback room behavior |
| Restart | Which system restores state and how contradictions are reconciled |
| Responsibility | Named owner for PMS connector, network, room logic, and acceptance |
A late checkout event must not override a newer check-in. Require ordering or reconciliation behavior and test it with deliberately delayed messages. See KNX and hotel PMS integration for the wider interface boundary.
The LAN may be unavailable while the KNX room bus remains healthy. Specify which local controls continue in that condition. Separately test loss of bus power: that is a different failure, and “works offline” tells you nothing about it.
Buy a witnessed mock-up, not just a showroom demonstration
Use the actual room’s luminaires, driver types, fan coil interface, curtain motor, bedside controls, and representative network. A bench with substitute loads cannot settle dimming quality, relay noise, or the brightness of a screen in a dark room.
Agree acceptance records for each scene, local override, actuator feedback, service indication, and restart. Measure response time against a project-agreed limit rather than promising a universal number. Include duplicate PMS messages and a disconnected gateway. Repeat relevant tests after a firmware or ETS application revision.
For rollout, retain a signed room-type configuration and a differences register. A suite should not quietly inherit a standard-room template with unused channels and wrong names. The commissioning process should include room-by-room evidence, not just one successful mock-up.
Questions that belong in the tender
Does every hotel room need a touchscreen?
No. Simple tactile bedside controls can be a better fit for lights and sleep scenes. Choose a touchscreen where its extra functions are genuinely useful, and keep essential guest actions easy to find.
Can the PMS alone determine occupancy?
No. It describes hotel-operating status. Physical occupancy requires a separate, tested strategy, including the possibility that the system is uncertain.
Can a bidder guarantee an energy-saving percentage?
Not from a device list. Ask for a baseline, measurement boundary, occupancy and weather normalization, and a verification period. Treat an unqualified percentage as a marketing claim, not an acceptance criterion.
What is the minimum handover package?
A recoverable ETS project, room-state narrative, I/O and group-address schedules, approved software versions, interface ownership, secure credential handover, and the witnessed test results. Add a practical procedure for replacing one room controller without disturbing neighboring rooms.
Before requesting a project review, assemble one representative room plan and its load schedule. Those two documents reveal more about the required GRMS than a catalogue of panel finishes.