I solved mine. It was a IP address conflict! DOH
I bought my first TP-Link HS100 today, it was a twinpack with two plugs.
Weird problem; either one of the devices will connect at any given time with full functionality, but not both together.
They show up as separate devices on my router with different IP and MAC addresses when connected independently, but only one can join at a time with the second device joining showing a network error.
I’m using a Telstra Router and they have the same device name on the admin console - I tried isolating the problem with MAC address name reservations, but the same result.
Factory reset done on both, yet the problem persists - any ideas, please?
My setup was working fine until the latest HA update. Now, have tplink setup again using the new configuration, but they are unstable as others are describing. Work at first then randomly go unavailable or do not load at all. Anyone having this issue with the new configuration?
I haven’t been able to get my four TP-Link switches connected since 89.0 update. Trying old method, new tplink: method, integration and combination of all. Docs are weak.
If you need help you have to post what your configuration looks like, log, etc. If you just want to complain the docs are weak… that’s possible as well ofcourse but not likely going to solve your issue.
1 Like
The old -platform method is no longer used. Try this to reconfigure your settings:
Also, as an aside, one of my TP-Link devices frequently goes unavailable since the update as well. Causes problems for me because it’s also used to trigger other automations. When it becomes available again it goes back to previous state which triggers the automation again when I don’t want it too. Tried finding a setting to increase the time before it errors out but didn’t find anything.
Here is my entry in configuration.yaml:
TP-Link
tplink:
discovery: false
light:
- host: 192.168.1.205
switch:- host: 192.168.1.200
- host: 192.168.1.201
- host: 192.168.1.202
- host: 192.168.1.203
- host: 192.168.1.204
- host: 192.168.1.206
- host: 192.168.1.209
My log says the following:
Error setting up entry TP-Link Smart Home for tplink
7:11 PM components/tplink/init.py (ERROR)
Failed to connect to switchmate
7:11 PM /usr/local/lib/python3.7/site-packages/switchbot/init.py (ERROR)
Thanks for any help.
Weird how I would constantly get errors saying it can’t read the states. And it’s what’s even more strange is that the switch would turn off on its own after a few minutes . I deleted the TP-Link integrations, hoping that would fix it for the time being.
Any update on this from anyone? I have the same issue and was thinking I would need a new router (currently using a Rogers CODA) or extender, but this also happens to TP-Link devices that are right next to the router.
Also happens right in the Kasa app, so not specific to HA
I also had issues with one of my TP Link HS-105 switches constantly disconnecting (with my history being littered with disconnects just like in OP’s screenshot), but I managed to find a solution that works for me and wanted to share in case it can help someone else. Long story short, it had to do with WiFi interference and moving the switch.
Here’s my anecdotal evidence: one of my switches would constantly go offline. It’s about 6ft away from the router without any wall in between, so you’d think connection shouldn’t be a problem. But, in my case, my Raspberry Pi running HA with a Zigbee USB stick connected was about 1.5ft away. As I found out, Zigbee is also on the 2.4GHz band, just like the WiFi radio of the HS105. So I got myself a 6ft extension cord and moved the HS105 about 4ft away from my Pi. I did this 4 days ago, and so far it has not dropped connection a single time, while before it would drop 100s of times a day. Just to rule out the extension cord somehow affecting things, I moved the switch back next to the Pi while still plugged into the extension cord, and the connection started dropping like crazy again.
So in short, if you’re having issues with the HS105 (or other TP-Link switches) disconnecting, try to think about if there’s some device that could be interfering with the 2.4GHz band nearby and consider doing something to boost your WiFi signal (as @jono did). I think these switches are just really bad at dealing with interference.
1 Like
Had the same issue. Even tho in the Kasa app it showed my HS200 had -45dbm strength, it was dropping out every few minutes. I changed the wifi channel on the AP and it hasn’t dropped out in hours.
I occasionally have the WiFi switches go “unavailable”, and it’s not just the TP-Link ones. I totally understand this - Home Assistant only updates status on a schedule, so if the WiFi connection to the switch is temporarily lost in a weak signal area, or heavy traffic from another device in the same area is temporarily affecting communications, I would expect to see that “Unavailable” temporarily. Often Google or Alexa also can’t communicate with the switch briefly when that happens. Usually it recovers on its own after a little while and shows normal status.
My problem is that my TP-Link HS-200 sometimes goes “Unavailable” and never recovers. Unlike the other switches, it gets stuck at that state permanently, even though the switch is working fine for Google and Alexa. The only way to fix it seems to be to reboot HA. I don’t know why only the HS-200 behaves this way, or why HA can’t recover from this state on the next scan.
After the tplink integration im experiencing unavailability from all of my tplink devices.
It’s strange that before the integration everything worked fine and after it they blame on the tplink connectivity part and not on the hassio code.
I guess if you want to be sure if it’s HA or not you can go back to an older version of HA and see 
I had this same problem which got worse more recently. I wasn’t sure whether it was because I had more TP-Link devices.
In my home network I have multiple UniFi APs and I read a Ubiquiti Networks support article that referred to interference in setups with multiple APs whereby devices get “overwhelmed” by multiple strong AP signals, even if they are meshed with the same SSID.
The recommendation was to turn down the TX power on the APs to the range 14-18dB. Almost immediately I saw a massive improvement in TP-Link performance with devices much more responsive and they’re no longer dropping off the Kasa App or appearing as Local.
This may not help folks with single AP setups but thought I would share my findings.
Pete
1 Like
It does appear the TP-Links suffer from multiple signals - even if the same SSID. To make things simple, I disabled the 2.4Ghz radio on all of my APs except for one. Turned the one to max and set it to “least congested 2.4Ghz”. I have a total of (4) APs to get good 5Ghz coverage, with only (1) with 2.4 enabled. Set to strongest power and least congested.
Been working like a charm - even better than turning all the radios down to 25mW or lower for 2.4Ghz.
The primary issue is not that TP-Link switches are sometimes temporarily unavailable due to poorly-designed firmware that isn’t very robust at handling interference. It’s that Home Assistant sometimes leaves the TP-Link switch permanently Unavailable even though it has recovered for other services like Kasa, Google, and Alexa, and requires a restart of the server to fix it.
2 Likes
The way to fix that is to set the TP-Link switches with DHCP static reservations based on their MAC address. Then define the switches in Home Assistant with their static IPs - and disable auto-discovery. That is how I have all mine setup and they work great.
1 Like
Have you ever have your TP link devices just disappear from HA?
I’ve got all of them set to static IP, however I’m still using auto-discovery, I’ll have to try turning off auto-discovery and see if it they still disappear.
Restarting HA usually get them to appear again.
Ensure you are running HA version .94 or higher and disable the TP-Link discovery. That should never happen again if you do both of those things. I have never had that issue and running .97 right now, disabled auto-discovery and all my TP-Link switches are static.