IoT / Foundation

Give different devices a shared business language.

Use properties, events, and actions to connect device semantics with product definitions, data interpretation, control parameters, and business interfaces.

THE CUSTOMER PROBLEM

Start with the connectivity management problem.

Two vendors may both report temperature while using different field names, units, precision, and read/write behavior. Carrying those differences into every page and statistic creates repeated integration work. A thing model gives these agreements a reusable home.

MECHANISM / REASON / TRADE-OFF

See how the capability works through the interface.

01

From shared definitions to individual devices

Common, category, product, and device levels serve different reuse scopes. A product model groups properties, events, and actions; configure device-specific differences through the supported model mechanisms.

Choice and trade-off
Before changing a model, check existing telemetry, historical fields, and consumers. Changes are not automatically backward compatible.
02

Properties, events, and actions mean different things

Properties describe state and values, events record occurrences, and actions describe callable capabilities. Identifiers, types, units, and access constraints form the device contract.

Choice and trade-off
A thing model describes device business semantics; it is not an entity knowledge graph or an ontology reasoning engine.
03

Models take part in data and control workflows

Message parsing, parameter validation, historical data, and visualization bindings work around model definitions. Business tools still use real interfaces to read or control devices.

Choice and trade-off
Bindings still need field, unit, and source checks. A model does not generate a complete industry application by itself.
Product thing-model property editorA historical editor from the documentation site (legacy iThings branding), used to explain type, access, and unit settings; not a screenshot of the current release.

A CONCRETE EXAMPLE / MECHANISM EXAMPLE

One temperature property used in several places

A field-mapping example, not measured device data. Map the source field, standard identifier, data type, and display unit explicitly.

  1. Confirm the unit and scaling rule for source field t
  2. Define the type, unit, and access range for temperature
  3. Reuse that meaning in history charts, business pages, and query tools

READY TO INTEGRATE

Confirm these points before connecting.

IoT SIM guide ↗
  • Definitions must match the device capabilities
  • Set read/write limits; do not treat read-only properties as controls
  • Check historical data and existing pages before model changes