I have been trying to add support for the new BPUP protocol that is part of BOND Home (ReDoc documentation). BOND is a device for controlling IR and RF devices with a really nice local API -- that makes it ideal for Hubitat in my mind. I have a fully working integration. However, I have to poll BOND to get device status. They implemented a UDP protocal that lets the device push data to Hubitat. Unfortunately, I only ever receive the first message because parse() is only called once after I use sendHubCommand() to send a UDP message. As a result, I have to use polling. Is there any possibility of this being added? I know I'm not the first to ask.
And I'm willing to go to bat for the UDP design decision. I know it's a bit unorthodox... We believe it gives both high performance and is robust with respect to connection/power-cycling issues.
Ideal use on the HE driver side would be:
- HE driver sends subscription packet to each Bond every 60 seconds.
- Bonds acknowledge the subscription. HE may simply ignore this ack.
- Bonds send state updates as they arrive, and HE updates device state on its side.
While it may seem that #1 above creates unnecessary noise on the network, consider that a long-lived TCP connection will generate Keep Alive packets at a similar rate.
Perhaps the biggest advantage of the BPUP (UDP) implementation is that there's no need for HE to track the state of a TCP connection and attempt re-establishment after power-cycle or other cause of communication failure.
I'd expect that the HE driver language would allow the driver to open multiple UDP sockets in this way.
It's also possible for HE to simply bind to UDP port 30007 and receive all state updates for Bonds on the subnet, but this ability to bind to a specific port (and to receive messages from multiple client IPs) is often blocked by the environment (as is the case in Android and iOS). Not sure if this is the case for HE.
While external, it seems like it would be easier to do in Home Assistant or Node-Red and then expose the data as MQTT to Hubitat.
Although I would love it if Hubitat would support just listening for messages on specified UDP port.... Would make a number of integrations (weatherflow, etc) that do UDP data broadcasts much easier.
Me too ,with broadcast address support - it seems a really strange omission / deficiency for a hub offering a USP of 'local' and has hampered me in several local integrations
Me too! Maybe someday...
We can add this request to the list of things that we haven't had time to get to yet but have value. UDP has not risen on our priority list due to low demand for it heretofore.
What's the best way to express demand for this? Posting here?
Looks like a driver I'm trying to write for Eufy Security can't get the data it needs without UDP sockets or UDP requests that can receive multiple responses.
Posting here or emailing support is about it.
There are at least a dozen drivers/devices I've seen/heard of on here that could have used the feature. It just doesn't seem to be high on the list.
In the meantime, I do anything that needs unsolicited/multiple response UDP listening in Node-RED and then push it down to Hubitat. Can do universal UDP listeners in about 5 seconds in Node-RED.
I do too or in a couple of cases not having UDP support, which I regard as a fundamental feature, has actually made me move to different controllers.
The whole of my home automation system was broadcast UDP (xAP) based but is now predominantly MQTT based with a xAP to UDP bridge implemented in Node-RED.
Yeah. That approach works, but it’s just one more thing that can break/go wrong. It’s surprising that UDP still isn’t supported. It’s been an awful long time since they added additional protocol support.
I also want UDP support so that I can integrate all of my Eufy devices. Please raise this issue to a higher priority.
Maybe @bravenel can drop by and offer some info on why this is or is not going to happen.