So I have had this problem for quite a while now and every time i restart most of my switches will say “entity not available” and i need to restart an addtional 10-15 times to get them to all show up again.
https://gyazo.com/9f7ef29a8d7690672a94b66cacba4ae4
Is there a way for me to fix this?
I’m not real pleased with the way TP-Link integration works in HA. My experience is that the Kasa app can always reliably see and control the 2 smart plugs I have, and I can always reliably ping them. It’s just HA that sometimes seems unable to communicate, and throws the dreaded “unavailable” error.
I tried hard-coding the IP addresses in configuration.yaml, and disabling the auto-detection, but that made it worse. So now I’m back to taking the defaults (nothing but tplink: all by itself in the config file) and it works most of the time, with lots of intermittent “unavailable” errors.
Getting back to your question, my only suggestions are to (1) give it 10-15 minutes before restarting, and (2) set up static IP addresses in your router so the TP-Link devices aren’t changing their addresses all the time.
If you’ve already done those things, then I’m out of ideas. Maybe someone with more experience than I with TP-Link stuff will chime in.
I am in the same boat…let’s call it the “H.M.S. TP-Link Stinks but I Have Too Much of it to Abandon Now.”
I have switched from using the Integration setup to the manual config with discovery disabled and it appeared to work well for a week. Then I did a restart and all of the TP Link devices are now Unavailable.
Anybody out there have a handle on this?
I’m afraid I don’t have a lot of answers. All I can really offer is my own experience with two TP-Link smart plugs. But maybe if we all do that, collectively we’ll figure some things out.
So far, it sounds like re-arranging the deck chairs on the HMS TP-tanic hasn’t brought consistent results. But we’ve all seen the symptom where we change something, restart, and things got dramatically worse, even to the point of non-functional at all.
I’m still highly suspicious that changes to the IP address of the switches/plugs can confuse HA. I’ve read enough reports of people who solved problems by assigning static address in their router’s DHCP setup that I consider that step one in troubleshooting.
From that, I infer that HA doesn’t do a good job of tracking which TPLink devices it’s talking to. Not knowing the architecture, how it identifies each device, or where that information is stored, prevents me from pulling that thread any farther. But I’m convinced that, once these values get corrupted, nothing is going to fix it short of deleting the entities, or possibly the whole integration, and starting over. I’d also be curious to see if simply deleting the database fixes it, but I’m not ready to go that far just yet.
It’s interesting that some have seen fewer problems by turning off auto-detection and hard-coding the IP addresses in configuration.yaml, while I’ve seen the opposite. Hence my analogy to re-arranging deck chairs. It could be the new settings are irrelevant, and it’s the fact that we changed things which caused it to work. Just as some previous change caused it to fail.
I am looking at the .storage and it looks like it identifies devices via MAC address not ip. I also get this error in my logs
File "/usr/local/lib/python3.7/site-packages/pyHS100/discover.py", line 54, in discover
info = json.loads(protocol.decrypt(data))
File "/usr/local/lib/python3.7/json/__init__.py", line 348, in loads
return _default_decoder.decode(s)
File "/usr/local/lib/python3.7/json/decoder.py", line 337, in decode
obj, end = self.raw_decode(s, idx=_w(s, 0).end())
File "/usr/local/lib/python3.7/json/decoder.py", line 355, in raw_decode
raise JSONDecodeError("Expecting value", s, err.value) from None
json.decoder.JSONDecodeError: Expecting value: line 1 column 1 (char 0)
Could this possibly be a volume problem? I have around 40 different switches and if it’s trying to find them all at once could that cause an error? still looking for ideas on how to fix.
Any update on this problem? It’s maddening to have to restart HA a dozen times in order to get all of the entities to show up. At this point they should revoke the TP-Link integration until it actually works.
I am having the same issue where i have to either reboot a ton of times or power cycle the device i.e. turn of the breaker or unplug and plug back in. It was working for quite a while no issue then all of a sudden this ugly issue has come up.
Yes it is incredibly annoying. Unfortunately I have no idea how to fix it. I guess we need one of the developers to buy one of these (and get annoyed) in order to get a solution.
That sounds about right
The thing is, someone DID develop the integration. And, mostly, it works great. I really appreciate that.
I notice that the TP-Link “Kasa” app doesn’t have these problems. So we know it’s possible.
My theory, and it’s only a theory, is that these devices simply don’t always respond, or don’t respond quickly enough. Maybe the Kasa app simply tries again, or waits longer, where the HA integration throws an error and gives up.
I’m a big fan of doing a good job trapping and reporting errors, so I get where the developer is coming from. But sometimes you have to just deal with what you’re given. If the hardware is expecting you to keep re-trying, then that’s what needs to happen.
Well said, Capt. I agree with your theory, as well. I thought I saw something about extending the retry frequency and/or period and was hoping that would fix it but I’m not sure that it was ever applied. I didn’t see anything in the recent release notes pertaining to this problem.
I was able to fix it by manually assigning the ips
Thank you for letting us know. I think setting IP address reservations is “step 1” in troubleshooting. Step 2 is playing with auto-detection. For me, enabling it got me the best results. Others say disabling it worked for them.
My TP-Link sensors still throw “unavailable” warnings, but they mostly work. My solution is to simply not look at the log, so I don’t get so upset about the warnings.
So after the last HA update the integration with my TP-Link HS110 switch is fine as usual, but all the sensors for power consumption stopped working. In the past the templates mention here were perfect. Now they appear as grey and not supported anymore. Does anyone has the same issue?
I continuously lose contact between HA and my hard IP-coded HS-100 switches, although TP-Link Kasa has no problems and run very stable. There is also dropping contact between HA and some of my Hue’s and other Zigbee (mostly Osram) switches. After a restart of HA it usually fixes the zigbee problems, but the TP-Link is most times still unavailable.
I really think this problem have escalated in the last 6 months, and feel there is something wrong with HA in this case.
I can’t get the template to work at all.
Just updated to 0.106.2 this morning. The templates for my HS-110’s seem OK so far.
One of my devices is showing “unavailable” at the moment. As usual, the Kasa app (on the same network) is rock-solid. In other words, no change.
Yes, the switch works fine, but the templates for total consumption, etc are no longer working.
One week ago I got an error saying it was unavailable due to a functionality that was discontinued, now its just shows unnavailable.
Same has happened with My Xiaomi vaccum and my panasonic TV.
I’m now on 0.106.4
Found one example:
For the TP link switch the error is diferent now:
