https://www.umh.app logo
Join Discord
Powered by
Sparkplug B input datatype handling
# umh-support
p
I’m using the Sparkplug B input plugin and I have a question about datatype handling. My NBIRTH message contains datatype and name information, my NDATA message does not (only contains the minimal alias, no name, no datatype). the bridge seems to process the sparkplug B messages almost ok, but there is some problems: alias resolving is mostly fine (apart from the first messages after startin-up), But the conversion of the value is not ok. In the Topic Browser, when i look at the meta data, I do not see spb_datatype. Is spb_datatype supposed to be present on NDATA messages, or is it sufficient if present in the NBIRTH message? Seems strange that alias resolving does seem to work, value resolving is not.
j
@Aaron
a
Hi @pascaldesmet. that is indeed an issue in our benthos implementation. Thanks for pointing it out. As far as I know spb_datatype shouldn't be present in NDATA but just in NBIRTH so your setup is right. I am now implementing a fix to enable our Sparkplug B input plugin to resolve the values.
p
@Aaron ok, thanks for the confirmation. I checked the code in the meantime and as far as I understood, for now the implementation solely relies on the protobuf type and doesn't take the sparkplug datatype into account, am i right?
Some extra context about the failing value conversion: BIRTH snippet:
Copy code
{
      "name": "asset/subasset/Driver/Actual_Torque",
      "alias": "463",
      "timestamp": "1781015531863",
      "datatype": 3,
      "metadata": {
        "meta": {
          "timestampNs": 891576,
          "seq": 23231,
          "txstate": "TRACE"
        }
      },
      "intValue": 4294967294
    } `
DATA snippet:
Copy code
{
  "alias": {
    "low": 463,
    "high": 0,
    "unsigned": true
  },
  "timestamp": {
    "low": -1396398977,
    "high": 414,
    "unsigned": true
  },
  "metadata": {},
  "intValue": 4294967293
}
Expected value: -2
a
Yes exactly. The implementation does not save the spb_datatype and thus does not take it into account. I could reproduce the failing value conversion with unsigned int32 as well
We fixed the issue in this PR https://github.com/united-manufacturing-hub/benthos-umh/pull/368. It is currently being merged into staging and should be in the release next week
6 Views
PreviousNext
Powered by