-
-
Notifications
You must be signed in to change notification settings - Fork 86
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
How to map a String with multiple possible values to google assistant #178
Comments
I actually just finished an implementation of modes. I currently use it for a LED strip and the fading animations. This works quite well. When I'm back on the PC, I will share an example. Still, this is work in progress. |
Cool, I also use the modes for animations of all my LEDs in my room and PC. The modes are actually iCUE profile names which are synced to my PC with https://github.com/Legion2/open-cue-mqtt. |
@michikrug just want to ask about the status of your work in progress implementation of modes. |
@Legion2 Thanks for reminding me... I completely forgot to give you an update. My current test setup looks like this:
This reflects the fading program of a LED strip. Please let me know if you like more insights. |
Would it be possible to make the settings dynamic, so one can get the settings list from another String item. I think the mapping from the spoken values to some other values (numbers in your example) is not really needed to be implemented by the google assistant integration, it would be sufficient to use an openhab rule to convert the value using a transform and then update the openhab thing. |
Can you sketch me a use case where such a dynamic setting would make sense? And for the values: in my opinion, the less rules or transformations I need to configure the better. With the current approach I would have at least only one place where I need to configure something. |
I'm using iCUE a software to manage PC RGB lighting. In the software I can create lighting profiles. I created an MQTT Adapter for iCUE, so I can get all profiles from iCUE and activate profiles via MQTT. The list of profiles I can store into an openhab item with the MQTT binding. With the Google Assistant Integration I want to be able to activate one of the available profiles. And I don't want to update the Item in openhab manually when I add or update a profile in iCUE. |
Hi, I'm currently looking at Alexa and GA to access my devices and have a real need for the dynamic selection too. @michikrug asked for an example so here is mine. I have OpenHab connected to my Kodi box. Kodi has a channel (String) which is used to play/open a favourite. When you add the channel as an item, PaperUI show the item as a list of favourites as a Combo Box of string values, you pick the selection from the combo box, and Kodi plays/opens the content. Example list "BBC 1", "Apollo 13", "Radio Station", "Tube Channel". I'd like to say "play/set [favourite] BBC 1 on Kodi". The list of favourite's can't be a predefined list in the item, as it's whatever the user has currently decided to tag as a favourite in Kodi. But all the options are returned to OpenHab has as a list of strings via the thing's channel. I can get it to work in Alaxa via mode, with a pre-defined list in the item. Works as in concept, but useless in real, unless the list is dynamic. Is this possilbe? |
I started some implementation based on your use cases and will report back as soon as I have run some tests. |
I have been able to get it to work in Alexa without the pre-defined list in the Item's mode. When not specified it seems to load them all. It doesn't auto refresh though, I need to "Alexa, find devices", after I have made change to favourites. But once I've done that, it can do this "Alexa, watch BBC1 in the movie room", which works pretty well. If the GA mode feature could work in a similar way it would be nice, even better, if it refreshed dynamically. |
where does the String Item get the list of all possible Strings from? |
It must be build into the kodi plugin for the channel, as standard open hab; This is how I add it in PaperUI, I simple add the channel, and it's of type string. OH must know it's a array and not a single string, and the render the item accordingly. I do nothing extra at all to make this happen, So it must be standard functionality for the channel type oh, the list comes back via the channel used to set it, if that's what you meant. |
yeah, that's what I mean. I didn't know OH supports lists, what is the format of the lists? |
Also with Google Assistant (with my current test) you will have to sync your devices everytime that list changes as the values are stored in the metadata of the device that is only retrieved when the device is synced. |
is this a limitation of Google Assistant API? |
That's not too much of an issue, it's not something you'd do all the time. To be able to pull the data at all, without changing the Item definition is the main thing. |
It does seem a little odd it can push states values such as modes and switches and other controls back to the assistant so it's aware, without a sync, but not the string values from this control... I don't know enough about how it all works though. |
Well the modes trait is probably just not made for that use case. Normally, the modes of a device are static, will never change and are known as soon as you install the device. So I would argue that the use case is just very special. But this is just my pov. |
@michikrug, that's a perfectly valid case for mode you state. It's handy it can be adapted to suit this thought. But maybe it really requires a feature of it's own to encompass selection of dynamic lists. But for now, glad it can :) |
I'm also fine with the limitation, that the device must be synced to add new values for a Mode. |
I found that OH items have a StateDescription which contains an options field. It describes option values with labels allows to set for the item. These options can be set using metadata or are set by linked channels automatically. I think this is why @peepshow-21 sees a list of options for the string item. Maybe the google assistant integration should also use these options which are build into openhab instead of defining own mappings. |
This is indeed an interesting finding... But there seems to be no way to influence those option by the user. Also the UI does not show them properly |
In my openhab I have a String Item which represents the mode of a device, which supports many modes (>10), so simple OnOff Item does not work. I would like to control the mode of that device with google assistant, for example I want to say "Hey Google, activate/set Mode A [of device X]".
This could be done with Scenes in google assistant, but I would have to create a Scene for each possible mode. Is there a better mapping to google assistant? Also It would be nice to also have support for dynamic discovery of modes, by using a second String Item which contains a comma separated list of all possible modes.
The text was updated successfully, but these errors were encountered: