A sensor reading on a screen looks like a fact: a temperature, a fuel level, a door that is closed. Behind each figure sits a chain of hardware, wiring, radio coverage and software, and any link in that chain can produce a number that is wrong, out of date or meaningless. Every decision, alert and report built on those numbers inherits the problem.
Trustworthy sensor data depends on knowing what a raw value actually means, being honest about data that is missing or old, and raising alarms only when something has really happened. This explainer uses LIOMO Fleet, our fleet platform, as a worked example. The same principles apply to sensors in fields, cold rooms, grain stores and buildings.
Missing data is not zero
When a sensor is unplugged or failing, it does not always go quiet. It may keep sending a value that means, in effect, "nothing to say". If software treats that value as a real measurement, a chart shows a sudden plunge or spike, an average is dragged off course and an alert may fire for a problem that does not exist.
LIOMO Fleet handles this explicitly. When a sensor sends its "nothing to say" value, the platform shows "No signal" instead of a figure. Those moments are left out of charts and out of the minimum, maximum and average, so there are no false spikes: the line runs straight from the reading before the gap to the reading after it.
The general rule for any sensor system: define which raw values mean "no data", and never store or display them as if they were measurements.
Old data should say how old it is
A reading can be accurate and still misleading if it is out of date. Trackers and battery-powered sensors sleep to save power, and vehicles pass through areas without mobile coverage. The last value received may describe the situation an hour ago, not now.
In LIOMO Fleet, any reading older than 15 minutes is labelled with its age, for example "3 h ago", because the tracker may be asleep or out of coverage. The value stays visible, since it is still useful, but nobody mistakes it for a live one.
Coverage gaps also affect the history. Readings are judged as they happen, and data that a tracker sends after a coverage gap is stored, so the record of what happened is complete once the vehicle is back in range.
Calibration turns a signal into a quantity
Many sensors do not measure the thing you care about directly. A fuel-level sensor does not report litres by itself. Tanks are rarely simple shapes, so the same change in the sensor reading can mean quite different volumes near the top, middle and bottom of a tank.
This is why LIOMO Fleet fuel sensors are calibrated. When the sensor is fitted, the tank is measured, and litres are worked out from that calibration. The platform is open about where this applies and where it does not:
- Readings from a sensor that has not been calibrated are labelled "Not calibrated".
- Readings outside the calibrated range are labelled as such, so users know the figure lies beyond what was measured at fitting.
- Fuel charts average the points within each stretch of time: 10 minutes on the 24-hour view, 1 hour on the 7-day view and 4 hours on the 30-day view, which keeps each view readable.
The same principle applies to soil moisture probes, tank-level sensors on farms and flow meters in buildings. A raw signal becomes a quantity only through calibration, and the system should make it obvious when that step is missing.
Alarms that wait for a real problem
An alert that fires too often is soon ignored. The most common cause is reacting to a single reading. When the door of a refrigerated vehicle is opened for a delivery, warm air comes in, and the temperature may briefly cross its limit before recovering once the door is closed. That is normal operation, not an incident.
LIOMO Fleet raises a temperature or humidity alert only after the reading has stayed outside its limits for 10 minutes, so a door opened for a delivery does not trigger it. The alert is then raised again only after the reading has returned inside its limits and left them once more.
Questions to ask of any sensor system
Whether the sensors sit in vehicles, greenhouses, cold stores or plant rooms, the same questions separate data you can act on from data you have to double-check:
- How does it show a sensor that is disconnected or failing, and is that value kept out of charts and averages?
- Does every reading carry its time, and does the display make old readings obvious?
- Which sensors need calibration, who performs it, and what is shown before it is done?
- How long must a condition last before an alert is raised, and when is it raised again?
- What happens to data that arrives late, after a gap in coverage?
A LIOMO IoT project can include sensor selection, installation coordination, connectivity and the software rules that decide what each reading means, so that the numbers people see are numbers they can rely on.