TCP Lighting Integration Issue - 10/27

Good morning!

My TCP bulbs stopped working last night. I’ve rebooted ST and the TCP Hub. No luck. I can’t even control the bulbs using the TCP app. I wonder if TCP pushed a bad firmware update recently?

-Rob

Recently got TCP hub and bulb really cheap at Home depot clearance section and added them to ST using the official (i assume) smartapp. But it loses connection to the hub way too often and never recovers it by itself. I think it happens when connection is lost by physical switch turned off and back on. TCP hub seems to always regain connection without reboot or resync. Wink app, which is also controlling TCP, also reports lost connection and recommends pressing the sync button on TCP hub but regardlessly lights still can be controlled by Wink.

Smarthings, however, never regains connection by itself, nor it can control the lights. Log is flooded with error code 400 (or 500), yet it doesn’t recommend any course of action how to fix it. I don’t know where this smartapp came from but it feels like a amateur authored hack rather than a solid official support. Anybody using TCP bulbs successfully with ST?

No. You are better off returning and getting something else if you can. The frustrating part is that ST points the finger at TCP. The interesting part is my friend has their TCP bulbs hooked up to a Wink hub and never has a problem…

I replaced my TCP bulbs with the GE Link bulbs. So far no problems.

I’d take it back. I’d grab the Hue white lights instead. TCP bulbs are decent, and I’ve had mostly good luck but given some support issues I would (if I could go back in time) just grab a bunch of Hue lights (or GE lights).

Thing is, the TCP lights dim really well, low light… the GE lights are bright. Hue lights dim super low as well. In some rooms I put in GE lights, but in others where I use more low-light, TCP or Hue.

Hope that helps!

Thank you for the advice. It was clearance, too cheap to pass (hub+2bulbs for $15) so no harm done. Probably will use it with wink. And yes I do like TCP’s dimming much better than GE link. (still too bright at the dimmest)

I’m just disappointed that ST’s official TCP support is so flaky. Not sure if ‘plays well with others’ is true for other 3rd party products.

It gets worse. TCP has announced support will end for connected lamps by the end of the month.

I believe that what they are dropping support for is the cloud service. You’ll still be able to run them locally, at least for now. ( this should break the wink integration as well as the smartthings integration, and anything else that used a cloud to cloud method.)

Yeah… the app is dead as well. Love the rather matter of fact comment…

“appreciate your understanding as the Internet of Things (IoT) market continues to evolve.”

Maybe that should have been “revolv”.

2 Likes

Well crap. :frowning: I was going to post this, but it may not work starting in June…

Hi everyone,

I got so sick of TCP bulbs not working correctly I dove into the source and fixed some things. I’m submitting to official SmartThings repo but if you don’t want to wait you can use my code today. Just go to https://github.com/mmacaula/tcp-bulbs and follow the instructions there. It’s basically just a couple of changes from the original. I’ve been using it for the past several days and not once have I had to re-install my bulbs!

Mike

Makes me wonder who’s gonna get “revolved” next. :smiley:

Nest seemed unstoppable but not so much anymore. Founder Tony Fadell is out and there is arstechnica article about how Google poured money and resources into the team yet nothing came off of it.

By the way if TCP folds their cloud side service and abandon the IoT products I hope they would open source it so that people can run their own cloud service and plug it into Wink or ST.

1 Like

I see no chance of this happening before hell freezes over. :slight_smile:

2 Likes

Has anyone tried to move over their hub and bulbs to greenwave? The app looks very similar. And doing some research it looks like tcp actually uses greenwave cloud.

When those TCP changes came along all those many moons ago, the web interface was changed to https://tcp.greenwavereality.com.

I connected my TCP stuff to the Greenwave IFTTT channel and everything works as well. When you go make the connection it asks if you’re using TCP, E.ON, Greenwave EU or a bunch of other internal stuff they’re apparently testing. I selected TCP, logged in with the same credentials and everything worked fine.

WAN cloud access has been through greenwave for a while. I noticed about 6 months ago LAN access via //lighting was gone.
I have actually almost gotten used to having to opening the TCP connected app in ST and relogin daily. With all cloud integration going away, I really need to go through the house and see if I even still have any TCP bulbs in use.
Maybe I can pawn the TCP hub and bulbs off on somebody that doesn’t need integration or remote access. I should still have the TCP remote kicking around somewhere.

I had so many issues with the ST integration that a while back I just decided to forgo that whole idea and use the TCP app, which worked more reliably, if not 100% of the time.

It will be interesting to see what happens though. Greenwave has a couple of items available and a big IoT presence, including IFTTT integration of their other products. I don’t know why they would simply turn that off and continue to support their other stuff.

I wonder if there would be someone brave enough to try to hack something together that would talk to the TCP hub.

Isnt that what we originally had before they forced us to use the Cloud - Cloud integration? If so, can we go back to that method?

As I recall, there was some kind of web interface in the old hub firmware that would allow it, but that was disabled / removed at some point by TCP because of some security issues. It used to be some kind of simple HTTP GET calls to the bulb ID to change its state.

As @esung said, it would be nice if the TCP becomes abandonware and they release the source to allow people to come up with their own solutions, but that’s unlikely to happen.

I guess someone with a Jennet-IP sniffer can try and figure out how to talk to the bulbs in some other fashion, or maybe physically hack a remote control so you can send it remote commands.

Interestingly enough, there have been a few efforts out there to get the TCP stuff sorted out after the local web interface was disabled.

The one that seems to have gotten furthest is one on github that relies on “fooling” the gateway into granting you access, because it thinks you’re on the local network. This is the way that the app used to work, and the way that the current mobile apps work, by getting a UUID from the hub when you press the sync button.

It looks like you should be able to initiate a sync to get the UUID “token” from the gateway, which can then be used to send commands to a room or an individual device.

My guess is that this should be relatively easy to incorporate into some sort of workaround to continue making REST calls to the hub. TCP will supposedly just kill their cloud to cloud access, but that would just mean turning off their side of things… for the app to continue to work locally they would need to keep this current setup in place.

It will probably require some fiddler/wireshark work initially, and port forwarding to the internal gateway IP on port 443 to make the calls over the internet, but it shouldn’t be “that hard” :slight_smile:

2 Likes

Ok so I’ve been poking at this whole thing and it seems to be easier than it looks… of course, that’s because everyone else already did the heavy lifting… :slight_smile:

There are individual commands to get the status of devices, you can target by room name, device ID, etc. It’s just a matter of parsing the response after you get the token.

The process is simple…

  • Find your TCP hub IP somehow. It answers to SSDP, or you can go through your router, etc.
  • Put the TCP hub into Sync mode by pressing the button.
  • Go to the URL to initiate a login request:

https://whatever hub ip/gwr/gop.php?cmd=GWRLogin&data=<gip><version>1</version><email>[myuuid]</email><password>[myuuid]</password></gip>&fmt=xml to initiate a login request.

The [myuuid] stuff in the login request doesn’t matter. The hub is in Sync mode so it will spit out an answer in the form of 1200[your 40 character token]. The 1 and 200 (HTTP OK) always precede any response from the hub.

If you attempt this without putting the hub in sync mode, you will get a 1404 (apparently the hub gives you a 404 error code when it’s not in sync).

From this point on you can issue a “RoomGetCarousel” command to query info about the status of all the devices.

https://whatever hub ip/gwr/gop.php?cmd=GWRBatch&data=<gwrcmds><gwrcmd><gcmd>RoomGetCarousel</gcmd><gdata><gip><version>1</version><token> your 40 character token </token> <fields>name,image,imageurl,control,power,product,class,realtype,status</fields></gip></gdata></gwrcmd></gwrcmds>&fmt=xml

The response is much easier to parse if you make use REST calls and parse the output, since you get everything about every device / room connected to the hub. You can simplify this by using <fields>name,status</fields> or whatever, but it’s still pretty gnarly. You can get device ID, state, power usage, brand, model, etc. which can get crowded very easily if you have even a few devices.

I guess the next steps would be to figure out how to make the calls and parse the output, and tie everything into ST. This should allow people to continue to control TCP devices even after the cloud-to-cloud portion is turned off.

In theory.

– edited to wrap the URL into code tags so it would display properly