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".
Our take on this is that the solution that @JasonJoel describes is the way to go, and that it doesn't make sense to burden every post with static information.
Is this actually a real issue? Or hypothetical?
How about an option you can set to include the hubId?
Being not to good at this stuff, wondering how I might use this to do something.
I current have a device I had to leave on ST (reasons not important). So I created a small app here that uses an httpGet to the ST API to send on/off command using a virtual switch. Works fine. (Yeah I know I could use HubConnect, but that seemed an overkill).
So it would appear that I could do this with this feature? But don't know quite how to format it.
Example: HomeSeer plugins have a fixed endpoint available to the plugins because the plugin doesn't control the webserver. With that I have 1 endpoint I can receive POST data from and only 1.
An optional/option for including hubId would work perfectly. Can the option be included as a variable to the POST to enable the endpoint?
To automate it and make it easier for the end user. I have no issue with knowing/clicking a checkbox but I'm sure you're not surprised when I say that a lot of users do have problems without guidance.
This wouldn't really address that, unless you have a smartapp/driver listening on the ST side for the event. This is basically the same as the events websocket, but in a HTTP POST form and allows outside apps to be able to react to events coming from Hubitat devices.
As an example, I have a small node.js script that makes http calls to my NodeMCUs running my holiday lights. Because it's easier for me to code complex logic in node.js versus Rule Machine, I can have the Maker API make a HTTP POST to my node.js script when my mode (or any device, really) changes and then the script can do all the heavy lifting of turning on/off my outside lights.
Another example is being able to log device events to a log aggregation service and then be able to use that to search through logs about events happening on my devices.
Please pardon my ignorance, I don't have any experience with HTTP communications.
I've bee working with Maker API and can talk to my hub sending commands and seeing status with my web browser. Trying to set up device events and am stuck in the mud.
From the first post I am entering the following in my web browser:
[http://[Hub IP]/apps/api/[Maker API #]/postURL/[URL]?access_token=YOUR_ACCESS_TOKEN
I put the Hub IP in [Hub IP]
Put the app # in my case 290 in [Maker API #]
My token in the access _token=
For [URL] I've been entering the IP of the computer that I am running the browser.
When I run the command the Hub returns the IP address of the browser computer but that is all I see. If I go to the logs I see the API 290 running. Sending the command without the [URL] stops the API 290 in the logs. Do I just need to establish communications with a terminal, add a port # to the end of the IP address? I think it's something that simple.
