Most IoT systems begin by sending one kind of message: a periodic reading. It works, and it keeps working right up to the point where someone asks a question the data cannot answer — when did that valve close, why did the device restart, did the command actually arrive.
The answer is not more telemetry. It is recognising that connected devices produce several genuinely different kinds of event, each with its own delivery requirement, retention need, and consumer. Treating them all as interchangeable readings is one of the most common structural weaknesses in IoT platforms.
This guide covers the five event types that appear in every mature system, why the distinctions matter operationally, and how to design an event model that does not need rebuilding at scale.
Why Event Design Decides System Behaviour
An event model is the contract between devices and everything downstream. Get it right and new capabilities are additive. Get it wrong and every new requirement means either a firmware change or an unreliable inference from data that was never meant to answer that question.
The distinctions matter because each type has different requirements:
- Delivery guarantee. Losing one temperature sample is harmless. Losing a door-open event may be a compliance failure.
- Latency. Telemetry can batch for an hour. An alarm cannot.
- Retention. High-rate readings should be downsampled; state changes should be kept in full.
- Ordering. Some events are meaningless out of sequence.
- Consumer. Analytics, operations, and support teams each depend on different types.
A platform that treats every message identically must apply the strictest requirement to everything, which is expensive, or the loosest, which is unsafe.
The Five IoT Event Types
Telemetry — continuous measurement
Periodic readings describing a continuous quantity: temperature, pressure, current, position. High volume, individually low value, meaningful in aggregate.
- At-most-once delivery is acceptable — a lost sample is recoverable from the trend
- Batch aggressively; latency requirements are usually minutes, not seconds
- Downsample after a defined period rather than retaining full resolution forever
- This is where data reduction pays for itself
State change — a discrete transition
Something moved from one condition to another: a door opened, a pump started, a mode switched, an operator logged in. Low volume, individually high value.
- At-least-once delivery with deduplication — losing one leaves the system with a wrong model of reality
- Order matters; include a monotonic sequence number so gaps are detectable
- Retain in full — never downsample state history
- Include both the previous and the new state, so a single message is self-contained
Deriving state changes from telemetry is a persistent temptation and a persistent source of bugs, because a transition that occurs between two samples is simply invisible.
Alarm — a condition requiring response
A threshold crossed, an anomaly detected, a safety limit exceeded. Rare, urgent, and directed at a human or an automated responder.
- Highest delivery priority; send before any queued telemetry
- Model alarms as having a lifecycle — raised, acknowledged, cleared — not as isolated notifications
- Include severity and the values that triggered it, so responders need no second query
- Apply hysteresis so a value oscillating around a threshold does not generate a storm
The lifecycle point is the one most often missed. Without an explicit clear event, systems accumulate alarms that nobody can tell are still active.
Lifecycle — the device describing itself
Boot, reset cause, firmware version change, configuration applied, connectivity established or lost, battery status, self-test results. This is the device talking about its own health rather than about the world.
- Reliable delivery — these events are how fleets are diagnosed remotely
- Always include reset cause; it is frequently the only evidence of a field problem
- Route to operations and support tooling, not to product analytics
- Retain long enough to establish reliability trends across firmware versions
Teams that omit lifecycle events end up sending engineers to sites to answer questions the device could have answered itself — the difference between diagnosing a field failure remotely and guessing at it.
Command and acknowledgement — the downlink path
Instructions travelling to the device, and confirmation of what happened. The only event type that flows downward, and the one with the strictest correctness requirements.
- Every command carries a unique identifier; every acknowledgement references it
- Commands must be idempotent — retries happen, and a duplicated actuation can be dangerous
- Include an expiry, so a command delivered after a long outage does not execute out of context
- Report outcome, not just receipt: accepted, applied, rejected, or failed with a reason
The expiry rule matters more than it appears. A device that reconnects after two days and executes a queued instruction from an entirely different operational situation is a genuine safety hazard.
Requirements by Event Type
| Type | Volume | Delivery | Latency | Retention |
|---|---|---|---|---|
| Telemetry | Very high | At most once | Minutes | Downsample over time |
| State change | Low | At least once, deduplicated | Seconds | Full, indefinitely |
| Alarm | Very low | At least once, prioritised | Immediate | Full, with lifecycle |
| Lifecycle | Low | At least once | Minutes | Full, medium term |
| Command / ack | Low | Exactly-once semantics | Seconds | Full, audited |
If every message in your system has the same delivery guarantee, you are either overpaying for telemetry or under-protecting your alarms.
Designing an Event Model That Lasts
Frequently Asked Questions
Conclusion
A connected device does not produce one kind of message. It produces measurements, transitions, alarms, self-reports, and responses to instructions — and each carries different obligations about delivery, ordering, urgency, and retention.
Systems that model those types explicitly can add capabilities without touching firmware, prioritise correctly after an outage, and diagnose faults remotely. Systems that flatten everything into telemetry end up unable to answer questions that were always going to be asked.