Skip to main content


Eclipse Community Forums
Forum Search:

Search      Help    Register    Login    Home
Home » Eclipse Projects » Unide » Meta data for PPMP measurement messages(There seems to be something missing!)
Meta data for PPMP measurement messages [message #1756178] Mon, 13 March 2017 14:38 Go to next message
Stephen Bryant is currently offline Stephen BryantFriend
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?
Re: Meta data for PPMP measurement messages [message #1756509 is a reply to message #1756178] Sat, 18 March 2017 08:43 Go to previous messageGo to next message
Axel Meinhardt is currently offline Axel MeinhardtFriend
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?
Re: Meta data for PPMP measurement messages [message #1758578 is a reply to message #1756509] Thu, 30 March 2017 09:27 Go to previous message
Stephen Bryant is currently offline Stephen BryantFriend
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.
Previous Topic:Support for raw IO-Link process data
Next Topic:Additional field for the device state
Goto Forum:
  


Current Time: Wed Sep 26 10:58:09 GMT 2018

Powered by FUDForum. Page generated in 0.02191 seconds
.:: Contact :: Home ::.

Powered by: FUDforum 3.0.2.
Copyright ©2001-2010 FUDforum Bulletin Board Software

Back to the top