8000 TP Link Dimmer switch (HS220) hardware version 2.0 not being discovered · Issue #105 · python-kasa/python-kasa · GitHub
[go: up one dir, main page]
Skip to content

TP Link Dimmer switch (HS220) hardware version 2.0 not being discovered #105

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.

Sign up for GitHub

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

Jump to bottom
Closed
adamurban opened this issue Sep 23, 2020 · 24 comments · Fixed by #147
Closed

TP Link Dimmer switch (HS220) hardware version 2.0 not being discovered #105

adamurban opened this issue Sep 23, 2020 · 24 comments · Fixed by #147

Comments

@adamurban
Copy link
adamurban commented Sep 23, 2020 •
edited
Loading

TP Link Dimmer switch (HS220) hardware version 2.0 not being discovered. All other TP Link switches, bulbs, and plugs are successfully discovered.

Relates to home-assistant/core#39395

While I don't currently have a good environment to test python-kasa in currently, I was able to fix this on home assistant by manually editing the old pyHS100/discover.py that it uses.

Specifically, I changed
class Discover: DISCOVERY_QUERY = {"system": {"get_sysinfo": None}, "emeter": {"get_realtime": None}}
to
class Discover: DISCOVERY_QUERY = {"system": {"get_sysinfo": None}}

and then was able to successfully discover and use the version 2.0 dimmers.

I suspect a similar modification to python-kasa's discover.py will fix it here too:

python-kasa/kasa/discover.py

Line 138 in c59b748

DISCOVERY_QUERY = {

@adamurban adamurban mentioned this issue Sep 23, 2020
Closed
@rytilahti
Copy link
Member

This needs some investigation for the best approach. The library currently uses "smartlife.iot.dimmer": {"get_dimmer_parameters": None}, response to detect the HS220, so I assume this was working properly at some point.

@adamurban
Copy link
Author

The HS220 2.0 hardware is relatively new / was launched in July from what I can tell. Previous HW versions still seem to work ok with the current code, but the new HW/FW does not.

I got the library up and running on Ubuntu if there are any tests I can run/help with. Can also grab packet captures/etc if helpful.

@rytilahti
Copy link
Member

Could you modify the discovery request manually only to contain the sysinfo request and create a PR to add the devinfo file (kasa dump-discover) to the test suite?

The dev_name is probably the field we can use for discovery process instead of checking for the availability of the dimmer service.

@appleguru
Copy link
Contributor

Oddly, when I make that change discovery just seems to hang. It works fine in the older pyHS100 version running on HA, but that doesn't seem to have a dump-discover command? Perhaps I can take the debug output from pyHS100 and manually build the devinfo file?

@appleguru
Copy link
Contributor

Turning --debug on, discovery works ok and sees all the devices with the modified string, but I see it hanging on:

DEBUG:kasa.protocol:Unable to query the device, retrying: unpack requires a buffer of 4 bytes DEBUG:kasa.protocol:> (144) {"system": {"get_sysinfo": null}, "emeter": {"get_realtime": null, "get_monthstat": {"year": 2020}, "get_daystat": {"month": 10, "year": 2020}}}

@appleguru appleguru mentioned this issue Oct 8, 2020
Merged
@appleguru
Copy link
Contributor

PR submitted. Please review as I pieced together this fixture from the debug output, as I was not able to ever get it to save from kasa dump-discover

Can share the raw debug logs via a non-public channel if helpful.

@rytilahti
Copy link
Member
rytilahti commented Oct 8, 2020 •
edited
Loading

Hmm, looking at the file, it still has all those services available? Which parts did you "glue" manually to it? I have seen some devices not being always responsive to the discovery requests, maybe this hw 2.0 is such? Can you please do repeat the discovery multiple times to see if it works sometimes (without the query modification)?

@appleguru
Copy link
Contributor
appleguru commented Oct 9, 2020 •
edited by rytilahti
Loading

I built it from the debug output, which looked like this:

DEBUG:kasa.discover:[DISCOVERY] 10.0.0.150 << {'system': {'get_sysinfo': {'sw_ver': '1.0.3 Build 200326 Rel.082355', 'hw_ver': '2.0', 'model': 'HS220(US)', 'deviceId': '0000000000000000000000000000000000000000', 'oemId': '00000000000000000000000000000000', 'hwId': '00000000000000000000000000000000', 'rssi': -45, 'latitude_i': 1234, 'longitude_i': -1234, 'alias': 'Living Room Lights, 'mic_type': 'IOT.SMARTPLUGSWITCH', 'feature': 'TIM', 'mac': '00:00:00:00:00:00', 'updating': 0, 'led_off': 0, 'relay_state': 0, 'brightness': 100, 'on_time': 0, 'icon_hash': '', 'dev_name': 'Wi-Fi Smart Dimmer', 'active_mode': 'none', 'next_action': {'type': -1}, 'preferred_state': [{'index': 0, 'brightness': 100}, {'index': 1, 'brightness': 75}, {'index': 2, 'brightness': 50}, {'index': 3, 'brightness': 25}], 'err_code': 0}}, 'smartlife.iot.dimmer': {'get_dimmer_parameters': {'fadeOnTime': 1000, 'fadeOffTime': 1000, 'gentleOnTime': 3000, 'gentleOffTime': 10000, 'rampRate': 30, 'minThreshold': 0, 'err_code': 0}}, 'smartlife.iot.common.emeter': {'err_code': -1, 'err_msg': 'module not support'}, 'smartlife.iot.smartbulb.lightingservice': {'err_code': -1, 'err_msg': 'module not support'}}

@appleguru
Copy link
Contributor

Discovery works 100% of the time with the query modification (though the CLI tool hangs; likely a separate issue). Without the query mod, they don't ever discover from what I've seen so far.

@appleguru
Copy link
Contributor
appleguru commented Oct 9, 2020 •
edited
Loading

This is the culprit for why discovery was hanging even with the modified discovery string:

python-kasa/kasa/smartdevice.py

Line 302 in c59b748

req.update(self._create_emeter_request())

The emeter requests are what the v2.0 hw/fw don't like, so the logic to " # Check for emeter if we were never updated, or if the device has emeter" fails.

If I replace the line above with a pass, I successfully generate the device profiles. Updating PR with the "real" profile now:

2538a79

@lovell88
Copy link

Appleguru, can you explain how you're implementing the fix? I am not very familiar with Python. To at least try something, I tried to comment out lines 301 and 302 and that didn't change anything.

Unfortunately, I am a little desperate trying to get the led indicator off on a v2 hs220 as it is waking up my children at night. Any help would be greatly appreciated.

@adamurban
Copy link
Author

Appleguru, can you explain how you're implementing the fix? I am not very familiar with Python. To at least try something, I tried to comment out lines 301 and 302 and that didn't change anything.

Unfortunately, I am a little desperate trying to get the led indicator off on a v2 hs220 as it is waking up my children at night. Any help would be greatly appreciated.

Try commenting out this line:

python-kasa/kasa/discover.py

Line 140 in c59b748

"emeter": {"get_realtime": None},

And then replace this line with “pass”:

python-kasa/kasa/smartdevice.py

Line 302 in c59b748

req.update(self._create_emeter_request())

@lovell88
Copy link

Adam, thank you so much. The line on discover.py was on 134, not 140, but other than that, that worked great. Now the wife is happy and I am happy.

@rcblackwell
Copy link
rcblackwell commented Oct 14, 2020 •
edited
Loading

This is the culprit for why discovery was hanging even with the modified discovery string:

python-kasa/kasa/smartdevice.py

Line 302 in c59b748

req.update(self._create_emeter_request())

The emeter requests are what the v2.0 hw/fw don't like, so the logic to " # Check for emeter if we were never updated, or if the device has emeter" fails.

If I replace the line above with a pass, I successfully generate the device profiles. Updating PR with the "real" profile now:

2538a79

I have a number of TPLink dimmers which are not being discovered automatically. I'd like to utilize this updated integration but, being new to HA, I don't know how to install. Is there a timeline on inclusion of this update with stable versions of HA? If not, where would I find instruction on how to add the revised integration to HA?

Regards
Robert

@adamurban
Copy link
Author

This is the culprit for why discovery was hanging even with the modified discovery string:

python-kasa/kasa/smartdevice.py

Line 302 in c59b748

req.update(self._create_emeter_request())

The emeter requests are what the v2.0 hw/fw don't like, so the logic to " # Check for emeter if we were never updated, or if the device has emeter" fails.
If I replace the line above with a pass, I successfully generate the device profiles. Updating PR with the "real" profile now:
2538a79

I have a number of TPLink dimmers which are not being discovered automatically. I'd like to utilize this updated integration but, being new to HA, I don't know how to install. Is there a timeline on inclusion of this update with stable versions of HA? If not, where would I find instruction on how to add the revised integration to HA?

Regards
Robert

If you're running a "managed" HA system (You have a "Supervisor" tab), you can follow my instructions here to apply this fix to HA: home-assistant/core#39395 (comment)

@rcblackwell
Copy link

If you're running a "managed" HA system (You have a "Supervisor" tab)

I'm running HassOS 5.3 on a RPi. I see the supervisory tab but don't know which tool to use to execute the commands. I tried issuing the commands noted in the solution from a terminal window (SSH & Term add-on) but received an error.

I'm new to Linux and HA, thus my knowledge in these areas is somewhat limited. What tips could you offer that might point me in the right direction?

@adamurban
Copy link
Author

If you're running a "managed" HA system (You have a "Supervisor" tab)

I'm running HassOS 5.3 on a RPi. I see the supervisory tab but don't know which tool to use to execute the commands. I tried issuing the commands noted in the solution from a terminal window (SSH & Term add-on) but received an error.

I'm new to Linux and HA, thus my knowledge in these areas is somewhat limited. What tips could you offer that might point me in the right direction?

What error did you receive? If you're using the Terminal add on, make sure you Disable "protection mode" so that you can actually run useful commands..

@rcblackwell
Copy link
rcblackwell commented Oct 16, 2020 •
edited
Loading

make sure you Disable "protection mode"

That was it! I disabled "protection mode" made the change and rebooted. Now all devices are discovered.

Thank you for the tip.

@bmbouter
Copy link

What can I do to help with this issue? @appleguru do you know? I have an HS220 that is experiencing the issue, I can develop in Python, and I'd like to help.

@rytilahti rytilahti mentioned this issue Nov 3, 2020
Closed
@Belval
Copy link
Belval commented Nov 6, 2020

I am having an issue where HS103 switches with latest firmware are not being discovered and need to be manually configured to work.

I intended to simply open a documentation PR, but by reading this read it seems that it is fixable by tweaking the module? Would you rather get a PR for that?

@kirichkov
Copy link
Contributor

We'd always prefer a PR :)

Please don't forget to provide dumps and tests for the specific device!

@rytilahti
Copy link
Member

So I have been thinking about how to handle this neatly, but I'm not completely sure how to do it. Here a couple of thoughts:

  • We could easily modify the discovery process to use only the system.get_sysinfo as that contains enough information to make a decision about the device type. The dimmers use dev_name containing the word "Dimmer" and we can leverage other properties to do detection of other device classes based on the sysinfo responses. However, the dump-devinfo is using this query to get more information besides the sysinfo from the devices (to be used as fixtures for our unit tests), so we'd need a separate code path for the regular discovery and for data collection. This is not a big deal, but requires some code changes.
  • The second point concerns on how to handle the update procedure. The emeter query was added to the initial query to make sure that the emeter results are always available, when supported. The fix is for dimmers is straightforward: we can simply override the update() on SmartDimmer class to skip the extra emeter query. And maybe adding smartlife.iot.dimmer.get_dimmer_parameters to the query to make the settings available..
  • The last remaining question is how to deal with smartplugs when we do not know if emeter is supported (i.e., when the SmartPlug gets initialized manually)? One solution for the initial update() would be to query only the system.get_sysinfo, followed by checking its response to see if EME is listed in the features, and doing the emeter query if needed. This will increase the number of requests for the initial update from 1 to 2 on emeter enabled devices but I think it's fair as this needs only be done once during the initial update.

@Belval if you want to give it a shot, I'd be happy to do code review & help with testing :-)

@Belval
Copy link
Belval commented Nov 7, 2020 •
edited
Loading

Ok, so to modify the discovery process I added a parameter called complete=False on the discover_single function which seems to be the one used by conftest.py. The parameter is set to true, the old query dict is used instead of only get_sysinfo.

You can see those changes here: Belval@32dc52a

As for the last point, I saw that there was already an has_emeter function in SmartDevice so I simply added a check before making the query to effectively split it in two. Those changes can be seen here: Belval@e2e6627

I am still not sure about the second point though, shouldn't the current changes address it?

EDIT: I'll be waiting for your ok before opening a PR, just to make sure that I am not 100% off with what you had in mind.

@rytilahti rytilahti mentioned this issue Nov 7, 2020
Merged
@rytilahti
Copy link
Member
rytilahti commented Nov 7, 2020 •
edited
Loading

@Belval I created a PR with some existing cleanups I had done locally previously, which allow dimmer detection using only the data accessible in system.get_sysinfo call (the first step to fix the first bulletpoint).

I also added some comments to the commits you linked, please feel to create a PR (even when it's not ready yet) as they are much easier to comment on and the CI will be run automatically (which should have spotted those issues I mentioned in the comments :-).

This was referenced Nov 10, 2020
Closed
Closed
@rytilahti rytilahti mentioned this issue Nov 24, 2020
Merged
@dcmorton dcmorton mentioned this issue Dec 2, 2020
Closed
@mfalzone mfalzone mentioned this issue Dec 3, 2020
Closed
@rytilahti rytilahti mentioned this issue Feb 14, 2021
Closed
@rytilahti rytilahti mentioned this issue Mar 18, 2021
Merged
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

Successfully merging a pull request may close this issue.

Simplify discovery query, refactor dump-devinfo rytilahti/python-kasa
8 participants
@bmbouter @kirichkov @appleguru @adamurban @rytilahti @Belval @lovell88 @rcblackwell
0