-
Notifications
You must be signed in to change notification settings - Fork 784
Allow add-ons to provide custom meta-data on items #3692
Comments
A very generic idea. So what if add-ons could implement a certain class to provide scoped (prefixed like Alexa:) meta-tags. The ui could then provide a drop down based on all those provided tags |
Continuing the discussion from 1093...
Could you elaborate on what you mean here? I'm not sure exactly why a boolean flag would not work. I figured that the complexity should be pushed down to the individual addons. Once an item is exposed to an addon, the addons themselves could provide additional metadata if necessary. For example, HomeKit internally will need to map the OH semantic tags to HK accessory types. Shouldn't it be up to the HomeKit addon to provide a way to configure that if desired, rather than OH? You mention custom labels - I presume you mean the ability to specify alternative names for items to be controlled by voice. That seems like a pretty complex issue. For now, users can achieve multiple labels / alternative voice names by simply having multiple items that work together through groups, rules, or sharing channels. (not ideal, I know) I agree that you don't want to get into a situation where you have to live with a temporary solution forever. However, a simple boolean UI would unblock development of this (seemingly highly-desired) feature, and keeping it simple would allow iteration later if more control is desired at the OH level. |
I must say that I also liked the imho intuitive way I used homebridge with OH1.8. There I just had a sitemap to expose items to homekit, the sitemap allowed:
Could such a solution help us? Or is this too much of a work around. |
I have never been a fan of overloading the current sitemap structure for this, but I understand your point about simplicity, and I think its worth talking about. One aspect to this is that we are still dealing with a UI, just a voice UI vs a visual UI. So, I guess one thought is do we have something similar to the sitemap (voicemap?) where you can lay out what voice items, types and labels you want. This would also very much help with things like Thermostats, where we need to group items together. You could then have a voicemap for each type of service (Alexa, homekit, ....) . Or maybe we extend the sitemap to be more voice friendly? My hesitation with using sitemaps as is is that we are overloading one concept to fit another (frames, images, etc... do not fit voice). My other is that sitemaps are a OH1 concept and there is no built in storage for them other then flat files (aka no JSON storage). |
The Alexa binding i have prototyped I think accomplishes this, and to your next point, if you need to have items exposed differently, you can create duplicate items with different labels and tags and only expose those to a particular service. This works, I think, but I'm not sure is ideal. There are now several places a user has to change things, and it can be difficult to explain. Tagging an item by itself has been difficult for users, but trying to explain now how to duplicate items, tag them differently, then go to a particular binding and choose those items to expose is a lot of work. Of course, thats exactly the path I went down :-) |
What about this, maybe introducing types in/of sitemaps? @kaikreuzer wdyt? |
@anthonygillet: Well yes, this was exactly my point: We need more meta-data than just a boolean flag. And if we have a mechanism for add-ons to provide that meta-data, they can also provide the "exposed or not" information, such that there is no need for having that information provided by the core framework.
Yes, but this is really ugly indeed. If we have a mechanism for meta-data, a custom label would imho fit in there without any problem as well and be a much nicer solution. @digitaldan: Your prototype looks nice and it is what can be done with the current possibilities.
@martinvw: As @digitaldan mentioned, the current sitemaps are not state-of-the-art for ESH and rather due to be replaced by something more UI-editing-friendly. So from a technical standpoint alone, I would not suggest to go that way. Furthermore, I would not reduce the discussion here to "voice", but we are actually talking about any kind of add-on that wants to expose stuff in some specific way. The required meta-data can also be very different for each add-on, so trying to make sitemaps suitable for all, probably won't work. I'd think the sketched solution from above that builds on @digitaldan's prototype should be a possible way to solve the requirement. Note that from a UX perspective, it is pretty different to using custom tags for such meta-data:
I cannot say which approach I prefer, but I have a tendency towards option 2 as it keeps the modularity aspect visible: If an add-on isn't installed at all, there also is no way to configure it. On the other hand, only option 1 so far has a solution for providing the meta-data through the REST API; so we might actually have to come up with some mix of both approaches. Maybe we can declare it as a new add-on configuration concept and NOT introduce a generic Map support in configurations for the start, but instead have the framework support this special requirement by merging such configurations with the items on the REST API. The problem would then only be that we also need a dedicated UI for editing such information... All not too easy, I am afraid :-( |
We might. But this will introduce an awful lot of complexity, both in terms of UI design as well as on keeping the information consistent and staying generic at the same time in the data model. I therefore would like to avoid unless really needed. So we should cautiously check if the use-case we have in mind here really makes sense like that or if the modeling really is correct from a conceptual point of view. From reading the above discussion, it looks to me like the additional configuration indeed is a property of the item and not of the add-on, while still being specific to the add-on. So why not combine the two suggested approaches like following - it more or less follows the path that you indicated in your last paragraph: We could treat such configuration as a "link" between an item and an add-on. It would contain the item name and the add-on name as "primary keys" and would carry a specific configuration . The add-on provides a config description and therefore defines what can be configured in the realm of this add-on. UIs then may decide themselves whether they want to start from the item (selecting the add-on) or from the add-on (selecting the item) for this specific configuration part. As we have config descriptions, this should not be too complicated to embed in the existing UIs using the available mechanism for generically rendering configs. The available "add-on-links" could then be rendered into the /rest/items resources (maybe only upon request by an attribute) so that clients may use them. |
I second @SJKA´s approach. |
I also like the idea, but it will also mean that we introduce yet another "entity" that needs to be handled by the infrastructure. FTR: I have started prototyping a proof of concept - the rough architecture is the following:
A few thoughts/issues I came across:
|
@kaikreuzer - in that prototype you describe, how do you see users managing the actual mapping to an add-on's type. It seems like a good way to solve "Should I expose this?" but not necessarily "What is this?". Currently, we do that with a tag like "Lighting". There's a proposal out there to use Channel Categories instead, with tags as a fallback. Do you envision this would instead become part of the metadata? It seems we then lose some of the auto-configuration we'd have from Channel Categories. |
@kaikreuzer & @digitaldan: I think @digitaldan approach is a big step and we should keep in mind that we need to make this run, even without OH dependencies. Best is to engage the REST API and let the solutions decide how to show it in UIs. Only some small ideas and inputs. Still thought that metadata infrastructure is already in place..or lets say we have a PR :-) BR Mehmet |
Surely there is: #4390 - it has already received quite some thumbs-up, and no down, so I would suggest that you look at that and provide your feedback where you might see problems. @beowulfe Sorry, I actually missed your comment here on the issue, but I hope that the PR that I created shortly after answered at least part of your questions. So yes, the tags should imho become such meta-data and I think we will need both, categories and tags as a combination to get a full picture of the item (the category more for describing the type and capabilities, while the tags rather describe the purpose and the semantics). |
This is a continuation of the discussion at #1093 (comment).
We have multiple add-ons (HomeKit, Alexa, ImperiHome, ...) that want to expose items to external systems and which require some special meta-information like a mapping to the type system of the remote system.
So far the approach was to use semantic tagging, but this has the drawback that it isn't possible to have different meta-data for different add-ons and to decide which ones to include or exclude on a per add-on basis.
I think we therefore need some other mechanism to provide that information. So far my recommendation usually was to come up with an add-on specific configuration file and create a dedicated REST endpoint for exposing the data.
@digitaldan challenged that and fears that we will end up with too many endpoints that would fragment the REST API and be a potential security risk.
Also, we should have a common way how to configure such meta-data - we should not force every add-on to come up with its own UI to do this job.
The text was updated successfully, but these errors were encountered: