Config and Option Flow for Govee Light Local

[Galorhallen]

Breaking change

Proposed change

This PR updates the config flow and add an option flow to Govee Light Local.
The config flow now allows the user to enable or disable the automatic discovery of the lights in the network
The option flow allows to:

• Enable or disable the discovery
• Manually add a device via its IP address
• Remove a device added manually to the integration

This changes should allow user that can't or won't enable the discovery to manually add and control devices.
It should also help users with a network setup that doesn't allow multicast across VLANs (the devices discovery uses multicast UPD to discover devices in the network)

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: Add support for filling in IP in Govee Local API (VLAN Issue) #109993 and Issues with Govee Local and multiple VLANs #115611
• Link to documentation pull request: Config and Option Flow for Govee Light Local home-assistant.io#38148
• Link to developer documentation pull request:
• Link to frontend 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.

To help with the load of incoming pull requests:

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

[joostlek]

How does a manual IP work if we still connect with them via UDP?

[Galorhallen]

How does a manual IP work if we still connect with them via UDP?

The library will send a discovery packet to the specific IP, and when the entity responds, it will be treated as an update to the entity that is already being tracked via discovery.
Each entity internally tracks whether it has been manually added or not.

Now that you mention this, could a "manual takeover" option make sense?

[joostlek]

I'm more wondering if the integration can't just go to a 1 entry 1 device set up in a way

[Galorhallen]

I'm more wondering if the integration can't just go to a 1 entry 1 device set up in a way

I don't think that is possibile: the devices still reports back their status and the responses to the unicast discovery to the same port (4002), so they still require a single instance "hub".