Access /eventstream from cloud? Or, alternative ways for hub to 'push' updates to a mobile device

🚧 Developers
#1

Hi,

I've been working on an Android dashboard for a while now (here). It's working using a combination of the MakerAPI and the /eventsocket for receiving device state updates.

I'm also supporting remote access using the cloud token with MakerAPI. But, at least as far as I know the /eventsocket isn't accessible outside of the network.

I know MakerAPI offers a webhook - a URL you can set which will get called any time there's an update to report. However, that's not practical for a mobile device which typically can't be reached this way. So, I'm looking for some thoughts on alternative ideas.

The best way to reach a mobile device is push notifications (aka: GCM or FCM).. Hubitat uses these already to send out mobile notifications to your device. But, I don't imagine this would be available to 3rd party apps.

Another way would be to have a websocket (aka /eventsocket) available via the cloud API.. to be honest this might already be available and I just need some help what the URL would be to reach it.

The only other thought I can think of is some 3rd party service which might turn that webhook and turn it into a push notification.. it's not ideal as I'd like to avoid needing any servers at all - but at least it would offer a solution when you're away from home.

(of course a custom hubitat app running on the hub might be the best solution.. but I'm an Android developer so that's not something I'd be comfortable with without a lot of help!)

thanks,
joe

2 Likes
The Home Remote
[RELEASE] HD+ - Android Dashboard
[RELEASE] HD+ - Android Dashboard
[RELEASE] HD+ - Android Dashboard
MakerAPI returning lots of "null" values.. can these be removed?
Help creating a cloud based websocket (server)
#2

This is an old post but one I'd really like to ask again now that I have more experience developing an app for Hubitat.

I wrote the Hubitat Dashboard for Android which initially was designed for wall-mounted tablets throughout your house but has evolved into a pretty full-featured app that works anywhere.

There's over 2,000 active devices using it today and I've heard a lot of great feedback from the community. I'm constantly updating it to handle requests for all kinds of devices that I don't have myself but I like being able to contribute to help Hubitat grow!

Anyway, I'm pretty happy with how the app works locally (on the same network as the hub). It uses a combination of MakerAPI's and /eventsocket for realtime updates.

BUT, when in 'cloud' mode (outside of the network) things aren't as great. The app can't use the /eventsocket endpoint and needs to rely on polling the MakerAPI's for device state changes.

My app (and anyone's for that matter) would really benefit from being able to receive notifications of device state changes remotely (cloud mode). I can think of 2 ways to do this -- and probably not too difficult either:

  1. allow the /eventstream websocket endpoint to be hit from outside the network.. maybe with some additional protections such as the 'allow HSM' toggle option in MakerAPI. Basically, a client can keep an open HTTP connection to this endpoint and receive updates real-time.

  2. add logic to send out push notifications (GCM/FCM). The Hubitat app does this today to receive notifications. Admittedly, this is more of an Android solution than iOS as I don't know if iOS allows for 'background notifications' (ie: not just displaying everything in the notification panel).

For #2, I thought about creating a Hub app which would be able to listen to events and send them out to the user's device(s) via push notifications. I imagine it can be done and isn't super difficult but I'm not a server-developer anymore and I'd need help getting that one off the ground..

#1 seems like an easy win for everyone IMO.. I know a lot of developers rely on /eventstream today.. just allowing it to be accessed remotely using the MakerAPI's authentication token would allow my app (and anyone else's) to stop polling for changes and just wait for them.

I'd love it if any Hubitat devs would be able to comment on how feasible these ideas are. I don't know anyone personally as I've been focused on my app.. but, now that I've got some downtime this would be a good time for me to start asking around too

2 Likes
#3

Tagging @gopher.ny from Hubitat, as he may be best qualified to answer these questions.

1 Like
#4

That’s a significant issue. One that is likely to bite more people is when their WAN IP changes. Whatever mechanism you envisage would work best if it used Hubitat’s cloud. Which has the negative effect of increasing their expenses.

#5

As long as it is optional/disable-able with the default being disabled, then I'm good with any change. :slight_smile:

#6

I'm not sure that's the case.. Right now I'm polling the MakerAPI every few seconds.. and because the /devices/all endpoint is so slow - I have to fetch each device individually.. so, for 100 devices that's 100 API calls every few seconds while the app is running in the foreground.

A websocket is a persistent (keep-alive) connection to your local Hub. If the connection is closed for some reason (ie: walk into an elevator) - it'll reconnect. It should be a lot less overhead than polling.

As for Hubitat's cloud expenses, I'm sure they're not free. But, ultimately they just need to direct traffic to your local hub. There's no server in the middle to maintain AFAIK.

2 Likes
#7

I'm not sure I see the security risk if that's what you're getting at.. not any more than any other MakerAPI endpoint which is accessible from anywhere.

Like any MakerAPI endpoint it'd still require:

  • maker api installed & devices selected
  • app ID
  • app token
  • cloud token
#8

I don't want something I have zero intention of using accessible externally, regardless of the other mitigations. Just my preference.

No argument that it would probably be fine even if it was externally available with the other protections though.

But less is more when it comes to unused connectivity.

1 Like
#9

Just wanted to revisit this topic to see if anything's being planned.. I have to imagine it wouldn't only help just my app to be able to receive realtime updates remotely without constantly polling MakerAPI.

I don't think it would introduce any new security risks either.. there's already an option in MakerAPI to access via cloud..
image

In my mind, all you'd need to do is add an /eventstream-like endpoint to MakerAPI and let it be protected the same way all of MakerAPI app is protected. It already has to be manually added - and then also has both local and remote protect options from there

2 Likes
#10

@gopher.ny would you be available to shed any light on this please?

#11

This whole thing fell off the radar for a while. Let me see what can be cooked up, and don't hesitate to remind me every now and then. I can see the use cases for it.

6 Likes
#12

Hey @bravenel and @gopher.ny is there any further thoughts about this being taken any further?

1 Like
#13

@jpage4500 have you had any further updates on this?

Additionally, what did you do for HSM and Mode? I'm still trying to determine if /eventsocket provides updates for these special type of devices ??

#14

I haven't heard anything, no. I'd love to remove polling from the app when outside of the network though so still hoping something can be done.

I was wondering if it'd be possible for someone to write a community-supported version of MakerAPI? Just like there's a community supported version of Google Home and some other drivers.. not sure how feasible that would be but it does seem like something that could be useful to any app that wants to use MakerAPI both in-network and out of network (offering push updates instead of just requiring polling)

I fetch HSM and Mode data separately via MakerAPI.. I don't believe any state changes for these get pushed through the /eventstream connection

#15

I've seen that some events arrive as LOCATION or APP for the source, and these ones seem to contain HSM or Mode attributes.

Also, have you seen cases where certain releases of the hub cause problems? I'm seeing a small number of users with issues.

#16

Yep, agree - if only we joined forces and worked on the problem together... LOL

#17

Just adding another ping about this one.. it would be a BIG win for any app that uses MakerAPI IMO!!

Somewhat unrelated - would it be possible for Hubitat to open source the MakerAPI app to allow some additional features to be added? Even if just to allow for pull requests to make it into the official MakerAPI.. just thinking it could allow for some dev with some time on their hands to get some kind of 'community' version out there with several tweaks/features to ultimately allow the apps to do more.

#18

@jpage4500 in your dashboard thread you linked to this thread regarding mobile "pinging" of the hub. I use your dashboard as my phones UI with fully kiosk. You mentioned having the dash up all the time when using the cloud were you referring to phone battery, phone data, or the actual hub? At work I have my phone screen (which means the dashboard) active for 12-16 hours a day. It seems to only use about 10 percent of my battery but I am unsure (and dont really care) about data usage. Is my hub at home going nuts with my phone constantly accessing maker API?

#19

It's still on my list, this would be useful. Releasing C8 took the top priority spot for the last few months, though.

4 Likes
#20

That's a good question.. if you're in cloud mode the app (HD+) does poll MakerAPI to get device state changes. That's the only way (that I know of) to get updates remotely. I picked 5 seconds I believe because that's what the native dashboard used. But, you can change this in HD+ (about -> cloud mode) to a higher number if you think it's doing too much work on the Hub.

image
image892×134 5.32 KB

Download the Hubitat app