Skip to content

Improve Home Assistant recognition reliability - #6

Open
booyasatoshi wants to merge 1 commit into
EuleMitKeule:masterfrom
booyasatoshi:ha-recognition-reliability-fixes
Open

Improve Home Assistant recognition reliability#6
booyasatoshi wants to merge 1 commit into
EuleMitKeule:masterfrom
booyasatoshi:ha-recognition-reliability-fixes

Conversation

@booyasatoshi

Copy link
Copy Markdown

Summary

This PR improves reliability of the Home Assistant custom integration runtime recognition path.

The changes are intentionally limited to:

  • custom_components/speaker_recognition/recognition.py
  • custom_components/speaker_recognition/stt.py

This avoids mixing runtime reliability fixes with UI, branding, config-flow, or conversation-agent behavior changes.

What changed

Media source file resolution

The integration now resolves Home Assistant local media-source voice samples from both:

  • /media/<relative path>
  • hass.config.path("media")/<relative path>

It also URL-decodes the local media-source path before resolving it.

This makes voice sample training more reliable across Home Assistant OS/container layouts where the selected media file may exist under /media rather than only under Home Assistant's configured media path.

Defensive voice sample handling

The training path now validates configured voice sample entries before using them.

It also accepts the older one-item list shape for the media selector value, while rejecting invalid, empty, or multi-file values.

This helps avoid breaking existing saved options if the selector shape changed or if older configuration data is still present.

Avoid blocking the Home Assistant event loop

Backend train and recognize calls are now run through Home Assistant's executor instead of being awaited directly in the entity's async path.

This prevents backend/client work from running directly on Home Assistant's event loop.

Training result handling

The training path no longer depends on a specific TrainingResult.users_trained response attribute.

The previous logging assumed that field existed, but the installed/backend client may not expose it consistently.

Logging cleanup

Successful speaker recognition is now logged at info level instead of error level.

Actual exceptions during recognition are still logged as errors.

A recognition attempt returning no result is logged as a warning instead of an error.

Why

These changes make the Home Assistant integration more tolerant of real Home Assistant media paths, older saved selector data, backend response differences, and blocking backend calls.

They also make logs clearer by avoiding error-level messages for successful recognition.

Testing

Tested locally in Home Assistant with the speaker recognition STT proxy and conversation proxy.

Observed behavior:

  • Integration loads successfully.
  • Voice samples train successfully from Home Assistant local media.
  • Recognition runs after STT processing.
  • speaker_recognition_detected events are still fired.
  • Last recognition result is still stored in hass.data for conversation use.
  • Successful recognition is no longer logged as an error.

Also ran:

python3 -m py_compile \
  custom_components/speaker_recognition/recognition.py \
  custom_components/speaker_recognition/stt.py

python3 -m compileall custom_components/speaker_recognition

@booyasatoshi

Copy link
Copy Markdown
Author

Hey folks, I am following up on this PR. Is this repo being maintained or watched by anyone? Could a maintainer approve the workflow when possible so we can move on the better things?

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Labels

None yet

Projects

None yet

Development

Successfully merging this pull request may close these issues.

1 participant