Definition
RCU (Room Control Unit, guest room controller) is an intelligent control device for hotel rooms, responsible for controlling lights, air conditioning, curtains, TV, power outlets, etc., and interfacing with PMS (Property Management System) to enable check-in/check-out linkage (card insertion for power, power off at check-out), energy monitoring, remote control, scene modes, and more. RCU is one of the core hardware components of smart hotels, supporting room intelligence and energy management.
RCU communicates with PMS and BAS via wired (RS-485, KNX) or wireless (Zigbee, Bluetooth, Wi-Fi) methods. IoT SIM cards provide connectivity for RCU remote operation, centralized management of multiple hotels, OTA upgrades, and scenarios without wired deployment.
Technical Features
RCU supports card-based power, unattended energy saving (turning off air conditioning and lights), Do Not Disturb, Please Clean, and other linkages. Integration with PMS allows obtaining check-in status, enabling energy saving for vacant rooms. Some RCUs support voice control and mobile app control. Multi-hotel chain scenarios require a centralized management platform, with IoT SIM cards ensuring data return from RCUs in each hotel.
Use Cases
RCU is applied in hotels, guesthouses, apartments, and long-stay apartments. Typical applications include check-in/check-out linkage, room energy monitoring, remote control, centralized management of multiple hotels, and energy saving for vacant rooms. SimtoLink provides IoT SIM cards, dedicated APN, and smart hotel solutions for RCU smart hotel scenarios.
How the occupied flag drives the room load
An RCU uses an IoT SIM so that, on a floor or a franchised property with no dedicated room network, check-in, check-out, and power-take status can reach the hotel system, and the result of the vacant-room policy can come back. It is not a remote switch for the lights. Whether lights, air conditioning, curtains, and outlets should run depends on whether this room is occupied, vacant-dirty, vacant-clean, or under maintenance. The room number and the controller identity must already be bound. A room-status change from the hotel system must be able to reach this controller, and the controller must be able to report card insert, door contact, or occupancy. With downlink only and no uplink, the front desk thinks the room was checked out and powered off, the card is still in the slot, and the air conditioning keeps running.
The boundary between vacant-room saving and guest comfort belongs in the policy, not in whether the SIM is online. While occupied, the guest may change the temperature. While vacant, air conditioning is limited to what freeze protection or mold prevention needs. That range is an HVAC policy. The controller executes it, and the platform only sends room status. How the building-side central air-conditioning plant supplies cooling is a separate layer. If the room valve is fully open and the plant has no cooling capacity, that must not be recorded as the RCU failing to execute. When the link drops, the controller should keep the last valid room status. It must not reboot into a default of occupied or a default of vacant.
Card power conflicts with the platform status
A common mistake is that power-take trusts only the inserted card, room status trusts only the platform, and a conflict has no priority. The guest has checked in but the room-status message is late, and the room stays dark. Or the guest has checked out, the card was not removed, and the platform keeps supplying power because of an old "occupied." A clear check-out may remove power, but it needs a delay. A failed check-in message must not cut power immediately in a room that already has someone in it. Another mistake is a maintenance room covered by the ordinary vacant-room policy. A technician taking power is treated as a guest check-in, and check-out logic then removes the power.
In centralized operations across properties, a repeated room number whose controller serial is not bound to the property sends the command to the same room number at another property. A firmware upgrade should also not reboot the whole room's loads while the room is occupied and the guest is using it. For acceptance, do one check-in and one check-out, and pull the uplink in between. After check-in the loads should be available. After the check-out message arrives, an unremoved card should enter the vacant-room policy after the agreed delay. During maintenance status, an ordinary check-out command must not return the room to for-sale and open power-take. The three room states must be distinguishable in the record.
A room under maintenance must not take the vacant-room policy
During maintenance status, an ordinary check-out or vacant-room command must not return the room to for-sale and open power-take. If the guest has checked in and room status is late, do not cut power immediately. If the guest has checked out and the card is still inserted, enter the vacant-room policy after the agreed delay, rather than supplying power as occupied indefinitely. After a reboot the controller keeps the last valid room status. It must not default to occupied or vacant. The room number must be bound together with the property and the controller serial, so a same-number command is not sent to another property.
While the room is occupied, a full reboot and an upgrade that affects power-take can wait. Limiting the air-conditioning range in a vacant room is a room policy. No cooling capacity at the plant must not be recorded as the controller failing to execute. Loads available after check-in, power removed after the check-out delay, and maintenance status not rewritten by an ordinary command: when those three records stay separate, the room controller and the hotel room status are aligned.