The sensors are the easy part. They are cheap, they install quickly, and the pilot usually works.

What comes next is where projects stall. The sensor produces a reading. Something has to decide the reading matters, decide which physical asset it refers to, decide who should act, and put that in front of a person who can do something about it. Every one of those steps is an integration problem, and none of them appears on the quote.

This is an honest assessment of where smart building integration currently delivers, where it consistently disappoints, and what to require before signing anything. For the groundwork on what these systems are, see RIOO explainers on IoT in facility management and smart building technology. This article assumes you already know what a sensor does and asks what happens after it fires.

Key takeaways

• Protocol incompatibility is the visible problem and usually the more tractable one. Data model inconsistency is the expensive one.

• A sensor alert that does not create a work order changes nothing about how the building is run.

• Unfiltered sensor data makes maintenance teams slower, not faster.

• Device lifecycle, batteries, firmware, and vendor obsolescence are rarely budgeted and always arrive.

• Pilots succeed because someone is watching. Rollouts stall because nobody is.

In this guide

• What is smart building integration?

• Where the pitch and the delivery diverge

• The protocol problem, and why it is usually the easier one

• The data model problem, and why it is not

• The trigger question: does an alert become a work order?

• When more data makes the team slower

• The lifecycle nobody budgets for

• Why pilots succeed and rollouts stall

• What to require before you sign

• Where this genuinely pays off today

• Frequently asked questions

What is smart building integration?

Short answer: Smart building integration is the work of connecting building systems and sensors so that data from one produces action in another. It covers protocol translation between devices that speak different languages, a shared data model so every system means the same thing by the same asset, and workflow connection so a reading becomes a task somebody owns. Buying sensors is procurement. Integration is the part that determines whether they change anything.

The distinction matters because vendors sell the first and quietly assume the second and third.

Where the pitch and the delivery diverge

None of this means the technology does not work. It means the technology is the smaller half of the project.

The protocol problem, and why it is usually the easier one

Buildings speak several languages at once. Trade reporting on the interoperability question notes that traditional BMS protocols such as BACnet and KNX often clash with modern IoT standards like MQTT and REST APIs, creating gaps that have to be bridged rather than assumed away. HVAC might run on BACnet, lighting on a different standard, and a new sensor fleet on MQTT.

The good news is that protocol translation is generally more tractable than the semantic problem that follows it, though tractable does not mean cheap in every project. Protocol gateways and multi-protocol edge devices have become substantially cheaper and more capable, supporting many protocols with limited configuration. One common approach is to use BACnet/IP as a backbone for building operations while allowing IoT devices to connect natively via MQTT or APIs, which reduces translation complexity rather than adding another layer of it. It suits many buildings rather than all of them.

Treat protocol compatibility as a procurement item with a knowable cost. In most projects it is among the more predictable parts.

The data model problem, and why it is not

This is the one that quietly wrecks projects, and it is not a technology problem at all.

The symptom is specific: two platforms report different values for the same asset or the same space. An energy dashboard shows occupancy that does not match the building automation system. Both are working correctly. They simply disagree about what the space is.

The same trade analysis identifies the cause plainly. Systems can exchange data successfully while interpreting equipment, sensors, and locations differently, and as deployments expand, inconsistent naming conventions and missing metadata become major obstacles. Open data models such as Project Haystack and Brick Schema exist to normalise this, which tells you the industry considers it serious enough to standardise.

For a property team the practical version is simpler. Every sensor needs to attach to a named asset in a register, at a location expressed in the naming convention your team actually uses. If "AHU-3" in the BMS is "Air Handler 3, Level 4 Plant" in your asset register and "L4-AHU-03" in the sensor platform, no amount of integration middleware will produce a coherent answer.

This is the same naming discipline that governs a clean maintenance and work order record, and it is why teams with a tidy asset register integrate quickly while teams without one spend the budget on reconciliation.

The trigger question: does an alert become a work order?

Ask any smart building vendor this and listen carefully to the answer.

A temperature sensor reports a value outside its band. Four things can happen:

Only the last one changes how the building runs. The first three are visibility, which is worth something but is not the business case that was sold.

Getting to the fourth requires decisions nobody enjoys making: which alert types justify a work order, what threshold, what priority, which team, and what happens when it fires at 3am on a Sunday. Those decisions are yours to make, not the vendor's, and they need making before go-live rather than after the first alert storm. The service request and task workflow on the receiving end has to be able to accept a system-generated ticket and route it like any other.

When more data makes the team slower

A well-observed point in current smart building commentary is that buildings deploying sensors without clear standards end up overwhelmed by noise rather than insight.

The mechanism is familiar to anyone who has run a monitored system. A sensor fleet produces thousands of readings a day. Without filtering, a meaningful proportion cross a threshold at some point. Each one competes for attention. Within weeks the team learns that most alerts are not worth acting on, and shortly after that they stop reading any of them, including the one that mattered.

Three defences, in order of importance:

Set thresholds against observed behaviour, not manufacturer defaults. A default alarm band tuned for a laboratory will fire constantly in a plant room.

Require persistence before alerting. A reading outside band for ninety seconds is noise. Outside band for forty minutes is a condition.

Escalate rather than broadcast. One recipient, with a defined escalation path if unacknowledged, beats a distribution list that everyone assumes someone else is reading.

The lifecycle nobody budgets for

The most useful realism check on smart buildings comes from a UCL research paper reviewing two decades of operating a real building automation deployment. It concludes that operating an intelligent building automation system today still runs into hardware failures, vendor obsolescence, and evolving security threats, and that these have not been comprehensively addressed by either the industrial or the home automation industries, which limits how feasible large truly smart deployments are to run. The paper describes the fragmented device ecosystem as imposing a significant ongoing maintenance burden, requiring manual management of device failures, software updates, and connectivity disruptions.

Translated into a budget line, that means:

Model these at portfolio scale before the pilot, not after it. A fleet of two thousand battery devices is a recurring maintenance programme, not a purchase.

Why pilots succeed and rollouts stall

Pilots succeed for a reason that does not scale: someone is watching.

During a pilot there is a project owner, a vendor engineer on call, a small device count, and enough attention that anomalies get investigated the day they appear. Every one of those conditions disappears at rollout. The project owner moves on, the vendor moves to implementation support, device count multiplies, and the anomalies land on a team that has a day job.

The pilots that do scale share three traits:

• The workflow was built before the hardware. Alert types, thresholds, routing, and ownership were decided during the pilot, not deferred to it.

• The asset register was clean first. Sensors attached to existing named assets rather than creating a parallel inventory.

• Someone owns the system after go-live. Not the vendor. A named internal role responsible for device health, threshold tuning, and the alert-to-work-order rules.

If a pilot proposal does not address those three, it is a demonstration rather than a trial.

What to require before you sign

1. Documented protocol support, naming the specific standards and versions, not a claim of universal compatibility.

2. Data exportability in writing. You can extract your historical data in a usable format, at any time, without a fee.

3. Open API access with object mapping, covering the systems you will need to connect, with documentation available before purchase rather than after. API availability alone is not sufficient. You need documented objects and the specific use cases you intend to support.

4. A point-mapping deliverable, showing each sensor mapped to a named asset and location in your convention.

5. The alert-to-action design as a project deliverable, including thresholds, priorities, and routing rules.

6. A lifecycle cost model at full portfolio scale covering batteries, replacement rate, patching, and recommissioning.

7. An exit path. What happens to the hardware, the data, and the integrations if you leave the platform.

The last one is the question vendors least expect and answer most revealingly.

Where this genuinely pays off today

An honest scorecard, based on where the operational case is strongest rather than where the marketing is loudest.

The pattern is consistent. Narrow applications with unambiguous alerts and obvious actions work now. Broad applications promising insight rather than action are where budgets disappear.

Frequently asked questions

1. What is smart building integration?
The work of connecting building systems and sensors so data from one produces action in another. It covers protocol translation between devices using different standards, a shared data model so systems agree on what each asset and location is, and workflow connection so a reading becomes a task somebody owns.

2. Why do smart building projects fail after the pilot?
Because pilots run under conditions that do not scale: a dedicated owner, vendor engineers on call, and few enough devices that anomalies get investigated. At rollout those conditions disappear and the alert volume multiplies, so the system stops being read.

3. What is the difference between a protocol problem and a data model problem?
A protocol problem is systems not being able to exchange data, generally addressed with gateways at a knowable cost. A data model problem is systems exchanging data successfully but interpreting equipment, sensors, and locations differently, so the same asset appears under different names with different values.

4. What are Project Haystack and Brick Schema?
Open data models that standardise how building equipment, sensors, and spaces are described and tagged, so different systems can interpret the same data consistently. They exist because inconsistent naming and missing metadata are recognised as a major obstacle at scale.

5. Should sensor alerts create work orders automatically?
For a defined subset, yes. An alert that only reaches a dashboard requires someone to be watching it. An alert that creates a work order with a priority, an owner, and an asset reference produces work. Deciding which alert types qualify is the core design decision of the project.

6. What causes alarm fatigue in building systems?
Thresholds set from manufacturer defaults rather than observed behaviour, no persistence requirement so momentary excursions alert, and broadcast distribution so no single person is accountable. The result is that teams stop reading alerts entirely.

7. What ongoing costs do smart building deployments carry?
Battery replacement across the fleet, firmware and security patching, device failure and replacement, network coverage remediation, recommissioning after building works, and eventual platform migration when a vendor discontinues or is acquired.

8. Do I need a clean asset register before deploying sensors?
It is one of the strongest predictors of a smooth integration. Sensors need to attach to named assets at locations expressed in your own naming convention. Teams without a clean register spend a large share of the budget on reconciliation instead of deployment.

9. What should I ask a smart building vendor before buying?
Which specific protocols and versions are supported, whether historical data can be exported in a usable format without fee, whether APIs and their object mappings are documented and available pre-purchase, what the point-mapping deliverable looks like, how alerts convert to action, the full lifecycle cost at portfolio scale, and what happens to hardware and data if you leave.

10. Which smart building applications are most reliable today?
Leak detection in risk areas and utility submetering have the clearest operational case: narrow alerts, obvious actions, and cost impact that is easy to attribute. Plant runtime monitoring and environmental sensing in sensitive spaces work well where the asset register is clean and thresholds are tuned.

11. Is predictive maintenance from IoT sensors realistic yet?
For major plant with long data baselines and consistent quality, it is emerging and useful. For most portfolios it remains oversold relative to the data maturity required. Condition-based alerting on defined thresholds delivers most of the value with far less complexity.

Smart building technology works. The claim that deserves more scrutiny is that installing it is the project.

The sensors will arrive and they will report accurately. Whether that changes anything depends on decisions nobody in the sales process is responsible for making: what each asset is called, which readings deserve attention, who acts, and who owns the fleet in year three. Those decisions are cheap to make early and expensive to retrofit.