While trying to use (and understand) Units of Measurement on MainUI observed a faulty behaviour.
Used a Generic MQTT Thing with a number channel and JSONPATH transformation
stateTopic: tele/deviceID/SENSOR
Incoming ValuecTansformation: JSONPATH:$.AM2301.Temperature
Unit of Measurement is set to °C
The values are transmitted from the device in °C.
The linked item is a Number:Temperature type.
Linking it without a State Description Pattern gives a display of : 16°C.
Using a Pattern of %.1f °F results in a display of 60,8°F (correct localized decimal character!).
After a couple of minutes however the display changes to 16,0 °F.
Anybody else seeing such faulty behaviour? I would have expected such reports but haven’t seen any! Am I doing something wrong?
I´ve got the same problem. But in the other direction. From °F to °C. i used %.1f °C. The right value ist displayed. After the MQTT send new data, the value changes wrong…
Checked on MainUI (Items) as well as a file based sitemap ( using standard formatting, I.e. no pattern).
The events.log does not show any of the conversions triggered by a change of the Pattern. The change to the ‘faulty’ display seems to be correlating with an ItemStateChangeEvent.
Like: 2021-03-14 14:00:32.259 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'TestTemperature' changed from 16.0 °C to 16.0 °F
Leaving the %.1f °F on the system for a longer time (~1-2 hours) and removing the pattern after that does initially result in a totally wrong display -8.888889 °C ( conversion from C to F on a value of 16). , after a couple of minutes ( correlating with an ItemStateChangeEvent) it changes to 16°C.
It’s like the update is using the Item default units without conversion, instead of the unit specified in channel and converting on the way.
Confident you really have a Number:Temperature type Item? This is the kind of behaviour I’d expect to see from a standard Number type.
An (unverified) hypothesis on what’s happening here:
The MQTT channel only receives the raw number (16) and passes it to the Item. The Unit of Measurement Setting sets the state description to °C, which makes the Item combine the raw value with a unit before the Item’s state is set.
When changing the stateDescription on the Item, this overrides the value set on the channel, which makes the raw value (16) be combined with the unit °F instead, before the Item is updated.
The value configured on the Item takes precedence, so the one configured on the channel is not used. This is just like the mechanism where bindings can supply a default state description which can be overridden by the Item configuration.
That would be a problem, this all relies on passing a complete Quantity e.g. “18 °C”
Idea to test what the channel passes; link a temporary additional String Item to the channel - you’ll either get the update as string, or an error log complaint about it.
Thinks; always puzzled me what order the various channel transforms and format parameters are applied in. Maybe the JSONPATH wipes away the channel putting " °C" on the end.
Yes, the optional parameter used only for number type MQTT channels.
Maybe it’s worth checking in JSONDB what this is set to, I think it will show up as 'unit' like in a xxx.things file definition. Just in case this is UI not saving properly or something.
We’ve all been assuming that what you put in there gets appended to the numeric you extract from your incoming payload, before it is used to update the linked Item.
A really clever customtransformation would extract both your numeric value, and the units data, and then use both to build an openHAB quantity value “18 °C”.
But that’s just avoiding why the unit parameter declaration doesn’t work.
That is what I expected as well. And that is what is happening initially, no state change (nothing in the events.log), only the displayed value is converted. What puts me off track is the change after that, the log showing Item 'TestTemperature' changed from 16.0 °C to 16.0 °F, in other words the original value of 16.0 °C ( at the moment the converted value to °F is displayed!) is changed to 16.0 °F ( displayed is then 16,0 °F , note the different decimal separator)!
Why does the ItemState change at all?
It’s a Number:Temperature type Item, so it has a system default (°C)
With no pattern
Post 16.0, get 16.0°C in Item state (system default)
Set pattern °F, display will auto convert to 60.8°F
A while later another update comes along
Post 16.0, get 16.0°F (now uses individual Item default set by pattern)
Display as 16.0°F
If you were to use API or rule to post “17 °C” to your Item with °F pattern active, I’d expect to see it update to 63°F or something. This what you want to happen from the channel.
What’s wrong is the channel posting updates without the units that you asked for.
Did some more tests, this time created an item that gets set by a rule only. Sending 12.5 °C via the rule and using a State description pattern of %.1 °F does work even after updates of the item. @rossko57 IMHO your reasoning is validated.
I’ll file an issue for the MQTT binding. Issue
