[DEPRECATED] Kasa Plug, Switch, and Bulb integration

⚙️ Custom Apps and Drivers Custom Drivers
280

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?

281

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!

282

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

283

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.
Dave

284

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.

3 Likes
285

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).

Notes:

  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.
Dave

2 Likes
286

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.

287

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.

288

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 = 192.168.0.102, 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).

289

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.

2 Likes
290

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

291

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
292

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.

Dave

1 Like
293

"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.

294

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.

295

@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"

Rich

296

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
297

Will look into on next rev.

298

Thank You!

299

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