[netatmo] Semantics added to channel types

[lolodomo]

Signed-off-by: Laurent Garnier [email protected]

[clinique]

I will take in account these evolutions in the ongoing PR also.

[kaikreuzer]

Can you help me understand what the "Switch" tag was good for? This channel seems to be related to light, so I'd rather would have expected a tag for that. Just because something is "switchable" is imho not enough for such a tag, especially as this information is already contained in the item-type.

[clinique]

To tell the truth @kaikreuzer , I did not spend much time reviewing this because existing version of the Netatmo binding is hardly functional due to some evolutions on Netatmo API side. I rewrote it completely (opened PR on this) still WIP but 95% done. Heavy work ongoing. I expect to be able to target OH 3.2

[lolodomo]

Yes, I agree, "Light" should be added.

[kaikreuzer]

But then again, "Light" is usually used to light up some room. A floodlight of a camera has a fairly special semantic and shouldn't be used as a random light (you don't want it to go on when you enter the room. You probably do not want it to turn off, when you're leaving the house, etc.)
I'd in such cases hence rather prefer to not put any tag on it, but leave it to the user on how he actually uses the device. Only he knows his concrete use cases.

[kaikreuzer]

Note that there a few other "Switch" tags in that PR as well.

[lolodomo]

I just look at Netatmo product information, the outside camera integrates a real light, it combines a light and a camera.
https://www.netatmo.com/fr-fr/security/cam-outdoor
Considering it as a light that can be switch on and off is IMHO fully correct as it is what it is.

[lolodomo]

I checked again all channels with only "Switch" tag and fixed them.

[kaikreuzer]

I'd suggest we park this PR until we finish the discussion on openhab/openhab-core#1791. Putting "Status" on everything where we don't have dedicated semantic tags for does not feel right to me and I wouldn't want to see this to be done for 300+ bindings now...

[lolodomo]

@kaikreuzer : to make progress, I propose to only keep tags that are obvious (in particular measurements like temperature, humidity, pressure, ...) and suppress "Status" where we don't have dedicated semantic tags. Can we at least do that ?

[kaikreuzer]

I propose to only keep tags that are obvious (in particular measurements like temperature, humidity, pressure, ...)

Yes, that makes sense, but I would really want to keep it to channels that reflect the "current" measurements. Channels about "min" and "max" and "in the last hour", etc. are imho not an obvious match for the semantics. The question you should always ask yourself: Do two channels of the same item-type with the same semantic tags transport the same information, i.e. are they interchangeable?

[lolodomo]

We come back to the need to tag channels to display them in equipment and property UI tabs. And any normal user will certainly expect to have all his temperatures (current, min, max, ...) at the same place in "temperature" property. That is more than a reasonable default that can be proposed to the user. That is my point of view and how I use MainUI like very probably a majority of users.

[kaikreuzer]

My point is not so much about saying that the channel is related to "Temperature" property, but that it is a type "Measurement". While I understand your point that the user might like to see "everything related to temperature" on a single screen (although that can get easily cluttered), adding those tags will complete destroy other use cases like "tell me the temperature in the kitchen" - that would be a clear regression and that's why I don't see these tags as something obvious to add. I really believe that we need to find a common understanding of how the Main UI pages are supposed to be used (as mentioned here, for which I really want @ghys to be involved as the master of the Main UI.

[lolodomo]

I close this PR as a refactoring PR for this binding is in progress.