UDP & TCP Sockets from SmartThings

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.

I understand your point on the hub and sockets, but I haven’t seen them as a critical requirement for home automation. There are so many other devices that can be connected in other ways. Yes, they are required for some use cases, and it sounds like those use cases are most important to you. Sounds like hub 2.0 will upgrade the hardware and maybe it’ll be better for you. Or maybe not. :smile:

As far as engagement, I see them posting all the time and interacting with the community. Unfortunately, the answers aren’t always what people want to hear. In my development experience, it’s impossible to make the software that every one of your customers wants. You just try to do your best at prioritizing the work with the limitations you have.

1 Like

Deep breath…

@hamishahern and @troykelly in one thread. Both from down under and perpetually dissatisfied with everything SmartThings. I am completely sorry that our product does not support your products. I know you each have a financial interest in integrating and so far we have not delivered UDP and TCP socket options that will satisfy your needs. This wasn’t ever a primary part of our promise as a company but we have been listening and making strides to support more of this in the future. I expect the next version of the SmartThings Hub will satisfy many looking for functionality such as this — there may even be some relief in the next firmware version of the current hub — however I am not sure we’ll ever get into your good graces. When we do I will know that we have finally “made it”.

1 Like

LOL, trolling a troll…

@Ben Think its time for a legacy ST hub UDP relay app? Too soon to call it legacy?

I’m guessing this is a sore subject for some people - but is there any movement on this lately? I’m only really interested in look at a ARP tables for improved presence detection. I already have it implemented with a relay, which I’m trying to cut out.

Kristopher

Check out this thread:

What type of query do you want to do for the ARP tables? Where? On the hub or gateway?

Hi Patrick,

On the Hub I want to roll through all devices on the LAN and capture their MAC addresses

arp -n 192.168.1.1
arp -n 192.168.1.2

I was hoping to tie the MAC addresses to mobile presence sensors. Ideally I’d implement a ping as well.

Thanks!

Kristopher

That would be really awesome, I’ve been wanting to do that for a while. I’m really curious on the how your going to code that lovelyness, cause my brain goes to using the TCP socket to poll a snmp device on the network (like a router) to get its arp table, but I’m not geek enough to pull that off.

The mobile presence sensors are zigbee not IP based so what you are looking to do would be very difficult, if not impossible. Although ZigBee devices have Mac addresses, they aren’t pingable in the IP sense.

Hey @sidjohn1

I have a small POC available here. My router currently displays all networked MAC addresses via an internal LAN-only page. I currently poll that page via motion and this simple app:

I also had to update my mobile presence sensor to add the command class. There is also a small tweak in there where I gave it the refresh() capability, to clear out a stuck presence sensor. I manage about 20 devices across 5 locations and I noticed this happens sometimes – if the app crashes while the user is at a location they get stuck there.

I dug a bit into how I might fire an arp command locally from the SmartThings Hub, but it doesn’t seem possible with the current security regime. I believe I might be able to emulate a UDP ping in some capacity or another, so I will probably try that next.

@troykelly - did you find success in getting ST to talk to Bitwise?

@benflux no - still waiting for the “new” smartthings server / hub. ST have been silent.

Allowing TCP would allow us to use the popular TP-Link HS105 power switch. It will also allow integration with many other devices as reported in this forum. Is it expected this year?

It would be nice. I am already controlling the TP-Link bulbs, plugs, and switches using a Windows PC bridge, node.js, and a server application. I also have prototype (and workiing) device handlers that do everything (including encryption) - but still require the hub as a bridge. All i need is the TCP communications to get rid of the bridge. About a four hour fix to go from prototype to working!

Yes, this has gone on too long. We need this API to clean up projects like AlarmServer. Smarthings, what is up? This is hobbling the developer community.

The SmartThings hub does not have the power or ability to allow developer access to sockets.
It will not be a feature offered until there is a new hub, and is not a priority for Samsung.
Samsung have made it abundantly clear the Developer community is not a priority for them (outside of being a sales and advocacy channel). There is no engagement or improvement because of developer feedback - it is simply a form of marketing outreach.
If you are looking for a dynamic, programmable device - you need to look elsewhere, the SmartThings eco system is only for integrated products.

2 Likes

Thank you Troy_Kelly for addressing this issue here.
I got two follow-up questions:

  1. I am also facing the same issue with using the popular TP-LINK HS-100 . Can we expect a device handler from smart things to solve this need?
  2. I value the strive to maintain a device with high reliability, but what is the technical cause preventing TCP/UDP access? Is the QA for this feature to expensive? Is it possible to allow it only to developers, opting-in for this feature? This way most users wont be affected.
    Or is this a hardware limitation?

To be clear @Niv_Gal_Waizer - I don’t speak for Samsung.
I spent a long time arguing the point with ST / Samsung for TCP / UDP access.
As you can see - I started this in 2014.
SmartThings have not really innovated since launch, which is really really sad - but also just a fact of life.
Have you had a look at baking your own solution? A Raspberry Pi with a web service translating to the device?
I started going down that road… but then got annoyed that I had to bolt on a pi just to use my SmartThings.

I’ve been told by SmartThings reps that it’s a hardware limitation, and because of the lack of power within the device - they can’t expose socket connectivity. I can’t wrap my mind around that argument - it seems more like a “business” decision to me - but I’m not in a position to say either way.

Build your own solution for TP-LInk is already done. There are DHs and bridge apps already available in this forum. Just build the hardware (Windows PC, raspberry pi, etc), install node.js (free), the bridge app, the device handler, and the devices.

Hardware platforms for the server are Windows-based PCs (i.e., sticks), Raspberry Pi, and probably any platform supporting node.js. I use an ASUS stick PC that is always on but no monitor/keyboard unless I am changing something. Have run since early February without a problem. There are other cheap windows pc’s and tablets (under $50 on sale incl. Windows) that can do the same.

Of course, you could build a generic UDP/TCP bridge using node.js. Actually, I have already done this moving all functionality except the bridging to smart-things (in a working prototype)