Telemetry

1. Start the SDK: your app creates IoTConnectSDK(UniqueId, SdkOptions) and the SDK connects the device.

2. Sync: the SDK sends the Hello message (mt 200) and then asks for the template attributes (mt 201).

3. Attributes arrive: the response lists every attribute with its local name (ln), data type (dt) and validation rule (dv). The Hello response also carries the Data Frequency (df) and the rpt and flt topics.

4. Ready: the SDK calls your onReady() callback. Only start sending data after this.

5. Send: your app calls SendData() with a list of objects, each with a time and a data JSON object.

6. Check: the SDK checks every value against its attribute. A value of the right type that passes the validation rule is Reporting data. A value of the wrong type, a value outside the rule, or a key with no matching attribute is Faulty data. A call made sooner than the Data Frequency after the last accepted one is skipped.

7. Reporting message: the valid values are published on the rpt topic.

8. Faulty message: if any values failed, they are published in a second message, with the same shape, on the flt topic.

9. Reporting data in /IOTCONNECT™: it appears on the device’s Live Data tab, is checked by the rule engine, and is stored.

10. Faulty data: it is kept apart as faulty data. It does not appear as normal telemetry and is never evaluated by rules.

11. Result: SendData() returns True when the message was published. If the device is offline, the SDK saves the message to offline storage and publishes it when the connection comes back.

Per value, not per message: one SendData() call can produce both a Reporting and a Faulty message. A wrong value only moves that one value to Faulty; the rest of the object is still reported.

Names must match exactly: the key in your JSON must be the attribute’s Local Name, with the same case. A key with no attribute is sent to Faulty with its value unchanged.

Nested objects: for an OBJECT attribute, each child key is checked against the child attributes. Failed or unknown children go to Faulty under the same parent name.

Number strings are converted: for INTEGER, LONG and DECIMAL attributes the SDK converts number strings such as "25" to numbers, and the converted number is what gets reported.

Turning the checks off: with "skipValidation": True in the SDK options, the SDK does not check types or rules, and every value whose key matches an attribute is reported. Keys with no attribute are still sent to Faulty.

Edge devices: on a template with Edge enabled the SDK aggregates numeric values and publishes them on the erpt topic instead. See D2C Messages.

Telemetry View: Displays the latest values for each attribute in a structured list format. Values update in real time as new messages arrive from the device. Ideal for quick status checks and monitoring current device state.

Graph View: Renders numeric attribute values as time-series line charts. Select one or more attributes to visualize trends over configurable time windows. Useful for spotting patterns, anomalies, and correlations between sensor readings.

Tabular View: Shows telemetry history as a paginated data table with timestamp, attribute name, and value columns. Supports filtering by date range and attribute. Best for detailed data inspection and export.

1. Open the template: go to Devices → Templates and click the template your device uses.

2. Set the Data Frequency: on the Properties tab, set Data Frequency (In Seconds). The SDK accepts at most one SendData() call per this interval and skips calls that come sooner, so send no faster than this value.

3. Add one attribute per key: on the Attributes tab, add an attribute for every key in your data object. The Local Name must be exactly the JSON key, for example temperature. Use Display Name, Unit and Color Code to control how it looks on Live Data and dashboards.

4. Choose the data type: pick the Data Type that matches the JSON value you send. Use the table below; a mismatch makes every value of that attribute Faulty.

5. Add nested values as an OBJECT: for a nested JSON object such as "gyroscope": {"x": 1.2}, create an OBJECT attribute named gyroscope and add a child attribute for each key inside it.

6. Add a validation rule (optional): if the attribute has a validation rule, the SDK receives it as dv and treats values outside it as Faulty. A rule is a comma-separated list of allowed values and ranges, for example 10 to 50, 0 to 100,255 or red,green,blue.

7. Save: save the attributes. A connected SDK receives an attribute change command and syncs the attributes again on its own; if you don’t see the change, restart the device app.

Ready: with "IsDebug": True the SDK prints Atrributes Get Successfully (spelled this way in the SDK) when the attributes are synced, and your onReady callback runs.

Split: on every accepted call the SDK prints the two messages it built, as rtp: (Reporting) and flt: (Faulty). A value you expected to see in Reporting but find in Faulty points to a name, type or rule mismatch.

Publish: Publish data sucessfully... means the broker accepted the message, and the sample prints Data Publish Success.

1. Open the device: go to Devices → Device, click the device’s Unique ID, and open the Live Data tab.

2. Telemetry view: check that every attribute shows its latest value and updates about once per Data Frequency.

3. Graph view: select numeric attributes (INTEGER, LONG, DECIMAL) to see them as time-series lines. The attribute’s Color Code and Unit are used here.

4. Tabular view: check the timestamps. They come from the time you passed, so a wrong clock or time zone on the device shows up here.

5. Look for gaps: an attribute that never gets a value on Live Data is being sent as Faulty data (or not sent at all). Compare its key, type and rule with the template.

6. Inspect Faulty data: Faulty data is not shown as telemetry. To keep and inspect it, turn on a connector and select the Faulty data type. See Connectors.