After 3.4.2 -> 4.3.4 upgrade, two of five MQTT/homie sensors have wrong units

[joelmr (Joel)]

I have five temperature sensors connected to a Raspberry pi. Three of them provide only temperature, and the other two provide temperature and humidity. I’m using the GitHub - mjcumming/Homie4: Python package for Homie v4 specification python library to read the values and publish them to mqtt. In Openhab 3, the Things created for all five sensors have the statuses as unitless Numbers. For instance:

In Openhab 4, the Things created for objects that only supply temperature show the sensor status as Numbers with a unit of Temperature:

However, the Things created for objects that supply both temperature and humidity show the temperature status as a Number with a unit of ElectricCapacitance:

When I snoop on the mqtt bus, both types of sensors seem to be identical as far as temperature reporting goes - both report temperature units as “F”:

(a temperature-only sensor)
homie/ts-226/status/temperature/$unit F

(a temp/humid sensor)
homie/temphumid2/status/temperature/$unit F

Interestingly, according to Units Of Measurement | openHAB, a unit of “F” is actually a Farad, the unit of capacitance. It’s “°F”, with the degree thingee in front of the F, that’s the unit for temperature (in Fahrenheit). Why would one type of Thing get the units right, and the other get it wrong?

There are assorted warnings in the logs about these objects, but none of them says anything like “I can’t figure out what “F” is so I’m going to assume it’s a temperature”.

I know I can (and now must, in OH4) supply units on the item side, to fix certain dimensionless numbers like humidity, but the temperature items bound to these Things already have “°F” set as the units.

How can I debug this further? And, is there a way to override the units assigned by the MQTT binding? Thanks.

-Joel

[rlkoshak (Rich Koshak)]

@joelmr

In Openhab 4, the Things created for objects that only supply temperature show the sensor status as Numbers with a unit of Temperature:

Note, one of the changes in OH 4 is that units are not optional. So you can certainly continue to use plain old Number Items without units and OH will strip the units off. That cold be one way to work around this problem.

@joelmr

However, the Things created for objects that supply both temperature and humidity show the temperature status as a Number with a unit of ElectricCapacitance

That is falt out wrong. I’d say that’s a bug in the MQTT binding. Or it’s a bug in what ever is publishing the $unit to the homie topic. It’s been a very long time since I’ve looked at the homie standard so I don’t know what it has to say on the proper unit for a temperature.

@joelmr

Interestingly, according to Units Of Measurement | openHAB, a unit of “F” is actually a Farad, the unit of capacitance. It’s “°F”, with the degree thingee in front of the F, that’s the unit for temperature (in Fahrenheit). Why would one type of Thing get the units right, and the other get it wrong?

A bug in the binding perhaps? Indeed “F” is a Farad and “°F” is a temperature. Sometimes it’s reading that unit published to the $unit topic correctly and sometimes it isn’t which is the main reason I think this is a bug.

@joelmr

And, is there a way to override the units assigned by the MQTT binding?

Yes there is, luckily.

You’ll need to add a script profiles on the link between the Channel and the Item. Assuming that the number is correct and it’s just the unit that’s a problem, you could use the following inline transform (the following is JS but it’ll look almost identical in most of the rules languages):

| input.replace("F", "°F")

You could also just strip the unit off the update entirely and OH will assume it’s °F.

Of course, you’ll need to make sure your Item is a Number:Temperature in both cases.

Another approach would be to use a Generic MQTT Thing for these Channels instead. There you’ll have full control over everything, including the unit.

But do please file an issue on the binding.

[joelmr (Joel)]

Thanks for the speedy response. I tried your suggestion of adding a profile, but I can’t tell if it’s working. It didn’t immediately solve the problem, do I need to starts something, or wait a certain amount of time for the change to take effect? Do I need to restart something or clear a cache?

Also, if I’m still unable to get this to work, you suggested I open a ticket. But, I’m having a couple of issues. First, I can’t find the location in github for the MQTT binding. Is this it? openhab-addons/bundles/org.openhab.binding.mqtt.homie at main · openhab/openhab-addons · GitHub. If so, I don’t seem to have permission to create an issue there, I don’t see the icon". Or, am I missing something more fundamental? Thanks.

-Joel

[rlkoshak (Rich Koshak)]

@joelmr

It didn’t immediately solve the problem, do I need to starts something, or wait a certain amount of time for the change to take effect? Do I need to restart something or clear a cache?

It doesn’t change anything retroactively. You’ll have to wait for a new value to be published before the profile will be invoked. And remember the Item must be a Number:Temperature.

@joelmr

First, I can’t find the location in github for the MQTT binding. Is this it? openhab-addons/bundles/org.openhab.binding.mqtt.homie at main · openhab/openhab-addons · GitHub. If so, I don’t seem to have permission to create an issue there, I don’t see the icon". Or, am I missing something more fundamental?

That’s the right repo but there isn’t a separate project for individual add-ons. Just click the “Issues” at the top of that page and the green “new issue” button. I think you have to be logged into GitHub to do this.

[joelmr (Joel)]

Ah, finally figured out how to create a bug report, see [MQTT] homie temp/humidity sensor gets wrong units after upgrade from 3.4.2 to 4.3.4 · Issue #18606 · openhab/openhab-addons · GitHub.