IoT Sensors for Predictive Maintenance

Ask a vendor about IoT sensors for predictive maintenance and you will get a catalogue: battery life figures, wireless range in open field, a cloud dashboard with a health score. Ask a reliability engineer the same question and you will get a different conversation entirely, one about mounting surfaces, sampling rates, failure modes and whether anyone is actually on the hook to respond to an alert. Both conversations matter, but only the second one determines whether the money comes back. Having sat on the implementation side of CMMS, EAM and CAFM projects for over two decades, I have watched sensor deployments succeed and fail, and the difference is almost never the sensor brand. It is the engineering around it.

The message up front: a sensor is only useful if it can physically see the failure mode you care about, if it is mounted and sampled well enough to resolve that signal, and if its output lands in front of somebody with a duty to act. Get those three right on a small number of critical assets and the sensing layer earns its keep. Get any one of them wrong and you have bought a data subscription, not a maintenance capability.

1. Start from the failure mode, not the sensor catalogue

The correct order of operations is unglamorous and almost always skipped. You do not start by choosing sensors. You start by writing down, for a specific asset, the handful of failure modes that actually cause it to stop doing its job, and then you ask a blunt question of each one: does this failure mode emit a physical signal, early enough and strongly enough, that an instrument can detect it from outside the machine?

For a centrifugal pump the honest answer is usually yes for bearing degradation, yes for misalignment and imbalance, yes for cavitation, partially for impeller wear, and no for a sudden coupling fracture or a failed control card. That answer, not a product sheet, decides the sensor list. Bearing degradation and imbalance point to vibration. Cavitation points to a combination of vibration, discharge pressure and ultrasonic. Impeller wear shows up in the relationship between flow, pressure and power draw rather than in any single channel. And the sudden failures point nowhere at all, which is a legitimate outcome: those get redundancy, spares strategy or design change, not monitoring.

This is the same detectability screen described in the predictive maintenance practitioner's guide, applied one level down at the instrument level. The screen has a second half that matters just as much: even where a signal exists, you need to know roughly how long the warning lasts. A failure mode that gives six weeks of rising vibration can be caught by a sensor reporting twice a day. A failure mode that goes from first detectable to functional failure in eight hours cannot, no matter how good the sensor is, if the device is configured to wake up once every twelve hours to save battery. Detectability and sampling cadence are a matched pair, and they are set at procurement time.

2. The sensor types and what each one actually detects

Below is the working set. Each entry is described by what it genuinely sees rather than what it is marketed as seeing, because the gap between those two is where most disappointment originates.

Accelerometers and vibration sensors. The richest source of mechanical diagnostic information on rotating equipment, and the sensor most often installed badly. Vibration energy at particular frequencies maps to particular defects: unbalance at running speed, misalignment typically at twice running speed with an axial component, looseness as multiple harmonics, gear mesh defects at tooth-passing frequencies, and rolling element bearing defects at characteristic frequencies calculable from the bearing geometry. That mapping is what makes vibration diagnostic rather than merely indicative.

Two configuration choices decide whether you get diagnosis or only a trend. The first is axes. A single-axis sensor mounted radially will see unbalance and bearing defects well enough to trend, but it misses the axial signature that distinguishes misalignment from other faults. Triaxial costs more, consumes more power and triples the data, but it lets an analyst separate fault types rather than just observe that something is worsening. My default: triaxial where you intend to diagnose, single-axis where you only intend to trend and escalate to a handheld analyser when the trend moves.

The second, and this is what separates a useful vibration program from a decorative one, is sampling rate and what the device transmits. A sensor reporting an overall RMS velocity value once an hour gives you a trend line. That is not nothing, but it tells you only that vibration increased, not why. To diagnose you need a spectrum, which means sampling fast enough to resolve the frequencies of interest. The sampling theorem sets a hard floor at twice the highest frequency you care about, and practical spectral analysis wants comfortable margin above that. Bearing and gear mesh frequencies sit well above running speed, which is why cheap low-bandwidth wireless sensors can trend a pump but cannot explain its degradation. Ask for the sampling rate, the frequency range of the delivered spectrum, the lines of resolution, and whether the raw time waveform is available. If the answer is vague, assume trending only and price the program accordingly.

Temperature: contact and infrared. Heat is the most universally available symptom because almost every failure mechanism eventually dissipates energy. Contact sensors, thermocouples or RTDs, are accurate, cheap and reliable, and are right for bearing housings, windings, lubricant sumps and process fluid. Infrared measures surface temperature without contact, which is what you want for rotating surfaces and energised electrical parts. The infrared limitation is emissivity: the reading depends on the surface's radiative properties, so shiny metal reads badly unless you correct for it or apply a high-emissivity target patch. Temperature is also a late indicator on mechanical faults. By the time a bearing housing is measurably hot, vibration has been telling the story for weeks. Use it as corroboration and as a safety backstop, not as primary early warning on rotating plant.

Ultrasonic sensors. Airborne and structure-borne ultrasound picks up high-frequency emissions that vibration sensors and human hearing miss. Three applications justify their place: compressed air and gas leak detection, often the fastest-paying single application in an industrial plant; early-stage bearing lubrication problems, detected before measurable vibration change; and electrical partial discharge and arcing in switchgear, complementing thermography. Steam trap assessment and valve pass-through are useful secondary uses. The limitation is that ultrasound is highly directional and heavily attenuated, so placement and background noise matter enormously, and interpretation leans on operator skill more than most techniques.

Current and power monitoring. A motor is an instrument for measuring its own load, if you read the supply carefully enough. Current transformers clamped on the supply are non-intrusive, cheap, safe to retrofit and need no access to the driven machine. Motor current signature analysis can reveal broken rotor bars, air-gap eccentricity, stator winding issues and load-side faults. Power monitoring adds a second dimension: the relationship between power draw and delivered output is a direct efficiency measure, and slow divergence between them is one of the cleanest degradation signals available. This is the sensor type I most often recommend as a first deployment on a site with no monitoring at all: low installation risk, no contact with the machine, and coverage of both electrical and mechanical degradation.

Pressure sensors. Suction and discharge pressure on pumps, differential pressure across filters and heat exchangers, system pressure on hydraulic and pneumatic circuits. Differential pressure across a filter is the textbook condition signal: it rises monotonically with loading and has a clear intervention threshold, so it is easy to automate and easy to trust. On pumps, pressure paired with flow places the machine on its performance curve, which is how you distinguish a worn impeller from a blocked strainer from a closed valve. Transducers are wetted components, so they add a leak path and they drift, which means calibration belongs in the PM schedule.

Flow sensors. Flow rarely earns its place as a standalone condition sensor: meters are comparatively expensive, often intrusive, and flow alone is ambiguous. Its value is as the partner to pressure and power, because flow plus head plus power gives hydraulic efficiency, and a declining efficiency trend on a large pump is a financial signal independent of any failure prediction. Where flow metering already exists for process or billing reasons, harvest it. Where it does not, think twice before adding it purely for condition monitoring.

Oil quality sensors and particle counters. Laboratory oil analysis remains the gold standard for wear diagnosis because a lab identifies which metals are present and therefore which internal surface is wearing. Inline oil sensors do something complementary: they continuously monitor bulk properties, typically viscosity, dielectric constant, water content and sometimes ferrous debris, and flag a change between lab samples. Inline particle counters track contamination against cleanliness codes, the primary driver of hydraulic component life. Oil-based techniques usually give the longest warning of any method, sometimes months. The limitation is that inline sensors tell you something changed, not what is wearing, so the sensible architecture is inline sensing to trigger an off-schedule laboratory sample rather than to replace the lab.

Acoustic emission sensors. Distinct from ultrasonic microphones, acoustic emission listens for the elastic stress waves released when material deforms, cracks or rubs. It is the technique for crack initiation and growth in pressure vessels, structures and slow-turning large bearings where conventional vibration analysis struggles for lack of rotational energy to produce a clean spectrum. Specialist, interpretation-heavy, and rarely justified outside high-consequence structural and pressure-containment applications.

Humidity and environmental sensors. These do not monitor the asset, they monitor the conditions that shorten its life: humidity in a switch room, temperature in a UPS or battery room, dust loading at air intakes, water presence in a basement plant room. Cheap, low-power, and they prevent a category of failure that monitoring the asset itself will not catch until damage is done. Leak detection cable in a plant room is one of the highest-value low-cost sensors in facilities work, and it belongs in the same conversation as the smart building real-time monitoring layer.

Displacement and proximity probes. Eddy-current probes measure actual shaft position and movement relative to the bearing housing rather than casing vibration. On large machines with fluid-film bearings, turbines and large compressors, shaft displacement is the correct measurement and casing accelerometers are the wrong one, because the oil film decouples shaft motion from the casing. These are permanently engineered installations, usually part of a machinery protection system rather than a retrofit IoT deployment.

3. Sensor selection reference table

The table below is the summary I would put in front of a maintenance team deciding where to spend a first monitoring budget. The limitation column is the one to read twice.

4. Mounting quality: the most common cause of useless vibration data

If there is one paragraph here to act on, it is this one. More vibration deployments are ruined by mounting than by every other cause combined, and the damage is insidious because a badly mounted sensor still reports numbers. The data looks fine. Nobody discovers the problem until an analyst tries to diagnose a fault and finds the spectrum has nothing usable above a couple of kilohertz.

The physics is simple. An accelerometer measures the motion of whatever it is attached to. A compliant attachment behaves as a spring and mass system with its own resonance, and above a fraction of that resonant frequency the sensor no longer faithfully reports machine motion. The mounting method therefore sets the usable frequency range, which sets whether bearing and gear defect frequencies are visible at all. Ranked from best to worst:

• Stud mounting into a spot-faced, tapped hole. The reference standard. Widest usable frequency range, mechanically secure, survives wash-down and vibration. It requires drilling and tapping the machine, which means planning, permits and sometimes OEM warranty conversations. Worth the trouble on assets you intend to monitor for years.
• Adhesive mounting on a prepared flat pad. Very good when done properly with a rigid adhesive on a clean, flat, paint-free surface. Preparation is the whole game: paint, rust and curvature all degrade the coupling. A thick or flexible adhesive layer will throw away the high-frequency range.
• Magnetic mounting, flat or dual-rail magnet. Convenient, removable, and the correct choice for walk-around routes. Usable frequency range is meaningfully lower than stud or adhesive, and it depends on the magnet, the surface and the cleanliness of both. Acceptable for permanent installation only when you have accepted a trend-only program.
• Handheld probe on the machine surface. Fine for a quick check, and not a measurement you should trend or compare over time, because the contact quality and angle vary with every reading.

Location matters as much as method. The sensor belongs as close as physically possible to the bearing being monitored, on the bearing housing itself, in the load direction, on solid metal rather than on a cover, shroud, guard or fan cowl. I have seen wireless sensors adhered to a sheet metal fan cover because it was the only flat accessible surface; those were measuring the resonance of the cover, not the condition of the bearing. Position must also be repeatable: mark it, photograph it, record it in the asset record, because a reading taken 150mm from last quarter's is not comparable to it. The formal guidance is worth reading first hand, in the ISO standards catalogue : the ISO 13373 series on vibration condition monitoring, and ISO 10816 and ISO 20816 on vibration evaluation and severity limits. Give the installer the mounting requirement in writing and inspect the first ten installations yourself.

5. Sampling rate, resolution and the battery trade-off

Every wireless sensor specification is an argument between three things that cannot all be maximised: how often it measures, how much detail each measurement carries, and how long the battery lasts. Vendors resolve that argument in the marketing material by quoting battery life at the lowest useful sampling configuration and diagnostic capability at the highest. Read both numbers from the same configuration or you are being misled by omission. The practical shape of the trade-off:

• Measurement interval. A device reporting an overall value every few hours can run for years. One capturing a full high-resolution spectrum every fifteen minutes will not. Derive the interval from the warning window of the failure modes, with margin, not from the battery datasheet.
• What gets transmitted. Scalars are cheap in power and bandwidth; a full time waveform is expensive in both. The architecture that usually wins is scalars frequently, spectra on a slower schedule, and a high-resolution capture triggered automatically when a scalar threshold is breached. Continuous trending, periodic diagnosis, detail exactly when something is developing.
• Frequency range and lines of resolution. These decide whether a spectrum is diagnostic. Too few lines smears adjacent frequencies together, which is how a bearing defect frequency ends up indistinguishable from a nearby harmonic. Specify from the machine's running speed and bearing geometry, not from the vendor default.
• Battery replacement as a maintenance task. A three to five year battery across two hundred sensors is a recurring PM job, a stocked spare and an access plan, and a source of silent data loss when a sensor dies unnoticed. Monitor sensor health and last-reported time as a first-class metric.

A fourth variable gets forgotten: the machine's operating state at the moment of measurement. A vibration reading at forty percent speed on a variable frequency drive is not comparable to one at full speed, and a temperature reading on a machine that started ten minutes ago means nothing. Sensors sampling on a fixed clock, blind to duty, generate scatter that looks like degradation. Either gate the measurement on a run signal and speed band, or capture speed and load alongside every reading so the analysis can normalise. That is the strongest argument for pulling context from the control layer, which is why SCADA and CMMS integration and IoT to BMS integration matter more to sensor data quality than most people expect.

6. Wired versus wireless, and the connectivity decision

Wireless made retrofit condition monitoring economically viable, and that is a genuine shift. It did not make wiring obsolete. The choice comes down to how critical the asset is, how much data you need off it, and whether cable routing is feasible.

Wired sensing wins where you need continuous high-bandwidth data, guaranteed availability, protection-grade reliability, or power that does not run out: large rotating machines on machinery protection systems, anything where a monitoring outage is itself a safety or availability issue, and assets that are already inside a control system with spare instrument capacity. Wireless wins for the long tail: the hundreds of pumps, fans, AHUs and motors scattered across a site where running conduit to each one costs multiples of the sensor, and where a periodic measurement is genuinely sufficient.

The connectivity choice within wireless is where the coverage problems live, and the honest version of this table looks different from the vendor version because vendors quote range in open air.

The coverage problem deserves a specific warning because it is the most common unpleasant surprise. Plant rooms, basements, pump houses, tank farms, lift motor rooms and switch rooms are radio-hostile by construction: reinforced concrete, steel plant, dense pipework, metal enclosures, often below grade. A sensor that works perfectly on a bench in the office will not reach a gateway two floors up through a slab. Two habits prevent this from derailing a project. Do a physical RF survey in the actual rooms before you order, not after. And count gateways as part of the sensor cost rather than an afterthought, because the count needed in a basement plant room is routinely well above what a vendor coverage model suggests. Remember too that each gateway needs power and a backhaul path, which is a small cabling project in exactly the location you were trying to avoid cabling.

7. Edge preprocessing, data volume and what it costs to keep

Raw vibration waveforms are large. Sample a triaxial accelerometer fast enough for bearing diagnosis and streaming everything to a cloud platform, then paying to store it indefinitely, becomes a poor decision. Edge preprocessing is the answer. In the sensor or in the gateway, the device performs the frequency transform locally and transmits derived features, overall values, band energies, peak frequencies, crest factor, envelope values, instead of the raw waveform. That cuts volume by orders of magnitude while keeping most of the diagnostic content. The pattern is tiered: features always, spectra periodically, raw waveform on exception. Keep features long term because trends need history, and keep raw captures on a shorter retention window because their value is immediate.

The cost conversation to have before signing covers four lines, and usually only the first is in the proposal: sensor hardware; gateways and network infrastructure; the platform subscription, often priced per sensor per year and the item that grows quietly as the deployment scales; and storage and egress for the data volume you have committed to. On a five-year view the recurring lines usually exceed the hardware. Model it over five years, per asset, against the failure consequence you are protecting. That is the same triage described in asset criticality classification: monitoring spend concentrated where failure genuinely hurts, and deliberately withheld from the rest.

Edge processing also buys resilience. A gateway that buffers locally through a network outage loses nothing; one that does not leaves gaps, and a trend with holes in it is much harder to extrapolate from. Ask specifically about buffering depth and behaviour on reconnection.

8. Cybersecurity: you are adding devices to an OT network

Every sensor, gateway and cloud connection you add is a new element on or adjacent to the operational technology network, and it deserves the same scrutiny as any other OT change. This is the part of a sensor project most likely to be discovered late, usually by an IT security review two weeks before go-live, and it can stop a deployment cold.

The controls I would insist on before a single gateway is installed:

• Segmentation. Monitoring devices sit on their own network segment, firewalled from both the control network and the corporate network, with explicitly permitted flows. A condition monitoring gateway has no business being able to reach a PLC.
• One-way data flow wherever possible. Condition monitoring is a read activity. If the architecture allows data out without allowing commands in, insist on it. Any vendor requirement for inbound remote access needs a named justification and a controlled mechanism, not a permanent open tunnel.
• Authentication and encryption in transit and at rest, with default credentials changed on every device during commissioning. Default passwords on gateways are depressingly common and are found by automated scanning within days of exposure.
• Patching and firmware lifecycle. Ask how firmware is updated, whether updates are signed, how long the vendor commits to supporting the device, and what happens when support ends. A sensor fleet is a ten-year commitment and a device with no update path becomes a liability.
• Asset inventory. Every gateway and sensor goes in the asset register with an owner, a location and a firmware version. Devices nobody owns are devices nobody patches.
• Data residency and access. Know which jurisdiction the platform stores your operational data in, who at the vendor can see it, and what happens to it if you terminate. This is a contract question, not a technical one.

The reference frame worth aligning to is the industrial control system security series published by the International Society of Automation , the ISA/IEC 62443 family, along with the guidance from the US National Institute of Standards and Technology on operational technology security. Bring your IT security team into the project at the requirements stage, not at the review stage. They will say yes to a design they helped shape and no to one presented as finished.

9. Retrofit sensing versus embedded OEM sensing

There are two routes to a monitored asset, and they suit different situations. Retrofit sensing means adding third-party sensors to equipment already in service. Embedded OEM sensing means buying equipment that arrives instrumented, with the manufacturer's own monitoring platform behind it, which is increasingly the default on new motors, drives, chillers, gensets and large rotating packages.

Retrofit is the right call for an existing estate, which is most estates. It lets you choose where to spend based on criticality rather than on what happened to be bought. It gives you one sensor platform across mixed vendors, which matters enormously once you have chillers from one manufacturer, pumps from three others and gensets from a fifth. And it keeps the data in a system you control. The costs are real: installation labour, access and permits, mounting quality risk, network coverage work, and warranty conversations with OEMs about drilling their machines.

Embedded OEM sensing is the right call when the equipment is new, when the OEM has genuine physical access to signals you cannot reach from outside, internal winding temperatures, drive-level electrical data, refrigerant circuit parameters, internal control states, and when the OEM's algorithms are built on a fleet of identical machines and therefore have training data you will never accumulate yourself. A drive manufacturer monitoring its own drive has an information advantage no retrofit sensor can match.

The honest problem with the embedded route, and it gets worse every year, is fragmentation. Five OEM portals, five logins, five alerting models, five sets of terminology, and your maintenance team living in none of them because their actual job runs in the CMMS. My standing recommendation is a hybrid: accept embedded OEM monitoring where it gives access you cannot otherwise get, insist at procurement time on an open data interface out of it, typically an API or OPC UA endpoint or at minimum a structured export, and then normalise everything into one place that feeds the CMMS. Make that interface a contractual requirement in the equipment specification. Asking for it after delivery is a change order and sometimes a refusal. The integration patterns for that consolidation are covered in IoT integration with CMMS and more generally in IoT integration explained.

10. The two failure patterns that kill sensor programs

I want to be blunt about these, because between them they explain the large majority of sensor deployments that quietly stop being talked about after the first year. Neither is a technology failure.

Pattern one: sensors installed on assets whose failures the sensor cannot see. This happens when the deployment is organised by convenience rather than by failure mode. A budget arrives for two hundred wireless vibration sensors, and the deployment plan becomes a list of the two hundred most accessible motors. Some of those assets fail through bearing degradation, and for those the sensors work. Others fail through seal leakage, control card failure, blocked strainers, operator error or electrical supply problems, and for those the vibration sensor will report a healthy machine right up to the moment it stops. The program then produces a mixed record: it caught some failures, missed others, and nobody can explain the pattern, so trust decays. The fix is the section one discipline: monitor the failure mode, not the asset. A pump that fails through seals needs a different sensor, or no sensor at all, rather than the same sensor as its neighbour.

Pattern two: sensor data flowing to a dashboard nobody has a duty to act on. This is the more common and the more expensive of the two, and it is almost entirely organisational. The sensors are correct, the mounting is good, the platform works, the alerts fire. They fire into an email inbox, or onto a screen in an office, or into a portal that the reliability engineer opens on Tuesdays. There is no named role accountable for triage, no defined response time, no route from alert to work order, and no record of what was done. Within a few months the alerts are noise, the team has learned to ignore them, and the only remaining question is who cancels the subscription.

The fix is workflow, not technology, and it is specific. Every alert class needs a named owner and a response time. Every alert that survives triage becomes a work order in the CMMS, with the sensor reading and the asset both referenced, so the technician sees why they were sent. Every work order closes with a finding that says whether the alert was correct, which is the only way thresholds ever get tuned and the only way anyone can later prove the program works. Alert volume needs a ceiling, because a system generating more alerts than the team can triage is worse than no system at all: it teaches people to ignore instruments. And the metric that matters is not alerts generated. It is failures caught before functional failure, and unplanned downtime avoided. If you cannot report those, you cannot defend the budget. The same closed-loop argument applies to any anomaly detection layer sitting on top of the sensors, as covered in AI anomaly detection and early fault warning.

11. A deployment checklist you can lift

This is the sequence I would put on a project plan for a first or second sensing deployment. The order is deliberate: the cheap decisions come first and each one narrows the expensive ones.

• 1. Rank by criticality. Take the top tier of assets by failure consequence. Everything below that tier is out of scope for this phase, whatever the budget allows.
• 2. Write the failure modes down, per asset class. Two to five dominant modes each, taken from your own maintenance history rather than from a generic list. If the history is too poor to do this, fix the failure coding first; a sensor programme built on unknown failure modes is a guess.
• 3. Screen each mode for detectability and warning window. Detectable with a usable window goes forward. Sudden or undetectable goes to redundancy, design change or spares strategy.
• 4. Map parameter to sensor. Use the selection table. Choose the fewest sensors that cover the surviving failure modes, not the most the budget permits.
• 5. Set sampling and resolution from the warning window, then check the battery and connectivity implications. If the required cadence and the battery target conflict, that asset needs a powered or wired sensor, not a compromised wireless one.
• 6. Survey the RF environment physically, in the actual plant rooms, and cost the gateways, their power and their backhaul.
• 7. Agree the security architecture with IT before ordering: segmentation, flow direction, credentials, patching, data residency.
• 8. Specify mounting in writing and inspect the first installations personally. Record and photograph every measurement point.
• 9. Build the alert-to-work-order path before the sensors go live. Named owners, thresholds, response times, CMMS integration, closing findings. If this is not ready, delay the sensors rather than the workflow.
• 10. Baseline every asset over a few weeks of normal operation across its real duty range, so you have something to compare against. Thresholds set from a vendor default rather than from your own baseline will either flood you or stay silent.
• 11. Review at ninety days. Alert precision, false positive rate, catches, misses, sensor health and data completeness. Tune thresholds from closing findings.
• 12. Only then scale, to the next criticality tier, using what the first phase taught you rather than what the original business case assumed.

For a worked example of the asset classes this usually lands on first, rotating plant is almost always the answer, and the practical monitoring and PM detail for those is in generator, pump and motor preventive maintenance. If you are still deciding whether you are building condition-based monitoring or genuine prediction, the distinction is worth settling early: see condition-based versus predictive maintenance.

The idea to walk away with

Sensors do not detect failures. They detect changes in physical parameters, and a parameter is only useful if it changes when the failure mode you care about develops, if the instrument is mounted and sampled well enough to resolve that change, and if a human being is obliged to respond when it does. Three conditions, all of which are decided by engineering and organisational choices rather than by the sensor you buy.

That reframing changes how a sensing budget gets spent. Instead of maximising the number of assets covered, you maximise the number of consequential failure modes actually visible, and you accept that this means instrumenting fewer assets more thoroughly. A hundred properly specified, properly mounted sensors on the failure modes that matter, feeding a workflow with named owners, will outperform a thousand sensors installed where access was easy and reporting into a dashboard with no duty attached to it. That is not a budget constraint talking. It is what the physics and the organisational reality both require.

Final thoughts

The sensing layer is the least glamorous and most decisive part of a predictive maintenance program. The interesting conversations happen further up the stack, about models and anomaly detection and remaining useful life, but every one of those depends on whether an accelerometer was stud-mounted on a bearing housing or stuck to a fan cover, whether the sampling rate resolves the frequencies that matter, and whether the gateway in the basement can actually reach the network. Those decisions are made early, by installation contractors and procurement specifications, and they are expensive to undo.

So spend the effort at the front. Write the failure modes down. Screen them for detectability. Choose the fewest sensors that cover them. Specify the mounting and inspect it. Survey the radio environment before you order. Bring security in at the requirements stage. Build the path from alert to closed work order before the first sensor transmits. None of that requires a large budget or a data science team, and all of it is within the control of the maintenance organisation itself. Do it and the sensing layer becomes what it should be: a quiet, reliable source of early warning on the assets you cannot afford to be surprised by.

Related reading: Predictive maintenance: a practitioner's guide, Condition-based vs predictive maintenance, IoT integration with CMMS, AI anomaly detection and early fault warning, Asset criticality classification, Smart building IoT and real-time monitoring.