Report missing entities/areas instead of failing to match in Assist

[synesthesiam]

Breaking change

Proposed change

This PR:

• Bumps hassil to 1.5.2: home-assistant/hassil@v1.5.1...v1.5.2
• Adds better error messages for unmatched names and areas
• Cleans up conversation tests to use snapshots instead of literal comparisons where appropriate

Hassil, the intent matching library behind Assist, will report an intent match failure if the names of entities or areas are not what it expects by default ("Sorry, I couldn't understand that").

This PR uses a new feature of hassil 1.5.2 to produce more useful error messages. If a match fails, hassil is run again with "unmatched entities" enabled (slower), and the "best" match is used to determine the error message.

Choosing the "best" match is tricky. For example, "turn on the overhead light" could be interpreted as:

• turn on the <name> with name = "overhead light"
• turn on the <area> <name> with area = "overhead", name = "light"

In fact, there are many more possible matches, some including "the" in the entity or area name, etc.
The "best" match is the one with:

1. The fewest matching slots, so <name> or <area> will be preferred to <area> <name>
2. The most literal text matching the sentence template, so "the" will not be part of <name>

Only errors relating to unmatched <name> and <area> slots are currently supported. Errors for unmatched domains and device classes require more changes, and will be done in a future PR.

Type of change

• Dependency upgrade
• Bugfix (non-breaking change which fixes an issue)
• New integration (thank you!)
• New feature (which adds functionality to an existing integration)
• Deprecation (breaking change to happen in the future)
• Breaking change (fix/feature causing existing functionality to break)
• Code quality improvements to existing code or addition of tests

Additional information

• This PR fixes or closes issue: fixes #
• This PR is related to issue:
• Link to documentation pull request:

Checklist

• The code change is tested and works locally.
• Local tests pass. Your PR cannot be merged unless tests pass
• There is no commented out code in this PR.
• I have followed the development checklist
• I have followed the perfect PR recommendations
• The code has been formatted using Ruff (ruff format homeassistant tests)
• Tests have been added to verify that the new code works.

If user exposed functionality or configuration variables are added/changed:

• Documentation added/updated for www.home-assistant.io

If the code communicates with devices, web services, or third-party tools:

• The manifest file has all fields filled out correctly.
  Updated and included derived files by running: python3 -m script.hassfest.
• New or updated dependencies have been added to requirements_all.txt.
  Updated by running python3 -m script.gen_requirements_all.
• For the updated dependencies - a link to the changelog, or at minimum a diff between library versions is added to the PR description.
• Untested files have been added to .coveragerc.

To help with the load of incoming pull requests:

• I have reviewed two other open pull requests in this repository.

[home-assistant]

Hey there @home-assistant/core, mind taking a look at this pull request as it has been labeled with an integration (conversation) you are listed as a code owner for? Thanks!

Code owner commands

Code owners of conversation can trigger bot actions by commenting:

• @home-assistant close Closes the pull request.
• @home-assistant rename Awesome new title Renames the pull request.
• @home-assistant reopen Reopen the pull request.
• @home-assistant unassign conversation Removes the current integration label and assignees on the pull request, add the integration domain after the command.
• @home-assistant add-label needs-more-information Add a label (needs-more-information, problem in dependency, problem in custom component) to the pull request.
• @home-assistant remove-label needs-more-information Remove a label (needs-more-information, problem in dependency, problem in custom component) on the pull request.

[tetele]

@synesthesiam should we make the error messages a bit more friendly, more user-readable, while we're at it? Something like "Sorry, I am not aware of any area named dungeon" or "Sorry, I am not aware of any entity called floodlights"?

[synesthesiam]

Yes, we need the errors to say that something couldn't be found, not that it isn't there.

I was thinking something like "Sorry, I couldn't find an area named X".

[tetele]

Correct me if i'm wrong: there are 2 possible reasons for which an entity can't be handled - either it doesn't exist with that name/alias or it's not exposed.

For areas, the only possible reason is that it doesn't exist with that name/alias.

I was thinking something like "Sorry, I couldn't find an area named X".

For me personally, it seems like "couldn't find" (traditionally, in UIs) hints more towards inexistence and less towards lack of exposure, whereas "I am not aware" is vague enough to hint to both. Shall we ask the Discord community? Do you want to take an executive decision? :D

[synesthesiam]

I do like the "not aware" terminology" better than "couldn't find".

This question gets trickier with domain and device class constraints. A failure with "turn on lights in the kitchen" could be a missing area, no lights in the kitchen, or just no exposed lights. I think for this case, we may want to have an extra definitive error: "there are no lights in the kitchen".