I have found a much better solution. While working with the author of python-kasa (linked above), he gave me a command that will unbind the devices from the tplink acct therefore allowing me to remove blocks and redirects from my router. This works perfectly.
kasa --debug --host 192.168.*.* raw-command cnCloud unbind
The --debug flag is optional, but does return some good and interesting information.
BTW, this python-kasa command should really be included in Home Assistant releases. It’s too handy not to have.
Things have apparently changed in python-kasa. I get the following error:
No --type or --device-family and --encrypt-type defined, discovering…
WARNING:root:Deprecated, use ‘kasa command --module cnCloud unbind’
Got error: SmartDeviceException(“Error on cnCloud unbind: {‘err_code’: -24, ‘err_msg’: ‘no reply from server’}”)
I haven’t figured out the correct combination to make the suggested command work. I’m not sure where to insert the host ip. Also redirecting the dns entries as suggested earlier in the thread haven’t worked for me either
Any thoughts?
Edit: I tried:
kasa --host 192.168.3.9 command --module cnCloud unbind
And that returned the exact same error message as above:
SmartDeviceException(“Error on cnCloud unbind: {‘err_code’: -24, ‘err_msg’: ‘no reply from server’}”)
Maybe I’m doing something wrong on my end?
What OS are you trying this from? Also, I just tried it and it still worked for me. Your command structure is not the same as shown above.
kasa --host 192.168.1.220 raw-command cnCloud unbind
This worked.
If you would happen to get this error:
Got error: SmartDeviceException("Error on cnCloud unbind: {'err_code': -8, 'err_msg': 'not bind yet'}")
The device was not yet bound to the cloud.
I’m trying to do this from windows 10.
When I tired the commend like you listed it said it was deprecated and suggested what I used.
My switches have never connected to the internet. Should I let them do that first?
I would not do that. If they have never connected to the Internet, I would just leave well enough alone. Maybe the command is deprecated for the device type you are using? What is the device and what version of kasa are you using?
kasa --version
Mine is kasa, version 0.5.1
I have an HS220 and a couple HS200s. They are all 1.0.10
What is the version of the kasa python script? Mine is 0.5.1.
Just type “kasa --version” to retrieve it.
Oh, I see that v6.0 was released a few months ago:
Yeah, I have version 0.6.2.1
I will try to mess with the latest version over the weekend. It is quite different and supports the new Mater protocol and a few backported older devices that may have had their fw updated. I don’t want to break what I have working so I may have to jump though some hoops to test it without deleting my 0.5.1 version. All my computers are Linux (no Windows in the house) so this should be pretty straight forward, unlike on Windows.
I managed to get python-kasa 0.6.2.1 to unbind my switches from the cloud. If you run this several times:
kasa --host 192.168.0.xxx command --module cnCloud unbind
… it’ll eventually go thru and report:
{'err_code': -8, 'err_msg': 'not bind yet'}")
Once this is done if you go in the app a red exclamation mark with a “Remote Control” toggle is a new item in the device setup and it’s off.
Most of my devices stopped dropping, but my HS220’s still drop and reconnect. I was given this by another contributor, and I have submitted for the beta firmware that resolves this. Read more here, hope it helps.
Yes, I let mine connect to the internet and the hs200s downloaded a firmware update (1.0.11) and then when I did the unbind command and they are solid now. Like you, my hs220 is still at 1.0.10 and still dropping.
I’ll have to check out the beta firmware. Let me know if it works for you.
Thanks!
-Steve
Glad to see you got the command line syntax worked out. Also very happy to see that TP-Link has acknowledged the problem and are offering a fix. Nice find!
Hi all,
I’m having a similar issue with my KL125s. I wasn’t able to “unbind” them. When I attempt with kasa --debug --host 192.168.107.28 command --module cnCloud unbind I get the following:
DEBUG:kasa.discover:[DISCOVERY] 192.168.107.28 >> {'system': {'get_sysinfo': None}}
DEBUG:kasa.discover:Waiting a total of 5 seconds for responses...
DEBUG:kasa.discover:[DISCOVERY] 192.168.107.28 << {'system': {'get_sysinfo': {'sw_ver': '1.0.5 Build 230613 Rel.151643', 'hw_ver':
'4.0', 'model': 'KL125(US)', 'deviceId': '8012ACAFE5373783D517457AD4BE861921A86C5B', 'oemId': '82E6C9A57FC634FA41A9A8D339B1A6D4', 'hwId': 'F5DFE24039B182A525EA715C41177D2A', 'rssi': -56, 'latitude_i': 481980, 'longitude_i': -1222963, 'alias': "Gena's Lamp Bulb", 'status': 'new', 'obd_src': 'tplink', 'description': 'Smart Wi-Fi LED Bulb with Color Changing', 'mic_type': 'IOT.SMARTBULB', 'mic_mac': '3C52A1896807', 'dev_state': 'normal', 'is_factory': False, 'disco_ver': '1.0', 'ctrl_protocols': {'name': 'Linkie', 'version': '1.0'}, 'active_mode': 'none', 'is_dimmable': 1, 'is_color': 1, 'is_variable_color_temp': 1, 'light_state': {'on_off': 0, 'dft_on_state': {'mode': 'normal', 'hue': 0, 'saturation': 0, 'color_temp': 2500, 'brightness': 100}}, 'preferred_state': [{'index': 0,
'hue': 0, 'saturation': 0, 'color_temp': 2700, 'brightness': 100}, {'index': 1, 'hue': 0, 'saturation': 100, 'color_temp': 0, 'brightness': 100}, {'index': 2, 'hue': 120, 'saturation': 100, 'color_temp': 0, 'brightness': 100}, {'index': 3, 'hue': 240, 'saturation': 100, 'color_temp': 0, 'brightness': 100}], 'err_code': 0}}}
DEBUG:kasa.smartdevice:Initializing 192.168.107.28 of type <class 'kasa.smartbulb.SmartBulb'>
DEBUG:kasa.smartdevice:Adding module <Module Schedule (smartlife.iot.common.schedule) for 192.168.107.28>
DEBUG:kasa.smartdevice:Adding module <Module Usage (smartlife.iot.common.schedule) for 192.168.107.28>
DEBUG:kasa.smartdevice:Adding module <Module Antitheft (smartlife.iot.common.anti_theft) for 192.168.107.28>
DEBUG:kasa.smartdevice:Adding module <Module Time (smartlife.iot.common.timesetting) for 192.168.107.28>
DEBUG:kasa.smartdevice:Adding module <Module Emeter (smartlife.iot.common.emeter) for 192.168.107.28>
DEBUG:kasa.smartdevice:Adding module <Module Countdown (countdown) for 192.168.107.28>
DEBUG:kasa.smartdevice:Adding module <Module Cloud (smartlife.iot.common.cloud) for 192.168.107.28>
DEBUG:kasa.xortransport:192.168.107.28 >> {"cnCloud":{"unbind":null}}
DEBUG:kasa.xortransport:192.168.107.28 << {'cnCloud': {'err_code': -2001, 'err_msg': 'module not support'}}
Got error: SmartDeviceException("Error on cnCloud.unbind: {'err_code': -2001, 'err_msg': 'module not support'}")
I also tried --module Cloud unbind, but get a similar error.
I opened a new thread at the TP Link forum after Wayne-TP suggested I do so when I inquired about a firmware revision for the KL125 model.
Bulbs use a different module naming, you could try replacing cnCloud in your command line with smartlife.iot.common.cloud (like seen in your log, btw? :-)) to check if that works.
You know… I could swear I’d tried that, but I mustn’t have. Thank you for the suggestion!
This time around I got:
DEBUG:kasa.xortransport:192.168.LAN.185 >> {"smartlife.iot.common.cloud":{"unbind":null}}
DEBUG:kasa.xortransport:192.168.LAN.185 << {'smartlife.iot.common.cloud': {'unbind': {'err_code': -4001,
'err_msg': 'no reply from server'}}}
Got error: SmartDeviceException("Error on smartlife.iot.common.cloud unbind: {'err_code': -4001, 'err_msg': 'no reply from server'}")
'no reply from server' was a new response. After unblocking the TPLink servers in PiHole I got:
DEBUG:kasa.xortransport:192.168.LAN.182 >> {"smartlife.iot.common.cloud":{"unbind":null}}
DEBUG:kasa.xortransport:192.168.LAN.182 << {'smartlife.iot.common.cloud': {'unbind': {'err_code': 0}}}
{}
and then:
DEBUG:kasa.xortransport:192.168.LAN.182 >> {"smartlife.iot.common.cloud":{"unbind":null}}
DEBUG:kasa.xortransport:192.168.LAN.182 << {'smartlife.iot.common.cloud': {'unbind': {'err_code': -4002,
'err_msg': 'cloud account error'}}}
Got error: SmartDeviceException("Error on smartlife.iot.common.cloud unbind: {'err_code': -4002, 'err_msg': 'cloud account error'}")
I tried this on all the bulbs, some of which I’d moved out of the IOT Vlan for testing. The two on the main VLAN started showing up as discoverable in the Kasa app, including one which had been factory reset and provisioned by kasa-python. this is weird considering that the app hasn’t been able to see it previosly even though it’s network environment didn’t change. Also the “remote control” toggle started showing up. The only one which didn’t show up is the one left on the IOT VLAN.
I’ve got everything blocked again, so we’ll see if the disconnection issue pops up again. (it’s taken a few days in the past).
Sidenote - TPLink doesn’t seem to care about support for Home Assistant. The tech on their forum said so. They quit replying even after I showed that the devices were dropping within the Kasa app as well as on HA, and they haven’t responded at all to the thread they suggested I open. It’s a decent bulb for the cost except that it seems to be programmed to be dependant on the cloud. Fingers crossed this unbind changes that…
Sadly I have to report that didn’t fix it. It seems these bulbs are persistently programmed to depend on the cloud. Grr.
I was hopeful for a couple days until I realized my pihole rules weren’t working as intended. When I buttoned the bulbs back down they almost immediately started their 10 minutes on, 1 minute unavailable cycle.
I’m thinking I’m gonna try this…
Is there anything special I need to configure on the web server side? I.e. can I point these domains at my server that hosts docker and it will automatically reply with the acknowledgement, sort of like a ping response?
EDIT to add:
Ok, so I’ve added a new dnsmasq file in pihole with the lines mentioned in post #6 to a new .conf file in PiHole:
Now, when I ping or traceroute to the tplink* addresses I recieve a response from my local server, so I believe it is working, however I’m unable to see much activity from these devices with wireshark. What are you filtering by to see them? I’m using ip.addr and nothing much shows up unless I ping them or send a command with kasa-python.
I don’t think your server will reply with any acknowledgement of any sort, I think the Kasa devices are simply happy that it can connect to something/anything.
If memory servers me correct, my wireshark filter was something along these line:
ip.addr == 192.168.254.215 or ip.addr == 192.168.254.216 or ip.addr == 192.168.254.217 or ip.addr == 192.168.254.218
You can also do a “sudo tail -f /var/log/pihole.log | grep tplink” on your pihole to possibly see activity.