Skip to content

Conversation

@TheJulianJES
Copy link
Member

Proposed change

This PR changes ZHA's behavior to only automatically set up USB and hardware discovered coordinators (e.g. Yellow) when onboarding a new Home Assistant instance.

Zeroconf discovered network coordinators will no longer be set up without any confirmation before/during onboarding, instead requiring you to click on "Add" on the integrations page for the network coordinator you want to add.

Keeping original intent

USB and hardware discoveries, for which this was originally added (included in #76795), are unaffected by this change and will still be set up without any confirmation before/during onboarding. So, setting up a new HA Yellow or HA Green with a USB coordinator attached will still automatically configure ZHA.

Reasons behind this change

#153883 reported that before onboarding a new HA Blue, ZHA automatically discovered and configured a network coordinator that was already in use, wiping its settings in the progress, and breaking the main HA instance that was using this coordinator.

It's fine to keep the automatic setup for USB and hardware discoveries, as you have to make an explicit choice to plug in a USB coordinator before/during onboarding. With network coordinators, you do not have that choice, unless you want to fully disconnect your HA system before/during onboarding, but that's not ideal due to a lot of other reasons.

Since it's still easily possible to add network coordinators via the integrations page, we don't really add additional friction for first time users with network coordinators .

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 link to the changelog, or at minimum a diff between library versions is added to the PR description.

To help with the load of incoming pull requests:

@home-assistant
Copy link

home-assistant bot commented Oct 7, 2025

Hey there @dmulcahey, @Adminiuga, @puddly, mind taking a look at this pull request as it has been labeled with an integration (zha) you are listed as a code owner for? Thanks!

Code owner commands

Code owners of zha 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 zha 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.

Copy link
Contributor

Copilot AI left a comment

Choose a reason for hiding this comment

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

Pull Request Overview

This PR prevents ZHA from automatically setting up network coordinators discovered via Zeroconf during Home Assistant onboarding, addressing an issue where network coordinators already in use by other HA instances could be automatically configured and have their settings wiped.

  • Modifies the confirmation logic to exclude Zeroconf discoveries during onboarding
  • Preserves automatic setup for USB and hardware discoveries during onboarding
  • Adds test coverage for the new behavior when not onboarded

Reviewed Changes

Copilot reviewed 2 out of 2 changed files in this pull request and generated no comments.

File Description
homeassistant/components/zha/config_flow.py Adds condition to exclude Zeroconf source from automatic setup during onboarding
tests/components/zha/test_config_flow.py Adds test to verify Zeroconf discoveries require confirmation when not onboarded

@zweckj
Copy link
Member

zweckj commented Oct 7, 2025

If we do this, we should add a clear pointer in the documentation, that it needs to be done manually for network attached coordinators.

@TheJulianJES
Copy link
Member Author

AFAIK, we do not mention anywhere that we even automatically configure coordinators during onboarding. We certainly didn't document this auto-setup as intended for network coordinators, as we didn't intend it either, from what I can see.
From a quick look, I don't see other integrations with auto-setup during onboarding that documented this at least.

Just to clarify, the steps for configuring a coordinator on an existing HA instance stay the same.
This change only affects you if:

  • you already have a network coordinator plugged in on your network AND
  • are setting up a fresh HA instance from scratch at that time

If we wanted to add anything about this in the documentation, I'm not sure what it would be. The steps for configuring ZHA already point you to the correct place.
The auto-setup during onboarding makes sense to avoid users having to look at the documentation in the first place, so us describing our behavior in the docs about something after onboarding that doesn't matter now likely isn't really helpful.

I'd expect all users that buy a network-connected coordinator in the first place, possibly even with PoE, to be able to make a couple of clicks to get to the integrations page and confirm setup, where the network coordinator is still automatically discovered.

@puddly
Copy link
Contributor

puddly commented Oct 7, 2025

I think the original intent for this change was to have the Yellow radio be usable upon installation. Maybe we can restrict auto setup to just hardware integration discovery?

I guess it would be nice to have USB coordinators auto setup but there will be future config flow steps that will make this infeasible (e.g. confirmation step before wiping old settings from a coordinator).

@zweckj
Copy link
Member

zweckj commented Oct 7, 2025

Maybe you're right. I'm coming from the perspective that if some things behave differently then others, then that should be documented in case someone is wondering "why is this not working as I'm expecting it to" 🤷‍♂️

@puddly puddly added this to the 2025.10.2 milestone Oct 7, 2025
@puddly puddly merged commit 29bfbd2 into home-assistant:dev Oct 7, 2025
34 checks passed
@github-actions github-actions bot locked and limited conversation to collaborators Oct 8, 2025
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.

Projects

None yet

Development

Successfully merging this pull request may close these issues.

Onboarding - ZHA sets up network coordinators without confirmation

7 participants