This is what you sent for body with curl.
{t_cool”:74}
And this is what you sent with web requestor:
{“t_cool”,73}
You have a comma instead of colon.
This is what you sent for body with curl.
{t_cool”:74}
And this is what you sent with web requestor:
{“t_cool”,73}
You have a comma instead of colon.
I have tried this many different ways, I set it back to a colon and it still fails.
2022-09-11T15:37:04.529059836+00:00 INFO Web Requestor Multi v1.0 SEND POST COMMAND: http://192.168.0.36/tstat
2022-09-11T15:37:04.532302044+00:00 INFO Web Requestor Multi v1.0 with body: {“t_cool”:73}
2022-09-11T15:37:04.537707586+00:00 INFO Web Requestor Multi v1.0 with headers: Content-Type: application/json
2022-09-11T15:37:04.547385461+00:00 DEBUG Web Requestor Multi v1.0 Web Req Multi Master device thread event handled
2022-09-11T15:37:04.551528753+00:00 DEBUG Web Requestor Multi v1.0 driver device thread event handled
2022-09-11T15:37:04.760364544+00:00 INFO Web Requestor Multi v1.0 response code=<200>, status=<HTTP/1.1 200 OK>
2022-09-11T15:37:04.763954294+00:00 INFO Web Requestor Multi v1.0 <Device: 4420fe1e-558b-47fe-af49-445d823f5dab (Web Req Multi Master)> emitting event: {“attribute_id”:“httpcode”,“capability_id”:“partyvoice23922.httpcode”,“component_id”:“main”,“state”:{“value”:“200”}}
2022-09-11T15:37:04.774477211+00:00 DEBUG Web Requestor Multi v1.0 Response:
{“success”: 0}
And yet the device returns 200 OK which means it received the message and everything was supposedly good with it ?! Very strange…
As far as the driver sees everything worked just fine. It’s got to be one of two things: the body data or headers. One thing you could try is replacing all the special characters with%xx substitutes.
I’ll run some experiments here to see if I can replicate the issue.
I also get the issue with the HTTP Button edge driver from FreeMasen,
this is the curl command
curl -X POST http://192.168.0.45:46415/action -H “Content-Type: application/json” -d curl -X POST http://192.168.0.45:46415/action -H “Content-Type: application/json” -d “{"device_id": "5357fc44-40ec-402b-8ef9-0303a88f7ab4", "action": "hold" }” -v
Note: Unnecessary use of -X or --request, POST is already inferred.
POST /action HTTP/1.1
Host: 192.168.0.45:46415
User-Agent: curl/7.84.0
Accept: /
Content-Type: application/json
Content-Length: 72
POST /action HTTP/1.1
Host: 192.168.0.45:46415
User-Agent: curl/7.84.0
Accept: /
Content-Type: application/json
Content-Length: 72
but when send from Web Req I get a 500 error
2022-09-11T16:20:27.595361378+00:00 INFO Web Requestor Multi v1.0 SEND POST COMMAND: http://192.168.0.45:46415/action
2022-09-11T16:20:27.599261837+00:00 INFO Web Requestor Multi v1.0 with body: {"device_id": "5357fc44-40ec-402b-8ef9-0303a88f7ab4", "action": "hold" }
2022-09-11T16:20:27.602156545+00:00 INFO Web Requestor Multi v1.0 with headers: [Content-Type: application/json]
2022-09-11T16:20:27.607791337+00:00 DEBUG Web Requestor Multi v1.0 Web Req Multi #2 device thread event handled
2022-09-11T16:20:27.612442837+00:00 DEBUG Web Requestor Multi v1.0 driver device thread event handled
2022-09-11T16:20:27.706727378+00:00 INFO Web Requestor Multi v1.0 response code=<500>, status=<HTTP/1.1 500 Internal Server Error>
2022-09-11T16:20:27.710161462+00:00 INFO Web Requestor Multi v1.0 <Device: 1f9c08d9-b5da-455b-a394-9f59ca39943d (Web Req Multi #2)> emitting event: {“attribute_id”:“httpcode”,“capability_id”:“partyvoice23922.httpcode”,“component_id”:“main”,“state”:{“value”:“500”}}
2022-09-11T16:20:27.721559628+00:00 INFO Web Requestor Multi v1.0 <Device: 1f9c08d9-b5da-455b-a394-9f59ca39943d (Web Req Multi #2)> emitting event: {“attribute_id”:“response”,“capability_id”:“partyvoice23922.httpresponse”,“component_id”:“main”,“state”:{“value”:“–”},“visibility”:{“displayed”:false}}
2022-09-11T16:20:27.732032087+00:00 WARN Web Requestor Multi v1.0 HTTP POST request to http://192.168.0.45:46415/action failed with http code 500, status: HTTP/1.1 500 Internal Server Error
Thanks for the details. I’m going to set up a TCP trace and see what difference I can see between what the Edge http library sends vs curl.
BTW, On my thermostat always giving a 200 success message, i found that this only works for API’s that can use either a POST or a GET. There are a few API’s that are only POST and if there is no data or incorrect data it will return an error code.
This seems to have brackets around the Content-Type
that don’t appear in the earlier example. Just wondered if that is causing the 500. The last thing you need is a red herring.
I think my log message puts those there for printing to be able to see any extraneous spaces. Will confirm when I am back to the computer.
Are you having any success with messages that don’t require any body data? Might help us narrow down the problem.
It didn’t seem to in the earlier log, which was why I was querying it.
Good eye; you’re right. I’ll definitely have to look at that…
Yes, if there is no data everything works as expected. interesting the command as follows actual seems to work correctly.
2022-09-11T21:56:19.405451638+00:00 INFO Web Requestor Multi v1.0 SEND POST COMMAND: http://192.168.0.36/tstat/led
2022-09-11T21:56:19.408767054+00:00 INFO Web Requestor Multi v1.0 with body: {“energy_led”:1}
2022-09-11T21:56:19.411671304+00:00 INFO Web Requestor Multi v1.0 with headers:
2022-09-11T21:56:19.417515429+00:00 DEBUG Web Requestor Multi v1.0 Web Req Multi Master device thread event handled
2022-09-11T21:56:19.422738013+00:00 DEBUG Web Requestor Multi v1.0 driver device thread event handled
2022-09-11T21:56:19.713912304+00:00 INFO Web Requestor Multi v1.0 response code=<200>, status=<HTTP/1.1 200 OK>
2022-09-11T21:56:19.718007763+00:00 INFO Web Requestor Multi v1.0 <Device: 4420fe1e-558b-47fe-af49-445d823f5dab (Web Req Multi Master)> emitting event: {“attribute_id”:“httpcode”,“capability_id”:“partyvoice23922.httpcode”,“component_id”:“main”,“state”:{“value”:“200”}}
2022-09-11T21:56:19.728314346+00:00 DEBUG Web Requestor Multi v1.0 Response:
{“success”: 0}
I’m getting a 400 error in the CLI (Bad Request). Curl and Postman work fine, but when using the WebRequestor it fails. I looked in my own API code and it’s hitting the server and failing before it even gets to the route due to the bad request and malformed JSON for some reason (never seen this happen actually). (address redacted but logs below)
2022-09-11T23:20:33.089290532+00:00 INFO Web Requestor Multi v1.0 SEND POST COMMAND: http://192.168.X.XXX:XXXXX/v2/XXXXXXXXXX
2022-09-11T23:20:33.101219657+00:00 INFO Web Requestor Multi v1.0 with body: {“message”:”test”}
2022-09-11T23:20:33.110897949+00:00 INFO Web Requestor Multi v1.0 with headers: Content-type=application/json
2022-09-11T23:20:33.127286157+00:00 DEBUG Web Requestor Multi v1.0 Web Req Multi Master device thread event handled
2022-09-11T23:20:33.132343699+00:00 DEBUG Web Requestor Multi v1.0 driver device thread event handled
2022-09-11T23:20:33.271178324+00:00 INFO Web Requestor Multi v1.0 response code=<400>, status=<HTTP/1.1 400 Bad Request>
2022-09-11T23:20:33.274769366+00:00 INFO Web Requestor Multi v1.0 <Device: a9b89658-78a0-4144-8543-acab60de0445 (Web Req Multi Master)> emitting event: {"attribute_id":"httpcode","capability_id":"partyvoice23922.httpcode","component_id":"main","state":{"value":"400"}}
2022-09-11T23:20:33.296279074+00:00 INFO Web Requestor Multi v1.0 <Device: a9b89658-78a0-4144-8543-acab60de0445 (Web Req Multi Master)> emitting event: {"attribute_id":"response","capability_id":"partyvoice23922.httpresponse","component_id":"main","state":{"value":"--"},"visibility":{"displayed":false}}
2022-09-11T23:20:33.307418866+00:00 WARN Web Requestor Multi v1.0 HTTP POST request to http://192.168.X.XXX:XXXXX/v2/XXXXXXXX failed with http code 400, status: HTTP/1.1 400 Bad Request
2022-09-11T23:20:33.311057657+00:00 DEBUG Web Requestor Multi v1.0 Web Req Multi Master device thread event handled
2022-09-11T23:20:38.128965490+00:00 INFO Web Requestor Multi v1.0 <Device: a9b89658-78a0-4144-8543-acab60de0445 (Web Req Multi Master)> emitting event: {"attribute_id":"selection","capability_id":"partyvoice23922.webrequestselect","component_id":"main","state":{"value":" "},"state_change":true,"visibility":{"displayed":false}}
2022-09-11T23:20:38.157305823+00:00 DEBUG Web Requestor Multi v1.0 driver device thread event handled
Something worth mentioning, i’m only testing using the settings in the actual Web Requestor device, not in a Rule. I’m curious if it would work in a rule instead or if it would fail in both the same way. Thoughts?
One thing to watch out for is the double-quote character.
In this log, the body contains left and right quotes around the key and value. I don’t know if that’s just the way it is being displayed here in the forum, but just make sure you are using the regular double quote character. Sometimes if you copy paste from other sources it pulls in the left and right quotes instead.
It shouldn’t make a difference; the same code path is executed for the most part.
OK - this is good to know.
This seems to be for a different device too, yes?
Just noticed that there’s an extra space prior to your last bracket. Probably not an issue, but just in case…
Wow. Smart quotes sneaking in without realizing it. iOS defaults to smart quotes when you use double quotes. You have to press and hold to select regular double quotes instead. Once I did this it worked like a charm. Great eye @TAustin !!
I think I may have found the issue, and we’re all going to kick ourselves if this is it…
Get rid of all the quotes inside your json string. Curl will actually remove them before sending the request if it’s a json-formatted body.
This is a TCP dump of the curl command:
POST /action HTTP/1.1
Host: 192.168.1.140:6666
User-Agent: curl/7.83.1
Accept: */*
Content-Type: application/json
Content-Length: 64
{device_id: 5357fc44-40ec-402b-8ef9-0303a88f7ab4, action: hold }
Notice there are no quotes in the sent data body even though I executed curl with this command:
curl http://192.168.1.140:6666/action -H “Content-Type: application/json” -d “{“device_id”: “5357fc44-40ec-402b-8ef9-0303a88f7ab4”, “action”: “hold” }”
Now, if I configure a web requestor slot similarly to your request with this as the body (used the regular keyboard double-quote character):
{“device_id”: “5357fc44-40ec-402b-8ef9-0303a88f7ab4”, “action”: “hold” }
The quote characters are getting transposed into UTF-8 encoding for left and right quotes!!! Not by the driver, but by the underlying http library or TCP layers.
You can see it here in this TCP dump:
00000000 47 45 54 20 2f 61 63 74 69 6f 6e 20 48 54 54 50 GET /act ion HTTP
00000010 2f 31 2e 31 0d 0a /1.1..
00000016 43 6f 6e 6e 65 63 74 69 6f 6e 3a 20 63 6c 6f 73 Connecti on: clos
00000026 65 2c 20 54 45 0d 0a 41 63 63 65 70 74 3a 20 2a e, TE..A ccept: *
00000036 2f 2a 0d 0a 54 45 3a 20 74 72 61 69 6c 65 72 73 /*..TE: trailers
00000046 0d 0a 43 6f 6e 74 65 6e 74 2d 4c 65 6e 67 74 68 ..Conten t-Length
00000056 3a 20 38 38 0d 0a 55 73 65 72 2d 41 67 65 6e 74 : 88..Us er-Agent
00000066 3a 20 73 6f 63 6b 65 74 20 33 2e 30 2d 72 63 31 : socket 3.0-rc1
00000076 0d 0a 48 6f 73 74 3a 20 31 39 32 2e 31 36 38 2e ..Host: 192.168.
00000086 31 2e 31 34 30 3a 36 36 36 36 0d 0a 0d 0a 1.140:66 66....
00000094 7b e2 80 9c 64 65 76 69 63 65 5f 69 64 e2 80 9d {...devi ce_id...
000000A4 3a 20 e2 80 9c 35 33 35 37 66 63 34 34 2d 34 30 : ...535 7fc44-40
000000B4 65 63 2d 34 30 32 62 2d 38 65 66 39 2d 30 33 30 ec-402b- 8ef9-030
000000C4 33 61 38 38 66 37 61 62 34 e2 80 9d 2c 20 e2 80 3a88f7ab 4..., ..
000000D4 9c 61 63 74 69 6f 6e e2 80 9d 3a 20 e2 80 9c 68 .action. ..: ...h
000000E4 6f 6c 64 e2 80 9d 20 7d old... }
UTF-8 for left quote: e2 80 9c
UTF-8 for right quote: e2 80 9d
So although we’ve hopefully solved your issue by just removing the quotes altogether, we’re still left with this potential issue.
What I suspect is that in your case, your device did not know how to deal with the UTF-8 encoding. Other devices or applications may have no problem with it. (I had a Python http server receiving this test request, and it recognized the UTF-8 encoded quotes with no problems)
Sorry for the longwinded response, but I like to document these things for others!