Unable to scan or connect to wifi

OS: Kubuntu 20.04 Node: v14.17.2 Bulb: KL130

There appears to be a bug effecting wifi onboarding - I received the same error when attempting to scan available networks and connect to a network (both while connected to the bulb’s setup network). Other functions I tried (turn light on/off, change color temp) worked perfectly. To rule out issues with my node setup, I fresh installed node on a different computer (same OS + node version) and got identical errors.

Scan:

jamedeus@desktop:~/tp-link-python-client$ tplight wifi 192.168.0.1
TypeError: Cannot read property 'ap_list' of undefined
    at /usr/lib/node_modules/tplink-lightbulb/build/lib.js:1:1042
    at processTicksAndRejections (internal/process/task_queues.js:95:5)

Connect:

jamedeus@desktop:~/tp-link-python-client$ tplight join 192.168.0.1 <credentials-removed>
TypeError: Cannot read property 'ap_list' of undefined
    at /usr/lib/node_modules/tplink-lightbulb/build/lib.js:1:1042
    at processTicksAndRejections (internal/process/task_queues.js:95:5)

Unfortunately I’m not able to debug this as I don’t know javascript.

I can however confirm that the bulb is capable of connecting without the kasa app. I had previously used this python client to onboard and control my TP-Link HS220 smart dimmers. It includes an option for sending raw JSON to the device from CLI. However, it didn’t work with my new KL130 bulb which led me to this project.

After reading this commit, I noticed that the first JSON parameter is different than what I had used for the dimmers (Bulb=smartlife.iot.common.softaponboarding, dimmer=netif), while the rest was identical. I went back to the python client and swapped these parameters out. The bulb connected without issue, confirming that TP-Link hasn’t disabled this with a firmware update.

While I’m not able to debug, I’d be happy to reproduce the problem and test out potential solutions if that would help. Great project, much more user-friendly than what I had used previously!

[konsumer]

model and hwId both look like reliable indicators of which device it is.

Agreed. I’d prefer to not keep a big table of all the supported versions (it’s more fragile, and requires a lot more maintenance.) I think we might be able to try some other stuff to figure it out, though. I am ok with the fall-through for now, but I bet it could be improved.

mic_type might be useful? Says IOT.SMARTPLUGSWITCH for a dimmer which is odd

I saw this on mine, too. super-weird.

Please continue tracking this issue at #61, as it’s really a separate thing.

[jamedeus]

Here’s the full details for all my devices in case it’s helpful. Couple possibilities:

• model and hwId both look like reliable indicators of which device it is.
• mic_type might be useful? Says IOT.SMARTPLUGSWITCH for a dimmer which is odd, maybe there are only a few possible values here which would be easy split into 2 groups.

Thanks again!