openhab-addons: [mqtt] Faulty display of an linked item using Units of Measurement.
Setup
A device reports a temperature ( measured in °C) via mqtt as a plain number 16.0.
A channel is setup on that value using a JSONPATH transformation and a Unit of Measurement setting of °C.
A linked Number:Temperature item would display 16,0 °C.
Expected Behavior
Using a State Description pattern on the item of %.1f °F the displayed value would be converted to Fahrenheit. 60,8 °F.
Current Behavior
Initially the converted value is displayed correctly, however after the channel receives an update the displayed value changes back to the Degree value keeping the Fahrenheit sign 16,0 °F.
This change is correlating with this following events.log entry.
2021-03-14 14:00:32.259 [INFO ] [openhab.event.ItemStateChangedEvent ] - Item 'TestTemperature' changed from 16.0 °C to 16.0 °F
Discussed on the forum
About this issue
- Original URL
- State: closed
- Created 3 years ago
- Comments: 27 (15 by maintainers)
Sure. But we’re talking about incoming data here. In this case, numeric only. “We” the user/configurer knows that represents F or whatever, and wishes to add that info to the incoming data. In other words, add " °F" to the numeric to create a Quantity, ready for use updating a Number:Temperature Item.
I’m not sure what’s troubling you here.
Let’s work through it. You got an Item Number:Temperature, it starts life as NULL. Along comes the binding and posts “16” to it. But it’s a temperature type, it must have a unit, so the OH framework intervenes and looks for a unit - there’s no Item pattern option, but there is a system default, so it uses that. There’s no conversion because we started with just-a-number, there are no units to convert from. The post of “16” ends up as Item state “16 °C”
Next you come along and set Item option pattern “°F”. The Item still contains state “16 °C” But the UI uses the pattern immediately, conversion is done from °C to °F, that’s the real purpose of the pattern, and so you see “65 °F” at this time.
Later. along comes the binding with another update, it’s still just “16” Again, OH framework looks for a unit - but this time there is a pattern, so it uses that. There’s still no conversion because we still started with just-a-number, This time update “16” ends up as Item state “16 °F”
The UI still uses the pattern, does the no-operation conversion °F to °F, and displays “16 °F”
You might now come along and post “273 K” via the API. That’s fine, it’s a valid temperature. OH framework dutifully looks for a unit - still there is a pattern °F, so it uses that. But this time the update has come with units, so a conversion is applied K to°F Update “273 K” will give Item state “32 °F”
I believe this works fine in recent Modbus binding, with just a number type channel linked to Number:type of user’s choice. The binding creates a Quantity from raw numeric data and user-designated “unit” parameter. It is of course possible to misconfigure and try putting “22 °C” or “14 bananas” into a Number:Length Item, but this is after all an “advanced” manually configured usage and not expected to be idiot proof?
I do not know if Modbus specifically allows all Number:xxx Item types as “accepted”, or just takes advantage of lax policing when creating links.
EDIT -duh, Opus has already linked his plain number type MQTT channel to a Number:Temperature Item, so I guess there is no practical problem here.