You have identified the assets that matter most. You know that unplanned failures on those assets cost your organization hundreds of thousands of dollars annually. You have heard that IoT sensors and AI can predict failures weeks in advance.
Now comes the part most guides skip: how do you actually connect a vibration sensor on a pump to a work order in your CMMS?
This guide answers that question in concrete, actionable steps. It is written for maintenance engineers and IT teams implementing their first IoT-to-CMMS integration, and for operations leaders who need to understand what their team is building.
This post is part of our pillar series on AI-Powered Predictive Maintenance →
Before You Start: Three Prerequisites
A successful integration requires alignment on three things before any hardware is purchased:
1. A CMMS with an open API or native IoT connector Your CMMS must be able to receive external data. Some platforms require a middleware layer; others (like Task360) have native IoT ingestion built in. Confirm your platform’s integration architecture before specifying sensors.
2. A defined data model Decide in advance what data each sensor will send, at what frequency, and what asset record it maps to. A vibration sensor without a linked asset ID is useless data.
3. Network infrastructure at the asset location Sensors need connectivity. This is often the most underestimated constraint. Assess your facility’s Wi-Fi coverage, consider cellular-connected sensors for remote assets, and plan for edge computing nodes in areas with high sensor density.
Step 1, Select the Right Sensors for Each Asset Type
Sensor selection follows asset failure modes, not the other way around. Start with your criticality analysis and ask: what physical phenomenon precedes failure for this asset?
Rotating Machinery (motors, pumps, fans, compressors)
Primary: Vibration sensors (accelerometers)
- Mount on bearing housings, both drive-end and non-drive-end
- Look for sensors with 0-10 kHz frequency range to capture both low-speed and high-frequency bearing defects
- Sampling rate: continuous streaming for critical assets, 10-minute intervals for secondary
Secondary: Temperature (PT100 RTD or thermocouple) on motor windings and bearing housings
Electrical Equipment (switchgear, transformers, UPS)
Primary: Thermal imaging cameras or fixed IR sensors
- Detect hot spots at connection points, fuses, and busbars
- Trigger on temperature delta vs. baseline, not absolute value
Secondary: Current transducers (CTs) for load monitoring and power quality analyzers for harmonic detection
Fluid Systems (hydraulics, pneumatics, HVAC)
Primary: Pressure transducers upstream and downstream of key components
- Differential pressure across filters indicates blockage
- Pressure drop across pumps indicates impeller wear
Secondary: Flow meters, level sensors, and moisture sensors in lubricating oil systems
Stationary Assets (tanks, vessels, structural)
Primary: Ultrasonic thickness gauges for corrosion monitoring Secondary: Strain gauges for structural health on high-load components
Step 2, Choose Your Communication Protocol
This is where most IoT projects stall. There are dozens of protocols, and the right choice depends on your facility infrastructure, sensor vendor, and CMMS capabilities.
Industrial Protocol Reference
| Protocol | Best For | Range | Notes |
|---|---|---|---|
| MQTT | High-volume sensor streaming | Network-dependent | Lightweight, widely supported, ideal for cloud-connected CMMS |
| OPC-UA | PLCs and industrial automation systems | Network-dependent | Standard in manufacturing; rich data models |
| Modbus TCP/RTU | Legacy equipment and PLCs | Short (RS-485: ~1200m) | Ubiquitous in older facilities |
| LoRaWAN | Remote or outdoor assets | Up to 15km | Low power, low bandwidth; good for monthly meter readings |
| BLE (Bluetooth LE) | Handheld inspection tools | ~50m | Battery-operated; requires gateway |
| 4G/LTE | Remote assets with no facility network | Cellular coverage | Higher cost; eliminates Wi-Fi dependency |
Practical recommendation for most facilities: Use MQTT over Wi-Fi for high-frequency streaming sensors (vibration, temperature), and LoRaWAN for battery-operated sensors in areas without dense Wi-Fi coverage.
Step 3, Deploy an Edge Computing Layer (for High-Volume Assets)
For assets generating continuous high-frequency data (vibration sensors streaming at 10 kHz), it is not practical to send every raw reading to the cloud. An edge computing node (a small industrial PC or IoT gateway installed at the asset) handles:
- Signal processing, converts raw vibration time-series into frequency-domain features (FFT analysis)
- Anomaly pre-filtering, only sends alerts or compressed summaries to the CMMS, not raw data
- Local buffering, stores data during network outages and syncs when connectivity is restored
Popular edge platforms: AWS Greengrass, Azure IoT Edge, Siemens MindConnect, or purpose-built gateways from sensor vendors (ifm, SKF, Emerson).
Step 4, Map Sensor Data to CMMS Asset Records
This step is purely configuration, but it is the most important. Every data point sent to your CMMS must map to:
- An Asset ID, the specific piece of equipment being monitored
- A Measurement Point, which location on the asset (e.g., Drive-End Bearing, Non-Drive-End Bearing)
- A Parameter Type, vibration velocity, temperature, current, etc.
- Engineering Units, mm/s, °C, Amps
- Baseline and Alert Thresholds, normal operating range and the values that trigger alerts
Most CMMS platforms represent this as a Meter or Measurement Point object attached to the asset. In Task360, you configure measurement points in the asset profile and the API endpoint maps incoming sensor payloads directly to those points.
Example API payload (Task360 MQTT format):
{
"asset_id": "PUMP-042",
"measurement_point": "drive_end_bearing",
"parameter": "vibration_velocity_rms",
"value": 4.7,
"unit": "mm/s",
"timestamp": "2026-03-24T08:32:11Z"
}Step 5, Configure Alert Thresholds and Work Order Automation
With data flowing into the CMMS, define the rules that convert readings into action.
Threshold Types
Hard thresholds, absolute values based on ISO standards or OEM specifications:
- ISO 10816: vibration velocity >4.5 mm/s = Warning; >7.1 mm/s = Alarm (for most rotating machinery)
- Temperature delta >20°C above baseline = Warning for motor windings
Statistical thresholds, dynamic, based on the asset’s own historical baseline:
- Alert when current reading exceeds baseline mean by more than 3 standard deviations
- More sensitive than hard thresholds; catches gradual degradation earlier
AI/ML thresholds, generated by the predictive model:
- “Failure probability >70% within 30 days” triggers a Predictive Work Order
- This is the most powerful tier but requires 6-12 months of data to calibrate
Automating Work Orders from Alerts
Configure the CMMS so that when a threshold is crossed:
- A work order is automatically created with the correct asset, failure code, and priority
- The assigned technician is notified via push notification on their mobile device
- Required spare parts are listed on the work order based on the failure code
- If inventory is below the required quantity, a purchase requisition is triggered
This eliminates the human bottleneck between “sensor fires alert” and “technician is dispatched”, which in manual processes can take hours or days.
Step 6, Validate, Tune, and Scale
The first 90 days are a tuning phase, not a production phase.
Track false positives, alerts that fired but no actual issue was found. High false positive rates destroy technician trust. Raise thresholds or add pre-filters until the false positive rate is below 10%.
Track false negatives, failures that occurred without a prior alert. Analyze the sensor data retroactively. Was the failure mode captured by your sensors? Was the threshold too conservative?
Establish a monthly review cadence with your maintenance planner and whoever owns the CMMS configuration. Use real work order data (failure codes, repair findings) to continuously improve threshold accuracy.
Once the first cohort of assets is stable and the team trusts the system, expand to the next tier.
Common Pitfalls to Avoid
- Instrumenting too many assets at once, you will be overwhelmed with alerts before you have processes to handle them
- Skipping the data model design step, sensor data without a clear asset mapping is noise, not intelligence
- Using only hard thresholds, add statistical and AI thresholds as your data matures; they catch what hard thresholds miss
- Neglecting edge buffering, sensors with no local storage will lose data during network outages, creating gaps that corrupt trend analysis
- Not closing the feedback loop, if technicians do not enter completion notes and failure codes in work orders, the AI model never learns
The Result: A Closed-Loop Maintenance System
When this integration is fully operational, you have a closed loop:
Sensor → Edge → CMMS → AI Model → Work Order → Technician → Completion Data → AI Model
Each work order completed feeds more training data back into the model, making every future prediction more accurate. Over 12-24 months, the system becomes a compounding asset that grows more valuable the longer it runs.
