UDP broadcast support

I'm doing the same thing as you (and thanks again for the idea), it would be great if the port could be made to stay open, e.g. by returning something from the parse method. But it seems fast enough.

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

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.

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.

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.

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!

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.

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

Pretty cool seeing all this come together.

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

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
	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(
		[type: hubitat.device.HubAction.Type.LAN_TYPE_UDPCLIENT,
		 destinationAddress: "${getDataValue("deviceIP")}:9999",
		 encoding: hubitat.device.HubAction.Encoding.HEX_STRING])

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() {
	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.

1 Like

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.


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.

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.

So, this has been great. I have a working driver for a WiFi connected smoker working with the UDP client functionality.

Unfortunately, for me to be able to have a driver for the Meater+ Block (a wireless thermometer) or my Christmas Lights (a UDP protocol on an ESP8266) I need the ability to just listen for all broadcasts like has been suggested in this thread by a couple of others.

Both my thermometer and light controllers appear to just spew information constantly rather than have it requested. Is there a way I can get that traffic?

Thanks in advance! (I've very excited to have my smoker in Hubitat.)

1 Like

No, but you could do it in something like node-red or Home Assistant and write the value to a virtual device with maker API or mqtt.

Any time I see someone say "you could use Home Assistant for this" then I wonder... why use Hubitat? I'm not saying I plan to switch, but when the solution is "use a competing product for that feature" I guess I wonder, won't that just encourage people to switch to that product?

1 Like

If Home Assistant had as robust and flexible zigbee and zwave device support, i likely would switch to it entirely.

If Hubitat had as much processing power as I can have in Home Assistant and as good of cloud device/service integration I might ditch Home Assistant altogether.

But the fact is neither is perfect, and each has different strengths and weaknesses. As such, I think they complement each other nicely, and neither is a great full replacement for the other.


If you send out a packet, say, every 5 seconds, will the device’s constant transmissions get picked up in that and act like a response?

Node-RED is really not a competing product to HE , it's more an interconnect for many devices , monitoring >> reformatting >> redistributing control and status messages. It is especially useful and very capable with MQTT topics and payloads.

It does have a graphical 'rules engine' ability built in which is very different to say RM but augments rather than competes with it. Likewise an emerging UI capability.

UDP broadcast support - both transmit and receive - yes please :crossed_fingers:

1 Like

I dunno. I will try. I'm not sure if the device will listen to a message at a specific port either. It might only be listening to a broadcast so even if I could fool the hub into receiving a message I think there is a good chance I couldn't talk to it either. Devices that tend to spew data (broadcast) also tend to listen for broadcasts I think.

1 Like

Download the Hubitat app