Repository navigation
Timeout while discovering device type with newer versions of python-kasa #743
Description
I upgraded python-kasa via pip today, and one KP115 plug will timeout before discovering the device type.
With version 0.6.2.1 it times out:
`# kasa --host kp115 sysinfo
No --type or --device-family and --encrypt-type defined, discovering..
Got error: TimeoutException('Timed out getting discovery response for kp115')
`
With version 0.5.1 it succeeds:
`# kasa --host kp115 sysinfo
No --type defined, discovering..
== System info ==
{'active_mode': 'none',
'alias': '****',
'dev_name': 'Smart Wi-Fi Plug Mini',
'deviceId': '****',
'err_code': 0,
'feature': 'TIM:ENE',
'hwId': '24ACB9D5D9DA9BF17639988287D65DE6',
'hw_ver': '1.0',
'icon_hash': '',
'latitude_i': -1879048193,
'led_off': 0,
'longitude_i': -1879048193,
'mac': '****',
'mic_type': 'IOT.SMARTPLUGSWITCH',
'model': 'KP115(EU)',
'next_action': {'type': -1},
'ntc_state': 0,
'obd_src': 'tplink',
'oemId': 'A9AD6FB31E10A787A48B31AB9A10BBEC',
'on_time': 2035,
'relay_state': 1,
'rssi': -68,
'status': 'new',
'sw_ver': '1.0.20 Build 221125 Rel.092759',
'updating': 0}
`
when specifying --type plug it works with version 0.6.2.1 as well.
Activity
sdb9696 commented on Feb 8, 2024
Could you try increasing the timeout with kasa --host kp115 --discovery-timeout 5 sysinfo
MaxRower commented on Feb 8, 2024
Yes, with the longer timeout of 5s it does work. Tried it with setting --discovery-timeout 3 explicitly, and it failed. But only for that one plug. All others do work with 3s. Wifi connection is fine, ping time mostly between 3 and 8ms on that device. Very strange.
Edit: even with 5s it fails sometimes, increased to 10s, and it still does fail sometimes, ping times consistently low. I think, I will reset the plug, and see, if that helps.
sdb9696 commented on Feb 8, 2024
What happens if you omit the sysinfo command?
MaxRower commented on Feb 8, 2024
Same thing, only a different output, if it works. Maybe it's time to get rid of that six Kasa plugs, and replace them with tasmota based plugs. They are so much easier to use.
MaxRower commented on Feb 8, 2024
I did a factory rest of that KP115 now, it did not change anything. It uses the same wifi and the same vlan as the other plugs, so I still have no clue why it behaves that way.
sdb9696 commented on Feb 8, 2024
Could you try using the ip address of the device as argument to --host instead of the hostname see whether it makes a difference?
MaxRower commented on Feb 8, 2024
Oh, I did that already, it doesn't help anything.
MaxRower commented on Feb 8, 2024
tcpdump on the router when it is not working, regardless of the timeout:
listening on br-lan.7, link-type EN10MB (Ethernet), snapshot length 262144 bytes
17:00:46.117676 IP 192.168.24.168.55998 > 192.168.14.118.9999: UDP, length 31
17:00:46.117821 IP 192.168.24.168.55998 > 192.168.14.118.20002: UDP, length 16
17:00:47.786646 IP 192.168.24.168.55998 > 192.168.14.118.9999: UDP, length 31
17:00:47.786791 IP 192.168.24.168.55998 > 192.168.14.118.20002: UDP, length 16
17:00:49.454459 IP 192.168.24.168.55998 > 192.168.14.118.9999: UDP, length 31
17:00:49.454617 IP 192.168.24.168.55998 > 192.168.14.118.20002: UDP, length 16
tcpdump when it's working:
listening on br-lan.7, link-type EN10MB (Ethernet), snapshot length 262144 bytes
17:06:48.918695 IP 192.168.24.168.55917 > 192.168.14.118.9999: UDP, length 31
17:06:48.921385 IP 192.168.24.168.55917 > 192.168.14.118.20002: UDP, length 16
17:06:48.925769 IP 192.168.14.118.9999 > 192.168.24.168.55917: UDP, length 614
17:06:48.927609 IP 192.168.14.118 > 192.168.24.168: ICMP 192.168.14.118 udp port 20002 unreachable, length 36
17:06:48.929508 IP 192.168.24.168.51694 > 192.168.14.118.9999: Flags [S], seq 455070334, win 64240, options [mss 1460,nop,wscale 8,nop,nop,sackOK], length 0
17:06:48.935851 IP 192.168.14.118.9999 > 192.168.24.168.51694: Flags [S.], seq 94764, ack 455070335, win 2920, options [mss 1460], length 0
17:06:48.936593 IP 192.168.24.168.51694 > 192.168.14.118.9999: Flags [.], ack 1, win 64240, length 0
17:06:48.937368 IP 192.168.24.168.51694 > 192.168.14.118.9999: Flags [P.], seq 1:404, ack 1, win 64240, length 403
17:06:49.238978 IP 192.168.24.168.51694 > 192.168.14.118.9999: Flags [P.], seq 1:404, ack 1, win 64240, length 403
17:06:49.254270 IP 192.168.14.118.9999 > 192.168.24.168.51694: Flags [P.], seq 1:1029, ack 404, win 2517, length 1028
17:06:49.301049 IP 192.168.24.168.51694 > 192.168.14.118.9999: Flags [.], ack 1029, win 63212, length 0
17:06:49.304333 IP 192.168.14.118.9999 > 192.168.24.168.51694: Flags [P.], seq 1029:1756, ack 404, win 2517, length 727
17:06:49.304870 IP 192.168.24.168.51694 > 192.168.14.118.9999: Flags [.], ack 1756, win 64240, length 0
17:06:49.364762 IP 192.168.24.168.51694 > 192.168.14.118.9999: Flags [F.], seq 404, ack 1756, win 64240, length 0
17:06:49.367424 IP 192.168.14.118.9999 > 192.168.24.168.51694: Flags [.], ack 405, win 2516, length 0
17:06:49.468359 IP 192.168.14.118.9999 > 192.168.24.168.51694: Flags [F.], seq 1756, ack 405, win 2516, length 0
17:06:49.471203 IP 192.168.24.168.51694 > 192.168.14.118.9999: Flags [.], ack 1757, win 64240, length 0
I tried --discovery-timeout 1000, most of the time, it definitely does not wait that long. Seems as long as 5s or 3s.
tcpdump with another, normally working KP115:
listening on br-lan.7, link-type EN10MB (Ethernet), snapshot length 262144 bytes
17:09:44.677739 IP 192.168.24.168.60288 > 192.168.14.205.9999: UDP, length 31
17:09:44.677978 IP 192.168.24.168.60288 > 192.168.14.205.20002: UDP, length 16
17:09:44.684878 IP 192.168.14.205.9999 > 192.168.24.168.60288: UDP, length 628
17:09:44.685484 IP 192.168.14.205 > 192.168.24.168: ICMP 192.168.14.205 udp port 20002 unreachable, length 36
17:09:44.696708 IP 192.168.24.168.51738 > 192.168.14.205.9999: Flags [S], seq 1602541815, win 64240, options [mss 1460,nop,wscale 8,nop,nop,sackOK], length 0
17:09:44.701279 IP 192.168.14.205.9999 > 192.168.24.168.51738: Flags [S.], seq 6027888, ack 1602541816, win 2920, options [mss 1460], length 0
17:09:44.702141 IP 192.168.24.168.51738 > 192.168.14.205.9999: Flags [.], ack 1, win 64240, length 0
17:09:44.702861 IP 192.168.24.168.51738 > 192.168.14.205.9999: Flags [P.], seq 1:404, ack 1, win 64240, length 403
17:09:44.720764 IP 192.168.14.205.9999 > 192.168.24.168.51738: Flags [P.], seq 1:1029, ack 404, win 2517, length 1028
17:09:44.725286 IP 192.168.14.205.9999 > 192.168.24.168.51738: Flags [P.], seq 1029:2489, ack 404, win 2517, length 1460
17:09:44.726155 IP 192.168.24.168.51738 > 192.168.14.205.9999: Flags [.], ack 2489, win 61752, length 0
17:09:44.726179 IP 192.168.24.168.51738 > 192.168.14.205.9999: Flags [.], ack 2489, win 64240, length 0
17:09:44.729380 IP 192.168.14.205.9999 > 192.168.24.168.51738: Flags [P.], seq 2489:2502, ack 404, win 2517, length 13
17:09:44.785182 IP 192.168.24.168.51738 > 192.168.14.205.9999: Flags [.], ack 2502, win 64227, length 0
17:09:44.793527 IP 192.168.24.168.51738 > 192.168.14.205.9999: Flags [F.], seq 404, ack 2502, win 64227, length 0
17:09:44.797266 IP 192.168.14.205.9999 > 192.168.24.168.51738: Flags [.], ack 405, win 2516, length 0
17:09:44.898179 IP 192.168.14.205.9999 > 192.168.24.168.51738: Flags [F.], seq 2502, ack 405, win 2516, length 0
17:09:44.898919 IP 192.168.24.168.51738 > 192.168.14.205.9999: Flags [.], ack 2503, win 64227, length 0
sdb9696 commented on Feb 8, 2024
So it seems there is an issue with the discovery-timeout not being passed although which I've created a PR for #744 although that doesn't explain why the device isn't responding.
N.B. the library now uses UDP for initial discovery of a single device instead of TCP which is why 0.5.1 isn't having the issue.
Is the hw_ver and sw_ver on your working KP115 the same as the intermittent one? Do they have the same values for other fields like odb_src and status?
MaxRower commented on Feb 8, 2024
Yes, they are identical plugs, ordered at the same time from amazon.de in August 2021. I upgraded the firmware yesterday from 1.0.16 to 1.0.20, I hesitated a long time to try it, because there were cases, where people lost their local access. But in the end, it was for other models only and just the change for requiring authentication. My three HS110 upgraded in seconds, one KP115 took serveral tries until successful, and the remaining two refused to upgrade, even with 20 or more tries. Then I found that ticket how to upgrade manually via python-kasa, and it worked right from the start. But the bad behaviour of that KP115 did not change.
sdb9696 commented on Feb 8, 2024
So the badly behaved KP115 is the one you managed to upgrade via the TPLink Kasa App and the two you upgraded via python-kasa are behaving?
MaxRower commented on Feb 8, 2024
No, the bad one had to be upgraded manually, but another one working fine as well. So no clue here.
MaxRower commented on Feb 8, 2024
The strange thing is, while python-mqtt has problems with it, my Home Assistant gets emeter updates every 10s and logs them to my influxdb, from every kasa plug. But I would like to get rid of that HA integration, and do the communication only via mqtt2kasa, even for HA. But that will be a long way to go, until it does work fully. My experience says, that mqtt for controlling and logging is more stable than using HA alone. At least my numerous Tasmota plugs never make problems, and can be fine tuned much better.
sdb9696 commented on Feb 8, 2024
Is HA running and communicating with the KP115 at the same time as you are testing it with the kasa cli? Are you using the same PC to test with that HA is running on?
MaxRower commented on Feb 8, 2024
Yes, HA ist constantly running. But since there is a problem with only one of them, I don't think it matters. I did the testing via CLI inside the HA container, and on my Windows PC with wsl. No difference.
sdb9696 commented on Feb 8, 2024
I think it might be worthwhile testing it while HA is not running. We don't know but there could be some kind of side effect with connections not being closed properly etc. Which version of HA are you running btw?
MaxRower commented on Feb 8, 2024
Currently I have mqtt2kasa running as well, getting emeter updates every 10s. No problem with the good plugs, the bad one refuses to get discovered.
MaxRower commented on Feb 8, 2024
HA runs as a snap in an ubuntu lxd container.
home-assistant-snap 2023.12.4 585 latest/stable
I will shutdown both mqtt2kasa and HA and test again, but I'm certain, it won't help.
MaxRower commented on Feb 8, 2024
A expected, no traffic for the plugs with tcpdump, so everything is shutdown completely, but it does not change anything. The good ones reply instantly, the bad one mostly does not.
Maybe it's a hardware problem with ageing of the components inside? But why does it respond normally when specifying --type plug? Everything else seems to work fine.
sdb9696 commented on Feb 8, 2024
When you specify --type plug it connects directly via TCP, when you don't it uses UDP to discover the type.
rytilahti commented on Feb 8, 2024
Your packet trace shows no responses from the device to that discovery query, could you check if you might have a firewall rule forbidding UDP?
github-actions commented on Sep 28, 2024
There hasn't been any activity on this issue recently. This issue has been automatically marked as stale because of that. It will be closed if no further activity occurs.
Please make sure to update to the latest python-kasa version and check if that solves the issue.
Thank you for your contributions.