A hotel's building management system (BMS) and its guest-room or lighting control platform should only ever exchange a defined, narrow set of BACnet points — typically occupancy status, scene/mode commands, setpoint values, and load-shed signals — while each system keeps authority over its own domain. The BMS stays authoritative for central plant and mechanical sequencing; the lighting or room-control processor stays authoritative for scenes, keypads, and the guest-facing experience. Getting that split wrong, or skipping acceptance testing on it, is how a BMS write ends up stranding a guest room in an unusable state. This is a scope-of-work and commissioning question that belongs on the table with the MEP engineer and BMS programmer before any point list is finalized.
What actually crosses the wire between Crestron and a BMS?
Crestron's control processors support native BACnet/IP as a built-in feature rather than a bolt-on. The CP4N control processor documentation confirms "Native BACnet network/IP support," describing it as a way to give "a direct interface to third‑party building management systems over Ethernet, simplifying integration with HVAC, security, and other systems," while noting that "each system runs independently but communicates together on one platform" — which is the core design principle an owner's rep should hold the project to CP4N Features. In practice that means the points that cross the wire are the ones genuinely shared between the two systems: occupied/unoccupied status, a scene or mode selection, a temperature setpoint, and a load-shed or demand-response command. Anything that only matters to the guest experience — keypad scene recall, do-not-disturb state, shade position — has no reason to be exposed as a BACnet object at all.
It's worth noting that BACnet licensing on Crestron 4-Series processors is tiered: a free license supports up to 50 BACnet objects on a single processor, with a paid license required beyond that, up to a documented maximum of 1,000 objects when a processor is dedicated to BACnet use only. That object count should be sized against the real point list — not padded with every variable the programmer can expose — because it directly affects license cost and processor load.
How do virtual BACnet devices map to rooms and floors?
Crestron's control processors and virtualized room instances (such as those hosted on a Crestron Virtual Control server) are organized around a Room ID model, where each guest room or logical room runs as its own addressable instance with its own program and device associations. The Crestron Virtual Control server documentation describes adding rooms individually, each with a unique Room ID that "allows Crestron devices to connect to a room automatically" and persists across restarts. For a BMS integration, this room-by-room structure is what should map to the BMS's own point naming convention — one logical BACnet device per room, or in larger buildings, one per floor aggregation — so that a load-shed command sent to "Floor 6" resolves unambiguously to the correct set of room processors rather than relying on an engineer's manual cross-reference sheet.
This mapping exercise is exactly the kind of coordination that belongs in hospitality technology design meetings between the lighting/AV integrator and the BMS contractor, well before devices are commissioned room by room.
Where does BMS authority end and room-system authority begin?
The practical line is this: the BMS can request a state (unoccupied setback, demand-response load shed, a scheduled setpoint) but the room-control processor decides how to realize that request without breaking the guest experience. For thermostats, Crestron's BACnet Thermostat configuration documentation shows this clearly — a thermostat's setpoint objects carry a configurable Priority level, and the system defaults unconfigured objects to "Parent Priority," meaning the thermostat's own logic, not an arbitrary external write, decides which command wins when two sources disagree. The same documentation describes a "System Failsafe Temperature," used for "safe operation when there is no connection to a control system" — an explicit acknowledgment that the local device must have a safe default behavior if the network link to the BMS (or to the room processor itself) drops. That failsafe concept is the right model to require anywhere a BMS can write into a guest room: if the BACnet link goes down, the room should fall back to a known-safe local state, not freeze in whatever state the last BMS command left it.
When is a BBMD actually needed?
A BACnet Broadcast Management Device (BBMD) becomes necessary whenever the BMS and the lighting/room-control processors sit on different IP subnets, because standard BACnet/IP broadcast discovery does not cross a router boundary on its own. In a multi-floor hotel where guest-room processors are typically segmented onto their own VLAN away from the BMS and general building network, this is close to a given rather than an edge case. Crestron's native BACnet/IP support on processors like the 4-Series runs over the same Ethernet interface used for other control traffic, so the BBMD or foreign-device registration needs to be planned as part of the network design — not discovered during commissioning when a BMS operator notices rooms aren't reporting status.
What should be tested before a BMS command can reach a live guest room?
Before any guest room is handed over, every point that the BMS can write to — setpoints, mode changes, load-shed commands — should be tested under three conditions: normal operation, a simulated network interruption between the BMS and the room processor, and a conflicting command sent from the room's own keypad or guest-room interface at the same time as a BMS write. The goal of that third test is to confirm which system wins, and that the result is never an unusable room (locked-out thermostat, lights stuck off, HVAC that won't respond to the guest). The priority and failsafe settings available on Crestron's BACnet thermostat configuration give the commissioning team the tools to define that behavior explicitly rather than leaving it to firmware defaults. Discontinued protocol-translator hardware, such as Crestron's older GLA-BMS gateway (now listed as discontinued, with Crestron directing customers to a 3-Series or newer BACnet/IP-native replacement), is a reminder that any BMS interface spec written years ago should be re-verified against current processor generations rather than assumed to still apply.
A hotel considering this integration for a new build or a system upgrade should bring the lighting/control integrator, the BMS programmer, and the mechanical contractor into the same room before the point list is finalized, and confirm in writing who owns each acceptance test. Cave Group designs guest-room automation on Crestron and coordinates PMS, networking, and platform integration as part of its hospitality work, with BMS point-ownership and commissioning exactly the kind of scope question that should be resolved at design stage rather than at punch list.
Frequently asked questions
What is a BBMD and why does a hotel need one?
A BACnet Broadcast Management Device forwards BACnet/IP broadcast traffic across subnet boundaries. If the BMS and the guest-room or lighting processors sit on separate VLANs or subnets — which is typical in a segmented hotel network — a BBMD or foreign-device registration is needed for the two systems to discover each other's devices.
Does the BMS or the room-control system make the final decision on a setpoint?
The room-control processor should make the final decision, using its own priority configuration. Crestron's BACnet thermostat settings document a configurable priority level per object and a default "Parent Priority" behavior, so the room processor's own logic — not an arbitrary external write — resolves conflicting commands.
What happens to a guest room if the BACnet link to the BMS drops?
The room should fall back to a locally defined safe state rather than freezing in its last commanded state. Crestron's thermostat documentation includes a "System Failsafe Temperature" specifically for operation when there is no connection to a control system, and that same fallback principle should extend to any other point the BMS can write.
How many BACnet points can a Crestron processor handle?
Crestron 4-Series processors ship with a free license supporting up to 50 BACnet objects, with a paid license required for more; a processor dedicated entirely to BACnet use can support up to 1,000 objects. The actual point list should be sized to what's genuinely needed, not expanded to use available capacity.
Who should own the BACnet point list — the integrator or the BMS contractor?
Neither party alone; the point list should be agreed jointly by the lighting/AV integrator, the BMS programmer, and the mechanical contractor during design, with each point's owning system and failsafe behavior documented before commissioning begins.