Skip to content

Add Plugwise scan_interval config option#37229

Merged
bdraco merged 17 commits intohome-assistant:devfrom
plugwise:plugwise-config_options
Sep 6, 2020
Merged

Add Plugwise scan_interval config option#37229
bdraco merged 17 commits intohome-assistant:devfrom
plugwise:plugwise-config_options

Conversation

@bouwew
Copy link
Copy Markdown
Contributor

@bouwew bouwew commented Jun 29, 2020

Proposed change

Add OPTIONS to the config-flow: make it possible to change the interval between data-updates from the Smile(s).

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)
  • 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:

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:

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.
  • Untested files have been added to .coveragerc.

The integration reached or maintains the following Integration Quality Scale:

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

@probot-home-assistant
Copy link
Copy Markdown

Hey there @CoMPaTech, mind taking a look at this pull request as its been labeled with an integration (plugwise) you are listed as a codeowner for? Thanks!
(message by CodeOwnersMention)

Copy link
Copy Markdown
Member

@CoMPaTech CoMPaTech left a comment

Choose a reason for hiding this comment

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

OK from me as co-author

@bouwew
Copy link
Copy Markdown
Contributor Author

bouwew commented Jul 4, 2020

Ok, ready for rereview now, sorry, I'm still learning...

Copy link
Copy Markdown
Member

@CoMPaTech CoMPaTech left a comment

Choose a reason for hiding this comment

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

Looking good and functional on test and devcontainer

@frenck
Copy link
Copy Markdown
Member

frenck commented Jul 4, 2020

The tests need to be extended as the config flow requires a 100% test coverage.

Furthermore, do we really need this to be user-configurable? As in, in general we should have a sane default for the scan interval. Is there a specific reason for adding this?

@bouwew
Copy link
Copy Markdown
Contributor Author

bouwew commented Jul 4, 2020

@frenck Clear on the test-coverage requirement.

Several users have requested this feature, they would prefer to use different interval-values than were set as the defaults.
Also, there was no clear preference from the users which default scan_interval to set, so we've set them to the Core-default for Climate (60 secs) and to 10 sec for the Smile P1, as this is the DSMR scan interval. And promised to provide a settable scan_interval per Smile integration.

@MartinHjelmare MartinHjelmare changed the title Plugwise - Add config options - scan_interval Add Plugwise scan_interval config option Jul 5, 2020
@CoMPaTech
Copy link
Copy Markdown
Member

@frenck do you consider this a viable PR (the testing requirement is clear, but I guess we didn't trigger the 100% on config_flow in #37289 if I'm honest)

As in ... we can provide the required testing, either in this PR or the pending full(er) testing PR that's still open to solve the already merged zeroconf one.

@frenck
Copy link
Copy Markdown
Member

frenck commented Jul 14, 2020

I'm fine with a scan interval, just saying it is general better to avoid it. Hence my questioning.

The test requirements have to be met. Config flows require a 100% coverage.

@CoMPaTech
Copy link
Copy Markdown
Member

Still working on that, not much progress yet, aiming for next week

@CoMPaTech
Copy link
Copy Markdown
Member

Additional tests added

@CoMPaTech CoMPaTech mentioned this pull request Aug 4, 2020
20 tasks
@bouwew
Copy link
Copy Markdown
Contributor Author

bouwew commented Aug 8, 2020

@frenck What is the status of this PR from your point-of-view? Can this one be merged?

We are working on several fixes for the Plugwise integration, related to the recently reported issues.
This PR is kind of blocking our progress :)

@CoMPaTech CoMPaTech force-pushed the plugwise-config_options branch from b0f90ad to 4f96695 Compare August 20, 2020 17:37
@CoMPaTech
Copy link
Copy Markdown
Member

Catch-up with dev

@CoMPaTech CoMPaTech force-pushed the plugwise-config_options branch from 4f96695 to 1aa7bae Compare September 2, 2020 17:23
@CoMPaTech
Copy link
Copy Markdown
Member

Catchup with dev and conflict resolve

@CoMPaTech CoMPaTech force-pushed the plugwise-config_options branch from f5715c3 to f0a21e0 Compare September 4, 2020 18:38
@CoMPaTech
Copy link
Copy Markdown
Member

Tested locally against newer pending release of the module as requested in plugwise/Plugwise-Smile#86

if single_master_thermostat is None:
platforms = SENSOR_PLATFORMS

entry.add_update_listener(_update_listener)
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

Please store and unsubscribe the listener when the config entry is unloaded to prevent it leaking. Example in nut

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

Adding/testing

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

Hopefully implemented as indicated, passing local functionality and commit-checks.

@CoMPaTech
Copy link
Copy Markdown
Member

Looks like we've made some progress ... food and snacks tend to help. Also tested locally with newer module version so we can add a version-bump PR once this merges to solve plugwise/Plugwise-Smile#86 (module dependencies module vs core)

@CoMPaTech
Copy link
Copy Markdown
Member

Seems CI checks and codecov concur :)

@CoMPaTech CoMPaTech force-pushed the plugwise-config_options branch from b0dff64 to bca3ce8 Compare September 6, 2020 10:42
@CoMPaTech
Copy link
Copy Markdown
Member

@bdraco Do we still want to pass this for 0.115 beta including a quick additional PR for module version bump as per @MartinHjelmare for plugwise/Plugwise-Smile#86?

@bdraco
Copy link
Copy Markdown
Member

bdraco commented Sep 6, 2020

 tests/components/plugwise/test_config_flow.py ✓✓✓✓✓✓✓✓                                                                                                                                                                                                              100% ██████████

----------- coverage: platform linux, python 3.8.1-final-0 -----------
Name                                               Stmts   Miss  Cover   Missing
--------------------------------------------------------------------------------
homeassistant/components/plugwise/config_flow.py      80      0   100%
homeassistant/components/plugwise/const.py            31      0   100%
--------------------------------------------------------------------------------
TOTAL                                                111      0   100%

Comment thread homeassistant/components/plugwise/config_flow.py Outdated
Comment thread homeassistant/components/plugwise/__init__.py Outdated
@bdraco bdraco merged commit 61e8ab1 into home-assistant:dev Sep 6, 2020
@CoMPaTech
Copy link
Copy Markdown
Member

Tnx @bdraco

hass.data[DOMAIN] = {entry.entry_id: {"api": MagicMock(smile_type="power")}}
entry.add_to_hass(hass)

result = await hass.config_entries.options.async_init(entry.entry_id)
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

We should set up the config entry before starting the options flow.

The options flow requires the config flow module to be loaded. This will happen when setting up the config entry. If CI splits testing the config flow might not be loaded by the other tests when the options flow tests run.

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

Tnx, will look into this and the below comment and get an PR started later today

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

#39736 it is


async def test_show_zeroconf_form(hass, mock_smile) -> None:
"""Test that the zeroconf confirmation form is served."""
flow = config_flow.PlugwiseConfigFlow()
Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

Always start the tests with the core interfaces. Here use hass.config_entries.flow.async_init.

Copy link
Copy Markdown
Member

Choose a reason for hiding this comment

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

Overlooked when refitting between PRs, that def is redundant now that 78: async def test_zeroconf_form(hass): is in. Update PR will be in later today

@CoMPaTech CoMPaTech deleted the plugwise-config_options branch September 7, 2020 12:43
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.

6 participants