CMMS integration is where most sensing projects are actually decided, and it is the part almost nobody scopes. Last week we looked at what a custom battery-free sensor can measure. The measurement was the easy half of that post too. A reading that stays inside a tag, a phone or a CSV file has changed nothing. It starts to earn its keep when it opens, prioritises or closes a work order in the system your maintenance team already lives in.
This post is about that last stretch. Not the radio and not the message format, but what a reading has to carry before a computerised maintenance management system can act on it. We write it for the asset manager and the IT person who will own the pipeline. In our experience they are the ones who decide whether the project ships.
Why the work order decides the project
A sensor project has two ends. At one end there is physics: energy, antenna, sensing element. At the other there is a person with a job list. Everything in between exists to move a number from the first end to the second without losing its meaning on the way.
We have watched projects with excellent sensing fail at the second end. The readings arrived, went into a dashboard, and the dashboard became a second place to look that nobody opened twice. We raised this in the post on NFC maintenance rounds. There, the question of which system owns the record was one of the three that qualify the whole idea. This post is the answer to that question, written as a recipe.
The recipe has four steps. Identity, absence, reduction and the work order itself. Get those four right and CMMS integration becomes an afternoon of configuration. Get them wrong and no amount of middleware saves it.
What CMMS integration actually moves
It is tempting to think of CMMS integration as plumbing. Take the value out of the tag, put it into the maintenance system, done. But a CMMS does not store temperatures. It stores assets, conditions, work and history. A reading only fits once somebody has translated it into those four things.
So the pipeline is not moving a number. It is moving a claim: this asset, at this time, was in this condition, and here is the evidence. Each word in that claim is a design decision. Battery-free sensing changes two of them, and we will get to those.
Identity: the tag is not the asset
The first decision is what the reading is about. A tag reports its own serial number. A CMMS knows equipment numbers and functional locations. Somebody has to hold the mapping between the two, and that mapping is itself a maintenance record. Tags get replaced. Assets get moved. A pipeline that hard-codes the tag serial breaks the first time either happens.
Our recommendation is boring, and it works. The asset identity travels with the reading from the moment it leaves the reader. The mapping lives in one place that maintenance owns, not in the sensor firmware and not in a spreadsheet on the integrator’s laptop. When a tag is swapped, the swap is a work order like any other, and closing it updates the mapping.
This sounds obvious. It is also the step we see skipped most, because on day one there are twelve tags and everybody remembers which is which.
Absence: no reading is not a reading
Here is the first thing battery-free changes. A powered sensor that stops reporting is a fault. A battery-free sensor that stops reporting may simply be waiting for energy. It reports when a reader, a gateway or a phone is close enough to power it, and the interval depends on the field, not on a clock. No data has three possible meanings. The asset is fine, nobody has been past, or the tag is dead.
A CMMS cannot tell those apart, and nobody should ask it to. The pipeline has to. That means every point on the route needs an expected cadence. When a point goes quiet for longer than that cadence allows, the pipeline raises its own condition. Silence then becomes a state with a name, rather than a gap that looks like good news.
If you take only one thing from this post, take this. The most expensive failure in condition monitoring is not a false alarm. It is a missing reading that everybody read as normal.
Reduction: the CMMS wants an exception
The second battery-free change is volume, and it goes the other way. A fixed reader in a cabinet can interrogate a tag many times a minute. None of that belongs in the maintenance system. A CMMS is a system of work, and exceptions create work.
So between the reader and the CMMS there is a layer that keeps the time series and emits conditions. Call it a historian, an edge box or a rules engine. The name matters less than the question of who owns the threshold. In our experience the answer is the maintenance engineer, and the threshold should change without a firmware release or a ticket to IT. That is the same person who has to defend the switch from calendar to condition, and we wrote about what that business case rests on.
What crosses into the CMMS is small. Asset, condition, severity, when it started, and the last few readings as evidence. That is enough to open work, and it is all the CMMS integration has to carry. It is also small enough that the integration survives when the CMMS is replaced in five years and the tags are still on the assets.
The work order: what it needs to open, and what it needs to close
Opening a work order from a condition is the part every vendor demos. Closing it is where anyone measures the value, and it needs the pipeline just as much.
To open well, the work order needs the condition in the technician’s language, not the sensor’s. Not “channel 3 above threshold” but “joint B2 on the incoming busbar, warmer than its neighbours for six days”. The pipeline has that information. The CMMS does not, unless the pipeline sends it.
To close well, the work order needs a verification read. The technician tightens the joint, taps the tag, and the reading that comes back is the proof that the work was effective. Attach it to the closing record and something changes in the organisation. Maintenance history starts to contain measurements instead of tick boxes. Battery-free tags make that history cheap to collect, because the verification costs a tap rather than a battery.
The ERP side of CMMS integration is smaller than it sounds
The ERP holds the asset register, cost centres and spares. Most of what it needs from CMMS integration it already gets from the CMMS. Two things do change.
The first is the asset record itself. A battery-free sensor on a forty-year asset is a permanent attribute of that asset, not a consumable with a replacement cycle. So it belongs in the asset data rather than in the stores list. The second is the maintenance plan. The scheduled task that existed to replace batteries disappears. The task that existed to take a reading becomes a verification instead of a discovery. Both are changes to master data, and both are worth making explicitly. They are where the business case shows up in a place finance can see.
Three paths for CMMS integration, and which part is ours
We should be clear about what we deliver and what we do not. Our SDK and our evaluation software hand you decoded readings with a timestamp and a tag identity, over MQTT, a REST call or a CSV file. Where the data goes after that is your architecture. We do not sell a CMMS connector, and we would be suspicious of anyone who did, because the last mile depends entirely on the system you run.
In practice the last mile takes one of three shapes. Most modern maintenance platforms expose an API for creating conditions or work requests. A small service between our data and that API is a few days of work for the IT team. Older systems accept a scheduled file import, which is less elegant and often good enough. And some sites already run an IoT or historian platform with its own connector to the CMMS. In that case our job is to publish into that platform, in its schema, and stop.
Which path applies is a question for the people who run your systems, not for us. What we bring to that conversation is the four steps above, and the parts of them that battery-free changes.
A word on standards, because the question comes up. OPC UA exists precisely so that identity and meaning travel with the value, instead of being reconstructed at the far end. Whether you use it or a plain JSON message matters much less than putting the asset identity and the expected cadence in the payload at all. The message formats themselves get their own post later in the series.
What to send us
If you are scoping CMMS integration for battery-free data, three things let us answer properly in the first call. Which maintenance system you run, and whether it exposes an API or takes file imports. How an asset is identified in it, and who maintains that list. And how a work order gets created today when somebody notices something on a round. The pipeline should copy that path rather than invent a new one.
Send us those three. We will tell you where the readings will come from, what they will carry, and where our part stops and yours starts. Talk to our engineering team.
Next week: sealed, inaccessible and mission-critical all at once, and what that category really looks like.