Binding-provided Default Semantic Tags

[ccutrer]

See also #1688

Re #1688 (comment) in particular:

I have alarm bells going off in my head at the thought of bindings pushing semantic models on the users.

While I agree that users should always have the ultimate say in something, I think it's very useful for bindings to provide useful defaults for many things, and then allow the user to override if they feel they need/want to. State descriptions (min, max, step), units, and heck even category (icon) as was discussed in the parent discussion are all examples we already have.

There are plenty of semantic tags that seem pretty unambiguous - if a binding is for a thermostat, having the item linked to set point channel always be tagged SetPoint would be correct in 99% of cases. For a RGB+CCT light, tagging ColorTemperature will almost never be wrong. An Air Quality Sensor should almost always have CO, CO2, Pressure, Temperature, and Humidity channels tagged.

Unless I'm mistaken, creating an Equipment from a Thing doesn't imply anything about the hierarchy of the semantic model - bindings would never be trying to push "this is a garage door, which would always belong in a group named lGarage".

And while openHAB supports extensions to the semantic model now, I think a few of the existing tag could be better defined. Like Light - is that supposed to be for a luminance sensor? Or a lightbulb? If for the latter, does it only get applied to actual bulbs, or to light switches? Do dimmers count? Speaking of dimmers, is a dimmer always a Switch? Should there be a new child Point of Switch named Dimmer?

Given all of that uncertainty, if we start to allow binding provided semantic tags, we would need clear guidelines. And chief among them would be "unless it's very unambiguous what this channel is for, don't provide a tag." For example, don't provide the Light tag for a Zwave light switch thing. While not the majority use case, it is very common for a light switch to control non-lighting things - like a fireplace, fan, pump, air handler, etc.

In my ideal world, I'd love to get to the point where I can have a thing for a thermostat, I click "Create Equipment From Points", and then from the Equipment item have a "Expose to HomeKit" button (which kind of already exists) --- that then infers the linked items automatically based on the semantic model. But still configurable and overridable. Way back when the HomeKit add-on only supported using category to expose items, and it was far too coarse and couldn't describe many accessories HomeKit supports. Though this even predated the semantic model.

cc @openhab/maintainers