I have successfully completed a Service Manager - Device Handler capability for TP-Link Plugs, Switches, and Lights that DOES NOT require a bridge. It uses SmartThings Cloud to TP-Link Cloud communications to control and monitor plugs and bulbs. See the thread “TP-Link Bulbs and Plugs Control”, lead-in message.
Thanks. I now have a SmartThings integration directly to the cloud (not IFTTT) that works and is in Beta. See the thread:
TP-Link Bulbs and Plugs Control
Interesting concept. I need to get educated on how the virtual device specifics are exposed to the external world. My concerns with this approach (if I understand it correctly) are security and reliability. I’m not sure that I as a home security implementor would want parts of my security system farmed out to external entities, i.e. having IFTTT applets execute externally and then piping their output to my security system devices. That makes me somewhat uneasy.
I’m really perplexed why the SmartThings powers that be opened their system up to smart app and device handler development, but failed to provide commonly used libraries such as socket programming which is fundamental to all platforms. Such a library would yield a neat and clean solution which could execute on the hub thus eliminating the need for a local middleman host or going off into the Internet.
Looking at all the available options for hs100 control via SmartThings at this point I’m most inclined to just buy a z-wave outlet plug and punt on the hs100. Second option would be to use Raspberry Pi as a small cost effective controller for just this type of task. Both these approaches would seem to yield better security and reliability than accessing external hosts on the Internet.
For the TP-Link Cloud Integration, the exposure is can be depicted as the flows:
Path: SmartThingsServer ==> TP-LinkCloud ==> SmartThingsServer
URI : The uri path is always https.
Frequency - once every week (changing to every 2 weeks?)
URI: "“https: // wap. tplinkcloud. com”"
Data ==> TPLinkCloud: Username and Password
Data ==> SmartThingsServer: Token
Frequency: Initial installation, on comms error, and when adding devices.
URI: "“https :// wap. tplinkcloud. com”"
Data ==> TPLinkCloud: Token
Data ==> SmartThingsServer: Device Serial Number, Device MAC (no address info)
Frequency: about every 15 minutes
URI: "“https: // wap. tplinkcloud. com”“
Data ==> TPLinkCloud: Token, device MAC.
Data ==” SmartThingsServer: Cmd Response (device data, but not IP, etc. in these apps)
Risk factors (compared to Z-Wave/Zigbee). The big risk factor is the trust level of the cloud server. These are not evaluated (but should be). However, for TP-Link, this is a large company with knowledge of security issues as well as a strong interest in maintaining their reputation (since their primary products employ security features).
a. SmartThings Platform and service. About a nine out of 10.
b. TP-Link Cloud. 9.5 out of 10 (I have had no problems, looking at blog, do not see many).
c. Service Manager and Device Handler. Very reliable
1. Cloud Based: 1.5 months, 8 devices, no errors.
2. Hub Based: 6 months, 8 devices, no hard failures, about 0.5% SW errors not leading to failure (PC Hub)
PS - do not blame SmartThings. Although the TCP interface would be relatively simple to implement, the return formats are widely different and SmartThings would have to figure out how to manage this wide-variety of returns to successfully pass back to the requesting handler. It just does not fit well into the planned architecture.
Hey Dave I see that your link is dead. Can I find this somewhere else? I reciever my TP-Link HS200’s today and would like to add them to my smartthings hub that I also just got.
I have a new link. Sorry for the confusion. I added a cloud version that does not require a Hub. New link:
Thanks for the info and work @Gutheinz!
I did someone playing around tonight setting up the new Hub and it picked up everything I have already that’s WeMo but want to test out the TP-Link setup. Hope to give it a test in coming weeks.
I am new to the SmartThings environment. I just picked up couple of the TP-Link HS200 wireless switches. I am wondering if there are instructions to modify it to connect to the smarthings hub.
See the below link.
This must be a silly question. Where do I start as I haven’t played with the smart thing hub. I only have connected my Philips hue system with it. Your help if very appreciated.
So new to Smart Things and the development environment (IDE). I was there in January. Read what Tyler provided. However, as a quick start…
- From this page, select “COMMUNITY” at the top right of the page.
- Create an account.
- Create your location, which defines your hub in the environment.
- Go to the link in my original response for the CLOUD BASED HANDLER.
- On the GitHub site, click the green “Clone or download” (top right).
- Select “Download ZIP”.
- Extract the zip file to a directory.
- In the top directory, there are explicit instructions on installing this product.
It should take about 30 - 45 minutes the first time you do a custom. After that 15 minutes would be a very slow installation.
First off thank you @Gutheinz for your work on this!
I hate asking too many questions and I have searched a fair bit on this but I have gone over Cloud Based Setup Instructions but I keep getting a “No signature of method:” error. I’ve found other posts about this but can’t seem to find a clear fix or something that I might be doing wrong.
Here’s a quick video of the error https://youtu.be/F77jCsgTzQM
And here is a quick screenshot https://i.imgur.com/t9YsZzu.png
Two errors - one which caused the problem:
a. You did not select the location prior to installation (must do so, or ST gets confused).
b. (Critical). You pressed “My SmartApps” instead of My Device Handlers. Therefore, you are trying to install a device handler as a smart app.
Thanks for all the information to set it up.
It now shows up in my Smartthings app, but i can only turn it on/off. Any way i can have schedule, away and timer like the Kasa app?
I have the HS-105 smart plug btw
I did not provide scheduling and timers and this is not planned. It would be difficult to replicate using the tools available.
The primary idea is to set up the control functions in SmartThings and then use the SmartThings environment tools for scheduling, away functions, etc. Example 1, using Automations, you can control most smart things devices to turn on/off on a schedule. Example 2, you can set an automation to turn the lights off and set a controlled thermostat to a non-occupied temperature every day at 7AM and another to reset at 4PM. EXample 3: an automation can be set to turn the fans, lights, thermostat, and other items off when you leave home (detected by your phone) and back on when you return.
There are other items within the environment that allow even finer control.
You mean to create a routine?
Yes. And there are other things various people do to further automate using Pistons, Action Tiles, etc. However, I am not familiar with these. The goal, of course, is an integrated environment where control of different devices is done through the same interface. Allows automation of the connected devices based on EVENTS, not just time, etc.
I also use Amazon Echo and have created routines based on my events - such as going to bed to read and going to sleep - to assure everything if OFF that I want off. Same when I wake up at 3AM. I say the command and it turns on the bedside light, den light, and turns off the bedroom fan. Also turns on my soundbar and other items. Just say "Alexa turn-on wake.
I’m really torn here… it seems great that this cloud based bridge exists for tp-link stuff but how worthwhile is this vs zwave/zigbee stuff if you’re just starting out? I just got some tp-link switches and outlets and after setting up my smartthings hub I’m starting to think I should just return my tp-link and get other options. Any opinions from experienced users?
I bought mine when I was early on in my HA adventure, before I had a ST hub. They are big and bulky and for some reason were designed in a way that makes it impossible to use the second plug on a wall outlet. Since I already had them, this was a good way to integrate them.
Personally I’d go with zwave, no reason to over complicate things by mixing protocols if you already have a ST hub. If you’re concerned with being able to move them around, get the plug in type. If you are looking for a clean installation, get the replacement receptacles. I really like the handful of zwave receptacles I have, allows you to have one switched and one always-on.