I’m running 0.115.5 and recently installed the TP-Link Kasa integration. Prior to this, I was using Samsungs SmartThinbs integration to detect and operate the Kasa devices. Auto discovery for the TP-Link Kasa integration has been disabled and the following lines added to configuration.yaml;
When the TP-Link Kasa integration was first configured, the dimmers showed under “Devices” and “Entities” but were marked “unavailable”. HA was restarted a couple of times before all devices showed as available. HA has been running for about twelve hours. All devices remain active.
Since changing from SmartThings to the TP-Link Kasa integration I’ve noticed Kasa devices triggered by the state change of another Kasa device take about thirty seconds to execute. For example; when the light switch for the counter light in the kitchen is turned on, the state change is noted in a script that triggers the light for the kitchen island light to turn on. When the counter light is turned on (manually), the island light turns on but only after a period of time, usually thirty seconds. I’ve checked the log and see now errors associated with the script. Any idea why there’s a delay in executing the script?
When the counter light is turned on (manually), the island light turns on but only after a period of time, usually thirty seconds.
I see the exact same issue. I have an HS200 the controls some outside lights and is also used to trigger an HS100 (in a water-proof box) that controls some additional outside lights. When I manually switch the HS200, it takes from 3 to 28 seconds to trigger the HS100.
I have attributed this to the speed of my RPi4… and huge path length of the HA code.
HA is running in Docker on a QNAP NAS. I’m thinking the same as you. The NAS is taxed. System overview often shows the processor pinned at 100%. I have a spare PC that I’m thinking of installing Ubuntu, Docker and HA on to test this theory. I’m not a `nix user so the process is bound to be slow. I anticipate a week or so before it’s up and running. I’ll report back here if there’s any improvement.
One thing that still puzzles me is why, when the SmartThings integration is used, does this automation perform so much faster. Doesn’t HA process the SmartThings integration different to the TP-Link integration?
I keep seeing this error in the logs when I restart:
Logger: homeassistant.config_entries
Source: components/tplink/common.py:122
First occurred: 11:26:19 AM (1 occurrences)
Last logged: 11:26:19 AM
Error setting up entry TP-Link Smart Home for tplink
Traceback (most recent call last):
File "/usr/local/lib/python3.8/site-packages/pyHS100/smartdevice.py", line 115, in _query_helper
response = self.protocol.query(
File "/usr/local/lib/python3.8/site-packages/pyHS100/protocol.py", line 60, in query
length = struct.unpack(">I", chunk[0:4])[0]
struct.error: unpack requires a buffer of 4 bytes
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 228, in async_setup
result = await component.async_setup_entry(hass, self) # type: ignore
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.8/site-packages/pyHS100/smartstrip.py", line 43, in __init__
children = self.sys_info["children"]
File "/usr/local/lib/python3.8/site-packages/pyHS100/smartdevice.py", line 186, in sys_info
return defaultdict(lambda: None, self.get_sysinfo())
File "/usr/local/lib/python3.8/site-packages/pyHS100/smartdevice.py", line 196, in get_sysinfo
return self._query_helper("system", "get_sysinfo")
File "/usr/local/lib/python3.8/site-packages/pyHS100/smartdevice.py", line 120, in _query_helper
raise SmartDeviceException('Communication error') from ex
pyHS100.smartdevice.SmartDeviceException: Communication error
Just adding my 2 cents here.
I have 15 TP-Link switches in my house (HS200 and HS220). The switches where going unavailable many times a day. Even the one next the router (an old Asus RT-N66U) would be unavailable even though it was more stable than the one at the other end of the house which loses signal more frequently.
I just got a new router (Orbi AX6000) 2 days ago and since the last 2 days not a single switch became unavailable.
The switches are using the TP-Link integration and none of them are using static ip.
Since they are behind drywall and in a metal enclosure maybe they have difficulties getting a good signal.
Just hope the new router helps and it stays like this.
@rcblackwell likewise triggering the switch from the lovelace user interface is “instantaneous”.
I don’t know if the “turn ON” automation to switch a light on happens at 6:00:00 PM or 6:00:30 PM, but I know for sure that the triggering of one event in the TP-Link integration with another, takes “forever” (e.g. approaching 30 seconds
I managed to build a Linux Debian 10.6 server and copy the configuration files from the NAS to the new HA server over the weekend. Sad to say, performance of the Automation (Kasa Switches) is exactly the same. The routine takes about 25 seconds to execute. I’d say the issue is not related to the QNAP NAS, or in your case the RPi. It seems to be related to HA or more likely the TP-Link integration. Monitoring switch position from Lovelace I see the first switch takes about 25 seconds to report back its new position. As soon as the status of the switch changes the second switch operates. It seems status reporting is delayed thus causing a delay in the Automation.
@rcblackwell your conclusion is sound. I too lean towards the delay being contained in the TP-Link integration.
Thanks for running the Debian test; it reinforces the suspicions. I don’t have the skills to examine any related source code in GitHub.
Aside from operating independently of the TP-Link severs, my favorite feature with HA is to be able to turn on lights with an “offset” from sundown as it gets dark inside, sooner than it gets dark outside. I have not made any special accommodation for cloudy days (yet).
Another thing I discovered is that dimmer switches (HS220) are not discovered by the integration. There was a need to add their ip addresses manually in the configuration.yaml file.
Is anyone watching this thread familiar with this integration and willing to look into these issues?
For the time being to fix the unavailable tplink issues, you need to run the modified tplink component as a custom component (or overwrite the HA version). These changes will fix the issue but we have been having trouble getting them approved.
I had a similar problem with a new HS210 switch - where the status of the switch lagged. Switch would turn on instantly, but the toggle would switch back to off and then back on again due to lag in status.
I fixed that one by making the following changes to switch.py in the tplink component in HA.
def turn_on(self, **kwargs):
"""Turn the switch on."""
self.smartplug.turn_on()
self.update_state()
def turn_off(self, **kwargs):
"""Turn the switch off."""
self.smartplug.turn_off()
self.update_state()
Add the “self.update_state()” to both the def statements like shown above. I really am trying to get all these fixes in place and into HA.
I can zip up my entire modified tplink component if that makes things easier. I’m using it with the latest HA version 115 and no issues at all. We realize these are work-arounds, but at least they work until we have the re-written integration using the latest python-kasa library.
I downloaded TPlink.zip to my WIndows system. Unzipped it and then copy the TPlink folder to /config/custom_components on my RPi4… (SMB) then restarted hassio/server management . I didn’t see anything in the the log to show that I was running anything “different”, so I went to Supervisor -> System and rebooted… still not sure what to look for in the log…
No operational change… (all TP-link devices available) still experience a 15 - 25 second lag from the time I press an HS200 switch to the time the switch status changes in the lovelace UI.
should the folder in custom_components be TPlink or tplink ?
did your changes address the switch status reporting “lag”?
should I be posting these questions on the github site?
Your help is very much appreciated!!
All of my TP-Link devices are on a separate wireless VLAN from my RPi4/HA server. Because of this I do not expect the TP-link integration to discover my devices. I set discovery: false, and explicitly list all of my TP-link device IP addresses.
@YetAnotherDave I was going to try this out but I see you already have, without success. Thank you for taking the leap. Did you remove the TP-LINK integration prior to configuring manually?
Under the “custom_components” directory, you need to make a “tplink” directory - and then unzip the contents of the archive into that location. When you restart HA, you should see a message about it using the custom component.
The other option is to backup your current HA tplink data, and use the files in the archive. For Windows, this is the location on my system:
@markhofmann11 thanks!
I’ve got it running as a custom_component (changed the directory name from TPlink to tplink)
2020-10-09 11:14:26 WARNING (MainThread) [homeassistant.loader] You are using a custom integration for tplink which has not been tested by Home Assistant. This component might cause stability problems, be sure to disable it if you experience issues with Home Assistant.
All is fine… but it does not address the 25 second lag from when I press an HS200 to also trigger an HS100 (this automation works instantaneously when I switch the HS200 via the lovelace UI)… I’ll open this as a separate thread.
@YetAnotherDave, Pleased to hear you managed install of the custom integration. I’ll follow you over to the new thread so I can follow along/contribute to the switch delay issue.
