Add Plugwise scan_interval config option#37229
Conversation
|
Hey there @CoMPaTech, mind taking a look at this pull request as its been labeled with an integration ( |
6896f9a to
bf9809f
Compare
|
Ok, ready for rereview now, sorry, I'm still learning... |
CoMPaTech
left a comment
There was a problem hiding this comment.
Looking good and functional on test and devcontainer
|
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? |
|
@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. |
|
@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. |
|
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. |
|
Still working on that, not much progress yet, aiming for next week |
664e2ee to
504a284
Compare
|
Additional tests added |
|
@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. |
b0f90ad to
4f96695
Compare
|
Catch-up with dev |
4f96695 to
1aa7bae
Compare
|
Catchup with dev and conflict resolve |
f5715c3 to
f0a21e0
Compare
|
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) |
There was a problem hiding this comment.
Please store and unsubscribe the listener when the config entry is unloaded to prevent it leaking. Example in nut
There was a problem hiding this comment.
Hopefully implemented as indicated, passing local functionality and commit-checks.
|
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) |
|
Seems CI checks and codecov concur :) |
b0dff64 to
bca3ce8
Compare
|
@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? |
|
|
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) |
There was a problem hiding this comment.
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.
There was a problem hiding this comment.
Tnx, will look into this and the below comment and get an PR started later today
|
|
||
| async def test_show_zeroconf_form(hass, mock_smile) -> None: | ||
| """Test that the zeroconf confirmation form is served.""" | ||
| flow = config_flow.PlugwiseConfigFlow() |
There was a problem hiding this comment.
Always start the tests with the core interfaces. Here use hass.config_entries.flow.async_init.
There was a problem hiding this comment.
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
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
Additional information
Checklist
black --fast homeassistant tests)If user exposed functionality or configuration variables are added/changed:
If the code communicates with devices, web services, or third-party tools:
Updated and included derived files by running:
python3 -m script.hassfest.requirements_all.txt.Updated by running
python3 -m script.gen_requirements_all..coveragerc.The integration reached or maintains the following Integration Quality Scale: