Check existing semantic tags defined on channel types

[lolodomo]

The guidelines about semantic tags are not yet really clear.
We found the following temporary agreement with @kaikreuzer to start adding semantic tags. Here are the current guidelines. Kai, please correct me if something is wrong or not enough clear:

1. Semantic tags should be added to a channel type only when the assignment is absolutely obvious. For example, the tags "Measurement" + "Temperature" should not be set on a channel type used for forecasted temperature as forecast is not a measurement.
2. It is not allowed to set only "Control" or "Switch" tag on a writable channel type. Also not expected to set "Status" tag on all read-only channel types.
3. No property tag is expected with the "Status" point tag; a property tag is generally expected with a "Control" or "Measurement" point tag. As an example, Status + Temperature is not expected.

Now here are all the bindings which defined semantic tags on static channel types. We have to check if they respect the rules defined above:

• airquality (6 channels) => PR [airquality] Cleanup semantic tags #12290
• danfossairunit (1 channel) => the system channel type could have probably rather be used.
• deconz (5 channels) => PR [deconz] Cleanup semantic tags #12287
• dmx (3 channels) => the system channel types could have probably rather be used. PR [dmx] Fix tags for channel color_temperature #12265
• feican (1 channel) => the system channel type could have probably rather be used.
• homeconnect (1 channel) => I see several other similar channel types without any tag.
• hue (3 channels)
• ipobserver (13 channels) => PR [ipobserver] Cleanup semantic tags #12379
• lifx (6 channels) => the system channel types could have probably rather be used. PR [lifx] Cleanup semantic tags #12274
• max (3 channels) => PR [max] Use defined semantic tags #12268
• mihome (3 channels) => the system channel types could have probably rather be used.
• milight (2 channels) => the system channel types could have probably rather be used.
• millheat (7 channels) => PR [millheat] Cleanup semantic tags #12289
• mqtt.espmilighthub (3 channels) => the system channel types could have probably rather be used.
• nikohomecontrol (2 channels)
• omnilink (8 channels) =>PR [omnilink] Removed tags from channel type lock_switch #12288
• openweathermap (6 channels) => PR [openweathermap] Cleanup semantic tags #12285
• openwebnet (5 channels) => PR [openwebnet] Fix tags for channel shutter #12271
• qbus (2 channels)
• rotel (1 channel)
• sagercaster (4 channels) => PR [sagercaster] Cleanup semantic tags #12284
• sensibo (2 channels)
• [shelly] (5 channels) => the system channel types could have probably rather be used for some of the channel types. #12326
• sonyprojector (1 channel) => PR [sonyprojector] Fix tags for channel type powerstate #12283
• souliss (10 channels) => PR [souliss] Fix semantic tags #12269 and PR [souliss] Remove tags from channel type power #12282
• touchwand (1 channel)
• vigicrues (7 channels) => PR [vigicrues] Cleanup semantic tags #12286
• wled (1 channel)
• yeelight (5 channels) => the system channel types could have probably rather be used. PR [yeelight] Cleanup semantic tags #12270

And here are all the bindings using withDefaultTags (channel) and/or withTags / withTag (channel type) that should be checked:

• digitalstrom
• hueemulation ?
• km200 => PR [km200] Cleanup semantic tags #12573
• loxone => Lighting, CurrentTemperature, Blinds, Switchable, Scene
• miio => tags to be set dynamically are defined in files database/*.json => a massive cleanup would be required
• sensibo => PR [sensibo] Fix semantic tags for target temperature channel #12750
• webthing => PR [webthing] Cleanup semantic tags for dynamic channels #12751,

We can discuss in this topic each time we find a tag which does not match the rules.

[lolodomo]

@kaikreuzer / I believe we should moderate the fourth rule because for old bindings you have sometimes Number channels without any dimension but the semantic tags "Measurement" + "something" make sense (I guess the binding was created before UoM was introduced in openHAB core, or maybe the developer decided to not use UoM).
And another case is the UV index, it is generally a simple Number channel but it make sense to tag it with "Measurement" + "Ultraviolet", like it is done in the openweathermap binding.

[lolodomo]

For the sonyprojector binding, I defined the channel type "powerstate" (Current detailed power state of the projector). I tagged the channel type with "Status" + "Power". It does not respect the third rule. @kaikreuzer : should I switch to "Measurement" + "Power" ? Or maybe only "Status" ?

[lolodomo]

@kaikreuzer : for the sagercaster binding, we have 2 cases to discuss:

1. the channel "is-raining": this is an ON/OFF information. It was tagged with "Status" + "Rain". Should we remove all the tags ? If not, what tags should we use ?
2. the channel "timestamp" (Timestamp of the last weather forecast update): this is another interesting case as we could find it in many bindings. It was tagged with "Status" + "Timestamp". Should we remove all the tags ? If not, what tags should we use ?

@clinioque as author of the binding

[wborn]

You could add some SAT checks so it is easier to check and enforce the logic on tags. 😉

[jlaur]

@lolodomo - addressing the danfossairunit system channel type comment: #12277

[kaikreuzer]

Kai, please correct me if something is wrong or not enough clear

Thanks @lolodomo for your efforts here, the summary above sounds good to me.
Just FWIW: I am not the one to ultimately decide here, so these guidelines were just a suggestion on how to proceed for now, as they are probably the least controversial. Anyhow, everyone should feel free to challenge and suggest changes. But in order to move forward, let's go with this unless anyone complains!

I'll try to look into and answer your questions later today...

[lolodomo]

I am not the one to ultimately decide here, so these guidelines were just a suggestion on how to proceed for now

Yes, of course. And that is clear for me that is the current and temporary proposed guidelines, not the final ones.

[jlaur]

Just openend an issue so that it may be added to the developer docs.

Or maybe even user docs? After all, deriving consistent default tags should have user impact, otherwise there would be no point. So if we could explain the rules in relation to the end result, this might be worth doing.

[lsiepel]

To add a questions to the 'rules' discussion i want to point to #14160

Some tags where added (Setpoint + Temperature) to the "Intended Boiler Temperature" channel. While this channel is read-only, it does hold the setpoint for that temperature. It is not writable from openHAB, but it is controlled by the device.

So how would this channel be tagged? If Setpoint+Temperature is wrong, then should the rules be adapted to never ever allow control + read-only?

I hardly see any bindings with default tags, and that might be because these rules are not clear yet. I really think the out-of-the-box experience could be improved by adding as much as tags as possible (offcourse only by rules and that make sense). I'm willing to spend a lot of time on many bindings to add those tags, but only if we cvan come up with some more rules / guidance.

[openhab-bot]

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

https://community.openhab.org/t/setting-semantic-class-from-binding/146975/4

[openhab-bot]

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

https://community.openhab.org/t/openhab-5-semantic-model-proposal/162526/88

[jimtng]

2. It is not allowed to set only "Control" or "Switch" tag on a writable channel type

How should I set the tags for an airconditioner mode channel? Control + Something but I can't find a suitable property.

Ditto for:

• TV Channel (To change the channel)
• TV Application (launcher)