Cloud: Long-running actions return “not responding” response

[bachya]

Make sure you are running the latest version of Home Assistant before reporting an issue.

You should only file an issue if you found a bug. Feature and enhancement requests should go in the Feature Requests section of our community forum:

Home Assistant release (hass --version): 0.60.0

Python release (python3 --version): 3.6.1

Component/platform: cloud

Description of problem: Long-running actions cause Alexa to return a “Hmm... XYZ isn’t responding” response (even when the action is successful).

Expected: Since Amazon has a timeout that (as far as I know) can’t be worked around, the component should asynchronously return an “OK” response (much like the intent_script component does).

Problem-relevant configuration.yaml entries and steps to reproduce:

cloud:

1. Implement a long-running action (e.g., a scene).
2. Attempt to activate it via Cloud-Alexa.

Traceback (if applicable): N/A

[RiRomain]

I guess it would be preferable to let the scene handle that, no?

For example avoid using delay and prefer starting a timer.

Which concrete component/action poses a problem? (for my understanding)

[bachya]

That’s intriguing! I’m open to putting the solution wherever it fits best.

For me, issue is most noticeable with SimpliSafe: arming/disarming can take 6+ seconds.

Reference: https://github.com/home-assistant/home-assistant/issues/8609

[RiRomain]

I suppose one way of doing it, is to setup an automation that is triggered when the scene is activated. This automation taking care of changing the status of those long-running action.

And to always return "Ok" might have unwanted consequence, if I say "Please lock the front door", I pretty much would like to know if something went wrong :smile:

Is there no way to define scene or grouped action in Alexa? So that Alexa take care of setting every component one by one.

[OverloadUT]

I think putting the onus of this on the user is the wrong way to go. The VUI convention here is to send the response the Alexa skill the moment you know what you need to do, unless you need to wait to actually build the response. In the case of home automation devices, since you are often just saying "okay", it should respond the moment Hass receives the intent.

[RiRomain]

I suppose that's because it should be an home automation devices, and not a group controlling 10 of them ^^

[OverloadUT]

No, I say it makes no difference. The guidelines for when to return a response in a VUI is the moment you have enough information to give the response. Often times this will be BEFORE the full processing is done behind the scenes - you just need to get to the point where you are reasonably sure you can give an accurate response to the user.

In the context of Home Assistant controlling a group of lights, it should be the moment the skill is able to successfully hit the Hass endpoint to turn on the lights. It should not wait for all of the internal Hass logic to finish - if we hit the endpoint, have Alexa say "okay" and call it a day.

This CAN create occasional frustration with Alexa saying "okay" when the command didn't actually complete successfully, but this is way, way offset by the importance of a FAST response from a skill. Every fraction of a second you make the user wait for a response in a VUI is death. It's the single most important thing to try to get as good as possible.

[balloob]

The cloud will automatically close a request after 5 seconds.

Alexa Smart Home v3 supports sending DeferredResponse and sending the actual result later:

• https://developer.amazon.com/docs/smarthome/build-smart-home-skills-for-locks.html#slow-locks
• https://developer.amazon.com/docs/device-apis/alexa-interface.html#deferredresponse

So in 4.5 seconds, we should automatically send a DeferredResponse and send the actual result when it is done.

[balloob]

Hmm, it looks like Alexa will report it as failed after 8 seconds, even if a DeferredResponse has been submitted.

[balloob]

We don't know if a service succeeds, so blocking the request until it is done seems unnecessary. @OverloadUT is right here and we should just create the response.

[balloob]

https://developer.amazon.com/docs/device-apis/alexa-interface.html#response

If a directive is successfully handled, you should respond with an Response event. A Response can be sent from a Lambda function to Alexa or from your device cloud to the Alexa event gateway. When you send a response event you should report the value of affected properties in the context of the message.

We currently don't do this last part. If we would do that, it would mean that we can't just send a positive response right away.

CC @pvizeli