add possibility to have a callback that take in argument the AxdrCaptures instead of the obis string and transformed value

[doreille]

Thank you for this excellent library.

It would be great if we could access the reference to the AxdrCaptures object from the "cooked_cb" callback function, or even better, if there were a "DlmsParser::parse_raw" method whose callback took only the reference to the AxdrCaptures object as an argument.

The reason is that the user may need the obis code as a binary value rather than a string, or the exact numerical value. Converting all numeric values to float32 can result in a loss of precision.

[PolarGoose]

If you need AxdrCaptures, we can just add it to the cooked_cb as an extra parameter.

Would this solve your problem?

[doreille]

Yes, that solves my problem (I’ve already done it on my local branch).

However, this generates unnecessary operations in the AxdrParser::emit_object_ method, with calls to obis_to_string, data_as_float and apply_scaler.

[PolarGoose]

ok, you don't want to pay for this extra processing. This is the issue?

[doreille]

Yes. I'm running it on a microcontroller.

[PolarGoose]

Converting all numeric values to float32 can result in a loss of precision.

@Tomer27cz, @latonita,
Guys, why do we convert to float instead of double? It is possible that some of the values in the AXDR payload are doubles:

  case DLMS_DATA_TYPE_FLOAT64: {
    if (len < 8) return 0.0f;
    const uint64_t i64 = be64(ptr);
    double d;
    std::memcpy(&d, &i64, sizeof(double));
    return static_cast<float>(d);
  }

[latonita]

We focus on MCUs and on meter units. Floats are basic types, not all mcu are good with doubles, they might need to use extra code for that.
But all in all... typically meter readings are given as integer values.
Float values are typically for the informational data like current flow/power/whatever.
So this was a design desision in the lib.
"Good enough for home automation"
Plus esphome publishing floats, not doubles.
Your thoughts?

[doreille]

I think the DLMS_DATA_TYPE_FLOAT64 type is rarely used in meters.

The issue concerns the DLMS_DATA_TYPE_INT32 and DLMS_DATA_TYPE_UINT32 types, which are the most commonly used and are converted to float. In this case, precision is lost.

case DLMS_DATA_TYPE_UINT32: return len >= 4 ? static_cast(be32(ptr)) : 0.0f;
case DLMS_DATA_TYPE_INT32: return len >= 4 ? static_cast(static_cast<int32_t>(be32(ptr))) : 0.0f;

[PolarGoose]

@doreille,

The issue concerns the DLMS_DATA_TYPE_INT32 and DLMS_DATA_TYPE_UINT32 types, which are the most commonly used and are converted to float.

But they also have a scaler, so how should we convert them properly?

[doreille]

If you want to convert a DLMS_DATA_TYPE_INT32 type associated with a scalar to a floating-point number without any loss of precision, you must use the double type.

I think the best approach is to let the user choose how they wish to convert the AxdrCapture value. Some may accept a loss of precision and also prefer to use floats for efficiency reasons, whilst others require an exact representation and will retain the integer + scalar representation.

[PolarGoose]

If you want to convert a DLMS_DATA_TYPE_INT32 type associated with a scalar to a floating-point number without any loss of precision, you must use the double type.

It doesn't help. This is why C# has Decimal. You will still lose precision when converting a number like 123.456 to double.

I think the best approach is to let the user choose how they wish to convert the AxdrCapture value.

Yes, this is a good idea. I'm working on it in the #5