Dynamic OK

[elmar-hinz]

I like to come up with an alternative to ok_suppression: #158 to improve dialogues. It's an alternative to, not a replacement of the suppression feature. That's why I give it it's own feature request.

While suppression is followed by a new call to the skill or a call to the media_player, this idea executes it all within one connection to the skill, by planning ahead.

Let's say the possible answers are YES and NO. Then we send along with the question one response per possible answer:

{
event_id: 123,
text: "Do you want to hear some music?",
confirmation_yes:  "Here we go.",
confirmation_no: "Maybe later."
}

This dynamically replaces the dumb okay confirmation. Compared to the suppression feature the latency is reduced.

[elmar-hinz]

This would require some conceptional work before, to get a uniform configuration.

For example in case of a number intent there could be a level to separate to different confirmations. "You like it cold!", "You like it hot!".

[DEADSEC-SECURITY]

Lets first figure out #158 and then i can work on this. This might be a bit harder to implement for now

[DEADSEC-SECURITY]

Well this would make supression #158 kinda useless cuz you could pass false or none or a empty string to supress a response for yes or no for example

[DEADSEC-SECURITY]

Well for other intents I was wondering how to set them up cuz i think its not very intuitive to have like 2 settings for every intent. Do you have anything in mind? @elmar-hinz

[DEADSEC-SECURITY]

Just had an idea. We could create a rule set. Like:

{
   "rules":{
      "int":{
         "bigger_then":{
            "value":10,
            "text":"hi bigger then 10"
         },
         "smaller_then":{
            "value":10,
            "text":"hi smaller then 10"
         }
      },
      "str":{
         "equals":{
            "yes":"hey"
         }
      }
   }
}

[DEADSEC-SECURITY]

something in those lines

[elmar-hinz]

Well I think we should keep it in mind but not take action immediately. Let's see what ppl ask for within the next months.

[elmar-hinz]

I did a protocol of the interaction latencies:

normal + second call:

• question
• 0 sec
• beep
• answer given
• 1 sec
• beep
• 0 sec
• okay
• 1 sec
• second call confirmation

suppression + second call:

• question
• 0 sec
• beep
• answer given
• 1 sec
• beep
• 1 sec
• second call confirmation

There is this sequence "1 sec, beep, 1 sec". That is fast enough though still a little annoying.

Here a prepared confirmation, that replaces "okay", would save one second.

• question
• 0 sec
• beep
• answer given
• 1 sec
• beep
• 0 sec
• prepared confirmation

[elmar-hinz]

I did some research how to send more complex data by the REST API because the input_text is limited to 255 chars.

• https://community.home-assistant.io/t/service-to-set-attribute-of-input-text/517634
• https://community.home-assistant.io/t/rest-api-message-with-more-than-255-characters/515159/2

The solution is basically in using attributes instead of value. That would bring in a python script to be able to set attributes. So it would make the setup more complex. That is an argument against this approach.

[DEADSEC-SECURITY]

Sorry @elmar-hinz I havent been very active. Have been busy with another project reversing a medical device and that has been a big project so maybe next week ill get back to this.

[elmar-hinz]

Got slowly. It's your leisure time. :)