Predictive maintenance alerts catch a failing bearing, an overheating compressor head, or a seized pump seal weeks before it takes a line down — this guide covers the sensor, rule, and alarm setup on Kilo Cloud step by step, built for teams running 2026 production schedules with no room for surprise downtime.
- Kilo Cloud's rules engine turns raw vibration and temperature readings into predictive maintenance alerts for industrial equipment in under an hour per asset template.
- Set vibration RMS thresholds around 4.5 mm/s on rotating equipment; that's early bearing wear, not shutdown-level failure.
- mioty-based sensors hold signal better than standard LoRaWAN inside dense steel-frame plants — check sensor fit before wiring a pilot.
- Route predictive maintenance alarms to SMS or a named supervisor, not just a dashboard tile nobody watches at 2 a.m.
- Test every new alarm against a real fault condition before trusting it on the floor in 2026.
Why this matters
Most plants already collect temperature, vibration, or current data somewhere. The gap is turning that stream into an alert someone actually acts on before the failure, not a chart someone reviews after it. A predictive maintenance platform for manufacturing closes that gap by pairing sensor readings with rules that fire on trend, not just on a single bad reading.
Unplanned downtime is the most avoidable line item on a maintenance budget, and it's almost always preventable with a threshold set two or three weeks earlier than the emergency call. The setup below assumes you're starting from sensors and connectivity that already exist or are being installed for this purpose in 2026 — not a greenfield IoT rollout.
What you'll need
- At least one vibration or temperature sensor per monitored asset — bearing housing, motor casing, compressor head, or pump seal
- A connectivity path: a LoRaWAN gateway, a mioty base station, or an MQTT bridge from an existing PLC or SCADA system
- A Kilo Cloud workspace with the rules engine and alarms enabled
- Baseline readings from the equipment running normally for at least 1-2 weeks
- A named recipient list — who gets the alert, and on which channel
- Time: budget 2-3 hours for the first asset, then 15-20 minutes per additional asset once a rule template exists
The steps
1. Establish a baseline before you touch a threshold
Run the sensor for 7-14 days under normal load before setting any alarm condition. A vibration sensor on a healthy motor might read 1.5-2.5 mm/s RMS at steady state — that range is your zero point, not a guess from a spec sheet. Skipping this step is the single most common mistake: teams copy a generic threshold from a vendor manual and spend the first month chasing false alarms.
2. Pick sensor and connectivity for the environment, not the catalog
Dense steel structures, thick concrete, and metal enclosures degrade standard LoRaWAN range fast. mioty's telegram-splitting approach holds up better in that kind of RF environment, which is why plants with heavy structural interference lean on mioty industrial sensors instead of defaulting to whatever protocol was used on the last site. If a PLC already streams the data, an MQTT bridge into Kilo Cloud skips new hardware entirely.
3. Wire the rule around a condition, not a single reading
A single vibration spike can be a forklift bumping the machine. A rule that requires the reading to stay above threshold for a sustained window — say 4.5 mm/s RMS sustained for 10 minutes — filters that noise out. Kilo Cloud's rules engine lets you combine duration, threshold, and asset scope in one condition instead of one flat trigger per sensor.
4. Set severity tiers instead of one flat alarm
One alert level treats early bearing wear the same as imminent failure, which trains operators to ignore everything. Set a warning tier at the first deviation from baseline (say 20-30% above normal RMS) and a critical tier closer to the failure threshold. This is the same layered logic behind vibration anomaly alarms — a warning that goes to a maintenance queue, and a critical alert that interrupts a person immediately.
5. Route the alert to a person, not just a screen
A dashboard tile is not an alert. Configure the critical tier to hit SMS, a webhook into your CMMS, or a direct message to the on-shift supervisor. If the only place a predictive maintenance alert appears is a dashboard nobody has open at 2 a.m., the alarm did its job and the process still failed.
6. Use the AI integrator to draft the rule in plain language
Instead of building conditions field by field, describe the outcome — "alert me if compressor 3's bearing temperature stays above 80°C for more than 15 minutes" — and let Kilo Cloud's built-in AI integrator draft the rule and confirm it against your live device list before it goes active. It still shows you the exact condition before saving, so nothing runs on autopilot.
7. Test the alarm against a real condition before you trust it
Simulate the failure condition, or wait for a planned maintenance shutdown, and confirm the alert actually fires and reaches the right person on the right channel. An untested alarm is a guess with a green checkmark next to it.
“If the vibration alarm fires more than once a shift, the threshold is wrong, not the machine.”
Troubleshooting
- Alarm fires constantly. Raise the threshold or add a sustained-duration condition instead of a single-reading trigger — most noise comes from short mechanical bumps, not real drift.
- No alert despite a known failure. Check the sensor's uplink interval first; a sensor reporting every 30 minutes will miss a fast-developing fault. Confirm the rule status is active, not paused.
- Alert reaches the dashboard but nobody responds. Add an SMS or webhook channel to the critical tier — dashboards get missed, phones don't.
- Sensor stuck on "waiting for first data." Check battery seating and gateway range before assuming a firmware problem; re-provision the device if it still won't report after 30 minutes in range.
- Vibration threshold trips on every startup. Exclude the first 2-3 minutes after power-on, or average the RMS reading over a longer window so a normal startup surge doesn't read as a fault.
- Signal drops inside a steel-frame structure. Reposition the gateway closer to the asset or move to a protocol built for that environment — see the sensor fit note in step 2.
Tools and resources
- Kilo Cloud rules engine and alarms — the core of every predictive maintenance alert built in this guide
- Sensor data integration via API if readings already live in another system and need to feed Kilo Cloud's rules directly
- A baseline log (spreadsheet is fine) recording normal readings before any threshold goes live
- A named on-call list per asset class, reviewed at least quarterly through 2026
Set up your first predictive alert
See how Kilo Cloud pairs sensors, rules, and alarms on one platform.
What to do next
Once the first asset is alarmed and tested, the next move is scaling the rule template across every similar asset on the line rather than rebuilding each one from scratch — copy the condition, swap the device, adjust the baseline. Teams running mixed equipment across several sites usually hit a device management question before a rules question; that's worth sorting out before the sensor count climbs past a handful of assets.
FAQ
What's the best way to set predictive maintenance alerts for industrial equipment?
Start with a 7-14 day baseline on normal operation, then set a rule with a sustained-duration condition rather than a single-reading trigger. Layer a warning tier and a critical tier so operators can tell drift from imminent failure.
Is vibration or temperature better for predictive maintenance alarms?
Vibration catches bearing and alignment problems earlier, often weeks before failure; temperature catches overheating, friction, and lubrication issues closer to the event. Most rotating equipment benefits from monitoring both.
How much does a predictive maintenance alert setup cost in 2026?
Cost depends on sensor count, connectivity type, and whether hardware already exists on site. Check current sensor and platform pricing directly rather than assuming a flat per-asset number.
How often should I check the alarm thresholds?
Review thresholds quarterly, or immediately after any mechanical work on the asset, since a rebuild or part replacement shifts the normal baseline.
Can I use existing PLC data instead of new IoT sensors?
Yes — an MQTT bridge can feed existing PLC or SCADA readings into a rules engine without adding new hardware, as long as the data includes the reading you want to alarm on.
What causes false predictive maintenance alerts?
Single-reading triggers without a duration condition are the most common cause, along with thresholds copied from a generic spec sheet instead of a measured baseline.
Should alerts go to email, SMS, or a dashboard?
Warning-tier alerts can sit in a dashboard queue for review, but critical-tier alerts need SMS or a direct message to a named person — dashboards get missed during a shift.
How long before predictive maintenance alerts start working reliably?
Expect 2-4 weeks of tuning after the baseline period as thresholds get adjusted against real plant noise, then the rule template can be copied across similar assets in minutes.
One last thing
The rule that catches the most failures early isn't the tightest threshold — it's the sustained-duration condition. A single bad reading is noise; the same reading held for 10 minutes is a trend, and trends are what predictive maintenance alerts for industrial equipment are supposed to catch before the shutdown call.
