开云体育

ctrl + shift + ? for shortcuts
© 2025 Groups.io
  1. Crestron
  2. Topics

http command works when sent from a browser but not when sent from a Crestron system

 

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 Crestron system.? Most of the commands being sent to the Hubitat to control the Hydrawise work fine.? Such as:

[Hubitat IP Address]/apps/api/20/devices/100/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:

[Hubitat IP Address]/apps/api/20/devices/100/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 Crestron 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 Crestron system to webhooks.site.? I'm not seeing anything that jumps out at me that would stop this from working.

When sent from the Crestron system I'm not setting any http header info.

The browser, on the other hand sets the following:

|connection|close|
|---|---|
|sec-gpc|1|
|accept-language|en-US,en;q=0.9|
|accept-encoding|gzip, deflate|
|accept|text/html,application/xhtml+xml,application/xml;q=0.9,image/avif,image/webp,image/apng,*/*;q=0.8,application/signed-exchange;v=b3;q=0.9|
|user-agent|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 Hubitat command from being accepted when sent from the Crestron system would be greatly appreciated.

Thanks in advance for the help

Jay
 

I have been messing with some HTTP stuff recently myself.? I've found the best thing is to run wireshark on the system with the browser and see what the traffic back and forth looks like.? In my case the device was doing digest authentication, which is impossible to deal with without S#.
 

I have no experience with the Hubitat or the Hydrawise, but ideally the response for an auth issue should be a 401 or 403 and not the 404 that you're seeing.? A 404 is supposed to indicate an issue in the URL string.? However, it could be worth a try to leave off the access_token URL parameter (and/or supply a bogus value) on the Crestron call and see if a 404 is still returned.? If the response changes to a 401 or 403 then you have some confidence that you're not dealing with an auth issue with your access_token.? Also, may want to try the browser calling the URL without the access_token and compare that with Crestron calling the URL without access_token to see if there's a difference in response/behavior between the two in that scenario.??

I've seen some equipment that needed certain headers before playing nice, so another suggestion would be adding some of the headers that aren't currently being sent from the Crestron call.? To help with issues like this I tend to use the curl command from a command prompt instead of the browser when troubleshooting.? If a basic curl command with no headers works, then I would suspect something in how the Crestron program is formatting the command and at that point you could try comparing the curl call vs the Crestron call (with the webhooks site or wireshark) without the noise of the additional headers that the browser introduced.? If curl also fails when you use it without headers, then could try adding the headers one by one that the web browser is sending.??

Good luck!

On Sunday, August 1, 2021, 08:58:36 AM CDT, Wyatt J <wyatt@...> wrote:


I have been messing with some HTTP stuff recently myself.? I've found the best thing is to run wireshark on the system with the browser and see what the traffic back and forth looks like.? In my case the device was doing digest authentication, which is impossible to deal with without S#.

 

开云体育

Thanks Wyatt.

The challenge here is that I'm almost 5000 miles away from where all the hardware is located so trying to use wireshark is a bit of an issue.? Also, all the commands the software is sending to the Hubitat work with the single exception of the command to suspend watering.? There is just something different when the date is attached to the end of the url that works when entered using a browser but doesn't work when sent through S#.

Thanks again

Jay

On 8/1/2021 7:58 AM, Wyatt J wrote:

I have been messing with some HTTP stuff recently myself.? I've found the best thing is to run wireshark on the system with the browser and see what the traffic back and forth looks like.? In my case the device was doing digest authentication, which is impossible to deal with without S#.

 

开云体育

Thanks Ken,

I am sending multiple different commands to the hubitat that all work perfectly.? It is just the for suspending watering until a date that is causing issues.? So, I know that the token and authorization are fine.?

My guesses are that it is either a header issue or something with the way the url (with the date) is being encoded that is causing the problem.? I was hoping someone would look at the url, that has more http knowledge than I do, and the issue would be obvious to them.

Using curl is a great idea since there is much more control of the headers than with a browser.?

Thanks again

Jay

On 8/1/2021 11:51 AM, Ken Ragan via groups.io wrote:

I have no experience with the Hubitat or the Hydrawise, but ideally the response for an auth issue should be a 401 or 403 and not the 404 that you're seeing.? A 404 is supposed to indicate an issue in the URL string.? However, it could be worth a try to leave off the access_token URL parameter (and/or supply a bogus value) on the Crestron call and see if a 404 is still returned.? If the response changes to a 401 or 403 then you have some confidence that you're not dealing with an auth issue with your access_token.? Also, may want to try the browser calling the URL without the access_token and compare that with Crestron calling the URL without access_token to see if there's a difference in response/behavior between the two in that scenario.??

I've seen some equipment that needed certain headers before playing nice, so another suggestion would be adding some of the headers that aren't currently being sent from the Crestron call.? To help with issues like this I tend to use the curl command from a command prompt instead of the browser when troubleshooting.? If a basic curl command with no headers works, then I would suspect something in how the Crestron program is formatting the command and at that point you could try comparing the curl call vs the Crestron call (with the webhooks site or wireshark) without the noise of the additional headers that the browser introduced.? If curl also fails when you use it without headers, then could try adding the headers one by one that the web browser is sending.??

Good luck!

On Sunday, August 1, 2021, 08:58:36 AM CDT, Wyatt J <wyatt@...> wrote:


I have been messing with some HTTP stuff recently myself.? I've found the best thing is to run wireshark on the system with the browser and see what the traffic back and forth looks like.? In my case the device was doing digest authentication, which is impossible to deal with without S#.

 

This would be a use for Postman. I use it for testing any http stuff.
 

Hi Jay,

I use Wireshark at work exclusively on remote machines.? I RDP into a remote server or PC, install Wireshark, then before starting a capture I add a filter to keep the files size down.? It hasn't failed me yet.

Good luck,
Thyce


On Sun, Aug 1, 2021 at 12:18 PM jbasen <jay.m.basen@...> wrote:

Thanks Wyatt.

The challenge here is that I'm almost 5000 miles away from where all the hardware is located so trying to use wireshark is a bit of an issue.? Also, all the commands the software is sending to the Hubitat work with the single exception of the command to suspend watering.? There is just something different when the date is attached to the end of the url that works when entered using a browser but doesn't work when sent through S#.

Thanks again

Jay

On 8/1/2021 7:58 AM, Wyatt J wrote:
I have been messing with some HTTP stuff recently myself.? I've found the best thing is to run wireshark on the system with the browser and see what the traffic back and forth looks like.? In my case the device was doing digest authentication, which is impossible to deal with without S#.

 

开云体育

Thanks Kenny.? I'll take a look at Postman

Jay

On 8/1/2021 1:51 PM, Kenny Hays wrote:

This would be a use for Postman. I use it for testing any http stuff.
 

开云体育

Thanks Thyce

On 8/1/2021 2:07 PM, Thyce : wrote:

Hi Jay,

I use Wireshark at work exclusively on remote machines.? I RDP into a remote server or PC, install Wireshark, then before starting a capture I add a filter to keep the files size down.? It hasn't failed me yet.

Good luck,
Thyce


On Sun, Aug 1, 2021 at 12:18 PM jbasen <jay.m.basen@...> wrote:

Thanks Wyatt.

The challenge here is that I'm almost 5000 miles away from where all the hardware is located so trying to use wireshark is a bit of an issue.? Also, all the commands the software is sending to the Hubitat work with the single exception of the command to suspend watering.? There is just something different when the date is attached to the end of the url that works when entered using a browser but doesn't work when sent through S#.

Thanks again

Jay

On 8/1/2021 7:58 AM, Wyatt J wrote:
I have been messing with some HTTP stuff recently myself.? I've found the best thing is to run wireshark on the system with the browser and see what the traffic back and forth looks like.? In my case the device was doing digest authentication, which is impossible to deal with without S#.

 

I just wanted to follow up that adding a little bit of extra header information to the http request solved the problem.?

Thanks again to everyone that responded with suggestions.
 
Edited

Usually, there's a minimum acceptable amount of header info that products require and finding that can be time consuming. ?The process of stripping something down to its barest essence is called Muntzing. It's some good geeky early A/V history actually, I have my grandfathers Muntz 8-Track in my office for inspiration. ?
 

I use Fiddler2 from Telerik to quickly figure out http headers and responses. I found it very useful when debugging SSL problems as well.
Paul
 

开云体育

Thanks Paul

On 8/4/2021 8:32 AM, sfbusfbu wrote:

I use Fiddler2 from Telerik to quickly figure out http headers and responses. I found it very useful when debugging SSL problems as well.
Paul

1 - 13 of 13