Costs after installation
After a sensor is installed, costs begin for connectivity, batteries, calibration and site visits. Readings need to be collected and checked; faults need to be detected and repaired. Maintenance budgets and responsibilities are established before the network expands.
Imagine a park's moisture sensor
Imagine a fictional park with automated irrigation. One sensor reports almost identical moisture for several days. This might reflect stable soil, missing new measurements or device failure. If the system displays the last value as fresh, the operator sees an unjustifiably reassuring picture.
Investigation needs the latest measurement time, message-receipt time and connection state. Comparing nearby points and taking an on-site reference measurement helps. Comparison forms a hypothesis but does not replace verification: neighbouring areas may differ in shade, soil and irrigation.
Measurements must retain context
A value without units, location, time and measurement method is difficult to use. OGC SensorThings API provides a common approach to observations and metadata across heterogeneous sensor systems. A compatible interface connects devices and applications more easily but does not itself prove any reading correct.
Operation needs a register: which sensor is installed, when it was replaced and which settings applied. A replacement may have different characteristics or positioning. Without history, a jump in a chart can be mistaken for environmental change when the observation method changed instead.
Different faults need different responses
Missing messages, an unusual value and gradual measurement drift are different situations. The first suggests checking power and transmission, the second the object's actual state, and the third comparison with a reference measurement. One generic sensor-error alert hides these distinctions and complicates assignment.
Set alert thresholds around the task. Over-sensitive rules create unnecessary visits; overly tolerant ones miss important changes. During a pilot, retain trigger reasons and inspection outcomes so thresholds change through observation rather than a desire for a calmer dashboard.
A site visit includes digital completion
After replacing a battery or device, confirm restored transmission and plausible data. Visiting a location does not mean the overall service uses the correct source again. Sometimes a new record appears under another identifier while the working dashboard continues reading the old one.
Connect the physical object, device, problem and post-repair check in the work order. Plan site access, spare equipment and procedures without connectivity. These details determine servicing time more than an impressive demonstration on a supplier's desk.
A pilot should survive a fault
Before expanding the network, run an agreed test: simulate missing new data at a test point and follow detection, assignment, repair and confirmation. Measure the whole cycle, including waiting for a visit. Separately assess attention spent on false alarms and unclear messages.
