Azure Digital Twins difference between properties and telemetries?-CodePudding

I'm working on an Azure Digital Twins project and I got a bit confused about my understanding of telemetry and property.

From https://github.com/Azure/opendigitaltwins-dtdl/blob/master/DTDL/v2/dtdlv2.md I get:

Telemetry describes the data emitted by any digital twin, whether the data is a regular stream of sensor readings or a computed stream of data, such as occupancy, or an occasional error or information message.

I summarize this to telemetry = data stream

and

A Property describes the read-only and read/write state of any digital twin. For example, a device serial number may be a read-only property, the desired temperature on a thermostat may be a read-write property; and the name of a room may be a read-write property.

My summery: Properties are variables of a twin with low frequency update rate that can be set from the twin and the IoT Plattform. Properties are not streaming data from sensors.

okay, if I now take these definitions and look at Microsofts Examples, like: https://docs.microsoft.com/en-us/azure/digital-twins/how-to-ingest-iot-hub-data?tabs=cli#add-a-model-and-twin and https://techcommunity.microsoft.com/t5/internet-of-things-blog/rewind-the-metaverse-with-data-history-for-azure-digital-twins/bc-p/3302065#M672 I see that Microsoft writes in the articles about telemetry data and uses streamed data, but uses in their dtdl Models "@type": "Property" only. That's inconsistent with the definition from dtdl.

Am I understanding something wrong here? Or does Microsoft examples don't follow their own definitions?

I know, that a lot of the stuff here is still in preview and under development, but I would anyway like to understand this difference.

CodePudding user response：

I wanted to start this answer with something other than "I feel your pain", but you're drawing a lot of good conclusions, so:

I feel your pain. The first link you shared is about DTDL (Digital Twins Definition Language). It's a language that's used in two places: Azure Digital Twins (ADT) and IoT Plug-and-Play (IoT PNP, a feature of Azure IoT Hub). While both utilise this language, Azure Digital Twins only uses a subset of the language and doesn't treat properties and telemetry the same. The difference is officially documented here, but I'll share the implications below.

ADT does support the telemetry feature, it doesn't store telemetry in the twin graph. So you could upload your telemetry data to ADT, but you would need to add an event listener to then pick up that very same telemetry to do anything with it. For this reason, most telemetry types of messages sent by your device will be stored in property type fields in ADT. This is also why even the Microsoft examples will store telemetry in properties.

If you would be interested in streaming telemetry through ADT, be aware that there are service rate limits in place. So in the case of high-frequency telemetry, you might want to use a different service to analyze and/or transform that data before storing it in... an ADT twin property.

The gist of it:

telemetry isn't stored in the graph, properties are.
telemetry is usually stored in property fields on your twin.
if you have high-frequency telemetry, don't stream it through ADT, transform/analyze it and store it in a property.

I should add that I love working with ADT, and I hope that the telemetry/property features will be solved in the future. But at the time of writing, store your telemetry in properties.