TP-Link Smart Home Devices does not show unavailable after home assistant restart 0.89.1

[sungla55guy]

After restarting hassio 0.89.1 if device is not connected it will not show up in the entity states but will be missing completely. This causes an issue with my automatons because I have one bulb on a switch and when this bulb comes back online it signals for the others to come on as well.

[marc-gist]

unfortunately the tplink component appears to be in its early stages, not sure why it was pushed into "production". A solution would be to setup manual, however, there is little control/options to do so. see docs on how to setup via tplink: and hosts: directives.

[xnaron]

I agree. The component is really flakey. It wasn't ready for release. Mine are setup manually. If a device is unavailable or temporarily drops from the network it will not show up in home assistant again. The previous component worked flawlessly.

[evisser4]

I am having the same on 0.91.3 & 0.91.4. I can't get my tp link lights/switches to load at all as of about a week ago.

[MrPaulAR]

Adding a me too. It's just my TPlink lights that don't work however. My single TPLink switch works fine. For what it's worth this is running within docker.

[THespos]

Me, too. Three or four deletions of the config are necessary to pick up my 10 switches. And I’ll randomly lose one or two eventually and need to reconfig again within a couple days.

[coolguymatt]

Instead of deleting the integration, I generally need to restart HA 3-4 times before all my devices appear as usable.

[prologic]

Having the same problem too. I reconfigured to manual configuration for now:

configuration.yaml:

tplink:
  discovery: false
  switch:
    - host: 10.0.0.161

And set a DHCP reservation of all my TP-Link devices. I'm not sure why the TP-Link devices become unavailable after some time as I can't see anything at all in the logs anywhere.

[evisser4]

@prologic I can confirm that your fixes worked for me as well. Something must be up with auto discovery.

[rytilahti]

My post here is related: #22313 (comment) - the problem with devices not being available during the homeassistant startup / configuration of integration will obviously leave them undetected as the discovery process is only done during the homeassistant's startup and/or when the integration gets configured via the UI. I hope some core developer (@home-assistant/core) will chime in on how this should be fixed properly, an obvious solution could be to have a way to re-trigger the discovery process again.

edit: to add, it seems weird that multiple restarts are required to get the detected (assuming they are all online and accessible). Maybe there is a problem with your network and/or the devices are not responding in that three second timeout the discovery uses per default. You could try to change the discover() call in https://github.com/home-assistant/home-assistant/blob/dev/homeassistant/components/tplink/__init__.py#L42 to be discover(timeout=10) give it 10 seconds to collect responses (it defaults to 3 seconds: https://github.com/GadgetReactor/pyHS100/blob/master/pyHS100/discover.py#L17).

[prologic]

Dumb question; But why would we perform discovery only on startup? It this generally true of other components too?

[MrPaulAR]

This is how my configuration.yaml has been configured since the change in syntax.

tplink:
  # discovery: true
  light:
    - host: 192.168.86.197
      # name: "Pantry Light"
    - host: 192.168.86.198
      # name: "Media Closet Light"
  switch:
    - host: 192.168.86.201
      # name: "Smoker Plug"

The switch works 100% of the time. All 3 devices are sticky DHCP assignments in the router. The 3 devices work properly in the TP-Link app. I've tried manually setting discovery to false and true to see if anything changes but no luck on the 2 switches.

Also, I'm currently running 0.92.2 within docker.

[rytilahti]

#23668 is a potential fix.

[scubanarc]

You could try to change the discover() call in https://github.com/home-assistant/home-assistant/blob/dev/homeassistant/components/tplink/__init__.py#L42 to be discover(timeout=10) give it 10 seconds to collect responses (it defaults to 3 seconds: https://github.com/GadgetReactor/pyHS100/blob/master/pyHS100/discover.py#L17).

I tried this and it did not seem to help. I suspect that the first discovery packet is missed by the device because the network coverage is spotty, and then discover() never sends another packet.

Part of the total solution might need to include attempting discovery more than once and combining the results. I'd like to be able to run discovery from the UI.

[rytilahti]

That's a fair point, you could try to modify https://github.com/GadgetReactor/pyHS100/blob/master/pyHS100/discover.py#L45 to be:

for i in range(3):
    sock.sendto(encrypted_req[4:], (target, port))

to see if it helps. That will simply send the discovery packet three times and wait for the answers.

To be able to run the discovery from the UI is another matter and not related to this, but you can create another issue to see how other developers feel about it.

[scubanarc]

That's a fair point, you could try to modify https://github.com/GadgetReactor/pyHS100/blob/master/pyHS100/discover.py#L45 to be:

for i in range(3):
    sock.sendto(encrypted_req[4:], (target, port))

to see if it helps. That will simply send the discovery packet three times and wait for the answers.

This is a great suggestion, and it seems to have helped in my case.

I have noticed that pinging the difficult devices before running discovery helps as well. Usually the first ping has a long delay and then the rest of them are normal. The long delay probably affects discovery.

Between increasing the discovery wait time to 10 seconds and sending the packet 3 times my detection rate has significantly improved.

[rytilahti]

Glad to hear it helped! I did prepare a PR to make the number of requests configurable.

[HappyVampireSoft]

I'm having the same kind of issues. I have 8 tplink smart plugs. If I delete the TPLink integration and re-add it it finds random plugs out of my 8, sometimes just a couple. I get various random errors in my logs indicating communication errors, variable and object errors, etc. I have added all plugs manually in my config with static IPs and now they are all in the integration UI but still some are unavailable and if I restart then it's random which ones are available after the restart. I have not successfully had all 8 active at the same time.

If I unplug one, it becomes unavailable and will not become available again.

Also, autodiscovery should certainly not only work during adding of the integration. I plugged some new sonoma plugs in yesterday and within seconds they were discovered and added. If I unplug one and plug it back in that works correctly also. We need this to work the same way.

We need to have ongoing discovery without deleting and adding the integration, and we need to have it try to find a plug that becomes unavailable and then becomes available again.

Honestly, my TPlink plugs are basically unusable right now.

I'm new to HA and I really like it, having moved from HCA to Openhab ,and now to HA. I'm not familiar enough to try and contribute to code yet, like I did with HCA and Openhab, but I'll get there. It takes time.

[frankletank]

Please update to at least 93, I'm on 94.2 and tplink entity work like a charm to me. I've 7 units and got the same issues as you on prior 93.0 (from memory). Are you updated to the lastest version?

[rytilahti]

#23668 should fix the issue you are describing, and it should be in 0.94 (even when not shown in the changelog, sorry, my bad). All credit goes to @vangorra for fixing this. If the issue still remains with 0.94+, please reopen this.

[bschatzow]

I have this problem on . 993. I have 6 devices all are set with static IPs and discovery false. 3 are unavailable. All are seen by the Kasa app.

[marc-gist]

I have this problem on . 993. I have 6 devices all are set with static IPs and discovery false. 3 are unavailable. All are seen by the Kasa app.

How long as it been like that? can you ping from your HA machine to the TPLink device?
I still get random unavailable using TP-Link switches in HA, but usually corrects itself in a few minutes... overall works fine. what can take time are state updates (as HA does polling of the device for status, rather than receive a message when the state changes).

[bschatzow]

Problem since update. Did .100 update last night and all working again.

[bschatzow]

Problem is back this morning. Three of the six devices not available. All can be pinged and all seen by kasa.

[vangorra]

Will you set the log level for tplink to debug and upload what you have when the issue occurs?

…

-------- Original Message --------

On Oct 12, 2019, 3:57 AM, bschatzow wrote: Problem is back this morning. Three of the six devices not available. All can be pinged and all seen by kasa. — You are receiving this because you were mentioned. Reply to this email directly, [view it on GitHub](#21966), or [unsubscribe](https://github.com/notifications/unsubscribe-auth/AANL2MVZVKKFBSVCM4CLMOLQOGURHANCNFSM4G5KV7HA).

[bschatzow]

All working again with the latest release.

[bschatzow]

Just did the latest update .101.0 and lost one of the switches. All are static called out in router, all are in my custom yaml
discovery: false
switch:
- host: 192.168.1.45
- host: 192.168.1.47
- host: 192.168.1.50
- host: 192.168.1.51
- host: 192.168.1.52
- host: 192.168.1.53
Integration is missing .47. It stopped working in hassio, but is reachable by Kasa and ping. Tried deleting all and re adding still missing. Any ideas?

[rytilahti]

Please open a new issue with details to avoid sending notifications on all of those who participated in this (already fixed) issue.