ThingIO — telemetry, twins, and attributes¶
ThingIO is the operational data view for devices visible to the selected account. Its three work areas are Telemetry, Digital twins, and Attributes.
Query telemetry¶
Use Telemetry to query readings by thing, scope, and time range. A query returns the timestamp, thing, account/scope context, and payload for each reading.
A query covers the last 24 hours unless you give it a range, and it only ever covers the account you are working in. Narrow the time range, or target one thing or one scope, if the result set is too broad.
Readings come back newest first. Three things about a result are worth knowing before you read it as a total:
A page is never cut in the middle of one device’s readings at a single instant, so a page can hold slightly more rows than you asked for — that is the whole group of readings that arrived together, not a fault.
Asking for more rows than a single query may return, or for a time range that is too wide, is refused with a message. It is never answered with a quietly smaller page.
The rows you receive are one page of the matching readings, not a count of them. If the set is too broad, narrow the time range or the target.
If you need readings from a very wide window, query it in several narrower ranges rather than treating one wide result as complete.
A reading also records which app on the device produced it, when the device reports one. That is what lets you share one app’s data with its publisher without sharing the rest of the machine — see Sharing device data with another account.
ThingIO is the query surface; ingestion adapters and normalized streams are managed in ThingFeed.
Work with digital twins¶
A digital twin separates desired state (what the account wants) from reported state (what the device last reported). Each side has an independent version and update time.
Inspect both sides before changing desired state.
Apply a JSON merge patch to desired state. ThingIO includes the expected version so concurrent edits fail instead of silently overwriting one another.
Use Version history to see who changed the twin and what changed.
If a write reports a version conflict, reload the twin, review the newer state, and apply the change again against the new version.
Work with attributes¶
Attributes are divided into three buckets:
SERVER — written by an authorized server-side user or workload.
SHARED — account-managed values shared with the device.
CLIENT — reported by the device and read-only in the console.
You can create, update, and delete SERVER or SHARED attributes. Review Attribute audit for the previous value, new value, actor, source, and version. CLIENT attributes cannot be changed from the console.
Note
Scopes and cross-account visibility are managed in ThingHub. Pipelines and rules are managed in ThingLogic. ThingIO does not duplicate either function.