Help creating a cloud based websocket (server)

🚧 Developers Coding Questions
#1

This is something I've always wanted to do but never had the skills and not even sure how feasible it is either.. but, I've got to start somewhere so figured I'd start with some basic questions.

I'd love to create a 'cloud' version of the current /eventstream API. More specifically, what's described in this thread: Access /eventstream from cloud? Or, alternative ways for hub to 'push' updates to a mobile device

I want a way for a mobile device to get 'push' device state updates when remote. MakerAPI only offers a webhook but that's not feasible for mobile devices. However, the internal /eventstream is ideal as a client can connect when running and not have to poll to get device changes.

Of course /eventstream isn't available outside of the network.. thus, what I'm looking to do is write a Hubitat app/driver which can be reached from outside of your network..

  1. Is it possible for a Hubitat app to create a websocket server? Are there any examples of this in existing apps/drivers anywhere? I know several apps (like Orbit) connect to existing websocket server connections (client-side)

  2. Besides the websocket server, I'm also unsure how a mobile device can 'reach' this app externally. MakerAPI uses a cloud token but I assume that's only available to MakerAPI endpoints. Is OAUTH the answer? I know other apps are able to be reached from external services somehow.

Anyway, if anyone has thoughts or ideas please let me know! Maybe I'm in over my head too but can't hurt to do some digging

#2

In short, a websocket client possible, so this could work if you have an external server you can connect to from the hub. However, for example, your mobile app could not open such a connection directly to the hub.

OAuth is probably the answer you are looking for. It's undoubtedly what Maker API uses under the hood, as well as a variety of built-in and community apps that offer similar capabilities. There are two ways an app can register and endpoint (or both), local or cloud, and the cloud ones use Hubitat's servers. This would work well for your mobile app sending an HTTP GET, PUT, or POST to one of these cloud endpoints, which the on-hub app could then respond to.

I have some code that does this, but it's not really well-formatted for an easy-to-look-at example. If no one else comes up with anything first, I do plan to make an example of this at some point...

PS - In the meantime, you are looking for things like createAccessToken() and the get...ApiServerUrl() methods: App Object | Hubitat Documentation

#3

rats.. well that's what I was hoping for.. using the Hubitat as the server-side of the websocket and having the mobile device connect directly to it -- then pushing updates as they come in

The hope isn't to offer polling like MakerAPI already has but something more robust / event driven..

There's another option but I think it'd be more difficult (maybe).. sending push messages (GCM/FCM) from the Hub to a phone.

That's how the native Hubitat app gets notifications pushed to it.

#4

I believe what vendors like ActionTiles and SharpTools do, is to host their own cloud server that can handle the multiple connections from multiple clients, and also the one connection through the Hubitat Cloud server to the end-user's hub.

1 Like
#5

Yeah that's the #1 thing I want to avoid - the need for a 3rd party server. But, the Hub is already a 'server' right? It can handle multiple connections from multiple sources - just like any server can.

Download the Hubitat app