-
-
Notifications
You must be signed in to change notification settings - Fork 227
Do not do update() in discover_single #542
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Conversation
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## master #542 +/- ##
==========================================
+ Coverage 81.63% 81.74% +0.11%
==========================================
Files 28 28
Lines 2417 2421 +4
Branches 683 685 +2
==========================================
+ Hits 1973 1979 +6
+ Misses 383 382 -1
+ Partials 61 60 -1 ☔ View full report in Codecov by Sentry. |
@bdraco friendly ping to keep you in the loop. |
I'm not sure we can take the device update out without breaking the power strips, unless we pass the device type in. As soon as I get home, I'll review this and tested, as you may already be doing that and I just can't see it on my mobile. |
All the child plugs show as unavailable without the update |
diff --git a/kasa/discover.py b/kasa/discover.py
index 9883ad2..2ce408d 100755
--- a/kasa/discover.py
+++ b/kasa/discover.py
@@ -326,6 +326,11 @@ class Discover:
if ip in protocol.discovered_devices:
dev = protocol.discovered_devices[ip]
dev.host = host
+ # If the device has children we have
+ # to update the device since we will
+ # otherwise have missing children
+ if dev.sys_info.get("child_num"):
+ await dev.update()
return dev
elif ip in protocol.unsupported_devices:
raise UnsupportedDeviceException( This fixes the powerstrips. It would be better to abstract this as a property in the smart device object |
The power strips are really poorly responsive since we switch to the 5s interval because it updates all the children every time one is switched |
Actually that one is on the same subnet 😢 |
The device sets up fine if I change the timeout to 10
|
I fixed the power strips being overloaded with too many requests in home-assistant/core#103668 |
Rather than doing it that way I've included a check to see if the type is SmartStrip. This is to future proof for klap/tuya devices that will
kwarg: |
I don't anticipate subnet related issues with UDP |
I think this will still break with any devices that have children that are not smart strips since its the children that need to be updated. I don't think there are any other devices that I have that have children though |
I couldn’t see children properties on any other device types. Do you think there are others? Maybe the smartlightstrip? |
I think only tplink can answer that, but they all have suggested change bdraco@638a9b5 |
@sdb9696 Can you fix the conflicts here? |
71ada4f
to
bdf088b
Compare
bdf088b
to
f7627fe
Compare
I will revert HA to use this and than test after dinner |
Ok that's done and includes your suggested changes for adding the |
Are there any klap devices that have children that we know of at this point? |
Not that we know of. |
I think its ok to avoid the update for the klap devices unless its otherwise needed. We can always add support for klap devices with children in a future update |
But you can't access the |
It looks like we call update_from_discover_info for klap devices as well. Does self._last_update = info not get set for these devices ? |
It's a limited set of properties, not the full sys_info list. If you try to access properties not in the limited list it will error. |
Thats annoying. Since we only support children on the power strips, maybe go back to what you had before but move it behind the has_children property and take off |
So the has_children property in smartdevice checks if it’s a lightstrip instance instead of looking at child_num? |
Its the only the power strips (DeviceType.Strip) that have children (yes the names are confusing) not the light strips (DeviceType.LightStrip) Something like this diff --git a/kasa/smartdevice.py b/kasa/smartdevice.py
index 6461f33..d019912 100755
--- a/kasa/smartdevice.py
+++ b/kasa/smartdevice.py
@@ -411,11 +411,14 @@ class SmartDevice:
sys_info = self._sys_info
return str(sys_info["model"])
- @property # type: ignore
- @requires_update
+ @property
def has_children(self) -> bool:
"""Check if the device has children devices."""
- return bool(self._sys_info.get("child_num"))
+ # Ideally we would check for the 'child_num' key in sys_info,
+ # but devices that speak klap do not populate this key via
+ # update_from_discover_info so we check for the devices
+ # we know have children instead.
+ return self.is_strip
@property # type: ignore
@requires_update |
Yes sorry, meant strip. Makes sense, will update tomorrow am. |
Ok that's done |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
LGTM thanks @sdb9696
Will push to my production and test shortly
Took a few tries, but the power strip did eventually set up so this is good to go. |
This change removes the
device.update()
call in discover_single so that the logic is consistent withdiscover()
which only uses UDP and relies solely ondevice.update_from_discover_info()
. Reasons are:device.update()
anyway so it's a duplicate call there.device.update()
calls.device.update()
should make downstream issues clearer.EDIT:
This change inadvertently reduced test coverage because by a fluke
test_discover_single()
was hitting the following path in smartdevice.py L348 when the fixture specified it didn't support emeter:So I have added a test to restore the coverage and made sure that any fixtures that have "module not support" for a module will correctly pass that back from the test framework protocol.