Recording a reading

A reading is a value somebody looked at and wrote down: a tank level, a temperature, a meter, a count on a shelf. It is recorded against an item, for one of its group's monitored parameters.

Recording one

1. Open the tracker group and then the item — from Tracked Groups, or from Tracked Items if you know what you are looking for.
2. The item's page lists the group's parameters. Choose the one you are recording.
3. Enter the value, and the date and time it applies to if it is not now.
4. Add a comment if the figure needs one — see below.
5. Save.

Every parameter in the group is offered against every item

Parameters belong to the group rather than to individual items, so an item may be offered readings that do not apply to it. Recording is optional per item — leave what does not apply blank. If the noise is unbearable, the real fix is two groups, not a workaround.

Recording for several items at once

Where a group has many items taking the same reading, the group's items page offers a bulk broadcast action: enter the parameter once and put a value against each item in a single pass.

This action is hidden on a group whose figures come from forms, because the picker behind it would be empty.

Comments on a figure

A reading can carry a comment, and the comment travels with the figure into the reports that show it. Use it for the thing a reader would otherwise ask about: "tank was still settling", "read after the compressor was replaced".

A comment is per reading, not per parameter

Correcting a figure and leaving its comment behind means the new figure inherits a note about the old one. If the remark no longer applies, clear it when you correct the value.

A long comment is shortened, never refused

A comment holds up to 500 characters, and so does a parameter's text value. Send a longer one — by broadcasting it, by correcting a reading, or by filling in a form field the form broadcasts as its remark — and the reading is still recorded: the note is stored cut to fit, ending in … where it was cut, so anybody reading it later can see it is not the whole remark.

The number is the same wherever the remark comes from. A remark typed into a form and the same remark broadcast land in the same place and are read on the same tooltip, the same report and the same export, so they must cut at the same length and end the same way.

Trackapt will not turn a figure away because the remark beside it ran long — a reading held back on a device underground is worse than a note missing its last sentence. If the whole remark matters, keep it short, or put the long version where long text belongs: a form field, or the report the figure appears in.

Correcting a figure a form published

A figure that came from a form submission shows on the item's readings like any other, and its value and comment can be corrected there for as long as the submission itself can be corrected. The correction is written back into the submission, so the form and the item never disagree.

Its date and period are not yours to move from there. They are the submission's: the form says which day or shift the whole document covers, and one of its figures cannot cover a different one. Try it and the change is turned away with:

This value came from a form submission, so its date and period are the submission's. Change the value here if you need to, but to move it to another date or period, edit the form entry it came from.

Nothing is changed when that happens — not the value either, so make the two changes separately. To move the figure, open the form entry it came from and correct the date there; every figure the entry published moves with it. If the entry was filed for the wrong day altogether, see Correcting by deleting.

A figure that was broadcast by hand, rather than published by a form, can still be moved to another date or period from the item's readings.

When a broadcast is turned away

The server has two different answers, and they mean different things.

One reading is refused, the rest are recorded. The period already holds a figure a form entry captured, so broadcasting over it would leave the form and the item disagreeing. The answer names the parameter, the item, the period and the form, and says what to do: edit that entry — or, where an approved entry has locked the figure, ask one of its approvers.

Nothing is recorded. The answer begins Nothing was broadcast and says which reading stopped it and why. In the app it arrives inside the notice that a sync failed — Your Broadcasts are safely saved but sync failed due to: … — because every broadcast travels through the device's queue:

Nothing was broadcast: reading 3 of 12 cannot be taken because its value is missing or is not a number. No reading in this batch was recorded, not even the ones that were fine — they are all still waiting on this device.

The sentence ends…	What it means
its value is missing or is not a number	The figure arrived blank, or as text. Trackapt does not guess a number out of "50" or "about 50".
its group / item / parameter is missing or is not a valid id	The reading does not say what it is a reading of.
its period (slot) is missing or is not text, its date is missing or is not a number	The reading does not say when it is for.
the time it was captured is in the future — check the device's clock, its date is in the future	The device's clock is more than an hour fast, or the date is one. Set the clock and send again.
the time it was captured is not a real date, its date is not a real date	The time or the period is missing, zero, or in the wrong unit.
its comment is not text, its text is not text	Something other than words was sent as the note. A note that is merely too long is never refused — see above.
its time is not in the form HH:mm	A time value must read like 06:30 or 18:05.

Trackapt's own broadcast screens and the spreadsheet upload send readings in this shape, so you should not meet the second kind from inside the app. It is the answer an integration gets when it sends something malformed, and the sentence is written for whoever has to find the bad row: it counts from 1, in the order the readings were sent.

Why the whole batch, and not just the bad reading

A request that is malformed in one place cannot be trusted in the others, and recording eleven of twelve readings leaves somebody to work out later which one is missing. Refusing the batch keeps the two states simple: all of it arrived, or none of it did. A refusal never deletes anything from a device's offline queue — the readings stay where they were taken.

Units

The unit comes from the parameter, not from you — see Parameters and units. If a unit is wrong on a reading screen, it is wrong on the parameter, and fixing it there fixes it everywhere.

What happens next

• The figure appears on the dashboard and on Supervise, live — nobody has to refresh.
• Any alert rule on that parameter is evaluated. Who hears about it is filtered by who may see the item.
• It becomes available to reports and to any computed parameter that uses it as an operand.

A missing reading is not a zero

This is the single most important thing to know about readings, and it shows up across the app:

• A maintenance service with a meter interval on an asset nobody has read shows as Unknown, not as OK. A service reported as fine when nobody knows is the more dangerous of the two errors.
• A fuel fill with no meter reading is reported as not measurable, rather than being quietly dropped from the average.
• An item property with no value is unknown, so an alert threshold that resolves to it stays silent.
• A range-based figure capped at the last date every input has figures is worked out only up to that date, and says so, rather than setting days that have figures against days that have none.

Trackapt consistently prefers saying "cannot say" to inventing a figure. When a screen tells you it could not measure something, that list is as important as the figures beside it.