@jeshab, could you please provide an update on whether Items with autoupdate=“false” are able to be used with the skill? This post leads me to believe that they are not… but is this still correct?
It depends what you are expecting. If you are looking for an item with autoupdate="false" to report its state to Alexa, then this falls under the asynchronous deferred response workflow which is not currently supported.
Currently, the skill automatically set the item state, related to that parameter, as not retrievable. This means that the skill will return the requested command as state and that there will be no representation of the item state at the Alexa level.
1 Like
I’m just hoping to send commands to the Item from Alexa. The Item itself is basically stateless, and I would not expect Alexa to know or to be able to report it.
To be more specific, PlayerItems require a separate SwitchItem for Stop functionality. Programmatically maintaining the state of the Stop Item is quite an undertaking, and it is much easier to use a stateless button. If this Stop Item can be discovered and sent an ON command through Alexa, then everything should work OK, since Stop is never sent an OFF command.
There are several bindings with Stop functionality. The new UPnP Control binding is one of them, and I was questioning the use of it with the Alexa skill.
That exactly how the skill would interpret it.
For that part, it might be challenging if you are trying to couple with a Player item modeled as a PlaybackController. You might want to use a proxy String item, modeled a ModeController, that would control both items via rules. It might not be perfect in term of supported utterances but it should work.
Currently, PlaybackController is limited to the Player item supported operations. I think this use case should extend the support for that capability to String items with a supported operations parameter.
1 Like
@5iver I have been looking to implement this use-case. I am planning to add a way to tag a switch item for playback stop commands, part of a group endpoint, matching the Chromecast and Kodi binding implementation. I am debating if I should also allow String item as well. Looking for your thoughts.
Here is an example on how it would be configured:
items
Group gKodi "Kodi" {alexa="StreamingDevice"}
Player KodiControl "Control" (gKodi) {alexa="MediaPlayerControl", channel="kodi:...:control"}
Switch KodiStop "Stop" (gKodi) {alexa="MediaPlayerStop", channel="kodi:...:stop"}
utterances
Alexa, play Kodi
Alexa, stop Kodi
Jeremy
I’m not sure Scott is active in the forum at this time. Maybe PM him
No worries. After looking into this a little more, I think there is no need to expand the support to String item for this capability since all playback control enabled bindings are using a Player item associated with a Switch item to provide stop command support.
1 Like