TPLink Devices constantly disconnect/reconnect, but only when I block them [SOLVED]

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.

Kasa Smart Switch/Plug Disconnects and Reconnects to Wi-Fi Every 10 Minutes on A Local Wi-Fi Network - Smart Home Community (tp-link.com)

1 Like

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.

1 Like

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.

1 Like

Thanks for the info! I’m learning a lot trying to get these bulbs to play nice…

I wasn’t able to see most of the bulb traffic with Wireshark because it wasn’t hitting my PC since it wasn’t the target of the packet. I was only seeing the communications to HA from service calls, as well as broadcast messages. I had to ssh to one of my access points and run Wireshark against its tcpdump output. Then I was able to see all the traffic of the devices on the AP.

In the end what I found was I had to let the bulbs connect to TPLink, then DNSmasq the domains to my HA server IP. Then I firewalled them from the internet. That all worked, but I had concerns it would break as it was dependent on that initial successful communication with TPLink. I was right…, after a few days without issues I restarted my router and a few hours later noticed all 3 bulbs had started becoming unresponsive every 10 mins. Grr.

Can confirm that this fix is working? Because if yes, we could adjust the documentation accordingly given that this is a rather nasty issue even when it’s only encountered by people with strict firewall rules.

I was hoping I could make that contribution, however my testing doesn’t support it, at least with the kl125 bulbs.

They were rock solid after I tricked them (as mentioned above), but they’ve been back to their usual ruckus since. Very annoying. I’m looking for other options since TPLink hasn’t acknowledged it as something they intend to fix despite it matching symptoms on a plug they updated firmware for.

Top half of the history is availability in HA, bottom half is ping.

I don’t have any Kasa light bulbs, but I have not had any issues in months since this was solved in this thread (not really solved I guess). I think the newer firmware doesn’t react the same as the older fw I am running (probably using SSL now). Once I get these devices working, I do not allow updates to occur. I have only been buying Wiz light bulbs for the past year or so. The pairing app works without an account and HA finds them instantly once connected to wifi.

1 Like

It seems to only be working dependent on the fw in the TPLink device. So, yes and no.

If you device cannot disconnect from the TPLink servers, I would suggest posting in the GIT page for python-kasa. Issues · python-kasa/python-kasa · GitHub

The author is very good at responding to issues and is willing to help get it resolved.

2 Likes

Ah, that’s too bad… But thanks for letting us know, and thanks for your nice words as I am the library author :slight_smile:

I saw that they fixed this issue on some plugs (Kasa Smart Switch/Plug Disconnects and Reconnects to Wi-Fi Every 10 Minutes on A Local Wi-Fi Network - Smart Home Community) but not on all, so maybe there’s hope.

2 Likes