SmartThings Community

UDP Not Possible They Said? Wait, what's this?

(Patrick Stuart [@pstuart]) #1

Hmm, ST said UDP wasn’t possible. They said wait for hub v2. They said it doesn’t work. Well, they were wrong…

Yes Victoria, there is UDP support in the hubaction…

def cmd = "0s6379 c4.amp.chvol 02 e0"
    def ip = ""
    def deviceNetworkId = "C0A86566:222E"
    def x = new physicalgraph.device.HubAction("${cmd}\r\nHOST: $ip\r\n\r\n", physicalgraph.device.Protocol.LAN)
    x.options = [type:"LAN_TYPE_UDPCLIENT"]

Results in getting the following response:

index:00, mac:000FFF121004, ip:C0A86566, port:222E, type:LAN_TYPE_UDPCLIENT, payload:307236333739203030300D0A

Yeah, that payload means that the command to set the volume to my Control4 16 channel Amp just got set.

Its all because of the hubaction.options = [type:“LAN_TYPE_UDPCLIENT”] and all because someone broke S3 today did I decide to poke around in it.

I’m a happy camper. I can finally, after almost a year, mute or turn up/down my whole house audio and finally integrate the sonos connected to it via ST.

Local v2 Hub Functionality
What Happened to deviceNetworkId?
Running ST locally, DIY control panel, and feasibility
Lutron RadioRA Integration
UK supported devices
Lightwave RF Integration (UK)
Action based on tcp ping
Can I develop an app that will work with Phidget devices?
(jjsapido) #2

Hey Patrick, thanks for your big effort in ST community.
I tried to implement some UDP calls following your suggestion… unfortunately i always obtain

groovy.lang.MissingMethodException: No signature of method: script14286146292671354638572.sendHubCommand() is applicable for argument types: (physicalgraph.device.HubAction) values: [null

] @ line 146

it looks the sendHubCommand doesn’t work for me… is there anything i did wrong?

i actually implemented the following method:
private sendCommand2(command, method = “get”, success = {}){
def ip = “”

def deviceNetworkId = "C0A80298:22C3"
def x = new physicalgraph.device.HubAction("${cmd}\r\nHOST: $ip\r\n\r\n", physicalgraph.device.Protocol.LAN, , "${deviceNetworkId}")
x.options = [type:"LAN_TYPE_UDPCLIENT"]

log.debug(“sent test command”)
log.debug location.hubs*.firmwareVersionString.findAll { it }

Thanks for help

(Patrick Stuart [@pstuart]) #3

Are you trying to do this from a SmartApp or DeviceType?

My code above only works in a DeviceType. There is a separate way to call it in a SmartApp, but I haven’t tested that.

Try adding the deviceNetworkId to the end of your hubaction like this:

def x = new physicalgraph.device.HubAction("${cmd}\r\nHOST: $ip\r\n\r\n", physicalgraph.device.Protocol.LAN, , "${deviceNetworkId}", deviceNetworkId)

This should give the SmartApp the place to reroute the parse action back to something handling location.

(jjsapido) #4

I confirm you I was writing a device type from code
Do you have any published device type I can try?

(Patrick Stuart [@pstuart]) #5

Well, it appears it might be even more simple.

You are sending no commands to the hubaction.

Might want to change ${cmd} to ${command} and see if that works.

(jjsapido) #6

I checked and the command variable appear empty as you suggested
i fixed it, I just wrote some text into the command (i.e. 64 00 85), I threat it as a string is that correct?

def x = new physicalgraph.device.HubAction(“64 00 85\r\nHOST: $ip\r\n\r\n”, physicalgraph.device.Protocol.LAN, , “${deviceNetworkId}”)

here’s still the same error
00:18:14 CEST: error groovy.lang.MissingMethodException: No signature of method: script142861784000633107159.sendHubCommand() is applicable for argument types: (physicalgraph.device.HubAction) values: [64 00 85

] @ line 154

(Patrick Stuart [@pstuart]) #7

def x = new physicalgraph.device.HubAction(“64 00 85\r\nHOST: $ip\r\n\r\n”, physicalgraph.device.Protocol.LAN, , “${deviceNetworkId}”)

def x = new physicalgraph.device.HubAction(“64 00 85\r\nHOST: $ip\r\n\r\n”, physicalgraph.device.Protocol.LAN)

(jjsapido) #8

here’s the new code according to your suggestion:

def ip = ""
def deviceNetworkId = "C0A80298:22C3"

def x1 = new physicalgraph.device.HubAction("64 00 85\r\nHOST: $ip\r\n\r\n", physicalgraph.device.Protocol.LAN) 
/*def x = new physicalgraph.device.HubAction("64 00 85\r\nHOST: $ip\r\n\r\n", physicalgraph.device.Protocol.LAN, "${deviceNetworkId}"*/
x1.options = [type:"LAN_TYPE_UDPCLIENT"]
sendHubCommand(x1)               <- this is line 151

Unfortunately i still receive the same error…

1:42:27 PM: error groovy.lang.MissingMethodException: No signature of method: script14286661472771337409123.sendHubCommand() is applicable for argument types: (physicalgraph.device.HubAction) values: [64 00 85

] @ line 151

(Patrick Stuart [@pstuart]) #9

Sorry, I was mistaken above. I had two code testing areas, a deviceType and SmartApp. This code should work in a smartApp not deviceType.

I haven’t tried making this work in a deviceType, sorry for the confusion.

(jjsapido) #10

Thanks for all your support… I will try to write a smartapp then…

(Davis Darvish) #11

Sorry for the total n00b like questions… how is having UDP useful?

(Patrick Stuart [@pstuart]) #12

A ton of simple av devices use a raw UDP socket to send and receive commands ala telnet or serial.

Having UDP packets along with TCP packets allows communication with practically anything on a local network. Before this discovery it was only limited to TCP.

(Dan) #13



This is very intriguing to me. Is there anyway for a LAN device to send a UDP packet to a Device Type? Looking for true two-way UDP traffic between a device type and a LAN device, without having to poll the LAN device from the ST Cloud. Would love to have a Raspberry PI be able to initiate data updates to a Device Type without having to be polled.


(Patrick Stuart [@pstuart]) #14

True UDP will be a long way off, maybe possible in Hub v2?

Right now, the limits on UDP are having to send one command and wait for it to time out. The response back is then available after that time out (about 20 seconds).

I think you will find that eventually Hub v2 will process everything locally that it can and what you are wanting to do will be closer to possible, who knows…

1 Like
(Dan) #15

Thanks Patrick. Here’s to hoping Hub v2.0 is everything to everyone!

(Kristopher Kubicki) #16


Do you know what sits above parse()? Is it accessible? From the relatively little I know about ST guts, its that the return packet is coming back into the ST Hub, its just not being sent down to the parse(). I think this is something about the architecture where the whole packet has to go back to the cloud before coming back to parse()

How did you find that UDP flag again?

(Patrick Stuart [@pstuart]) #17

As far as I can tell, parse is way downstream from the relay the hub does.

Essentially hub v1 is a stupidly simple device. It’s a radio stack for zigbee and zwave and basic IP functions to communicate with the cloud services.

The local hubaction originates in the cloud, sends the request down to the hub, out over ip, leaves the port open and waits for a response, ala a web browser request. Then the response is relayed back up to the cloud for processing.

This is where the issue is, there is frankly nothing that can be really done locally on the hub without the cloud completely controlling it.

The response is parsed in the cloud and based on the DNI it routes it to the appropriate devicetype bound to that DNI or in the case of smartApps it routes it to the location (hub location) handler for ANY smartapp to parse.

So I think you are probably wanting to dig into the location handler and not the parse function. However, that code only exists cloud side (for now, hub v2? maybe local) and isn’t user accessible.

I found the UDP flag via a lengthy search and putting together lots of pieces of a puzzle, but ultimately not accepting that it isn’t possible to do.

Essentially, once I realized they were wrapping the basic httprequester function in java into the hubaction, it was clear that UDP could be done, it was just a matter of how it needed to be configured.

Just keep in mind the local hubaction commands are completely not supported (my words, not ST) and will probably depreciate them soon as hub v2 eventually launches and should have a much more robust local network support (maybe?).

We’ve come a long way since a year ago with hubactions locally, however, very little has changed or has been shared from ST. This has been a complete hack by end-users / community developers.

Too bad really… Would be nice to pull aside the komono a bit and show us exactly what could be done with hub v1 and not just tell us to wait (forever?) for hub v2.

Anyway, maybe someday soon the local network support for ST will be feature rich and allow true integrations with anything. I won’t be holding my breath, instead, I’ll keep firing up packet sniffers and watching packets and asking the same questions in different ways until I find that one piece of knowledge I need to make it work. (then they will break it, again… Go figure.)

(Kristopher Kubicki) #18

OK nice. So you dug into httprequester to find this? That is probably a place where a bunch of other useful interaction exists. I will look at that more


(Patrick Stuart [@pstuart]) #19

Not exactly, I found they seem to be using it. I found the flags from a hint someone gave me related to how s3 worked. Put two and two together and I got lucky.

1 Like
(Kristopher Kubicki) #20

Hey Patrick,

Have you found a “timeout” flag? That would let us cut down the latency on a bunch of UDP and TCP devices a lot!