[rfc] UoM shall I create a new unit(s) for humidity??

[andrewfg]

Many OH bindings relate to interior HVAC and/or outside climate and thus have humidity channels. Humidity is measured in several ways..

1. current amount of water in the air as a proportion of the maximum amount of water that the air can hold (at the current temperature) -- it is called relative humidity -- and formally displayed as 57 % r.H.
2. grams of water per kilogram of dry air it is called absolute humidity -- and formally displayed as 57 g/Kg
3. grams of water per cubic meter of dry air it is also called absolute humidity -- and formally displayed as 57 g/m3

Measurement methods 1. and 2. are both dimensionless measures, whereas 3. is a density measure.

Method 1. can be represented in OH via the existing UoM unit Units.PERCENT but this is not strictly correct since the formal display "57 %" differs from the formal display "57 % r.H."

So my questions (resp. proposals) are whether I shall create two new units for OH as follows..

• A new Units.RELATIVE_HUMIDITY which is a subclass of Units.PERCENT where the formal display is overridden as "57 % r.H."
• A new Units.ABSOLUTE_HUMIDITY which is a subclass of Units.ONE with a scale of 1/1000 and a formal display of "57 g/Kg"

Note that Unit conversion between Units.RELATIVE_HUMIDITY and Units.ABSOLUTE_HUMIDITY is not strictly 100% possible. This is because air has a higher capacity to hold water when it is warmer. (Which BTW explains why you get condensation and eventually frost when air is chilled). However there is a 'quasi/normalized' Unit conversion possible between Units.RELATIVE_HUMIDITY and Units.ABSOLUTE_HUMIDITY which can be made based on air at a normalized temperature of 20 Celsius.

=> WDYT?

[openhab-bot]

This issue has been mentioned on openHAB Community. There might be relevant details there:

https://community.openhab.org/t/migrate-channel-type-of-existing-things/154648/7

[rkoshak]

I think there was a discussion recently that covered this idea and there were arguments against having two different dimensions that represent the same thing. Whether it's percent humidity or percent of something else, it's still a percent.

You can add "r.H" to the state description when/if you want to be that specific in how the state is displayed. But in all other respects, it behaves as a percent so I'm not entirely certain making the distinction add anything.

And IIRC a unit for absolute humidity has been added sometime in the past year or so already but I can't find that PR at the moment for some reason.

However there is a 'quasi/normalized' Unit conversion possible between Units.RELATIVE_HUMIDITY and Units.ABSOLUTE_HUMIDITY which can be made based on air at a normalized temperature of 20 Celsius.

I don't like this idea at all. If someone is bothering to use absolute humidity in the first place, they are probably not going to want it normalized like that. Also, doesn't absolute humidity also depend on altitude? I don't like the idea of a conversion that kind of fakes it just to make it so we can have a separate pseudo Dimension for humidity.

[andrewfg]

I don't like this idea at all.

It wasn't really 'an idea' .. but rather a statement about actual (if infrequent) practice.

doesn't absolute humidity also depend on altitude?

One of the two absolute humidities — g/m3 — does depend on altitude (and weather related barometric pressure), whereas the other — g/Kg — does not. That is why the latter is preferable to the former.

[andrewfg]

You can add "r.H" to the state description when/if you want to be that specific in how the state is displayed. But in all other respects, it behaves as a percent so I'm not entirely certain making the distinction add anything.

@rkoshak please see this https://github.com/openhab/openhab-addons/pull/16531#discussion_r1528888167

[rkoshak]

That's a regression. It has worked in the past and it should continue to work to put anything one wants after the unit in the state description pattern. I can say that is currently does work in when the pattern is set in MainUI in OH 4.2 M1.

And even if that was never supported, it's better to enable that then it is to invent a whole new pseudo dimension with units that aren't really compatible/convertible between each other and which already exist elsewhere in other dimensions.

[J-N-K]

Can we close here?

[andrewfg]

Closing