Skip to main content
A meter counts something an asset does: running hours, kilometres, cycles. A sensor measures a condition, such as vibration or temperature. Sending readings in from a building management system, a SCADA historian or a telematics feed is how usage-based maintenance plans fall due without anybody typing a number. The examples assume a token in $TOKEN (Authentication).

Find the meter

Meters have codes, so filter by the one your system knows:
Look the id up once and keep it. It does not change.

Send a reading

The answer is the meter as it now stands, with the rate the asset is running at:
The reading brings the meter forward, and any maintenance plan whose usage has fallen due raises its work order straight away. Send the time the reading was taken as p_reading_at, if it was not taken just now. A reading dated earlier than the latest is kept in the history but does not move the meter back, so sending a backlog in any order is safe.

Readings that are refused

A meter that counts upwards cannot go down:
A counter that wraps back to zero is accepted once the meter has a rollover value. If the counter on the asset was physically replaced, the asset gets a new meter and the old one is switched off, as Meters describes. Send readings to the new meter from then on.

Read the history

Sensor readings

Find the sensor’s id from /sensors?select=id,code,name&code=eq.<code>, then send each value:
The answer says what the reading set off: alerts opened or cleared against the sensor’s thresholds, and whether it also moved a meter.