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.
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.
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.
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.
@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.
This is actually not entirely true since standard HTTP requests (GET or POST) is sent as TCP traffic with ack/nack and an overhead for each frame. In a larger system with lots of events this is actually a very inefficient method compared to a websocket or when retrieving data make sure the dataset is a large enough as it's more efficient then multiple requests.
There are of course ways to use UDP as the transport layer for HTTP but it's not common in regular web traffic and a quick wireshark session proved that in this case the hub is using regular HTTP with TCP as the transport layer, it's even sending TCP Keep-Alive on a regular basis.
But still the solution as a whole with the device events post url is quite ingenious and will open up for integrations where a websocket is not possible, just wish there was an official support websocket
I may have missed it if already asked, however I request adding the "hub id" or other source identifier to the messages. This would make supporting multi-hub integrations much easier.
Another thing you could do though is post the events to a specific URL with the hub suffix. Then on the integration side you should be able to tag whatever hub it came from.
So on one hub I use a "/161" for the POST URL suffix. For another hub I use "/151".
