It looks like some progress is being made on the issue here: https://github.com/softScheck/tplink-smartplug/issues/81
Perhaps this might allow us a route to rebuild the integration to get it working again?
Maybe this is the motivation I need to get my ass back into development and picking up python again.
Ill be honest and say I didnt read this entire thread but I have a temp solution for those that are having this issue.
For me it only occurs when I restart HA.
To get the device back I reload the integration and it always comes back. Im doing this manually so if there is a way to script it I would like to know.
Hello Reuben,
that is precisely how I am doing this and also, I blocked the internet access for the TPLink devices on my router.
I gradually change over to the z-wave devices from Fibrao and I am really happy with their preformance and stability.
Cheers
Dietger
I have a mix of TP-Link Kasa devices including HS103, HS100, HS110, and HS220.
As soon as I installed my Unifi Dream Machine, they all started disappearing randomly from my network and Home Assistant, along with my Sense Energy Monitor, ecobee3 and ecobee4 and Somfy Mylink device.
I seem to have stabilized the TP-Link devices in my environment through the following methods:
I gave every one of them a static DHCP lease, so I know the IP addresses.
In configuration.yaml:
tplink:
discovery: true
switch:
- host: 192.168.10.18
- host: 192.168.10.13
- host: 192.168.10.25
- host: 192.168.10.23
- host: 192.168.10.21
dimmer:
- host: 192.168.10.16
- host: 192.168.10.20
In my Unifi Dream Machine, I created a separate IoT-only SSID running 2.4 GHz only with WPA2.
I nerfed every advanced feature I could find.
Multicast and Broadcast Filtering: OFF
Fast Roaming: OFF
Hide SSID: OFF
Group Rekey Interval: Left default - enable and 3600
User Group: Default
UAPSD: OFF
Scheduled: OFF
Multicast Enhancement: OFF
Beacon Country: OFF
BSS Transition: OFF
TDLS Prohibit: OFF
Point to Point: OFF
P2P Cross Connected: Can’t modify, grayed out
Proxy ARP: Disabled
L2 Isolation: Disabled
Legacy Support ENABLED
PMF: Disabled - disabled and Ecobee and Sense came back online immediately
WPA Mode: WPA2 Only
So far so good. It’s just the Somfy Mylink giving me trouble now, and I think I’m just going to replace it with a Bond Bridge, and gain control of some ceiling fans.
I have the the issue of one device going unavailable after I changed the entity ID (renamed) a few days ago: After an HA restart, only this device will show unavailable until I reload the integration. Until then, the logs show:
2021-04-05 10:52:53 WARNING (SyncWorker_1) [homeassistant.components.tplink.common] Unable to communicate with device 192.168.0.xxx: Communication error
2021-04-05 10:52:53 WARNING (MainThread) [homeassistant.components.light] Platform tplink not ready yet. Retrying in 30 seconds.
The device is otherwise reachable and can be controlled from the Kasa app (even before reloading the integration in HA which means the device is communicating fine).
HA core 2021.3.2.
(Reposted after accidentally replying to to a user instead of just extending the thread.)
Although I don’t use HA I got hold of 3 KP115 sockets to experiment with. I wrote a Win32 C++ console app to control them locally using native windows Winsock tcp sockets on port 9999. Everything works great and is totally stable UNLESS there is a whiff of a wifi extender, repeater, access point, proxy, WDS etc on the network. Any IP reservations are rendered unreliable and therefore useless as the KP units hop between main router and extenders causing the associated MAC addresses to virtualize. For those having problems, try monitoring the MAC addresses for consistency over time. I know that home automation folks like to use additional wifi hardware to isolate networked devices but my experiments show that in my case the extra nodes are not going to work reliably.
BTW, useful Winsock code here:
Payload in hex bytes to turn KS115 on= “0000002AD0F281F88BFF9AF7D5EF94B6C5A0D48BF99CF091E8B7C4B0D1A5C0E2D8A381F286E793F6D4EEDFA2DFA2”
Payload in hex to turn KS115 off=
“0000002AD0F281F88BFF9AF7D5EF94B6C5A0D48BF99CF091E8B7C4B0D1A5C0E2D8A381F286E793F6D4EEDEA3DEA3”
These are encrypted json commands. The complete local protocol is described here:
Additionally, for stress testing I have a 6 way power strip with adjacent 3xTP-link, 2xWemo and 1xSonoff with tasmota all active and 3 thick brick walls away from my Archer router and there are no interference or contention issues.
My TP-Link devices (11 total: 2x HS100, 2x HS105, 6x HS200, 1x KP400) have been stable for more than 6 months now. I decided it was time to block all communication to the outside world.
From my router, I prevent all WAN IN & WAN OUT communication from each HS* device IP address.
From my Pi-Hole, I blacklisted all DNS lookups for *.tplinkcloud.com. This blocks requests for devs.tplinkcloud.com, n-deventry.tplinkcloud.com and n-devs-tplinkcloud.com.
Local operations work as expected. No access from the Kasa App (as expected).
What I did not expect was that these 11 TP-Link devices are now 9 of the top 10 clients in the PiHole Blocked list and 66% of all DNS requests)… i.e. I didn’t realize how often they communicate with their cloud overlords until now.
Has anyone found a firmware update to put these devices into true standalone mode? (minimize outbound requests from the device. only speak when spoken to. etc…)
I found this on the TP-Link Community Forum. …and this elsewhere in the home-assistant world. but I didn’t find the incantations to get these devices to quiet down.
I wish I had isolated the TP-link devices sooner. Really glad I have them walled off now.
If I could cut down on the DNS chatter that would be nice.
has anyone else noticed that their TP Link devices only become usable through Home Assistant after you load into the Kasa application? I can’t get my devices (HS105, HS110, HS107) to work without opening the Kasa application on my iPhone or iPad first. Then the devices become available for a short time.
I have the same issue but I have to uninstall the integration and do a reinstall to get the data coming through to HA. The integration is only fine for a short time. I have tried opening the Kasa app and making some minor adjustments but this does not load the integration.
I had same issue of TP link devices disappearing from dashboard. I had to continually re-add them to the dashboard. They were there, but had dropped out.
I have turned off auto discovery for TP Link as someone else suggested. Hopefully this resolved the problem.
Sorry to necro this thread, but in my case I had overly restrictive firewall rules on my router that were blocking NTP access as well as, oddly enough, communication with Home Assistant itself. I had the devices configured in my firewall (UDM SE) to allow only established & related traffic back to Home Assistant, but this was still not enough as the Kasa appears to be initiating its own packets to Home Assistant. So I opened up all traffic from Kasa to Home Assistant regardless of initiating party.
Another thing that substantially helped was looking at my Wi-Fi signal strength and placement. In my case I have two APs and the plug was roaming between two APs. In my UniFi config I was able to lock the device to a single AP (the closest one) which seems to be helping. I also boosted my 2.4ghz band output from Low to Medium strength as well.
Adding another recent data point - randomly disappearing/being unavailable keeps happening. Debugged to the point where it seems like a subnet specific issue where HA isn’t able to ping the devices (devices can access internet just fine though - Kasa app doesn’t reflect this issue). Other devices on the same subnet don’t have this issue which make me suspect it’s related to flakiness from TP-Link versus something firewall related.
When hitting the hard reset button, the switches started coming back online but it isn’t consistent in solving the issue.
I’m hitting this with one of my 3-plug strips. It is dropping from home assistant with pretty wild frequency, but it never seems to have any issue with reachability through the native Kasa app.
Funny enough, I have a second 3-plug strip and 4 mini plugs that aren’t dropping at all. So I’m really not sure what’s going on here.
Currently I’ve 5 out of 6 in use tp-Link sockets that Home Assistant can’t communicate with but are active in the Kasa app. I’ve had issues in the last two years or so with individual sockets randomly not being available for stretches of time, then suddenly being available again, but never so many at once. I’m resigned myself to the conclusion that I’ll have to replace them all with something more reliable. Whether the problem lies with the integration or TP-Link, I can’t say, but I’ve had enough.
Local Bytes has a reliable (so far) and cheaper smart socket that’s flashed with tasmota.
Its pretty crazy for 2 of 4 TP Link single pole switches, have those switches from 3-4 years and had no issues, since March started noticing this unavailable issue.
OH THANK GOODNESS somebody else is reporting this! That timeline coincides with my troubles. I have 150+ TP link devices and I have done fresh installs TWICE because I’m so desperate for stability. I can look in the TP Link app and I can see the devices having rolling outages.
I have taken many steps to isolate this but all I have is theories.
First, I noticed the problems in the HA error logs starting a few months ago. Issues with devices losing connection (I never saw it in aggregate like you’re showing).
My roomate was convinced it was wifi interference because it was so intermittent. I tested against this by asking my neighbor to turn off his wifi for an entire day while I diagnosed the problem. I had the same instability when my neighbors wifi was off. I have ubiquiti with 7 access points.
Then I thought maybe it was something with my adaptive light add-on. I disabled all adaptive lighting integrations and the issue persisted.
Then, I noticed whenever my hub was off, I started regaining stability in the TP-link app (zero devices showing offline). It was reproduceable, whenever the hub was down, TP Link app seemed to recover. Restart hub, and everything will be stable for a little while and will eventually start degrading by throwing random devices offline.
I verified that there’s not a limit from TP link on how many devices the app can handle. Although I did find a weird quirk where you can’t have more than 37 devices in a group in tp link and that’s apparently new because my groups were created years ago. Thinking this might be a problem, I fixed all groups to under 37 devices. The issue persisted. I removed all devices in TP link and HA that aren’t currently online (halloween and christmas).
I got so frustrated that I ripped all TP link devices out of home assistant a few weeks ago and started to readd them. I experienced stability until I got over 100 devices and then I started witnessing the same symptoms again. And again, shutting down the hub achieves stability in the tp link app.
Now that I re-added all the devices, I thought maybe it’s struggling with polling 150+ devices. I went into all the bulbs and turned off polling because they’re programatically controlled. Physical switches require polling so they can detect when they’re turned on for auto-off countdowns. In the 25ish devices that have a physical switch, polling was left on. The issue persists.
I bought home assistant yellow today because I was so convinced there must be something that I can’t see/fix in my current system and I’m so desperate for stability. Like you, this stuff has been rock solid for years.
wow this looks just like my switches issues that brought me here. I’ve only just integrated my first 2 TP-Link switches (HS103) but they are constantly going “Unavailable” and back. It seems to have “something” to do with the Wi-Fi “strength” or quality as when they’re up in the gameroom near the AP they are solid but here in the office they bounce constantly. Any I wouldn’t say my office has “bad” wifi but it’s just a bit further from the AP enough to cause this issue. Plenty of other non-Kasa devices on the same wifi have no stability issues. (Local Tuya, mqtt, etc.)
I have also had this issue for years. I have concluded that it is definitely due to the TP Link devices requiring very strong wifi. My KP200s almost all have this issue. The only one that is stable is under 20 ft from the AP. I do not have this issue with any of my HS103s, however. I believe this is because they are not buried in the wall, and therefore don’t need to be as close to the AP as the in-wall KP200s.
Recently, I found this thread and followed @YetAnotherDave 's advice. I blocked the TP Link devices from the internet, and blocked DNS for TP link cloud sites using the following regex block:
.*dev.*\.tplinkcloud\.com$
I now see the following two addresses as the most blocked on my network:
n-devs.tplinkcloud.com
n-deventry.tplinkcloud.com
This has made the devices much more stable. Still, though, I am getting a few disconnects per day.
I also have a workaround. I make an input boolean helper for each switch, and use the following blueprint to sync its status with the switch. This way my key automations (like turning the coffee machine on in the morning) succeed (I just have the coffee automation turn on the helper boolean instead of the (possibly offline) switch). The blueprint automation will set the switch to the proper state when it comes back from being unavailable.
blueprint:
name: Stable Switch
description: Use an input boolean to control a switch with poor wifi
domain: automation
input:
actual_switch:
name: Switch
description: Switch to controll
selector:
entity:
domain: switch
helper:
name: Helper
description: Input boolean to use
selector:
entity:
domain: input_boolean
variables:
actual_switch: !input actual_switch
helper: !input helper
trigger:
- platform: state
entity_id:
- !input actual_switch
- !input helper
condition: []
action:
- if:
- condition: template
value_template: >-
{{ trigger.entity_id == actual_switch and
(trigger.from_state.state in ["on", "off"]) and
(trigger.to_state.state in ["on", "off"]) }}
then:
- service: "input_boolean.turn_{{ states(actual_switch) }}"
data: {}
target:
entity_id: !input helper
else:
- service: "switch.turn_{{ states(helper) }}"
data: {}
target:
entity_id: !input actual_switch
mode: queued
max: 10
yup all my tplink switches are completely unreliable with my Unifi APs, even ones close to it. i had to install an old Asus router to connect them to and it’s rock solid. something with Unifi and the TPlink smart swtiches and plugs. sucks, wish there was a solution as it looks janky in my rack.
Are you using VLANs? Do you have Multicast turned on? Do you have mDNS enabled for the network? Unifi has a lot of default lock down settings enabled for the networks. You need to enabled a few things for things to “see” each other properly.