Has anyone tried this methode on the HS-105 to connect to SmartThings?
The app in this thread should work (same command structure). The app in the thread ā āTP-Link Bulbs and Plugs Controlā also works. The 105 is exactly like the 100 in command and return structure.
Has anybody tried using an android device as the gateway? I donāt have a raspberry pi, but I do have an older android phone I use for some home automation.
[quote=āSeth_D, post:110, topic:70538ā]
using an android device as the gateway? I donāt have a raspberry pi, but I do have an older android phone I use for some[/quote]
There are instructions for getting Node.JS installed on android on the web. Then these apps should work if you can get a link to them from the android device.
I didnāt read all the information in this thread but I believe I figured out an easier method and no need to run a server. I didnāt create this method I am only taking information I found in other threads
You can first add a virtual switch to SmartThings using the information in this link.
now setup your tplink to work with IFTTT using the information in the link below:
you can make two ifttt recipes using smartthings virtual button, one button to turn it on the other to turn it off.
Now when you click on the virtual device button in smartthings it should turn on or off your tplink.
only problem with this way is I am using the hs200 wall switch so if I hit the physical button to turn off my lights the virtual button will still show it is on, and if using google home you should remove the tplink account and just use smartthings instead to avoid the same problem with hitting the physical button.
3 Likes
Great site. Will take some investigation. However, the process involved is far more complicated than the install with Hub. Each individual has to get a URL, code ifttt, etc plus write the device handler.
With this information, it should be possible to create a Smart App and Device Handlers similar to the Wemo App/ Device Handlers. I will investigate this. It would all be automated except Username and Password. Being an inexperienced programmer, I may need help. It will probably take some time. May require Oauth - a big issue.
Joseph, Again, thanks for the information. I was able to use this method to control the devices external to SmartThings. Sadly, in SmartThings, the URL is blacklisted (i.e., not allowed). (sigh)
For me, it is not the best solution. I would have to create an IFTTT. I do not believe I can send parameters to IFTTT so that I would have a single recipe. Now that would be a game changer. I will be checking this further.
Maybe you can set up a reverse proxy server that can act as a middle man. That wouldnāt be black listed. Iām not sure thatās practical or economical for most people. Iāve set one up for a different website I ownā¦ To set one up from scratch it costs $5/mo to rent the Unix server and an annual fee for your ssl certificate. The server rent would increase the more traffic hitting it. If you are the only person using it you wonāt have any risk of too much traffic. But if you shared it with the community, that might increase the cost.
1 Like
Understand. Probably no better than the current stand-alone hub (bridge) running node.js. At least you have control of that local device and security is actually enhanced. Currently, hubs can be Windows computers, Raspberry Pi, android devices (android 2.2.1 or later) and Amazon Fire HD Tablets. I have tested all of these except Raspberry. The android device was an old phone with Android 4.4.
I am disappointed. I was hoping we could get somewhere for the casual user without having a hub (or proxy or other complex setup). Wanted to be similar to Lifx bulbs with a connect app and the device handlers. (sigh)
Were you using the āeuā url? Iām wondering if other regional urls are also
blocked. You might could try the IP address instead. If folks were
willing to pay a setup fee or a small monthly fee, we could set up a
reverse proxy server for the subscribers.
-
When you download the list of devices from TP-Link, a URL is listed for each device. For me, these were āhttps://use1-wap.tplinkcloud.comā.
-
Trying the IP address would not work. The URL has the security token for the indivicual user: āhttps://use1-wap.tplinkcloud.com/token=XXXXXXXā. Using this gets an automatic error code.
-
Possibly a pay for proxy would work; however, the price break would be very low when I can buy Android tablets (as a hub) for under $50 at Fryās, or use an old (replaced by new) smart phone, etc.
i want to thank you guys for this. i picked up the 3 TP-Link HS100s on Prime Day (came up to $11 ea) and i was concerned that i wouldnāt be able to use them outside of Kasa/Echo. I was almost about to return them, when i stumbled on this thread.
Iām new to SmartThings (iāve only owned a hub for 2 days now lol) and the extensibility is amazing. Kudos to everyone that made this integration happen.
I made an error earlier. I CAN communicate with the TP-Link Cloud to control my plug (and I believe this will be true for bulbs). Now the work is parsing the different format return from the cloud (vice TCP), writing a Service Manager and updating Device Handlers. Then install will be load Service Manager and Device Handler and then run Service Manager. No separate hub (bridge).
Anyone interested???
Pros - no hub. Simple installation (even I can do it)
Cons - must open up TP-Link devices to Cloud control (security), sending info to cloud w/o formal OAUTH process, must rely on TP-Link Cloud to keep track of devices.
2 Likes
SUCCESS!. Now the work to integrate begins.
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.
1 Like
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
3 Likes
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.
Token Attainment
Frequency - once every week (changing to every 2 weeks?)
URI: "āhttps: // wap. tplinkcloud. comā"
Data ==> TPLinkCloud: Username and Password
Data ==> SmartThingsServer: Token
Get Devices
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)
Control Devices
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).
Reliability Factors:
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.
Thank you!
I have a new link. Sorry for the confusion. I added a cloud version that does not require a Hub. New link:
1 Like