I don’t have a TCP gateway, but I took the liberty of looking over the device JSON file and found the issue causing the advance tab and setting not displaying on UI7.
@pmnb: The name of the device type you have defined in your device definition file is:
Technically, you should correct the name in the device file, but I did not want to do that since there are probably other references in your code to that device name. So I modified the JSON file (last couple lines) to be consistent with the “…service:TCPLightingGateway:1” device name.
You should be able to upload the attached JSON file to your vera, and a browser refresh later your advanced tab should be back.
Unfortunately, I cannot help with TCP removing HTTP access to the gateway.
@JoeyD Thanks for catching that! I had taken a quick look at the JSON file and it met the basic requirements stated in the thread regarding UI7 and the Advanced tab, but nothing was jumping out at me. You’ve certainly saved me some hunting
I’ll roll the fix into the next plugin version I release. Right now, my TCP Lighting Gateway has gone south on me, so I’ll need to get that back to life again. My particular situation doesn’t seem to be just the gateway firmware issue - it’s not connecting the network at all and has red LAN/WAN indicators. I may just switch to a second gateway I have sitting around.
[quote=“JoeyD, post:41, topic:179548”]All,
I don’t have a TCP gateway, but I took the liberty of looking over the device JSON file and found the issue causing the advance tab and setting not displaying on UI7.
@pmnb: The name of the device type you have defined in your device definition file is:
Technically, you should correct the name in the device file, but I did not want to do that since there are probably other references in your code to that device name. So I modified the JSON file (last couple lines) to be consistent with the “…service:TCPLightingGateway:1” device name.
You should be able to upload the attached JSON file to your vera, and a browser refresh later your advanced tab should be back.
Unfortunately, I cannot help with TCP removing HTTP access to the gateway. :'([/quote]
So I contacted TCP two days ago and received the following reply today;
Hello,
Security is a top priority at TCP and we employ the latest security standards. For this reason the Local user Interface (windows PC:/lighting & Mac/lighting.local) of the Connected by TCP Gateway has been disabled. We’re sorry for any inconvenience this may cause. We do not anticipate this service to be running in the foreseeable future. Please continue to use your smart phone and/or tablet as the primary control devices of your Connected by TCP system. We are sorry to say but we can not roll back to the old firmware version in the gateway. We are sorry for the inconvenience that this may bring you. Thanks.
Connected by TCP Wireless Support (DMM) www.connectedbytcp.com
800.397.2864
Support Hours: M-F 8:00 AM - 6:00 PM EST
Needless to say, I’m extremely disappointed with their response.
Fortunately, I have an extended warranty, filed a return, and will be sending everything back tomorrow.
Their pricing was certainly competitive, but with their lack of support, I’ll gladly suck it up and take my business elsewhere.
[quote=“pmnb, post:45, topic:179548”]On a related note, I have not had any luck getting access to a supported API:
Hello,
Unfortunately the LUI will be disabled until further notice and we do not have a release date of the API as of yet.
Thank you,
Connected by TCP Wireless Support (DJR)
800.397.2864
Support Hours: M-F 8:00 AM - 5:00 PM EST
[/quote]
I can now view the advanced options with the new json file. However, the plugin fails to connect with a message that it needs a username and password. There is no location for this. Would that solve the LUI issue?
There seem to be some mixed messages floating around. TCPi are saying that local access is disabled, but there are also postings elsewhere that indicate the local API has been modified to support authentication. I’ll see if I can dig deeper into this.
Apparently, the Local User Interface has been disabled in firmware 3.0.74+… But the Local secure API interface has not…
It has been figured out by someone on the SmartThings forums… and is documented => [url=http://home.stockmopar.com/updated-connected-by-tcp-api/#more-116]Updated Connected by TCP API – Home Automation… From what I can tell so far… you need to do a “login” process to get a valid token rather than using a fake token… and using https rather than http…
[quote=“cybrmage, post:48, topic:179548”]Apparently, the Local User Interface has been disabled in firmware 3.0.74+… But the Local secure API interface has not…
It has been figured out by someone on the SmartThings forums… and is documented => [url=http://home.stockmopar.com/updated-connected-by-tcp-api/#more-116]Updated Connected by TCP API – Home Automation… From what I can tell so far… you need to do a “login” process to get a valid token rather than using a fake token… and using https rather than http…[/quote]
That’s the exact link that I referenced in my posting. Once I get a few free cycles I’ll try to implement this.
Oops… Your post wasn’t there when I started my reply 8-}
If you need some reference code for the HTTPS requests, my Wink Hub plugin uses HTTPS for the OAUTH2 authentication… Fell free to borrow, steal or mangle it if it will help.
+1 for implementing the workaround quickly. my attempt to block the outgoing traffic and the incoming firmware update was not successful and I’ve lost control of my TCP bulbs. I could connect them to the wink hub and use that plug-in, but I find the 3-4 second delay caused by having to communicate over the wink api pretty annoying
[ol][li]I’ve been able to cobble together some test Lua code that successfully authenticates against a TCP gateway via HTTPS.[/li]
[li]Now I need to integrate it into the plugin and adjust all subsequent gateway calls to use HTTPS and the token provided by the gateway.[/li]
[li]Since I’m racing against the clock due to upcoming business travel, my plan will be to make some alpha code available for anyone who would like to try it as soon as I have something minimally working.[/li]
[li]I’ll then take my time to perform further testing and put together a version solid enough to put in the app marketplace.[/li][/ol]
I’ve attached a very, very alpha version of the updated plugin code.
Only existing plugin users that have been messed up by the recent TCPi firmware updates discussed above should try this version.
Installation (UI5)
[ol][li]Download and unzip the attached zip file.[/li]
[li]Upload all of the plugin XML, JSON and LUA files using the Apps / Develop Apps / Luup files page. Make sure to click the “Restart Luup after upload” checkbox.[/li]
[li]Wait for the Luup restart to complete.[/li]
[li]Go into the TCPLighting device configuration UI (wrench icon). You should see a “Login” button - but don’t click it yet ;)[/li]
[li]Press the green sync button on your Connected by TCP gateway.[/li]
[li]Press the “Login” button on the TCP Lighting config UI. Wait a few seconds.[/li]
[li]Press the “Sync” button on the TCP Lighting config UI.[/li]
[li]Cross your fingers and see if things are working again.[/li][/ol]
Please let me know (one way or the other) if you have any luck with this version…
Not sure if this is what I can do. I loaded the 1.0 version from app store. put in IP address … got the connection refused like others. Loaded the alpha version. Got message No Gateway. Press the green button on gateway and click login. The gateway about token disappeared. Press sync and nothing happened. Seem like I got the token as I can see the token in the advance tab. but press the sync button did nothing for me.
EDIT: My problem … not the plug in. Someone in my house turned off with the ON/OFF switch. Turn the light back on. TCP app can see the active light … Press Sync Again and the light got created in Vera. Thank you
