Help with UDP

🚧 Developers Coding Questions
1

I'm trying to get a Wi-Fi T-Smart Immersion working - the device does communicates fine so it's not the issue.

Here my code - based on stuff I found here in the community.

def read() {
byte[] rawBytes = [0xF1, 0x00, 0x00, 0xA4]
String stringBytes = hubitat.helper.HexUtils.byteArrayToHexString(rawBytes)
def myHubAction = new hubitat.device.HubAction(
stringBytes,
hubitat.device.Protocol.LAN,
[
type : hubitat.device.HubAction.Type.LAN_TYPE_UDPCLIENT,
destinationAddress: "192.168.199.59:1337",
encoding : hubitat.device.HubAction.Encoding.HEX_STRING
]
)

def response = sendHubCommand(myHubAction)
log.debug "response from sendHubCommand ${response}"
}

The response I get to the log.debug is "response from sendHubCommand java.util.concurrent.FutureTask@159748b"

Each time I try it the response is the same except for the bit after the "@"...

Anyone any idea what's going on???

Thanks,
Simon

2

My recollections - been a while since I dabbled in this area... The HubAction is asynchronous, so you don't need to store the sendHubCommand output in a variable. Instead, when the hub receives a response, it will be passed to a parse method that you define in your driver, or you can specify a callback arg in the options map for the HubAction for a custom method to be called with the response.

3

Thank you. I'll play around with a parse method

4

Here's where I'm at....

def read() {
  byte[] rawBytes = [0xF1, 0x00, 0x00, 0xA4]
  String stringBytes = hubitat.helper.HexUtils.byteArrayToHexString(rawBytes)
  def myHubAction = new hubitat.device.HubAction(
        stringBytes,
        hubitat.device.Protocol.LAN,
        [
                type              : hubitat.device.HubAction.Type.LAN_TYPE_UDPCLIENT,
                destinationAddress: "192.168.199.59:1337",
                encoding          : hubitat.device.HubAction.Encoding.HEX_STRING,
		        callback: parseUDP
        ]
  )
}

def parseUDP(message) {  
  log.debug "Got something to parse"
  log.debug "UDP Response -> ${message}"    
}

But not getting a response......... I've tested the device with WireShark from a PC, so I know my command, port, etc are all correct and that the device does respond.

Any insights appreciated.

5

try callback: "parseUDP" -- I think the method should be provided as a string.

6

Nope - tried it - not that.

The UDP examples I see here in the community don't have the callback name as a string in quotes.

7

Hmm... You could also play with the following in the options map:

ignoreResponse: false,
parseWarning: true,
timeout: NNN

default timeout is 10 seconds, maybe your device takes longer?

8

I've already tried those (with the exception of ignoreResponse, which does not seem to make a difference).

There does not seem to be any significant delay with the device response when I do it from a PC and monitor with Wireshark - seems instantaneous.

Here what i have now:

def read() {
  byte[] rawBytes = [0xF1, 0x00, 0x00, 0xA4]
  String stringBytes = hubitat.helper.HexUtils.byteArrayToHexString(rawBytes)
  def myHubAction = new hubitat.device.HubAction(
        stringBytes,
        hubitat.device.Protocol.LAN,
        [
                type              : hubitat.device.HubAction.Type.LAN_TYPE_UDPCLIENT,
                destinationAddress: "192.168.199.59:1337",
                encoding          : hubitat.device.HubAction.Encoding.HEX_STRING,
                ignoreResponse: false,
                parseWarning: true,
                timeout: 10,
		        callback: parseUDP
        ]
  )
  sendHubCommand(myHubAction)    
}

def parseUDP(message) {  
  log.debug "Got something to parse"
  log.debug "UDP Response -> ${message}"    
}
9

Question: did you try using a default def parse(message) method?

10

Since you've already fired up Wireshark, I'd recommend just troubleshooting using that.

Capture the command packet being sent by the PC, then with Hubitat. Is a packet being sent by Hubitat? If so, how does it differ from the one being sent by the PC (which works)?

What application are you using on the PC to send the command?

1 Like
11

Yes - tried that. No joy.

12

I used Node-Red on a Windoze PC to send command and used Wireshark view both the command and the response.

I've not been able to get Wireshark to view the communications from Hubitat - I think my Unifi network is filtering the traffic - however if I send a command to 255.255.255.255 I do then see it, but can't see the response. i had a quick look to see how I can get Unifi to stop filtering - but that's not obvious.

I don't see any difference in the packet sent by Hubitat (using the broadcast address for testing) and by the PC - so I assume the device is responding correctly to Hubitat... but my code never receives in anything.

Thank for the suggestions

13

Regarding your suspicion of your network not routing the command and/or response, what leads you to believe that? Are there any network rules that apply to routes between your PC and the device that don't apply between Hubitat and the device? Are they in different VLANs or networks?

Just to be clear, when you send the command from the PC is it directly to the device IP (and not broadcasting to 255.255.255.255)? Is the reply you see in Wireshark directly to the PC IP?

Just throwing out random ideas now, are there any commands that you can send that would have a noticeable effect on the end device without needing to see a network response back on the Hubitat side? Or are there logs on the device that you could use to confirm that the command is reaching it in the first place?

14

I'm just guessing at what may be going on..... I've no network rules on my internal network, no VLANS.

Sending a read command directly to the IP address of the device from node-red on my PC and running Wireshark on the PC gives me:

image
image962×530 16.5 KB

...and all this looks correct.

When I do the same command from Hubitat I get nothing in Wireshark and I'm thinking this is because my Unifi network knows where IP addresses are and it routes accordingly. I've looked to see if there is a promiscuous mode setting on the network and I don't see one.

There is a phone app for the device and it works fine. In Wireshark on the PC I see frequent broadcasts from the phone to 255.255.255.255 on the port the device uses - this further supports my theory that my network is filtering traffic. If I mimic this broadcast from Hubitat I see the same thing in Wireshark.

From Hubitat I can send the UDP command to turn the device off and that works fine, device goes off..... proves that UDP communication from Hubitat to the device works - I just dont get a response.

I don't need to do anything to open the port for Hubitat to read the response ?????

Here's my current code....

private read() {
  byte[] rawBytes = [0xF1, 0x00, 0x00, 0xA4]
  String stringBytes = hubitat.helper.HexUtils.byteArrayToHexString(rawBytes)
  def myHubAction = new hubitat.device.HubAction(
        stringBytes,
        hubitat.device.Protocol.LAN,
        [
             type              : hubitat.device.HubAction.Type.LAN_TYPE_UDPCLIENT,
             destinationAddress: "192.168.199.59:1337",
             encoding          : hubitat.device.HubAction.Encoding.HEX_STRING,
             ignoreResponse    : false,
             parseWarning      : true,
             timeout           : 10,
		     callback          : parseUDP
        ]
  )
  sendHubCommand(myHubAction)    
}

def parseUDP(message) {  
  log.debug "Got something to parseUDP"
  log.debug "UDP Response -> ${message}"    
}

Many thanks for your assistance.

15

What happens if you change parseUDP to parse? (Callback should override, but…)

16

Tried that - no difference............

17

Well by definition, IRRC, UDP doesn’t require the device to respond, so maybe it is working as designed?

18

Nope. On my PC, using node-red - I can send out the read command to read the temperature and I get the response back into node-red. In Wireshark all looks perfect.

19

Is the device on the same subnet as your hub?

20

Sure is