python-kasa / python-kasa

🏠🤖 Python API for TP-Link smarthome products
https://python-kasa.readthedocs.io/en/stable/
Other
1.25k stars 204 forks source link

Unable to add plug to Wi-Fi #1325

Open RiderExMachina opened 21 hours ago

RiderExMachina commented 21 hours ago

Trying to connect some Kasa HS100 smart plugs using version 0.8.0 from pip on Linux.

$ uname -a
Linux 6.11.7-300.fc41.x86_64 #1 SMP PREEMPT_DYNAMIC Fri Nov  8 19:23:10 UTC 2024 x86_64 GNU/Linux

$ kasa --version
kasa, version 0.8.0

I connect to the device via its setup network and run the wifi join command like so:

$ kasa --host 192.168.0.1 wifi join <wi-fi name>
Discovering device 192.168.0.1 for 10 seconds
Keytype: WPA2
Password: 
Asking the device to connect to <wi-fi name>..
Raised error: invalid literal for int() with base 10: 'WPA2'
Run with --debug enabled to see stacktrace

Looking into the code more, it appears that it wants wpa2_psk as an option, so I tried that as well:

$ kasa --host 192.168.0.1 wifi join <wi-fi name>
Discovering device 192.168.0.1 for 10 seconds
Keytype: wpa2_psk
Password: 
Asking the device to connect to <wi-fi name>..
Raised error: invalid literal for int() with base 10: 'wpa2_psk'
Run with --debug enabled to see stacktrace

Actually reading through the error, I realize that it appears as if the code is trying to convert the string into an int at some point, but when trying to follow the code, I am unable to locate where, and every instance where it asks for the Keytype, it asks for a string.

My workaround to get it to work was to comment out and/or remove the calls for keytype within cli/wifi.py, which, because of the default option within device.py, allowed my devices to connect with no problems.

From a usability standpoint, I would recommend either asking the user if their keytype is not wpa2_psk, and if they say no, then ask what type of keytype they need, and also listing out some common possible keytypes with what the program will expect.

forrestab commented 5 hours ago

Running wifi scan provided the numeric value of keytype for me.

Note: wifi scan defaults to a 5s timeout which was too short for me, I ended up having to specify --timeout 30 to see anything.

RiderExMachina commented 5 hours ago

Running wifi scan provided the numeric value of keytype for me.

This may have been part of my problem; wifi scan returns an error for me, even now when the device has been connected to wifi.

kasa --host <ip address> wifi scan
Discovering device <ip address> for 10 seconds
Scanning for wifi networks, wait a second..
Raised error: Error on smartlife.iot.common.softaponboarding.get_scaninfo: {'err_code': -1, 'err_msg': 'module not support'}
Run with --debug enabled to see stacktrace

I'm guessing it has to do with the features of my plug?

rytilahti commented 1 hour ago

If you add --debug directly after kasa, do you see it trying the same command on another module? Is it also erroring out?

The cli could indeed use some improvements on this regard, so if anyone wants to create a PR, I'm happy to help reviewing it. The reason why there exists both numeric and string-based key types is that different device/protocol families use different format, and we try to cater both types.