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

Use asyncio Lock for fibaro light #18622

Merged
merged 4 commits into from Nov 26, 2018

Conversation

Projects
None yet
6 participants
@pbalogh77
Contributor

pbalogh77 commented Nov 21, 2018

Description:

Changes Fibaro light turn_on and update functions into async versions, getting rid of a blocking lock by switching to async locks. Big thanks to @amelchio.

Related issue (if applicable): fixes #

Pull request in home-assistant.io with documentation (if applicable): home-assistant/home-assistant.io#<home-assistant.io PR number goes here>

Example entry for configuration.yaml (if applicable):

Checklist:

  • The code change is tested and works locally.
  • Local tests pass with tox. Your PR cannot be merged unless tests pass
  • There is no commented out code in this PR.

If user exposed functionality or configuration variables are added/changed:

If the code communicates with devices, web services, or third-party tools:

  • New dependencies have been added to the REQUIREMENTS variable (example).
  • New dependencies are only imported inside functions that use them (example).
  • New or updated dependencies have been added to requirements_all.txt by running script/gen_requirements_all.py.
  • New files were added to .coveragerc.

If the code does not interact with devices:

  • Tests have been added to verify that the new code works.
@pvizeli

Do you sure that you need a lock? Because home assistant calls none async things sequential.

@MartinHjelmare

Turn off still has the old handling of the lock.

@pbalogh77

This comment has been minimized.

Contributor

pbalogh77 commented Nov 22, 2018

@pvizeli: The issue is that there's a thread for receiving updates from the fibaro hub, which then requests an update on the light. In the turn_on function there are (in case of switched off color lights) two calls out to fibaro hub, setting the color and switching it on. They trigger updates, and I'd have the update function called on a thread while turn_on is still being processed. So there is a race condition, which could have some side effects, unless handled. Maybe its a small thing, and it might not cause a crash, but could introduce a level of unpredictability as both functions are working on the same variables.

async turn_off
Turned the turn_off into async as well

@MartinHjelmare MartinHjelmare added this to the 0.83 milestone Nov 22, 2018

bless you, blank lines...
My local flake8 lies to me. Not cool.
@pbalogh77

This comment has been minimized.

Contributor

pbalogh77 commented Nov 26, 2018

Dear Reviewers,

Can this be merged or is there something else that needs to be done?

Cheers,
Peter

@MartinHjelmare MartinHjelmare merged commit 4a661e3 into home-assistant:dev Nov 26, 2018

5 checks passed

Hound No violations found. Woof!
WIP ready for review
Details
cla-bot Everyone involved has signed the CLA
continuous-integration/travis-ci/pr The Travis CI build passed
Details
coverage/coveralls Coverage remained the same at 93.019%
Details

@wafflebot wafflebot bot removed the in progress label Nov 26, 2018

balloob added a commit that referenced this pull request Nov 26, 2018

Use asyncio Lock for fibaro light (#18622)
* Use asyncio Lock for fibaro light

* line length and empty line at end

* async turn_off

Turned the turn_off into async as well

* bless you, blank lines...

My local flake8 lies to me. Not cool.

@pbalogh77 pbalogh77 deleted the pbalogh77:fibaro-async-light-lock branch Nov 26, 2018

@balloob balloob referenced this pull request Nov 29, 2018

Merged

0.83 #18776

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment