Thingworx best practice for managing diagnostic information

[kleone]

Take the example of a device that has a temperature sensor. The temperature reading (e.g. 25 degrees Celsius) naturally fits into a Thingworx property. The status of the sensor fits into that as well (e.g. Operational, Not Operational). Let's say I have an algorithm running in the edge that periodically checks whether the temperature sensor working per its specification. This algorithm is what sets the status of the sensor. If algorithm sets the status to Not Operational, then a set of diagnostic information is collected to help understand why.

How best to use implement the edge, and model this data in the platform to manage the diagnostic information like this?

One option is to create a property called "diagnostic information" and have that information stored in a value stream. That doesn't seem to be a great fit though. This information is not what I'd typically describe as a property. And Thingworx events seem to be events that happen in the platform not in the edge (though they can be triggered by the edge.)

This seems like such a typical use case that I feel like I am overlooking something obvious.

Any tips?

[CarlesColl]

Don't think there's a best way of doing it, just how you want to implement, and for my experience having this third property to record that information will be way to go, if it's complex data you may save it as JSON property.

[PaiChung]

I would model the temperature as a property and I would model the Operational/Not Operational as an event.

each would end up in their own separate streams.

If you had to combine the data in a graph though. Sensor reading over time with state based formattting when it was in 'non operating' mode, you'll want to have two properties both to the value stream so you can record them side by side and format your graph appropriately.