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!)
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:
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.
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
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.
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.
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.
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..
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
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.
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
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.
@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?
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.
