A guest room should not need your server to work

There is a question worth asking any vendor selling you a hotel energy system: what does the building do when your server is unreachable?

The answer separates two very different products that look identical in a brochure. One is a control system. The other is a monitoring dashboard with a control panel bolted on.

The failure that does not look like a failure

A hotel loses its network more often than anyone plans for. A switch reboots. Somebody unplugs the wrong thing in the riser. The internet line drops for four hours on a Sunday. None of these are dramatic, and none of them get reported as incidents.

If your energy policy is enforced centrally, all of them stop the saving. Nobody notices, because nothing visibly breaks — the rooms just quietly go back to running as if there were no system at all. The bill arrives a month later and nobody connects it to the switch that rebooted.

Worse is the version where the room does visibly break. A guest returns to a room that has been sitting at 30 °C because the server that was supposed to bring it back never got the keycard event. That is a complaint at reception, and it is the fastest way to have a building system switched off by the people who have to live with it.

Where the decision belongs

The rule we settled on is that the decision belongs as close to the room as the decision’s inputs are.

Occupancy is known in the room — a keycard is in a slot or it is not. The door is open or it is not. The setpoint is whatever the guest last chose. All three inputs are physically present at the room module. Nothing about deciding “the room is empty, drop to the setback setpoint after twenty minutes” requires a server, a network or a cloud.

So that decision is made on the module, from configuration stored on the module. It survives:

• the gateway being unreachable
• the site server being rebooted or replaced
• the internet being down
• a power cut, because the configuration is in non-volatile memory and the module restores its own state on power-up

The central system’s job is to set the policy, observe the outcome, and override when a human wants to. Not to be in the loop for every keycard pull.

What that costs

This is not free, and it is worth being honest about the trade.

Putting the policy on the module means the module has to hold state, which means it has to be commissioned properly and its configuration has to be kept in step with the centre. That is real engineering work: a schema for the stored configuration, a way to push changes reliably, a way to detect drift, and a firmware update path that will not brick a device sitting behind a wall in an occupied room.

The centralised alternative is genuinely easier to build. You keep every decision in one place where you can see it, change it, and debug it. That is why so many systems are built that way.

We think it is the wrong trade for hospitality specifically, because the cost of the failure lands on a guest rather than on an operator, and because the buildings we work in do not have the network reliability that assumption requires.

The part people forget: the guest still has a remote

An energy scheme that works by taking control away from the guest gets defeated. Guests find the override. They wedge the keycard slot with a business card. They complain, and the property turns the strictness down until the saving is gone.

So the guest’s own remote keeps working. Within limits you set, they can do what they want. The system does not fight them while they are in the room — it acts when the room is empty, which is the only time the saving is free.

Occupancy-driven setback works because an empty room has no opinion.

What to ask a vendor

If you are evaluating anything in this category, three questions get you most of the way:

1. Where is the setback policy stored, and what enforces it? If the answer is “our server”, the saving depends on your network.
2. What happens to a room mid-stay if the gateway dies? “It holds its current state” and “it reverts to always-on” are very different answers.
3. Can the guest still use their remote? If not, ask what happens when they complain.

None of these are trick questions. A vendor who has thought about the problem will have ready answers, because they will have had to make these decisions explicitly.

We wrote ours down because we got some of them wrong the first time.