JSON call from Curl

[wpiman]

I am trying to make JSON calls to HS from a linux machine. It is on the same subnet. No authority issues.

First, I make the call with the entire website totally filled out. This works fine. Next, I use the CURL JSON to pass the arguments.

I was doing this in HS3 I believe and from Linux and more importantly from the iOS shortcut tool.

I tried a myriad of options here, but I wasn't able to get HS to respond to the JSON command no matter what I did.

Can someone confirm this?

--- SCRIPT----------
curl -v -H 'Content-type: application/json' http://192.168.0.5/JSON?request=hsversion
curl -X GET \
-H "Content-type: application/json" \
-H "Accept: application/json" \
-d {"action":"hsversion"} \
"http://192.168.0.5/JSON" -v

----RESULTS-------------------------
source runmedo

* Trying 192.168.0.5...

* TCP_NODELAY set

* Connected to 192.168.0.5 (192.168.0.5) port 80 (#0)

> GET /JSON?request=hsversion HTTP/1.1

> Host: 192.168.0.5

> User-Agent: curl/7.58.0

> Accept: */*

> Content-type: application/json

>

* HTTP 1.0, assume close after body

< HTTP/1.0 200 OK

< Server: HomeSeer

< Cache-Control: no-cache

< Access-Control-Allow-Origin: *

< Content-Type: application/json; charset=utf-8

< Accept-Ranges: none

< Content-Length: 24

<

* Closing connection 0

{ "Response":"4.1.2.0" }*

Trying 192.168.0.5...

* TCP_NODELAY set

* Connected to 192.168.0.5 (192.168.0.5) port 80 (#0)

> GET /JSON HTTP/1.1

> Host: 192.168.0.5

> User-Agent: curl/7.58.0

> Content-type: application/json

> Accept: application/json

> Content-Length: 18

>

* upload completely sent off: 18 out of 18 bytes

* HTTP 1.0, assume close after body

< HTTP/1.0 200 OK

< Server: HomeSeer

< Cache-Control: no-cache

< Access-Control-Allow-Origin: *

< Content-Type: application/json; charset=utf-8

< Accept-Ranges: none

< Content-Length: 35

<

* Closing connection 0

{ "Response":"Error, bad request"

[zwolfpack]

This works for me

HS3

curl 192.168.1.103/JSON?request=hsversion
{ "Response":"3.0.0.548" }

HS4

curl 192.168.1.111/JSON?request=hsversion
{ "Response":"4.1.2.0" }

[zwolfpack]

In your second form, appears you're trying to mix POST data option (-d) with a GET request. Perhaps over-complicated ?

[wpiman]

In your second form, appears you're trying to mix POST data option (-d) with a GET request. Perhaps over-complicated ?

According to this...

https://ec.haxx.se/http/http-post#convert-that-to-a-get

I should be able to use a -G and a -d option for getting and it will convert it to the appropriate URL.

[wpiman]

This works for me

HS3

curl 192.168.1.103/JSON?request=hsversion
{ "Response":"3.0.0.548" }

HS4

curl 192.168.1.111/JSON?request=hsversion
{ "Response":"4.1.2.0" }

I don't have HS3 running-- what about (with your IPs)

curl -G -d '{"action","hsversion"}' 192.168.1.111/JSON
curl -G -d '{"action","hsversion"}' 192.168.1.103/JSON

[zwolfpack]

I don't have HS3 running-- what about (with your IPs)

curl -G -d '{"action","hsversion"}' 192.168.1.111/JSON
curl -G -d '{"action","hsversion"}' 192.168.1.103/JSON

HS3

curl -G -d '{"action","hsversion"}' 192.168.1.103/JSON
{ "Response":"Error, request missing" }

HS4

curl -G -d '{"action","hsversion"}' 192.168.1.111/JSON
{ "Response":"Error, request missing" }

[zwolfpack]

Sending that request to a http server that prints out what was received

curl -G -d '{"action","hsversion"}' 192.168.1.118:8000/JSON

GET /JSON?%7B%22action%22,%22hsversion%22%7D HTTP/1.1
Accept: */*
Host: 192.168.1.118:8000
User-Agent: curl/7.66.0

Contrast to the working

curl 192.168.1.118:8000/JSON?request=hsversion

GET /JSON?request=hsversion HTTP/1.1
Accept: */*
Host: 192.168.1.118:8000
User-Agent: curl/7.66.0

[zwolfpack]

And this works for HS3 or HS4

curl -G -d 'request=hsversion' 192.168.1.111/JSON

[wpiman]

And this works for HS3 or HS4

curl -G -d 'request=hsversion' 192.168.1.111/JSON

Thanks! I think the

-H "Content-type: application/json"

switch is supposed to tell CURL to interpret the -d as JSON and format it for the webpage.

Does that work when you send to that 8000 port on your system?

What I am really trying to do here is come up with a script that I can run from iOS shortcuts that takes Dictated Text and passed it to Linux over ssh and then . I was using wget with the passed text, but it had to be formatted.


https://forums.homeseer.com/forum/ho...hone-shortcuts

[wpiman]

I ended up just using the full URL for now. I source the following script from ssh iOS shortcuts and pass the dictate speech as "SPEAK". This parses it and calls voice command and passes the spoken phrase with the urlencode command.

# Called from iOS shortcuts. SPEAK will be the text
PHRASE=`urlencode $SPEAK`
RETURN=`curl http://192.168.0.5/JSON?request=voicecommand\&phrase=$PHRASE`
echo $RETURN


When I want to do the broadcast message, I had to do this. The URL encode didn't work here for some reason?! Homeseer must parse the phrases differently.

# Called from iOS shortcuts. SPEAK will be the text
#PHRASE=`urlencode $SPEAK`
# HS doesn't use url encode?!
PHRASE=`echo $SPEAK|sed 's/ /%10/g'`
RETURN=`curl http://192.168.0.5/JSON?request=speak\&phrase=$PHRASE`
echo $RETURN

[zwolfpack]

Thanks! I think the

-H "Content-type: application/json"

switch is supposed to tell CURL to interpret the -d as JSON and format it for the webpage.

I doubt that. The -H option just tells curl to send the given parameter as a request header.

sending
curl -G -d '{"action","hsversion"}' 192.168.1.118:8000/JSON
gives

GET /JSON?%7B%22action%22,%22hsversion%22%7D HTTP/1.1
Accept: */*
Host: 192.168.1.118:8000
User-Agent: curl/7.66.0

sending
curl -G -d '{"action","hsversion"}' -H "Content-type: application/json" 192.168.1.118:8000/JSON
gives

GET /JSON?%7B%22action%22,%22hsversion%22%7D HTTP/1.1
Accept: */*
Host: 192.168.1.118:8000
User-Agent: curl/7.66.0
Content-Type: application/json

As expected, same except for addition of the extra header.

Interpretation of the header would be up to the receiving server (HS3/HS4). However, per https://stackoverflow.com/questions/...p-get-requests

the Content-Type HTTP header should be set only for PUT and POST requests.