[feature request] Tags

[tmrobert8]

Michael Kohler asked me to start a thread about this.

Would be nice if we can assign 'tags' at a device, control and sensor level. A tag would just be an open ended way for the plugin writer to communicate special attributes that the brain can then act on.

An example everyone knows about right now is the 'brightness' slider for a LIGHT type. If we had the ability to tag the slider as a 'brightness' slider - then the name of the slider wouldn't matter. Likewise we could do that with the various hue, saturation, etc sliders (with an appropriate tag).

At the device level, you've already (kinda) use tags with the device capabilities ("alwaysOn", etc).

Beyond behavioral tags, you could also use tags to communicate UI needs. Plugin writer would be able to specify which widget's to use via a tag ("transport", etc) and then use tags on the buttons/switches to identify how to link them up ("play","pause",etc) rather than deduce the widgets from what specially named buttons are included. Tags make it explicit what is needed rather than guessing what is needed (and hoping things are named correctly).

Lastly - looking beyond NEEO at potential integration, tags allow the plugin writer to communicate how to expose items to integrations (homekit, etc). If I put together an ecobee plugin, I could tag a sensor as "CURRENTTEMPERATURE" and then homekit knows that's the current temperature item.

Upside to tags - it's open ended and easy to use
Downside to tags - it's open ended (ie needs good docs) and tags are single independent attributes - once you get more complex - you need another approach. But they are a good starting point, are simple (both in concept and usage) and cover ALOT of cases..

Bottom line
Basically anything that would require special identification or special handling could be communicated between the plugin/brain through an open ended system using tags.

[pfiaux]

Thanks for the write up!

As you mentioned this is already done for devices through capabilities.

We're looking into implementing a role field for most components but essentially it's similar to the tags what you described above. We need to know the purpose of these components and how they are to be integrated on the bigger picture and it should solve the name problem for sliders.

[gvdhoven]

note: Alexa also uses capabilities as a name for this.