Eclipse Community Forums: Unide » Meta data for PPMP measurement messages

Help

Home

Home » Archived » Unide » Meta data for PPMP measurement messages(There seems to be something missing!)

Show: Today's Messages :: Show Polls :: Message Navigator

Meta data for PPMP measurement messages [message #1756178]

Mon, 13 March 2017 14:38

Stephen Bryant

Messages: 2
Registered: March 2017

Junior Member

Hi,

we are starting to notice that the available fields in measurement messages are not enough to correctly describe the data that is being transported. We need additional fields for things like unit, factor/gradient and offset. Such fields will need to be specified per sub-field.

My suggestion is to an optional object parallel to "series" and "limits" that is structured in the same way as "limits" and allows arbitrary key-value pairs (both strings, as with the existing meta data fields).

For example:

{
  "ts": "...",
  "series": {
    "$_time": [ ... ],
    "temperature": [ ... ]
  },
  "subfieldMetaData": {
    "temperature": {
      "unit": "Fahrenheit",
      "gradient": "1.8",
      "offset": "32"
    }
  }
}

Comments?

Report message to a moderator

Re: Meta data for PPMP measurement messages [message #1756509 is a reply to message #1756178]

Sat, 18 March 2017 08:43

Axel Meinhardt

Messages: 5
Registered: August 2016

Junior Member

I like the idea. Some objects already have the metaData attribution, but the measurement doesn't. Could we also name it metaData?
Should we than combine limits object as subfield of that or continue having at as parallel entity?

Report message to a moderator

Re: Meta data for PPMP measurement messages [message #1758578 is a reply to message #1756509]

Thu, 30 March 2017 09:27

Stephen Bryant

Messages: 2
Registered: March 2017

Junior Member

I wondered if calling it "metaData" would be a good idea or not - as the internal structure differs from other fields named "metaData". Reusing the name for a different structure would make the definition incorrect. I don't otherwise mind which name is used.

Merging limits into this might cause problems for these reasons:

1. The metaData values are all strings, but limits are explicitly numeric.
2. Moving the limits would cause incompatibility issues with the existing standard.

Personally, I would prefer the limits to remain separated, as explicit numbers. This also avoids mixing explicitly named limit fields with arbitrarily named meta data fields.

Report message to a moderator

Previous Topic:	Support for raw IO-Link process data
Next Topic:	Additional field for the device state

Goto Forum:

-=] Back to Top [=-

[ Syndicate this forum (XML) ] [

]

Current Time: Tue Apr 23 13:53:01 GMT 2024

.:: Contact :: Home ::.

Breadcrumbs

Sign up to our Newsletter