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 support for VeSync Fans #36132

Merged
merged 16 commits into from
Sep 4, 2020
Merged

Add support for VeSync Fans #36132

merged 16 commits into from
Sep 4, 2020

Conversation

TheGardenMonkey
Copy link
Contributor

@TheGardenMonkey TheGardenMonkey commented May 25, 2020

Proposed change

Adds support to the VeSync component to include "fans" that are supported by the VeSync App / eco-system. Currently this includes the Leviot Smart Air Purifier LV-PUR131S. The added code is essentially a duplication of what is done in the current switch component.

Type of change

  • Dependency upgrade
  • Bugfix (non-breaking change which fixes an issue)
  • New integration (thank you!)
  • [ x ] 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

  • [ x ] The code change is tested and works locally.
  • [ x ] Local tests pass. Your PR cannot be merged unless tests pass
  • [ x ] There is no commented out code in this PR.
  • [ x ] I have followed the development checklist
  • [ x ] 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:

  • [ x ] 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

@TheGardenMonkey
Copy link
Contributor Author

Created documentation pull request to accompany this

home-assistant/home-assistant.io#13590

@SirDeadlystrike
Copy link

Looks Good! Thanks for adding fan support from VeSync. Was looking into this as well recently.

Tests are failing, Flake8 is complaining. Need to fix that.

If you need help testing let me know!

@TheGardenMonkey
Copy link
Contributor Author

Looks Good! Thanks for adding fan support from VeSync. Was looking into this as well recently.

Tests are failing, Flake8 is complaining. Need to fix that.

If you need help testing let me know!

thanks, I don't understand why it is failing. I believe what I have is correct, so not clear what is wrong...it is complaining about the "mood" on the first line but the language matches other integrations.

@SirDeadlystrike
Copy link

Flake8 passed now! Nice!

iSort is blowing up now. I think you need to install and run the command it references local to see the full verbose reason/error. If you are seeing this message in CI, reproduce locally with: pre-commit run --all-files.

@TheGardenMonkey
Copy link
Contributor Author

Should I just move the turn_on from common into the switch.py?

@theaquarium
Copy link

Thanks for adding this! I was just about to add it myself but I noticed that this PR already existed. I'd love to see this merged soon.

@theaquarium
Copy link

By the way, this integration should probably be renamed to just VeSync since it no longer only supports Etekcity VeSync products.

@TheGardenMonkey
Copy link
Contributor Author

Thanks for the feedback, I was wondering if that was OK to do as part of this pull request. I have removed from here and from the docs pull request.

@stale
Copy link

stale bot commented Jul 18, 2020

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.

@stale stale bot added the stale label Jul 18, 2020
@TheGardenMonkey
Copy link
Contributor Author

Adding a comment to prevent from closing.

@stale stale bot removed the stale label Jul 21, 2020
Copy link
Member

@bdraco bdraco left a comment

Choose a reason for hiding this comment

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

Thank you for your contribution thus far! 🎖 Since this is a significant contribution, we would appreciate you'd added yourself to the list of code owners for this integration. ❤️

Please, add your GitHub username to the manifest.json of this integration.

For more information about "code owners", see: Architecture Decision Record 0008: Code owners.

homeassistant/components/vesync/fan.py Outdated Show resolved Hide resolved
homeassistant/components/vesync/fan.py Outdated Show resolved Hide resolved
homeassistant/components/vesync/fan.py Outdated Show resolved Hide resolved
homeassistant/components/vesync/__init__.py Outdated Show resolved Hide resolved
TheGardenMonkey and others added 2 commits August 22, 2020 20:34
Copy link
Member

@bdraco bdraco 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 few small comments.

@bdraco
Copy link
Member

bdraco commented Aug 31, 2020

When its ready again for me to take a look, please request a review

def speed(self):
"""Return the current speed."""
if self.smartfan.mode == SPEED_AUTO:
return SPEED_AUTO
Copy link
Member

Choose a reason for hiding this comment

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

Since the fan can still return SPEED_AUTO, and we have taken it out of FAN_SPEEDS this puts us in an invalid state. Unfortunately it doesn't look like we can tell what speed the fan is actually running it so it leaves us in a position where violating the spec might make more sense since auto can be set from outside Home Assistant.

I think its ok to add back in as long as we refactor after home-assistant/architecture#127 resolves this.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

Sounds good and yes I will refactor when a decision is made.

Copy link
Member

@MartinHjelmare MartinHjelmare Sep 4, 2020

Choose a reason for hiding this comment

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

It's not ok to violate our architecture design until the architecture has been changed. Please remove the auto speed.

We can return None in that case.

@bdraco bdraco merged commit eb7742e into home-assistant:dev Sep 4, 2020
Copy link
Member

@MartinHjelmare MartinHjelmare left a comment

Choose a reason for hiding this comment

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

Please address the comments in a new PR. Thanks!

async def async_setup_entry(hass, config_entry, async_add_entities):
"""Set up the VeSync fan platform."""

async def async_discover(devices):
Copy link
Member

@MartinHjelmare MartinHjelmare Sep 4, 2020

Choose a reason for hiding this comment

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

async_discover could be a callback since we don't await inside.

hass.data[DOMAIN][VS_DISPATCHERS].append(disp)

_async_setup_entities(hass.data[DOMAIN][VS_FANS], async_add_entities)
return True
Copy link
Member

Choose a reason for hiding this comment

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

Nothing is checking this return value.

if not self.smartfan.is_on:
self.smartfan.turn_on()

if speed is None or speed == SPEED_AUTO:
Copy link
Member

Choose a reason for hiding this comment

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

Remove this case.

"mode": self.smartfan.mode,
"active_time": self.smartfan.active_time,
"filter_life": self.smartfan.filter_life,
"air_quality": self.smartfan.air_quality,
Copy link
Member

Choose a reason for hiding this comment

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

Air quality should be a separate sensor entity if it means a measurement of air quality and not a fan setting.

Copy link
Contributor Author

Choose a reason for hiding this comment

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

The 'fan' reports an air quality which ranges between bad to excellent, so just want to clarify if that makes sense and is still OK to keep as a sensor. I am assuming yes.

Copy link
Member

Choose a reason for hiding this comment

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

It makes sense to make it a sensor in this case 👍

leikoilja pushed a commit to leikoilja/core that referenced this pull request Sep 6, 2020
Co-authored-by: J. Nick Koston <nick@koston.org>
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Projects
None yet
Development

Successfully merging this pull request may close these issues.

6 participants