Decimal values from meter become unprecise when being sent to mqtt

[gr8bit]

Software: vzlogger v0.8.1 based on heads/master-0-g27eb8d1566 from Wed, 28 Sep 2022 16:27:45 +0200
Device: Energy meter via IR D0

When reading absolute counter values from my energy meter, they are being transmitted correctly as the debug mode shows. When they're submitted to mqtt though, they seem to get the "float inaccuracy treatment" and are sometimes sent with lots of digits after the comma:

As 37298.16 represented in double float is 37298.160000000003492459654808 (which matches the digits shown above), is there any configuration I can use to prevent this from happening? Like setting the maximum precision on the channel (which I know is 2 digits)?

Edit:
I followed the code to this line which renders the value vor MQTT publish:

vzlogger/src/mqtt.cpp

Line 303 in 76e868f

json_object_object_add(payload_obj, "value", json_object_new_double(rds.value()));

The publish() method gets the channel struct already, so adding a scale or precision option to the channel configuration and then applying that in the above line (using json_object_new_double_s) might be a possibility. What do you think?

[r00t-]

the debug output actually forces two digits of precision:

vzlogger/src/threads.cpp

Line 87 in 76e868f

print(log_debug, "Reading: id=%s/%s value=%.2f ts=%lld", mtr->name(),

the influxdb api forces six digits:

vzlogger/src/api/InfluxDB.cpp

Line 301 in 76e868f

value_str << " value=" << std::fixed << std::setprecision(6) << it->value();

mysmartgrid seems to only deal with integers:

vzlogger/src/api/MySmartGrid.cpp

Line 525 in 76e868f

json_object_array_add(json_tuple, json_object_new_int(value - _first_counter));

only the volkszaehler api seems to not limit the precision (like mqtt):

vzlogger/src/api/Volkszaehler.cpp

Line 242 in 76e868f

json_object_array_add(json_tuple, json_object_new_double(it->value()));

[r00t-]

i very much dislike the wording of the ticket title, the numbers are not "imprecise", rather, too much precision is used in the binary->decimal conversion.
the causes are descibed here: https://en.wikipedia.org/wiki/Floating-point_arithmetic#Representable_numbers,_conversion_and_rounding
but i'm still not sure what the correct term for the effect is. "quantization error" is my best guess so far.

[r00t-]

note that a very related floating-point related issue is discussed here:
#500