aguilaaj
commented
8 years ago Thanks for the feedback, unfortunately we are marking this issue as won't fix for the time being. If you'd like to implement the changes yourself, we will happily review pull requests. In addition, please post on User Voice for others to upvote the priority of this ask.
I have a couple of observations / suggestions about the implementation of dynamic telemetry
for these I will use the following example: If we take a pressure sensor, the device will obviously send back the pressure, but there maybe some metadata (e.g. trend, tendency and sensor error state) which is not out of the ordinary considering what IoT is trying to achieve... i.e.
Telemetry [ { pressureSensor: { value:1000.00, unitOfMeasure: "mBar", TimeStamp: 2016/04/14-11:00z, metadata: { trend: 2, tendency: 3, errorState: 0 } }, pressureSensor: { value:1000.06, unitOfMeasure: "mBar", TimeStamp: 2016/04/14-11:01z, metadata: { trend: 2, tendency: 3, errorState: 0 } } } ](note that the example could be improved (pressure sensor should be of sensorType or something) and it is just to prove the following points)there are at least 2 problems with this using the current mechanism:
1) if the value being ingested is an array (within the main telemetry array) then it will just get saved to the blobs CSV as a "record" string. This causes the dashboard not to display data, not only for this device, but for any device, and even when deleting the blob, the dashboard will not work until the next hour (presumably when a new file is created).
2) metadata is just that, "metadata", and shouldn't be shown on the dashboard as it doesn't display well with the primary measurement value (unless perhaps, the value is hovered upon) there should be some way to specify which values to display, and/or which to not.
As a suggestion, it would be helpful if you could describe the best graph type for the measurement type (instead of just displaying a line graph) as an optional field, or at device start-up, as some sensors would benefit, e.g. Rain gauge / motion sensor etc. may just send back a timestamp of when the event occurred.
Also (although not directly related) the system should use a timestamp field as its primary source (rather than using the ingestion time) as if the above was solved, would allow bulk sending of point measurements.