Yes… I just sent a command (XML) to port 5020 on my Control4 controller and turned on a light in my control4 environment.
Can’t get the response back yet, still working on if this is possible…
Moving over to a devicetype to see if there is a response there…
I wonder if there were changes to the SSDP discovery methods as well. I can now discover a ton more devices on my network…
Oh the fun I can have… I can now detect a Control4 Controller via SSDP as well…
Now, just give me a response handler and I’ll be a happy camper… Just need to parse about 15 megs worth of xml to get all the devices in my Control4 Project… Yikes…
Could anyone from ST side please comment on this. Community would really appreciate it. Thanks. 
We spoke a bit about this (I think) on the Developer Discussion tonight and I think there is ight at the end of the tunnel but maybe @doug-st should comment.
Does anyone know what the response looks like? I believe the parse method only passes up valid HTTP responses. @adam (who is out this week) - is still currently true?
I also would really like this feature. I’ve been very excited to hook up my tv as a trigger, but it only has a tcp/ip api.
For now I’m going to make a web based proxy to sit in the middle since smartthings can handle web better, but it means its not very portable.
Yes, response in most cases is just plain text, so no HTTP header or Response code.
It should be easy to fake a header and parse this on the hub side. The biggest issue is the size of the request is limited to some unknown limit (really small)
Wish we could implement some sort of S3 Image like handler so the response for the device goes up to the cloud and then we can do what we need to it from the cloud.
Raw packets (TCP only, no UDP) can be sent to devices in the device code (not smartapps) and it does work, but without a response no way to get two way info…
Very limiting in moving forward with basically any future integration… Writing a proxy / relay is the only real option.
Anyone interested in an open source, .NET windows service / HTTP proxy? I am willing to start a project and see if anyone wants to help build it out.
The hub doesn’t actually interpret the data. All non-discovery LAN socket traffic goes up to the cloud where the cloud looks for a valid HTTP frame to pass a whole response up to the device type. This allows a developer to handle the whole response in one ‘event’ rather than having to reconstruct the buffer or worse, not know if the whole frame was received or not.
The requests and responses aren’t size limited rather time limited to ~ 8 seconds for a whole request response transaction. If the Raw Socket flow was used, this RESTful timeout doesn’t apply.
Currently for this to work we are waiting on the RAW socket feature support to be added to the cloud. Hoping we get this out soon as well!
Raw TCP send does work from smart apps as well (or rather as poorly) as from device.
@geko were you able to get a response from a device/service using this raw socket implementation with sendHubCommand?
Nope. After more than a year waiting for a response, I think it’s safe to say it’s never going to happen. 
One last shot, @slagle @jody.albritton - do you think this can be done? It has basic support using LAN protocol, do you think it could be enhanced to provide a raw return value from the other end of the socket?
We’re talking about this internally. It’s not as easy as just putting a library on the hub unfortunately.
Another feature in this same genre that would be nice is an XMPP library that could be used from a smart app to talk with a device on my local network. I am sure that is not a simple request either but I do have a couple of devices on my local network that talk XMPP but today I have to communicate with an app running on my mac that act as a proxy between my ST app and the XMPP device. With a raw TCP socket i could probably do what I need but the actual protocol support would be even better!
Would you care to elaborate as to why it’s not this simple? Can you not just allow us to use the built in java socket object, instead of throwing a security exception? I understand there is some complexity for the simulator, but that seems simple enough to just mock the socket and send it to the UI?
Hi @geko would you mind sharing your complete hubCommand code? There’s plenty of people around struggling, apparently, like me. I’m also trying to send a tcp packet. So far I have a workaround with an arduino with ethernet shield and web server so I could send httpGet() commands. But if I could send raw tcp instead directly to my devices that’d be really useful. Mind sending your code? So far I can’t send any packet via the HubAction
I’ve managed to send out, but all responses are blank. We really need a message.raw option