Building Automation: HVAC, Lighting, Access Control IoT

Modern commercial buildings run three historically separate control domains — HVAC, lighting, and access control — on overlapping wired and wireless networks that now increasingly converge on IP and IoT protocols. A single 200,000 ft² office tower can host 2,000+ HVAC points, several thousand lighting fixtures with individual dimming/occupancy control, and hundreds of door readers, all reporting telemetry and accepting commands. Understanding how these subsystems are architected — and where they still fail to interoperate — is essential for anyone specifying or integrating building IoT hardware.

The Three Subsystems and Their Native Protocols

Each domain evolved its own fieldbus before IP-based convergence, and legacy installed base means you will encounter all of them.

BACnet (ASHRAE 135) remains the dominant HVAC integration standard; it defines standardized "objects" (Analog Input, Binary Output, Schedule, etc.) so a chiller from one vendor and a VAV box from another expose comparable data structures to a Building Management System (BMS). DALI (Digital Addressable Lighting Interface) does the equivalent for lighting, addressing up to 64 ballasts per bus segment with individual dim-level and status readback. Access control has been slower to standardize — OSDP (Open Supervised Device Protocol) is now displacing the older unidirectional, unencrypted Wiegand interface between readers and controllers, adding AES-128 encryption and bidirectional supervision (tamper/cut-wire detection).

Reference Topology

A typical converged deployment looks like this at the network layer:

[Sensor/Actuator]  --BACnet MS/TP / DALI / OSDP-->  [Field Panel / Controller]
                                                          |
                                                     BACnet/IP, MQTT
                                                          |
                                                    [IP Gateway / Edge Node]
                                                          |
                                                 Wi-Fi / Ethernet / cellular backhaul
                                                          |
                                                     [BMS / Cloud Platform]
                                                          |
                                                 Dashboards, analytics, alarms

The field panel (or DALI gateway, or access control panel) is doing local closed-loop control — a VAV controller runs its own PID loop on damper position regardless of whether the cloud connection is up. The gateway's job is aggregation, protocol translation (BACnet/DALI/OSDP → MQTT/JSON), and providing a single IP uplink instead of hundreds of individually-connected field devices. This is the standard edge-aggregation pattern: control loops stay local for latency and safety; supervisory, analytics, and reporting functions move to cloud.

Worked Example: Occupancy-Driven HVAC + Lighting Coordination

Consider a conference room with a PIR occupancy sensor feeding both the lighting controller and the BMS.

Sequence:

1. PIR sensor (DALI-integrated, polling interval 1 s) detects occupancy → lighting controller ramps fixtures from 0% to 80% over 2 s (dimming curve to avoid flicker perception).
2. Same occupancy event is published via the gateway as an MQTT message: {"room":"3B","occupied":true,"ts":1717000000} on topic bldg/floor3/room3B/occupancy.
3. BMS subscribes to that topic, and on occupied:true changes the room's HVAC setpoint from "unoccupied setback" (e.g., 27°C cooling setback) to "occupied comfort" (22°C) by writing a BACnet Analog Value object on the VAV controller.
4. VAV controller's local PID loop drives the damper/reheat coil to close the gap between measured zone temperature and new setpoint — this loop runs at ~1 Hz locally, independent of network latency.

Why this matters quantitatively: if the MQTT broker or Wi-Fi backhaul has 500 ms–2 s of latency (typical for a lightly loaded on-prem broker), the lighting response (local DALI bus, <100 ms) is unaffected, but the HVAC setpoint change is delayed by that same amount — acceptable, since thermal time constants for a room (minutes) dwarf network latency by 2–3 orders of magnitude. This asymmetry is exactly why HVAC tolerates cloud round-trips that lighting cannot: check the time constant of the physical process against the network latency budget before deciding what must stay local.

Access Control: A Higher-Stakes Latency and Security Case

Access control differs from HVAC/lighting in one critical way: a failed or slow decision has immediate physical/security consequences, so the door decision must never depend on a live cloud round-trip.

• Local decision, cloud sync: the door controller holds a cached credential list and makes the grant/deny decision locally (typically <300 ms end-to-end from badge tap to strike release). Cloud connectivity is used to push credential updates and pull audit logs — not to gate the real-time decision.
• OSDP vs. Wiegand: Wiegand is a simple two-wire, unidirectional, unencrypted signaling scheme — vulnerable to wiretapping/replay and offers no tamper feedback. OSDP adds encryption, bidirectional polling, and supports multi-drop (up to 128 devices per RS-485 bus vs. one reader per Wiegand home-run), reducing cable pulls.
• Fail-safe vs. fail-secure: an electromagnetic lock is typically fail-safe (unlocks on power loss, for egress/fire code compliance); an electric strike on a server room is typically fail-secure (stays locked on power loss). This is a life-safety and code decision (NFPA 101 / local fire code), not just an IoT configuration choice — get it wrong and you either trap occupants or leave a secure space open during a power event.

Interoperability Gaps in Practice

• Protocol translation overhead: every BACnet-to-MQTT or DALI-to-IP gateway is a potential single point of failure and adds a translation layer that must be maintained/patched independently of the field devices behind it.
• Object/point naming inconsistency: BACnet defines the object types but not naming conventions — "AHU-3-SAT" vs. "AirHandler3_SupplyAirTemp" for the same point across two integrators breaks any analytics layer built on point names rather than semantic tagging (this is part of why semantic tagging schemes like Brick Schema exist, though full adoption is still limited).
• Mixed security postures: a building commonly has hardened OSDP access control alongside legacy Wiegand readers still in service, and BACnet/IP traffic with no authentication at all (BACnet Secure Connection / BACnet/SC exists but adoption lags). A converged IP backbone means a weak lighting gateway can become a lateral-movement path into HVAC or access control VLANs if network segmentation isn't enforced.

Key Takeaways

• HVAC, lighting, and access control each have distinct legacy fieldbuses (BACnet, DALI, OSDP/Wiegand) that are converging onto IP/MQTT gateways, not being replaced by them.
• Local control loops stay local: VAV PID control, DALI dimming, and door grant/deny decisions must execute at the field controller regardless of cloud connectivity — the cloud layer handles setpoints, scheduling, analytics, and audit, not real-time actuation.
• Match latency tolerance to physical time constants: HVAC's multi-minute thermal time constants tolerate second-scale network latency; lighting and access control, with human-perceptible or security-critical response requirements, cannot.
• OSDP over Wiegand, and BACnet/SC over plain BACnet/IP, are the security upgrade paths in each domain — expect long tails of legacy unencrypted devices still in the field.
• Network segmentation matters more than protocol choice once everything shares an IP backbone — a compromised lighting gateway shouldn't have a path to the access control VLAN.