Skip to content

Conversation

ziv1234
Copy link
Contributor

@ziv1234 ziv1234 commented Apr 12, 2020

Breaking change

not breaking

Proposed change

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

Example entry for configuration.yaml:

# Example configuration.yaml

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

Hey there @etheralm, mind taking a look at this pull request as its been labeled with a integration (dyson) you are listed as a codeowner for? Thanks!

@@ -195,5 +195,5 @@ def __init__(self, device):
def state(self):
"""Return Air Quality value."""
if self._device.environmental_state:
return int(self._device.environmental_state.volatil_organic_compounds)
Copy link
Member

Choose a reason for hiding this comment

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

Copy link
Contributor Author

Choose a reason for hiding this comment

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

yes. it appeared in both ways in the tests and apparently it does so also in the library. definitely looks like a library bug since it should be the same interface for v1 and v2

Copy link
Contributor Author

Choose a reason for hiding this comment

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

in any case, it looks like the library maintainer and the component is the same, so he/she can probably shed some more light here

ziv1234 added 2 commits April 12, 2020 22:08
…gs into the mocks

so they don't throw exceptions for mocks not being able to convert to int
@etheralm
Copy link
Contributor

The v1 API implementation was done by the author of the original library (libpurecoollink). I was planing on updating both the library and the home assistant integration for the v1 api devices after I finish the home assistant integration for the HP06 model.

@ziv1234
Copy link
Contributor Author

ziv1234 commented Apr 12, 2020

so the current one only supports v1?
if that is the case, i will change it back to volatil in all places

added both values to the mock device (volatil and volatile)
@ziv1234
Copy link
Contributor Author

ziv1234 commented Apr 15, 2020

ok. reverted the homeassistant/components/dyson to its original state
I added both values to the mock so the mock supports both

@balloob balloob merged commit 5bfc1f3 into home-assistant:dev Apr 15, 2020
@lock lock bot locked and limited conversation to collaborators Apr 19, 2020
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.

Fix dyson tests that have uncaught exceptions
4 participants