Closed grewhit25 closed 3 years ago
Hey there @rytilahti, mind taking a look at this issue as its been labeled with a integration (tplink
) you are listed as a codeowner for? Thanks!
Ping @vangorra
I've managed to reproduce the issue your are reporting but I have not found that tplink is the culprit. I went as far as to remove all tplink code except for the basics (see below). The result is HA doesn't setup any other devices from the config file.
Skeleton tplink component during my test: All other code files were removed. The issue still persisted.
async def async_setup(hass, config):
"""Set up the TP-Link component."""
return True
``
Thanks for your reply. I agree tplink might not be the culprit but maybe one of the triggers.
I have just reproduced the problem by powering off one smartplug, but instead of restarting HA I waited for 10 minutes then powered up the plug moments after it came back online, HA continued with its startup.
Here is a full copy of the logs.
Note the freeze point is at:
2020-01-15 15:31:14 INFO (MainThread) [homeassistant.setup] Setup of domain tts took 0.7 seconds.
HA Continued after powering up the smartplug
2020-01-15 15:41:24 INFO (MainThread) [homeassistant.bootstrap] Home Assistant initialized in 712.96s
Not sure if this is related, but my TP Link plugs (HS105) stopped appearing on HA 2 days ago. I see them in devices and the integration info, but no switch.[blah] is available for developer states/services nor automations.
I have noticed with the latest dev, none of my test integrations are setting up devices (gogogate2, generic camera, tplink, vera). I'm gone as far as to remove all the tplink code from HA and the problem persists.
@vangorra Thanks for taking the time to investigate this issue.
I am not surprised by your findings if there is an issue within HA's initialisation process yet to be identified that can result in the kind of behaviour reported here.
Do we need to escalate into the core team for further investigation so that the underlying problem can be identified or even get a better understanding of what's going on behind the scenes?
I think escalation is a good idea.
Might also be related, but my TP-Link devices just refuse to initialize sometimes when I reboot....I cannot consistently reproduce it or fix it....just reboot a million times and hope it works. Once it intializes properly, the devices work perfectly until the next time I rebooot.
Here is the log:
Traceback (most recent call last):
File "/usr/local/lib/python3.7/site-packages/pyHS100/smartdevice.py", line 117, in _query_helper
request=request,
File "/usr/local/lib/python3.7/site-packages/pyHS100/protocol.py", line 47, in query
sock = socket.create_connection((host, port), timeout)
File "/usr/local/lib/python3.7/socket.py", line 728, in create_connection
raise err
File "/usr/local/lib/python3.7/socket.py", line 716, in create_connection
sock.connect(sa)
OSError: [Errno 113] Host is unreachable
The above exception was the direct cause of the following exception:
Traceback (most recent call last):
File "/usr/src/homeassistant/homeassistant/config_entries.py", line 215, in async_setup
hass, self
File "/usr/src/homeassistant/homeassistant/components/tplink/__init__.py", line 82, in async_setup_entry
static_devices = get_static_devices(config_data)
File "/usr/src/homeassistant/homeassistant/components/tplink/common.py", line 122, in get_static_devices
for plug in SmartStrip(host).plugs.values():
File "/usr/local/lib/python3.7/site-packages/pyHS100/smartstrip.py", line 43, in __init__
children = self.sys_info["children"]
File "/usr/local/lib/python3.7/site-packages/pyHS100/smartdevice.py", line 186, in sys_info
return defaultdict(lambda: None, self.get_sysinfo())
File "/usr/local/lib/python3.7/site-packages/pyHS100/smartdevice.py", line 196, in get_sysinfo
return self._query_helper("system", "get_sysinfo")
File "/usr/local/lib/python3.7/site-packages/pyHS100/smartdevice.py", line 120, in _query_helper
raise SmartDeviceException('Communication error') from ex
pyHS100.smartdevice.SmartDeviceException: Communication error```
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 👍 This issue now has been marked as stale and will be closed if no further activity occurs. Thank you for your contributions.
Unfortunately, the problem is still present. I recreated it again today to show that the issue has not been fixed. Current build.
System Health
arch armv7l
dev false
docker true
hassio false
os_name Linux
os_version 4.19.97-v7+
python_version 3.7.7
timezone Europe/London
version 0.109.6
virtualenv false
Here are the highlights: My Home-Assistance (core) instance runs in a docker container.
To recreate the issue: You must have a fully integrated and functional tplink smartplug. Do.
1. docker-compose down (the container must be stopped and removed for this to work)
2. power off tplink smartplug and remove from the mains.
3. docker-compose up -d (log timestamp 2020-05-14 07:11:24)
The first sign of a problem in the log output is at: 2020-05-14 07:13:51
2020-05-14 07:13:51 ERROR (MainThread) [homeassistant.components.switch] Setup of platform tplink is taking longer than 60 seconds. Startup will proceed without waiting any longer.
The next significant timestamp is at: 2020-05-14 07:15:15
2020-05-14 07:15:15 INFO (MainThread) [hass_nabucasa.iot] Connected
At this point Home-Assistant is not yet initialised. It’s either frozen or paused but this is an indefinite wait nothing will happen while the smartplug remains powered off.
4. After waiting for over 30 minutes, I reinserted the smartplug into the mains and power on.
2020-05-14 07:50:46 INFO (MainThread) [homeassistant.bootstrap] Home Assistant initialized in 2298.33s
I did raise issue #32256 hoping that it would find its way to the core team.
Correct. The pull request that fixes the issue is still open.
Same problem with HS110.
My configuration.yaml
:
tplink:
discovery: false
switch:
- host: 192.168.1.10
Same issue here, possibly due to using a separate network for iot.
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 👍 This issue has now been marked as stale and will be closed if no further activity occurs. Thank you for your contributions.
Home Assistant release with the issue:
Last working Home Assistant release (if known):
Home Assistant 0.103.5
Operating environment (Hass.io/Docker/Windows/etc.):
Docker
Integration:
https://www.home-assistant.io/integrations/tplink/
Description of problem:
I am on home-assistant dev channel and have my docker container automatically updated in the early hours of the morning. However, I noticed that since about build 0.104.0bx Home-Assistant freezes at the same point every morning and never gets fully initialised. I have to then do 'docker restart home-assistant' which allows home-assistant start up fully. This process breaks my smartthings integration which errors with invalid refresh token (I will raised a separate issue for that).
I discovered today that the problem maybe related to one of my tplink smartplugs being powered off. Which I did use one plug to manage December lights then disconnected it in early January leaving the plug disconnected from the mains as I had no immediate use for it. Prior to this both plugs were in use.
On powering up the second smartplug home-assistant will initialise fully without freezing when the container is stopped removed and restarted.
Snippet from the log on first startup when home-assistant freezes full log available is required.
Problem-relevant
configuration.yaml
entries and (fill out even if it seems unimportant):Traceback (if applicable):
Additional information: