I’m running into a similar problem as you @YetAnotherDave and did exactly as you did with the switches, one by one until they all recognized and even got the problem with “strip” suddenly turning all of my existing devices to some kind of error, almost like unavailable, but more a communication error. I kept the “discovery: false” piece commented out still as that seemed to make it work better.
How did you get “strip” to recognize? Assuming you did nothing special based on your previous post. I’m trying to add a KP400 strip.
After I upgraded to 0.115.1, I un-commented the strip & host lines shown above. This made ALL of my switchesonce again go UNavailable. I re-commented them, then ALL of my switches returned to AVAILABLE.
After I upgraded to 0.115.3, I un-commented the strip & host lines shown above. ALL of my switches remained AVAILABLE and my KP400 with 2 outlets also showed as AVAILABLE. It now all works as expected.
From my point of view 0.115.3 fixed the issue. I have no idea what explicitly fixed the issue. I am NOT rushing to install 0.115.4. I will stay at current levels until a compelling event occurs.
Thanks @YetAnotherDave. After you confirmed it all seemed to work for you, I tried again and it worked. I made the mistake of putting the wrong IP address for my KP400, but after correcting it all works beautifully now.
Now that it’s working, I’m with you on not rushing to change anything else.
I’m having similar issues. All my TP-Link devices became unavailable yesterday. I was on 0.115.5. I tried upgrading to 0.115.6 and they are all still available. Multiple restarts of HA have not helped.
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.
