Enable Wemo option for subscriptions across subnets

[jherby2k]

Proposed change

Enables setting a "callback_address" (advanced option) in the Wemo integration to enable subscriptions when HA and the Wemo switches are on different subnets. Eliminates a recurring error message, and allows for instantanous updates when a Wemo device is operated physically or through the Wemo mobile app.

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

PYWEMO_CALLBACK_ADDRESS was recently enabled in pywemo to address this issue. This PR simply exposes a way to set this environment variable from HA.

• This PR is related to issue: Wemo plugs keep reconnecting to the network pywemo/pywemo#275
• Link to documentation pull request: Wemo callback address home-assistant.io#23442

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
• The code has been formatted using Black (black --fast 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.

The integration reached or maintains the following Integration Quality Scale:

• No score or internal
• 🥈 Silver
• 🥇 Gold
• 🏆 Platinum

To help with the load of incoming pull requests:

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

[probot-home-assistant]

Hey there @esev, mind taking a look at this pull request as it has been labeled with an integration (wemo) you are listed as a code owner for? Thanks!
_{^{(message by CodeOwnersMention)}}

[esev]

Thank you!

[frenck]

Shouldn't this be provided by the Network integration instead?

Additionally:

For integrations that connect to devices or services, we no longer accept new YAML configuration or changes.

This integration needs to be refactored first to use a configuration flow and config entries first.

More information about this can be found in Architecture Decision Record:

• ADR-0010: https://github.com/home-assistant/architecture/blob/master/adr/0010-integration-configuration.md#decision

See our developer documentation on how to get started creating a configuration flow for this integration:

https://developers.home-assistant.io/docs/config_entries_config_flow_handler

As these changes often involve a bit of work and some significant shift in the current code, we will close this PR for now.

We (and our community!) would really appreciate it if you could start on the refactoring of this integration in a new PR.

Thanks already! 👍

[jherby2k]

I don't see how this would go in the Network integration... it configures a pywemo-specific environment variable. Anyway, will rework after config flow is done. Beyond my current capabilities.

[esev]

Hi @frenck, could you provide feedback on #56972? I know I need to fix the merge conflict, but is the approach okay?

I've previously been told that integrations should not use a config entry per device. So that's why I went the route I did for #56972, making it a global config for the integration.

TBH, I have no idea how to replicate the static config without having a config entry per device.

[frenck]

Hi @frenck, could you provide feedback on #56972? I know I need to fix the merge conflict, but is the approach okay?

That is not related to this PR? I'm confused?

I've #44192 (comment) that integrations should not use a config entry per device.

Depends on who you ask and the use case. Some integrations benefit from using a per device approach. A good example is LIFX for which is a PR open right now to migrate to a per device based approach because of similar issues I guess 🤷

[esev]

Thank you! It's not directly related, but if the approach is okay I think this configuration option could be put in the same spot.

Edit: frenck said it should go in the Network integration instead. So definitely not related.