IoT / Foundation

A value matters only when you know when it was measured.

Distinguish latest state, historical records, and aggregates across time-series data, model units, and business definitions.

IoT SIM guide ↗Back to the foundation →

THE CUSTOMER PROBLEM

Start with the connectivity management problem.

A device can be online while its reading is stale. Summing cumulative energy directly or counting parent and child meters twice can also make a complete-looking dashboard wrong. Before data enters a business workflow, its source, time, unit, and scope need to be understood together.

MECHANISM / REASON / TRADE-OFF

See how the capability works through the interface.

Keep high-frequency history apart from business master data

Device properties and logs use time-series storage; devices, products, and projects use business storage. The TDengine path organizes device history and batch writes.

Choice and trade-off: Storage and write configuration affect available performance. Do not claim unmeasured throughput multipliers or fixed latency.

A fused device host shortens the processing path

Device management, MQTT-related processing, protocol interpretation, and time-series storage cooperate within the device host. Deployment determines direct or remote service boundaries.

Choice and trade-off: An integrated process also shares process resources; it does not mean each customer has a dedicated runtime.

Read query results with their aggregation rules

Latest values, raw records in a time range, and aggregate queries serve status, traceability, and analysis respectively. Bindings should confirm units, time windows, and device scope.

Choice and trade-off: Cumulative deltas, meter replacement, and parent-child boundaries need industry rules. Missing and stale data must remain visible.

**Industrial data overview**A public historical case interface showing data as it appeared then; it is not the query result illustrated on this page.

A CONCRETE EXAMPLE / MECHANISM EXAMPLE

Why can’t project energy use be the sum of every meter?

A metering example, with no fabricated usage. Define the time range and metering boundary before reading history under an agreed rule.

Confirm the project, time range, and valid metering points
Separate power in kW from energy in kWh and remove parent-child double counts
Check missing or stale records, then return the result with its definition

READY TO INTEGRATE

Confirm these points before connecting.

IoT SIM guide ↗

Check device clocks, units, and reporting intervals
Define query scope and industry aggregation rules
Set history retention and abnormal-data handling rules

CONTINUE WITH THE FOUNDATION

Explore more of the same foundation.

All cases →

Back to the IoT overview →