I’m trying to write a LifX and iTach Infrared driver for SmartThings, as I have done for Ninja Blocks.
Given the documentation for this platform is non-existent - can somebody provide some examples of using sockets within the confines of SmartThings.
I would much prefer a link to documentation if it exists and I just can’t find it - but an example of opening a UDP connection, listening for traffic etc will get me started.
Surely this is not impossible?
I’ve emailed SmartThings directly with zero response, I’ve even messaged via LinkedIn! with no response.
It just does not make sense to not allow IP based communication locally, the lack of documentation is really an embarrassment for the whole platform.
I’m a couple of days away from repudiating the transaction with the bank for “goods not as described” - if I wanted a paperweight, I would have purchased a cheaper one locally and not had it shipped all the way out here at great expense.
I am having exactly the same issues. Very little documentation and what I found is 12 months old. URLs have changed, other minor adjustments that I have to pull example code down to see.
I am in the same boat you are… I shelled out $80 for a couple Arduino shields, and though I am clumsily getting them to work, I have a lot of unanswered questions.
I have a laughable but official response from SmartThings which I can only assume they are too embarrassed to put in here - no, they do not support UDP and TCP.
In essence - you can not create drivers for any networked devices.
Please update all use of the phrase “Internet of Things” to now be “Internet of Things (that don’t use ip networking)”
That’s funny, I have it commanding and listening to network devices just fine. Maybe you didn’t phrase your question right? Or give them the secret password and handshake. <JK’ing.
I also have made some pretty cool things done with the ST arduino shield. An 8/16 station sprinkler controller, parking distance spotter and garage door controller.
I looked at the iTach API and it looks totally doable in ST. What is it exactly that you’re trying to do?
Twack
Any documentation you have / examples would be great twack! 
There are several drivers I wish to write.
They will all need to open a UDP port on a broadcast address and listen for traffic. Once they hear a device they need to know about - depending on the platform - it will then need to open a TCP or UDP port and send / listen for commands.
None of it is rocket science - it’s just that the socket commands are blocked, and there is no documentation on alternatives.
I know the Hub can supposedly do RESTful HTTP - but nothing I have here uses that.
I’m not trying to do anything complex, just use the iTach device as I do in NinjaBlock land… ie - put it in learn mode, learn commands, and then offer those for re-use.
Where can I get this secret password or handshake? 
I’ve been told that TCP / UDP comm’s from a bridge is not possible by SmartThings staff, and that it would be available several weeks ago - but as with everything here… time is very “fluid”.
So what happened Mattro?
were you able to do it?
If so, it would be great if you guys could share how you did it.
No @alex_leiva - ST and in particular @Ben have been silent.
If there is a way to open UDP sockets as @wackware suggests - nobody will share that information with me.
Great!!! but iTach does not support REST; it is a tcp stream (pure ascii-followed by CR). How to send this from device-type? Does hub action support it?
Well, let’s hope to have a more open community. Specially for the lack of documentation from ST.
In an ideal world there would be several scenarios fully documented and with example codes. Since this is not the case we might eventually put together simple reference for future users.
My understanding @alex_leiva and @scottinpollock is that the Hub (as it is now) will more than likely never support TCP / UDP sockets.
@Ben from ST has said there are resource and security issues at play. He was going to have somebody look in to it and get back to me - but as with everything at ST - full of promise, rarely (never?) follow through completely.
but as with everything at ST - full of promise, rarely (never?) follow through completely
Tell me about it!
More than 2 years and I’m still waiting for my Hub!
And it is very disappointing not supporting TCP/UDP sockets. What alternatives do we have?
Now that I figured out how to round trip a local HTTP GET (or post) in a device I can start developing a windows app that will be the proxy between simple socket solutions like UDP or TCP sockets and a simple web service API…
My goal for that app is to bridge ST and socket based devices. I hate to have to do it this way, but until the CoreAPI is opened or documentation is provided on hubAction there is only guessing how to do it.
A simple HTTP Post with the IP, port, type (UDP or TCP) and command to send and then this proxy app will then send that command, wait for response and then return the response to the HTTP Post command.
If I can get some free time this week, I should be able to whip something up in .NET pretty quick.
Well @alex_leiva, @pstuart is right on the money.
The only work around at the moment is to add a third party “proxy”. I have some hackery using NodeJS that I have done some testing with - but it is far from a solution - and I don’t even really consider it a work around.
The idea of having a service running on a PC to do this is not pleasing at all.
I am doing some testing with a PC1 from Push Controls - it is called a BC1 by BitWise Controls everywhere else except Australia and SIngapore. I am fairly sure you can use HTTP calls to trigger serial and IP Sockets events on the device.
In itself - it is also not a solution I like at all. But, it is a bit of a work around to achieve basic functionality in a more robust manner then a service running on a PC.
I need sockets for more than just the iTach devices - I want to integrate with a Ness (Elk outside of Australia) M1 panel. That is an intensive two way conversation - but could add incredible functionality if it were only possible.
I have something like this already (but Mac). It is essentially a bridge to OS X’s unix shell and OSAX scripting. I would not have been able to integrate SmartThings with the rest of my house (most importantly iTachs) without it.
While it would be nice to do all of this on the hub, one thing has occurred to me, and that is the rather finite command structure of the device-type. Without some kind of command parameter parsing within device types, preferable coupled to some form of user-space database, the 100’s of commands needed in my usage model (HT) becomes unwieldy very quickly.
Smart Things do not appear to be interested in supporting UDP support for home automation… this is their response for 2 years… I have tried my best, and even purchased the dev maker kit from kickstarter. I even sent SmartThings free $100s of dollars lighting pack with all our LimitlessLED products, but they still do not respond to my emails. This is the only response I could get out of them…
“I just heard back from our firmware team, we don’t support UDP right now.” -Andrew Urman 27Aug14.
SmartThings is not worth your time or consideration @hamishahern.
They don’t embrace the development community, or wish to interface with the hardware community.
Their product is poorly supported - and not ready for market. Sadly both Ninja and SmartThings are doing huge damage to the “Home Automation” industry by making people think that this sort of rubbish is what they should accept for a home automation product.
I’ve invested heavily both financially and my time in SmartThings - and their product sits in a box now… useless. Not even heavy enough to be a paperweight (like my LifX bulbs).
Wow, trolling. If you don’t like the product, why is it worth your time to come back here?
My 45 devices are working fine, and I like the system. Sure, there are many things that would be valuable to add, but not having them doesn’t make the product useless to me.
Not at all @swanny - I’m not trying to inflame things - simply making what I consider to be accurate statements.
There is no engagement here from SmartThings with a view to making things better - the device is so underpowered that it will never do sockets based comm’s locally (that’s an admission direct from SmartThings staff). This type of communication locally is critical. You list yourself as a programmer - you would know how important it is with home automation.
(As an example - you will see my post above - I am still waiting for @Ben to get back to me from July… Just one of many examples of the lack of engagement).
I think given my contributions here - I am more then within my rights to point out the deficiencies of the product. I’ve tried working out-of-forum with ST to get things resolved and I tried contributing here to make things better - nothing has changed in months.
I’m not swinging in here as a faceless, no-posts, no real name poster. I stand behind what I say.