Sensors + software: why full-stack CMMS wins

The integration tax nobody budgets for

The standard path to condition monitoring looks reasonable on a slide: buy sensors from one vendor, an IoT platform from a second, and connect both to your CMMS through an integration layer. In practice each seam is a project. Sensor payloads must be mapped to assets. Alert thresholds live in one system while work orders live in another. Firmware updates break parsers. Every vendor points at the other two when data stops flowing.

Teams that have run this stack report the same pattern: the pilot works, because pilots get engineering attention. The rollout stalls, because every new site repeats the mapping and calibration work with less attention. Twelve months in, half the sensors report into a dashboard nobody opens, and the CMMS still runs on manual meter readings. The failure is not any single product. It is the seams.

The integration tax also compounds at exactly the wrong moment — when an anomaly fires. An alert that must hop from sensor cloud to IoT platform to middleware to CMMS arrives late, stripped of context, and unassigned. The value of early detection is measured in hours. A three-system relay routinely spends those hours on plumbing.

What changes when hardware and software share a data model

In a full-stack system, a vibration sensor is not an external data source. It is a property of the asset record. Mount an OpsSense Vibra on a pump and the pump's page shows its telemetry, its alert history, and the work orders those alerts created — one object, one screen, one permission model. There is no mapping table to maintain because the sensor was born knowing which asset it belongs to.

This closes the loop that stitched stacks leave open. An anomaly on a bearing can create a work order that carries the waveform snapshot, the trend chart, and the recommended inspection checklist — automatically, because alerting and work management are the same system. The technician arrives knowing what the sensor saw. The reliability engineer sees, in one query, which alerts led to real findings and which were noise. That feedback loop is how detection models actually improve.

It also changes who is accountable. When readings look wrong, there is one vendor to call, and that vendor cannot triage by blaming a partner. Single-vendor accountability sounds like a procurement talking point until the first 2 a.m. incident, when it becomes an operational fact.

The deployment math

Consider an illustrative mid-size plant: 60 rotating assets to instrument, plus energy metering on 12 panels. The stitched path typically involves a site survey by the sensor vendor, gateway configuration by the IoT platform team, an integration workstream to reach the CMMS, and a commissioning phase to align asset IDs across three systems. Plans of 4–6 months are common, and the integration line item often rivals the hardware cost.

The full-stack path collapses this: sensors ship pre-paired to an edge gateway, the gateway ships knowing the site, and a technician assigns each sensor to its asset by scanning the asset's QR code during mounting. Commissioning becomes a checklist inside the same mobile app used for work orders. Days, not months — and repeatable at site two through site twenty, which is where stitched deployments historically die.

Honest caveat: full-stack does not mean cheapest per sensor. A commodity vibration sensor may cost less than an integrated one. The comparison that matters is installed, connected, and generating actioned work — per asset, per year. On that basis the integration tax usually dominates the hardware delta.

Where third-party sensors still make sense

No vendor's catalog covers every measurement. Specialized instrumentation — ultrasonic thickness, oil particle counters, high-temperature furnace probes, hazardous-area certified devices — will come from specialists for the foreseeable future. A credible full-stack platform must therefore stay open: MQTT, Modbus, OPC-UA, and LoRaWAN ingestion should be first-class, so third-party and legacy devices land in the same asset-centric model as first-party ones.

The same applies to existing investments. If a plant already has a SCADA historian or a fleet of installed sensors, ripping them out to achieve vendor purity is bad engineering. The right architecture treats first-party hardware as the fast path and open protocols as the guaranteed path. Judge a full-stack vendor by how well it ingests hardware it did not sell — that is the test of whether 'open fabric' is real.

How to evaluate a full-stack vendor

Run three tests. First, the loop test: from a live sensor threshold breach, how many systems and how many minutes until a technician holds an assigned work order with the sensor context attached? The answer should be one system and under a minute. Second, the openness test: bring a third-party Modbus or MQTT device and clock how long it takes to appear on an asset record. Third, the scale test: ask for the commissioning procedure for site five, in writing. If it reads like site one, rollout will stall.

Then check the unglamorous parts: battery life claims versus replacement logistics, firmware update mechanics, what happens to buffered data when connectivity drops, and how sensor health itself is monitored. A dead sensor that nobody notices is worse than no sensor — it provides false confidence. Full-stack wins because it makes the whole chain observable and accountable. Verify that the chain, not just the demo, holds.