TCP Socket Support in ST?

[AaronZON (Aaron)]

Continuing the discussion from CES 2015 New Stuff:

@geko

These are two different use cases. TCP socket support would allow integrating SmartThings hub with myriad of existing devices without requiring HTTP bridge, for example Envisalink 3 for integrating with alarm panels, iTach IR bridge for audio/video integration, etc. If you search the board, you’ll find a lot of stuff that could be easily integrated should ST opened up TCP socket comms. BTW, I’m talking about outbound socket, as opposed to inbound HTTP/JSON, although that would be welcome as well.

I’d love to know more about this. I would completely understand, however, if the experienced don’t want to take the time to educate a complete newb (or group of newbs).

Does ‘HTTP bridge’ = device API + ST Service Manager SmartApp? If so, why is this problematic? How does ‘TCP socket support’ create integration opportunities?

Respond, redirect, ignore. . . . I’m OK either way. Just interested. . . .

[geko]

Ok, so currently the hub can make outbound HTTP requests only. This is how LAN integrations are done for Foscam, Radio Thermostat, VLC Thing, just to name a few. There’s however much wider selection of 3-rd party LAN-connected devices with published (or reverse-engineered) API that use simple TCP socket protocol (a.k.a. ‘telnet’). Integration with these devices currently requires setting up a ‘bridge’ (typically a Linux server, e.g. Raspberry Pi) to translate HTTP requests from the hub to TCP socket messages.

The TCP socket feature has been requested numerous times by the community and was finally promised “before the end of the year” (that’s 2014). This promise has not materialized, unfortunately.

[thrash99er (Morgan)]

@geko I understand the need for outbound TCP/IP connections to allow greater integration. I totally agree with that, perhaps the beefed up Hub v2, will allow that. Let’s hope.

[AaronZON (Aaron)]

Thanks @geko. Your comments and some additional research helped considerable. Much appreciated! Reiterating to check my understanding. . . . the examples you gave are of existing hardware solutions for connecting things to a LAN (via wired or wireless connection), however, they do not support a HTTP layer and therefore will not support a RESTful HTTP API. They do support TCP, a lower level protocol, which can be supported with additional software on existing hub hardware. Right?

[geko]

You got it. I think it’s a fairly small effort to fix the software. It’s just a matter of priorities and unfortunately it seems to very low on their list.

Raw TCP Socket Communications with sendHubCommand()

So, I’ve proven to myself that one can send raw TCP data with sendHubCommand(). Whatever data I pass to sendHubCommand() is delivered unmodified, which is as raw as it get. This is how my app talks to Mochad X10 gateway in this demo: The question now is how to receive anything back. Currently, the hub sends back empty response, which is enough to confirm that data was sent successfully, but it would be much more useful if I could get data back from the socket. I know that sendHubCommand() takes an undocumented options argument, so the question is if there’s a magic option that can make the hub send reply back to the app?