@bravenel, is there a way to activate the location events via an endpoint? We can set the remote URL via an endpoint but not enable the location events. In addition, location events can only be enabled once a remote URL is set. It will be confusing to guide users through this process for any kind of integration that is being build
I'm all for more remote configuration. However, in this case I don't see it as a big deal.
The end user still has to know enough to install Maker API, record/find the app #, record the auth/token, and add devices to it (wither all or select), so they have to go into the Maker API anyway.
Having them check the option at this time seems incremental to the other activities.
1 Like
I am working on updating my homebridge plugin.
That plugin will need to open a port and it will tell MakerAPI where it is located to receive the events based on the postURL endpoint. The user would then have to go back into MakerAPI to enable the option after the plugin was started once. Really counter-intuitive if you ask me......
1 Like
Good point - I hadn't thought of that use case.
Maybe they will add it in a future release (after they add UNITS in the JSON response, since I asked 1st [<- that was a joke 
]).
2 Likes
Personally, I LOVE the websocket implementations in HE and have built a lot of my house infrastructure around them. But, I did it in a way that if HE did close them off, I could recover pretty quick. However, we, the community found the sockets and they were used intended for internal use only. I totally get that. But, I would also love to see a Maker API: Sockets implementation as well.
1 Like
Agreed, presumably web sockets has a much lower overhead (since it's already doing it anyway and an extra client is just a subscription on the socket) compared to having to do a HTTP POST for every event.
I actually just moved my own integration from the old ported ST MQTT/REST plugin (Hubitat MQTT Integration) to a web sockets and maker api equivalent for this reason. It would seem a step back to revert to a http post version .....
3 Likes
@bravenel, I have a second request 
After someone sets the endpoint URL via the postURL request, can you start sending events via the event stream. Right now, the user needs to go back into MakerAPI and hit done.
2 Likes
There's pros and cons to both. The HTTP Post approach means that it's stateless and doesn't need to keep resources open continually; it's a stateless, fire and forget mechanism and works really well in an environment that has constrained resources. With a socket implementation, the socket needs to be kept open in order to function (due to it being a duplex connection). This places additional strain on the system engine.
So, for HE, going the HTTP Post route makes sense if they are having any kind of resource or contention issues in the system engine. It doesn't require a server process running all the time and HTTP connections/DB objects can be disposed each and every time an event fires.
Isn't it already open anyway though?
I thought that was why we already "found" it, because it was already in use internally for dashboards and general UI? Similar for the "logging" socket?
My assumption (perhaps incorrectly) is that it's just a broadcast on those sockets which is happening anyway, another client subscribing to the socket doesn't add much overhead in comparison to an HTTP POST that has to wait for the receiving system to respond.
I know if I turn off a dozen devices in a Scene I get all those events pretty much instantly on the web socket, whereas the Maker API route would be 12 individual HTTP POSTS outbound.....
1 Like
It is and while multiple subscribers don't add much to the resource usage, they still do add to the resource usage.
In a true webhook system, the system making the HTTP POST doesn't wait for anything from the receiver; It fires and forgets. The reason for this is that there's too much risk in waiting for a reply from a system that may not be up or even able to respond. So, usually there is no wait involved. The HTTP POST is made and then resources get disposed of.
Yeah, that's where the pros and cons come into play. On the receiving end now, we don't have to sift through hundreds of messages per minute to get the event data we want. Plus, we can still create multiple copies of the Maker API app to target devices only the devices we want events from.
Hypothetically, let's say I ONLY want battery events and nothing else. I can create a Maker API app, add only my battery devices and then create a small node.js script that listens on a specific port and just processes when battery events come in. The logic to create that is super simple and could be considered a micro-service. I can then consume that tiny bit of logic into a bigger app that just loads the small node.js app as a plugin. That way, if I don't have any battery devices on my HE (rare, but I've seen people do it), I don't have to add that plugin.
All I know is if they remove the event socket and break hubconnect without providing an as good/better alternative there will be a very widespread mutiny and mass exodus. 
2 Likes
I will make setting option for location events independent of setting the URL. So it can be set when you first setup Maker API, even when the URL will be set remotely.
This is actually a bug. It is supposed to initialize the event subscriptions upon the URL being set. The bug is now fixed. Once those subscriptions are in place, it starts sending events by POST.
Both of these will be in the next hot fix release.
3 Likes
Lame. I asked first. (<-- That is me joking, in case it isn't obvious in print)
1 Like
What is the compelling reason that unit should be passed in each and every event?
So that the payload is indeed stand alone. No different than sending the display name or the device ID each time... Neither of those change either.
otherwise on the integration side we have to cache or manually look up the units each time.
1 Like
OK. I'll add unit.
3 Likes
I will add that last night while I was going through all of the different integrations I've made w/Hubitat - some on just a notional level, some actually revamping to use the POST updates - that was the only parameter that I felt was missing / required additional calls to be made in order to fully utilize the update data.
Sure, to support bi-directionality/commands externally the integration still needs to grab the supported command list (and in those cases you can just grab the units at that time as well), but for simple read-only integrations having the units in the update events would completely eliminate any additional calls needed.
Not that it matters, but I would rather give up the event description than units if we are trying to shrink the responses. But I'm sure others may disagree there. My thought is that the descriptions follow little/no structure (or at least the event text is not standardized enough to rely on 100% of the time in any case) so can't really be used as-is anyway and always require additional parsing, unless they are only being used for archiving purposes. Oh, and the event description text SHOULD be completely redundant information withe the name and value's passed in the event anyway (by definition).
A happy side note is that using the POST method significantly reduced the parsing code required externally versus drinking from the event socket fire hose, which is very welcome.
Thank again.
1 Like
Do I understand correctly, the Maker API is only for accessing HE devices etc from an external service, and does not include being able to access external devices from HE.
Correct
@bravenel Since you're feeling generous, I do have one feature request for the Maker API. Could we get a method to get a dump of the devices included without state info OR get more device info added to the base /devices endpoint without state info (capabilities & commands available)?
Currently, it only returns the device name, type and id. For anything more you either have to call each device independently or grab the entire devices structure which can take upwards of 2+ minutes with a large number of devices.
