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

Improve Wemo setup speed #19563

Merged
merged 8 commits into from Dec 30, 2018

Conversation

Projects
None yet
6 participants
@sqldiablo
Copy link
Contributor

sqldiablo commented Dec 24, 2018

Description:

Breaking change:
Move WeMo device discovery to run after home assistant start so it won't block initial component setup from completing quickly.

Example entry for configuration.yaml (if applicable):

wemo:

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.
Wemo - Improve setup speed
Move WeMo device discovery to an async context so it won't block initial component setup from completing quickly.
Show resolved Hide resolved homeassistant/components/wemo.py Outdated
Show resolved Hide resolved homeassistant/components/wemo.py Outdated

sqldiablo added some commits Dec 24, 2018

@MartinHjelmare
Copy link
Member

MartinHjelmare left a comment

I don't see the benefit of this, and there are mistakes regarding I/O in the event loop and api use.

Show resolved Hide resolved homeassistant/components/wemo.py
Show resolved Hide resolved homeassistant/components/wemo.py
Show resolved Hide resolved homeassistant/components/wemo.py
Show resolved Hide resolved homeassistant/components/wemo.py
Show resolved Hide resolved homeassistant/components/wemo.py Outdated

@fabaff fabaff changed the title Wemo - Improve setup speed Improve Wemo setup speed Dec 25, 2018

@sqldiablo

This comment has been minimized.

Copy link
Contributor

sqldiablo commented Dec 27, 2018

@MartinHjelmare I think I misunderstood some things here. I'm still getting used to how asyncio works. My hope was to allow the WeMo component to load quickly at startup by not having to wait for it to do its device discovery. That's why I moved the discovery process to a subroutine that I then called through hass.add_job(). If there's no good way to defer the discovery process until after setup of the component is complete, then we can close this PR. I was trying to eliminate the "taking a long time to load" messages at startup and make HA load faster on initial startup.

@sqldiablo

This comment has been minimized.

Copy link
Contributor

sqldiablo commented Dec 27, 2018

Is there an event that fires at the end of the setup phase that I could listen for and then run the wemo device discovery? That would accomplish my goal of starting up faster by deferring wemo discovery until after setup is complete.

@MartinHjelmare

This comment has been minimized.

Copy link
Member

MartinHjelmare commented Dec 27, 2018

We can listen for EVENT_HOMEASSISTANT_START that will fire when the setup phase is finished. Limitation of that could be that entitites that are loaded after home assistant start, via discovery, will not be ready to use in automations, immediately.

Show resolved Hide resolved homeassistant/components/wemo.py Outdated
Show resolved Hide resolved homeassistant/components/wemo.py Outdated
Show resolved Hide resolved homeassistant/components/wemo.py Outdated
@sqldiablo

This comment has been minimized.

Copy link
Contributor

sqldiablo commented Dec 28, 2018

I've changed the way this works, per our conversation. This no longer adds an async task to run in the event loop, but rather listens for the start event and then schedules a wemo discovery scan immediately. This is copied from how the discovery component works.

Show resolved Hide resolved homeassistant/components/wemo.py Outdated
Show resolved Hide resolved homeassistant/components/wemo.py Outdated
Show resolved Hide resolved homeassistant/components/wemo.py Outdated
Show resolved Hide resolved homeassistant/components/wemo.py Outdated
Show resolved Hide resolved homeassistant/components/wemo.py Outdated
@MartinHjelmare
Copy link
Member

MartinHjelmare left a comment

Good!

@MartinHjelmare MartinHjelmare merged commit 25e5864 into home-assistant:dev Dec 30, 2018

5 checks passed

Hound No violations found. Woof!
WIP Legacy commit status override — see details
Details
cla-bot Everyone involved has signed the CLA
continuous-integration/travis-ci/pr The Travis CI build passed
Details
coverage/coveralls Coverage increased (+0.03%) to 93.062%
Details

@wafflebot wafflebot bot removed the in progress label Dec 30, 2018

@MartinHjelmare

This comment has been minimized.

Copy link
Member

MartinHjelmare commented Dec 30, 2018

Marking this breaking change, since we change when discovery is run.

@sqldiablo sqldiablo deleted the sqldiablo:wemo_improve_setup_speed branch Dec 30, 2018

mxworm added a commit to mxworm/home-assistant that referenced this pull request Dec 30, 2018

Merge branch 'dev' into current
* dev: (44 commits)
  Fix ADS light when parameter adsvar_brightness is not set (home-assistant#19636)
  Bump pyHik library to 0.1.9 to improve device support. (home-assistant#19656)
  Use aioharmony for remote.harmony platform (home-assistant#19595)
  Add RaspyRFM switch platform (home-assistant#19130)
  Only bind clusters in ZHA remote entity (home-assistant#19577)
  Use async_configure for ZHA IAS binary sensor (home-assistant#19629)
  Improve Wemo setup speed (home-assistant#19563)
  Support knx operation types (home-assistant#19546)
  Use xml.etree through defusedxml (home-assistant#19640)
  Fix cpu_temp issue on Vero 4K (home-assistant#19638)
  Added events STARTED, RESTARTED AND PAUSED (home-assistant#19516)
  Revert "Bump pyotgw to 0.4b0 (home-assistant#19618)" (home-assistant#19635)
  Upgrade to async_upnp_client==0.13.8 (home-assistant#19634)
  Upgraded pyarlo to 0.2.3 (home-assistant#19626)
  Fix cpu_temp issue on Odroid (home-assistant#19620)
  Bump pyotgw to 0.4b0 (home-assistant#19618)
  Add additional neato alerts and errors (home-assistant#19608)
  LCN component and light platform (home-assistant#18621)
  Systemmonitor - add device_class property (home-assistant#19614)
  Upgrade huawei-lte-api to 1.1.1 (home-assistant#19615)
  ...
@cwhits

This comment has been minimized.

Copy link

cwhits commented Dec 31, 2018

Will this speed up static discovery as well?

wemo:
  static:
    - 10.0.40.21
    - 10.0.40.22
    - 10.0.40.23
    - 10.0.40.26

My Wemo devices are on another subnet and even though I have mDNS enabled, they're not discovered by HomeAssistant (Google Cast devices are discovered just fine though).

Doing static discovery with the Wemo devices causes home assistant to hang or about 20 seconds before allowing me to log back in.

@sqldiablo

This comment has been minimized.

Copy link
Contributor

sqldiablo commented Dec 31, 2018

Yep, it'll let HA start up a little faster, because it won't add the wemo devices until after HA has started up and let's you log in.

@balloob balloob referenced this pull request Jan 10, 2019

Merged

0.85.0 #19897

@juched78

This comment has been minimized.

Copy link

juched78 commented Jan 12, 2019

I think that this change means I now need to change my homekit component to not auto_start.

My wemo lights disappeared and I think it is because the wemo devices are discovered after, even though I have discovery disabled and my wemo devices statically defined.

Is there an event I could setup an automation on to turn on homekit once wemo devices are loaded? This would be helpful.

@MartinHjelmare

This comment has been minimized.

Copy link
Member

MartinHjelmare commented Jan 12, 2019

Please open an issue if you suspect a bug. If you need help please use our help channels:
https://home-assistant.io/help/#communication-channels

Merged PRs should not be used for support or bug reports. Thanks!

@home-assistant home-assistant locked as resolved and limited conversation to collaborators Jan 12, 2019

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