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.
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.
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.
Experiencing what sounds like the same issue. I recently added 3 additional TP-LINK Kasa smart dimmers to my previous 1 TP-LINK Kasa dimmer (for a total of 4 Kasa dimmer switches) and I cannot for the life of me get the new dimmers to show up in HA.
Removing and re-adding the Kasa integration does not seem to help at all, as it stubbornly holds onto this “memory” of the previous one TP-Link dimmer switch on the network.
It’s as if the Kasa integration is not even bothering to check for any new devices – it just reads some cached config file and carries on with that.
Is there some more “complete” way to remove / erase an integration like this? Such that no trace of any previous install /configuration remains?
Have same issue… sucks to revive an oldie, but both of my TP Link HS100’s no longer work. Keep wondering why my bed light was not waking me up for past week!
Even worse… I bought more on the black friday sales.
Have tried repairing them to the network, even purged them from the ubiquiti router (and rebooted it). Nothing works. Seems like something change in past revisions of HA
I am having the same issue after restoring a snapshot to a new RPI 4 8GB 64bit running on a SSD from a RPI 4 4GB 32bit. My 6 TP-Link light switches worked fine on the previous install of home assistant, now after the restored snapshot, they all show “entity not available”. My “new” RPI has the same IP address as the previous (reserved in router) and the Switches have the same IP address (reserved in router). I installed the TP-Link integration originally through Lovelace with auto discovery enabled. I have tried adding
tplink:
discovery: false
light:
- host: 192.168.1.12
etc.
to the configuration file but that does not fix the problem, delete, reinstall, reboot, with no luck.
The information provided makes it impossible to assess where the issue may be. Are the entries in your configuration.yaml file formatted as shown below?
Sorry I must have never posted the solution, I was able to fix it by assigning all my light switches static IPS and manually mapping each up in the TP-Link config.
I have 4 Kasa smart bulbs, and regularly get “unavailable” states. I’ve removed the devices and entities, used static IP addresses on my Router, then manually configured the devices in HS.
Great, they all work fine. Then the next day, they’re back to “unavailable” and no end of rebooting both HA and the bulbs makes any difference, until I remove the devices in HA and add them again… and round in a circle we go again. All this time the Kasa app is rock solid, and Amazon Alexa is very happy to control the bulbs on request.
They all did respond fairly well for some time, but after an update to HA at some point, all went pearshaped. It has to be a timing issue of some sort, assuming no-one is messing with the integration at each update.
Tearing my hair out here… any developments?
