This page helps when a device is connected (or its gateway is) but its readings do not appear on its Telemetry tab, or only some of them do. If the device does not connect at all, start with A device does not connect.
How a reading is stored
Device → broker or HTTP API (rate limits, size, quarantine)
→ the device's root flow (profile root, or the organisation's root)
→ Alarm rules → Save telemetry (key rules, time rules, key cap)
→ the telemetry store → Telemetry tab, dashboards, APIA reading can be lost at each step. The checks below follow that order.
Nothing at all is stored
| Check | How | Fix |
|---|---|---|
| The device is not quarantined | The device list shows Quarantined | A quarantined device connects, but its telemetry and attributes are acknowledged and dropped until an administrator selects Activate. See Quarantine. |
| The device is not disabled | Device page | Enable it |
| It publishes to the right topic | The device’s Log tab; the topic reference | Telemetry goes to v1/telemetry (or your profile’s custom topics). An unknown topic under v1/ is rejected as unknown_reserved_topic. See MQTT topics and payload reference. |
| A root flow is running on the IoT host | Automation, filter IoT | A root must be Running. A banner “No worker is running the IoT host right now…” means processing is down: contact support. |
| The emergency stop is off | Automation banner “Emergency stop: n flows are paused…” | Resume the flows |
| The device’s profile has its own root | The flow list shows Root badges with the profile’s name | That root, not the organisation’s, handles the device: it must contain Save telemetry |
| Messages reach Save telemetry | The root’s Activity panel: Debug, Errors, the message counts on the wires | Fix the path; keep Alarm rules, Save telemetry and Save client attributes on it |
| IoT automation is available to your organisation | Without it, no device data is stored | Contact support |
See Hosts, the root flow and profile root flows.
Some keys or some readings are missing
Save telemetry reports why it left a value out. Open the root flow’s Activity > Runs or Errors:
| Code | Cause | Fix |
|---|---|---|
key_invalid | A character outside A–Z a–z 0–9 _ . -, or an empty key | Rename the key on the device or in the flow |
key_too_long | Over 64 characters, also after a topic prefix | Shorter keys |
key_reserved | Starts with _, fw_, current_fw_ or cfg. | These prefixes belong to attributes and the platform. See Reserved keys and attributes. |
string_too_long | Text over 1,024 characters | Send a shorter text, or store it as an attribute |
value_too_large | JSON over 4 KiB, raw over its cap, or a number that is not finite (NaN, Infinity) | Split the value; send numbers |
bad_form | Not a form the store reads, or more than 1,000 key-value points in one message | Send a flat object, {"ts": …, "values": {…}} or an array of those; split large batches |
bad_ts | A time stamp not in epoch milliseconds, more than 10 minutes in the future, or older than Oldest accepted reading (days) | See Wrong times and gaps |
too_old | Older than your retention class keeps raw data (7 to 90 days) | Send buffered data sooner |
key_limit | A new key over your plan’s telemetry key cap (250, 400 or 2,050 by tier) | Drop unneeded keys before Save telemetry, or change the plan |
no_values | Nothing in the record could be stored | See the codes of its values |
The rest of the message is still stored when one key is refused.
The payload is not what Hermetry expects
| Symptom | Cause |
|---|---|
Everything is stored under one key raw | The body is not a JSON object (binary, plain text, a scalar or array on a custom topic). Decode it in the root flow, use a LoRaWAN codec, or send JSON. |
| A number is listed as Text | The device sends it in quotes ("21.5"). Send a number, or convert with number(...) in a Calculate block. |
| Values appear under a nested name | The profile’s Prefix keys with the topic stores data of a custom topic as <topic>.<key> |
| Nothing for a gateway’s child | The gateway must send v1/gw/connect for the child and use the v1/gw/telemetry form. See Devices behind a gateway. |
Messages are dropped by a limit
| Limit | Default | What happens | Where to look |
|---|---|---|---|
| Per-device telemetry messages | 10 a second and 300 a minute | Acknowledged and dropped; owners and admins get one notice per device per hour | The profile’s Limits |
| Per-device data points | 200 a second and 6,000 a minute | Same | Same |
| Per-device attribute updates | 5 a second and 60 a minute | Same | Same |
| Message size | 64 KiB | The message is dropped whole; the connection stays | The profile’s Max message payload (bytes) |
| Replayed (buffered) readings | Half the per-second telemetry count | Older records sent after an outage must fit Replay messages per second | The profile’s Limits |
| Whole organisation | 10, 15 or 70 messages a second and 6,000, 9,000 or 42,000 data points a minute, by tier | Acknowledged and dropped; HTTP answers 429 with Retry-After; one notice per hour | Plans and the IoT add-on |
| Gateway children | Per child and for the whole gateway message | A child over its own limits loses only its records (child_rate_limited) | Devices behind a gateway |
A device that keeps breaking its limit (more than three times its minute allowance dropped within a minute) has its session closed. See Device profiles.
Batch readings instead of sending one message per value: a message with 50 time-stamped records is one message.
The monthly message allowance
The monthly IoT message allowance never stops data. Past it, Hermetry keeps accepting, storing and processing your messages; the overage is billed. If data stops, look for one of the causes above, not the allowance. See Message quota and usage.
It is stored, but you do not see it
| Symptom | Cause |
|---|---|
| The Telemetry tab shows it, a dashboard does not | See A dashboard shows no data |
| A value card shows it, a chart says No values in this window | The key is text or true/false: those have no chart history. Store a numeric copy. See Numbers, text and true/false values. |
| A long-window chart lags by a minute or two | Windows over 24 hours read minute summaries, filled every minute |
| The latest value does not change | New readings carry an older or equal time stamp than the stored one |
By connection type
| Connection | More checks |
|---|---|
| LoRaWAN | Troubleshooting uplinks and downlinks, the Frames log and the codec |
| SNMP and other polled devices | Polling devices over SNMP: each poll writes one message; a failing device backs off |
| Device HTTP API | 400 invalid payload, 413 body too large, 429 rate limit. See Device HTTP API. |