[RELEASE] TP-Link Plug, Switch, and Bulb integration

Sorry to bother you with this since I just figured out the problem.

I had the devices on my guest wifi networks. I tried switching one over to my main network and it worked. I read somewhere you should keep smart home stuff on your guest network for security reasons, but I guess that doesn't work for Hubitat.

1 Like

Dave, Thanks for an excellent extension. I had the TP-Link devices before I got Hubitat and it's great to be able to still use them with the new setup. I occasionally get the UDP and CommsError warnings on a scheduled Refresh and have also gotten it in the past when sending a command. For the Refresh, it runs again at the next scheduled time but for a command, it is lost. I made a local change to add a retry counter and will reissue the sendCmd from setCommsError up to 5 times. It seems that there is a better chance the command will succeed and status is updated sooner without waiting for the next scheduled Refresh. I don't know if you have any changes that reduce the usefulness of this approach (or you see a problem I haven't run across) but I thought I'd pass it on. Rich

I would like to see this change added as well. I relatively frequently see the CommsError. I resorted to just sending the on/off commands multiple times with a short delay.

1 Like

Good idea. I will modify code to provide error counter in driver to retry up to five times. Probably several weeks (beginning of September). I am working bleBox devices right now.


1 Like

"Sorry to bother you with this since I just figured out the problem.

I had the devices on my guest wifi networks. I tried switching one over to my main network and it worked. I read somewhere you should keep smart home stuff on your guest network for security reasons, but I guess that doesn't work for Hubitat."

To build off of this. I have a separate VLan locked down from my main network with all of my IoT devices on it, the hubitat included. It basically drops all internal traffic as well and just allows access out to the internet when needed. To make this solution work, would I have to allow the hubitat accept pings to the IP of the TP-Link? Is there anyway to add via IP instead of discovery since we are assigning static IPs anyway? I didn't get a chance to mess around with it too much last night, but basically it was looking for devices for about 1-2 minutes and then found none, with nothing responding which isn't surprising based off my firewall rules.

I just wanted to get your thoughts, I Think a rule as mentioned above should allow it to see the device and that is fine. I could see others running into this in the future, having IoT things locked down is definitely a good way to go on a home network.

I do have a related question. I was previously using version 4.1.01 (2/4/19) that I'd modified with the retry processing I mentioned. I just updated to the current version. Since then I seem to be getting "Error occured with UDP message: SocketTimeoutException: Receive timed out" errors about 20% of the time on my HS105 plugs. I have them refresh every 5 minutes. Originally I didn't seem to be getting that on my HS220 dimmer but I realized I hadn't touched the device since I updated the driver code to 4.3. I saved new preferences on the dimmer and am now getting the UDP error.

I was curious if you can think of a reason this is happening. Is 4.3 doing something differently? It's not causing a big problem since I added the retry code to the switch and the command is usually successful on the first retry but I thought I could learn something. Thanks.

@djgutheinz, In addition to the previous post, I think there are a couple of issues in the TP-Link Dimming Switch driver in setLevel:

  • Line 133 has an undefined method logTrace. I presume that should be logDebug.
  • Line 134 is calling sendCMD but is not passing an action. I presume it should be "commandResponse"


The drivers are ALREADY designed to allow manual installation.

  • Copy over and save the driver.
  • Create a new device and enter type, label, dni. No specific rules on these. what you want. DNI must be unique.
  • Select the driver from the pull-down.
  • Save the device.
  • Enter the IP address in the preferences section. For multi-plugs, enter the Plug No.
  • Save Prefereces.
1 Like

Will look into on next rev.

Thank You!

Just noticing this error today.
IP is locked, and when I manually hit the switch in HE it responds.
It did just miss its automation and gave me this error.

dev:582019-08-11 08:30:27.486 pm infoTP plug 4.2.01 TP plug: Power: off

dev:582019-08-11 08:30:10.375 pm warnError occured with UDP message: SocketTimeoutException: Receive timed out

dev:582019-08-11 08:30:10.362 pm errorTP plug 4.2.01 CommsError: Device Offline. The device is not found at the current IP address. Caused by either the IP changed or the device not having power. Check device for power. To update IP either run the Hubitat TP-Link App or updated preferences for a manual installation

It is a device error (busy doing something else). The next version will attempt (by re-polling on periodic refresh message failure).

Are you using static IP addresses? (probably not the problem). I strongly recommend this.

has been on a static IP - yes.
When I click the HE switch it turns off, but it dropped the connection (only started happening today) right before the automation.
Thanks for the reply

What switch? I have been having similar issues with my HS300's (delayed response) when I try to do too much at one time. If you hit the devices too fast, they appear get lost and will not respond to a command.

I have a HS100. Nothing else is happening at that time.
its a single automation to turn the switch on at 430 and off at 830pm.

1 Like

Also, look at this link. not your problem, but if you use the automations it is an interesting thread.

1 Like

UPDATE. Updated device drivers and device handler have been added to the GitHub repository.

  • Correct URL for import code
  • Add auto-retransmit on comms error (5 tries).
  • Remove "OFFLINE" state from switch
  • Add attribute 'commsError' with value true/false and set after the failure of the auto-retransmit; reset on successful comms.
1 Like

update the driver if I have the HS100 ?

All updates are optional. If the features you see in the previous post are of interest, update; otherwise, it is not worth the hassle.


Update: I recommend update for you since you had an offline problem.

"If it ain't broke, don't fix it."


I updated the driver and the app.
It didnt find my HS100, but the logs showed this.

app:612019-08-23 05:01:03.849 pm info4.4.01 addData: DNI = B04E26C84E9E, model = HS100, ip = 192.168.1.XXX, alias = Hs100, type = IOT.SMARTPLUGSWITCH, plugNo = null, plugId = null

I didnt delete the device, and its showing up on my dashboard and is controllable now ??