TPLink Kasa HS200 Connection Refused

  • Platform information:
    • Hardware: Intel i7/16GB RAM/500GB m.2 ssd
    • OS: Win 10 Pro/22H2 64 bit
    • Java Runtime Environment: openjdk version “17.0.13” 2024-10-15 LTS
    • openHAB version: openHAB 4.3.0

Hi All,

This issue is on an existing system running with multiple Kasa HS200 devices which are working without problem. I’ve added another TPLink Kasa HS200 switch which is a newer version: hardware (ver 5.20) and firmware (ver 1.0.3). The Thing adds correctly but it never comes on-line, instead it is failing with a connection refused error. An examination of both the log file and a Wireshark capture of the nic traffic show an issue during initial handshake.

This is the Thing:

UID: tplinksmarthome:hs200:Test14
label: HS200:test14
thingTypeUID: tplinksmarthome:hs200
configuration:
  ipAddress: 192.168.0.14
  refresh: 1
channels:
  - id: switch
    channelTypeUID: system:power
    label: Power
    description: Device is operable when channel has state ON
    configuration: {}
  - id: led
    channelTypeUID: tplinksmarthome:led
    label: Switch Led
    description: Switch the Smart Home device led on or off.
    configuration: {}
  - id: rssi
    channelTypeUID: tplinksmarthome:rssi
    label: Signal
    description: Wi-Fi signal strength indicator.
    configuration: {}

Here is the logfile capture

2024-10-25 19:42:29.862 [DEBUG] [ernal.handler.TPLinkSmartHomeActions] - bundle org.openhab.binding.tplinksmarthome:4.3.0.202410250430 (266)[org.openhab.binding.tplinksmarthome.internal.handler.TPLinkSmartHomeActions(342)] : ServiceFactory.getService()
2024-10-25 19:42:29.863 [DEBUG] [ernal.handler.TPLinkSmartHomeActions] - bundle org.openhab.binding.tplinksmarthome:4.3.0.202410250430 (266)[org.openhab.binding.tplinksmarthome.internal.handler.TPLinkSmartHomeActions(342)] : This thread collected dependencies
2024-10-25 19:42:29.863 [DEBUG] [ernal.handler.TPLinkSmartHomeActions] - bundle org.openhab.binding.tplinksmarthome:4.3.0.202410250430 (266)[org.openhab.binding.tplinksmarthome.internal.handler.TPLinkSmartHomeActions(342)] : getService (ServiceFactory) dependencies collected.
2024-10-25 19:42:29.864 [DEBUG] [ernal.handler.TPLinkSmartHomeActions] - bundle org.openhab.binding.tplinksmarthome:4.3.0.202410250430 (266)[org.openhab.binding.tplinksmarthome.internal.handler.TPLinkSmartHomeActions(342)] : Querying state satisfied
2024-10-25 19:42:29.864 [DEBUG] [ernal.handler.TPLinkSmartHomeActions] - bundle org.openhab.binding.tplinksmarthome:4.3.0.202410250430 (266)[org.openhab.binding.tplinksmarthome.internal.handler.TPLinkSmartHomeActions(342)] : For dependency osgi.ds.satisfying.condition, optional: false; to bind: [[RefPair: ref: [{org.osgi.service.condition.Condition}={service.id=6, service.bundleid=0, service.scope=singleton, service.pid=0.org.osgi.service.condition.ConditionImpl, osgi.condition.id=true}] service: [null]]]
2024-10-25 19:42:29.864 [DEBUG] [ernal.handler.TPLinkSmartHomeActions] - bundle org.openhab.binding.tplinksmarthome:4.3.0.202410250430 (266)[org.openhab.binding.tplinksmarthome.internal.handler.TPLinkSmartHomeActions(342)] : Changed state from satisfied to active
2024-10-25 19:42:29.868 [DEBUG] [me.internal.handler.SmartHomeHandler] - Initializing TP-Link Smart device on ip '192.168.0.14' or deviceId 'null' 
2024-10-25 19:42:30.870 [TRACE] [me.internal.handler.SmartHomeHandler] - Update Channels for:tplinksmarthome:hs200:Test14
2024-10-25 19:42:30.870 [TRACE] [.tplinksmarthome.internal.Connection] - Executing command: {"system":{"get_sysinfo":{}}}
2024-10-25 19:42:33.940 [TRACE] [me.internal.handler.SmartHomeHandler] - Communication error, retry 1
java.net.ConnectException: Connection refused: connect
	at sun.nio.ch.Net.connect0(Native Method) ~[?:?]
	at sun.nio.ch.Net.connect(Net.java:579) ~[?:?]
	at sun.nio.ch.Net.connect(Net.java:568) ~[?:?]
	at sun.nio.ch.NioSocketImpl.connect(NioSocketImpl.java:593) ~[?:?]
	at java.net.SocksSocketImpl.connect(SocksSocketImpl.java:327) ~[?:?]
	at java.net.Socket.connect(Socket.java:639) ~[?:?]
	at java.net.Socket.connect(Socket.java:588) ~[?:?]
	at java.net.Socket.<init>(Socket.java:512) ~[?:?]
	at java.net.Socket.<init>(Socket.java:292) ~[?:?]
	at org.openhab.binding.tplinksmarthome.internal.Connection.createSocket(Connection.java:102) ~[?:?]
	at org.openhab.binding.tplinksmarthome.internal.Connection.sendCommand(Connection.java:69) ~[?:?]
	at org.openhab.binding.tplinksmarthome.internal.handler.SmartHomeHandler.refreshCache(SmartHomeHandler.java:184) ~[?:?]
	at org.openhab.core.cache.ExpiringCache.refreshValue(ExpiringCache.java:101) ~[?:?]
	at org.openhab.core.cache.ExpiringCache.getValue(ExpiringCache.java:72) ~[?:?]
	at org.openhab.binding.tplinksmarthome.internal.handler.SmartHomeHandler.lambda$3(SmartHomeHandler.java:263) ~[?:?]
	at java.lang.Iterable.forEach(Iterable.java:75) ~[?:?]
	at org.openhab.binding.tplinksmarthome.internal.handler.SmartHomeHandler.refreshChannels(SmartHomeHandler.java:263) ~[?:?]
	at java.util.concurrent.Executors$RunnableAdapter.call(Executors.java:539) [?:?]
	at java.util.concurrent.FutureTask.runAndReset(FutureTask.java:305) [?:?]
	at java.util.concurrent.ScheduledThreadPoolExecutor$ScheduledFutureTask.run(ScheduledThreadPoolExecutor.java:305) [?:?]
	at java.util.concurrent.ThreadPoolExecutor.runWorker(ThreadPoolExecutor.java:1136) [?:?]
	at java.util.concurrent.ThreadPoolExecutor$Worker.run(ThreadPoolExecutor.java:635) [?:?]
	at java.lang.Thread.run(Thread.java:840) [?:?]

It retries four times.

This is an image of a Wireshark capture which basically confirms the connection refusal. This exchange happens first:

And a few tics later this one confirms the refusal. This is repeated for each subsequent retry:

The switch does install correctly in the Kasa app and all switches are accessable from the app. I’ve tried this using the 4.2.2, 4.3.0, and 3.4.5 versions of OH with no difference. I’ve also reduced the variables and configured a test private network containing only the switches, OH server and my router. Also to no avail.

Has anyone else seen this? What am I missing something?

Perplexed,
Reg

I am having the same issue any update?

Jamie, No I haven’t. I did load an instance of Home Assistant and add these devices in the hopes of seeing if there would be a way to make a comparison of the login sequence. I am still investigating, but out of the box, HA worked with all the switches and devices I have.

Any update on this again?

Same issue here, newer HS200 won’t discover and can’t be added manually. If HA works with it then perhaps it’s a binding issue?

How do I log a PR for this issue with the TP Link binding?

Having the same issue with the HS220. I had several at my previous house and they worked without any issue, with openHAB v2.x and 4.x. I bought some new ones, before we moved in December and they all work with the Kasa and Tapo app. but will not work with OH v2.x or 4.x.

The only way I’ve been able to get them to work in OH 4.x, is by adding this Tap Control bridge and configuring it with my Kasa app. credentials.

However, when I try to add the HS220, it still doesn’t work. I keep getting a connection refused message. After doing some reading, I read some posts that talked about a new Tapo (I believe Tapo is the European equivalent of Kasa or Tapo is taking over Kasa…not sure) protocol being used that encrypts the login to the HS220, via their cloud. It’s called Secured KLAP HTTP Protocol. That option isn’t available when you select the HS220.

So, on a hunch, I tried to use one of the Tapo dimmer switch devices, ‘Recessed Lights (L610 Series White-Spot)’, which has the option to choose the KLAP HTTP protocol.

The damn thing came online! So now I can control the brightness level and on/off function of the HS220’s. I do get warning messages, saying that the MAC address for the device is incorrect, but it still works.

‘found type:‘HS220’ with mac:‘60-83-E7-XX-XX-XX’. Check IP-Address’

I read about the changes that Kasa/Tapo made, regarding shutting down the port that the OH binding used to locally access their devices and the subsequent backlash from opensource home automation users, of HA, OH, etc. Kasa/Tapo apparently then modified the firmware to give users the option to allow what they call, Third-Party access.

Unfortunately though, it still doesn’t work.

I do have several HS103 smart plugs and they work fine with OH 2.x and 4.x. I suspect though, that there will be an update for them as well, that adds the need to authenticate via their cloud, so I’m not going to update the firmware.

Hope that helps a bit. I’m at the point where I’m contemplating returning the HS220’s that I purchased before Christmas from Amazon. The return window closes on January 31st.

Well, sh1t. That worked for me as well.

  • Installed the tapo control binding and the tapo cloud login bridge with Kasa creds.
  • Created a thing manually (in this case for L510 Series White Bulb). Set IP to my new HS200 and protocol to Secured KLAP/HTTP

HS200 is now connected! Added the light-on/power item and can now control the switch via openhab. So at least there is this workaround.

Thanks again for the help. If anyone tries to modify the binding for direct access again I’m more than happy to help test.

1 Like

Glad it worked for you as well.

Clearly, Kasa/Tapo have made huge changes to the firmware. Still don’t understand why the Third-Party setting doesn’t work, either in the Kasa app. or the Tapo app. From my understanding, it’s to allow OH and HA users to access their devices directly.

The switches are also supposed to work if they don’t have access the Internet, ie., the cloud, to authenticate. They are supposed to go into ‘Local Mode’. Well, that’ doesn’t work either. I went into my router and blocked access to the Internet for the two installed HS220’s. The LED’s on the switches turn orange, which means no Internet access, but I lose all control from OH and the Kasa/Tapo apps. as well. Once I give them Internet access, they reconnect to the cloud, the LED’s turn white and they start working again.

Frustrating. Miss my WEMO’s.

Agreed. I’ve got too many kasa switches now to bother changing out unless they lock them down altogether. But thx for the tip (great catch), it keeps me going while longer on these devices :slight_smile: