Energy and building technology · IoT
Sensor data that was collected and never looked at
A global HVAC manufacturer had more than 100 devices in the field, each with 50 or more sensors, producing a continuous stream of operational data and no automated way to detect an anomaly, classify an operating mode or notice a failing sensor. We built a series of ML pipelines on AWS that replaced manual monitoring.
Key results
Client: Global HVAC manufacturer (under NDA)
One of the world’s leading producers of heating and air conditioning systems, with IoT-enabled device fleets. The manufacturer is under NDA, so it is not named here.
- Industry
- Energy and building technology
- Use case
- Anomaly detection and sensor analytics
- AI approach
- Machine learning with deep neural networks
- Infrastructure
- AWS with Azure IoT Hub
- Data
- Time series, 50 or more sensors per device
- Engagement
- A series of projects
In short
The data was there. The layer that reads it was not.
- Modern HVAC systems carry IoT sensors for temperature, pressure, humidity, airflow and dozens more, and this client had over 100 devices with 50-plus sensors each.
- Maintenance was still reactive. Sensor malfunctions went undetected until they caused a visible problem, and nothing classified how a device was actually being used.
- We built the cloud data architecture first, then layered five use cases on it: sensor reliability, operating mode classification, anomaly detection and environmental impact.
- The client moved from reactive maintenance to catching a malfunction before it becomes a service call.
The starting point
The challenge
The client was sitting on a large volume of IoT sensor data but had none of the data architecture, processing pipelines or models needed to get anything out of it. Everything was manual, or was not happening at all.
Modern HVAC systems are packed with IoT sensors, temperature, pressure, humidity, airflow and dozens more, producing a continuous stream of operational data. This client had over 100 devices in the field, each with 50 or more sensors. The data existed and was largely unused.
Maintenance was reactive. Sensor malfunctions went undetected until they caused a visible problem.
There was no automated way to classify device operating modes, compare sensor reliability across product variants, or tune performance to environmental conditions. The raw data was there; the intelligence layer was missing.
The build
What we built
This was not one project but a series, each targeting a specific use case. Together they turned the sensor data from a passive byproduct into something the business uses.
The data architecture first
We built the foundation on AWS, ingestion pipelines, processing layers and storage, with Apache Airflow for orchestration, AWS Glue for ETL, Athena for querying and Azure IoT Hub for device connectivity. Everything after this depended on it.
Which sensors can be trusted
We analysed field trial data to find which sensors were most durable and reliable across product variants. There was no ground truth to compare against, so we used clustering to detect abnormal behaviour by examining correlations between groups of sensors.
What the device is actually doing
Multivariate models classify the operating mode automatically, heating, cooling, standby, defrost and others, which shows how devices are really used in the field instead of how everyone assumed they were.
Catching the fault early
Algorithms identify a sensor or device malfunction by detecting deviations from normal data patterns. Automated alerts replaced manual monitoring, which means an issue surfaces before it becomes a failure or a service call.
Effect on the surrounding environment
We built models that assess how different operating modes affect the environment around the device, including automatic air quality optimisation based on indoor and outdoor conditions.
What changed
The results
Before
Sensor data collected but largely unused. Reactive maintenance, no automated classification of device behaviour, and no early warning of a malfunction.
After
A full cloud analytics platform in production, with automated anomaly detection, operating mode classification and sensor reliability insight across the fleet.
The client moved from reactive maintenance to data-driven decisions, and malfunctions that used to go unnoticed are now caught automatically.
Product teams gained concrete data on sensor reliability, which feeds future hardware decisions rather than staying an operations concern.
Operating mode classification revealed how the devices are actually used in the field, and that went straight into product development.
The engagement shows what a structured approach to IoT data unlocks: solid cloud architecture first, ML use cases layered on top, applied to data that was already being generated and never exploited.
Questions about this project
Anomaly detection and sensor analytics. The client was sitting on a large volume of IoT sensor data but had none of the data architecture, processing pipelines or models needed to get anything out of it. Everything was manual, or was not happening at all.
Devices monitored, each carrying 50 or more sensors: 100+. Distinct AI use cases delivered across the engagement: 5. A full cloud data architecture built from scratch: AWS. Anomaly detection in place of manual sensor monitoring: Auto.
Machine learning with deep neural networks. Technology used: Machine learning, Deep neural networks, Time series analysis, Anomaly detection, Clustering algorithms, AWS Airflow, Glue and Athena, Azure IoT Hub, Python.
Technology used
Talk to the people who built this
theBlue.ai comes back within one business day.
