Connected By TCP & IFTTT

I just contacted TCP and asked them if they were planning IFTT integration.

Their answer:
We will be releasing API for home integration later this quarter.

@JAA Don’t hold your breath man! They told me something similar in February it was coming soon, I’m not sure what’s going on with that company anymore.

1 - home depot is discontinuing the TCP Connected lights
2 - haven’t released an updated APP (needs an overhaul)

I’m still holding onto hope, because I really love TCP.

I’m with @antman2 on this one. I’ll believe the API when I see it :smile:

1 Like

Well, that’s disappointing. I’m going to go ahead and wait on any further TCP purchased, then. I’d hate to say it but it looks like the safe choice is “Hue” in that it appears to be supported by more services - and well.

@JAA I agree with you 100% man. I’ve completely stopped buying TCP with that very thought in mind, but then again I’m giving TCP a couple more months. If something doesn’t happen then I’ll sell all my lights and purchase the Hue bulbs.

I have been using TCP bulbs for a couple of months now with my ST hub, and I’m pretty disappointed. I’d say I’m experiencing maybe a 45% success rate in the ST app actually controlling the bulbs.

If I go into the settings of the bulb, and then settings of the TCP smartapp - i can uncheck the bulb in question… check it back… then the app will control it fine for a few hours before having to do that again.

Is anyone else having this issue, and have you found a way to get reliable performance? The same rings true for my only other “labs” smart app to control Wemo switches. Is it something in general with Labs releases? Should I expect this from all smartapps that come from there? I have 14 “things” right now, and TCP and Wemo are the only ones not working as they should.

Did update 11.705 help with the TCP bulbs?
Do you have a WeMo motion? if so how well does it work with ST and controlling the TCP bulbs?


I have 10 TCP bulbs and they work great with multiple motion detectors. I have the aeon labs multi and the SmartThings Motion. The TCP app is still a pile but I never use it.

1 Like

@Dave Unfortunately, the latest update did not help performance. Its as hit and miss as always. I do not have Wemo motion, but I do have a few other motions sensors tied to the TCP Bulbs… and it works…when it wants to.

The UltraIQ however work like a dream. A few bucks more, but they work with everything right out of the box. I have actually unplugged my TCP hub for the foreseeable future.

Can the Connected TCP bulbs work with the SmartThings hub by themselves or do I need to buy another hub to run them?

You need the ST hub and TCP hub if you want to connect the TCP bulbs to the ST App.

TCP Connected API?

I had asked one of the TCP Connected Lighting Android app developers about the possibility of an API last year (2014) and he said there wasn’t one available to the public and didn’t foresee such in the near future.

A year ago, I was excited about TCP products. Now, I am pretty disgusted with them. The forced update of the firmware, removal of the web interface, dodgy performance, ignorance of Daylight Savings Time, worthless portal interface, and lack of API make this a poor, closed and clunky home automation component.

It’s only a matter of time before TCP completely cuts off the Node.js hacking.

I think TCP’s closed system in the age of IoT and IFTTT, blocking interoperability, are really doing themselves and the consumers a disservice. I wish I could return the bulbs and gateway for a refund.

This might be a daft point but I have The TCP lighting system and found a remote log in by trying the GIP Server address which you can locate in the tools (spanner icon) >>System information section . Pop that in to web and as long as you have a remote account can control via we from any remote computer /device and seems to work okay.
Setting up a remote log in is quite simple within the android app. I don’t think its possible via web though.

I did find by the way that with out it, the local connection would refuse any connection attempt after a while. With a log on that problem seems to have gone for me.
For ref firmware of mine = 3.0.74


Nice work!! Will give this a try over the next few days.
Can we bring this into ST at all?

If you can make direct API calls, in theory yes. The API I wrote responds to the request strings the front end generates. I should really document that a bit more. As an example, once you have this running on a web server, you can issue a command like:
/api.php?fx=toggle&type=device&uid={DEVICEID}&val=1 would turn the light on, or
/api.php?fx=dim&type=device&uid={DEVICEID}&val={DIM_VALUE} would dim the light or you could do something like
/api.php?fx=toggle&type=room&uid={ROOMID}&val=0 would turn a given room off.

In my interfaces you can determine any of the ids by clicking the little “i” button and it will tell you the IDs

I could whip up a status page pretty easily so you could check if a light is on or off…

Happy to assist, drop a comment on my GitHub page.