Timeout while discovering device type with newer versions of python-kasa #743
Comments
|
Could you try increasing the timeout with |
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. |
|
What happens if you omit the |
|
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. |
|
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. |
|
Could you try using the ip address of the device as argument to |
Oh, I did that already, it doesn't help anything. |
|
tcpdump on the router when it is not working, regardless of the timeout: tcpdump when it's working: 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: |
|
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 |
|
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. |
|
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? |
|
No, the bad one had to be upgraded manually, but another one working fine as well. So no clue here. |
|
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. |
|
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? |
|
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. |
|
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? |
|
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. |
|
HA runs as a snap in an ubuntu lxd container. |
|
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. |
|
When you specify |
|
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? |
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.
The text was updated successfully, but these errors were encountered: