Ricoh Theta Z1 Doesn't Accept My Request to Change File Format - theta360

I am using a Ricoh Theta Z1 updated to the most recent firmware (1.60.1). I am trying to debug an Android application, but I found that one of our commands was repeatedly failing, so I connected to the camera directly from my dev box and tested the protocol directly via curl.
It's my understanding from the documentation that this command should work:
$ curl -X POST -H "Content-Type: application/json; charset=UTF-8" -d '{"name":"camera.setOptions", "parameters":{"options":{"captureMode":"image","fileFormat":{"height":3360,"type":"jpeg","width":6720}}}}' http://192.168.1.1/osc/commands/execute
But when I run this command I get this response:
{"error":{"code":"invalidParameterValue","message":"Any input parameter or option name is recognized, but its value is invalid."},"name":"camera.setOptions","state":"error"}
This in spite of the fact that when I ask the camera about its options, it responds with the exact block it has just told me wouldn't parse:
$ curl -X POST -H "Content-Type: application/json; charset=UTF-8" -d '{"name":"camera.getOptions", "parameters":{"optionNames":["clientVersion","captureMode","fileFormat"]}}' http://192.168.1.1/osc/commands/execute
gets this response:
{"name":"camera.getOptions","results":{"options":{"captureMode":"image","clientVersion":2,"fileFormat":{"height":3360,"type":"jpeg","width":6720}}},"state":"done"}
Furthermore, when I run the first command and omit the fileFormat parameter, the command executes just fine.
Any ideas what I am doing wrong here?

After a bunch of trial and error, I discovered that it is possible to use camera.setOptions to set the file format on the camera, but only if the fileFormat block is the only member of the options block. That is to say, this command:
$ curl -X POST -H "Content-Type: application/json; charset=UTF-8" -d '{"name":"camera.setOptions", "parameters":{"options":{"fileFormat":{"height":3360,"type":"jpeg","width":6720}}}}' http://192.168.1.1/osc/commands/execute
will succeed. I think this must be a bug in the Theta Z1 camera, because as far as I can discern from the docs (https://api.ricoh/docs/theta-web-api-v2/commands/camera.set_options/ and https://developers.google.com/streetview/open-spherical-camera/reference/camera/setoptions), there shouldn't be any restriction on what JSON goes into the options block. In any case, the workaround is simple enough: issue one command to set the file format and one or more as necessary to set the other options, and then you're good to go.

FYI, there is a similar bug with dateTimeZone. see this post
https://community.theta360.guide/t/how-setup-datetime-on-theta-camera-using-web-api/6572/3?u=craig
It seems like there are a few options that need to be set as a standalone option.
If you want to set dateTimeZone, it must be the only option set. I reported this to RICOH. I am going to post your findings on the community.theta360.guide forum to make it easier to find. Thanks.

Related

Autodek Forge Tutorial

I have been working through the Autodesk Forge Sample App tutorial.
WHen I click the button to connect with my account I get this error;
{"developerMessage":"The required parameter(s) redirect_uri not present in the request","errorCode":"AUTH-008","more info":"https://forge.autodesk.com/en/docs/oauth/v2/developers_guide/error_handling/"}
If you get this error, you probably trying a 3 legged oauth flow. And it means that you did not provide the callback url in the request. Since you did not say which tutorial you have been using, let me point you to 2 sources - the Forge documentation tutorial here or the Learn Forge tutorial here
In both case, it is important to have the callback url defined in the application page on the Forge portal - If you are using your local machine, it should be something like http://localhost:3000/mycallback. The learnforge material tells you to define it as (see here):
http://localhost:3000/api/forge/callback/oauth
where the documentation tutorial says to use
http://sampleapp.com/oauth/callback
but here they assume you own the domain sampleapp.com which is probably not true. You need to replace sampleapp.com by your own domain or the localhost:port when developing your webserver on your local machine. Note it is important to use your true domain vs localhost when you'll run the code on your server, and update both your application page and your code to use the same definition. I usually setup 3 applications (dev: with localhost:3001, staging: with myapp-staging.autod3sk.net, and production: with myapp.autod3sk.net) - this is to avoid to have to edits keys all the time and make the application deployment a lot easier.
Now that your application is setup, you need to use that URL in your request as documented in the Oauth API. But all parameters should be URL encoded, otherwise the / character will be misinterpreted by the server. Failing to pass the correct and encoded URL parameter in the request will result in the error you are seeing.
Here is an example:
https://developer.api.autodesk.com/authentication/v1/authorize \
?response_type=code \
&client_id=MYCLIENT_ID \
&redirect_uri=MY_ENCODE_CALLBACKURL \
&scope=REQUIRED_SCOPES
after replacing the placeholders, it should look like this
https://developer.api.autodesk.com/authentication/v1/authorize\
?response_type=code\
&client_id=oz9f...k2d\
&redirect_uri=http%3a%2f%2flocalhost%3a3000%2fapi%2fforge%2fcallback%2foauth\
&scope=data%3aread
Copy this in your browser, and after logging and the consent page, the service should return to your browser with a URL like this:
http://localhost:3000/api/forge/callback/oauth?code=wroM1vFA4E-Aj241-quh_LVjm7UldawnNgYEHQ8I
Because, we do not have a server yet, the browser will error, but you can clearly see the URL returned to you with a code. You know need to copy that code into another request to get the final token. Here, we will use curl, but ideally both request and the callback should be handled by your server code.
curl 'https://developer.api.autodesk.com/authentication/v1/gettoken' \
-X 'POST' \
-H 'Content-Type: application/x-www-form-urlencoded' \
-d 'client_id=oz9f...k2d' \
-d 'client_secret=eUr...Q1e' \
-d 'grant_type=authorization_code' \
-d 'code=wroM1vFA4E-Aj241-quh_LVjm7UldawnNgYEHQ8I' \
-d 'redirect_uri=http://localhost:3000/api/forge/callback/oauth'
Ideally, all this needs to be done in your server code, like the learnforge tutorial teach you to do.

Passing user and password in URL doesn't work

I have some URL like this : X.XXX.XXX.XXX:10080
I tried to add a user and password in this url like this: http://OLM:OLM794$#X.XXX.XXX.XXX:10080
User = OLM
Psw = OLM794$
And it doesn't work
Also when I run : curl http://OLM:OLM794$#X.XXX.XXX.XXX:10080 it shows me :
curl: (6) Could not resolve host:OLM:OLM794X.XXX.XXX.XXX, it removes $# and the port :10080
When I try : curl -u OLM X.XXX.XXX.XXX:10080 then I enter the password, it works, Im able to connecte to that server.
My need is to call my url with user and password like this:
http://OLM:OLM794$#X.XXX.XXX.XXX:10080
But it doesn't work.
I read this solution : Using cURL with a username and password? but I haven't found solution
Have you an idea why ?
It would seem curl parses and reconstructs the URL, leaving out characters that it thinks are illegal. For me, the same command gives a different error though.. It could be that your curl version differs from mine.
$ curl -v http://OLM:OLM794$#127.0.0.1:10000
* Rebuilt URL to: http://OLM:OLM794127.0.0.1:10000/
* Port number ended with 'O'
* Closing connection -1
curl: (3) Port number ended with 'O'
The solution is quite trivial, just url-escape the $ symbol: %24:
$ curl http://OLM:OLM794%24#127.0.0.1:10000
According to RFC1738, the dollar-sign was allowed as an unreserved character and could be directly used, but this old RFC has since been updated many times. RFC3986, for example, does not mention it as an unreserved character anymore. This means the $ symbol has received a special meaning and should be encoded in any URL where it does not serve the function it was given.

Watson Knowledge Studio integration with Watson Discovery

I was able to get the my_config.json file by doing the provided curl statement and update/save it, but when I PUT it given the requested curl I am receiving a 415 error, unsupported media type. According to the documentation, it's supposed to accept the .json. This is what I'm using: curl -X PUT -u "discovered":"discoverypw" -H “Content-Type: application/json” -d#my_config.json
I supposed you are trying to update a configuration.
I tried the operation as described at the following page and could not reproduce your problem. I could update my configuration.
https://www.ibm.com/watson/developercloud/discovery/api/v1/#replace_configuration

Google Drive Resumable Uploads

I am having trouble requesting the current status of a resumable upload. Based on the Google Documentation, the following request should return a Range header with the current range google has of my upload, but I keep getting the following response:
Failed to parse Content-Range header
Here is my curl request:
curl -H "Content-Range: bytes */1443452365" -H "Content-Length: 0" locationUrl -X PUT
I have also tried "bytes */*" and "*/*" for the Content-Range header, but no luck.
Any ideas?
First, you need to check the correct request format like the sample given below:
curl -H "Accept: application/json" -H "Content-type: application/json" -X POST -d '{"id":100}' http://localhost/api/postJsonReader.do
And, discussed in other command-line tools, when sending raw HTTP data, be aware that the POST and PUT operations will require computing the value for a Content-Length header. You can use the UNIX tool wc to compute this value. Place all the content of the HTTP body into a text file such as template_entry.xml (example used above) and run wc -c template_entry.xml. It is often difficult to debug if you accidentally use an incorrect value for the Content-Length header.
Lastly, you can request the status between chunks, not just if the upload is interrupted. If the upload request is interrupted, follow the procedure outlined in resume an interrupted upload.

WSO2 Data Services JSON issue

I hope you can help me getting JSON REST WSO2 Data Service work.
I use v 3.0.1 and sample data service. I suspect that I do smth wrong...
I created a resource 'products' that is bound to productsSQL query.
XML REST request work perfectly, but not JSON:
curl --request GET
http://myserver.com:9763/services/samples/RDBMSSample.HTTPEndpoint/products
-H Content-Type:"application/json"
returns
> "Fault":{"faultcode":"","faultstring":"No JSON message received
> through HTTP GET or POST","detail":""}}
From the source code looks like it expects to have some request body in request url (which is strange), so the next query is
curl --request GET
http://myserver.com:9763/services/samples/RDBMSSample.HTTPEndpoint/products?q=emptyquery
-H Content-Type:"application/json"
This one hangs and on server after several minutes I get the following exception:
> Feb 24, 2013 8:08:13 PM
> org.apache.tomcat.util.net.NioEndpoint$SocketProcessor run SEVERE:
> java.lang.ThreadDeath at java.lang.Thread.stop(Thread.java:776) at
> org.wso2.carbon.tomcat.ext.valves.CarbonStuckThreadDetectionValve.handleStuckThread(CarbonStuckThreadDetectionValve.java:121)
> at
> org.wso2.carbon.tomcat.ext.valves.CarbonStuckThreadDetectionValve.backgroundProcess(CarbonStuckThreadDetectionValve.java:175)
> at
> org.apache.catalina.core.ContainerBase.backgroundProcess(ContainerBase.java:1387)
> at
> org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.processChildren(ContainerBase.java:1566)
> at
> org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.processChildren(ContainerBase.java:1576)
> at
> org.apache.catalina.core.ContainerBase$ContainerBackgroundProcessor.run(ContainerBase.java:1555)
> at java.lang.Thread.run(Thread.java:680)
The following query works, however:
curl --data '{"employeesbynumber":{"employeenumber":{"$":"1002"}}}'
http://myserver.com:9763/services/samples/RDBMSSample/ --header
Content-Type:"application/json" --header
SOAPAction:"urn:employeesByNumber"
So after several hours debugging WSO2 DSS and Axis2 code there is a fix:
Reason: WSO2 still runs on Axis 1.6.1 which had some critical bugs in JSONOMBuilder and JSONDataSource (which seem to have been fixed in 1.6.2). Specifically it required all GET requests to have input parameter and also wrapped in a root element + some other issues. The fact is that inside, AXIS2 maps JSON payload to SOAP body, so needs to have root element..
Solution More of a workaround: For GET requests pass request body with parameters wrapped in a root element (and of course url encoded). Even if you do not have parameters - pass them anyway.
So the following queries work:
curl --request GET http://192.168.1.10:9763/services/samples/RDBMSSample.HTTPEndpoint/employees?q=%7B%22request%22%3A%7B%22employeeNumber%22%3A%221%22%7D%7D%20 -H Content-Type:"application/json"
And this one for query without parameter but passing dummy one anyway:
curl --request GET http://192.168.1.10:9763/ervices/samples/RDBMSSample.HTTPEndpoint/products?q=%7B%22request%22%3A%7B%22employeeNumber%22%3A%221%22%7D%7D%20 -H Content-Type:"application/json"
Hope WSO2 guys will update to latest Axis2 soon...
I think the way you call REST cal from curl is wrong if you want to play with curl you can use the reference [1].
the correct message would be
curl -i -H "Accept: application/json" http://myserver.com:9763/services/samples/RDBMSSample.HTTPEndpoint/products
Else there is a good Google chrome plugin "Advanced REST client" you can simply use it for invoke REST services.
[1]. http://blogs.plexibus.com/2009/01/15/rest-esting-with-curl/