Quick (?) question but is the Maker API only used for polling devices? I'm not sure if I'm reading the docs correctly.
For example, is it possible for, say, a motion sensor to send the events to my app? Or would I have to update the drivers to do that?
Maker API can be used for polling, but it can also POST device (and location) events to a specified URL, and it can "receive" (incoming) commands for selected devices. It's not clear to me which way you mean, but both are possible. But if you can do this directly with a driver, bypassing Maker API entirely is probably easier...
What I'm asking is if device changes can be pushed.
Motion active/inactive -> my app
light on/off/level -> my app
I can see where I can poll that info. It wasn't obvious if I can do the above.
For drivers I have a couple custom ones but I don't want to write drivers for all my standard devices. I'm also looking at how to connect the iOS app to HomeKit. Between the two options I should be an able to create a custom dashboard. 
I'm assuming you mean an "app" outside Hubitat? (A Hubitat app does not need to -- nor should it -- use Maker API to do this.) But yes, with any external system, as long as it can accept HTTP POSTs at some URL, Maker API can be configured to send these to your system for processing, allowing it to see events in real time from the hub without polling.
Yes, that will be key. 
That is correct. I'm playing with iOS and creating an app to act as a custom dashboard. It isn't very far along but I posted the idea here.
This is what some Hubitat -> Influx DB setups use to send the device updates for display in Grafana and other dashboarding options. Like @bertabcd1234 described, you can configure the list of devices you want in Maker API and their events will get sent (posted) to the URL you define, but you need something on the other end to receive them and parse / process the event data. In your case this would be the dashboard app you are developing, or in an InfluxDB example, an app on say a raspberry pi like a node.js app.
If you remember HubiVue, I'm pretty sure it used a similar setup, at least in the beginning, to get device updates and issue commands from the HubiVue dashboard app.
Exactly the rabbit hole I've jumped into. I just wired up sub views for each room. Now I need to get some data over there. I just missed the "URL to POST device events to" when I installed the Maker API.
I know nothing about Swift so it is a deep rabbit hole indeed. However, just today I have created custom button items, views, and have them wired up. The dev environment is pretty slick.
On the plus side: I'm not trying to make a universal app. This is strictly for my house and 100% custom so that simplifies things a bit.
Next up: Receiving incoming POST events.
Why not just use the websocket. This is what I use for my work in progress android/ios app.
I seem to remember lock code used was one of those pieces of data that was not sent on websocket. Again, I haven't checked in a long time as I simply stopped using websocket after I discovered that some data didn't get sent.
In addition to what @JasonJoel pointed out, websocket and logsocket are not officially supported. And may go away. MakerAPI will not.
Good point. If I were Hubitat I would nix web/log sockets.
Why have 2 ways of getting the data out anyway?
I think there was actually some talk of making the websocket (for events) official, but that hasn't happened yet to my knowledge. I think the main advantage of that over Maker API is that a websocket connection is faster and more efficient than a bunch of HTTP calls for every event. The downside is that it is full of things you might not care about unless you're likely to care about most devices on the hub (so it could actually be less efficient on the other end if you don't).
Also, depending on your use case, Maker API has a cloud option available, whereas you need to be local for the websocket.
Yes, you are correct. Victor briefly suggested making it official about a year ago. But I don't think that happened.
I'm fine either way. But the transactional API always has to stay at this point (even if replaced and deprecated to legacy status), so Hubitat would have to decide if they want to dedicate the resources to support both in an official manner or not.
I think that idea is a bust versus the long list of other support needs, but I am not the boss.
If they were really intent on supporting both connectivity paths then I think a lot of work needs to be done in rationalizing payload formats, content, etc. If they want to go that route I would expect they would just make a new consolidated external data API/method that includes both paths, and consider Maker API and the unofficial sockets paths "legacy".
But again, just guessing. I'm not involved in any of that.
Nice points on websocket, its my understanding their local dashboard uses that so I don't see it going away but valid point on cloud. I haven't noticed anything not being sent via websocket I use but i may come across that and will look at makerapi if that becomes the case. I hope not as sockets are fast and easy to handle. It doesnt provide alot of info I don't need/use but that is easy to ignore and grab what I do need so far, but nice points and good to know.
to clarify i do use makerapi for commands but didn't' for status updates as websockets like i said work for me so far.
Just Jason's opinion - I don't think that is a good conclusion to draw... I expect that dashboards will get a gigantic overhaul at some point, which is likely as not to include a back end data path change.
But whatever. We're just guessing / expressing feelings, not facts on that topic. There are various apps using websockets - supported or not - so you are likely correct that even if it went away or was supplanted by something else better, it wouldn't happen without notice.
Hubitat has a very good track record of not deprecating used functions (official or not) without notice.
And now I'll let this drop... I don't have time to compare every event between hook and socket and figure out what else (if anything) isn't reported by the socket... But I have to assume if this (as well as event type physical/digital) was missing other things could be too.
@JasonJoel i agree and appreciate you pointing out websocket didn’t report everything. It’s an easy enough replacement to handle post if I decide to go that route. It’s odd sometimes the “undocumented” stuff like websocket but agree hubitat is good at warning before breaking changes even on stuff like that.
No doubt. Websocket works really well overall / for most uses, just has some 'quirks'.
Download the Hubitat app
