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
74.17k stars 31.14k forks source link

TPLink Devices "cant connect" for a while after reboot of HA #128500

Open harmgsn opened 1 month ago

harmgsn commented 1 month ago

The problem

When HAOS is updated/rebooted most of the devices will fail to setup for a good 10-15min. They will eventually come back online, but for whatever reason 90% of them fail for a while. Out of the 19 devices, it's been a good 15min since HAOS rebooted and 2 of them are still failing. It claims it's "Unable to connect to the device". Device has been up the entire time and I've been able to access it directly outside of HAOS w/python the entire time. They come back online in "batches" - 3-4 at a time and every 2-3min another "batch" will start working.

What version of Home Assistant Core has the issue?

2024.10.2

What was the last working version of Home Assistant Core?

No response

What type of installation are you running?

Home Assistant OS

Integration causing the issue

TPLink

Link to integration documentation on our website

https://www.home-assistant.io/integrations/tplink

Diagnostics information

home-assistant_tplink_2024-10-16T02-47-42.350Z.log

Example YAML snippet

No response

Anything in the logs that might be useful for us?

No response

Additional information

No response

home-assistant[bot] commented 1 month ago

Hey there @rytilahti, @bdraco, @sdb9696, 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. - `@home-assistant add-label needs-more-information` Add a label (needs-more-information, problem in dependency, problem in custom component) to the issue. - `@home-assistant remove-label needs-more-information` Remove a label (needs-more-information, problem in dependency, problem in custom component) on the issue.

(message by CodeOwnersMention)

tplink documentation tplink source (message by IssueLinks)

Comodore125 commented 1 month ago

Is anyone working on these problems? I just did start with these integration and these tp link devices and I already got them unresponsive for 10 hours out of 20. Quite bad, everything else is fine honestly but tp link is badly broken.

Comodore125 commented 1 month ago

I am sending summary of the problematic logs I encountered today: Home Assistant Error Setting Up TP-Link Devices (First Log):

Home Assistant encountered errors when trying to set up the Chytrý hub KH100 and P110 plug. The logs show that an asyncio.exceptions.CancelledError occurred, which suggests a task related to device connection was canceled, possibly due to network issues or device unresponsiveness.

TP-Link Device Timeout (Second Log):

Home Assistant was unable to query a device at IP 10.106.0.147. Multiple queries (such as cloud state, device info, usage, etc.) resulted in timeouts, indicating that the device failed to respond to requests within a specified time. This could be due to network connectivity issues or the device being unreachable.

TP-Link Plug Data Retrieval Failure (Third Log):

Home Assistant failed to retrieve specific data (such as energy usage and auto-off configuration) from the P110 plug at IP 10.106.0.128**. The errors (INTERNAL_QUERY_ERROR`) suggest that the plug is not responding correctly to Home Assistant's requests, which could be caused by firmware, network, or configuration problems. - I could also provide raw logs if neccessary
rytilahti commented 1 month ago

To be honest, such issues usually hint towards general network problems. There are many people with lots of devices who are using these without many issues. Some devices (mostly tapo-branded) are known to have watchdog timers that reboot them if they are unable to connect to the cloud services, causing fluctuations in their availability and controllability.

There is no separate throttling within the homeassistant integration that should be causing devices becoming available in batches, not that I know of at least.

Comodore125 commented 1 month ago

I did zero changes of my network config. Devices were perfectly reachable via TP LINK applications. strangely tapo and kasa did not work in the same time frame. as one started to work the other worked too. I got them connected to different Wi-Fi APs but managed by single controller inside a VLAN but with open ports (any port) from HA towards these two devices. I did also investigate and both devices have perfect -53 dbm signal. there are also different APs to connect to if one dies. (deleted irrelevant info)

sdb9696 commented 1 month ago

@harmgsn I've looked through your log but I don't see any errors in it. Can you upload some logs that capture when the devices are actually failing?

harmgsn commented 1 month ago

To be honest, such issues usually hint towards general network problems. There are many people with lots of devices who are using these without many issues. Some devices (mostly tapo-branded) are known to have watchdog timers that reboot them if they are unable to connect to the cloud services, causing fluctuations in their availability and controllability.

There is no separate throttling within the homeassistant integration that should be causing devices becoming available in batches, not that I know of at least.

Yeah, no. It's not a "General Network Problem". I'm not saying the devices randomly drop offline. They are up and stay online so long as I don't reboot HAOS. When I do, some of the devices can initialize - the rest will fail for a period of time and then start working.

I have a python script that is able to communicate with the device just fine while they're failing to initalize.

@sdb9696 Those logs are from me enabling debug and hitting "reload" in the integration for that device. I stop debug logging when it returns to a "Failed to setup" on the device.

harmgsn commented 1 month ago

2024-10-18 16:34:07.121 DEBUG (MainThread) [kasa.iotprotocol] 192.168.2.189 >> {"system":{"get_sysinfo":{}}} 2024-10-18 16:34:12.122 DEBUG (MainThread) [kasa.iotprotocol] 192.168.2.189 >> {"system":{"get_sysinfo":{}}} 2024-10-18 16:34:17.124 DEBUG (MainThread) [kasa.iotprotocol] 192.168.2.189 >> {"system":{"get_sysinfo":{}}} 2024-10-18 16:34:22.124 DEBUG (MainThread) [kasa.iotprotocol] 192.168.2.189 >> {"system":{"get_sysinfo":{}}} 2024-10-18 16:34:27.126 DEBUG (MainThread) [kasa.iotprotocol] Giving up on 192.168.2.189 after 3 retries 2024-10-18 16:34:27.127 DEBUG (MainThread) [kasa.iotprotocol] 192.168.2.189 >> {"system":{"get_sysinfo":{}}} 2024-10-18 16:34:32.128 DEBUG (MainThread) [kasa.iotprotocol] 192.168.2.189 >> {"system":{"get_sysinfo":{}}} 2024-10-18 16:34:37.129 DEBUG (MainThread) [kasa.iotprotocol] 192.168.2.189 >> {"system":{"get_sysinfo":{}}} 2024-10-18 16:34:42.130 DEBUG (MainThread) [kasa.iotprotocol] 192.168.2.189 >> {"system":{"get_sysinfo":{}}} 2024-10-18 16:34:47.132 DEBUG (MainThread) [kasa.iotprotocol] Giving up on 192.168.2.189 after 3 retries 2024-10-18 16:34:47.132 DEBUG (MainThread) [kasa.iotprotocol] 192.168.2.189 >> {"system":{"get_sysinfo":{}}} 2024-10-18 16:34:52.133 DEBUG (MainThread) [kasa.iotprotocol] 192.168.2.189 >> {"system":{"get_sysinfo":{}}} 2024-10-18 16:34:57.134 DEBUG (MainThread) [kasa.iotprotocol] 192.168.2.189 >> {"system":{"get_sysinfo":{}}} 2024-10-18 16:35:02.135 DEBUG (MainThread) [kasa.iotprotocol] 192.168.2.189 >> {"system":{"get_sysinfo":{}}} 2024-10-18 16:35:07.138 DEBUG (MainThread) [kasa.iotprotocol] Giving up on 192.168.2.189 after 3 retries 2024-10-18 16:35:07.138 DEBUG (MainThread) [kasa.iotprotocol] 192.168.2.189 >> {"system":{"get_sysinfo":{}}}

There's the "failure" for it talking to a specific light switch.

Comodore125 commented 1 month ago

I would love to see this fixed? How can I help? I noticed that after last restart these still did not go back up.

Comodore125 commented 1 month ago

So, I deleted all tp link smart home devices. and next day I was again able to connect it back. My idea is that there is some serious bug in reconnecting. It does start getting time outs and then the device refuses to get joined into home assistant. This has to be handled in better way and requires more clever code to handle this and allow for safe reconnection without triggering some kind of block.

Also I noticed this PR might help https://github.com/home-assistant/core/pull/128994/commits/73d94be1fdd071f625a466c4735fd68a48d0ba45 #128994

I hope the PR will get into the HA soon.

If it will not help I am planning to look into this myself and at least get tcpdump in the IOT network to catch how the network traffic looks when it fails to reconnect. I am already thinking about how I would go about the new PR. But I dont even know how testing is handled, would probably need to install some testing version of HA to my last free RPI4

rytilahti commented 1 month ago

@harmgsn when you encounter this again, could you please try to use the kasa tool from python-kasa to see if you can communicate with the device using that? If you install uv (instructions), you can use a command like uvx --from python-kasa kasa --host 192.168.2.189 which will report you the device state.

@Comodore125 I added a link to the PR. So what that PR aims to fix is instances where UDP communications for discovery are restricted. This should the issue of the initial discovery of the connection parameters, but that might not be related to the issues you are having considering your devices are discoverable?

You could try if you can still communicate using the cli tool, because if not, then the problem is not just in the integration. To verify if the discovery is working, you can use the following command, but not that the system you run the command must be in the same network (broadcast domain): uvx --from python-kasa kasa --target 192.168.3.255 .

Note that you can also pass --debug (i.e., kasa --debug --host <foobar>) to get more information what is being sent and received.

sdb9696 commented 1 month ago

It could be helpful to try to get the kasa cli command tool running from the python-kasa package and try connecting via that tool to compare output. Also running the tool on a different machine to HA (it works on windows)

Comodore125 commented 1 month ago

My integration is back online after I removed it before and give it more than 12 hours. then it got added on first try. But I will be doing restarts of HA if I need to restart synology server its hosted in container manager inside or when there is new major release of HA. Then I will try to look into more tools to identify problem. Thanks for explanation that the PR is actualy not relevant as I dont have issue with UDP...

Comodore125 commented 3 weeks ago

I want to say that I juts did reboot my HA and upgraded to latest in container. This time I got no problem with TP link integration. I also added KE100 in the meantime. I simply got problems on L2 of the network - I had to add more unique mac adresses for different VLAN interfaces in the router settings. Otherwise ARP and possibly other protocol got broken, possibly also lead to sort of congestion which caused 5 second timeout being missed. Also had couple of weeks without issues. Hope I am totaly right and none of this issue will repeat. EDIT: Seems to be down again. Will investigate further.

Comodore125 commented 2 weeks ago

So I managed to get it working again - simply gave it couple of days and then reinitialized. Also I now installed the kasa command and everything was ok (after I did add username and password before that I got stacktrace) Now I am killing the home assistant container for longer time in order to recreate the bug. Lets see EDIT: So gave it low tens of minutes of downtime. It got back up fast without issue in home assistant. I did open two way communication unlike before when I opened just tp link > HA. now it is opened in firewall in both ways. It remains to be seen if there will not be any issue in the future. There might still be bug somwehere. At least I am fully ready to test it with kasa module as soon as it happens.

Comodore125 commented 2 weeks ago

I also killed the VLAN where the tplink resides from accessing internet. it took couple hours before the TCP IP comms died, then I caused one issue in FW config but nevertheless it still works via HA as it should so I am happy. Not accessible from the kasa app as it seems either rely on discovery or cloud access. So in conclusion everything is as expected. I might allow for discovery, but this is safer.

Comodore125 commented 1 week ago

This time I am getting closer to the root of the problem. I did update on my router - which went down for just tens of seconds and the automation for TP LINK broke - logs from HA: "Logger: kasa.smart.smartdevice Zdroj: components/tplink/coordinator.py:49 První výskyt: 18. listopadu 2024 v 03:27:52 (6617 výskyty) Naposledy logováno: 17:07:11

Error querying 10.106.0.128 individually for module query 'get_current_power' after first update: ('Unable to query the device, timed out: 10.106.0.128: ', TimeoutError())
Error querying 10.106.0.128 individually for module query 'get_led_info' after first update: ('Unable to query the device, timed out: 10.106.0.128: ', TimeoutError())
Error querying 10.106.0.147 individually for module query 'get_led_info' after first update: ('Unable to query the device, timed out: 10.106.0.147: ', TimeoutError())
Error querying 10.106.0.147 individually for module query 'get_device_time' after first update: ('Unable to query the device, timed out: 10.106.0.147: ', TimeoutError())
Error querying 10.106.0.128 individually for module query 'get_device_time' after first update: ('Unable to query the device, timed out: 10.106.0.128: ', TimeoutError())

" I have to say that using kasa --host 10.106.0.147 --username "REDACTED...." is working instantly and 100% as expected. there has to be bug in the HA side or more specificaly in the integration. How can I help further? For some reason something breaks on the side of HA

Comodore125 commented 1 week ago

I noticed that there were logs from kasa in HA no more. Changed HA yaml to log more. Now I got this after removing the integration and trying to add it again Meanwhile it still works totaly fine with python-kasa module. 

date | stream | content
-- | -- | --
2024/11/20 20:11:26 | stdout | 2024-11-20 20:11:26.731 DEBUG (MainThread) [kasa.discover] Unable to connect with <kasa.iotprotocol.IotProtocol object at 0x7f110a8ae270>
2024/11/20 20:11:26 | stdout | 2024-11-20 20:11:26.731 DEBUG (MainThread) [kasa.iotprotocol] Giving up on 10.106.0.128 after 3 retries
2024/11/20 20:11:21 | stdout | 2024-11-20 20:11:21.730 DEBUG (MainThread) [kasa.iotprotocol] 10.106.0.128 >> {"system":{"get_sysinfo":{}}}
2024/11/20 20:11:16 | stdout | 2024-11-20 20:11:16.729 DEBUG (MainThread) [kasa.iotprotocol] 10.106.0.128 >> {"system":{"get_sysinfo":{}}}
2024/11/20 20:11:11 | stdout | 2024-11-20 20:11:11.728 DEBUG (MainThread) [kasa.iotprotocol] 10.106.0.128 >> {"system":{"get_sysinfo":{}}}
2024/11/20 20:11:06 | stdout | 2024-11-20 20:11:06.726 DEBUG (MainThread) [kasa.iotprotocol] 10.106.0.128 >> {"system":{"get_sysinfo":{}}}
2024/11/20 20:11:06 | stdout | 2024-11-20 20:11:06.726 DEBUG (MainThread) [kasa.discover] Unable to connect with <kasa.smartprotocol.SmartProtocol object at 0x7f110eb4e300>
2024/11/20 20:11:06 | stdout | 2024-11-20 20:11:06.726 DEBUG (MainThread) [kasa.smartprotocol] Giving up on 10.106.0.128 after 3 retries
2024/11/20 20:11:00 | stdout | 2024-11-20 20:11:00.727 DEBUG (MainThread) [kasa.httpclient] Posting to http://10.106.0.128/app
2024/11/20 20:11:00 | stdout | 2024-11-20 20:11:00.727 DEBUG (MainThread) [kasa.aestransport] Will perform handshaking...
2024/11/20 20:11:00 | stdout | 2024-11-20 20:11:00.727 DEBUG (MainThread) [kasa.smartprotocol] 10.106.0.128 multi-request-batch-1-of-1 >> '{"method":"multipleRequest","request_time_milis":1732129860727,"terminal_uuid":"+RQeHa9kqSzr2gDM07x0ag==","params":{"requests":[{"method":"component_nego"},{"method":"get_device_info"},{"method":"get_connect_cloud_state"}]}}'
2024/11/20 20:10:53 | stdout | 2024-11-20 20:10:53.728 DEBUG (MainThread) [kasa.httpclient] Posting to http://10.106.0.128/app
2024/11/20 20:10:53 | stdout | 2024-11-20 20:10:53.728 DEBUG (MainThread) [kasa.aestransport] Will perform handshaking...
2024/11/20 20:10:53 | stdout | 2024-11-20 20:10:53.728 DEBUG (MainThread) [kasa.smartprotocol] 10.106.0.128 multi-request-batch-1-of-1 >> '{"method":"multipleRequest","request_time_milis":1732129853728,"terminal_uuid":"+RQeHa9kqSzr2gDM07x0ag==","params":{"requests":[{"method":"component_nego"},{"method":"get_device_info"},{"method":"get_connect_cloud_state"}]}}'
2024/11/20 20:10:46 | stdout | 2024-11-20 20:10:46.728 DEBUG (MainThread) [kasa.httpclient] Posting to http://10.106.0.128/app
2024/11/20 20:10:46 | stdout | 2024-11-20 20:10:46.728 DEBUG (MainThread) [kasa.aestransport] Will perform handshaking...
2024/11/20 20:10:46 | stdout | 2024-11-20 20:10:46.727 DEBUG (MainThread) [kasa.smartprotocol] 10.106.0.128 multi-request-batch-1-of-1 >> '{"method":"multipleRequest","request_time_milis":1732129846728,"terminal_uuid":"+RQeHa9kqSzr2gDM07x0ag==","params":{"requests":[{"method":"component_nego"},{"method":"get_device_info"},{"method":"get_connect_cloud_state"}]}}'
2024/11/20 20:10:45 | stdout | 2024-11-20 20:10:45.726 DEBUG (MainThread) [kasa.smartprotocol] Device 10.106.0.128 got a timeout error, will retry 3 times: ('Unable to query the device, timed out: 10.106.0.128: ', TimeoutError())
2024/11/20 20:10:39 | stdout | 2024-11-20 20:10:39.728 DEBUG (MainThread) [kasa.httpclient] Posting to http://10.106.0.128/app
2024/11/20 20:10:39 | stdout | 2024-11-20 20:10:39.728 DEBUG (MainThread) [kasa.aestransport] Will perform handshaking...
2024/11/20 20:10:39 | stdout | 2024-11-20 20:10:39.728 DEBUG (MainThread) [kasa.smartprotocol] 10.106.0.128 multi-request-batch-1-of-1 >> '{"method":"multipleRequest","request_time_milis":1732129839728,"terminal_uuid":"+RQeHa9kqSzr2gDM07x0ag==","params":{"requests":[{"method":"component_nego"},{"method":"get_device_info"},{"method":"get_connect_cloud_state"}]}}'
2024/11/20 20:10:39 | stdout | 2024-11-20 20:10:39.728 DEBUG (MainThread) [kasa.device] Initializing 10.106.0.128 of type <class 'kasa.smart.smartdevice.SmartDevice'>
2024/11/20 20:10:39 | stdout | 2024-11-20 20:10:39.727 DEBUG (MainThread) [kasa.discover] Unable to connect with <kasa.smartprotocol.SmartProtocol object at 0x7f11132744a0>
2024/11/20 20:10:39 | stdout | 2024-11-20 20:10:39.727 DEBUG (MainThread) [kasa.smartprotocol] Giving up on 10.106.0.128 after 3 retries
2024/11/20 20:10:33 | stdout | 2024-11-20 20:10:33.728 DEBUG (MainThread) [kasa.httpclient] Posting to http://10.106.0.128/app/handshake1
2024/11/20 20:10:33 | stdout | 2024-11-20 20:10:33.728 DEBUG (MainThread) [kasa.klaptransport] Starting handshake with 10.106.0.128
2024/11/20 20:10:33 | stdout | 2024-11-20 20:10:33.728 DEBUG (MainThread) [kasa.smartprotocol] 10.106.0.128 multi-request-batch-1-of-1 >> '{"method":"multipleRequest","request_time_milis":1732129833728,"terminal_uuid":"dGya7obX1YU9KzHIRtvwNw==","params":{"requests":[{"method":"component_nego"},{"method":"get_device_info"},{"method":"get_connect_cloud_state"}]}}'
2024/11/20 20:10:26 | stdout | 2024-11-20 20:10:26.727 DEBUG (MainThread) [kasa.httpclient] Posting to http://10.106.0.128/app/handshake1
2024/11/20 20:10:26 | stdout | 2024-11-20 20:10:26.727 DEBUG (MainThread) [kasa.klaptransport] Starting handshake with 10.106.0.128
2024/11/20 20:10:26 | stdout | 2024-11-20 20:10:26.727 DEBUG (MainThread) [kasa.smartprotocol] 10.106.0.128 multi-request-batch-1-of-1 >> '{"method":"multipleRequest","request_time_milis":1732129826727,"terminal_uuid":"dGya7obX1YU9KzHIRtvwNw==","params":{"requests":[{"method":"component_nego"},{"method":"get_device_info"},{"method":"get_connect_cloud_state"}]}}'
2024/11/20 20:10:19 | stdout | 2024-11-20 20:10:19.727 DEBUG (MainThread) [kasa.httpclient] Posting to http://10.106.0.128/app/handshake1
2024/11/20 20:10:19 | stdout | 2024-11-20 20:10:19.727 DEBUG (MainThread) [kasa.klaptransport] Starting handshake with 10.106.0.128
2024/11/20 20:10:19 | stdout | 2024-11-20 20:10:19.727 DEBUG (MainThread) [kasa.smartprotocol] 10.106.0.128 multi-request-batch-1-of-1 >> '{"method":"multipleRequest","request_time_milis":1732129819727,"terminal_uuid":"dGya7obX1YU9KzHIRtvwNw==","params":{"requests":[{"method":"component_nego"},{"method":"get_device_info"},{"method":"get_connect_cloud_state"}]}}'
2024/11/20 20:10:18 | stdout | 2024-11-20 20:10:18.726 DEBUG (MainThread) [kasa.smartprotocol] Device 10.106.0.128 got a timeout error, will retry 3 times: ('Unable to query the device, timed out: 10.106.0.128: ', TimeoutError())
2024/11/20 20:10:12 | stdout | 2024-11-20 20:10:12.728 DEBUG (MainThread) [kasa.httpclient] Posting to http://10.106.0.128/app/handshake1
2024/11/20 20:10:12 | stdout | 2024-11-20 20:10:12.728 DEBUG (MainThread) [kasa.klaptransport] Starting handshake with 10.106.0.128
2024/11/20 20:10:12 | stdout | 2024-11-20 20:10:12.728 DEBUG (MainThread) [kasa.smartprotocol] 10.106.0.128 multi-request-batch-1-of-1 >> '{"method":"multipleRequest","request_time_milis":1732129812728,"terminal_uuid":"dGya7obX1YU9KzHIRtvwNw==","params":{"requests":[{"method":"component_nego"},{"method":"get_device_info"},{"method":"get_connect_cloud_state"}]}}'
2024/11/20 20:10:12 | stdout | 2024-11-20 20:10:12.727 DEBUG (MainThread) [kasa.device] Initializing 10.106.0.128 of type <class 'kasa.smart.smartdevice.SmartDevice'>
2024/11/20 20:10:12 | stdout | 2024-11-20 20:10:12.727 DEBUG (MainThread) [kasa.discover] Unable to connect with <kasa.iotprotocol.IotProtocol object at 0x7f11133f3f20>
2024/11/20 20:10:12 | stdout | 2024-11-20 20:10:12.726 DEBUG (MainThread) [kasa.iotprotocol] Giving up on 10.106.0.128 after 3 retries
2024/11/20 20:10:06 | stdout | 2024-11-20 20:10:06.727 DEBUG (MainThread) [kasa.httpclient] Posting to http://10.106.0.128/app/handshake1
2024/11/20 20:10:06 | stdout | 2024-11-20 20:10:06.727 DEBUG (MainThread) [kasa.klaptransport] Starting handshake with 10.106.0.128
2024/11/20 20:10:06 | stdout | 2024-11-20 20:10:06.727 DEBUG (MainThread) [kasa.iotprotocol] 10.106.0.128 >> {"system":{"get_sysinfo":{}}}
2024/11/20 20:09:59 | stdout | 2024-11-20 20:09:59.727 DEBUG (MainThread) [kasa.httpclient] Posting to http://10.106.0.128/app/handshake1
2024/11/20 20:09:59 | stdout | 2024-11-20 20:09:59.727 DEBUG (MainThread) [kasa.klaptransport] Starting handshake with 10.106.0.128
2024/11/20 20:09:59 | stdout | 2024-11-20 20:09:59.727 DEBUG (MainThread) [kasa.iotprotocol] 10.106.0.128 >> {"system":{"get_sysinfo":{}}}
2024/11/20 20:09:52 | stdout | 2024-11-20 20:09:52.727 DEBUG (MainThread) [kasa.httpclient] Posting to http://10.106.0.128/app/handshake1
2024/11/20 20:09:52 | stdout | 2024-11-20 20:09:52.726 DEBUG (MainThread) [kasa.klaptransport] Starting handshake with 10.106.0.128
2024/11/20 20:09:52 | stdout | 2024-11-20 20:09:52.726 DEBUG (MainThread) [kasa.iotprotocol] 10.106.0.128 >> {"system":{"get_sysinfo":{}}}
2024/11/20 20:09:45 | stdout | 2024-11-20 20:09:45.851 DEBUG (MainThread) [kasa.httpclient] Posting to http://10.106.0.128/app/handshake1
2024/11/20 20:09:45 | stdout | 2024-11-20 20:09:45.851 DEBUG (MainThread) [kasa.klaptransport] Starting handshake with 10.106.0.128
2024/11/20 20:09:45 | stdout | 2024-11-20 20:09:45.851 DEBUG (MainThread) [kasa.iotprotocol] 10.106.0.128 >> {"system":{"get_sysinfo":{}}}
2024/11/20 20:09:45 | stdout | 2024-11-20 20:09:45.851 DEBUG (MainThread) [kasa.iot.iotdevice] Performing the initial update to obtain sysinfo
2024/11/20 20:09:45 | stdout | 2024-11-20 20:09:45.851 DEBUG (MainThread) [kasa.device] Initializing 10.106.0.128 of type <class 'kasa.iot.iotplug.IotPlug'>
2024/11/20 20:09:45 | stdout | 2024-11-20 20:09:45.850 DEBUG (MainThread) [kasa.aestransport] Created AES transport for 10.106.0.128
2024/11/20 20:09:45 | stdout | 2024-11-20 20:09:45.850 DEBUG (MainThread) [kasa.klaptransport] Created KLAP transport for 10.106.0.128
2024/11/20 20:09:45 | stdout | 2024-11-20 20:09:45.850 DEBUG (MainThread) [kasa.klaptransport] Created KLAP transport for 10.106.0.128
2024/11/20 20:09:40 | stdout | 2024-11-20 20:09:40.400 DEBUG (MainThread) [kasa.iotprotocol] Giving up on 10.106.0.128 after 3 retries
2024/11/20 20:09:35 | stdout | 2024-11-20 20:09:35.399 DEBUG (MainThread) [kasa.iotprotocol] 10.106.0.128 >> {"system":{"get_sysinfo":{}}}
2024/11/20 20:09:30 | stdout | 2024-11-20 20:09:30.397 DEBUG (MainThread) [kasa.iotprotocol] 10.106.0.128 >> {"system":{"get_sysinfo":{}}}
2024/11/20 20:09:25 | stdout | 2024-11-20 20:09:25.396 DEBUG (MainThread) [kasa.iotprotocol] 10.106.0.128 >> {"system":{"get_sysinfo":{}}}
2024/11/20 20:09:20 | stdout | 2024-11-20 20:09:20.395 DEBUG (MainThread) [kasa.iotprotocol] 10.106.0.128 >> {"system":{"get_sysinfo":{}}}
2024/11/20 20:09:15 | stdout | 2024-11-20 20:09:15.392 DEBUG (MainThread) [kasa.discover] Waiting a total of 5 seconds for responses...
2024/11/20 20:09:15 | stdout | 2024-11-20 20:09:15.341 DEBUG (MainThread) [kasa.discover] [DISCOVERY] 10.106.0.128 >> {'system': {'get_sysinfo': {}}}
2024/11/20 20:08:27 | stdout | 2024-11-20 20:08:27.718 DEBUG (ImportExecutor_0) [kasa.smart.smartmodule] Registering <class 'kasa.experimental.modules.time.Time'>
2024/11/20 20:08:27 | stdout | 2024-11-20 20:08:27.717 DEBUG (ImportExecutor_0) [kasa.smart.smartmodule] Registering <class 'kasa.experimental.modules.device.DeviceModule'>
2024/11/20 20:08:27 | stdout | 2024-11-20 20:08:27.716 DEBUG (ImportExecutor_0) [kasa.smart.smartmodule] Registering <class 'kasa.experimental.modules.childdevice.ChildDevice'>
2024/11/20 20:08:27 | stdout | 2024-11-20 20:08:27.715 DEBUG (ImportExecutor_0) [kasa.smart.smartmodule] Registering <class 'kasa.experimental.modules.camera.Camera'>
2024/11/20 20:08:27 | stdout | 2024-11-20 20:08:27.698 DEBUG (ImportExecutor_0) [kasa.smart.smartmodule] Registering <class 'kasa.smart.modules.waterleaksensor.WaterleakSensor'>
2024/11/20 20:08:27 | stdout | 2024-11-20 20:08:27.697 DEBUG (ImportExecutor_0) [kasa.smart.smartmodule] Registering <class 'kasa.smart.modules.triggerlogs.TriggerLogs'>
2024/11/20 20:08:27 | stdout | 2024-11-20 20:08:27.696 DEBUG (ImportExecutor_0) [kasa.smart.smartmodule] Registering <class 'kasa.smart.modules.time.Time'>
2024/11/20 20:08:27 | stdout | 2024-11-20 20:08:27.694 DEBUG (ImportExecutor_0) [kasa.smart.smartmodule] Registering <class 'kasa.smart.modules.temperaturesensor.TemperatureSensor'>
2024/11/20 20:08:27 | stdout | 2024-11-20 20:08:27.694 DEBUG (ImportExecutor_0) [kasa.smart.smartmodule] Registering <class 'kasa.smart.modules.temperaturecontrol.TemperatureControl'>
2024/11/20 20:08:27 | stdout | 2024-11-20 20:08:27.693 DEBUG (ImportExecutor_0) [kasa.smart.smartmodule] Registering <class 'kasa.smart.modules.reportmode.ReportMode'>
2024/11/20 20:08:27 | stdout | 2024-11-20 20:08:27.693 DEBUG (ImportExecutor_0) [kasa.smart.smartmodule] Registering <class 'kasa.smart.modules.motionsensor.MotionSensor'>
2024/11/20 20:08:27 | stdout | 2024-11-20 20:08:27.692 DEBUG (ImportExecutor_0) [kasa.smart.smartmodule] Registering <class 'kasa.smart.modules.lighttransition.LightTransition'>
2024/11/20 20:08:27 | stdout | 2024-11-20 20:08:27.691 DEBUG (ImportExecutor_0) [kasa.smart.smartmodule] Registering <class 'kasa.smart.modules.lightstripeffect.LightStripEffect'>
2024/11/20 20:08:27 | stdout | 2024-11-20 20:08:27.691 DEBUG (ImportExecutor_0) [kasa.smart.smartmodule] Registering <class 'kasa.smart.modules.lightpreset.LightPreset'>
2024/11/20 20:08:27 | stdout | 2024-11-20 20:08:27.690 DEBUG (ImportExecutor_0) [kasa.smart.smartmodule] Registering <class 'kasa.smart.modules.lighteffect.LightEffect'>
2024/11/20 20:08:27 | stdout | 2024-11-20 20:08:27.690 DEBUG (ImportExecutor_0) [kasa.smart.smartmodule] Registering <class 'kasa.smart.modules.light.Light'>
2024/11/20 20:08:27 | stdout | 2024-11-20 20:08:27.689 DEBUG (ImportExecutor_0) [kasa.smart.smartmodule] Registering <class 'kasa.smart.modules.led.Led'>
2024/11/20 20:08:27 | stdout | 2024-11-20 20:08:27.688 DEBUG (ImportExecutor_0) [kasa.smart.smartmodule] Registering <class 'kasa.smart.modules.humiditysensor.HumiditySensor'>
2024/11/20 20:08:27 | stdout | 2024-11-20 20:08:27.688 DEBUG (ImportExecutor_0) [kasa.smart.smartmodule] Registering <class 'kasa.smart.modules.frostprotection.FrostProtection'>
2024/11/20 20:08:27 | stdout | 2024-11-20 20:08:27.687 DEBUG (ImportExecutor_0) [kasa.smart.smartmodule] Registering <class 'kasa.smart.modules.firmware.Firmware'>
2024/11/20 20:08:27 | stdout | 2024-11-20 20:08:27.684 DEBUG (ImportExecutor_0) [kasa.smart.smartmodule] Registering <class 'kasa.smart.modules.fan.Fan'>
2024/11/20 20:08:27 | stdout | 2024-11-20 20:08:27.683 DEBUG (ImportExecutor_0) [kasa.smart.smartmodule] Registering <class 'kasa.smart.modules.energy.Energy'>
2024/11/20 20:08:27 | stdout | 2024-11-20 20:08:27.683 DEBUG (ImportExecutor_0) [kasa.smart.smartmodule] Registering <class 'kasa.smart.modules.devicemodule.DeviceModule'>
2024/11/20 20:08:27 | stdout | 2024-11-20 20:08:27.682 DEBUG (ImportExecutor_0) [kasa.smart.smartmodule] Registering <class 'kasa.smart.modules.contactsensor.ContactSensor'>
2024/11/20 20:08:27 | stdout | 2024-11-20 20:08:27.682 DEBUG (ImportExecutor_0) [kasa.smart.smartmodule] Registering <class 'kasa.smart.modules.colortemperature.ColorTemperature'>
2024/11/20 20:08:27 | stdout | 2024-11-20 20:08:27.681 DEBUG (ImportExecutor_0) [kasa.smart.smartmodule] Registering <class 'kasa.smart.modules.color.Color'>
2024/11/20 20:08:27 | stdout | 2024-11-20 20:08:27.681 DEBUG (ImportExecutor_0) [kasa.smart.smartmodule] Registering <class 'kasa.smart.modules.cloud.Cloud'>
2024/11/20 20:08:27 | stdout | 2024-11-20 20:08:27.680 DEBUG (ImportExecutor_0) [kasa.smart.smartmodule] Registering <class 'kasa.smart.modules.childprotection.ChildProtection'>
2024/11/20 20:08:27 | stdout | 2024-11-20 20:08:27.680 DEBUG (ImportExecutor_0) [kasa.smart.smartmodule] Registering <class 'kasa.smart.modules.childdevice.ChildDevice'>
2024/11/20 20:08:27 | stdout | 2024-11-20 20:08:27.679 DEBUG (ImportExecutor_0) [kasa.smart.smartmodule] Registering <class 'kasa.smart.modules.brightness.Brightness'>
2024/11/20 20:08:27 | stdout | 2024-11-20 20:08:27.679 DEBUG (ImportExecutor_0) [kasa.smart.smartmodule] Registering <class 'kasa.smart.modules.batterysensor.BatterySensor'>
2024/11/20 20:08:27 | stdout | 2024-11-20 20:08:27.678 DEBUG (ImportExecutor_0) [kasa.smart.smartmodule] Registering <class 'kasa.smart.modules.autooff.AutoOff'>
2024/11/20 20:08:27 | stdout | 2024-11-20 20:08:27.677 DEBUG (ImportExecutor_0) [kasa.smart.smartmodule] Registering <class 'kasa.smart.modules.alarm.Alarm'>
sdb9696 commented 1 week ago

Are you running the kasa tool from the HA device or a different device?

Comodore125 commented 1 week ago

I am running it from my PC but with same FW config as is allowed for HA. TP Link devices are still in different subnets. Since they dont work with HA at the moment I have at least opened cloud access again via FW change. HA is in container

EDIT: But its a good point. Something is broken I was working on that for two hours at least yesterday and it makes no sense to me:
obrazek

Image shows the command from container

After I got so far I am afraid that some network settings from my synology got deleted by updates or something and I think that there might be issue with gateways breaking access to other subnets because FW is where things looked absolutely fine.

Comodore125 commented 1 week ago

Thanks for pointing out the obvious. I used the uvx command from above - many thanks. I was reading into it and combined with diagnosing strange network issues (from day before) in a different level (not caused by FW) It got connected immediately. :)

I am finding it very strange that there even was this issue, since most of the time networks got connected easily but possibly two gateways on synology got confused from time to time and it might have been causing these issues. If it did not work from the first moment then it would have been easier to diagnose. :)