Skip to content

Automatically detect device class in vizio config flow - #177642

Open
raman325 wants to merge 1 commit into
home-assistant:devfrom
raman325:vizio-auto-device-class
Open

Automatically detect device class in vizio config flow#177642
raman325 wants to merge 1 commit into
home-assistant:devfrom
raman325:vizio-auto-device-class

Conversation

@raman325

Copy link
Copy Markdown
Contributor

Proposed change

Follow-up to the review discussion on #177590, where @gjohansson-ST asked whether the reconfigure flow should also cover device class/token. Rather than exposing the device class in more flows, this PR removes the "Device type" selector from the config flow entirely and detects it automatically. A revised reconfigure flow building on this will come in a separate PR — the scope here is intentionally only the auto-classification.

  • The "Device type" field is removed from the user step schema, along with its strings.json entry and the DEFAULT_DEVICE_CLASS constant.
  • The device class is now detected automatically using the same probe zeroconf discovery already uses: vizaio's async_is_tv, which makes a single unauthenticated request to the SmartCast audio-settings endpoint (sound bars answer without auth, TVs reject it until paired).
  • Detection is shared via a new _async_detect_device_class helper, which also passes Home Assistant's shared aiohttp session into async_is_tv (the zeroconf path previously created its own session).
  • The zeroconf step passes the detected class into the user step, which only probes when the class isn't already provided.
  • A wrong guess cannot create a bad entry: the serial-number fetch immediately afterwards aborts with cannot_connect if the device isn't reachable.
  • Existing config entries are unaffected (device_class remains stored in entry data). Not a breaking change — the setup form simply has one fewer field.
  • Tests: a new vizio_detect_tv fixture was added, and the two user-form-path tests now cover both detection outcomes (TV and speaker). All 82 vizio tests pass locally.

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

Checklist

  • I understand the code I am submitting and can explain how it works.
  • 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.
  • Any generated code has been carefully reviewed for correctness and compliance with project standards.

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

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 diff between library versions and ideally a link to the changelog/release notes is added to the PR description.

To help with the load of incoming pull requests:

Remove the device type selector from the user flow and detect whether
the device is a TV or a speaker with the same probe zeroconf discovery
already uses. A wrong guess cannot create a bad entry since the serial
number fetch validates reachability right after.

Co-Authored-By: Claude Fable 5 <noreply@anthropic.com>

Copilot AI left a comment

Copy link
Copy Markdown
Contributor

Choose a reason for hiding this comment

The reason will be displayed to describe this comment to others. Learn more.

Copilot was unable to review this pull request because the user who requested the review has reached their quota limit.

@raman325
raman325 marked this pull request as ready for review July 30, 2026 12:48
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Projects

None yet

Development

Successfully merging this pull request may close these issues.

2 participants