search

home-assistant / core

:house_with_garden: Open source home automation that puts local control and privacy first.
https://www.home-assistant.io
Apache License 2.0
73.74k stars 30.86k forks source link

Tp-link Kasa devices stopped working #99449

Closed Srkwithlove closed 9 months ago

Srkwithlove commented 1 year ago

The problem

Hi,

I have been using Tp-link Kasa integration for a long time. It has suddenly stopped working.

What version of Home Assistant Core has the issue?

2023.8.4

What was the last working version of Home Assistant Core?

Not Sure

What type of installation are you running?

Home Assistant OS

Integration causing the issue

TP-Link Kasa Smart

Link to integration documentation on our website

No response

Diagnostics information

No response

Example YAML snippet

No response

Anything in the logs that might be useful for us?

Logger: homeassistant.config_entries
Source: config_entries.py:1250
First occurred: 31 August 2023 at 16:46:45 (175 occurrences)
Last logged: 08:23:19

Config entry 'Living Room Lights KS220M(US)' for tplink integration not ready yet: Unable to connect to the device: 192.168.1.63:9999: [Errno 104] Connect call failed ('192.168.1.63', 9999); Retrying in background
Config entry 'Master Bedroom 2 KL125(US)' for tplink integration not ready yet: Unable to query the device 192.168.1.33:9999: Connection lost; Retrying in background
Config entry 'Living Room Lights KS220M(US)' for tplink integration not ready yet: Unable to query the device 192.168.1.63:9999: [Errno 104] Connection reset by peer; Retrying in background
Config entry 'Fan HS103(US)' for tplink integration not ready yet: Unable to query the device 192.168.1.96:9999: [Errno 104] Connection reset by peer; Retrying in background
Config entry 'Master Bedroom 2 KL125(US)' for tplink integration not ready yet: Unable to query the device 192.168.1.33:9999: [Errno 104] Connection reset by peer; Retrying in background

Additional information

No response

Kisty commented 1 year ago

Dupe of https://github.com/home-assistant/core/issues/95028?

Out of interest, have you moved recently? I've had the same thing recently and I have changed router as well.

Srkwithlove commented 1 year ago

I did look at #95028 but the error in my logs shows up as Errno104 which is different.

Also, I have deleted and added devices but they just don't come back.

Absolutely no issues controlling via Kasa app, Google Home.

Have not moved or changed the network. Just stopped working since last week.

home-assistant[bot] commented 1 year ago

Hey there @rytilahti, @thegardenmonkey, mind taking a look at this issue as it has been labeled with an integration (tplink) you are listed as a code owner for? Thanks!

Code owner commands Code owners of `tplink` can trigger bot actions by commenting: - `@home-assistant close` Closes the issue. - `@home-assistant rename Awesome new title` Renames the issue. - `@home-assistant reopen` Reopen the issue. - `@home-assistant unassign tplink` Removes the current integration label and assignees on the issue, add the integration domain after the command.

(message by CodeOwnersMention)

tplink documentation tplink source (message by IssueLinks)

bdraco commented 1 year ago

Have you tried rebooting your wifi / router?

SolarSciencePup commented 1 year ago

Same issue here

Home Assistant 2023.9.0b2 Supervisor 2023.08.3 Operating System 10.5 Frontend 20230901.0 - latest

Srkwithlove commented 1 year ago

Rebooted router, rebooted Rpi, tried reinitializing the devices, deleted and redetected the devices (gets added and immediately gives the same error)

On Sat, Sept 2, 2023, 5:07 a.m. Brandon170 @.***> wrote:

Same issue here

— Reply to this email directly, view it on GitHub https://github.com/home-assistant/core/issues/99449#issuecomment-1703772231, or unsubscribe https://github.com/notifications/unsubscribe-auth/AQ6YFJWVV2KG3H6BSUWGDM3XYLZLVANCNFSM6AAAAAA4HQJW4Q . You are receiving this because you authored the thread.Message ID: @.***>

bdraco commented 1 year ago

You'll probably have to capture a tcpdump to get more insight why HA can't connect to your devices

https://opensource.com/article/18/10/introduction-tcpdump

hickey commented 1 year ago

I also am having the same problem. Happened to me yesterday afternoon.

I was probably running HA 2023.5.3 when everything stopped working. We also had a momentary drop in power last night due to thunderstorms and it was noticed after HA had rebooted. Late last night I went ahead and upgraded HA to 2023.9.1 to see if that would fix the issue. It did not.

This instance is running in a Proxmox VM and is running OS 10.5 with Supervisor 2023.08.3.

I seem to remember having something similar to this happen before and ended up statically addressing all the Kasa devices with DHCP reservations. Running OPNSense as a firewall with Unbound for DNS resolution, so I can fully resolve a DNS name inside the house, but my problem seems to be that HA is not resolving the host names correctly.

If delete all the Kasa devices and then attempt to re-add them with the internally resolvable host name, then the TP-Link integration fails to find the device. But if I add the device by IP, then the device is added without a problem.

I seem to remember what I experienced a couple of months ago was that the Kasa devices were setup on dynamic IPs and occasionally they would receive a new IP. What seemed to happen is that when the IP changed, HA would not see that there was a new IP for the host name and the device would become disabled. I know that I waited for several hours to see if the nameserver cache would update (maybe even a day or two), but I never witnessed the nameserver cache being updated with the new IP. Hence why I moved all the Kasa devices to static IPs.

Update: In digging around in the HA VM, I have found that the nameservers have been set to 8.8.8.8, 1.1.1.1, and my internal DNS server (In that order). This would explain why I am having problems resolving internal host names now. I am not certain where the 8.8.8.8 and 1.1.1.1 are coming from. I can not find any nameserver settings in the HA settings and Proxmox is not configured to provide any nameservers. This would indicate that OPNSense is providing them, but all the DNS settings for the various subnets are listing the internal nameservers. So I am puzzled as to how HA is getting these nameservers. Other VMs on the same network segment as HA do not receive the additional nameservers.

Srkwithlove commented 1 year ago

Still no luck with this. Some of the devices came back on their own last week intermittently and now back to none of them working.

In both cases, nothing changed except HA updates being applied to latest versions as applicable.

erixom commented 1 year ago

@rytilahti I am also having this issue, it occurred when I updated Home Assistant and I have been unable to resolve. Any advice?

rytilahti commented 1 year ago

Alas, no. Does it start working again if you downgrade to the latest working version? If not, could it be that there was a firmware update that may have changed something?

There has not been that many changes to this integration for a while, so to me it sounds like something has changed in the network or in the OS. Alas, I don't know about the details of potential relevant changes in the homeassistant OS builds (python version upgrade or something else maybe?), so I cannot really help here.

bdraco commented 1 year ago

The current design requires working UDP responses within 5s since we do discover_single https://github.com/python-kasa/python-kasa/blob/20b3f7a771ccfc6f14c36d6bb17d333fd8657436/kasa/discover.py#L245 to create the device.

I suspect we could significantly improve reliability if we skipped that and connected to the IP via TCP for the device right away.

We could do SmartDevice(host=X), probe the device type, and than recreate the device with the correct type, and move the underlying protocol object to the new device type.

That would get us up and running much faster, wouldn't rely on UDP, and would be less likely to timeout

bdraco commented 1 year ago

Something like https://github.com/python-kasa/python-kasa/pull/528 should do it

bdraco commented 1 year ago

With https://github.com/python-kasa/python-kasa/pull/528 I'm able to break UDP and/or move the device to the edge of wifi range and still connect the devices successfully

sweharris commented 1 year ago

I'm seeing a similar issue, but I don't know if it's the same. I recently updated my docker container from 2023.10 to 2023.11.2 and now the Kasa integration broke. The devices are in "Failed setup, will retry" state.

I can see, in the debug logs, that get_sysinfo is being successful (I've masked some data)

023-11-12 10:31:45.877 DEBUG (MainThread) [kasa.discover] [DISCOVERY] ('tpplug1.spuddy.org', 9999) >> {'system': {'get_sysinfo': None}}
2023-11-12 10:31:45.883 DEBUG (MainThread) [kasa.discover] Waiting a total of 10 seconds for responses...
2023-11-12 10:31:45.886 DEBUG (MainThread) [kasa.discover] [DISCOVERY] 10.100.200.10 << {'system': {'get_sysinfo': {'sw_ver': '1.5.6 Build 191114 Rel.104204', 'hw_ver': '1.0', 'type': 'IOT.SMARTPLUGSWITCH', 'model': 'HS105(US)', 'mac': 'XXXX', 'dev_name': 'Smart Wi-Fi Plug Mini', 'alias': 'Office Light', 'relay_state': 0, 'on_time': 0, 'active_mode': 'none', 'feature': 'TIM', 'updating': 0, 'icon_hash': '', 'rssi': -37, 'led_off': 0, 'longitude_i': XXXXXX, 'latitude_i': XXXXX, 'hwId': 'XXXX', 'fwId': '00000000000000000000000000000000', 'deviceId': 'XXXX', 'oemId': 'XXX', 'next_action': {'type': -1}, 'err_code': 0}}}
2023-11-12 10:31:45.886 DEBUG (MainThread) [kasa.smartdevice] Initializing 10.100.200.10 of type <class 'kasa.smartplug.SmartPlug'>
2023-11-12 10:31:45.887 DEBUG (MainThread) [kasa.smartdevice] Adding module <Module Schedule (schedule) for 10.100.200.10>
2023-11-12 10:31:45.887 DEBUG (MainThread) [kasa.smartdevice] Adding module <Module Usage (schedule) for 10.100.200.10>
2023-11-12 10:31:45.888 DEBUG (MainThread) [kasa.smartdevice] Adding module <Module Antitheft (anti_theft) for 10.100.200.10>
2023-11-12 10:31:45.888 DEBUG (MainThread) [kasa.smartdevice] Adding module <Module Time (time) for 10.100.200.10>
2023-11-12 10:31:45.889 DEBUG (MainThread) [kasa.smartdevice] Adding module <Module Cloud (cnCloud) for 10.100.200.10>

I can also see UDP traffic being successful:

12:10:10.132824 IP hass.spuddy.org.36424 > tpplug1.spuddy.org.distinct: UDP, length 31
12:10:10.136609 IP hass.spuddy.org.36424 > tpplug1.spuddy.org.commtact-http: UDP, length 16
12:10:10.137874 IP hass.spuddy.org.36424 > tpplug1.spuddy.org.distinct: UDP, length 31
12:10:10.139021 IP hass.spuddy.org.36424 > tpplug1.spuddy.org.commtact-http: UDP, length 16
12:10:10.142032 IP hass.spuddy.org.36424 > tpplug1.spuddy.org.distinct: UDP, length 31
12:10:10.143133 IP hass.spuddy.org.36424 > tpplug1.spuddy.org.commtact-http: UDP, length 16
12:10:10.156699 IP tpplug1.spuddy.org.distinct > hass.spuddy.org.36424: UDP, length 595
12:10:10.156906 IP tpplug1.spuddy.org.distinct > hass.spuddy.org.36424: UDP, length 595
12:10:10.157277 IP tpplug1.spuddy.org.distinct > hass.spuddy.org.36424: UDP, length 595

(yeah, the timestamps are different 'cos I captured them at different times).

So I'm not sure if I'm seeing the same problem or if this is new.

JackBeQuick87 commented 1 year ago

I'm seeing a similar issue, but I don't know if it's the same. I recently updated my docker container from 2023.10 to 2023.11.2 and now the Kasa integration broke. The devices are in "Failed setup, will retry" state.

I can see, in the debug logs, that get_sysinfo is being successful (I've masked some data)

023-11-12 10:31:45.877 DEBUG (MainThread) [kasa.discover] [DISCOVERY] ('tpplug1.spuddy.org', 9999) >> {'system': {'get_sysinfo': None}}
2023-11-12 10:31:45.883 DEBUG (MainThread) [kasa.discover] Waiting a total of 10 seconds for responses...
2023-11-12 10:31:45.886 DEBUG (MainThread) [kasa.discover] [DISCOVERY] 10.100.200.10 << {'system': {'get_sysinfo': {'sw_ver': '1.5.6 Build 191114 Rel.104204', 'hw_ver': '1.0', 'type': 'IOT.SMARTPLUGSWITCH', 'model': 'HS105(US)', 'mac': 'XXXX', 'dev_name': 'Smart Wi-Fi Plug Mini', 'alias': 'Office Light', 'relay_state': 0, 'on_time': 0, 'active_mode': 'none', 'feature': 'TIM', 'updating': 0, 'icon_hash': '', 'rssi': -37, 'led_off': 0, 'longitude_i': XXXXXX, 'latitude_i': XXXXX, 'hwId': 'XXXX', 'fwId': '00000000000000000000000000000000', 'deviceId': 'XXXX', 'oemId': 'XXX', 'next_action': {'type': -1}, 'err_code': 0}}}
2023-11-12 10:31:45.886 DEBUG (MainThread) [kasa.smartdevice] Initializing 10.100.200.10 of type <class 'kasa.smartplug.SmartPlug'>
2023-11-12 10:31:45.887 DEBUG (MainThread) [kasa.smartdevice] Adding module <Module Schedule (schedule) for 10.100.200.10>
2023-11-12 10:31:45.887 DEBUG (MainThread) [kasa.smartdevice] Adding module <Module Usage (schedule) for 10.100.200.10>
2023-11-12 10:31:45.888 DEBUG (MainThread) [kasa.smartdevice] Adding module <Module Antitheft (anti_theft) for 10.100.200.10>
2023-11-12 10:31:45.888 DEBUG (MainThread) [kasa.smartdevice] Adding module <Module Time (time) for 10.100.200.10>
2023-11-12 10:31:45.889 DEBUG (MainThread) [kasa.smartdevice] Adding module <Module Cloud (cnCloud) for 10.100.200.10>

I can also see UDP traffic being successful:

12:10:10.132824 IP hass.spuddy.org.36424 > tpplug1.spuddy.org.distinct: UDP, length 31
12:10:10.136609 IP hass.spuddy.org.36424 > tpplug1.spuddy.org.commtact-http: UDP, length 16
12:10:10.137874 IP hass.spuddy.org.36424 > tpplug1.spuddy.org.distinct: UDP, length 31
12:10:10.139021 IP hass.spuddy.org.36424 > tpplug1.spuddy.org.commtact-http: UDP, length 16
12:10:10.142032 IP hass.spuddy.org.36424 > tpplug1.spuddy.org.distinct: UDP, length 31
12:10:10.143133 IP hass.spuddy.org.36424 > tpplug1.spuddy.org.commtact-http: UDP, length 16
12:10:10.156699 IP tpplug1.spuddy.org.distinct > hass.spuddy.org.36424: UDP, length 595
12:10:10.156906 IP tpplug1.spuddy.org.distinct > hass.spuddy.org.36424: UDP, length 595
12:10:10.157277 IP tpplug1.spuddy.org.distinct > hass.spuddy.org.36424: UDP, length 595

(yeah, the timestamps are different 'cos I captured them at different times).

So I'm not sure if I'm seeing the same problem or if this is new.

I have the same problem as you (@sweharris), but I believe the issue is different from this issue's OP. I have created a new issue for this: #103977

seancrites commented 11 months ago

@hickey - You don't mention what exactly you're using OPNSense to firewall against, ie, just WAN vs. LAN or if you are using subnets/vlans and firewalling between them too.

If you are firewalling between your HA & IOT networks, verify you're allowing UDP 9999 & 20002 to go from your HA to your IOT network, specifically your TP-LINKs. I roughly had the same issue as @sweharris referenced in #103977 and I believe updating their firewall may fix the problem.

hickey commented 11 months ago

@seancrites The OPNSense firewall has the incoming internet connection on one port and a second port that has a number of VLANs running over it. One of those VLANs is the automation network with all the switches, sensors and other smart devices on it. HA is a VM running on a Proxmox server and has two interfaces: one on the automation VLAN and the other on the media VLAN (to discover and connect to TVs, stereos, etc.).

So HA has always had direct access to the TP-LINK devices. The problem I found a while back about the time I posted my comment was that the TP-LINK devices were dynamically assigned IPs. Probably after a power outage is when I started having problems connecting to the devices and I think that I found that HA was trying to connect to the old IPs. Whether the IPs were cached or I used the IPs in HA to initially connect to the devices I can not say (fair chance the latter), but once they came up on new IPs HA would not find them. I ended up assigning DHCP reservations for all the devices so that they would keep the same address. This seems to have solved the problem for me. At least so far.

sdb9696 commented 9 months ago

This should be fixed in the latest HA release 2024.02

sdb9696 commented 9 months ago

@home-assistant close