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.
Analog input: supply-air temperature sensor
Continuous Range
Possible values
Any real number in range
54.2°F, 54.3°F, 68.97°F — resolution is limited only by the A/D converter and sensor accuracy.
What PID control needs
Exactly this
A PID loop needs a graded error signal (setpoint − PV) to compute a proportional response — impossible with only two states.
Binary input: fan proof-of-flow (status) switch
Two States Only
Possible values
0 or 1 — nothing else
Open/closed, on/off, run/stop, normal/alarm — always exactly two named states.
What it's good for
Status & on/off commands
Fan start/stop, damper end-switch, alarm contact — anything that is genuinely one of two conditions.
Why this works
The signal type is chosen by what the real-world quantity actually is — not the other way around.
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.
Common misconception
"Analog means the wiring uses a variable voltage, and binary means a relay contact — it's about the wire type."
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.
Analog Points vs Binary Points in a BAS — Concept Explainer
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).
Why This Is Commonly Confused
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.
The Four Point Types
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.
Where This Matters in Practice
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.
Frequently asked questions
Can a binary point ever drive a modulating actuator?
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.
What is a "multistate" or "multi-state value" point?
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).
Does BACnet define analog and binary points differently than LonWorks or proprietary DDC?
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.
Why does the points list matter so much during design?
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.