I’m using the new MQTT Binding from OpenHAB 2.4.0.
I’ve a topic that sends a QuantityType in the following format: {"Temp":"45.7°F"}
Using a MQTT Thing of type string and a JSONPATH transformation I’m able to retrieve “45.7°F” as a string. Type string : Temperature "Temperature" [ stateTopic="weather/status", transformationPattern="JSONPATH:$.Temp"]
I would like to connect Temperature directly to a QuantityType Number:Temperature and thereby automatically perform the °F -> °C convertion.
I tried to define the MQTT Thing as type number. In this case it never accepts the string “45.7°F”.
I tried to connect the MQTT Thing from type string with an item of type Number:Temperature. It never received any data.
The only working solution so far is an proxy string item: rule "Temperature_String changed" when Item Temperature_String changed then if ( Temperature_String.state != NULL ) { Temperature.postUpdate(Temperature_String.state.toString) } end
Is there any better idea where the channel can be directly connected with the QuantityType item?
I don’t think the 2.4 binding supports quantity types but even if it does, I think you still need to strip the °F from the number in order for it to work. With the MQTT 2.x binding you can chain transformations so add a ∩REGEX:(\d+)°F to your existing JSONPATH transformation and it will strip off the °F.
You can try with the quantity type after stripping the °F but I don’t know if it will work. I think the quantity types expect a space between the number and the units. You can try a JS transform to add back in the space.
Adding a space doesn’t help Incoming payload '40.8 °F' not supported by type 'NumberValue'
I guess the MQTT Thing only excepts plain NumberValues and never QuantityTypes.
When stripping the °F I loose the capability to receive the temp using different units
You can check the open issues on the MQTT binding in the openhab2-addons repo and if there isn’t one already, request support for quantity types in a new issue.
That’s correct. Initially I was going for quantity types, but that’s quite some effort and we wanted the binding to be released at some point.
The problem: At the moment, we have fixed channels with fixed types (“Number” for example).
If I want the type to dynamically adapt, depending on the received MQTT value (“Number” turning into “Number:Temperature” if °F is detected), I would need to introduce a ChannelTypeProvide, and I’m really not feeling do add that to the codebase for the time being.
Especially because I’m still busy with my Paper UI NG project. And because the snapshots are not yet stable for development.
Thanks for the clear statement. Then I do not need to try it any longer.
Once I had the following in my logs which was leading me to the idea that it might be somehow possible: openhab2/openhab.log:2019-02-09 13:05:02.108 [WARN ] [rthome.model.script.actions.BusEvent] - Cannot convert 'null°F' to a state type which item 'WH2600_HeatIndex' accepts: [DecimalType, QuantityType, UnDefType].
Why isn’t it possible to connect the MQTT thing from type string containing 40.8 °F with an Item from type Number:Temperature? In this case it should be possible to use the existing functions for the translation into the QuantityType.
If I want the type to dynamically adapt, depending on the received MQTT value (“Number” turning into “Number:Temperature” if °F is detected), I would need to introduce a ChannelTypeProvide , and I’m really not feeling do add that to the codebase for the time being.
Dynamically typed MQTT things would be one option. Alternative option could be pre-defined quantity types in the MQTT thing. E.g. if it is defined to number:temperature there, then it only excepts temperatures (with °C or °F) or numbers without unit.
There are over 50 quantity types. If you use text files, you probably don’t care, but on a UI you need to select from a list of channel types when creating a channel. For usability reasons we decided not to do that. It is also not scalable when a new quantity type is added. So we can only go the dynamic type change route.
Theoretically possible, I agree. But not part of this binding, but rather a Profile that converts a String channel into a Number Item.
