API Needs a "push" method

Just curious is there a reason you believe tcp to be better?

Why TCP better than a WebHook callback?

It was based on negative feedback on WebHooks from some commercial home automation platforms. Apparently they have trouble listening on a socket or creating a webserver. Making an outgoing connection to a known host+port was much simpler for them.

Ok, just wondering. I’m pretty sure SmartThings doesn’t support TCP. I can make it work with Hubitat, it’ll just be a big change

So, I prototyped a few different Push mechanisms this week. The UDP solution I mentioned is probably unfamiliar to many, so I made a demo video to show how simple it can be: https://www.youtube.com/watch?v=bKOh-b_sgVE

Some notes not covered in the video:

  • The timeouts I quote in the video are subject to change. More likely a 60sec keepalive interval and 125sec timeout are more appropriate (and also in-line with TCP keepalive, so a similar idle network traffic is achieved).

  • For clients that can bind a specific UDP port, you can simply listen on port 30007 and receive broadcasts from all Bond Bridge / SBB devices on the network without the need for keepalives or even discovery.

  • Clearly there’s an assumption about the security of the underlying WiFi network (as outlined already in the Local API docs).

  • True that UDP sockets do not, by themselves, provide a “connected” indication. However, in the broader context of connectivity in the face of rebooting devices etc., the UDP keepalive/timeout mechanism is just as robust an indicator–or perhaps more robust, because there’s no need to wait for the (client’s) OS to timeout a “stuck” TCP socket as sometimes happens).


Looking forward to trying it out whenever you can include this new feature in beta release firmware!

So it’s udp only? Hubitat I think only supports tcp. I will check with there devs but I haven’t seen how to open a udp socket.