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.