There is a long-standing bug in the TP-Link integration. This integration appears to have been orphaned; there don’t seem to be any developers working on it.
Probably the longest-running thread on this problem is here:
In summary, the TP-Link “Kasa” app has no trouble seeing these devices, but HA fails and reports “unavailable” any time there’s a minor network disruption or if HA starts before the TP-Link device is connected. From the symptoms, it appears that the HA integration never re-tries the connection, while the Kasa app does.
This issue keeps getting reported in various forms, but it never seems to be addressed.
My observation of this particular subject is that there is a fundamental flaw with the current ‘code owner’ policy for pull requests. There was a pull request that would have fixed this ages ago but it went stale because the code owner wanted to do it differently, but then didn’t do anything with it. The current ‘wip’ pr for the tp-link integration is about 8 months old and (unless something significant has happened fairly recently) is still miles away from being merged.
IMHO this is a significant error in the integration and should have been hotfixed with the patch, and then if the code owner wishes to do it differently he/she can refactor at their leisure.
Technically, if the code owner just decides to never return, then this will never be fixed as nobody will merge a PR without the code owner’s permission. Feels like a broken policy to me
If this is broken (which I believe it is) then it should not appear on the integration page TPlink. People may be buying these (like me) thinking they will work with HA.
These are very popular and very good devices. Could really do with being a priority to get this patched.
I’m not sure its as broken as its being made out to be. I’ve got half a dozen of them HS110’s and they’ve been fine for me.
They do unfortunately show a bunch of update failures in the log which is a bit messy, but its only temporary (they have ~-50dBm signal so its not signal issues), and they still operate perfectly; no unavailable shown in logs, and switching them on/off is OK.
Thank you for letting us know. I can’t wait to see this issue finally put to bed.
My only comment is I wonder if the 20 retries is sufficient. If the entire 40 seconds goes past without a reconnect, would it make sense to try again every so often? Every five minutes, every hour, whatever works.
Based on a conversation I had with @TheGardenMonkey I believe he has some other long term ideas for the integration as well. He seems genuinely interested in fixing it.
The pull request I submitted today is an updated version of what I submitted last year and what I and I know some others have been using successfully for various tp-link switches including the 6 port one. I would definitely appreciate testing and feedback. I know there is the issue of the “delay” when attempting to turn on / off multiple devices simultaneously, but other than that I haven’t noticed anything.
I started off using HA Supervised install for docker on a raspberry pi 4b 4GB and would have the issues you described all the time.
I recently moved my installation to a HassOS VM running on VirtualBox on top of Windows 10 on a NUC and I havent had a single issue with any of my tp-link devices ever since.
Not sure if this was a coincidence or something worth looking into?
As the person who started the top thread I should add mine have been solid for quiet sometime (and note I had the same issue in the Kasa app). Upgrading the firmware on the plugs (I now have 5) and my UniFi gear to the latest firmware has got rid of the problems I was having.
The only annoyance I have remaining is when Home Assistant is started and they are unplugged/turned off at the mains they will never be picked up by Home Assistant until I restart it - unlike Chromecasts for instance.
I think this is another aspect of the same problem. For example, if my power goes out, obviously HA and all the TP-Link smart plugs are off. When it comes back and they all re-start, sometimes HA is ready to look for the plugs before they’re back on line. In this case they remain “unavailable,” apparently forever.
I also did a lot of network tweaking, to make sure they always have a solid connection. This has significantly lowered the number of times they go “unavailable” to the point where it’s now rare. But if a neighbor reboots their router and it chooses a channel which conflicts with mine, I start seeing the problem again.
In other words, I think the problem still exists, it’s just that not everyone sees it.
My main goal was to prevent the devices from going unavailable issue (which also happens to resolve the issue of devices that are on from not getting added). In the current code, if a device stops responding, HA will mark it has unavailable immediately. However, one reason the switches go unavailable is due to them receiving too many consecutive / back to back / simultaneous requests. I would suspect that people who have restricted access to their switches to just HA probably see less issues, but those who haven’t are getting competing requests with Kasa and HA.
I have seen multiple people say that making some changes on their network have reduced or eliminated the unavailable issue, but I can’t figure out why that would make a difference. I have 30+ tplink devices (some are not always connected like some holiday switches) and I pretty confident that I have a good network setup, but without the retry attempts I always have at least 1 to 5 devices that will not get added to HA on startup and the same amount that will go unavailable after some random amounts of time. I have not blocked access to my switches out of laziness
The easiest way to test it is to copy the .py files from the pull request to a folder in your custom_components directory. I use the pip install of HA so I don’t know how you add custom_components in the other versions, but I assume it is pretty much the same / similar. When HA starts it will see that custom component there and will ignore the installed version.
I have 5 HS110s. When I first installed them I found they were calling home to aps1-api.tplinkra.com at least once a second every hour of every day. I installed pihole and blocked the domain and this somehow reduced the number to “only” about 20,000 a day. This seemed to reduce the frequency they went unavailable, but I’m not sure if it also blocks firmware updates (they’re on HW 2.0, FW 1.5.7). I also found some improvement by putting them on a guest 2.4GHz-only wifi connection.
I think it’s a bit harsh to blame the integration - the wifi light on the plug goes off at the same time, so I’d say they’re dodgy devices that the integration would have to work around. I have several other brands of plugs with no problems whatsoever.
I don’t think assigning blame is productive. Obviously TP-Link designed them in such a way that they’re not reliably available on the network at all times. If it’s true that they “phone home” once per second, my opinion is that’s just poor design. Presumably the developers chose to do other things I’d disagree with, too.
On the other hand, if that’s the way they were designed, and if you’re going to write an integration to work with them, you have to take their design, like it or not, into consideration.
Which brings us back to mf_social’s comment; if the Kasa app works, and the HA integration doesn’t, it’s hard to blame anything else. The only way forward is to make the integration work at least as well as the app. Personally, I have confidence that the HA developers can do better.
I think the Kasa app is slower to react. I’ve sat and watched and the light on the plug starts flashing (presumably lost wifi), and HA says it’s unavailable, but Kasa still thinks it’s online. For me Kasa only says it’s unavailable when it is offline for a while (red light on the plug I think). A cynic might suggest TP-Link knows the devices have problems and have their software work around it.
Your scenario is not the one that is being complained about here. We’re talking about tp-link devices that are available and usable in the kasa app, but that homeassistant reports as unavailable until restarted.
