Why "analog" doesn't mean a dial and "binary" doesn't mean a switch — the real distinction is how many possible values the point can report, and what a controller can do with the number it gets back.
Every point in a building automation system database is one of four kinds: analog input (AI), analog output (AO), binary input (BI), or binary output (BO). New BAS technicians often sort these by what the device physically looks like — a sensor feels "analog," a relay feels "binary" — but the actual test has nothing to do with the hardware's appearance. It's about the range of the signal the point carries. An analog point represents a continuously variable quantity across a range; a binary point represents one of exactly two discrete states. Confuse the two in a points list, a controller program, or a graphic, and you get a supply-air-temperature reading that can only ever say "hot" or "cold," or a damper command that tries to sit at 47% open on an output that physically can only be full-open or full-closed.
Room temperature, duct static pressure, VAV damper position, and chilled-water valve command are all physically continuous quantities — they can sit at any value across a range, so they belong on AI/AO points. Fan run status, filter-differential-pressure alarm, occupancy override, and damper end-of-travel limit switches are all genuinely two-state conditions — they belong on BI/BO points. Point-type selection is an engineering decision made at the points-list stage, and it constrains everything downstream: a value that's wired as binary can never later be read as a graded percentage without re-wiring, and a value wired as analog wastes controller I/O and confuses graphics if the real signal only ever has two meaningful states. Getting this right on the points list (often called a points schedule or I/O schedule) is one of the first and most consequential decisions in a BAS design.
The wiring convention (0–10 VDC, 4–20 mA, 1k/10k thermistor for analog; dry contact or 24 VAC for binary) is a consequence of the distinction, not the definition of it. The actual definition is about the point's data type in the controller database: how many discrete states can it hold? A 0–10 VDC output driving a two-position (open/closed only) damper actuator is still functionally binary from a control standpoint even though the wiring looks analog — the controller might command 0 V or 10 V and nothing between, because the actuator itself has no intermediate position. Conversely, some binary-looking hardware (a variable-speed drive's run contact plus a separate speed reference) actually pairs a binary point (run/stop) with an analog point (speed %) working together. The question to always ask is: how many values can this specific point meaningfully take on, not what the terminal block looks like.
Explains the real distinction between analog (AI/AO) and binary (BI/BO) points in a building automation system — not the wiring type, but how many discrete values the point can hold — using a side-by-side comparison of a supply-air temperature sensor (analog) and a fan proof-of-flow switch (binary).
New BAS technicians and even some junior controls engineers sort points by what the field device looks like: a sensor with a wire "feels" analog, a switch or contact "feels" binary. That intuition breaks down as soon as you meet a two-position damper actuator driven by a 0–10 VDC signal (analog wiring, binary behavior) or a VFD that pairs a binary run/stop contact with a separate analog speed reference. The correct test is always about the point's data type — how many states can it represent — not the terminal block it lands on.
A BAS controller database organizes every physical or virtual signal into one of four categories. Analog Input (AI): a continuously variable field measurement coming into the controller — space temperature, duct static pressure, CO2 ppm, humidity %RH. Analog Output (AO): a continuously variable command going out to a field device — a valve or damper actuator position (0–100%), a VFD speed reference. Binary Input (BI): a two-state field condition coming in — fan status, filter alarm, door contact, freezestat trip. Binary Output (BO): a two-state command going out — fan start/stop, pump enable, lockout relay.
Many BAS platforms add a fifth logical category, "multistate," for points with a small fixed number of named states greater than two (e.g., a 3-speed fan: OFF/LOW/HIGH), but the fundamental AI/AO/BI/BO split is universal across BACnet, LonWorks, and proprietary DDC systems alike.
Getting point type right at the points-list (I/O schedule) stage during design is far cheaper than fixing it in the field. Under-sizing a variable quantity onto a binary point loses control resolution — a VAV box commanded by a single binary damper output can only be full-open or full-closed, producing overshoot and poor comfort compared to a modulating AO output that can hold 34% open. Over-sizing a genuinely two-state condition onto an analog point wastes controller I/O capacity and adds noise to graphics and trend logs — a proof-of-flow switch reported as "87.3%" instead of a clean ON/OFF is harder to alarm on and confuses operators. Point type also determines what control strategies are even possible: true PID modulation absolutely requires an analog PV and analog output; anything running on binary I/O is necessarily limited to on/off, two-position, or time-proportioning (fast-cycling on/off) control.
Only in a crude, non-modulating way — a binary output can drive a floating-point (tri-state) actuator by pulsing "open" and "close" contacts for timed durations, which approximates modulation through timing rather than a true analog signal. This is common on older or lower-cost DDC systems and is distinct from a true AO, which sends a continuous 0–10 VDC or 4–20 mA signal directly proportional to desired position.
Many modern BACnet controllers support a Multistate Value/Input/Output object type — a point with a small fixed number of named states (e.g., 1=Off, 2=Low, 3=Medium, 4=High) that is neither purely binary (only 2 states) nor truly analog (infinite resolution). It is the correct object type for something like a 3-speed fan or an occupancy mode selector (Occupied/Unoccupied/Standby/Bypass).
The underlying concept is universal, but the object model differs. BACnet defines standard object types Analog Input/Output/Value and Binary Input/Output/Value with standardized properties (Present_Value, Units, etc.), which is a major reason BACnet became the dominant open BAS protocol — any BACnet-compliant workstation can read any vendor's AI/BI objects without custom translation. LonWorks instead uses Standard Network Variable Types (SNVTs) that serve a similar purpose but with different naming and property structures. Proprietary DDC systems predate both and often use vendor-specific internal representations, which is exactly the interoperability problem BACnet and LonWorks were created to solve.
The points list (I/O schedule) is the master document that assigns every physical field device to a specific point type, controller, and I/O terminal before installation. Errors here — wiring a variable-position damper as binary, for instance — often aren't discovered until commissioning, when correcting them means re-terminating wiring, changing controller point configuration, and sometimes swapping the physical actuator, all far more expensive than catching the mismatch on paper during design review.
Try our Smart Buildings Studio
More calculators, simulators, and guides for this discipline.
Building Management System Use Case (Full Access)
✨ Premium ContentA zoomable interactive reader — free preview, then unlock the full set.