Communication Standard Form

HTTP Request model

The Guardian Cloud system works with an HTTP request model quite simply to make the collection and processing of data.

The default HTTP method is GET (can be tested directly from the browser), intended to facilitate efficient access to the system we created a simplified URL, which can be accessed through the address: http://guardiao.cl.

One data will always be referenced is the Number of Device Series and the API Key, so keep these values in hand, and any questions of how to obtain this value, go here.

If in doubt of what could be invented visit our site examples.

There is a standard HTTP return code for all devices, the return code and its meaning is below:

Code HTTP Meaning
200 Information obtained / stored successfully.
404 Number not found.
500 Failed to find the project (Api Key not found)
501 Illegal State Shipping (only trigger).

Collecting device

To perform data collection, it is only necessary to call the URL: /collect/ then say what Serial number the device.

After such a call is required to pass the parameter containing the API Key, in the following format: ?apiKey={API_KEY} in our example below we use the following value: ?apiKey=497aa991-d8e6-4bb6-ad17-f01a13648333.

Any other value passed after this parameter is understood as data collection, that is, after the value of API Key, separado por & It will be understood to value any collection.

$ curl -X GET "http://guardiao.cl/collect/IOTWBS0001/?apiKey=497aa991-d8e6-4bb6-ad17-f01a13648333&temperatura=10&humidade=30&luminosidade=15"
# response: {"status":"OK"}

In our example here, three pieces of information being collected: &temperature=10&humidity=30&luminosity=15. For each value is displayed as shown below:

Identifier Value
temperature 10
humidity 30
luminosity 15

Remembering!! The data collection can have any name but must have numeric value.

Triggers

The trigger always waiting to know which state that the device should be, whether active or inactive. Therefore, there are two URL's, using the beginning: /trigger/, that can be called under certain conditions.

Thinking about the following scenario: I have a presence sensor, and was shot by the sensor that there is some movement in the room which is monitored. Can activate / enable the trigger, using the URL:

$ curl -X GET "http://guardiao.cl/trigger/IOTWBS0002/on/?apiKey=497aa991-d8e6-4bb6-ad17-f01a13648333"
# answer: {"status":true,"dateUpdated":"2015-05-26T11:38:41.587Z"}

Depending on the need, it is possible to activate only (there is a button on the dashboard which can inactivate). If you want to disable, as our example, I can call the following URL:

$ curl -X GET "http://guardiao.cl/trigger/IOTWBS0002/off/?apiKey=497aa991-d8e6-4bb6-ad17-f01a13648333"
# answer: {"status":false,"dateUpdated":"2015-05-26T11:50:12.249Z"}

The only parameter that changes the URL is /on/ and /off/ that is, they both follow the same model.

Actuators

The actuators are device that only orders the state it should be. Ie through the URL: /actuator/ You will be asked whether it should be active or inactive.

To control the device, you can activate / inactivate the device by Dashboard or by API Service.

$ curl -X GET "http://guardiao.cl/actuator/IOTWBS0003/?apiKey=497aa991-d8e6-4bb6-ad17-f01a13648333"

If the device is inactive, the return will be given as JSON example:

{"state":false}

If the device is inactive, the return will be given as JSON example:

{"state":true}

A good tip to try is through the active dashboard and disable the device and call the URL as example, and see the return.