Using Maker API - how to receive events?

🚧 Developers
4

thanks for the quick replies!!

I've worked on a few different Android app which needed to get updates from a server immediately so polling wasn't an option.

  • 1 company used websockets which was probably the best/most efficient option. The app would basically connect keeping the socket open when the UI was visible and send keepalives every few seconds. I think that could work remotely as well as long as we can reach the hub from the Internet
  • another company relied completely on google push messages (GCM or FCM as it's called today). This was an Instant Messenger app so messages needed to get delivered and surprisingly the silent push notifications worked very reliably. Ultimately, every Android device has it's own keep-alive connection to Google and it's much easier to use their connection vs creating our own
  • Wink also used push notifications through a 3rd party library, pubnub. It's not a free service though and it's easy enough to just use Google's push notifications for free.

Unfortunately, I know very little of the server-side of things so I was really hoping the MakerAPI or something else would have this already built.

Anyway, I'd love to hear any other ideas or thoughts on this.

5

Interesting topic... You may want to have a discussion with Hubitat’s @chuck.schwer. He understands Hubitat’s architecture better than anyone I know (probably because he wrote most of it! :wink:)

1 Like
6

HE has an eventstream you can tap into (websocket). There are quite a few posts about it on here if you search. It is awesome. I'm using it to develop a cool html/css/javascript dashboard. You can listen for events (streamed as JSON) and then run your script accordingly. You can also request the summary of a specific device or all devices from the server using Maker API and then parse the response.

Hope it helps and good luck!

7

But the eventstream websocket is local only, right? I'm assuming he wants his app to work even when not at home. I don't believe there is any "push" that will work outside of LAN, which is where, unfortunately, I think the only option HE currently offers is polling.

That being said, back in the old days, before we had websockets, we used to do "long polling" (comet) where you make a call, keep it open till it times out (or you receive a message) and you reopen whenever it either times out or you receive a message. It's still very inefficient, but better than regular polling.

8

Yes, true. Good point and well made :smiley:

9

Is using a VPN an option? Something lightweight like WireGuard? Will the websockets stuff work over that?

Another thought is maybe MQTT messaging... connect to a secure broker. There's a beta MQTT app for HE in progress. I'm doing that for owntracks communication right now..

10

It sounds like he's trying to setup something to be a simple solution for a mobile app, sounds like it would meet the needs of people asking for a "simple app like Wink that doesn't require a PhD." Once you're asking people to setup a VPN or an MQTT broker, I'm thinking that won't meet the OP's needs.

2 Likes
11

@jpage4500 - Well, the folks over at Sharptools have managed to figure this out. They do have the advantage of using a central cloud server platform to host their web-based users from. This would keep the updates going to one cloud server and then being disseminated to all of the web clients that are active. Sharptools is pretty impressive and responsive.

You could create an OAuth2 based App on Hubitat, that should allow your custom Mobile App to connect to the Hubitat Cloud and retrieve a token via an authorization process, in the same way that Amazon Alexa, Google Home, SharpTools, and even the Hubitat Mobile App does. Once your App is connected through cloud.hubitat.com, you should be able to read and write data bidirectionally. Handling multiple client apps (i.e. mobile phones) might be interesting, as you'd have to create some sort of connection manager to make sure all actively connected devices receive asynchronous updates as events come into your custom Hubitat OAuth2 Hub App.

Just thinking out loud... :thinking:

4 Likes
12

Since he was talking about writing his own Android app adding a public facing MQTT broker seems less challenging a task and once set up trivial for others to use. There are cloud providers like cloudMQTT - but then you've potentially added a subscription cost back into the mix.

For this specific case I think @csteele's idea is the way to go. Of course then you are back being reliant on the the "cloud" again and subject to the fortunes/whims of Hubitat. Likely (and appropriately) they would want to monetize any service hanging off their cloud.

13

Wow - it's awesome to see so much support. I'm glad I picked Hubitat!

the eventstream websocket is local only, right?

actually, the more i think about it my primary interest is just for use in wall-mounted tablets around the house.. so, all traffic would be local anyway. It would be cool if it also worked on phones from anywhere but that wouldn't be as important at least for me.

HE has an eventstream you can tap into (websocket)

I'll search for this - thanks for all of the suggestions!

14

Just be aware that Hubitat’s event stream webSocket is not a published tool for end users. While Hubitat has not indicated that they would lock it down, they have mentioned that it is subject to change as necessary. I use it with Node Red to collect data for InfluxDB/Grafana and it does work very well.

Hubitat’s preferred method is to use their published Maker API. Although, as you know, it can only publish updates automatically to a single device. I wonder what would happen if one chose to use a LAN broadcast IP address? I have no idea if that would work, or how much negative impact it would have on a home LAN? :thinking:

2 Likes
15

If it worked, and turned out to be detrimental, one could always put the HE and the tablets on their own VLAN with a subnet mask that permitted a small yet sufficient number of hosts.

1 Like
16

I was just going to post and ask if/how to use this from another device on the network. The documents I found so far seem to reference some utility methods that are part of the apps/drivers which reside on the Hubitat as I understand it.

I did see the URL 'ws://192.168.1.10/eventsocket' mentioned in one of the posts and I figured when I got time I could try to connect to it. But, would it even work without any kind of authentication? The connection would come from outside of the hubitat.

Hubitat’s preferred method is to use their published Maker API. Although, as you know, it can only publish updates automatically to a single device

I was thinking about how to implement that.. I'm not used to accepting incoming connections on a mobile device but I guess there's no reason it couldn't work as long as I can determine my IP address (to tell the hub). But, yeah, the single device/IP only limitation wouldn't make this super useful for multiple dashboards that are all active.

I tried to think about something 'else' which could accept these event notifications and then push them out to other devices that are listening.. but, that seems like it could get complicated quick. I'm comfortable writing the Android app part but not anything server-related (I've been a mobile-only developer for far too long lol)

side-note - i made a mistake in my first post.. I said Wink uses PubNub which piggybacked off of push notifications.. I remembered last night that PubNub instead is more like a websocket connection - except the connection is to their servers which aren't free.. anyway.. just wanted to correct that

17

woo-hoo! I found a little command-line tool to test websocket connections from my macbook: GitHub - vi/websocat: Command-line client for WebSockets, like netcat (or curl) for ws:// with advanced socat-like functions

I ran it and did a couple of actions to a door with a smart lock and open/close sensor:

~/Downloads$ websocat ws://192.168.0.202/eventsocket
-- locked door --
{"source":"DEVICE","name":"lock","displayName":"Porch Lock","value":"locked","unit":null,"deviceId":2,"hubId":null,"locationId":null,"installedAppId":null,"descriptionText":"Porch Lock was locked via key or thumbturn [physical]"}

-- unlocked door --
{"source":"DEVICE","name":"lock","displayName":"Porch Lock","value":"unlocked","unit":null,"deviceId":2,"hubId":null,"locationId":null,"installedAppId":null,"descriptionText":"Porch Lock was unlocked via key or thumbturn [physical]"}
{"source":"APP","name":"RM","displayName":null,"value":"Porch Lock lock unlocked","unit":null,"deviceId":null,"hubId":null,"locationId":null,"installedAppId":5,"descriptionText":null}

-- closed door --
{"source":"APP","name":"RM","displayName":null,"value":"Triggered","unit":null,"deviceId":null,"hubId":null,"locationId":null,"installedAppId":5,"descriptionText":null}
{"source":"DEVICE","name":"contact","displayName":"Patio Door","value":"closed","unit":null,"deviceId":67,"hubId":null,"locationId":null,"installedAppId":null,"descriptionText":"Patio Door was closed"}
4 Likes
18

Now you're on your way! Please keep us updated on the progress of your native Android App. If you're planning on sharing this work with the community, perhaps you'd consider developing with a toolset that allows for both Android and iOS Apps? Some of us are iOS users around here :wink:

4 Likes
19

Or seriously considering heading that way.

My ~3.5 year old original Pixel is on its last legs. I'm debating between getting the Pixel 4a when its released or the new iPhone SE.

20

You might also consider using "/logsocket" instead - a lot less cruft to sort through.

I use "node" (and "forever") to run a Javascript to pull (and archive) the "warn" and "error" messages from my logs.

21

Please keep us updated on the progress of your native Android App

So far so good! I had 3-4 hours last night and this morning to work on creating a base Android app with a lot of the networking layer started. I don't know how long it will be before I can get something up and running but I will keep anyone updated if interested.

Some of us are iOS users around here :wink:

I think more than half of America is using an iOS device! Unfortunately, I haven't worked on iOS in several years so this wouldn't be much help.

I will say that my high-level goal for doing this is to focus on making a wall-mounted tablet dashboard. I know there's plenty of people who mount iPad's on their wall but personally I'd go with the MUCH cheaper Android tablets. I have 4 Amazon Fire 7" tablets which I picked up for $29 each and they are more than good enough to serve as a dedicated dashboard. That said, the app should also work fine on any Android phone as well.

There's a few reasons why I want to do this project instead of just creating a dashboard and using the Hubitat Android app (or browser) to view on a tablet. Some things I'd like to make sure exist are:

  • speed.. it needs to be fast, look & feel like a native app
  • full screen - at least take up as much space as possible
  • adjust to fit the space; i tried using the Hubitat dashboard and while it was very customizable it took a lot of playing around with to adjust the tiles to fit the space. Then, I'd rotate the device and it would get all messed up.. using native UI widgets everything should just fit exactly
  • keep the screen ON and at full brightness while the dashboard is running
  • turn the screen off at night and back on again in the morning.. no need to keep the screen on at 3 AM as eventually the screen would burn-in.
  • touch to toggle/switch/etc.. not sure why i can't lock my door without a prompt but I want to be able to click on an unlocked door and have it lock
  • allow for some nice animations when toggling states (door lock)

I think all of this should be doable.. I would also add as much customization as I can (like icon size, colors, etc). No way it'll be as full featured as the current dashboard though just due to time. But, it'll all be in github if anyone wants to add to the UI experience.

I imagine once I get into the UI part of this project I'm going to have to figure out what icons to use (ie: door open, door closed; lock open, lock closed, etc). It'd be awesome to find some consistent images that look great in a dashboard view. While I was never happy with the Wink dashboard icons they are nice and clear.. it's easy to see if something is open or unlocked at a glance.

Anyway, more to come! I do have a day-job and it's going to be a very busy week so I can't say how much I can get done.. but, it's going to be hard to keep away from it as well :slight_smile:

5 Likes
22

Welcome (although you've been a member a while)...very glad to have you 'on the case' @jpage4500. A lot of people will be following with appreciation and interest.

23

Sweet. I'm currently doing the same using websocket but just in html/css/javascript (this way it can run on anything, so consider it a "web app". My objective is a real glitzy dashboard as per this post...

1 Like