Using Runtime Telemetry API

Monitoring device telemetry

Telemetry is reported as a read-only stream on a topic beginning with dt (device telemetry). It is up to the topic's consumer to determine the most appropriate way to handle subscribing to topics. Telemetry topics follow the pattern below:

dt/[app]/[device]/[parameter-measured]

As an example, the topic below is expected to report the values of the current drawn by VFD 1:

dt/vfdctl/vfd1/amps

Defining your subscription

Scoping your subscription properly is very important and will:

• minimize extraneous client-side filtering
• minimize extraneous handling logic
• minimize network bandwidth consumption
• minimize processing latency
• minimize RAM usage in deserializers

Example scenarios

• You are creating an engineering dashboard page per device for a web app, you only care about the currently selected "vfd1" device and want to display all messages in a historian table view

dt/vfdctl/vfd1/+

• You're now on revision 2 of your engineering dashboard page and have added React components with a line chart where you want to display current draw specifically

dt/vfdtl/vfd1/amps

• You want to use ai to predict your billing costs, so you create a trend of mean current draw across all devices on the network by setting up a listener in Node Red that every minute will reset its value, sum every incoming value and at the end of the next interval divide by the number of samples received before publishing the mean on a new topic called dt/facility1/vfd/amps and inserting the data into a database
• A conveyor you are driving can bind if it gets too worn, so you implement a Node Red listener to send a text message to a technician that VFD1's conveyor needs maintenance performed before irreversible damage occurs when the value passes an alarm setpoint

dt/vfdctl/+/amps