Before getting into mechanics, it is worth being clear that “occupancy integrated with BACnet” describes at least three quite different arrangements. They are not equivalent, and a proposal will rarely tell you which one is on offer.

1. The sensor is a point on a controller

The traditional approach, and still the most common in lighting control. A PIR or ultrasonic sensor is wired into a field controller, and the controller exposes it to the BMS as a BACnet point.

This works well for what it is. It is also limited to binary occupied or not occupied for the area that one device covers. There is no headcount, no space-level aggregation, and no concept of a room being at 30 percent capacity. For lighting and simple setback it is sufficient. For demand-controlled ventilation it is not.

2. Cloud API plus a middleware layer

The occupancy platform exposes a REST API. Something else polls that API and writes the values into BACnet objects the BMS can read.

That “something else” is usually one of three things: a supervisory platform already installed in the building, such as a Niagara-based station used for protocol normalization, a bespoke integration built by the systems integrator, or a general-purpose IoT middleware product.

This is a legitimate approach and a great deal of it exists in the field. Two caveats matter before choosing it.

The first is latency, which compounds in a way that is easy to underestimate. Data goes from the building to the cloud, gets processed, and comes back down before the BMS sees it. On top of that round trip sits whatever polling interval the middleware runs on, and those intervals are often measured in minutes because the layer was designed for dashboards rather than control loops.

The second is what happens during an outage. If the internet connection drops, the API is unreachable and the BACnet values go stale. The BMS falls back to a fixed schedule, which is exactly the behavior occupancy-driven control was installed to replace.

Worth noting too that this arrangement puts four parties on one data path: sensor vendor, middleware provider, systems integrator and BMS contractor. When occupancy stops updating in the BMS, the diagnostic conversation crosses all four of them.

3. An on-premise occupancy gateway

This is the newest of the three, and it is still emerging. Vendors describe it inconsistently: gateway, appliance, edge server, on-premise server, local processor. The underlying idea is the same.

A dedicated device is installed inside the building, usually rack-mounted in a comms room. It does three things:

1.  Receives sensor data locally. Sensors report to it over the building’s own network rather than to a cloud endpoint.

2.  Resolves that data into space-level occupancy. Raw sensor output becomes an occupancy status, a headcount and a percentage against capacity, per space.

3.  Publishes the result in building protocols. It presents itself to the BMS as a native BACnet device, and typically also publishes UDMI over a local MQTT broker.

Because all three steps happen inside the building, the control path never leaves it. There is no API to poll, nothing to license in between, and the BMS reads a value that was calculated a few meters away rather than in a data center.

How it resembles a conventional protocol gateway. In BACnet terms it behaves like any other gateway on the network. It is mains-powered, sits in a comms room, has no user interface, and appears as a BACnet device that the BMS discovers with WhoIs and IAm, enumerates, reads and subscribes to. Nothing about the integration itself is unfamiliar to a controls contractor, which is largely the point.

How it differs, and why it is not just a rebadged protocol converter. A conventional gateway does stateless point mapping. Modbus register 40001 becomes Analog Input 1. One input, one output, a fixed relationship configured at commissioning and left alone.

An occupancy gateway does resolution rather than mapping, and there is no one-to-one relationship between a sensor and a BACnet object. A single space is often covered by several sensors, coverage overlaps deliberately, and the same person can be seen by more than one sensor at once. Producing one trustworthy headcount means stitching those views together and deduplicating in real time. That is a computational job, not a lookup table.

It also holds a model of the building: which sensors cover which space, how spaces are grouped, what each space’s capacity is. That model changes whenever the floorplan does, so it has to be maintained rather than flashed once. In practice that means these devices are usually cloud-managed and vendor-maintained, which is a different operational model from a gateway an integrator commissions and hands over. It is also why several vendors call it an appliance rather than a gateway: the word signals managed hardware rather than a box you configure yourself.

For the rest of this guide we will call it an on-premise occupancy gateway. It is the arrangement that gives a BMS the real-time, space-level occupancy signal that demand-controlled ventilation and occupancy-driven HVAC sequencing actually require, so it is the one worth understanding in detail.