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

Add statistics capabilities to hp_ilo integration #65900

Closed
wants to merge 5 commits into from

Conversation

sibalzer
Copy link

@sibalzer sibalzer commented Feb 6, 2022

Proposed change

Add sensors with long-term statistic capabilities, by optional device_class and state_class options in the configuration.

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

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:

@homeassistant
Copy link
Contributor

Hi @sibalzer,

It seems you haven't yet signed a CLA. Please do so here.

Once you do that we will be able to review and accept this pull request.

Thanks!

@epenet
Copy link
Contributor

epenet commented Feb 8, 2022

Could you use attr shorthand instead of creating new properties?

@sibalzer
Copy link
Author

sibalzer commented Feb 8, 2022

I can look into it, but i think properies would be more intuitive since the template and sensor.rest, both use properties for the same functionality.

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.

Template and rest are not necessarily the best ones to use as basis as they were created before attribute shorthands were available.

I think you should avoid creating new properties if they are not necessary.
Then in a follow-up you can also migrate the other properties to shorthand attributes (native_unit_of_measurement, native_value, extra_state_attributes)

Comment on lines 147 to 153
if sensor_type == "server_power_readings":
if unit_of_measurement is None:
unit_of_measurement = "W"
if device_class is None:
device_class = "power"
if state_class is None:
state_class = "measurement"
Copy link
Contributor

Choose a reason for hiding this comment

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

Based on the rest of the code, I don't think these should be hard-coded.

Comment on lines 156 to 157
self._device_class = device_class
self._state_class = state_class
Copy link
Contributor

Choose a reason for hiding this comment

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

Use shorthand attributes instead

Suggested change
self._device_class = device_class
self._state_class = state_class
self._attr_device_class = device_class
self._attr_state_class = state_class

Comment on lines 169 to 178
@property
def device_class(self):
"""Return the state class of the sensor."""
return self._device_class

@property
def state_class(self):
"""Return the state class of the sensor."""
return self._state_class

Copy link
Contributor

Choose a reason for hiding this comment

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

Not needed if shorthand attributes are used

Suggested change
@property
def device_class(self):
"""Return the state class of the sensor."""
return self._device_class
@property
def state_class(self):
"""Return the state class of the sensor."""
return self._state_class

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.

Slight amend required on the unit_of_measurement

homeassistant/components/hp_ilo/sensor.py Outdated Show resolved Hide resolved
chkuendig added a commit to chkuendig/hass-hp_ilo-beta that referenced this pull request Feb 11, 2022
Comment on lines +72 to +73
vol.Optional(CONF_DEVICE_CLASS): DEVICE_CLASSES_SCHEMA,
vol.Optional(CONF_STATE_CLASS): STATE_CLASSES_SCHEMA,
Copy link
Member

Choose a reason for hiding this comment

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

This is an integration that connects to a device or service. As per ADR-0010.

For integrations that connect to devices or services, we no longer accept new YAML configuration or changes.

This integration needs to be refactored first to use a configuration flow and config entries first.

More information about this can be found in Architecture Decision Record:

See our developer documentation on how to get started creating a configuration flow for this integration:

https://developers.home-assistant.io/docs/config_entries_config_flow_handler

Copy link
Contributor

Choose a reason for hiding this comment

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

@sibalzer FWIW, I started such an config flow, including auto-discovery (but couldn't find the time to wrap it up, i.e. to migrate old config entries and to configure which sensor types shoudl automatically be generated). Feel free to copy from there: https://github.com/chkuendig/hass-hp_ilo-beta

@epenet
Copy link
Contributor

epenet commented Feb 21, 2022

You can also convert this PR to a cleanup PR implementing shorthand attributes. It will leave less to review later.

Co-authored-by: epenet <6771947+epenet@users.noreply.github.com>
@mrulke
Copy link

mrulke commented May 2, 2022

Can this get merged or are we still waiting on something?

@epenet
Copy link
Contributor

epenet commented May 2, 2022

@mrulke this is blocked until a config-flow is implemented (see #65900 (comment))
I have recommended that this PR be re-purposed as a cleanup PR to implement shorthand attributes in the meantime, but no progress has been made on that front.

@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 Jul 31, 2022
@github-actions github-actions bot closed this Aug 7, 2022
@github-actions github-actions bot locked and limited conversation to collaborators Aug 8, 2022
Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Projects
None yet
Development

Successfully merging this pull request may close these issues.

Add capability for hp_ilo to capture statistics
6 participants