HTTP is a general-purpose network protocol that can be used in IoT applications. You can find more information about HTTP here. HTTP protocol is TCP based and uses request-response model.
ThingsBoard server nodes act as an HTTP Server that supports both HTTP and HTTPS protocols.
You can find HTTP client libraries for different programming languages on the web. Examples in this article will be based on curl. In order to setup this tool, you can use instructions in our Hello World guide.
We will use access token device credentials in this article and they will be referred to later as $ACCESS_TOKEN. The application needs to include $ACCESS_TOKEN as a path parameter in each HTTP request. Possible error codes and their reasons:
By default, ThingsBoard supports key-value content in JSON. Key is always a string, while value can be either string, boolean, double, long or JSON. Using custom binary format or some serialization framework is also possible. See protocol customization for more details. For example:
{
"stringKey":"value1",
"booleanKey":true,
"doubleKey":42.0,
"longKey":73,
"jsonKey": {
"someNumber": 42,
"someArray": [1,2,3],
"someNestedObject": {"key": "value"}
}
}
In order to publish telemetry data to ThingsBoard server node, send POST request to the following URL:
http(s)://host:port/api/v1/$ACCESS_TOKEN/telemetry
The simplest supported data formats are:
{"key1":"value1", "key2":"value2"}
or
[{"key1":"value1"}, {"key2":"value2"}]
Please note that in this case, the server-side timestamp will be assigned to uploaded data!
In case your device is able to get the client-side timestamp, you can use following format:
{"ts":1451649600512, "values":{"key1":"value1", "key2":"value2"}}
In the example above, we assume that “1451649600512” is a unix timestamp with milliseconds precision. For example, the value ‘1451649600512’ corresponds to ‘Fri, 01 Jan 2016 12:00:00.512 GMT’
resources/http-telemetry.sh |
---|
|
resources/telemetry-data-as-object.json |
---|
|
resources/telemetry-data-as-array.json |
---|
|
resources/telemetry-data-with-ts.json |
---|
|
ThingsBoard attributes API allows devices to
In order to publish client-side device attributes to ThingsBoard server node, send POST request to the following URL:
http(s)://host:port/api/v1/$ACCESS_TOKEN/attributes
resources/http-attributes-publish.sh |
---|
|
resources/new-attributes-values.json |
---|
|
In order to request client-side or shared device attributes to ThingsBoard server node, send GET request to the following URL:
http(s)://host:port/api/v1/$ACCESS_TOKEN/attributes?clientKeys=attribute1,attribute2&sharedKeys=shared1,shared2
resources/http-attributes-request.sh |
---|
|
resources/attributes-response.json |
---|
|
Please note, the intersection of client-side and shared device attribute keys is a bad practice! However, it is still possible to have same keys for client, shared or even server-side attributes.
In order to subscribe to shared device attribute changes, send GET request with optional “timeout” request parameter to the following URL:
http(s)://host:port/api/v1/$ACCESS_TOKEN/attributes/updates
Once shared attribute will be changed by one of the server-side components (REST API or Rule Chain) the client will receive the following update:
resources/http-attributes-subscribe.sh |
---|
|
resources/attributes-response.json |
---|
|
In order to subscribe to RPC commands from the server, send GET request with optional “timeout” request parameter to the following URL:
http(s)://host:port/api/v1/$ACCESS_TOKEN/rpc
Once subscribed, a client may receive rpc request or a timeout message if there are no requests to a particular device. An example of RPC request body is shown below:
{
"id": "1",
"method": "setGpio",
"params": {
"pin": "23",
"value": 1
}
}
where
and can reply to them using POST request to the following URL:
http://host:port/api/v1/$ACCESS_TOKEN/rpc/{$id}
where $id is an integer request identifier.
resources/http-rpc-subscribe.sh |
---|
|
resources/http-rpc-reply.sh |
---|
|
resources/rpc-response.json |
---|
|
In order to send RPC commands to the server, send POST request to the following URL:
http://host:port/api/v1/$ACCESS_TOKEN/rpc
Both request and response body should be valid JSON documents. Theh content of the documents is specific to the rule node that will handle your request.
resources/http-rpc-from-client.sh |
---|
|
resources/rpc-client-request.json |
---|
|
resources/rpc-server-response.json |
---|
|
Please see the corresponding article to get more information about the Claiming devices feature.
In order to initiate claiming device, send POST request to the following URL:
http(s)://host:port/api/v1/$ACCESS_TOKEN/claim
The supported data format is:
{"secretKey":"value", "durationMs":60000}
Please note that the above fields are optional. In case the secretKey is not specified, the empty string as a default value is used. In case the durationMs is not specified, the system parameter device.claim.duration is used (in the file /etc/thingsboard/conf/thingsboard.yml).
HTTP transport can be fully customized for specific use-case by changing the corresponding module.
Getting started guides - These guides provide quick overview of main ThingsBoard features. Designed to be completed in 15-30 minutes.
Installation guides - Learn how to setup ThingsBoard on various available operating systems.
Data visualization - These guides contain instructions how to configure complex ThingsBoard dashboards.
Data processing & actions - Learn how to use ThingsBoard Rule Engine.
IoT Data analytics - Learn how to use rule engine to perform basic analytics tasks.
Hardware samples - Learn how to connect various hardware platforms to ThingsBoard.
Advanced features - Learn about advanced ThingsBoard features.
Contribution and Development - Learn about contribution and development in ThingsBoard.