Maker API App - Trouble with Refresh Command

Hi,

I'm working with the Maker API App to integrate Hubitat with a 3rd party processor. The code on the 3rd party processor is sending the following command to the Hubitat

http://192.168.1.124/apps/api/37/devices/1/refresh?access_token=xxxx

where 192.168.1.124 is the IP address of the hubitat

37 is the App ID of the maker app on my Hubitat

1 is the Device ID of a Z-Wave outlet integrated with the Hubitat

In the Hubitat log I see the following:

dev:12020-03-20 08:00:01.195 pm infoOutdoor Outlet is off [digital]

app:372020-03-20 08:00:01.136 pm debugdeviceItem called

app:372020-03-20 08:00:01.132 pm debugExecuting command: refresh on device: Outdoor Outlet

app:372020-03-20 08:00:01.097 pm debugfindDevice called

app:372020-03-20 08:00:01.094 pm debugsendDeviceCommand called

So I know the refresh command is reaching the hubitat

In the Maker API app settings I have "URL to send device events to by Post" set to http://192.168.1.66:9000 where 192.168.1.66 is the address of third party processor and 9000 is the port that the 3rd party processor is listening to for messages from the Hubitat.

When the above refresh command is sent to the hubitat, the 3rd party processor never gets a reply on port 9000. I'm guessing that since this isn't a "device event" the reply is being instead sent to port 80. I've tried the above refresh command in a browser and it works perfectly. Is there an alternate way that the 3rd party processor can get the status of the switch when the processor is first started so the programming knows the switch's status (on or off)?

Thanks

Are you wanting to get the current value hubitat has for the device, or specifically force/refreshing the device?

If you do a refresh, and the device is at the same value the hub already thinks the value is at - no event is created, so there is no feedback via Maker API.

So I'm not sure there is a way to do what you want... There might be, but I can't think of how I would do it.

Thanks @JasonJoel. I'm just trying to find out what state the device is in. The command you specified returns the details of all the devices, is there a way to just query one device by it's ID?

Thanks again for the help

No, it returns the all of the currentValues for the device specified only. Not all devices.

image

This would be for all devices:
http://192.168.1.124/apps/api/devices?access_token=xxxx
(notice no device number after /devices)

Or this if you wanted EVERYTHING for ALL devices:
http://192.168.1.124/apps/api/devices/all?access_token=xxxx

This is all in the Maker API documentation:
https://docs.hubitat.com/index.php?title=Hubitat™_Maker_API

Thanks for reminding me where the commands were all documented. I played around with the commands and tried

http://192.168.1.124/apps/api/37/devices/1?access_token=xxxx

Unfortunately, this again looks like its routed to port 80.

Thanks again

Yes. Only EVENTS are routed to the POST URL. And you can't force Hubitat to make an event for a value from Maker API - the driver/hub processing decides that.

Your 3rd party processor really needs to be able to handle HTTP GET responses and POST events.

1 Like

Thanks. I was expecting that once I specified the redirect of responses to port 9000 I could handle all the responses there. I can see now my code is simply going to get messy by having to distribute where responses are processed. Thanks again

Standard protocol with an HTTP GET message is to respond on the same port that the request was received.

I don't know what programming language the other system is using, but in Hubitat there are multiple methods to direct where a response to a GET would go to be processed. The easiest of which is a "callback". So, if you have some sort of programming reference, I would look for that term.

Thanks @Ryan780. The other system is all being programmed in C# so this isn't going to be an issue. I just had to get my head around implementing this differently than I had envisioned. This whole project has gone through several iterations based on my learning curve with Hubitat. It started with porting groovy code from SmartThings to using the Maker API and now the learning curve of working with Maker API. Thanks again for your help.

1 Like