UDP broadcast support

[rob]

Receiving all replies. Is there any secret in broadcast to be able to receive ALL of the responses. Currently, I only receive the first response receive then the port shuts down. Hope is there is some setting to keep the port open for 5 or so seconds.

I have a kluge that is working to find all my devices; however, I do not like it. Essentially, I extract the hub IP and parse for the segment (XXX.XXX.XXX). Then send get status command to all of the 254 possible addresses. Sub-optimal, but it works.

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.

[rob121]

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

mjg59/python-broadlink/blob/master/protocol.md

[rcjordan]

Broadlink rm mini3

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.

[rob]

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

python-broadlink/protocol.md at master · mjg59/python-broadlink · GitHub

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.

[rob]

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.

[rob121]

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!

[kevin]

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.

[rob]

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

[kilowatts]

Pretty cool seeing all this come together.

[djgutheinz]

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.

[bobbles]

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!!!!
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.

UK:LightwaveRF Integration

I’ve been using LightwaveRF devices integrated into ST via a Ras Pi to the Lightwave (LW) hub. I’ve got it working with Hubitat Elevation. I didn’t the process but have just been a grateful recipient. Here is the ST thread which shows you how to set it all up, followed by the DH code which I have amended to work with HE. Dimmer. /** * Lightwave Lights * * Copyright 2015 Adam Clark * For any information or help please contact ad@mclark.co * * Licensed under the Apache License,…

[djgutheinz]

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.

[codahq]

if you are asking about the hub receiving udp broadcasts from a device. No, we do not support that. You can only send out UDP messages and receive a reply to that message.

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

[JasonJoel]

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.

[dman2306]

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?

[JasonJoel]

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.

[adamkempenich]

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.

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?

[kevin]

"use a competing product for that feature"

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

[codahq]

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.