It's tempting to think of commercial building automation systems (BAS) as smart home products scaled up — more sensors, more zones, a bigger app. That framing misses what actually makes commercial BAS a different engineering discipline: the systems it controls (HVAC, life-safety, lighting at facility scale) can't simply be restarted or left in an undefined state, the protocols already running in the building predate consumer IoT by decades, and the people deploying and operating the system are facilities professionals working within an existing building, not consumers setting up a new device at home.
Legacy protocol integration is not optional
Commercial buildings run on protocols like BACnet and Modbus that have been the standard for HVAC, lighting, and building controls integration for a long time, and that installed base isn't going away — a new BAS platform that can't speak to existing BACnet controllers, Modbus-connected equipment, and other legacy building systems simply won't be adoptable in most real commercial buildings, because ripping out and replacing all existing controls hardware is rarely in budget or scope. That means BACnet/Modbus integration isn't a nice-to-have add-on, it's core platform capability that has to be designed in from the start, including handling the quirks and inconsistencies that show up across different vendors' implementations of those standards in the field.
Uptime and safety requirements that don't tolerate "just restart it"
A consumer smart home hub that hangs and needs a reboot is an inconvenience. A building automation controller that hangs can mean HVAC stops responding correctly, or a life-safety-adjacent system (fire dampers, smoke control sequences that interface with the BAS) doesn't behave as designed — the failure modes carry real consequences at building scale, not just user annoyance. That reality pushes BAS design toward patterns that are less common in consumer products: watchdog supervision that can recover a hung controller without human intervention, fail-safe defaults so that a controller losing communication with the rest of the system falls back to a safe, defined state rather than an undefined one, and update processes that don't force downtime on critical building functions to apply a firmware patch.
Retrofit reality: existing buildings, existing infrastructure, facilities teams
Unlike a smart home device a consumer buys and installs themselves, a commercial BAS deployment usually means retrofitting sensors and controllers into a building that's already standing, with existing wiring, existing controls infrastructure, and an existing facilities team that has to operate the system day to day once it's installed. That changes several design priorities: installation needs to work within real building constraints (existing conduit runs, panel space, network infrastructure that may or may not support what the new system needs), and the operator-facing interface needs to be built for facilities staff who are managing dozens of buildings and systems, not a single homeowner optimizing one house. Deployment planning — coordinating with a facilities team's schedule, minimizing disruption to an occupied building — is as much a part of a successful commercial BAS rollout as the technology itself.
Practical takeaway
Commercial building automation succeeds or fails on the unglamorous parts — legacy protocol compatibility, fail-safe behavior under fault conditions, and a deployment plan that respects how an occupied building actually operates. See our embedded hardware and cloud & device platform work for how we approach BAS-class systems.