Readings

What happens to a reading¶

A reading is one value of a measurement at one time. A sensor sends readings over HTTPS, up to 500 in a call (the sensor endpoint); for each one, in order:

1. Its time is the sensor's. at is what the reading is stored, charted and judged by; when it arrived is kept beside it. A reading stamped more than ten minutes ahead is refused — the sensor's clock is wrong — and one older than the enterprise keeps readings is refused too.
2. Each reading is received once. The same sensor and the same at again is already received and changes nothing, so a sensor may safely send a batch again.
3. A late reading is welcome. A backlog an hour old lands in its own hour and day of history; it never moves the asset's latest values backwards.
4. Rules judge it as it is stored — a limit is checked in the same request (Rules). A rule judges forward only: a reading older than the last it judged for that sensor is stored, but opens, extends or closes nothing.
5. The live layer takes the newest value of each measurement, per asset, in one write at most every 30 seconds on Haiyz Cloud — the refresh floor — so it is on a dashboard about a minute after it was sent.

Alert state¶

What an asset's readings say now, set by the platform, never by a person — the live layer's alert_state:

Value	Shown as	When
normal	Normal	a switched-on sensor of the asset has reported
alerting	Alerting	an event of a rule on its readings — a limit or a zone — is open
stale	Stale	a switched-on sensor has readings, the newest older than the class expects
none	None	nothing reports on it: no sensor, none switched on, or none has sent anything

When two apply, the order is stale, then alerting, then normal, then none: a quiet sensor wins over an open crossing, which stays open and counted in open_events, and the asset reads Alerting again once its sensor reports. A person's service status is a different column on a different layer.

Stale¶

A sensor is stale when it is switched on, has sent readings, and the newest of them — by its own time — is older than its class's Readings expected every. The platform looks every five minutes. An asset is stale while any of its switched-on sensors is; a sensor that reports again is cleared with that reading, not five minutes later. A sensor that has never sent anything is not stale: its asset reads None.

A sensor going quiet is told to people only through a rule on A sensor goes quiet. Without one it reads Stale on its page, its asset's, the live layer and the dashboards, and nobody is messaged.

History and charts¶

The asset's page › Readings: the latest values, and a chart per measurement with a line per sensor, over a period — the last 24 hours, 7, 30, 90 or 365 days. A short period draws every reading; a longer one the average of each hour, then of each day; the note under the period says which. A yes/no measurement draws each hour's or day's last value.

• Hours and days are Riyadh's (UTC+3, no daylight saving) — the same days a dashboard's charts use. A single reading is shown in your own time.
• Events are marked on the charts: a band from an event's start to its clear — to the chart's end while it is open — with the rule and the worst value when you point inside it.
• The sensor's page has the same charts for that sensor alone; a dashboard's Readings series widget draws one sensor, or every sensor of a class, with a statistic for each hour or day — last, mean, minimum, maximum, sum, count or median. A median needs every reading, so it reaches only as far back as readings are kept one by one. A class with more than 20 sensors is drawn as three lines instead of one each: the lowest, the average and the highest of all its sensors, hour by hour or day by day.

How long readings are kept¶

What	Kept
Each reading	the enterprise's retention — on Haiyz Cloud the tier's (Pro 30 days, Max 90 days); on a self-hosted instance its own setting (365 days unless changed)
Each hour's count, minimum, maximum, sum and last	90 days
Each day's	until the sensor, its class or the enterprise is deleted
The readings an event keeps	as long as the event is kept — see Events

A reading with a position can be personal data; it goes with the retention, with its sensor and with the enterprise.