Meter Readings

A meter is a counter on an asset that measures how hard it has worked: engine hours on a forklift, kilometers on a truck, press cycles on a stamp, motor revolutions on a spindle. Meters are how Beelocity translates usage into a maintenance trigger — a forklift due for a service every 250 hours can only know it’s due when the hour counter has accumulated 250 hours since the last service.

How readings get into the system

You can record a reading from several places:

• Mobile scan — operator scans the asset’s QR code, types the counter value.
• Manual entry — from the Meter Readings page, click Record, pick the asset (the unit is prefilled from the asset’s meter configuration), type the counter value, optionally flag rollover or reset, and save. The form posts to /meter-readings/record, which runs the cumulative/monotonicity logic and fires the plan-trigger check on the spot.
• Bulk import — CSV upload at month-end, especially common when a PLC exports counts to a spreadsheet.
• API — direct push from a PLC integration or IoT gateway.
• Work-order close — a reading entered while a work order is open is tagged with the Work order source. This is just a label on a reading you record yourself; closing a work order does not automatically capture a counter value for you.

Each reading captures the value, the unit, who recorded it, when, and the source.

The first cumulative reading you record for an asset sets that asset’s meter unit automatically (if it didn’t already have one). After that, every cumulative reading for the asset must use the same unit — a reading in a different unit is rejected so the counter history never mixes, say, kilometres with miles.

Cumulative vs condition readings

There are two kinds of reading:

• Cumulative — counters that only grow. The asset header carries a denormalized cumulative value that the plan scheduler reads. Rollovers (the counter wraps) and resets (the sensor is replaced) are absorbed in the log so the cumulative stays monotonic and the lifetime hours don’t lose history when a sensor swaps.
• Condition — sensor measurements that move in either direction: vibration RMS, oil acidity, bearing temperature. These don’t update the cumulative; they feed condition-based plan triggers (replace the bearing when vibration exceeds 8 mm/s sustained over five readings).

Rollovers and resets

When a 6-digit odometer rolls from 999 999 to 000 000, the operator flags the reading as a rollover and the system computes the wrap delta against the asset’s counter_max_value. When a sensor is replaced, the operator flags the reading as a reset and supplies the new sensor’s starting value (often zero). Subsequent readings track against the new baseline, and the asset’s lifetime hours don’t lose history.

The system never auto-detects a rollover from a downward raw value — too many false positives from typos. A downward reading without is_rollover = true is rejected and the operator is prompted to clarify (rollover, reset, or typo).

Corrections

Made a typo? File a correction: a new reading that points at the one being superseded. The original stays in the log for audit; the cumulative is re-walked forward from the correction point. Affected open work orders get a “meter correction followed” flag so the planner can decide whether to reopen them, and the correction re-checks the asset’s meter-based plans against the corrected value so any maintenance that should now be due is re-evaluated.

The plan-trigger hook

After every successful reading, the system synchronously checks the asset’s active meter-based plans. If the new cumulative has crossed a plan’s next-due threshold, a work order is materialized within milliseconds — no waiting for the next hourly tick.

Bulk imports defer the check to a per-asset background job to avoid overhead from triggering hundreds of times in a single ingest.

End-of-day fleet log

Two common bulk patterns are built in:

• End-of-day fleet log — a forklift coordinator types every truck’s hour meter at shift end. The grid shows one row per truck; one button posts the batch. Each batch gets an import_batch_id so the readings can be located together.
• Monthly CSV import — upload a PLC export; the system validates monotonicity per row, surfaces any rejects, and inserts the accepted rows. A reading is treated as a duplicate when another reading already exists for the same asset, unit, timestamp, and source — so re-uploading the same file (or re-typing a reading you already entered) is a no-op rather than a double entry.