IoT Platforms & Integration

Strip away the marketing and a building IoT platform earns its keep on four jobs.

Device management - keeping track of every connected thing. Registering devices, knowing which are online, pushing configuration and firmware updates, managing credentials and security, and flagging when a sensor goes silent. With hundreds or thousands of devices, doing this by hand is impossible; the platform is the registry and remote control for the whole fleet.

Data collection - the ingestion we met in Lesson 4.1, industrialised. The platform connects to each source over its native protocol (BACnet, Modbus, KNX, MQTT, LoRaWAN), pulls the readings in reliably, and lands them in storage. Good platforms buffer, retry and monitor these connections so a flaky link does not silently lose data.

Data normalisation and storage - turning a babel of vendor formats into one consistent shape, with common units, timestamps and identifiers, then persisting it (typically in a time-series store). This is where raw feeds become a coherent dataset.

APIs and application enablement - exposing all of that through clean, documented interfaces so other software - a twin, analytics, dashboards, a mobile app - can read data and sometimes send commands, without needing to know anything about the messy devices underneath. A platform that collects beautifully but exposes nothing is a dead end; the API is how value gets out.

Do these four well and you have a foundation. Do them badly and every application above inherits the mess.

A helpful way to picture the platform is as a universal translator sitting in the middle of the building. On one side it speaks the many dialects of the field - BACnet to the chillers, Modbus to the meters, KNX to the lights, MQTT to the wireless sensors - and on the other side it speaks one clean, consistent language to every application that wants building data. Everything messy and vendor-specific stays below the translator; everything above it enjoys a single, tidy view. That separation is the platform's quiet genius: it means a new analytics tool or a digital twin can be added without touching a single field device, and a field device can be swapped without rewriting the twin. The platform absorbs the churn so the applications above it do not have to.

The genuinely difficult part - and where most of the money and pain live - is integration: making all those vendor systems actually work together through the platform. This is hard for reasons that are structural, not incidental.

Different systems speak different protocols (Module 2's whole subject) - a lighting system on KNX, HVAC on BACnet, meters on Modbus, sensors on MQTT - so the platform needs drivers or gateways for each. They use different data models and naming - the same idea labelled a dozen different ways across vendors, which is exactly the problem Lesson 4.4 solves with Brick and Haystack. They have different capabilities - some offer open APIs, others are closed boxes you can barely read from. And they come from vendors with no incentive to interoperate, sometimes actively preferring lock-in.

This is why a specialist role has emerged: the master systems integrator (MSI), whose entire job is making the building's many systems speak as one and sit under a coherent data layer. It is skilled, unglamorous work, and it is where smart-building projects most often succeed or fail. A useful principle many owners now insist on is an independent data layer - a platform not owned by any one equipment vendor - so the building's data belongs to the owner and stays open to whatever twin or tool comes next, rather than being held hostage inside one supplier's ecosystem. Integration is not a detail on top of the platform; integration is the platform's reason to exist.

Every serious project reaches the same fork: assemble a platform yourself from open parts, or buy a commercial one - and it is better understood as a spectrum than a binary.

At the buy end sit commercial smart-building and IoT platforms - established software you configure rather than write. You get proven features, support, security patches and speed to value; you give up some control and take on subscription cost and the risk of vendor lock-in if the data and APIs are not open. At the build end you assemble a platform from open-source and cloud building blocks - a message broker, a time-series database, connectors, your own glue code. You get full control and no licence fees, but you own the complexity, the maintenance and the risk forever, and you need the team to do it.

Most real buildings land in the middle: buy a platform and integrate it, or assemble mostly-open components with some bought pieces. The decision hinges on honest questions - do we have the in-house skills to run bespoke software for a decade? How unusual are our needs? How much does independence from any one vendor matter? - not on which demo looked slickest. The single most important thing to protect, wherever you land, is your data and your exit: insist on open protocols in, standard formats at rest, documented APIs out, and the contractual right to take your data with you. Features you can add later; trapped data you may never escape.

'Platform' is one of the most abused words in proptech, so a clear-eyed reading matters. Plenty of products called platforms are really a single vendor's closed system with a dashboard bolted on - fine for that vendor's kit, useless the moment you add someone else's. The test is not the brochure; it is the integration and the openness.

Ask concrete questions. What can it actually integrate? How many protocols and systems, and how much custom work per new one? Who owns the data? Can you export everything in an open format and leave, or is it locked in a proprietary store? What are the real APIs? Are they documented, open and capable of both reading data and issuing commands, or is 'API' a marketing word for a login screen? Does it carry meaning? A platform that stores AHU1_SAT as an opaque string has punted the hard problem to you; one that supports a semantic model (Lesson 4.4) has actually solved something.

Be realistic about effort, too. Integration is labour, not magic - connecting a new legacy system is real engineering every time, and vendors routinely under-state it. And treat the platform as the security and privacy chokepoint it is: it now holds credentials to the building's controls and potentially sensitive occupancy data, an operational-technology asset whose protection (Module 8) belongs with qualified professionals. Judged this way - integration, openness, meaning, honest effort, security - you can tell a real platform from a pretty silo, which is the whole skill.

One more habit separates the experienced from the dazzled: watching the total cost over time, not the sticker price. A platform is a decade-long relationship, and the expensive parts are rarely the licence - they are the integration labour, the ongoing maintenance, the price of adding each new system, and the sometimes brutal cost of leaving if the data is locked in. A cheap platform that traps your data can be the most expensive decision in the building; a pricier one that keeps your data open and portable can be the cheapest. So the seasoned question is never just 'what does it do today?' but 'what will it cost to live with, extend, and eventually escape?' Answer that honestly and you are reading the platform the way an owner should, rather than the way a demo invites you to.