Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

assist on web client and android cannot start timers #120058

Open
dj-sf opened this issue Jun 21, 2024 · 2 comments
Open

assist on web client and android cannot start timers #120058

dj-sf opened this issue Jun 21, 2024 · 2 comments

Comments

@dj-sf
Copy link

dj-sf commented Jun 21, 2024 •
edited

The problem

I have been trying to get voice activated timers working for several days now. First I tried using the built in HassStartTimer intent, being sure to adhere to the sentence structures I saw in the yaml file. This only ever produced "Sorry, I couldn't understand that" responses.

I made a HA forum post about this and was told it may be due to the require_context: area param. So I created a custom version of the sentences file (timers.yaml) with that section removed. This led to to new behavior; it correctly interpreted the intent but says the requesting device is incompatible with timers.

Yaml & assist conversation text below:

Default conversation behavior:
image

modified timers.yaml without require_context block:

---
language: "en"
intents:
  HassStartTimer:
    data:
      - sentences:
          - "<timer_duration> timer"
          - "timer for <timer_duration>"
          - "<timer_duration> timer for {timer_name:name}"
          - "timer for <timer_duration> (named|called) {timer_name:name}"
          - "<timer_set>[ a] <timer_duration> timer"
          - "<timer_set>[ a] timer for <timer_duration>"
          - "<timer_set>[ a] <timer_duration> timer (named|called|for) {timer_name:name}"
          - "<timer_set>[ a] timer (named|called) {timer_name:name} for <timer_duration>"
          - "<timer_set>[ a] timer for <timer_duration> (named|called) {timer_name:name}"
      - sentences:
          - "{timer_command:conversation_command} in <timer_duration>"
          - "in <timer_duration> {timer_command:conversation_command}"
        response: command

behavior with custom timers.yaml file:
image

What version of Home Assistant Core has the issue?

core-2024.6.3

What was the last working version of Home Assistant Core?

No response

What type of installation are you running?

Home Assistant OS

Integration causing the issue

No response

Link to integration documentation on our website

No response

Diagnostics information

No response

Example YAML snippet

No response

Anything in the logs that might be useful for us?

No response

Additional information

Link to forum post: https://community.home-assistant.io/t/hassstarttimer-built-in-intent-not-working-with-assist/741117/4
@dj-sf
Copy link
Author

dj-sf commented Jun 21, 2024

brief update -- i tried labeling my devices with an "area" to see if this made a difference. it did not.

@dj-sf
Copy link
Author

dj-sf commented Jun 23, 2024 •
edited

After some tinkering locally, I've discovered a few things.

  1. The default HassStartTimer intent initially does not match due to the missing "area" property when running from web client (breakpoint stops here revealing "area" listed in maybe_result.unmatched_entities.)
  2. When using the custom version of that intent without the Area requirement ( see timers.yaml from original post) , the error being thrown is the TimersNotSupportedError on line 815 of the dev branch. This is because it fails the logic check that occurs immediately beforehand -- conversation_command & intent_obj.device_id are both None, and the device, not having an id, is not registered with the timer_manager.

Therefore, I'd like to propose some possible fixes:

First, we should either remove the area requirement from the default intent OR give the clients some sort of placeholder area value so that requirement is fulfilled.

Second, we should either modify the default attributes of the web & mobile clients so that they can pass this logic check out of the box OR we should change this logic to allow them to use the timer intents with their current attributes.

@synesthesiam I see that you have worked on the timer logic quite a bit. Do you know if any of these proposed solutions might work?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
1 participant
@dj-sf