I had the same experience with the hs105’s. Luckily I got them on Amazon and returned them for a 4 pack of Sonoff R1’s. What’s weird is that they would show up fine in the Kasa app but were going unavailable quite frequently in HA.
I found out that a stable connection is really important, I found a clear wireless channel and that’s the only way they’ve been working fine for months.
Now since last week there’s some interference and they started having issues again.
I find it bad that they might go offline momentarily and come back online but they still show up as unavailable in Hassio until I reset the integration. I control them via their Kasa app, so they’re connected and responsive.
It’s expected that devices lose some connectivity or have a degraded connection from time to time, so that’s completely normal and acceptable. My best guess is that the issue is with their local API or the integration.
FYI in case this helps others - I’ve noticed that one or two of my HS100’s seem to change their IP address for no reason. I wouldn’t notice it if I wasn’t running arpwatch, so I get emails when new devices show up on the network, or when mac addresses change.
It looks like the code after discovery uses the IP address, so it will break when the IP address changes.
I was having this issue this week after adding two additional TP link switches. Allocating static IPs and disabling discovery fixed the issue for me as well.
For what it is worth – I had this same issue with HS105 switches going unavailable, sometimes multiple times in a minute, while right next to a Ubiquiti NanoStation locoM2. I switched (!) over to some Sonoff devices and threw the HS105s in my junk box.
Fast forward six months, and for the holiday season I needed a couple of HA-enabled switches. So I grabbed the HS105s and configured them on on a different access point (an el-cheapo TrendNet).
The two switches have been rock solid on the TrendNet access point, not a single drop out in days.
Curious if anyone has found a solution to this problem. I recently upgraded from version 84.6 to 103 and the TP-link bulbs that used to be rock solid on the old version now drop in and out. I see there was a ‘fix’ in version 100 to address this but it must have only be for a specific case. I have tried removing the TP-Link discovery from the configuration but it does not help. Same router as before and lights respond with KASA app.
I have two TP-Link HS-110s. The only way I’ve been able to minimize the “unavailable” issue was to (1) reserve IP addresses for them in my router, and (2) leave auto-discovery ON in the HA Config. They do still drop occasionally, but my theory is the auto-discovery succeeds in “finding” them again.
It should be noted that the TP-Link “Kasa” app has no trouble accessing them, even when HA can’t. It’s tempting to blame TP-Link, or the user’s network, but I think the facts point to a problem in HA that, somehow, the Kasa developers have managed to overcome.
Add me as another having trouble with TP Link devices disappearing, mostly on restart. I hadn’t noticing them disappearing once they are (finally) discovered.
The problem is during playing around, I reboot a lot. And they are disappearing after restart, a lot. It’s becoming an issue.
Wish there was a way to kick off the discovery process after boot. 
Not sure if it helps or if anybody is already posted this I had my TPLink plugs set up under integrations but they kept on going unavailable. I manually added them to configuration.YAML and since they have been fine
We have a dozen+ devices. It’s not too much to ask for this auto-discovery component to work properly. At the very least, a way to re-trigger the service discovery without having to reboot each and every time.
1 Like
I noticed that I only started seeing my tp-link switches (HS 110s) going unavailable since upgrading to HA 0.103.5. I rolled back to 0.103.4 and so far (not long enough to be sure), all the switches are available…
EDIT: Never mind, about 24 hours later and the tp-links are unavailable again on 0.103.4.
Here’s a commit from Nov 26th that seems like it could be having an effect on HA finding tp-link smart plugs.
Hi, I also have a couple of HS100’s and I just upgraded to 0.103.5 from 0.84 and I noticed that I cannot customize the switch anymore.
I used to include this in the customize.yaml
switch.table_lamp:
friendly_name: Table Lamp
icon: mdi:lava-lamp
But I cannot seem to get it to work.
OK, just fixed. I needed to put custimize.yaml like this…
homeassistant:
customize: !include customize.yaml
Having the same issue as everyone mentioned here. I strongly suspect that it’s due to wifi not reaching it or something like that. My switch is down on the floor behind a dresser so it’s sandwiched between two “walls”. I’ll see if I can find another plug to put it on but it’s currently in the best place so I’d rather not move it if I don’t have to.
Interestingly enough, Google Assistant ALWAYS works on the Kasa switch. I don’t know if it’s because I use it on my Google Hub (which is in the same room as my Kasa switch, as opposed to my router).
Edit: I did an upgrade to to 0.104.0 and now my switch is being detected. Maybe I just need to restart Hass? I was also running high on memory so a restart helped anyway
Having the same issue with a HS110 plug. It’s definitely not a connection issue (it’s 5 metres from the access point) and I can always turn it on/off using Alexa and the Kasa app.
However, the home assistant integration only works like 50% of the time, and often I have to restart HA for it to work.
Since I have a SmartThings hub, I have connected the HS110 plug to that and I’m using the SmartThings integration in HA to control it, but this is far from ideal as I no longer have access to the energy usage data.
1 Like
Thank you for documenting your experience here. I think this helps demonstrate that there is a problem with the HA integration. We already know the Kasa app is able to communicate with these devices without throwing “unavailable” errors. Now it looks like SmartThings also operates without doing so.
Obviously there are a lot of things that can go wrong with any individual installation. And I know it’s easy to dismiss all problems as one-off network issues or user errors. Especially when many are reported here as found and fixed.
But there is an underlying problem with the HA integration. It’s a shame, because the TP-Link devices are pretty good hardware at a reasonable price. I worry that not being able to effectively use them is enough to drive people to look for alternatives to HA.
I believe the SmartThings Kasa integration works by cloud polling since I was asked for my TP-Link account credentials when I added the plug to my SmartThings hub (SmartThings > Kasa Cloud Server > Kasa Plug).
The HA integration works by local polling and no TP-Link credentials are required (Home Assistant > Kasa Plug). Perhaps that could be the source of the problem?
I had a similar problem with one of my HS110 and i realized it’s date and time got wrong somehow and after resetting it to factory settings and re-initialising in Kasa app it’s been working flawless.
All I got to say is the reliability of TP Link discovery is becoming a huge issue. I have about a dozen TP Link devices, and when I reboot, something is always showing unavailable.
I’m so reluctant to reboot when HA finally discovers everything. It’s getting really hard to get a clean (fully-connected) reboot these days.
HA seriously needs a way to trigger a discovery, post boot.
I know what you mean. I have enough stuff in Home Assistant now that its reliability window is only a day or two before something breaks. Could be one of my TP-Link HS200 switches goes permanently Unavailable, or the HomeKit power bar drops out, or the Alexa integration breaks. And it usually takes me a couple of tries to Restart successfully now, with manual command-line intervention via SSH to stop/start the service, as something inevitably times out during startup and causes the HA service startup to get stuck. It’s very annoying to realize that something has dropped out of service, restart, fail, stop, restart again, something different didn’t initialize correctly, stop again, start again… etc etc.