New TP-Link HS105 Switch Not Working

Hi all,

I just got a new TP-Link HS105 smart plug, and am having issues getting it working. As far as I can tell, the only configuration option for it is the IP address, but I am encountering some connection errors.

I am certain that the IP address is correct, and Home Assistant was able to poll the name of the plug (I named it “Case Study”), but beyond that, it seems unable to communicate with it.

Any suggestions as to what the issue could be and how I can troubleshoot further?

2017-08-09 21:47:09 WARNING (Thread-10) [homeassistant.components.switch.tplink] Could not read state for Case Study: 
2017-08-09 21:47:20 INFO (MainThread) [homeassistant.core] Bus:Handling <Event call_service[L]: service_data=entity_id=switch.case_study, service_call_id=3047515504-6, domain=homeassistant, service=turn_off>
2017-08-09 21:47:20 INFO (MainThread) [homeassistant.core] Bus:Handling <Event call_service[L]: service_data=entity_id=['switch.case_study'], service_call_id=3047515504-7, domain=switch, service=turn_off>
2017-08-09 21:47:25 ERROR (MainThread) [homeassistant.core] Error doing job: Task exception was never retrieved
Traceback (most recent call last):
  File "/root/.homeassistant/deps/lib/python3.4/site-packages/pyHS100/pyHS100.py", line 71, in _query_helper
    request={target: {cmd: arg}}
  File "/root/.homeassistant/deps/lib/python3.4/site-packages/pyHS100/protocol.py", line 47, in query
    sock.connect((host, port))
socket.timeout: timed out

The above exception was the direct cause of the following exception:

Traceback (most recent call last):
  File "/usr/lib/python3.4/asyncio/tasks.py", line 233, in _step
    result = coro.throw(exc)
  File "/usr/local/lib/python3.4/dist-packages/homeassistant/core.py", line 1025, in _event_to_service_call
    yield from service_handler.func(service_call)
  File "/usr/local/lib/python3.4/dist-packages/homeassistant/components/switch/__init__.py", line 116, in async_handle_switch_service
    yield from switch.async_turn_off()
  File "/usr/lib/python3.4/asyncio/futures.py", line 388, in __iter__
    yield self  # This tells Task to wait for completion.
  File "/usr/lib/python3.4/asyncio/tasks.py", line 286, in _wakeup
    value = future.result()
  File "/usr/lib/python3.4/asyncio/futures.py", line 277, in result
    raise self._exception
  File "/usr/lib/python3.4/concurrent/futures/thread.py", line 54, in run
    result = self.fn(*self.args, **self.kwargs)
  File "/usr/local/lib/python3.4/dist-packages/homeassistant/components/switch/tplink.py", line 77, in turn_off
    self.smartplug.turn_off()
  File "/root/.homeassistant/deps/lib/python3.4/site-packages/pyHS100/pyHS100.py", line 732, in turn_off
    self._query_helper("system", "set_relay_state", {"state": 0})
  File "/root/.homeassistant/deps/lib/python3.4/site-packages/pyHS100/pyHS100.py", line 74, in _query_helper
    raise_from(SmartPlugException(), ex)
  File "/root/.homeassistant/deps/lib/python3.4/site-packages/future/utils/__init__.py", line 398, in raise_from
    exec(execstr, myglobals, mylocals)
  File "<string>", line 1, in <module>
pyHS100.pyHS100.SmartPlugException

Thanks!

I am very interested in your outcome as I am looking to pick up some of the tplink wifi products. From the log it seems the HS105 is timing out. First, ensure the HS105 has a static IP. Then head over github and get the tplink-smartplug script to do some testing. Also, great reading here on the inner working of the tplink wifi products.

I’m confident that the IP is correct.

Interestingly, I restarted HomeAssistant for something else, and while monitoring the logs I noticed that the smartplug connected! So, I tried to toggle it to Off, and that worked. But immediately after that, it began timing out and throwing exceptions again. So, now it’s worked once but then broke itself.

Any update on the HS105? Have you tried using the tplink script to test switch?

After a bit of testing, I found that it’s actually the WiFi connection of the HS105 that is unreliable.

--- 10.65.0.2 ping statistics ---
140 packets transmitted, 44 received, 68% packet loss, time 141636ms
rtt min/avg/max/mdev = 3.004/2656.020/14393.725/4293.681 ms, pipe 15

There is no discernible reason for this, when I was testing it initially I had it in the same room with a Sensi smart thermostat and a Ubiquiti mFi mPower device, and this is the only device experiencing intermittent connectivity, and I mean very intermittent. There is no situation where 68% packet loss would be acceptable.

I moved the device very near to my access point, and it’s just as bad there. I changed WiFi channels just for the hell of it, even though my other devices are having no problems, but I saw no improvement at all. I also tried changing from 40MHz to 20MHz channel width, to no effect.

The device undergoes huge periods of disconnection, followed by massive latency spikes.

64 bytes from 10.65.0.2: icmp_seq=32 ttl=64 time=6.18 ms
64 bytes from 10.65.0.2: icmp_seq=33 ttl=64 time=7.75 ms
64 bytes from 10.65.0.2: icmp_seq=70 ttl=64 time=14393 ms
64 bytes from 10.65.0.2: icmp_seq=71 ttl=64 time=13375 ms
64 bytes from 10.65.0.2: icmp_seq=72 ttl=64 time=12351 ms
64 bytes from 10.65.0.2: icmp_seq=73 ttl=64 time=11329 ms
64 bytes from 10.65.0.2: icmp_seq=74 ttl=64 time=10305 ms
64 bytes from 10.65.0.2: icmp_seq=75 ttl=64 time=9281 ms
64 bytes from 10.65.0.2: icmp_seq=76 ttl=64 time=8257 ms
64 bytes from 10.65.0.2: icmp_seq=77 ttl=64 time=7233 ms
64 bytes from 10.65.0.2: icmp_seq=78 ttl=64 time=6209 ms
64 bytes from 10.65.0.2: icmp_seq=79 ttl=64 time=5185 ms
64 bytes from 10.65.0.2: icmp_seq=85 ttl=64 time=5.57 ms

I’ll emphasize again that this is the only device on my network experiencing this, and other devices are much farther away from the access point.

At this point I’m about ready to return this device to Amazon and buy something else.

1 Like

As some “evidence” that my wireless is not the problem, here is a comparable ping test to the Ubiquiti mFi mPower device on the same AP, and farther away.

PING 10.65.0.1 (10.65.0.1) 56(84) bytes of data.
64 bytes from 10.65.0.1: icmp_seq=1 ttl=64 time=5.51 ms
64 bytes from 10.65.0.1: icmp_seq=2 ttl=64 time=8.90 ms
64 bytes from 10.65.0.1: icmp_seq=3 ttl=64 time=9.00 ms
64 bytes from 10.65.0.1: icmp_seq=4 ttl=64 time=7.33 ms
64 bytes from 10.65.0.1: icmp_seq=5 ttl=64 time=11.2 ms
64 bytes from 10.65.0.1: icmp_seq=6 ttl=64 time=6.82 ms
64 bytes from 10.65.0.1: icmp_seq=7 ttl=64 time=7.46 ms
64 bytes from 10.65.0.1: icmp_seq=8 ttl=64 time=6.42 ms
64 bytes from 10.65.0.1: icmp_seq=9 ttl=64 time=8.41 ms
64 bytes from 10.65.0.1: icmp_seq=10 ttl=64 time=7.48 ms
64 bytes from 10.65.0.1: icmp_seq=11 ttl=64 time=11.4 ms
64 bytes from 10.65.0.1: icmp_seq=12 ttl=64 time=7.49 ms
64 bytes from 10.65.0.1: icmp_seq=13 ttl=64 time=6.61 ms
64 bytes from 10.65.0.1: icmp_seq=14 ttl=64 time=7.59 ms
64 bytes from 10.65.0.1: icmp_seq=15 ttl=64 time=11.1 ms
64 bytes from 10.65.0.1: icmp_seq=16 ttl=64 time=8.24 ms
64 bytes from 10.65.0.1: icmp_seq=17 ttl=64 time=3.36 ms
64 bytes from 10.65.0.1: icmp_seq=18 ttl=64 time=6.69 ms
64 bytes from 10.65.0.1: icmp_seq=19 ttl=64 time=6.59 ms
64 bytes from 10.65.0.1: icmp_seq=20 ttl=64 time=7.04 ms
64 bytes from 10.65.0.1: icmp_seq=21 ttl=64 time=3.18 ms
64 bytes from 10.65.0.1: icmp_seq=22 ttl=64 time=8.71 ms
64 bytes from 10.65.0.1: icmp_seq=23 ttl=64 time=6.51 ms
64 bytes from 10.65.0.1: icmp_seq=24 ttl=64 time=7.49 ms
64 bytes from 10.65.0.1: icmp_seq=25 ttl=64 time=10.9 ms
^C
--- 10.65.0.1 ping statistics ---
25 packets transmitted, 25 received, 0% packet loss, time 24037ms
rtt min/avg/max/mdev = 3.186/7.669/11.441/2.059 ms

Thanks for the info. This will definitely influence my purchasing decisions.

I had a tp-105 and connected it. I can reliably turn the unit on and off but get errors while trying to fetch the status of the device

Could not read state for 192.168.1.230: Communication error

The ping times are good from the hass.io server. Is it possible to install wireshark on the RPi?