Device Telemetry - IoT Lens

Device Telemetry

There are many uses cases (such as industrial IoT) where the value for IoT is in collecting telemetry on how a machine is performing. For example, this data can be used to enable predictive maintenance, preventing costly unforeseen equipment failures. Telemetry must be collected from the machine and uploaded to an IoT application. Another benefit of sending telemetry is the ability of your cloud applications to use this data for analysis and to interpret optimizations that can be made to your firmware over time.

Telemetry data is read-only that is collected and transmitted to the IoT application. Since telemetry data is passive, ensure the MQTT topic for telemetry messages does not overlap with any topics that relate to IoT commands. For example, a telemetry topic could be data/device/sensortype where any MQTT topic that begins with “data” is considered a telemetry topic.

From a logical perspective, we have defined several scenarios for capturing and interacting with device data telemetry.

Figure 2: Options for capturing telemetry

  1. One publishing topic and one subscriber. For example, a smart light bulb that publishes its brightness level to a single topic where only a single application can subscribe.

  2. One publishing topic with variables and one subscriber. For example, a collection of smart bulbs publishing their brightness on similar but unique topics. Each subscriber can listen to a unique publish message.

  3. Single publishing topic and multiple subscribers. In this case, a light sensor that publishes its values to a topic that all the light bulbs in a house subscribe to.

  4. Multiple publishing topics and a single subscriber. For example, a collection of light bulbs with motion sensors. The smart home system subscribes to all of the light bulb topics, inclusive of motion sensors, and creates a composite view of brightness and motion sensor data.