Describe the bug
Thingsboard's Sparkplug integration seems to treat UInt32 and UInt64 metrics the same as their signed counterparts. UInt32 does not support the full expected range 0..4294967295. A metric with datatype = 7 (UInt32) and int_value = 4294967295 shows up in the Thingsboard UI as -1. Correspondingly, a metric with datatype = 8 (UInt64) and long_value = 18446744073709551615 also shows up in the Thingsboard UI as -1.

Your Server Environment

• ThingsBoard Cloud (Europe)

Your Client Environment

I'm developing a SparkplugB edge-node implementation meant for use with Thingsboard and other compliant systems.

To Reproduce
Steps to reproduce the behavior:

1. Send an NBIRTH message containing a metric with datatype UInt32 and int_value = 4294967295, and one with datatype UInt64 and long_value = 18446744073709551615

Log output from reproduction for bug report:

Publishing to 'spBv1.0/<group id>/NBIRTH/<edge node id>' (qos=1, retain=0):
timestamp: 1773036457931
metrics {
  name: "bdSeq"
  timestamp: 1773036457782
  datatype: 8
  long_value: 3
}
metrics {
  name: "Node Control/Rebirth"
  timestamp: 1773036457931
  datatype: 11
  boolean_value: false
}
metrics {
  name: "_Test/Int32Metric"
  timestamp: 1773036457782
  datatype: 3
  int_value: 4294967295
}
metrics {
  name: "_Test/UInt32Metric"
  timestamp: 1773036457782
  datatype: 7
  int_value: 4294967295
}
metrics {
  name: "_Test/Int64Metric"
  timestamp: 1773036457782
  datatype: 4
  long_value: 18446744073709551615
}
metrics {
  name: "_Test/UInt64Metric"
  timestamp: 1773036457782
  datatype: 8
  long_value: 18446744073709551615
}
seq: 0

Expected behavior
I expect UInt32 metrics to support the range 0..4294967295, and UInt64 metrics to support the range 0..18446744073709551615.

Screenshots

Additional context

In the Protobuf schema for Payload.Metric the value field is declared as follows (irrelevant fields omitted):

    oneof value {
      uint32 int_value = 10;
      uint64 long_value = 11;
      [...]
    }

In other words int_value and long_value are both unsigned types (uint32 and uint64 respectively) and can clearly hold the full expected data ranges. Signed integer types require conversion to and from an unsigned representation in the Protobuf format. Thingsboard seems to handle this as I would expect. The problem seems to be that you apply the same conversion to metrics using unsiged types.