If anyone is still using this (I am - in conjunction with around 30 Hue lights), I have a working local device handler. However, I wasn’t able to invoke physicalgraph.device.HubAction directly to the hub (it’s cert isn’t valid), so I’ve written a proxy web service to translate the traffic to non-SSL.
Anyone out there found a better way? It works perfectly - all local. But, it does require a local host for the proxy service, which I don’t like.
Sounds better than my plan of pulling an old hub with old firmware on it and trying to reconnect everything!
Yes, if I knew how to do it I would. Happy to fund or support this effort any way I can given my sunk cost into TCP bulbs as it stands currently.
I am very interested in doing this. I have every bulb in my house converted to TCP and would love for them to work with Smartthings again.
I will also would like to see a workaround for TCP lights.
I wrote TCP support to see if there is a possibility to rollback to local processing (as it was when I bought it) so that we can have the integration with ST. I would encourage all to do the same and maybe we can get create some pressure at TCP.
Would love to see this working. Will probably give people who invested in TCP bulbs but not Smartthings to take the plunge.
I would like to try this out when I get some time - I also have several TCP bulbs and want them working in SmartThings again! For now I just use the scheduler via the TCP app on my phone to control them.
In seeing how Wink use to support local control, there was a point where the Wink setup process wanted me to push the button on the TCP hub to allow full local control. At the time I didn’t get that part working, so Wink was using the TCP control over the web. Now it doesn’t work via Wink, but could we use something like that for local control via ST?
I know that ST doesn’t support https traffic for local control, but does pushing the button on the TCP hub to authenticate with other devices alter this any?
Would like to try this, I have two hubs here. I have also emailed Greenwave dircetly to see if i have any options.
Any update? Mean while can you advise on how you are running it currently with Proxy.
A user recently posted a copy of the old firmware and downgrade/restore instructions on github.
WARNING: this is not for the faint of heart/technically challenged. The brief steps are: run an SSL webserver, redirect the requests for some greenwavereality.com domains to your webserver, serve the old firmware.
More details: https://github.com/hypergolic/greeenwave_firmware
I was able to use this to de-brick a hub that I brought online a few weeks ago for the first time since before the firmware fiasco.
I now successfully have a restored hub and my lights are all working again. Investment recouped. Getting it integrated with ST… is the next challenge.
Looking now for a local integration for the old-style firmware, but would be interested/willing to upgrade/run a local proxy if it means smoother/more reliable integration.
Also, not sure how much effort has been put into it, but in poking around on the firmware for -the tcp device- it seems to be a Jennic 5618 zigbee radio, so it shouldnt be too unpossible to figure out how to speak directly with these units now that we have access to the device…
studio:~ adam$ ssh root@tcp-hub The authenticity of host 'tcp-hub (192.168.1.7)' can't be established. ECDSA key fingerprint is SHA256:DDPLwW889ZCIzPdc/iOl2m/ZqjsJdFl5riEbc9uPHcI. Are you sure you want to continue connecting (yes/no)? yes Warning: Permanently added 'tcp-hub,192.168.1.7' (ECDSA) to the list of known hosts. root@tcp-hub's password: ~ # pwd /root ~ # uname -a Linux lighting 3.5.3 #1 PREEMPT Tue Dec 3 10:44:29 CET 2013 ppc GNU/Linux ~ # date Wed Dec 31 16:31:28 PST 1969 ~ # Connection to tcp-hub closed. studio:~ adam$ date Mon Aug 8 23:30:44 PDT 2016 studio:~ adam$
@dev_sec Is there somewhere we can find the code for your local device handler? I now have my devices running successfully locally on the legacy firmware without SSL, so with some minor tweaks I should be able to make a seamless integration without a proxy (for my specific use-case)
BTW someone on the Vera forums has a fully working implementation of control via php. I’m running this on my synology NAS and I can view / control all of my TCP bulbs via a web page either local or remotely.
I tried the node.js implementation on the NAS but couldn’t get it to work, but this version appears to work flawlessly.
It’s not a real solution to the ST integration, but at least you can control your bulbs remotely again, and with enough effort I’m sure someone can finagle a solution even if it’s using this as a proxy.
I would also like LAN interaction with the Hub. SmartThings refusing to allow us to connect to a self signed cert is nuts. If only they allowed us the option to accept any cert then this wouldn’t be too hard to fix. Instead they cut off support 
I didn’t want to run anything at my house 24/7 so to get around ST’s security I gave my TCP Connected hub a fixed IP, forwarded the port through my router for HTTPS access. Then I configured a THINGHTTP to bounce between ST and my hub. I didn’t fully hash out the discovery that is implemented in the Connect app. I manually gave the smartapp my THINGHTTP details, and the secret/token from the hub using https://github.com/therivenman/pygop to get the token.
Altogether, I am not sure saving my sunk costs was worth it. However, so far it has been working for about a week.
With all due credit to those have figured things out before, here is a bash script for any who may find it useful. The username and password get you a token that will work for further calls but need not be your real TCP/Greenwave credentials. Press the button on the unit, first. Given your TCP connected gateway IP, it will spit out a token and device IDs of your connected bulbs. In previous experimentation I have also proxied out certificate of the TCP gateway using HAProxy so that https is no longer needed. But as I’m new to ST, it does not yet buy me any advantage because I was already controlling locally (and remotely) via curl -k commands. But I would like to see better ST local integration. Controlling locally is also much quicker as others have pointed out.
#!/bin/bash
#arbitrary useremail
useremail="bill.gates@microsoft.com"
#arbitrary password
password="linuxR0cks!"
#your tcp connected gateway IP
gatewayip="192.168.x.x"
`s=$(curl -s -k "https://$gatewayip/gwr/gop.php?cmd=GWRLogin&data=<gip><version>1</version><email>$useremail</email><password>$passord</password></gip>&fmt=xml" )`
#echo $s
token=$(grep -oPm1 "(?<=<token>)[^<]+" <<< "$s")
echo "Token: $token"
carosel=$(curl -s -k "https://$gatewayip/gwr/gop.php?cmd=GWRBatch&data=<gwrcmds><gwrcmd><gcmd>RoomGetCarousel</gcmd><gdata><gip><version>1</version><token>$token</token>%20<fields>name,image,imageurl,control,power,product,class,realtype,status</fields></gip></gdata></gwrcmd></gwrcmds>&fmt=xml")
did=$(grep -oPm1 "(?<=<did>)[^<]+" <<< "$carosel")
echo $did
echo ""
Typical command to turn on a bulb (use value 0 for off):
token=n9xxxxxxxxxx----xxx—xx–x-x-x-1244 #replace with your own token
gatewayip=192.168.x.x #replace with your tcp connected gateway IP
bulbdid=219777xxxxxxxx #replace with your own DID
curl -k "https://$gatewayip/gwr/gop.php?cmd=DeviceSendCommand&data=<gip><version>1</version><token>$token</token><did>$bulbdid</did><value>1</value></gip>&fmt=xml" > /dev/null 2>&1
There is a command for dimming also but I have not made use of it. Also, if there is is interest in my haproxy config, I will try and re-find it.
Hi, I’m trying to downgrade the gateway. but I have problems with certificate when run python https.py
it request me Enter PEM pass phrase:
Do You known what I need to enter?
If I enter any phrase or just enter I got the error
ssl.SSLError: [SSL] PEM lib (ssl.c:2718)
Could you help me to downgrade the gateway?
Thanks
Does anyone know if I can use the GW110 GreenWave gatewayto connect to the tcp bulbs?
Or any other compatible hubs than this one and TCP connected? Try to find a lot of many hubs in a decent price,
I am not actually interested in a cloud solution, only local, by Wifi.
Thanks
@Kirk_Brown
Can you expand on this a bit? Are you saying you have ST controlling your TCP bulbs by manually inputting token/secret and a THINGHTTP (whats that?) proxy to get around SSL cert issues?
Try this
You must downgrad your TCP hub to v2 , but works great
I’m not a coder but has anyone looked at Vera’s app for this? It works great and doesn’t have this firmware requirement. I’m not sure if that’s helpful or worth looking into for ST integration: http://forum.micasaverde.com/index.php/topic,23288.0.html