TP-Link Switches going "Unavailable"

Configuration
196

Hi All,

I am relatively new to Home Assistant however with the comments in the thread I managed to get my three Kasa (2 x HS100 and 1 KP303) devices to connect without issue until this week.

I have been using the custom zip from MarkHofmann11, with static IP entries and no discovery. All of this was working until Tuesday night (lasted about 1 month). In the logs I saw that each of the switches (HS100) became unavailable and then the strip also dropped off. Nothing I did would restore the devices or entities.

At a similar time I had performed a number of updates on components however I am now not sure if I had 0.117.6 before or after the issue. However removing the custom integration gave me a blank box with no devices (i did not look at the logs).

Today I have deleted and reapplied the custom zip. After reloading I watched as it created the pycache and I get the following error in the logs

Logger: homeassistant.components.switch
Source: custom_components/tplink/switch.py:36
Integration: Switch (documentation, issues)
First occurred: 6:47:09 PM (1 occurrences)
Last logged: 6:47:09 PM

Error while setting up tplink platform for switch
Traceback (most recent call last):
  File "/usr/local/lib/python3.8/site-packages/pyHS100/smartdevice.py", line 115, in _query_helper
    response = self.protocol.query(
  File "/usr/local/lib/python3.8/site-packages/pyHS100/protocol.py", line 47, in query
    sock = socket.create_connection((host, port), timeout)
  File "/usr/local/lib/python3.8/socket.py", line 808, in create_connection
    raise err
  File "/usr/local/lib/python3.8/socket.py", line 796, in create_connection
    sock.connect(sa)
ConnectionRefusedError: [Errno 111] Connection refused

The above exception was the direct cause of the following exception:

Traceback (most recent call last):
  File "/usr/src/homeassistant/homeassistant/helpers/entity_platform.py", line 197, in _async_setup_platform
    await asyncio.shield(task)
  File "/config/custom_components/tplink/switch.py", line 36, in async_setup_entry
    await hass.async_add_executor_job(device.get_sysinfo)
  File "/usr/local/lib/python3.8/concurrent/futures/thread.py", line 57, in run
    result = self.fn(*self.args, **self.kwargs)
  File "/usr/local/lib/python3.8/site-packages/pyHS100/smartdevice.py", line 196, in get_sysinfo
    return self._query_helper("system", "get_sysinfo")
  File "/usr/local/lib/python3.8/site-packages/pyHS100/smartdevice.py", line 120, in _query_helper
    raise SmartDeviceException('Communication error') from ex
pyHS100.smartdevice.SmartDeviceException: Communication error

None of the devices will connect.

However I have now manually copied the code from the dev information on the https://github.com/home-assistant/core/tree/dev/homeassistant/components/tplink

In this situation my KP303 works perfectly however I still get the errors from my two HS100 units which are using firmware 1.01

Logger: custom_components.tplink.common
Source: custom_components/tplink/common.py:150
Integration: TP-Link Kasa Smart (documentation)
First occurred: 6:54:02 PM (2 occurrences)
Last logged: 6:54:02 PM

Unable to communicate with device 10.0.3.15: Communication error
Unable to communicate with device 10.0.3.17: Communication error

All units have continued to be accessible via the Kasa app at all times and I can ping both devices.

So there seems to be something specifically wrong with the communication in relation to HS100 devices.

Any thoughts or more information i can provide?

197

I don’t know if this is of any help, but I have noticed a correlation:

I too was having intermittent issues with some of my HS100’s (I have 6 total), I read through some of this thread and have changed to manual discovery (they already had static IPs). Since moving to manual discovery, there is a clear split: 4 units are now rock solid. 2 units are still a PITA. I looked at the hardware/firmware revisions and:

  1. HW 4.1 FW 1.1.0
  2. HW 4.1 FW 1.1.0
  3. HW 2.1 FW 1.5.10
  4. HW 2.1 FW 1.5.10
  5. HW 2.1 FW 1.5.10
  6. HW 2.1 FW 1.5.10

First, what I found confusing was the HW Revision, 2.1 and 4.1. This is because the 2 units that are 4.1, were purhcased SEVERAL YEARS BEFORE the others. My first thought was that the 4 units with the 2.1 hardware revision must have been older stock, but they were all purchased from the same reputable retailer. I doubt this is the case.

So for me, at least, it looks like the manual discovery has provided enough stability for the 4 newer(?) units, but those 2 older(?) ones are looking like they might get Freecycled and replaced with Tradfri Zigbee units (which are solid by the way - I just wish they had a button!). If the hardware revisions are indeed correct, I am unsure why TP-Link have chosen to number their hardware revisions in this manner. If they incorrect (chronologically/logically speaking), and 4.1 is indeed older than 2.1 then this points to a clear issue with some of the older units (and the mental state of TP-Link engineers). In any case, I am sure I won’t be buying any more of these. It’s become a bit of a joke in our house, and Wife Approval Factor has waned significantly!

Hopefully this helps someone else who’s got a few of these and is only experiencing sporadic issues with some units.

198

I have checked my hardware revision and mine are both HW 4.1 FW 1.1.0 (correction from my previous post). Mine a UK versions just to prevent any confusion.

Both of these units are brand new, purchased from Amazon in the last month so I would be very surprised that these were old stock. I have checked the units and the serial number gives no clues to the production date but I still have the boxes and will look when I next go in to the loft.

199

Very strange. Mine are also UK units and all were purchased from Curry’s PC World (not usually a retailer I would use but on both occasions were on massive black Friday promo). I can’t remember off the top of my head but the order with 2 units was purchased 2017/2018 and the order with 4 units was definitely end of 2019. I am assuming that the the 4 units with same HW/Firmware were delivered in the 2019 order, but I can’t rule out it being 2 x HW 2.1’s and 2 x HW 4.1s… it seems unlikely though… that’s a hell of a jump in hardware revisions for a massive retailer with high turn over to be sending out in the same order.

Edit: forgot to mention that my 4.1s were also accessible via the Kasa app like yours were. It’s just HA that couldn’t communicate with them.

Edit 2: So just looking at HW versions that others have, I never see any mention of 3.1 or any 3.x version. So I am guessing that at the end of 2019 was the tick over of the 2.1 to 4.1 versions, and my original order of 2 x units back in 2017/2018 were indeed 2.1 and in 2019, the four units most likely consisted of 2 x 2.1 and 2 x 4.1. So they’ll still be under warranty, but I don’t think this will help as it seems to be a 3rd party integration issue. The Kasa app is fine.

200

Is anyone familiar with how to create a ruleset in an edgerouter 4 to block the updates… (GUI) never really went beyond the default firewall settings… :grimacing: they all have static ips… my first attempt ended up blocking internet to everything… I created a group with all the tplink devices… but with the rules in the rulesets in the groups… I feel lost and can’t seem to find a clear explanation when googling

201

Before doing any firmware updates, especially for UK or EU hardware, you might want to check this thread:

202

@CaptTom - thanks for the link. This is rather annoying but it explains why they no longer work with HA.

I will have to consider the options going forward as they were otherwise good units.

203

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.

204

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.

1 Like
205

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

206

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.

208

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.)

1 Like
209

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.

1 Like
210

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.

1 Like
211

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.

212

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.

213

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.

214

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.

215

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.

216

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.