When most people hear "IoT" they think of smart speakers, connected thermostats and app-controlled lightbulbs. Commercial building IoT is an entirely different discipline. The devices used in offices, logistics hubs and multi-tenant developments across London and the South East are industrial-grade, designed for 24/7 unattended operation, and expected to deliver reliable data streams over years rather than months. They communicate over IP networks, expose REST or MQTT APIs, and in many cases feed cloud-hosted analytics platforms operated by the device manufacturer.
At Alpha Controls we work with both traditional Building Management Systems and this newer generation of IP-connected field devices. Understanding how the two worlds differ — and where they genuinely complement each other — is the starting point for any successful integration project.
A conventional BMS is built around hardwired field devices: room temperature sensors, VAV actuators, chiller controllers and the like. These devices speak BACnet or Modbus over twisted-pair cabling, report to a local controller, and the controller reports to a supervisor such as Trend IQVISION or Niagara N4. The chain is deterministic, low-latency and entirely on-premises. If the internet goes down, the building still runs.
IoT sensors operate differently. A typical commercial IoT device — say a desk-level air quality monitor or a wireless occupancy puck — connects to the building Wi-Fi or a private LoRaWAN gateway, authenticates against a cloud platform, and pushes readings to a vendor-hosted API endpoint. Dashboards, alerts and analytics all live in the cloud. This approach is fast to deploy and produces rich, easily consumed data, but it introduces dependencies on internet connectivity and third-party cloud services that a BMS engineer has no control over.
Neither model is universally superior. The practical question is always: which devices are best suited to each use case, and how do we bring the data together into a coherent picture?
Traditional BMS occupancy comes from PIR sensors covering a zone — enough to trigger a lighting scene or set back HVAC in an empty room, but not granular enough to tell a facilities manager how many desks in an open-plan floor are actually used on a Tuesday. IoT platforms such as LightFi deploy small under-desk or ceiling-mounted sensors that report individual workpoint utilisation every few minutes. That data feeds workplace analytics — useful for hybrid working policies, cleaning rosters and real estate consolidation decisions — and can simultaneously inform the BMS about zone-level occupancy with far greater accuracy than a single PIR would provide.
Half-hourly AMR meters have been a staple of energy management for years, but modern IP-connected meters push readings every few minutes to cloud platforms that automatically flag anomalies, compare consumption against degree-day data and generate the reports landlords need for MEES compliance and EPCs. Integrating that metered data back into the BMS supervisor gives operators a single-screen view of energy versus plant status — very useful for fault detection.
Post-2020 there has been strong demand for real-time indoor air quality visibility, particularly CO2, PM2.5 and TVOC levels. IoT air quality devices can feed both a tenant-facing web dashboard — a genuine amenity in a let building — and the BMS, so that elevated CO2 in a meeting room automatically triggers an increase in fresh air supply via the AHU, rather than relying on a timed schedule.
EV charger networks are inherently IoT: each charge point communicates with an OCPP cloud back-end that handles session authentication, billing and load management. Integrating charge point power demand into the BMS allows dynamic load-shedding — if site demand is approaching the agreed capacity, the BMS can signal the charge network to throttle sessions rather than trip the main incomer. This is one area where a genuine control integration, not just monitoring, is often justified.
Inverter manufacturers including SolarEdge, SMA and Fronius all publish cloud APIs. Pulling generation and battery state-of-charge data into the BMS supervisor enables smarter plant sequencing — running the chiller during periods of high solar export rather than drawing from the grid, for instance.
The IoT platform exposes a REST API; the BMS supervisor polls it on a schedule and maps returned values to virtual BACnet objects or driver points. A practical example is LightFi occupancy counts pulled every five minutes into Trend IQVISION via a REST driver, where they appear as standard BACnet analogue values that schedules and logic modules can act on. This approach requires no changes to the site network and works well where the IoT platform is the authoritative source and the BMS just needs to consume summary data. The limitation is latency — you are at the mercy of both the IoT cloud and the internet connection — so it is not suitable for anything that needs sub-minute response.
An IoT gateway — a small Linux device on-site — subscribes to device data locally and republishes it to a BACnet/IP virtual device or an MQTT broker that the BMS supervisor reads directly. This keeps data on the local network, reduces latency, and removes the dependency on external cloud services. It is particularly useful where the customer has concerns about data leaving the building, or where the site internet connection is unreliable. The trade-off is that the gateway is another device to manage, patch and monitor.
Some manufacturers — particularly in the metering and HVAC sensor space — ship devices that support both cloud connectivity and a local Modbus RTU or BACnet/IP interface simultaneously. This is the cleanest integration path for control applications: the BMS treats the device exactly like any other field device, with no gateway, no cloud dependency and full read/write capability. Where it is available, choosing the right protocol matters — BACnet/IP is preferable on Ethernet for its native BMS compatibility; Modbus RTU suits daisy-chained meter panels where RS-485 cabling is already in place.
MQTT is a lightweight publish-subscribe messaging protocol originally developed for low-bandwidth machine-to-machine communication. It has become the de facto standard for IoT device communication — most commercial IoT gateways and many devices support it natively. In a building context, an MQTT broker acts as the hub: devices publish readings to topic strings, and any subscriber — including the BMS supervisor — receives those readings in near real-time.
Niagara N4 supports MQTT natively through its MQTT driver module, which means a Niagara-based BMS can subscribe directly to an on-site MQTT broker and present IoT device data as standard Niagara points — no custom middleware required. This has significantly lowered the integration effort for IoT projects on Niagara platforms, and it is an approach we use regularly on projects across London and Kent.
This is the area that most IoT product brochures gloss over. IoT devices are among the most commonly exploited entry points into building and corporate networks. Many ship with default credentials, receive infrequent firmware updates, and run lightweight operating systems with limited security hardening. Connecting them directly to the same network segment as BMS controllers or the corporate LAN is a significant risk.
Alpha Controls recommends a structured approach to IoT network security, consistent with our network design practice:
The formal standards landscape for IoT device security is catching up with the risk. ETSI EN 303 645 — the European standard for cyber security in consumer IoT, increasingly referenced in commercial specifications — establishes baseline requirements including no default passwords, a vulnerability disclosure policy, and secure update mechanisms. The UK Product Security and Telecommunications Infrastructure Act 2022 (PSTI) enshrines similar requirements in law for consumer devices and is shaping procurement expectations in the commercial sector. For building owners in regulated industries, the NCSC's Cyber Assessment Framework (CAF) and the IEC 62443 operational technology security standard both provide structured approaches to managing risk across building automation networks. If your specification requires Cyber Essentials certification, note that any IoT device connected to your network must be within scope — which has direct implications for VLAN design and update policy.
IoT sensors are well suited to monitoring and analytics workloads where the consequence of a missed or delayed reading is a slightly incomplete dataset. They are not well suited to hardwired control loops where a missed signal could mean an AHU running at full speed overnight or a frost protection circuit failing to respond. Do not replace hardwired BMS sensors on critical control circuits with wireless IoT alternatives purely to save cabling cost — the reliability profile is simply not equivalent.
The pattern that works well in practice is a layered one: traditional hardwired BMS field devices handle control, with IoT sensors layered on top to enrich the monitoring picture, feed analytics platforms and provide the granular data that occupants and building owners increasingly expect. Getting that layering right — technically and commercially — is where experience matters.
Alpha Controls is a BMS specialist based in Gravesend, Kent, serving commercial buildings across London and the South East. We design, install and maintain BMS systems and have hands-on experience integrating IoT platforms — occupancy networks, smart metering, EV charge management and more — with Trend, Niagara and other supervisory platforms. Our networking team handles the underlying IP infrastructure and VLAN architecture that makes these integrations secure and reliable.
If you are planning an IoT integration, considering a BMS upgrade, or want independent advice on the right approach for your building, get in touch with our team. We are happy to discuss your requirements without obligation.
Our team of building automation specialists is ready to help you optimise your building's performance and efficiency.
Get in Touch
