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

pstuart · April 24, 2015, 8:52pm

Haven’t looked. Let me know if you find anything but I suspect its hard coded.

amirf · May 3, 2015, 11:46pm

Thanks for this great find.

I am a little newbie here. I created a Device Type and got the UDP thing to work however the messages seem to be queued up. So either two messages (on and off) are sent right after each other or the one prior to the last UDP message is sent. Here is my code:

// parse events into attributes
def parse(String description) {
	log.debug "Parsing '${description}'"
	// TODO: handle 'switch' attribute
	// TODO: handle 'level' attribute

}

// handle commands
def on() {
	def cmd = "0x35 0x00 0x55"
    def ip = "192.168.1.126:8899"
    log.debug "Executing 'on':\r\n${cmd}\r\nHOST: $ip\r\n\r\n"
    def hubCmd = new physicalgraph.device.HubAction("${cmd}\r\nHOST: $ip\r\n\r\n", physicalgraph.device.Protocol.LAN)
    hubCmd.options = [type:"LAN_TYPE_UDPCLIENT"]
    return hubCmd
}

def off() {
	def cmd = "0x39 0x00 0x55"
    def ip = "192.168.1.126:8899"
    log.debug "Executing 'off':\r\n${cmd}\r\nHOST: $ip\r\n\r\n"
    def hubCmd = new physicalgraph.device.HubAction("${cmd}\r\nHOST: $ip\r\n\r\n", physicalgraph.device.Protocol.LAN)
    hubCmd.options = [type:"LAN_TYPE_UDPCLIENT"]
    return hubCmd
}

I’m not sure what’s happening but is there a way to flush the to be sent queue (if there’s such a thing)?

pstuart · May 3, 2015, 11:55pm

Not sure what the issue is, but in my testing, there is about a 20 second timeout with the port open. Which means that if another hubaction fires on that port within that timeout, then it will fail.

Not sure about queuing, there is something of a queue, but no idea how to access it.

Kristopher · May 4, 2015, 12:34pm

I’ve noticed the connection may close on a variable rate per device (my Sharp is about 9 seconds, my Yamaha is indefinite). Some devices let you stack commands on top of each other, and some don’t, like my Sharp TV.

I wrote some very primitive non-blocking here:

github.com

KristopherKubicki/device-sharp-aquos/blob/master/device-type-sharp-aquos.groovy

/**
 *  Sharp Aquos TV
 *     Works on Sharp TVs
 *    Very basic asynchronous, non-polling control of most Sharp TVs made since 2010
 *   NOTE: PLEASE HARDCODE THE INPUTS YOU WANT TO CONTROL ON LINE 92
 *
 *    Losely based on: https://github.com/halkeye/sharp.aquos.devicetype.groovy
 *   and page 36 of this manual http://snpi.dell.com/sna/manuals/A1534250.pdf
 */

preferences {
	input("destIp", "text", title: "IP", description: "The device IP",required:true)
	input("destPort", "number", title: "Port", description: "The port you wish to connect", required:true)
	input("login", "text", title: "Login", description: "The login")
	input("password", "password", title: "Password", description: "The password")}
 

metadata {
	definition (name: "Sharp Aquos", namespace: "KristopherKubicki", 
    	author: "kristopher@acm.org") {

This file has been truncated. show original

Ideally, we’d just send a flag to reduce the timeout and thus flushing the buffer. I didn’t find anything like that yet, but I’m highly confident it exists.

geko · August 30, 2015, 11:23pm

Hey Patrick, could you confirm this works in a SmartApp? For the life of me I cannot get it to work.

I open listening UDP socket with netcat:

nc -luv 4001

and can talk to it from another host on the same LAN, but not from the hub. I see outgoing hubAction in the logs, but nothing arrives at the UDP socket.

hamishahern · September 29, 2015, 2:48pm

did anyone find a v1 hub timeout flag for this? or find a better udp local function in v2 hub?

Kristopher · October 7, 2015, 2:29am

I’m starting to look at this again now that I have a v2. We’ll see!

AutomateEverything · October 7, 2015, 2:40am

Total rookie question, but i love to learn and know what is what wherever i can to tey better by own knowledge on ST hahaha

This all sounds super interesting and even more so as you mentioned V2, what kind of integrations could this open up that were not possible before, what use cases / devices / integrations do you see been able to utalize this ?

hamishahern · October 14, 2015, 3:54pm

TCP seems to work… kinda

smurphy · October 20, 2015, 9:37pm

Hi Patrick , Sorry if I’m late to the party here but this is great stuff. I’m interested hearing you are controlling the Control4 Amp as this is something I’ve been wanting to do. I was wondering if you know the list of commands that the Amp responds to as I can’t find any information on that anywhere. Any pointers would be greatly appreciated.
Thanks

zuperman4ever · October 21, 2015, 1:12pm

With it connecting to the MiLight does it just do the main hub to dim all lights at the same time? Does it let us change the light color? If I have 4 light strips working will I be able to connect to all four and change them independently?

tonesto7 · November 12, 2015, 6:21pm

So is this possible?

Send a UDP multicast/broadcast message to IP 269.255.255.250 on port 1900 to scan for LG TV's?

pstuart · November 12, 2015, 7:28pm

No, not using today’s implementation of the hub action.

hamishahern · November 17, 2015, 7:01am

Seems that this option has been removed from the Smart Things hub library. I am hoping they bring it back in the next update.

theli · February 16, 2016, 8:01pm

Aww, such a shame they removed local UDP, was looking to make an ONKYO receiver discovery/handler without using any intermediate service but this kills it

allanak · February 17, 2016, 7:33am

Onkyo eISCP uses TCP. Maybe you can’t do discovery anymore, but if you give your receiver a static IP its not an issue. I built an awful handler that can at least send commands but doesn’t parse/query anything.

github.com

allanak/SmartThings/blob/master/onkyoIP.groovy

/**
 *  Onkyo IP Control Device Type for SmartThings
 *  Allan Klein (@allanak)
 *  Originally based on: Mike Maxwell's code
 *
 *  Usage:
 *  1. Be sure you have enabled control of the receiver via the network under the settings on your receiver.
 *  2. Add this code as a device handler in the SmartThings IDE
 *  3. Create a device using OnkyoIP as the device handler using a hexadecimal representation of IP:port as the device network ID value
 *  For example, a receiver at 192.168.1.222:60128 would have a device network ID of C0A801DE:EAE0
 *  Note: Port 60128 is the default Onkyo eISCP port so you shouldn't need to change anything after the colon
 *  4. Enjoy the new functionality of the SmartThings app
 * 
 *  Licensed under the Apache License, Version 2.0 (the "License"); you may not use this file except
 *  in compliance with the License. You may obtain a copy of the License at:
 *
 *      http://www.apache.org/licenses/LICENSE-2.0
 *
 *  Unless required by applicable law or agreed to in writing, software distributed under the License is distributed
 *  on an "AS IS" BASIS, WITHOUT WARRANTIES OR CONDITIONS OF ANY KIND, either express or implied. See the License

This file has been truncated. show original

theli · February 17, 2016, 5:30pm

Thanks, Alan, I know it uses TCP and UDP is only used for discovery. Still, without ability to receive raw TCP payload in response querying anything is impossible.
And thanks for your handler. It would be possible to tie a poor man’s discovery to it using SSDP (as all of them are also DLNA renderers, and one can just match manufacturer == ONKYO).

batlin · November 13, 2016, 5:29pm

Is there any updated on Smarthings and UDP? I saw one post where they said that the command was disabled. Is this true? I have been trying to control a device in my house that only accepts UDP packets and I just cannot get it to work. Wireshark also shows no UDP packets being sent

nevir · January 3, 2017, 4:44pm

Also curious whether this still works, and/or whether there are better ways to talk UDP

KellyDarren · January 10, 2017, 5:53pm

I see @Jared is asking the same question here Haven't stopped by in a while -- is there UDP support yet?

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

Customers

Developers

Download the SmartThings App