[mqtt] Parsing floats with a lowercase "e" separating mantissa and exponent fails

[abbe79]

Hi,
using stable 3.3 I get following entry in my log file when my PV inverter sends really small wattage values at night:

Incoming payload '5.605193857299268e-45' not supported by type 'NumberValue'

Seems like mqtts NumberValue does not like the lowercase "e", separating mantissa and exponent.

Using an uppercase "E" (-> 5.605193857299268E-45) works.

While I could work around this using a transformation, I think others could fall in this trap too, because this is the notation that is used by C++ (and probably other languages too), see https://cplusplus.com/reference/ios/scientific/

Could this be changed to accept both notations? Thanks!

Expected Behavior

Float value 5.605193857299268e-45 should be parsed correctly to the "close to zero" value.
Using an uppercase E works as intended.

Current Behavior

Parsing fails and item is not updated. Log entry is:
2022-09-08 20:51:01.336 [WARN ] [ab.binding.mqtt.generic.ChannelState] - Incoming payload '5.605193857299268e-45' not supported by type 'NumberValue'

Possible Solution

Accept "e" and "E".

Steps to Reproduce (for Bugs)

Send 5.605193857299268e-45 to an mqtt number channel.

Context

My PV inverter sends values in this format, this is the default that C++s std::scientific uses.

Your Environment

• Version used: 3.3 stable
• Operating System and version: docker on Synology NAS

[openhab-bot]

This issue has been mentioned on openHAB Community. There might be relevant details there:

https://community.openhab.org/t/error-parsing-floats-with-negative-exponent/138746/4

[FordPrfkt]

From briefly looking at the source code, it seems that the payload is parsed as a DecimalType.
According to here: https://stackoverflow.com/questions/13925334/how-to-create-a-numberformat-in-java-that-supports-both-an-upper-case-and-a-lowe/13925393#13925393
DecimalType wants an upper case "E" as the exponent. I'll debug into it.

[FordPrfkt]

After debugging, this does not seem to be a bug in MQTT, the root cause is in the Java Number class: It wants a upper case E as the exponent, the Decimal Type extends it so it has the same behavior.
I expect this problem to exist in all bindings that deal with input data in scientific notation and do not have their own workaround, so the best way to fix it would be in the DecimalType class. (Fix would be simply calling "toUpper" on the string before parsing)

[abbe79]

Thanks @FordPrfkt for looking into this.

While I've my own workaround (regex via thing transition) running, your suggestion is probably the best way to go.

I'll create a ticket in the main repo and we'll see what the core devs think about it.

Again thank you!

[FordPrfkt]

Yes, thats probably for the best. Maybe the current behavior is intentional or changing the DecimalType breaks something else...

[jimtng]

@abbe79 have you opened an issue in the main repo about this? If so could you link it here?

[abbe79]

Hi @jimtng, thanks for the reminder, issue to be found at openhab/openhab-core#3833

[lsiepel]

The related PR to fix this issue was merged in core. It should be included in 4.1.0 milestone 3.