Repository navigation
Exclude querying certain modules for KL125(US) which cause crashes - #451
rytilahti merged 10 commits into
Conversation
Sorry, something went wrong.
|
|
||
| # Certain module queries will crash devices; this list skips those queries | ||
| MODULE_EXCLUSIONS = { | ||
| "KL125(US)": ["antitheft", "cloud", "countdown"] |
There was a problem hiding this comment.
Add a comment linking to the issue, just in case someone comes around wondering why this is done.
Btw, are you certain that cloud is also an issue? I'm seeing on my KL130 that it does not support countdown:
{'countdown': {'err_code': -2001, 'err_msg': 'Module not support'}
and one of the antitheft methods is also unsupported:
'smartlife.iot.common.anti_theft': {'get_next_action': {'err_code': -2000,
'err_msg': 'Method '
'not '
'support'},
'get_rules': {'enable': 0,
'err_code': 0,
'rule_list': []}},
while the cloud query has worked on all on my test devices.
Could it just be, that the number of modules (and/or methods) is the thing that breaks it?
Sorry, something went wrong.
There was a problem hiding this comment.
Add a comment linking to the issue, just in case someone comes around wondering why this is done.
Done!
Btw, are you certain that cloud is also an issue? I'm seeing on my KL130 that it does not support countdown:
I went back and did more testing and made a few additional interesting discoveries (that I'll document here in case someone else stumbles onto them).
- I had a power outage last week and so all of my bulbs were powered off about 72 hours ago.
- As a result, I discovered that querying the cloud, countdown, and antitheft modules did NOT cause most of my KL125 bulbs to consistently crash. This tells me that the "crashing" of the bulbs is loosely tied to how long they've been powered on.
- I was able to get one of my bulbs to misbehave and confirmed your comment that the countdown and antitheft modules are indeed not supported, and the cloud module IS supported; however querying this module made the bulb crash with every other query.
- So while the cloud module is_supported, it's interrogation seems to cause instability in the bulb.
- I was able to reduce the exclude list down to just cloud and the bulb queries stabilized
I've reduced the exclusion list to cloud and that seems to be stable now for me.
Sorry, something went wrong.
Co-authored-by: Teemu R. <tpr@iki.fi>
Codecov ReportPatch coverage: 100.00% and project coverage change: +0.15 🎉
❗ Your organization is not using the GitHub App Integration. As a result you may experience degraded service beginning May 15th. Please install the Github App Integration for your organization. Read more. Additional details and impacted files@@ Coverage Diff @@
## master #451 +/- ##
==========================================
+ Coverage 79.17% 79.32% +0.15%
==========================================
Files 25 25
Lines 1930 1935 +5
Branches 597 598 +1
==========================================
+ Hits 1528 1535 +7
+ Misses 361 359 -2
Partials 41 41
... and 1 file with indirect coverage changes ☔ View full report in Codecov by Sentry. |
Sorry, something went wrong.
rytilahti
left a comment
There was a problem hiding this comment.
LGTM, thanks @brianthedavis! 👍
Sorry, something went wrong.
…ython-kasa#451) * commented out modules that break * added exclusion logic to smartdevice.py * cleaning up a name * removing test fixture that isn't related to this PR * incorporating PR feedback * fixed an if statement * reduced exclusion list to just 'cloud' * Tidy up the issue comment Co-authored-by: Teemu R. <tpr@iki.fi> * this seems to be what the linter whats --------- Co-authored-by: Teemu R. <tpr@iki.fi>
…ython-kasa#451) * commented out modules that break * added exclusion logic to smartdevice.py * cleaning up a name * removing test fixture that isn't related to this PR * incorporating PR feedback * fixed an if statement * reduced exclusion list to just 'cloud' * Tidy up the issue comment Co-authored-by: Teemu R. <tpr@iki.fi> * this seems to be what the linter whats --------- Co-authored-by: Teemu R. <tpr@iki.fi>
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 in #345. 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.
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've added in an exclusion filter into smartdevice.py to remove these modules on a model by model basis; I'm not sure if this is the "right" way to do this; I tried figuring out a more effective way to eliminate certain modules but only by model type, but we don't know enough information when the modules are added. I'm more than happy to refactor this based on any input.
I was able to successfully execute the tests against these code changes and they all passed.
Fixes #345