Possible firmware issue with KL125 (1.0.7 Build 211009 Rel.172044)
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 https://github.com/python-kasa/python-kasa/issues/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.
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
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.
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!
@drummerboy2543 Any updates on this?
Curious to know if this is still an issue?
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.
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):
dhcp-host=40:3f:8c:ab:a2:ac,10.0.20.158,kasa-bc04,infinite
dhcp-host=e8:48:b8:55:0e:74,10.0.20.66,kasa-bc05,infinite
dhcp-host=e8:48:b8:55:32:95,10.0.20.148,kasa-bc06,infinite
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 https://github.com/python-kasa/python-kasa/pull/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.
Thanks for your elaborate description and the PR, @brianthedavis! I added some comments to the PR, it would be great to get this fixed :-)