Wrong times and gaps

This page helps when readings appear at the wrong time, disappear because of their time stamp, or when a chart shows gaps, flat lines or less detail than you expect. Most of these problems come from the device’s clock, from the form of the time stamp, or from how long windows are read.

Readings at the wrong time

Symptom	Cause	Fix
Readings are hours off	The device sends `ts` in local time	`ts` is milliseconds since 1970 in UTC. Send UTC, or send flat objects without `ts` and let Hermetry stamp the arrival time.
Readings are in 1970, or refused	The device sends `ts` in seconds	Multiply by 1,000, or leave `ts` out
Readings drift a little more every day	The device clock is not synchronised	Use NTP, or leave `ts` out
All readings of a batch have the same time	The device stamps the send time, not the measuring time	Stamp each record when it is measured
The Telemetry tab’s Updated time is old although the device reports	The device sends an old or fixed `ts`	Send the measuring time; check the clock after a battery change

Everything is stored in UTC. The console, dashboards and exports show times in the viewer’s time zone (set under My Profile). Two people in different zones see the same reading at different clock times.

Rule of thumb: send ts only when the device’s clock is synchronised. A device without a reliable clock should send flat objects.

Readings refused for their time

Code	When	Fix
`bad_ts`	`ts` is not an integer of epoch milliseconds	Fix the form
`bad_ts`	More than 10 minutes in the future when it arrives	Fix the clock. Administrators can change Future timestamp tolerance (minutes) (1 to 1,440) under Settings > Telemetry.
`bad_ts`	Older than Oldest accepted reading (days) (0 = any age, the default)	Expected when that setting is used to stop very old replays
`too_old`	Older than your retention class keeps raw readings	Cannot be changed by a setting. See the table below.

Retention class	Readings older than this are refused
7 days	7 days
30 days	7 days
90 days	30 days
365 days	90 days
1,095 days	90 days

The run records of the root flow show these codes. See Timestamps, late and duplicate readings.

Readings sent after an outage

What you see	Why
Buffered readings appear in the history but the latest value did not change	Older readings never replace a newer latest value
Alarms opened from the buffered data are marked Backfilled, and nobody was told	Alarm rules evaluate late readings as backfill: the history is complete, nobody is paged for the past
Some buffered readings are missing	They were older than the raw window (`too_old`), or the replay was faster than the profile’s Replay messages per second
A flow that forwards data did not send the backlog	Messages processed more than 5 minutes late are marked late; blocks that act outside the platform skip them unless their late setting is `send`

Duplicates and corrections

Symptom	Cause
A reading sent twice is stored once	Expected: the same values at the same time for the same device are stored once
A corrected value does not show	It was sent with the same `ts` as the original. The latest value keeps the first one it saw for that time stamp. Send the correction with a new `ts`.
The same value twice without `ts` is stored twice	Without `ts` or a message id, two sends are two readings

Gaps on charts

Symptom	Cause	Fix
No data for this period	The device sent nothing in the window, or the key is misspelled	Check the device’s Telemetry tab; pick a longer window
A text or true/false key draws nothing	Only numbers have a chart history; text and booleans have no summaries	Store a numeric copy (for example `door_open` as 0/1). See Numbers, text and true/false values.
A gap where the device was offline	No readings were stored	Expected. Buffer on the device and send with `ts` after the outage.
Older parts of a long window are empty	The window reaches past what is kept: raw readings 7 to 90 days, minute summaries at most 31 days	Use a coarser interval (hour or day) for long windows. See How long data is kept.
An API request answers `400 range_too_large`	More than 10,000 buckets at the chosen resolution	Ask for a coarser bucket or a shorter window

Smoothed or flat lines

Symptom	Cause
A long window looks smoother than the last day	Windows longer than 24 hours read minute, hour or day summaries instead of every reading
Peaks disappear on a long window	The aggregate is `avg`. Use `max` to keep peaks, `min` for dips.
A counter (kWh, m³) shows a rising line instead of consumption	Use the aggregate `increase`; a drop is taken as a counter restart
A daily figure does not match your local day	Day summaries run midnight to midnight UTC. For local days, read hourly figures and add them up by local day. See Aggregates and rollups.
A fresh reading is missing from a long-window chart	Summaries are filled every minute; wait a minute or two

Schedules at the wrong hour

Where	Time zone used
A flow’s Schedule block	Its tz setting; empty uses the organisation’s default zone
A Rules-card time trigger	The organisation’s time zone
A Rules-card time window	The place’s time zone
Sunrise and sunset	The place’s location

See Time, sunrise/sunset, dates and holidays and Locations and time zones.