Sentence triggers in "wait for"

[west gate]

So I created the script, that could be the building brick to the functionality of continuous conversation in Assist:
https://pastebin.com/CwUaJFLq

And it works. The trouble is, that even with conversation response set, it still says "done" and that's it.
Why?..

And yes, it's awesome it can do it!
@shut horizon sorry for ping - I know you're experienced in this.

[peak elk]

Does the response need to be the last action?

[west gate]

Well it depends on trigger sentence, so it's after "wait" section...

[west gate]

Or you mean it should always be last? Will it work with result delivery before it?

[peak elk]

Yeah that's what I'm not sure of. I'm wondering if it's saying Done because the stop command is at the end instead of the conversation response 🤷

Maybe they need to switch places?

[west gate]

Switched. Same... Result delivered, answer "done"

[peak elk]

If you hardcode the response to a string does that work?

Think there was a bug around something like this a long time ago, though that was for the automation ui i think.

[west gate]

Hardcoded, tried on different positions - doesn't work...

Could it be that setting the response works only for automations?

[peak elk]

Huh good point, could be 🫤

[west gate]

That'd be a bummer.

I'd prefer in that case it'd work without audible response at all...

[peak elk]

Could the script be wrapped in an automation maybe?

And use the result of the script to set conversation reply in the automation?

[west gate]

Yeah it could be, but then there should be a trigger, and no fields...

[peak elk]

Why no field? Seems they are supported in automations https://www.home-assistant.io/integrations/script#passing-variables-to-scripts

[west gate]

I see what you're talking about. Let me try

triggers:
  - trigger: conversation
    command:
      - pc is working
actions:
  - action: script.ask_and_wait_yes_no_response
    data:
      f_area: 113428be048742a898b9d11f1bc046dc
      f_question: Turn it off now?
    response_variable: result
  - set_conversation_response: Did it!

Works great, but still does response "done" 😦

[peak elk]

So weird. I have an automation that uses the set response and it is working correctly..

[west gate]

Yeah i guess the trick is in wait for trigger

I made it working by doing it via intent script for yes and no - but that thing is full of redundancy and clunkiness

This script looks flawless - but this one thing makes it useless...

[shut horizon]

Pretty much to unpack here... i'll give it a go
Your {{ v_va_start_action }} starts a pipeline on the calling satellite. That pipeline does not specifically wait for your sentence trigger (yes/no), you can ask it to turn off lights if you wanted to (in which case, your wait_for_trigger will simply time out). As such, it will respond with whatever the conversation component (via default_agent) instructs it to respond.
The implementation of sentence triggers relies on the fact that they are triggers for starting automations HassJobs. As such, when declared, registered and attached, the trigger explicitly waits for its parent job to finish in order to access the conversation_result variable in the automation result
I must admit i don't know if this can be overcome in any way, but it seems to me that the conversation_result needs to be set in the same automation/script as the sentence trigger. I'll keep digging

[shut horizon]

After further testing, it seems that wait_for_trigger (expectedly) does not return a ScriptRunResult
The question of how set_conversation_response should be used with wait_for_trigger was never answered
A long, long time ago, in a galaxy far away, someone tried to tackle this use case too, by allowing you to tie the response directly on the trigger. Since it did not meet expectations, here we are today 😅

[west gate]

Daaaamn, thanks for this ton of information! That's very helpful! Also I'm fascinated that I unwind same road you went.
Do you maybe think it's worth reviving now? It's been a year, and now voice is stronger than ever. We need this.

I believe the best way is not to wait for automation to finish completely to deliver response, but have explicit action on pipeline ending with response. Then automation could finish the voice pipeline, and continue running after. Also single automation could hold several pipeline runs.

[shut horizon]

In all fairness, it's high time for a new architecture which supports actual conversations instead of workarounds. I don't imagine the core/voice team would fancy workarounds, they never did 🙂
However, I won't be the one to implement that. I've devoted too much time and received too little satisfaction in return to go down that path again. I'm just a happy user nowadays, waiting for stuff to be released 😅