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

I have the HS110 monitoring my gas dryer. The 30 minute polling was not specific enough for me, so I appreciate the ability to change this parameter. Is there a way with Rule Manager to change the polling to 5 minutes when drawing power, then revert to 30 minutes when not drawing power? Or might this considered as a future feature for your code? Thanks for your great work!

Hey Dave,

Also in Aust. Got 5 HS110's today. I'm setting them up, but getting errors. I've succesfully added them to wifi network, and asigned static IP. When I add to HE though, errors and warnings. I've added in the app and the right driver.

Driver installed:

This is the first TP Link device I've installed. I have four more to do.

Edit: FYI, the app finds the plug, but when I select the plug, it errors with the above error. No device is added to HE.

EDIT 2: dont worry, I didnt realise what EM stood for. Now I do. Stupid me.

But, it's not updating the on/off/status/etc.

It seemed to fix itself after 10 mins or so. Thanks for the app!

1 Like

How do I get energy monitoring for the HS110's. I've got the right driver, and it's all connected to HE, however, it only has on/off/refresh. Nothing about energy monitoring.....

Edit: I'm still getting a stack of those timeout's in the post 2 above when I add new switches into the HE mix.

Timeout errors: These are due to a rather cumbersome (but unavoidable) discovery method. Since Hubitat does not support UDP discovery, I must poll the LAN IP:9999 addresses. If successful, then I data is returned and I parse that data. If unsuccessful, I get the above. This only occurs when you run the app, and then one-time.

No EM Data: You may have hooked to the incorrect file (there are two for two different devices). The correct file link is " TP-LinkEM-Plug(Hubitat).groovy".
Documentation: Installation instructions created to add note on UDP errors and also correct fild identifier for the EM plug.

If you still have a problem, I will look further at the code to see what is going on.


Hey Dave, I do have the right driver in Hubitat. Something else is going on I suspect. I've now got two identical versions of the hubitat energy monitor driver in HE.

Uninstall and start over tomorrow when I update the EM code.

I tried to create an automated function. Too many chances for user-induced, hard to recover errors, in the driver. It might be a future release.

PS: I could expose the setRefreshRate function as a custom command. You may be able to control that through the rule machine. You would have to try. Interested?

Using Rule Machine would be just fine. I basically would crate a trigger that says when dryer starts drawing power, SetRefreshRate to 1, when Dryer stops drawing power, setRefreshRate to 30. I would be happy to test for you. Let me know!

I should have something today or tomorrow. It will be custom and not in general distribution until you test.

Update to Energy Monitor Plug Driver (for HS-110). An update is on the server removing some errors and providing access to refresh interval from external programs. Follow the instructions below to assure update is successful

For each HS-110 device, Follow the below in the order stated:

  1. Set your refresh interval using the new command "Set Refresh Interval". Allowed values are 1, 5, 10, 15, and 30.
  2. In preferences, select "Enable energy monitor features". This will kick-start for energy monitor.

Note: I have created the custom command "Set Refresh Interval" to replace the previous preference entry. Two advantages:

  • Can update without running preferences (and associated overhead),
  • Can (hopefully) access from rule machine when you have linked to the other capabilities.

Problems - contact me.

This helped me out too, thanks. First post after getting Hubitat. I got several Caseta, TP-Link, and z-wave devices working in less than an hour since unboxing. The straightforward methods of setup and use is incredibly refreshing after deciding to try to migrate from a more challenged platform.


TP-Link Device Local LAN Only Option
The Kasa App no longer supports Local LAN Only as a user option. If the device was Local Lan Only when the app was updated, the "remote Access" option remained in the Preferences; however, once selected, the option disappeares.

Fix: New App Kasa Devices Local/Cloud Manager. This new app is in final test by me. provides the following:

  • Unbinding TP-Link Plugs, Switches, and Bulbs from the Kasa Cloud.
  • Binding devices that have been unbinded via the above (requires username and password).


  1. Once unbound, the plugs and switches are listed in the Kasa App as local control only. Bulbs do not do this, but they are indeed unbound.
  2. Some models are not controllable by the Kasa App when unbound. The only one I have encountered is the HS-107. (HS-100, 105, 200, 300 and the bulbs work fine.)
  3. The binding process works well - but need username and password for the Kasa Account.
  4. Once run, the application is no longer required. It can be safely uninstalled, then reinstalled on next use, or just sit in the installed application list. It DOES NOT run unless user executed.
  5. The App uses the UDP search for the devices and generates while doing this up to 250 error message related to timeout on the interface. It only runs Once, and only after selecting the bind or unbind option.

Probably available at start of month.


I just got a Hubitat so I could be making just a dumb mistake, I'm trying to add a couple of HS105s, one HS100, and two HS300s. Loading the app only takes about one minute, but no error messages are given. On the manager page to add devices, no devices have been found. Any help would be appreciated. I have copied over the device drivers.

I guess I should add that these are devices I've already connected to my wifi system and use the kasa and alexa apps with.

The only guess I have is that they are not on the same IP segment as your Hub. I tried with the app just now and all 17 were found the first time. I have a series of HS-105, HS-107, HS-300, plus bulbs. Ran a fresh copy (renamed app) and stopped at the install page.

All error messages would be in the logs; however, you should ignore the messages (a lot) in the first line below. The second line is a sample of a success.

app:22412019-08-03 09:25:54.263 pm warnError occured with UDP message: SocketTimeoutException: Receive timed out

app:22412019-08-03 09:25:54.207 pm info4.3.02 updateDevices: DNI = 50C7BF24E4E4, model = LB130, ip =, alias = Den Right, plugNo = null, plugId = null

Things to check:

  • Assure you have the latest Hubitat application version (do a check for updates)
  • Assure your devices are on the same IP segment as your hub. They should all have the same address segement (i.e., "192.168.0").

Please tell me if you resolve. I could load the next version of the integration early for you to try. It is fully tested, just waiting time to cure in my home environment (no errors yet). But, If you can not even discover the devices with this driver, then something is wrong with basic communications (outside the realm of the integration application).

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.


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