Add UnitUtils.shouldUseUnitHint

[ccutrer]

I've been adding unitHint to several of my bindings. First I did mqtt.homie, which just does a straight "if the upstream system provided a unit, then use that as the unitHint." Now I've been adding to several other channels in mqtt.homeassistant which are more well-defined, and I've realized that a binding actually shouldn't provide a unitHint in most scenarios. So, correct me if I'm wrong here:

• Number:Dimensionless should always provide a unit hint (one is never useful)
• Number:Temperature should provide a unit hint if the unit is K or MK⁻¹ (if it's °F or °C, we actually don't want a hint, because we want MainUI to simply suggest the preferred unit for that dimension, regardless of the device)
• For all other dimensions, we should not provide a hint, for the same reason - create item's in the user's preferred unit, and let the framework convert from the device's unit if it's different.

Assuming these are the correct guidelines in the first place, I suggest codifying it in UnitUtils so that bindings that present dynamic channels (basically anything that bridges from another ecosystem - mqtt, zwave, etc.) can automatically determine if the channel they create should present a unit hint, instead of always forcing the device's units on the user.

I opened as an issue to get confirmation from @openhab/core-maintainers that this seems reasonable before I simply go and write this method myself.

[lolodomo]

I am not a core maintenance but IMHO they are correct guidelines. I would just add one another: set unitHint when you know the default unit can't be the best choice for a particular channel. And this is something that cannot be determined by a generic method.
By the way, it would be good to write these guidelines in our documentation for developer.

[lolodomo]

Example:
openhab/openhab-addons#17826

[ccutrer]

Looking through https://www.openhab.org/docs/concepts/units-of-measurement.html again, it feels like for a lot of dimensions a unitHint might well be useful, but only within the same system. I.e. for a Length, if the device is providing units in ft, and the current unit system is in imperial, the unitHint is still useful because the magnitude of the unit is very important, instead of the default of in. But if openHAB is in metric, neither ft nor in is useful, so all bets are off. So... maybe this additional guideline--which only works for dynamically channels-- if the proposed unit is in the same measurement system as openHAB's system settings, always use that as the unitHint. If it's not, then don't propose a unitHint at all. But perhaps this suggests either core or MainUI should be applying that logic across all channels when creating items, then it would work for static channel definitions as well.

[mherwege]

A unitHint is just that, a hint, that gets suggested when first setting up the item, so the internally stored unit will be different from the default in the dimension. You are free to decouple representation from that stored unit using state descriptions. So I would only use unitHint when it avoids confusion for the end user. And the list on top is fair. I think it is something for documentation, rather than attempting to code in core though.
The UI also has other means to present a proper, prioritized, list of units, completely coded in the UI: https://github.com/openhab/openhab-webui/blob/main/bundles/org.openhab.ui/web/src/assets/units.js. If a unitHint is provided, this will be on top of the selection list. If not, the selection dropdown will be constructed with the info from this file. The list constructed does not represent all possibilities, only the most typically used ones. It is still possible to manually type a unit.