I'm working with someone in England helping them to control their Hunter Hydrawise irrigation system that is connected to a Hubitat Elevation hub from a 3rd party automation processor through the Hubitat Maker API. Most of the commands being sent to the Hubitat Maker API work fine. Such as:
http://[Hubitat IP Address]/apps/api/[Maker API App ID]/devices/[Maker API Device ID/open?access_token=[Access Token]
However, I'm having problems with the suspendZone command; which takes a date in the format of yyyy-mm-dd. The Hydrawise will suspend watering until that date.
The format of the command ends up being:
http://[Hubitat IP Address]/apps/api/[Maker API App ID]/devices/[Maker API Device ID/suspendZone/2021-12-31?access_token=[Access Token]
The strange part is when the person I'm working with sends this particular command from a browser to their Hubitat to control their Hydrawise system they are telling me it works fine.. However, when sent from a third party automation processor to their hubitat they are reporting they get the following error: HttpException: HTTP/1.1 404 Not Found
I've looked at the differences between if the command is sent from a browser to webhooks.site and when the url is sent from a 3rd party system to webhooks.site. I'm not seeing anything that jumps out at me that would stop this from working.
When sent from the 3rd party system I'm not setting any http header info.
The browser, on the other hand sets the following:
Mozilla/5.0 (Windows NT 10.0; Win64; x64) AppleWebKit/537.36 (KHTML, like Gecko) Chrome/92.0.4515.107 Safari/537.36
upgrade-insecure-requests
1
dnt
1
cache-control
max-age=0
host
webhook.site
content-length
content-type
Any ideas on what could be different that would keep the maker api command from being accepted when sent from the 3rd party system would be greatly appreciated.
Thanks so much @sburke781. I thought about url encoding. To check for encoding I redirected the command to webhooks.site. If you aren't familiar with the tool it allows you to view exactly what is being sent by a system including the url, contents, and headers.
When I looked at the received url there didn't appear to be any encoding taking place. I was especially looking for how the dashes in the date and in the security token were handled and neither appeared to be encoded.
I just wanted to double check so I went to https://www.urlencoder.org/ and tested the url. The typical things that are encoded in an url, such as the / characters, were encoded. However, the dash characters in the date, were not.
The only real difference between the open command that works and the suspendZone command that doesn't work are the dashes in the date.
Based on this I don't think the issue could be url encoding.
Have you checked what is displayed in the device edit page for that command? I created a generic attribute driver a while ago to allow the storage of basic data types and the command for storing a date expects dd/mm/yyyy. I was about to suggest changing the format of the date passed in, but that won't work in a URL....
I wasn 't actually able to get it to accept dd/mm/yyyy. I got a little excited when I saw it, but wasn't able to pass it in myself, but maybe the URL encoded version you posted may work....
Thanks @sburke781 . I'll post back here. It will take a few days as I have to pass the code I'm working on to the individual in England so he can test it.
I think you are using the Hydrawise integration that @JustinL and I created. The date format for that command is definitely: yyyy-MM-dd
I think your original syntax is correct. (Side note: what do you do if there are more than one parameters for a command? The Maker API docs don't describe that case).
To rule out more fundamental communication issues between the two systems, I would try something like GET /devices/[device id]/commands from the third party system to make sure you have a route to Hubitat and all of the paths are correct.
You are correct. I know that the person I'm working with in England is using the Hydrawise integration that you and @JustinL wrote as he provided me with a link to your Github where the driver is located. I personally have a Rachio.
I'm just writing the code on a Crestron system that integrates the Crestron system with a Hubitat through the Maker API to open up the Crestron world to off-the-shelf smart devices. The person I'm helping in England has the Hydrawise.
I do know that all the other commands I've implemented work fine such as Start Watering, Stop Watering, Run All Zones, and Stop All Zones. It is the just the suspendZone command that has been problematic.
I have implemented code to communicate with a long list of different devices on the Hubitat including: Buttons, Contact Sensors, Dimmers, various Environmental Sensors, Ceiling Fan Controllers, Light Sensors, Moisture Sensors, Motion Sensors, Multi-Sensors, Philips Hue Bulbs, Presence Sensors, RGB and RGBW bulbs, Shades, Switches, Thermostats, etc. With all these devices I haven't had to pass more than one parameter for any command. There are probably some cases where the device does support commands with multiple parameters but I've pretty much just implemented the common functionality that people use 95% of the time and avoided the corner cases.
That being said, if @sburke781 's idea of passing parameters through a named parameter i.e.
%suspendDateStr=yyyy-mm-dd or %suspendDateStr=dd/mm/yyyy then that would support any number of parameters.
I'll find out more in a few days when the code I sent over to England gets tested.
I wasn't thinking so much of including the name of the parameter, I don't think that would work, I was wondering whether URL encoding a date string with the forward slashes may have worked, e.g. encoding 01/08/2021 as the secondary value.
I also am not sure how to pass through multiple parameters.
You certainly have more experience than I do with Maker API, and I'm just shooting in the dark with ideas to track it down.
Just to be clear, I think you said that other commands in the same Hubitat driver are working from your Crestron setup through Maker API. That would seem to indicate that your headers and general request structure are fine and that something is getting mangled with this specific request.
If your latest shot at it still fails, maybe try this: Instead of the date string with dashes, try sending a flat string of any value. I'd like to see if you can get inside suspendZone and fail there (due to the date not parsing) rather than the 404 from (I assume) Maker API itself.
FYI, here is some info about using commands with multiple parameters: Maker API New Features
I had asked the guy I'm working with in England to make a few tests. One of them is passing an url encoded date string in the format dd%2Fmm%2Fyyyy
Hopefully this will work.
Thanks also for the link to the information on sending multiple parameters! I already use the url post callback to get feedback on that status of devices but being able to send multiple parameters by separating them with a comma will be useful to expand the functionality the code I've written offers people.
