Socket Connection?

(Patrick Stuart [@pstuart]) #1

Any way to send a socket connection on a specific port and get the response?

For example, if I open a putty connection to a RAW socket I can issue commands and get responses from a lot of different devices…

Is there a way in the physicalgraph.device.HubAction() to send a socket connection on a specific port and monitor the response?

[RELEASE] cast-web 1.0.0 - Chromecast Device Handler & SmartApps
(Geko) #2

Yeah, that would be awesome. Unfortunately, ST supports only HTTP and UPnP protocols as far as I know.

(Matty & Troy) #3

@geko is completely correct, and this may not change for some time.

My understanding is that there are capacity / capability issues within the hub that currently prevent this, in addition to security concerns (I don’t know what that could possibly be - but this is what I have been told).

My suggestion is to completely document the protocol you are looking to use, and supply it to support. This can be handed over to the developers for possible addition in the future.

I have tried to develop both LifX and iTach Infrared devices - but without sockets neither is possible.

(Geko) #4

My guess is that the hub acts just like a dumb proxy when making HTTP request. It’s fairly easy to manage because of its request/response nature. A raw socket connection on the other hand is not transactional and the server-side application is only allowed to run for no more than a few seconds before it gets nuked.

Another option would be to implement a simple HTTP-to-whatever protocol proxy to make ST hub happy.

(Patrick Stuart [@pstuart]) #5

Wow, seems like a raw sockets connection is the simplest form of communication. If it can do a HTTP Post / Get / Push, you would think it could do a simple socket open, send data, receive data, close socket action.

All the functionality is already there in the HTTP commandset, just need to dumb it down. Most systems are this simple:
Open IP:Port
Send ASCII command (maybe a null byte at end of command)
Get response
Close IP:Port

This is exactly what is happening if I sniff the
sendHubCommand(new physicalgraph.device.HubAction("""POST ...""", physicalgraph.device.Protocol.LAN, "HexIP"))
command, but with all the extra HTTP overhead.

It would seem that a slight modification or extension to the physicalgraph.device.Protocol.LAN could be added / changed to physicalgraph.device.Protocol.Socket and the response would be parsed out.

This would give ST access to a ton of simple IP based devices on a LAN that don’t have a HTTP API but function far simpler, ie serial control that moved to IP.

Devices include but not limited to:
-Matrix Switches
-Blind Controls
-Alarm Systems
-Anything over an IP to serial bridge

I’ll try to document it better, but frankly it is so simple, there isn’t much to document.

Maybe the real risk is exposing raw socket capabilities on a cloud connected hub could lead to major issues, but that same risk already exists in modifying the payload of the current HTTP usage.