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)
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.
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.
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.
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.
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:
dtostrf(DHTTemp,5, 1, 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.
Thanks a lot for your last detailed reply, I had the same issue and… solved thanks to you!