Using timer trigger for this will help. Currently, you can only achieve this by defining a specific time.

This is especially useful for devices that would normally be set to the default position of "on" and I don't want to forget that I temporarily turned it off.

Alternatively, you could give us the ability "if off, turn on in 'x' minutes".

Also useful because default position in most switches is 'off' after power outage. Right now, I'm running a 'turn on' once per hour in case of power failure.

I'd really like to get it down to 10 minutes but that's simply too much manual config with no easy copy/paste.

Problem:

When an audio streaming skill is actively streaming/playing, users of the skill have to re-open the skill in order to issue additional commands. This creates a very awkward user experience, for example:

"Alexa, ask AnyPod to play This American Life"

<This American Life starts playing>

"Alexa, ask AnyPod to play the oldest episode"

<oldest episode starts playing>

"Alexa, ask AnyPod to fast forward 3 minutes"

<episode fast forwards>

"Alexa, ask AnyPod to <etc>"

--

Solution 1:

Ideally this interaction would go like this:

"Alexa, ask AnyPod to play This American Life"

<This American Life starts playing>

"AnyPod, play the oldest episode"

Having "AnyPod" (the skill's invocation name) substitute in as an alternate wake word would be great. But of course you'll never do that in a million years, until in a few years from now when you actually do. So how about this as a compromise in the meantime:

Solution 2:

"Alexa, ask AnyPod to play This American Life"

<This American Life starts playing>

"Alexa, play the oldest episode"

This will require some clever engineering to determine whether the user is said something that maps to a valid intent within the active audio streaming skill's invocation model - and if not, handle the request the same way they are currently handled. That seems reasonably doable.

It does create potential problems where an audio streaming skill may have an intent that conflicts with the invocation name of another skill -ie, the user may wish to open another skill but find that the audio streaming skill "hijacked" their request because the invocation name for the other skill triggered an intent in the audio streaming skill. But, that problem is solvable a few different ways - put greater restrictions on the intents that can be accessed in this scenario, for example:
a "catch all" intent with nothing but a custom slot could not be allowed

any intent with words matching the invocation name of existing skills would not be allowed (they would be allowed during normal skill usage, but not in this more restricted context)

The current flash briefing content (per provider) is a 'one size fits all approach'. Everyone gets the same NPR briefing, for example.

There are many use-cases where user-specific information could be very powerful in the flash briefing, often in concert with interactive skills. Some examples:

• A sport team skill that (in the flash briefing) reminds you of your game time this weekend (or of changes), without you ever having to touch a calendar

• A retailer skill that (in a flash briefing) advises of significant deals, relevant to your buying history or explicit 'watch list'.

I think this would take flash briefing content 'to the next level'.
Please consider!

Room awareness enhancement: add popular device types such as Fan, Air Conditioner, Set-top-box and let users change device type to their favorite. Now Alexa app allows changing device type between Light and Switch for some smart plug devices. But it would be great if for any device, users can define it as light, fan, air conditioner or set-top-box... and the room awareness feature will help simplify voice command. Users just can say: turn on the air conditioner, turn on the fan...
This device-type-changing feature will be very powerful when an infrared/RF universal remote control like Broadlink is connected to alexa. All traditional “dumb” devices can be voice controlled by alexa taking advantage of the room awareness feature.

I would like my skill to be able to listen for specific responses, i.e. make Alexa bias towards utterances of one or multiple intents that I specify in the skill's response, for the next user input.

For example, let's say my skill has a CityIntent which has utterances:

• I live in {city}
• It is {city}
• {city}

And my skill has another MovieIntent which has utterances:

• I like {movieType}
• I prefer {movieType}
• {movieType}

And at certain times my skill may also expect {yes/no} answer from user.

Since {city} and {movieType} have different value, Alexa usually does a good job of figuring out which intent should be mapped.

However, sometime the single word utterances are incorrectly mapped to wrong intents, and there's very little or hacky way for my skill can cope with such cases.

Therefore I want my skill to have the ability to specify what the NEXT intention user is likely to make, at any point during conversation. Then Alexa can bias the listening towards the likely utterances and map to the correct intents.

I have looked into DialogModel, however it doesn't seem to be applicable because it doesn't allow switching intent, i.e. my code cannot be handling MovieIntent and then request Alexa to ElicitSlot for CityIntent.

Thanks!

We would like to use this, but can't because the rules are too restrictive.If a user is asked about what they want info about, they should not be forced to say "tell me about Point Defiance Zoo". They should be able to say "Point Defiance Zoo" with no leading phrase. Instead of forcing us to use a leading or trailing phrase, please allow the use of just {query} (without 'search for...' or other text around it as in the example below:
{

    "name": "SearchIntent",

    "samples": [

      "search for {Query}",

      "find out {Query}",

      "search for {Query} near me"

    ],

    "slots": [

      {

        "name": "Query",

        "type": "AMAZON.SearchQuery"

      }

    ]

  }

The audio player interface allows playing from a streaming service - e.g. a radio station
This is a continuous stream that could run for many hours - but the skill is only given the opportunity to provide song information at the start.
It could respond to user requests - such as "What song is this?" (which is OK) but, primarily for devices with screens, it would be useful for the skill to be able to provide title/subtitle/graphics as the songs change within the continuous stream.

This could be done by having the Skill start the audio stream with a duration parameter which would result in a callback when it is about to be reached - similar to the PlaybackNearlyFinished request.
The Skill could then send new metadata (potentially with an offset to say display in X seconds) and with a new duration parameter.

An alternative approach that could work without any skill being developed at all ...
If the player automatically took the metadata from an ICY stream (as provided by Shoutcast / Icecast servers) then it would be a good alternative - especially if the skill to parse a regex that should be used to parse the ICY title - with a default that would handle "artist name - song title" which is what many internet radio stations use (and StreamURL for the image).
For example ...
Playing http://www.dandelionradio.com/DandelionRadio.pls.

Name : Dandelion Radio
Genre : Alternative
Website: http://www.dandelionradio.com
Public : yes
Bitrate: 128kbit/s
ICY Info: StreamTitle='Rocker: D. A. Stern - Isn't It Obvious?';StreamUrl='http://www.dandelionradio.com/images/drlogosq-black.jpg';

Right now a routine is triggered by a voice command or specific time. However, some routines are to be triggered by voice and time.

For example:
Alexa, good night. Will turn of the lights, etc.
But you want this routine to run at certain time, say 22:00, in case you forgot or because you don’t want to say even the command, etc.
Currently to achieve this you would have to recreate the entire skill by hand, as were is no copy function either, but this time change the trigger. This is extremely annoying and worsens as the actions in the routine increase in count.

Alternatively, a solution to this problem would be to be able to run routines from inside other routines, so that the setup for the second routine, as stated before, would be much quicker and easier.