Repository navigation
Possible firmware issue with KL125 (1.0.7 Build 211009 Rel.172044) #345
Description
In the last week or two I started having some issues with the 5 KL125 bulbs in my house (software version: 1.0.6 Build 210813 Rel.153518). I mostly interact through Home Assistant but I'm noticing issues using python-kasa directly as well. To narrow down the issue I pulled a spare bulb (software version: 1.0.7 Build 211009 Rel.172044) that had been sitting in a drawer and tested the same and that one still works great in HA or python-kasa:
Works well: 1.0.6 Build 210813 Rel.153518
Issue on: 1.0.7 Build 211009 Rel.172044
To reproduce:
kasa --host 192.168.1.205 --type bulb state - works well kasa --host 192.168.1.205 --type bulb off - turns off as expected kasa --host 192.168.1.205 --type bulb state - Unresponsive (Unable to query the device 192.168.1.205). Sometimes turning off and on via the Kasa app on my phone helps but haven't pinned that down
When I try this on the older Software Version bulb, it works just fine between on / off / state. Works great in HA as well
The Kasa app also seems to still work consistently but if the bulbs get into a bad state via using python-kasa I have had to power cycle them to get them working there as well. If I only use the Kasa app, it seems like they work consistently.
I'm not sure if this is the same issue as #320 but mine definitely feels like the TP-Link Software Version is the difference...I hadn't logged into the app on my phone in a while but had to the other day to reset a device and I wonder if this version got pushed out.
I also have a KL110 (Software: 1.8.11 Build 191113 Rel.105336) that seems to work just fine with python-kasa so whatever the issue doesn't seem to affect that model / software version)
Questions I have:
Is anyone else seeing a similar issue?
Is this a known problem?
Is there a way to rollback the Software Version (even just to test)?
I've really liked these bulbs and this project (and it's integration into HA) has made them outstanding and a big part of my smart home. Let me know if there is anything else I can do to troubleshoot.
Activity
rytilahti commented on May 29, 2022
Sounds indeed like a firmware issue.. I don't think there's a simple way to do rollbacks, or at least I haven't heard anyone doing so.
You could try to sniff the traffic send by the official app to the device and try to use those commands directly with kasa raw-command to see if that works (e.g. kasa --host raw-command system get_sysinfo` to get system info only).
Alternatively, you could try to downgrade to 0.4.3 to see if it works. Since the last release (#299) this library requests all available information using a single state query, and there used to be some issues on some devices on similar, multi-module queries.
drummerboy2543 commented on Sep 14, 2022
Hello! I know it has been a bit but I am running a similar issue where I can not seem to discover my KL125 bulbs after some time of inactivity. I have to manually repower them or send data via the app to "wake" them. I can talk to them if I put their ip address in the host but I am not able to discover them via the broadcast method or via the discover methods.
I looked across the internet and there seems to not be much of an update. I was curious if any solution has been found as of yet. Thank You!
apizzi69 commented on Jan 12, 2023
@drummerboy2543 Any updates on this?
MattMarquise commented on Jan 16, 2023
Curious to know if this is still an issue?
Nathanlclark commented on Jan 29, 2023
To be honest I moved away from using the Kasa Wifi bulbs to use Zigbee bulbs instead. I still have the Kasa bulbs in a drawer but I haven't bothered to try them out.
If someone else is having this problem, please share now.
brianthedavis commented on Apr 26, 2023
I've noticed two things similar to this thread - figured I'd share for reference. I've got a bunch of KL125 bulbs (hw_ver: 1.20, sw_ver: 1.0.7 Build 211009 Rel.172044).
General Unresponsiveness
Regardless of the python-kasa utility, I discovered that the DHCP address of the bulbs was expiring from my DHCP server, but the bulbs didn't know that and never asked for a renewed lease. So, effectively, my network forgot where the bulbs were (by hostname) but the bulbs still though they were connected. (I was hard-coding bulb hostnames using dnsmasq/pihole). My mitigation to this was to change the DHCP Lease time of these bulbs in my dnsmasq configuration to infinite instead of the default of 2 days. So, (if anyone else is using dnsmasq for dhcp), part of my conf file now looks like):
This has largely solved the issue that @drummerboy2543 mentioned for me; I'm not sure if it affects the discoverability of them. Prior to this solution, I had to power cycle (some) of the bulbs to get them to reconnect.
Original Issue
I've been running an old 0.4.0dev5 build for quite a while reliably and haven't had any python-kasa issues since #199 - but in downloading the latest version I had the exact same issues that @Nathanlclark mentioned. I could run the command once, but subsequent commands would time out. This made me believe that this is a regression of the issue that #199 addressed - requesting modules that the bulb doesn't support causes it to crash and restart; thus being unresponsive for a few seconds.
@rytilahti I think I confirmed this theory -- if I modify the constructor of the smartbulb.py file to this:
def __init__(self, host: str) -> None: super().__init__(host=host) self._device_type = DeviceType.Bulb self.add_module("schedule", Schedule(self, "smartlife.iot.common.schedule")) self.add_module("usage", Usage(self, "smartlife.iot.common.schedule")) # self.add_module("antitheft", Antitheft(self, "smartlife.iot.common.anti_theft")) self.add_module("time", Time(self, "smartlife.iot.common.timesetting")) self.add_module("emeter", Emeter(self, self.emeter_type)) # self.add_module("countdown", Countdown(self, "countdown")) # self.add_module("cloud", Cloud(self, "smartlife.iot.common.cloud"))(removing the antitheft, countdown, and cloud modules), I can consistently run python-kasa over and over with no lag.
I put together #451 as an attempt to fix this for the KL125(US) bulb; but I'm not sure that this is the right way to do this.
rytilahti commented on Apr 29, 2023
Thanks for your elaborate description and the PR, @brianthedavis! I added some comments to the PR, it would be great to get this fixed :-)