TP Link Dimmer switch (HS220) hardware version 2.0 not being discovered · Issue #105 · python-kasa/python-kasa · GitHub

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 = {

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.

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.

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.

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?

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}}}

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.

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)?

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'}}

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.

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

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.

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())

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.

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

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)

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?

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..

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.

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.

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?

We'd always prefer a PR :)

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

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 :-)

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.

@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 :-).

TP Link Dimmer switch (HS220) hardware version 2.0 not being discovered · Issue #105 · python-kasa/python-kasa · GitHub

Repository navigation

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

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

TP Link Dimmer switch (HS220) hardware version 2.0 not being discovered · Issue #105 · python-kasa/python-kasa · GitHub

Repository navigation

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

Description

Activity

rytilahti commented on Sep 30, 2020

adamurban commented on Oct 4, 2020

rytilahti commented on Oct 4, 2020

appleguru commented on Oct 8, 2020

appleguru commented on Oct 8, 2020

appleguru commented on Oct 8, 2020

rytilahti commented on Oct 8, 2020

appleguru commented on Oct 9, 2020

appleguru commented on Oct 9, 2020

appleguru commented on Oct 9, 2020

lovell88 commented on Oct 14, 2020

adamurban commented on Oct 14, 2020

lovell88 commented on Oct 14, 2020

rcblackwell commented on Oct 14, 2020

adamurban commented on Oct 14, 2020

rcblackwell commented on Oct 15, 2020

adamurban commented on Oct 16, 2020

rcblackwell commented on Oct 16, 2020

bmbouter commented on Oct 28, 2020

Belval commented on Nov 6, 2020

kirichkov commented on Nov 6, 2020

rytilahti commented on Nov 6, 2020

Belval commented on Nov 7, 2020

rytilahti commented on Nov 7, 2020

Metadata

Metadata

Assignees

Labels

Type

Projects

Milestone

Relationships

Development

Issue actions