Core: TP Link Dimmer switch (HS220) hardware version 2.0 not being discovered

[hursey013]

The problem

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

Environment

• Home Assistant Core release with the issue: 0.114.4
• Last working Home Assistant Core release (if known):
• Operating environment (OS/Container/Supervised/Core): Docker
• Integration causing this issue: TP Link
• Link to integration documentation on our website: https://www.home-assistant.io/integrations/tplink/

Problem-relevant configuration.yaml

Traceback/Error logs

Additional information

Related issue: https://github.com/plasticrake/homebridge-tplink-smarthome/issues/131

[rytilahti]

Can you check out if it is working with python-kasa? Looking at the related issue, this could be an issue related to payload sizes.

[tycm]

Also having the same issue, But it is discovered when adding it to the config manually via IP. I am not able to control the switch though. When searching for the switch with python-kasa using kasa discover The HS220 does not appear, only the other kasa-smart items on my network. When trying to control the switch via kasa --host $IP on the command runs indefinitely.

2020-09-11 16:56:04 ERROR (SyncWorker_4) [homeassistant.components.octoprint] Endpoint: printer Failed to update OctoPrint status. Error: 409 Client Error: CONFLICT for url: http://octopi.mccrickard.us:80/api/printer 2020-09-11 16:56:17 WARNING (MainThread) [homeassistant.components.light] Setup of light platform tplink is taking over 10 seconds. 2020-09-11 16:57:07 ERROR (MainThread) [homeassistant.components.light] Setup of platform tplink is taking longer than 60 seconds. Startup will proceed without waiting any longer.

[appleguru]

Just installed 9 of these 2.0 dimmers so far and am having the same issues. Do we have a workaround/fix yet?

(Also, looks like HA is still using an old version of pyHS100? "requirements": ["pyHS100==0.3.5.1"], should probably upgrade it to python-kasa, but from the comments above it's not clear that will help)

[appleguru]

Ok, I found a workaround that seems to work. Am running the HaasOS image, so had to modify the file in the docker container:

docker exec -it homeassistant vi /usr/local/lib/python3.8/site-packages/pyHS100/discover.py

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 rebooted everything. Now all of my new dimmers show up and are controllable.

[rytilahti]

Could you please create an issue to python-kasa project so that won't be forgotten? Looks like HS220 does not like when multiple modules being requested, so the discovery process should be adapted accordingly.

[adamurban]

Captured here: https://github.com/python-kasa/python-kasa/issues/105

I don't have a good dev environment for python-kasa atm (can't get it to run correctly on my mac), but at least we can track it there. If a get a different system to test on I'll fill out that story some more.

Is there a plan and/or timeline to move HA to python-kasa from pyHS100?

[mstarks01]

Ok, I found a workaround that seems to work. Am running the HaasOS image, so had to modify the file in the docker container:

docker exec -it homeassistant vi /usr/local/lib/python3.8/site-packages/pyHS100/discover.py

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 rebooted everything. Now all of my new dimmers show up and are controllable.

Thanks, this worked for me. Just as a note to others: I did not need to reboot.

[jpuderer]

This works great for me too, but what can be done about it in the medium/long term?

pyHS100 is no longer being maintained, and there are no tickets to upgrade to python-kasa (#35137 was recently closed).

It’s an issue in python-kasa, but it looks like it will be addressed soon:
python-kasa/issues/105

Could we override it inside the tplink component by adding the following right after the imports in common.py?

Discover.DISCOVERY_QUERY = {"system": {"get_sysinfo": None}}

[adamurban]

This works great for me too, but what can be done about it in the medium/long term?

pyHS100 is no longer being maintained, and there are no tickets to upgrade to python-kasa (#35137 was recently closed).

It’s an issue in python-kasa, but it looks like it will be addressed soon:
python-kasa/issues/105

Could we override it inside the tplink component by adding the following right after the imports in common.py?

Discover.DISCOVERY_QUERY = {"system": {"get_sysinfo": None}}

The “right” way to fix it is downstream; once we get it working in python-kasa, we can update the pyHS100 module to python-kasa and update the integration accordingly.

The biggest downside to my “hot fix” is that you have to apply it after every update. Perhaps could persistently fix it with a custom component in a way similar to what you’re describing while we wait/work to get the downstream code fixed... feel free to give it a shot and report your findings!

[JediMindFrak]

Thank you! I've been messing around trying to get this working for a week and now my dimmer switch is up and running! Hopefully the proper fix will come soon.

[MichaelSprague]

Unfortunately this did not resolve my issue with HS220 showing as Unavailable.

class Discover: DISCOVERY_QUERY = {"system": {"get_sysinfo": None}}

Do you have the HS220s set up as a "light" in your configuration, as is called out on the integration page?
After making the change to discovery.py, I am still getting this error in my log:
Could not read data for 192.168.12.14: Error on smartlife.iot.common.emeter.get_daystat: {'err_code': -1, 'err_msg': 'module not support'}
I'm running HA 0.116.4 on HassOS 4.14.

Update: I changed the HS220 to a "dimmer" and it looks like it is up and running now. I guess I misinterpreted the integration page.

[bmbouter]

I also experienced this issue, and I applied the fix and it worked for me too.

Am I understanding correctly that the next step is to fix this issue in python-kasa and then switch the tplink component to use it?

[rytilahti]

@bmbouter correct, that's the plan to fix this.

The short term plan is to have a custom component to make it easy to test the python-kasa-based integration without disrupting the existing integration and installations. Going the custom component route will allow using both integrations at the same time, which I hope makes it easy to verify that everything is good to go before (the long term) inclusion back to the core.

[appleguru]

@rytilahti Can we (instead of a custom component) make a change to pyHS100 to remove the emeter part of the discover query as a stop gap solution until we have it fixed in python-kasa and have the kasa HA integration migrated over to using python-kasa instead of pyHS100 (which could take months?). Any downsides to this approach (given that pyHS100 is EOL already anyways?)

[bmbouter]

@appleguru I was thinking the same thing, Releasing a forked version of pyHS100 with this patch is easy enough, and switching the component to use it is also easy. I could do that if that's helpful.

@rytilahti I have the same question @appleguru asks: what are the downsides to this approach? Should I open PRs for this?

[rytilahti]

@appleguru @bmbouter if the only change necessary is to remove that part from the query (and it doesn't break any other functionality), feel free to create a PR on pyhs100 and I can prepare a bug fix release with only that fix included.

[bmbouter]

@rytilahti Great thank you! Here's a PR against the same version the tplink component uses (0.3.5.1) https://github.com/GadgetReactor/pyHS100/pull/197

[rytilahti]

Thanks for the PR @bmbouter! A new release is out and I created a PR to bump the version, too. I really hope this will be the very, very last pyhs100 release we will ever have :-)