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.
This is what I use in my app, minus the secret stuff.
https://graph-na02-useast1.api.smartthings.com/api/smartapps/installations/[appid]/command/on/?access_token=[token]
What I have works fine, but just wondering how it might be done. More for my education than anything else.
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?
What's the purpose of that? Is there a reason you can't select an option in the UI?
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.
I am assuming you're trying to have the Maker API send unsolicited device status updates to your LabView system, correct? If so, all you need to do is put in whatever URL you'd like (that LabView is listening for) in the following field of the Maker API Application.
Does that help? Or have you already tried that and it isn't working?
You will not be able to define the URL to have device status updates sent to via a Web Browser. Web Browsers issue http GET commands. In this case, you're trying to set a value within the Maker API, so you would need to use an http POST command. This can be done programatically on many platforms, or via 'curl' on many platforms. But, it is simpler to set the URL via the Maker API App's configuration page.
Sorry, didn’t include in my post that I had put the straight IP address of the computer in the Maker API configuration, 192.168.1.43 in my case.
Right now I’m just using my browser to communicate. Once I’m talking I’ll start using Labview.
I think there is a misunderstanding here.
You cannot use your browser to use the HTTP POST feature in MakerAPI. You need a web server application that accepts a HTTP POST message. Think about it this way: Your browser is a nice user interface but not more. Your browser talks to a web server to receive information on what to display. You need that web server part to use the HTTP POST feature.
EDIT: Take a look at this here, that is what you need from a LabView perspective
https://zone.ni.com/reference/en-XX/help/371361R-01/lvhowto/build_web_service/
Dan, thanks I missed that. Teach me to post without having any coffee in the morning.
Hi - not sure if this is the appropriate place to put this - not sure if this is a problem in Maker API or expected behavior. Also, bear with me if I describe anything incorrectly - just learning this system.
I'm working with the Abode Security system driver being developed by @endorphin_junkie. The driver captures events from my abode security system (such as contact closure events) correctly - they appear in Events for the Abode device using that driver.
The SendEvents lines in the driver include isStateChange : true.
Here's one of those lines:
sendEvent(name: alert_name, value: alert_value, descriptionText: message, type: alert_type, displayed: true, isStateChange: true)
I would like to use Maker API to send these events via HTTP Post, but they are not showing up in Maker. In the Maker API settings, I saw that it was only subscribed to events related to two attributes defined in the driver. I also read that Maker API requires events to have a capability (associate with a capability?) , so added the ContactSensor capability to the driver. It then shows up in subscribed Events, but Maker still doesn't log or send these events.
When I look at device events via
http://[Hub IP]/apps/api/[Maker App ID]/devices/[Device ID]/events?access_token=[my token]
I see the events but it says "isStateChange" : null. Not sure why the value of isStateChange isn't making it to Maker API.
Here's one of the events from the above URL:
{"device_id":"[device ID]","label":"Abode System","name":"Front Door","value":"Closed","date":"2020-04-01T14:52:45+0000","unit":null,"isStateChange":null,"source":"DEVICE"}
Any thoughts?
Thanks!
I added these lines to the driver but the events still aren't making it through Maker API.
capability 'ContactSensor'
attribute 'alert_name', 'String'I believe Maker API is going to work best with Standard Capabilities (I.e. attributes and commands.) If the drivers you are using are not implementing standard capabilities fully, the it is unlikely to work well with Maker API.
It appears you’re trying to add a standard capability, but the question remains, has it been properly implemented in the driver to raise the correct events? “alert_name” is not a standard attribute of a Contact Sensor. “contact” is the correct attribute for a Contact Sensor. This is described in the Hubitat Developer documentation.
I would encourage you to ask the developer to make the appropriate changes to their integration to implement Standard Capabilities, instead of custom attributes and commands. This will allow the integration to work with the rest of the standard Hubitat Apps, including Maker API.
Thank you - I'll pass this on!
It appears that's because the driver isn't publishing an event for an attribute titled alert_name, it's publishing an event for "Front Door"
That should be a string of "alert_name" or "contact" not the name of the device that is opened or closed. If the device is intended to monitor multiple contact sensors, then it should have child devices for each sensor. That's the only way you're going to get it to work right. The name is in reference to the attribute, not the device that is opening or closing. In this case, you;d have to have an attribute of "Front Door" to get it to work correctly.
I was able to figure this out because in the driver, both alert_name and alert_value are not strings, but are variables.
sendEvent(name: alert_name, value: alert_value, descriptionText: message, type: alert_type, displayed: true)
Unless alert_name is being set to "contact", then this is never going to work correctly.
Thank you!
Not sure if I understood that last bit - are you saying change the name of the variable to "contact" or set the value of the variable to "contact" - or something else? But it seems from what you said that child devices would still be needed for each actual sensor?
Yes, if you're trying to monitor multiple doors and windows from a home security system, then the integration will need to create a child "Contact Sensor" device for each of them. This is really the best way to make these sensors appear as standard "Contact Sensor" devices within Hubitat. Once those child devices exist, every App within Hubitat can just use them.
Got it - thank you.
The name of the event has to correspond to whatever attribute you are reporting the event for. In this case, the name is "Front Door" but there is no attribute name "Front Door". That's why you won't see a POST message from the Maker API. A real event is not generated because there is no corresponding attribute.
Download the Hubitat app
