Cloud API nebulous

I’m having trouble understanding the use of the cloud to poll variables, functions on our device (Electron in my case).

I think I have registered my Electron OK – I can go to the dashboard and see its device id.

I previously installed “Node.js” and installed the Particle driver and installed Particle CLI with “npm install -g particle-cli”.

I have “flashed” my Electron with the example program: “functionvariable.ino” by using Particle Build to download the compiled code and flash the device over USB using: “particle flash --serial firmware.bin”. It seems to go OK now (after some initial failures).

Reading the Cloud API, I think I should be able to fetch the value of the photoresistor using the URL in Chrome:{my device id}/analogvalue -d access_token={my access token}

I get my device id from the Particle Dashboard, and the access token from Particle Build | Settings.

But I always get the response:

“error”: “invalid_request”,
“error_description”: “The access token was not found”

I suspect this is not a correct “rest” web service call. I don’t understand the implications of using the “curl” terminal app to show us examples.

Update: I think this URL seems more appropriate, but I get the same response:


Did you register variable analogvalue with Particle.variable(‘analogvalue’,variable_name) in the setup portion of your application?


For quick testing you could use this page as well: to call functions/variables easily.

1 Like

The backslashes (\) in the doc samples should only denote line breaks, but should not be part of your command.

curl is a tool (present on most Linux platforms) to allow easy GET/POST requests from the command line.
The use of the -d switch in a command implicitly makes it a POST request (in the doc samples this is :wink: - it’s a bit more invovled, but that would be discussed in 3rd party curl docs)

Thanks - that variation worked. I should have guessed the backslashes were not part of it. I think the examples could be a little clearer in the Cloud API doc (particularly clearly partitioning the POST, GET, etc. examples) – the use of curl adds uncertainty to interpreting the requests, and in my opinion the docs should especially highlight a URL example for a standard web browser. The “two pane” format of the Docs is good on one hand, but sometimes adds confusion as to what goes with what; it also makes printing more of a chore.

If you’ve got suggestions/ideas on how to improve, then please do hit the ‘edit’ button at the top and make a pull request in the relevant parts on GitHub. It’s open source for a reason, and community contributions are highly welcome :)!

Using that same edit button will take you to the respective GitHub page, which may, or may not, be more printer-friendly :slight_smile:

OK, will do!

Thanks again for help in clarifying it all.

1 Like