Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Make BT support detection dynamic for Shelly RPC devices #137323

Draft
wants to merge 9 commits into
base: dev
Choose a base branch
from

Conversation

chemelli74
Copy link
Contributor

Proposed change

Some devices, even if gen2+, has support for BT but not for scripts.
With the introduction of XMOD devices, "model" is no more reliable for such detection.

This PR test for the real capability so that is no more linked to a static list of devices.

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:
  • Link to documentation pull request:
  • 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:

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 Feb 4, 2025

Hey there @balloob, @bieniu, @thecode, @bdraco, mind taking a look at this pull request as it has been labeled with an integration (shelly) you are listed as a code owner for? Thanks!

Code owner commands

Code owners of shelly 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 shelly 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
Member

@thecode thecode left a comment

Choose a reason for hiding this comment

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

The approach looks good, left some comments

homeassistant/components/shelly/coordinator.py Outdated Show resolved Hide resolved
homeassistant/components/shelly/config_flow.py Outdated Show resolved Hide resolved
@chemelli74 chemelli74 marked this pull request as ready for review February 4, 2025 18:21
@@ -460,7 +483,7 @@ def async_supports_options_flow(cls, config_entry: ConfigEntry) -> bool:
return (
get_device_entry_gen(config_entry) in RPC_GENERATIONS
and not config_entry.data.get(CONF_SLEEP_PERIOD)
and config_entry.data.get("model") != MODEL_WALL_DISPLAY
and config_entry.data.get(CONF_SCRIPT, True)
Copy link
Member

Choose a reason for hiding this comment

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

We need the config_entry.data.get("model") != MODEL_WALL_DISPLAY condition here in addition, the update of the entry data will happen after this is evaluated and will be incorrect

Comment on lines +87 to +91
# Model Wall Display does not support scripts
# even if Script.List method is available
if device.model == MODEL_WALL_DISPLAY:
return False

Copy link
Member

Choose a reason for hiding this comment

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

Suggested change
# Model Wall Display does not support scripts
# even if Script.List method is available
if device.model == MODEL_WALL_DISPLAY:
return False

Comment on lines 243 to 249
if entry.data.get(CONF_MODEL) == MODEL_WALL_DISPLAY and not entry.data.get(
CONF_SCRIPT
):
data = {**entry.data}
data[CONF_SCRIPT] = False
hass.config_entries.async_update_entry(entry, data=data)

Copy link
Member

Choose a reason for hiding this comment

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

This will happen only after the config flow has already evaluated the condition if options are allowed or not and is not effective until device is reloaded, I also think it just complicates the PR, PR was already ready with a very simple solution, why do we need to complicate it?

Suggested change
if entry.data.get(CONF_MODEL) == MODEL_WALL_DISPLAY and not entry.data.get(
CONF_SCRIPT
):
data = {**entry.data}
data[CONF_SCRIPT] = False
hass.config_entries.async_update_entry(entry, data=data)

Copy link
Contributor Author

Choose a reason for hiding this comment

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

I think that if we store for other devices the info of script=False and we know a device should be listed, we should update it.

The best option is indeed to migrate the config entry.
But I applied the same we did for the wrong sleep period.

Copy link
Member

Choose a reason for hiding this comment

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

but as I explained it won't work for the first time as the device will load with the older value, this also makes a simple PR complicated, I already tested and validated a very simple solution (which you created) and now we complicate it. It would also mean we need to add tests for the migration of the data

@home-assistant home-assistant bot marked this pull request as draft February 4, 2025 18:27
@home-assistant
Copy link

home-assistant bot commented Feb 4, 2025

Please take a look at the requested changes, and use the Ready for review button when you are done, thanks 👍

Learn more about our pull request process.

@@ -460,7 +483,7 @@ def async_supports_options_flow(cls, config_entry: ConfigEntry) -> bool:
return (
get_device_entry_gen(config_entry) in RPC_GENERATIONS
and not config_entry.data.get(CONF_SLEEP_PERIOD)
and config_entry.data.get("model") != MODEL_WALL_DISPLAY
and config_entry.data.get(CONF_SCRIPT, True)
Copy link
Member

Choose a reason for hiding this comment

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

Suggested change
and config_entry.data.get(CONF_SCRIPT, True)
and config_entry.data.get(CONF_SCRIPT, True)
and config_entry.data.get("model") != MODEL_WALL_DISPLAY

@chemelli74
Copy link
Contributor Author

Coding completed and tested in all variations I was able to.
Will add tests once the Team agree on the approach.

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.

5 participants