Get rid of okay confirmation

[elmar-hinz]

Feature request

The dialogue should be:

• Alexa: "Do you like dogs?"
• You: "Yes"
• Alexa: "Cool, I like dogs too"

The dialogue is:

• Alexa: "Do you like dogs?"
• You: "Yes"
• Alexa: "Okay"
• Alexa: "Cool, I like dogs too"

Wanted:

An option to suppress the automatic "okay" confirmation, if you want to handle the confirmation yourself. Something like this:

  - service: script.activate_alexa_actionable_notification
    data:
      text: Yes or no?
      suppress_confirmation: True
      event_id: hello_world
      alexa_device: media_player.<Your Media Player>

[elmar-hinz]

Technical considerations

The OK seems to be worded in language_strings.json. Maybe it could be a workaround to temporarily set the value to an empty string.

Better, if ask_sdk_core has an API to control this. I guess the behaviour is originating there. OK is not actively called within lambda_function.py at least.

[DEADSEC-SECURITY]

This is fixed under the branch. Pending testing @elmar-hinz. If you could also give it a try and let me know if you find bugs

[DEADSEC-SECURITY]

Im fixing bugs though so might not work yet

[elmar-hinz]

One concern per commit. Please just don't mix bug fixing and features into one commit. It's difficult to track.

[DEADSEC-SECURITY]

Done fixed. Did some refactoring too cuz it was hard debugging the original code. In my example I call the service like this.

My script looks like this:

alias: Alexa Home Voice Ask
description: Activates an actionable notification on a specific echo device
fields:
  text:
    description: The text you would like alexa to speak.
    example: What would you like the thermostat set to?
  event_id:
    description: Correlation ID for event responses
    example: ask_for_temperature
  suppress_confirmation:
    description: If it should supress the Okay default response confirmation
    example: true
  alexa_device:
    description: Alexa device you want to trigger
    example: media_player.bedroom_echo
sequence:
  - service: input_text.set_value
    data:
      entity_id: input_text.alexa_actionable_notification
      value: >-
        {"text": "{{ text }}", "suppress_confirmation": "{{
        suppress_confirmation }}", "event": "{{ event_id }}"}
  - service: media_player.play_media
    data:
      entity_id: "{{ alexa_device }}"
      media_content_type: skill
      media_content_id: amzn1.ask.skill.87fb0d7f-dd0b-4bd1-92ef-3f59187374ae
mode: single

[DEADSEC-SECURITY]

Now just need to update docs to reflect this change and should be good to go.

If you could test @elmar-hinz I would appreciate.

[DEADSEC-SECURITY]

We could also have the option to send a custom response message as well as be able to suppress it

[DEADSEC-SECURITY]

@elmar-hinz

[elmar-hinz]

A am gonne check it out this evening.

[elmar-hinz]

I started further testing now. The first problem to solve was how to import a branch as a skill. Would the import use the master branch or the default branch of my fork?

After making the development branch the default branch, the import did call the development branch as source for the import. That simplifies testing.

[elmar-hinz]

@DEADSEC-SECURITY I didn't get the branch running. It doesn't create a response any more. There is no JSON output on the right.

I did call the default launch request:

I will replace lambda_function.py with the version of master, to see if it is running again.

[elmar-hinz]

With the code of the master branch it is working again. This confirms a bug. Did you put too many changes into one pull request? ;-)

[DEADSEC-SECURITY]

I did do some refactoring but in my alexa it was working properly.

[DEADSEC-SECURITY]

@elmar-hinz

[DEADSEC-SECURITY]

Can you share cloudwatch logs @elmar-hinz