UDP broadcast support


#41

Thanks @rob and @djgutheinz I'm thinking I'm at the end of my rope on this, I was looking at doing an integration for the Broadlink rm mini3 but the protocol is complex and one thing I need is the source port of the connection which doesn't look like I'll get in this scope.

It looks like I'm going to have to go to a fall back intermediate service unless anyone else has ideas? By the way this is the protocol


#42

Aaaargh! That's the last device I need to port over. Damn thing works great once you get past the clunky app. But I'm not keen on (A) apps and (B) phoning home to China.


#43

Looking at that you may be out of luck with the current UDP implementation since it will only currently accept a single message.

By source port do you mean the port that the device sends the response from? That should be available in the description parameter that is passed to the parse() method of your device handler.


#44

Having said that, what you might want to do is use the python code for discovery on a PC and then copy and paste the relevant output into input fields in your device handler, at least as a temporary solution.


#45

Yeah I think I'm just going to deploy a full http endpoint on a intermediate machine and then setup a simple driver to execute http commands. Thanks for the info guys!


#46

I gave up on this too for xAP support.

I was also disappointed with TCP socket support.

It seemed an obvious thing for Hubitat promote that differentiated it from ST.


#47

I'm sure better support will come in a later release


#48

Pretty cool seeing all this come together.


split this topic #49

A post was split to a new topic: UDP Feature Request


#50

UDP Comms Error Handling with Application

I created a device handler with a "UDP Polling" capability to discover the devices and update the IPs (in the rare circumstances they occur). In stead of a periodic refresh of the IPs, I have decided to do polling base on a "commsError" event triggered in the device. This will then preclude the polling from occurring except when running the application or when a device is unreachable (i.e., there is no response to a command within 3 seconds. The relevant code methods are below:

Driver Error Triggering Code:

def parse(response) {		//	4.2.01
	unschedule(createCommsError)
	sendEvent(name: "commsError", value: "none")
}
private sendCmd(command) {		//	4.2.01
	runIn(3, createCommsError)	//	Starts 3 second timer for error.
	def myHubAction = new hubitat.device.HubAction(
		outputXOR(command), 
		hubitat.device.Protocol.LAN,
		[type: hubitat.device.HubAction.Type.LAN_TYPE_UDPCLIENT,
		 destinationAddress: "${getDataValue("deviceIP")}:9999",
		 encoding: hubitat.device.HubAction.Encoding.HEX_STRING])
	sendHubCommand(myHubAction)
}

def createCommsError() {		//	4.2.01
	sendEvent(name: "commsError", value: "deviceOffline",descriptionText: "Comms Error. Device offline. See logs.")
	log.error "${device.label}: Communications Error. Device is offline." +
				"\nTP-Link Device Manager will attempt to recover." +
				"\nYou may also run this application to attempt a manual recovery."
}

Application Code (including scheduling events):

def initialize() {
	unsubscribe()
	unschedule()
	if (selectedDevices) { addDevices()	}
	runIn(5, deviceSubscribe)		//	4.2.01
}

def deviceSubscribe() {		//	4.2.01
	def devices = getChildDevices()
	devices.each { d ->
		subscribe(d, "commsError", commsErrorHandler)
	}
}

def commsErrorHandler(evt) {		//	4.2.01
	if (evt.value == "deviceOffline") {
		runIn(30, discoverDevices)
	}
}

Note: The runIn(30, discoverDevices) updates the IPs. The delay is to prevent multiple requests for the same instance.


#51

I'm just going to throw something out there for UDP.
I have LightwaveRF devices that I believe, but am not sure because I know nothing about these sort of things, are using UDP.
I just followed the instructions and it worked!!!! :smile:
My reasoning is that it is mentioned in the ST thread below.

In my setup I have a LightwaveRF hub (LW) with a reserved IP address (as is my HE hub and RPi).
HE sends a message to turn on the LW dimmers/switches to the LW hub via an RPi.

image

Now I'm not sure if this helps at all with what you guys are trying to achieve but I just thought I would post this information in case it can help you in some way.


#52

Your implementation looks like it uses an external hub.

BTW - My TP-Link devices are working fine using UDP. Using UDP, the device does not require a raspberry Pi or other device. My post above was showing how I am reducing UDP traffic if the IP changes (not everyone sets a static IP address).

Thanks for the information.