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

Filtered values are no longer rounded if values are not changed/calculated #76164

Merged
merged 14 commits into from Apr 8, 2023

Conversation

dgomes
Copy link
Contributor

@dgomes dgomes commented Aug 3, 2022

Breaking change

Values are no longer rounded to the default 2 decimals points for the "Range", "Throttle" and "TimeThrottle" filters, and will keep the source precision

Proposed change

Filtered values are no longer rounded if values are not changed/calculated such as in the case of "Range", "Throttle" and "TimeThrottle" filters

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

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

@project-bot project-bot bot added this to Needs review in Dev Aug 3, 2022
@project-bot project-bot bot moved this from Needs review to By Code Owner in Dev Aug 3, 2022
@frenck frenck added the smash Indicator this PR is close to finish for merging or closing label Aug 4, 2022
Dev automation moved this from By Code Owner to Review in progress Aug 7, 2022
Copy link
Contributor

@veleek veleek left a comment

Choose a reason for hiding this comment

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

I think the correct approach is just to change the schema.

@@ -488,7 +488,7 @@ class RangeFilter(Filter, SensorEntity):
def __init__(
self,
entity,
precision: int | None = DEFAULT_PRECISION,
precision,
Copy link
Contributor

Choose a reason for hiding this comment

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

Any reason not to keep int | None type definition? Or is it standard to not include it if you're not including a default value?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

If I include the type definition mypy complains :(

Copy link
Contributor

Choose a reason for hiding this comment

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

I think mypy probably complains for a reason...
I started to look into it and I found it very awkward that functions only had partial type hints, and some even had invalid type hints.
I suggest that we fix the type hints first: #86141

@veleek
Copy link
Contributor

veleek commented Aug 9, 2022

Failing checks seem unrelated to this change... any way to just re-run them?

@@ -79,7 +79,7 @@
ICON = "mdi:chart-line-variant"

FILTER_SCHEMA = vol.Schema(
{vol.Optional(CONF_FILTER_PRECISION, default=DEFAULT_PRECISION): vol.Coerce(int)}
{vol.Optional(CONF_FILTER_PRECISION, default=None): vol.Any(None, vol.Coerce(int))}
Copy link
Member

Choose a reason for hiding this comment

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

Definition of DEFAULT_PRECISION can be removed.

I don't understand how removing default precision only applies to 3 filters, while all filter schemas are extending from FILTER_SCHEMA? If we want a different default value, we could keep track of a dictionary mapping filter name => default value, only used when we detect that precision is None.

Copy link
Contributor Author

@dgomes dgomes Aug 17, 2022

Choose a reason for hiding this comment

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

I'm trying to make this a less of a breaking change as possible, so I don't want to remove DEFAULT_PRECISION (that was my mistake on the refactor after the 1st review)

Also preferred to have the default value next to the class definition instead of a global dict

@github-actions
Copy link

There hasn't been any activity on this pull request recently. This pull request has been automatically marked as stale because of that and will be closed if no further activity occurs within 7 days.
Thank you for your contributions.

@github-actions github-actions bot added the stale label Nov 15, 2022
@dgomes
Copy link
Contributor Author

dgomes commented Nov 15, 2022

still valid :(

@github-actions github-actions bot removed the stale label Nov 15, 2022
@dgomes dgomes mentioned this pull request Jan 17, 2023
19 tasks
@epenet epenet mentioned this pull request Jan 18, 2023
19 tasks
@epenet
Copy link
Contributor

epenet commented Jan 19, 2023

I have finished adding typing to filter integration
I suggest that you rebase this PR now.

@dgomes dgomes requested a review from epenet March 28, 2023 20:22
dgomes and others added 2 commits March 30, 2023 11:00
Co-authored-by: epenet <6771947+epenet@users.noreply.github.com>
Copy link
Contributor

@epenet epenet left a comment

Choose a reason for hiding this comment

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

The type hint for precision is still wrong on every __init__ method.
I suggest that you change the schema to:

    {vol.Optional(CONF_FILTER_PRECISION): vol.Coerce(int)}

And set the default value on each init method.

def __init__(self, window_size: timedelta, entity: str, precision: int | None = None) -> None:

or

def __init__(self, window_size: timedelta, entity: str, precision: int | None = DEFAULT_PRECISION) -> None:

@home-assistant home-assistant bot marked this pull request as draft March 30, 2023 10:22
@home-assistant
Copy link

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.

@dgomes
Copy link
Contributor Author

dgomes commented Mar 30, 2023

Can't set the default value on each init method because there are arguments without default values after precision

@epenet
Copy link
Contributor

epenet commented Mar 30, 2023

Can't set the default value on each init method because there are arguments without default values after precision

You can change the order of the arguments, as it is always built using keyword arguments with **_filter:

    filters = [
        FILTERS[_filter.pop(CONF_FILTER_NAME)](entity=entity_id, **_filter)
        for _filter in filter_configs
    ]

@dgomes dgomes marked this pull request as ready for review March 31, 2023 17:34
@home-assistant home-assistant bot requested review from epenet and veleek March 31, 2023 17:34
Comment on lines 467 to 468
if self.filter_precision is not None:
filtered.set_precision(self.filter_precision)
Copy link
Contributor

Choose a reason for hiding this comment

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

Is this change necessary?
Does it not end up being a duplicate of the change on line 384/386?

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 believe so, filter_precision starts as None

Copy link
Contributor

@epenet epenet Apr 7, 2023

Choose a reason for hiding this comment

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

What I mean is that the first line in set_precision is check that the passed value is not None.
if precision is not None and isinstance(self.state, Number):

So you are first checking that it's not None outside the function, and then checking a second time for the same thing inside the function.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Sorry misunderstood initial comment (fixed)

dgomes and others added 3 commits April 7, 2023 14:13
Copy link
Contributor

@epenet epenet left a comment

Choose a reason for hiding this comment

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

LGTM 👍
@balloob are you happy?

Dev automation moved this from Review in progress to Reviewer approved Apr 7, 2023
FILTER_SCHEMA = vol.Schema(
{vol.Optional(CONF_FILTER_PRECISION, default=DEFAULT_PRECISION): vol.Coerce(int)}
)
FILTER_SCHEMA = vol.Schema({vol.Optional(CONF_FILTER_PRECISION): vol.Coerce(int)})
Copy link
Member

Choose a reason for hiding this comment

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

Just a note for a follow-up PR, since precision is now a user-facing sensor option, this can be completely dropped in a future PR.

@balloob balloob merged commit b1a23c5 into home-assistant:dev Apr 8, 2023
22 checks passed
Dev automation moved this from Reviewer approved to Done Apr 8, 2023
@github-actions github-actions bot locked and limited conversation to collaborators Apr 9, 2023
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
bugfix by-code-owner cla-signed integration: filter small-pr PRs with less than 30 lines. smash Indicator this PR is close to finish for merging or closing
Projects
Dev
  
Done
Development

Successfully merging this pull request may close these issues.

Rounding to precision value is applied to all filters
6 participants