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

Fix exception during history_stats startup #16932

Merged
merged 3 commits into from Sep 29, 2018

Conversation

Projects
None yet
4 participants
@amelchio
Member

amelchio commented Sep 28, 2018

Description:

Move registration of state tracking to after EVENT_HOMEASSISTANT_START.

Related issue (if applicable): reported by @arsaboo in chat

Error doing job: Future exception was never retrieved
Traceback (most recent call last):
  File "/usr/local/lib/python3.6/concurrent/futures/thread.py", line 56, in run
    result = self.fn(*self.args, **self.kwargs)
  File "/srv/homeassistant/lib/python3.6/site-packages/homeassistant/components/sensor/history_stats.py", line 114, in force_refresh
    self.schedule_update_ha_state(True)
  File "/srv/homeassistant/lib/python3.6/site-packages/homeassistant/helpers/entity.py", line 319, in schedule_update_ha_state
    self.hass.add_job(self.async_update_ha_state(force_refresh))
AttributeError: 'NoneType' object has no attribute 'add_job'

Checklist:

  • The code change is tested and works locally.
  • Local tests pass with tox.

If the code does not interact with devices:

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

This comment has been minimized.

Member

balloob commented Sep 28, 2018

That's weird. The start event should not be fired until the setup phase is completed and all entities added.

@amelchio

This comment has been minimized.

Member

amelchio commented Sep 28, 2018

That was just a simplification while at it. The real issue was track_state_change().

@balloob

This comment has been minimized.

Member

balloob commented Sep 28, 2018

I think that the listening on start was to prevent it from querying the DB a couple of times during startup if a state (ie a group) changes multiple times during startup.

This update is expensive, so we don't want to do it during startup either, especially because it will change in the future.

I think that the easiest solution would just be to have self._hass be renamed to self.hass in the constructor 😉

@amelchio

This comment has been minimized.

Member

amelchio commented Sep 28, 2018

As discussed in chat, I will change this to only start listening after EVENT_HOMEASSISTANT_START.

@arsaboo

This comment has been minimized.

Contributor

arsaboo commented Sep 28, 2018

Thanks!! Let me know if/when you want me to test it out.

amelchio added some commits Sep 28, 2018

@arsaboo

This comment has been minimized.

Contributor

arsaboo commented Sep 28, 2018

Just tested the fix @amelchio and can confirm that it fixes the issue for me (no more errors in the logs).

@amelchio amelchio changed the title from WIP: Fix exception during history_stats startup to Fix exception during history_stats startup Sep 28, 2018

@balloob balloob added this to the 0.79.1 milestone Sep 29, 2018

@balloob balloob merged commit caaf4f5 into home-assistant:dev Sep 29, 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 decreased (-0.002%) to 93.572%
Details

@wafflebot wafflebot bot removed the in progress label Sep 29, 2018

balloob added a commit that referenced this pull request Sep 30, 2018

Fix exception during history_stats startup (#16932)
* Fix exception during history_stats startup

* Do not track changes during startup

* Ignore args

@balloob balloob referenced this pull request Sep 30, 2018

Merged

0.79.1 #16988

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