Catch UDP Timeout warning?

🚧 Developers
21

UDP, particularly broadcast has not had any serious attention or mindset from Hubitat. Which for a 'local' hub is surprising. UDP by design is fire and forget.

I adopted HE for it's local functionality - unfortunately for UDP I have had to use an alternative now, which invalidates my choice in the primary case.

You still can't handle ad hoc incoming UDP messages to HE.

22

I agree. I’d really like to see enhanced UDP support. It would open up a bunch more integration possibilities

1 Like
23

Here is my frustration - what is local ? HE markets itself as such

In a strict sense this is what interaction can happen locally ...

For Z-Wave and Zigbee all interaction is local.
For TCP all interaction could be local or cloud
For UDP most practical interaction would be local but cloud although possible but unreliable.
There are other supported interactions e.g. Bluetooth (local) and others exist but are not well supported if at all.

So TCP is available locally and so is UDP - why is UDP not supported fully on a 'local' featured and promoted hub?

Half baked

24

Because the average user isn’t clamoring for it.

25

I agree but 'local' is the differential feature and it should be fully exploited / supported. TCP and UDP are the significant protocols, otherwise it's really just only a local hub for TCP.

26

As a reality check I now choose to use another hub for 'local' IP as it fully supports TCP and UDP.

Now admittably I'm a more advanced user probably then most but I'm sad to relegate HE as a preference because it doesn't fulfill it's key differential feature of 'local' - but aside it's Z radio support is still attractive and fully featured .. but not unique.

27

In the hubAction setup, set parseWarning to true. This then passes the error to the parse method for the sendHubCommand. Below is my sendCommand method with these parameters. After that is one of the parse methods (action) I use to show how I handle the error. In the parse method, I look for type "LAN_TYPE_UDPCLIENT", meaning a non-error response. Otherwise, my method setCommsError runs, which includes calls the repeatCommand method. To enable this, I use a state.lastCommand to capture the command and use if the repeat is necessary. I think it actually works quite well.

private sendCmd(command, action) {
	logDebug("sendCmd: action = ${action}")
	state.lastCommand = [command: "${command}", action: "${action}"]
	sendHubCommand(new hubitat.device.HubAction(
		command,
		hubitat.device.Protocol.LAN,
		[type: hubitat.device.HubAction.Type.LAN_TYPE_UDPCLIENT,
		 destinationAddress: "${getDataValue("deviceIP")}:9999",
		 encoding: hubitat.device.HubAction.Encoding.HEX_STRING,
		 parseWarning: true,
		 timeout: 5,
		 callback: action]
	))
}

def commandResponse(response) {
	def resp = parseLanMessage(response)
	if(resp.type == "LAN_TYPE_UDPCLIENT") {
		state.errorCount = 0
		def status = parseJson(inputXOR(resp.payload)).system.get_sysinfo
		logDebug("commandResponse: status = ${status}")
		def onOff = "on"
		if (status.relay_state == 0) { onOff = "off" }
		if (onOff != device.currentValue("switch")) {
			sendEvent(name: "switch", value: onOff, type: "digital")
		}
		logInfo("commandResponse: switch: ${onOff}")
		if (state.pollFreq > 0) {
			runIn(state.pollFreq, quickPoll)
		}
	} else {
		setCommsError()
	}
}

def repeatCommand() { 
	logWarn("repeatCommand: ${state.lastCommand}")
	sendCmd(state.lastCommand.command, state.lastCommand.action)
}

The entire driver can be viewed at: https://raw.githubusercontent.com/DaveGut/HubitatActive/master/KasaDevices/DeviceDrivers/Plug-Switch.groovy