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

Statistics component fix device_class for incremental source sensors #88096

Merged

Conversation

ThomDietrich
Copy link
Contributor

Proposed change

Fixes errors shown since 2023.02: #87376

This PR implements the proposal explained here: #87376 (comment)

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.

To help with the load of incoming pull requests:

@home-assistant
Copy link

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

Code owner commands

Code owners of statistics can trigger bot actions by commenting:

  • @home-assistant close Closes the issue.
  • @home-assistant rename Awesome new title Change the title of the issue.
  • @home-assistant reopen Reopen the issue.
  • @home-assistant unassign statistics Removes the current integration label and assignees on the issue, add the integration domain after the command.

@ThomDietrich
Copy link
Contributor Author

@emontnemery thanks for your review!

Copy link
Contributor

@emontnemery emontnemery left a comment

Choose a reason for hiding this comment

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

Looks good, just a minor comment + question

homeassistant/components/statistics/sensor.py Outdated Show resolved Hide resolved
Comment on lines +481 to +482
self._update_listener() # pragma: no cover
self._update_listener = None # pragma: no cover
Copy link
Contributor

Choose a reason for hiding this comment

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

When does this happen?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Can't exactly tell you. I did not develop this part of the code. Pytest always showed missing coverage for these two lines, hence the comment. Maybe the code can be removed or changed, but I didn't feel the need.

Copy link
Contributor

Choose a reason for hiding this comment

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

There shouldn't be any pragma: no cover in homeassistant code.
It is better to have reduced coverage than invalid coverage.

Copy link
Contributor

Choose a reason for hiding this comment

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

Opened #88173

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 do not agree and don't see how it would make sense in this particular case. Anyhow, understand the incentive generally and won't fight with you.

Copy link
Contributor

Choose a reason for hiding this comment

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

If the code is there, there must be a reason...

  • If it is dead code that can't be reached, then it should be removed
  • If it is not dead code, then we need to be reminded that coverage should be improved

The only time when no cover is in use is when we raise an exception for unreachable code.

Copy link
Member

Choose a reason for hiding this comment

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

There is not reason to introduce fake coverage. Epenet is right here, it should not have had these flags. I've therefore merged the PR to remove them.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

On second thought @epenet I agree with you. I did not develop this code nor did I ever touch it. I believe it's "dead code" as you called it and will do some tests and provide a fix in a future PR.

Copy link
Contributor

@emontnemery emontnemery left a comment

Choose a reason for hiding this comment

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

Thanks, @ThomDietrich 👍

@emontnemery emontnemery added this to the 2023.2.5 milestone Feb 15, 2023
@emontnemery emontnemery merged commit a0e0feb into home-assistant:dev Feb 15, 2023
Comment on lines +402 to +403
if sensor_device_class is None:
return None
Copy link
Member

Choose a reason for hiding this comment

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

Can we add coverage for this one?

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Will do! This wasn't raised by pytest before the changes regarding DEVICE_CLASS_STATE_CLASSES

Comment on lines +401 to +402
sensor_device_class = try_parse_enum(SensorDeviceClass, source_device_class)
if sensor_device_class is None:
Copy link
Member

Choose a reason for hiding this comment

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

Wallrus could have been used.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Could certainly, but then black will line-break this logic into oblivion!? I already had arguably better code locally.
You wanna suggest something? Maybe you have a better idea than me

Copy link
Member

@frenck frenck Feb 15, 2023

Choose a reason for hiding this comment

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

My suggestion was already above, just wallrus it. We don't worry about formatting, that is what black is for.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Doesn't that contradict the wish for easily readable and maintainable code?

I'll have a look

Copy link
Member

Choose a reason for hiding this comment

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

Sure, that is what black is for. You dont' have to agree with its style, but it is the style we are using consistently. The formatting is maintained by black and thus not a concern.

Comment on lines +404 to +406
sensor_state_classes = DEVICE_CLASS_STATE_CLASSES.get(
sensor_device_class, set()
)
Copy link
Member

Choose a reason for hiding this comment

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

The creation of an empty set() here is not needed.

Comment on lines +404 to +407
sensor_state_classes = DEVICE_CLASS_STATE_CLASSES.get(
sensor_device_class, set()
)
if SensorStateClass.MEASUREMENT not in sensor_state_classes:
Copy link
Member

Choose a reason for hiding this comment

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

Wallrus could have been used.

Comment on lines +582 to +583
if self.is_binary
else f"_stat_{characteristic}",
Copy link
Member

Choose a reason for hiding this comment

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

We don't allow the use of multi-line inline if-statements; as they become hard to read. Please adjust this in a followup PR to have a regular if statement.

source_device_class = source_state.attributes.get(ATTR_DEVICE_CLASS)
if source_device_class is None:
return None
sensor_device_class = try_parse_enum(SensorDeviceClass, source_device_class)
Copy link
Member

Choose a reason for hiding this comment

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

We do not need to parse the enum to try to look it up in DEVICE_CLASS_STATE_CLASSES.

@ThomDietrich
Copy link
Contributor Author

@frenck thanks for the detailed feedback. I will provide a follow-up PR and reference you in a few days time. Cheers

balloob pushed a commit that referenced this pull request Feb 15, 2023
…88096)

* Return None device_class for incremental source sensors

* Ignore linting error

* Fix ignore linting error

* Fix ignore linting error

* Fix ignore linting error

* Catch potential parsing error with enum
@balloob balloob mentioned this pull request Feb 15, 2023
@ianfretwell
Copy link

I was assuming this PR was supposed to fix the following type of log entry - this is from 2023.2.5 - and so it hasn't. Or was I missing the point ?

And despite the log entry all these sensors appear to work just fine for me.

(I have no idea how else to paste this log entry in - this is the way it copies it to clipboard direct from the HA interface)

Logger: homeassistant.components.sensor
Source: components/sensor/init.py:503
Integration: Sensor (documentation, issues)
First occurred: 08:34:11 (13 occurrences)
Last logged: 08:34:13

Entity sensor.smart_meter_gas_import_this_week (<class 'homeassistant.components.mqtt.sensor.MqttSensor'>) is using state class 'measurement' which is impossible considering device class ('energy') it is using; expected None or one of 'total', 'total_increasing'; Please update your configuration if your entity is manually configured, otherwise create a bug report at https://github.com/home-assistant/core/issues?q=is%3Aopen+is%3Aissue+label%3A%22integration%3A+mqtt%22
Entity sensor.smart_meter_gas_import_this_month (<class 'homeassistant.components.mqtt.sensor.MqttSensor'>) is using state class 'measurement' which is impossible considering device class ('energy') it is using; expected None or one of 'total', 'total_increasing'; Please update your configuration if your entity is manually configured, otherwise create a bug report at https://github.com/home-assistant/core/issues?q=is%3Aopen+is%3Aissue+label%3A%22integration%3A+mqtt%22
Entity sensor.smart_meter_gas_import_unit_rate (<class 'homeassistant.components.mqtt.sensor.MqttSensor'>) is using state class 'measurement' which is impossible considering device class ('monetary') it is using; expected None or one of 'total'; Please update your configuration if your entity is manually configured, otherwise create a bug report at https://github.com/home-assistant/core/issues?q=is%3Aopen+is%3Aissue+label%3A%22integration%3A+mqtt%22
Entity sensor.smart_meter_gas_import_standing_charge (<class 'homeassistant.components.mqtt.sensor.MqttSensor'>) is using state class 'measurement' which is impossible considering device class ('monetary') it is using; expected None or one of 'total'; Please update your configuration if your entity is manually configured, otherwise create a bug report at https://github.com/home-assistant/core/issues?q=is%3Aopen+is%3Aissue+label%3A%22integration%3A+mqtt%22
Entity sensor.electric_cost_today_mercers (<class 'custom_components.hildebrandglow_dcc.sensor.Cost'>) is using state class 'total_increasing' which is impossible considering device class ('monetary') it is using; expected None or one of 'total'; Please update your configuration if your entity is manually configured, otherwise report it to the custom integration author.

@frenck
Copy link
Member

frenck commented Feb 16, 2023

@ianfretwell This is a merged PR. If you experience issues, please raise an issue in the issue tracker. Merged PR aren't trackable as an issue.

Thanks 👍

@github-actions github-actions bot locked and limited conversation to collaborators Feb 17, 2023
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
7 participants