FOGL-9302 Support for signed 32-bit integer values in the metric

[ashish-jabble]

No description provided.

[ashwini-k-pandey]

Do not change auto generated file, this need not be changed ..

[ashish-jabble]

This is necessary for handling signed integers. This generic MQTT SparkplugB subscriber addresses the issue for any data type, eliminating the need for ctypes

[ashwini-k-pandey]

In the implementation outlined in the DRAFT PR (accessible here), we are addressing the handling of the metric.datatype field to determine how to properly interpret the data contained in metric.int_value.

Overview of metric.datatype

The metric.datatype indicates the type of data represented by metric.int_value. This field informs the application whether the integer value should be treated as a signed or unsigned integer.

Handling of Integer Values

1. Protobuf Encoding: In Protocol Buffers (protobuf), both signed and unsigned integers are encoded as unsigned integers. This means that when we receive an integer value through the protobuf payload, it does not inherently carry information about whether it is signed or unsigned.

2. Type Casting Based on datatype:

   • The application must read the metric.datatype field to determine how to interpret the metric.int_value.
   • Based on the value of metric.datatype, we can decide if the integer should be treated as a signed integer (e.g., using ctypes.c_int) or if it should remain as an unsigned integer.

Implementation Changes in the Draft PR

• For example, if datatype indicates that the value is signed, we cast it using:

  value = ctypes.c_int(metric.int_value).value

[ashish-jabble]

To cast signed integer values in Protobuf is generally not recommended. While it might work in some cases, it's not the best or most portable approach.

a) ctypes can introduce portability issues if you're targeting environments with different architectures.

b) It also adds unnecessary overhead for simple operations, like casting or type-checking, which can be done much more directly in Python.

c) Protobuf already provides a clean and efficient way to handle integer types, including signed and unsigned integers

IMO, we should use Protobuf’s own type system and avoid unnecessary casting through ctypes.

[ashwini-k-pandey]

The solution in this pull request requires changes to the auto-generated code, which seem to introduce portability issues. I'm unsure about the specifics of the portability concerns you are pointing. Could you please point me to the relevant documentation for Protocol Buffers that explains these issues and offers a foundation for my understanding?

[firozalikhan]

It ignores the values and does not ingest anything, smaller than minimum value (-2147483648) of a signed 32-bit integer say -2147483649, and logs a message, same it does for the larger than the max value (2147483647) of a singed 32-bit integer, as expected.
Fledge mqq1[6507] WARNING: mqtt_sparkplug: mqtt_sparkplug: Ignoring metric 'Humidity Sensor' due to unknown type. Only supported types are: float, integer, string, bool.,

[ashish-jabble]

It ignores the values and does not ingest anything, smaller than minimum value (-2147483648) of a signed 32-bit integer say -2147483649, and logs a message, same it does for the larger than the max value (2147483647) of a singed 32-bit integer, as expected.
Fledge mqq1[6507] WARNING: mqtt_sparkplug: mqtt_sparkplug: Ignoring metric 'Humidity Sensor' due to unknown type. Only supported types are: float, integer, string, bool.,

That behavior is expected, as it exceeds the limit of a signed 32-bit integer, which is why the warning log is being generated.