Energy is one of the largest controllable costs in a full-service hotel, and much of it is spent where nobody is. A guest checks out at ten, and the room may sit lit and conditioned for hours. The ballroom gets cooled for an event that starts at seven. Corridor lighting runs at full output through the night. The reason is rarely bad intent. Lighting, HVAC and the building management system were bought from different vendors at different times, and they do not share what they know. The property management system knows the room is vacant. The lights and the fan coil do not.
Fixing that means an integration project across hundreds of rooms, and the owner carries the risk. Will the new lighting controls work with the BMS? Will guests be comfortable? Will the saving be real? Nobody wants to find out on a fully booked weekend.
What a digital twin means here
A digital twin of a hotel is a working model of the building and its systems: rooms, floors, plant, lighting networks, controllers and the logic that connects them. Because the model behaves like the building, you can run a day of check-ins and check-outs and watch the systems respond, before anything is installed. The idea is broader than hotels; see What is a digital twin?.
For an owner, the twin is a rehearsal space for integration and a common picture for the operator, the engineers and the vendors.
What we built
Our Hotel Twin models Octopus Grand Hotel Sydney, a fictional 20-storey five-star harbourside hotel with 277 keys, from three basement levels to the roof.
- Every room is a set of devices. Over 5,500 simulated devices, including lighting, fan coils, sensors, and sheer and blackout curtain motors. More than 1,000 of them appear as BACnet devices, organised the way a real BMS would see them.
- A lighting integration behind a connector. A simulated Casambi-style lighting network sits behind a connector. The connector uses the same device model that a future live connection would use, and it has three modes: Simulation, Hybrid and Live. Compatibility is tested separately from the simulation with a conformance suite. A simulation that passes is not taken as proof that the integration will work.
- Physics with labelled provenance. Every value is marked PHYS (physics-simulated), EST (estimated) or DEMO (scripted for the story). Comfort is checked room by room, so a saving that makes occupied rooms uncomfortable shows up as a failure.
- A repeatable seven-step storyline. The story runs from check-in to dimming a vacant room, an AI optimisation and a device fault. It is event-sourced, so it replays identically every time, and every step leaves an audit trail with the basis for each AI calculation.
- Rooms you can walk into. Guest rooms and suites are rendered with baked lighting. A smart-room panel lets you set curtains, presets and the room setpoint, and the building responds.
Decisions it helps you make
- What actually happens in a room between check-out and the next check-in, and what does it cost?
- If lighting, curtains and HVAC follow occupancy and daylight, does comfort hold in every occupied room?
- Which floors, zones or plant items drive the energy bill at two in the afternoon on a hot day?
- Can the new lighting controls hand their data to our BMS, and how will we prove it before rollout?
- When a device fails, who sees it first, and what does the guest notice?
What changes
Before: each system is commissioned on its own, and integration is tested room by room after installation. Savings are estimated in a proposal and argued about afterwards. Engineering, front office and vendors each hold part of the picture.
After: the integrated behaviour is visible before purchase orders are signed. Vendors integrate against a shared device model and a conformance test instead of a slide deck. Operators see check-in, vacancy, comfort and energy on one screen. Engineering gets faults with their context, and the owner can see what the expected saving rests on. Rollout can be planned floor by floor, with the twin showing what each phase changes.
Getting there in your hotel
- Discovery. We collect floor plans, room types, the device schedules for lighting and HVAC, BMS point lists, PMS occupancy history and utility bills, and agree on the questions the twin must answer.
- Prototype on your data. We model your building and room types, replay your real occupancy, and show the joined-up behaviour with every number labelled simulated or estimated.
- Connected twin. We connect to the BMS over BACnet/IP and to the lighting system through its official API. A pilot floor runs in Hybrid mode, and the model is calibrated against metered data before anyone quotes a saving.
Ask any vendor: Which numbers are physics, which are estimates, and which are scripted? How is compatibility with my lighting system tested, separately from your simulation? What happens to guest comfort in your optimisation? Who owns the runtime and the data?
Honest limits
The hotel is fictional, and every device in this demo is simulated. The lighting simulator is an Octopus mock modelled on public documentation. It is not a Casambi product or an official Casambi environment, and no Casambi network or BMS is connected. The 13.4 % HVAC and lighting saving shown in the demo is a simulated, demo-only figure, not a commitment for any building. It has not been calibrated against metered data.
See it for yourself
- Live twin: hotel.octopustwin.com
- Case study: Hotel Twin · Lighting, HVAC & BMS
- Planning a lighting or BMS upgrade? Talk to us before you commit.
