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

Non-responsive sensor can block startup #2332

Closed
usul27 opened this Issue Jun 19, 2016 · 8 comments

Comments

Projects
None yet
5 participants
@usul27
Contributor

usul27 commented Jun 19, 2016

Make sure you are running the latest version of Home Assistant before reporting an issue.

You should only file an issue if you found a bug. Feature and enhancement requests should go in the Feature Requests section of our community forum:

Home Assistant release (hass --version): 0.22

Python release (python3 --version): 3.4.2

Component/platform: Linux/RPi

Description of problem: A non-responsive sensor can block the startup

Expected:

Problem-relevant configuration.yaml entries and steps to reproduce:

switch:
  platform: edimax
  host: xxx
  username: admin
  password: xxx
  name: xxx

I use Home Assistant to control some Edimax switches. One of them became unresponsive. This completely blocked Home Assistant. Even restarting did not work as Home Assistant was hanging in the startup process waiting for a response from the Switch.

In general, reading data from sensors should be non-blocking. A single non-responsive component should not be able to block the whole startup. I don't think this is an issue specific to the Edimax platform, but a general issue that should be solved in the core.

@fabaff

This comment has been minimized.

Member

fabaff commented Jun 21, 2016

@usul27

This comment has been minimized.

Contributor

usul27 commented Jun 21, 2016

While it may be a bug in a dependency, I think, HA should not allow an external library to block core functionalities. There should be at least some timeout mechanism that disables a plugin if it doesn't respond.

@fabaff

This comment has been minimized.

Member

fabaff commented Jun 21, 2016

Reference: #1543

@fabaff fabaff added the duplicate label Jun 21, 2016

@balloob

This comment has been minimized.

Member

balloob commented Jun 21, 2016

Python does not have a good way of doing this for threaded solutions. Using async it would be possible but that's a core change we can't do. If you know of something please let us know

@usul27

This comment has been minimized.

Contributor

usul27 commented Jun 21, 2016

I understand that this isn't a thing to fix with a few lines of code. However, I think in the long run there need to be a change in the core to allow subsystems to work asynchronously. Otherwise problems like this will happen in many complex installations - especially when using external libraries that do not behave well. Blocking I/O is still the default in many libraries.

@Zac-HD

This comment has been minimized.

Contributor

Zac-HD commented Feb 18, 2017

@balloob - I think this one has been solved by the move to async core. Time to close the issue?

@balloob

This comment has been minimized.

Member

balloob commented Feb 18, 2017

It actually has not been resolved. We still don't have implemented the timeout mentioned here but being async, it is possible.

@balloobbot

This comment has been minimized.

Contributor

balloobbot commented Apr 30, 2017

There hasn't been any activity on this issue recently. Due to the high number of incoming GitHub notifications, we have to clean some of the old issues, as many of them have already been resolved with the latest updates.

Please make sure to update to the latest Home Assistant version and check if that solves the issue. Let us know if that works for you by adding a comment 👍

@balloob balloob closed this Apr 30, 2017

@home-assistant home-assistant locked and limited conversation to collaborators Aug 12, 2017

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