MQTT Binding in Paperui - lost decimal precision for generic thing number channel

Add-ons Bindings
, ,
1

Hello all,
I’ve recently gotten a ESP8266 working with a DHT22 sensor, transmitting 2 decimal-point precision temperatures (and humidities, etc) via MQTT.
The temperatures as reported by PaperUI generic MQTT Thing with a corresponding number-formatted channel gives the whole integer, not the decimal.
Looking at the generic MQTT channel format options, I don’t see any option for decimal precision. Looking online, I see ways that a text-formatted MQTT thing can have specified decimal precision.

I’m certainly not looking for two decimal points - that is within the error of the sensor, I believe, but would certainly wish for one decimal point.

When observing the MQTT channel via a command line, I can see the two-decimal point temperature data being transmitted correctly.

Is this a known issue? Do I need to make this a text-file created thing/channel and use the extra options as described here: https://www.openhab.org/addons/bindings/mqtt.generic/ ?

–
Openhab 2.4 stable, raspbian on RPi3+ (current with updates as of today)

Thanks!

edit:
It seems that OpenHab isn’t getting the integers at all - what I had been seeing before were residual values before I had increased the precision from the MQTT device to two decimal points. Now OpenHab / PaperUI is displaying “-NaN” for all fields that had decimal precision. The field that is only integer (the Heat Index) comes through and updates fine.

2

Add:
and the log has corresponding entries of:
2019-01-27 20:46:36.895 [WARN ] [eneric.internal.generic.ChannelState] - Incoming payload ’ 21.10’ not supported by type ‘NumberValue’

I don’t see any option in PaperUI for a DecimalValue or similar construct.

3

It’s because of your locale. Your system seem to expect a comma instead of a dot. Because numbervalue should also take decimal values.
Just a guess.

4

HI David,
While there may still be something to this, I do, however, have no problem with decimal values from zwave bindings (4-in-1 sensors with temperature and humidity) or weather bindings (with local outdoor temp, humidity), which all seem to show the temp with a decimal.

FWIW, my current localle, per Openhabian-Config has 3 options selected:
EN_CA.UTF-8 UTF-8 (correct one - canada, english, and config suggests UTF-8)
EN_GB.UTF-8 UTF-8 (not sure how this became selected)
EN_US.UTF-8 UTF-8 (not sure how this became selected)

As an update to my earlier post, it seems that OpenHab isn’t getting the integers at all - what I had been seeing before were residual values before I had increased the precision from the MQTT device to two decimal points. Now OpenHab / PaperUI is displaying “-NaN” for all fields that had decimal precision. The field that is only integer (the Heat Index) comes through and updates fine.

5

I’ve finally figured the problem out.
The problem was in the string formatting on the arduino side. I converted the float value from the DHT22 temperature read into a character array ‘buffer’ using dtostrf. I had understood the middle parameter (for width) to represent the maximum character array length, when it actually represented the minimum length (this detail took quite a while to get an answer for). Below is the code I used:

char buffer[10];
// [snip]
dtostrf(DHTTemp,5, 1, buffer);  
Serial.println(buffer);
client.publish(DHT_temp_topic, buffer);

When observing the mqtt topic via mosquitto_sub, I didn’t notice this, however when looking closer at the openhab error log, I saw a leading empty character:

2019-02-03 21:03:32.130 [WARN ] [eneric.internal.generic.ChannelState] - Incoming payload ' 20.8' not supported by type 'NumberValue'

This led me to dig into dtostrf specifications. dtostrf (double/float input, array length, decimal precision, output character array)
Eventually I found documentation that the array length specified the MINIMUM length of the string/character array, and if the total length was less than this, it would be lengthened to match this. I had used a length of 5 initially when using two decimal point precision, as a temp up to 40C, including the decimal point, would require 5 characters.

Short answer: put a zero in the width parameter, and it will work.

dtostrf(DHTTemp,0, 1, buffer)

Making this change, openhab was able to interpret the incoming number perfectly.

Cheers!

6

Thanks a lot for your last detailed reply, I had the same issue and… solved thanks to you!

1 Like