Definition
Telemetry (telemetry data) is the real-time or historical data reported by devices according to the Thing Model definition, such as temperature, humidity, power, and vibration. The platform writes telemetry data into Time Series DB, supporting real-time curves, historical queries, and trend analysis.
Use Cases
- Real-Time Monitoring: Device Monitoring displays real-time device curves
- Fault Diagnosis: Fault Diagnosis Compare curves before and after abnormal moments
- Predictive Maintenance: Predictive Maintenance Based on time series data analysis
Data Storage and Query
Telemetry Data Ingestion Time Series DB Time Series Database, indexed by device, attribute, timestamp. Supports real-time subscriptions (e.g., Event Stream Event Stream), historical range queries, aggregation statistics (max, mean, percentiles, etc.). Data retention policies are configurable; cold data can be archived to object storage, balancing query performance and storage cost.
Integration with Rule Engine
Telemetry data can trigger Rule Engine Rule Engine: for example, N consecutive temperature limit exceedances, sudden vibration amplitude changes, etc. The rule engine performs threshold evaluation or expression calculation on telemetry, triggering alarms, Webhook or Downstream Command downstream commands, enabling automated operations and predictive maintenance.
A telemetry point is a timestamped sample of a property
A telemetry point contains at least a device identity, a thing-model property, a sample time, and a value. The time the platform received it can only be the ingest time. It cannot stand in for the sample time. Backfill, an offline cache, and batch upload all separate the two times. If the curve is drawn by ingest time, history from a stoppage piles up on the second the device came back online. The type and unit of the value follow the thing model. A device must not report a number for the same property at one moment and a string explanation at the next.
Sampling may be periodic, or it may report when a change exceeds a deadband. Periodic sampling makes it easier to align several properties. Change sampling saves traffic, but quiet intervals leave gaps, and a gap is not a value of zero. Storage and charting both have to keep the information that this stretch has no point. A quality mark, such as sensor invalid, over range, or a substituted value, should be stored with the point. Writing an invalid value as zero makes rules treat a fault as a real zero and act on it. Points that need reliable delivery choose a quality of service on their own. A temperature that the next sample will cover does not all have to be acknowledged.
Set the reporting interval together with the retention policy
An interval finer than the decision the consumer needs only amplifies writes and cost. An interval longer than the fault lasts can drop the whole fault between two points, and the curve never shows it. Before fixing the interval, write down how quickly an alarm must be noticed, how fine the report must be, and how much the device link can keep sending. When the three conflict, apply a deadband or a short aggregation on the device, and have the platform keep the result that supports the finest grain that is actually required. Do not retain the raw maximum rate, unselectively, for the whole life of the data.
The retention policy is the other half of the condition for use. Hot data serves recent curves and rules. Warm data serves reviews. If older data keeps only a daily aggregate, it can no longer answer a minute-level question. Before changing the policy, tell the rules and reports that depend on the old grain. If the device clock drifts past the allowed range, the point may still be stored, but it should be marked clock-untrustworthy, so it is not ordered against the operation audit. The latest value shown in the shadow should take only the most recent valid point of each property. Do not treat the shadow as a second history store. History remains the time-series record. The shadow page is only the current snapshot.
Writing events and control receipts into the same telemetry
An event is one occurrence, such as a door opening or a fault code appearing. A control receipt is the result of a particular command. Neither is a periodic property. Forced into a telemetry table, charting draws a point at the event time that cannot be interpolated, and the aggregated mean is pulled off. Events should use the event channel. Receipts should hang off the command identifier. Telemetry keeps only quantities that can be sampled repeatedly. If the business really must make the current value of a fault code into a property, state that it is the current code and not the count of occurrences. Count and occurrence time are recorded separately.
When the same sample time is reported again with a different value, there needs to be a replacement rule. By default keep the point that arrived first and record the conflict. Do not silently let the later one overwrite, or a backfill rewrites history that was already used for an alarm. Property identifiers follow the thing model. Do not use a register address as the telemetry name. On a revision, a new property takes a new identifier. A property that is no longer used keeps its old points so they can still be read. Do not write a new unit of measure into the old identifier. When syncing to the device shadow, push only the latest valid value. One failed sync should not trigger a resend of the whole history. That turns a normal backfill into a traffic peak.
For each property, record the expected interval and the gap that is allowed. When a gap exceeds what is allowed, produce a missing mark. Do not draw a flat line by reusing the previous value. A flat line is read as a stable process. If a backfill lands inside a window that has already been aggregated, recompute that window or mark the window unfinished. Do not let the aggregate computed first stand forever for that stretch of time. After a property is retired, stop expecting new points, but a query of the old time range can still read points from before retirement. If a new point uses a retired identifier again, reject it on ingest and raise an alarm, so a new quantity with a different unit is not written into the old series. Sample time follows what the device reported. The platform must not rewrite it into receive order. Receive order is only for observing delay. It does not belong on the time axis of the curve.