Star

ThingsBoard Documentation

Documentation for using ThingsBoard IoT Platform.

Action Nodes

Action Nodes execute various actions based on incoming Message.

Create Alarm Node

image

This Node tries to load latest Alarm with configured Alarm Type for Message Originator. If Uncleared Alarm exist, then this Alarm will be updated, otherwise a new Alarm will be created.

Node Configuration:

Alarm Details Builder script used for generating Alarm Details JsonNode. It is useful for storing additional parameters inside Alarm. For example you can save attribute name/value pair from Original Message payload or Metadata.

Alarm Details Builder script should return details object.

image

Optional: previous Alarm Details can be accessed via metadata.prevAlarmDetails. If previous Alarm does not exist, this field will not be present in Metadata. Note that metadata.prevAlarmDetails is a raw String field and it needs to be converted into object using this construction:

var details = {};
if (metadata.prevAlarmDetails) {
    details = JSON.parse(metadata.prevAlarmDetails);
}

Alarm Details Builder script function can be verified using Test JavaScript function.

Example of Details Builder Function

This function takes count property from previous Alarm and increment it. Also put temperature attribute from inbound Message payload into Alarm details.

var details = {temperature: msg.temperature, count: 1};

if (metadata.prevAlarmDetails) {
    var prevDetails = JSON.parse(metadata.prevAlarmDetails);
    if(prevDetails.count) {
        details.count = prevDetails.count + 1;
    }
}

return details;

Alarm created/updated with those properties:

Outbound message will have the following structure:

After new Alarm created, Outbound message will contain additional property inside Metadata - isNewAlarm with true value. Message will be passed via Created chain.

After existing Alarm updated, Outbound message will contain additional property inside Metadata - isExistingAlarm with true value. Message will be passed via Updated chain.

Here is an example of Outbound Message payload

{
  "tenantId": {
    "entityType": "TENANT",
    "id": "22cd8888-5dac-11e8-bbab-ad47060c9bbb"
  },
  "type": "High Temperature Alarm",
  "originator": {
    "entityType": "DEVICE",
    "id": "11cd8777-5dac-11e8-bbab-ad55560c9ccc"
  },
  "severity": "CRITICAL",
  "status": "ACTIVE_UNACK",
  "startTs": 1526985698000,
  "endTs": 1526985698000,
  "ackTs": 0,
  "clearTs": 0,
  "details": {
    "temperature": 70,
    "ts": 1526985696000
  },
  "propagate": true,
  "id": "33cd8999-5dac-11e8-bbab-ad47060c9431",
  "createdTime": 1526985698000,
  "name": "High Temperature Alarm"
}

More details about Alarms in the Thingsboard can be found in this tutorial

You can see the real life example, where this node is used, in the next tutorial:


Clear Alarm Node

image

This Node loads the latest Alarm with configured Alarm Type for Message Originator and Clear the Alarm if it exist.

Node Configuration:

Alarm Details Builder script used for updating Alarm Details JsonNode. It is useful for storing additional parameters inside Alarm. For example you can save attribute name/value pair from Original Message payload or Metadata.

Alarm Details Builder script should return details object.

image

Note that metadata.prevAlarmDetails is a raw String field and it needs to be converted into object using this construction:

var details = {};
if (metadata.prevAlarmDetails) {
    details = JSON.parse(metadata.prevAlarmDetails);
}

Alarm Details Builder script function can be verified using Test JavaScript function.

Example of Details Builder Function

This function takes count property from previous Alarm and increment it. Also put temperature attribute from inbound Message payload into Alarm details.

var details = {temperature: msg.temperature, count: 1};

if (metadata.prevAlarmDetails) {
    var prevDetails = JSON.parse(metadata.prevAlarmDetails);
    if(prevDetails.count) {
        details.count = prevDetails.count + 1;
    }
}

return details;

This Node updates Current Alarm:

In case when Alarm does not exist or it is already Cleared Alarm, original Message will be passed to the next nodes via False chain.

Otherwise new Message will be passed via Cleared chain.

Outbound message will have the following structure:

Here is an example of Outbound Message payload

{
  "tenantId": {
    "entityType": "TENANT",
    "id": "22cd8888-5dac-11e8-bbab-ad47060c9bbb"
  },
  "type": "High Temperature Alarm",
  "originator": {
    "entityType": "DEVICE",
    "id": "11cd8777-5dac-11e8-bbab-ad55560c9ccc"
  },
  "severity": "CRITICAL",
  "status": "CLEARED_UNACK",
  "startTs": 1526985698000,
  "endTs": 1526985698000,
  "ackTs": 0,
  "clearTs": 1526985712000,
  "details": {
    "temperature": 70,
    "ts": 1526985696000
  },
  "propagate": true,
  "id": "33cd8999-5dac-11e8-bbab-ad47060c9431",
  "createdTime": 1526985698000,
  "name": "High Temperature Alarm"
}

More details about Alarms in the Thingsboard can be found in this tutorial

You can see the real life example, where this node is used, in the next tutorial:


Delay Node

image

Delays incoming messages for configurable period.

Configuration:

image

When delay period for particular incoming message will be reached it will be removed from pending queue and routed to the next nodes via Success chain.

Each next message will be routed via Failure chain if the maximum pending messages limit will be reached.


Generator Node

image

Generates Messages with configurable period. JavaScript function is used for message generation.

Node Configuration:

JavaScript function receive 3 input parameters:

Script should return the following structure:

{   
    msg: new payload,
    metadata: new metadata,
    msgType: new msgType 
}

image

All fields in resulting object are optional and will be taken from previously generated Message if not specified.

Outbound Message from this Node will be new Message that was constructed using configured JavaScript function.

JavaScript generator function can be verified using Test JavaScript function.

This node can be used for Rule Chain debugging purposes.


Log Node

image

Transform incoming Message with configured JavaScript function to String and log final value into the Thingsboard log file.

INFO log level is used for logging.

JavaScript function receive 3 input parameters

Script should return String value.

image

JavaScript transform function can be verified using Test JavaScript function.

You can see the real life example, where this node is used, in the next tutorial:

RPC Call Reply Node

image

Sends response to the RPC Call originator. All incoming RPC requests are passed through Rule Chain as Messages. Also all RPC requests have request ID field. It is used for mapping requests and responses. Message Originator must be a Device entity because RPC response is initiated to the Message Originator.

Node configuration has special request ID field mapping. If the mapping is not specified, requestId metadata field is used by default.

image

RPC request can be received via different transports:

Message payload example:

{
  "method": "setGpio",
  "params": {
    "pin": "23",
    "value": 1
  }
}

Message will be routed via Failure chain in the following cases:

For more details how RPC works in the Thingsboard, please read RPC capabilities Article.

You can see the real life example, where this node is used, in the next tutorial:

RPC Call Request Node

image

Sends RPC requests to the Device and routing response to the next Rule nodes. Message Originator must be a Device entity as RPC request can be initiated only to device.

Node configuration has Timeout field used to specify timeout waiting for response from device.

image

Message payload must have correct format for RPC request. It must contains method and params fields. Example:

{
  "method": "setGpio",
  "params": {
    "pin": "23",
    "value": 1
  }
}

If Message Payload contains requestId field, its value used to identify RPC request to the Device. Otherwise random requestId will be generated.

Outbound Message will have same originator and metadata as in inbound Message. Response from the Device will be added into Message payload.

Message will be routed via Failure chain in the following cases:

Otherwise Message will be routed via Success chain.

For more details how RPC works in the Thingsboard, please read RPC capabilities article.


Save Attributes Node

image

Stores attributes from incoming Message payload to the database and associate them to the Entity, that is identified by the Message Originator. Configured scope is used to identify attributes scope.

Supported scope types:

image

Expects messages with POST_ATTRIBUTES_REQUEST message type. If message Type is not POST_ATTRIBUTES_REQUEST, Message will be routed via Failure chain.

When attributes are uploaded over existing API (HTTP / MQTT / CoAP / etc.) Message with correct payload and type will be passed into Input node of the Root Rule Chain.

In cases when it is required to trigger attributes saving inside Rule Chain, the Rule Chain should be configured to transform Message payload to the expected format and set message type to POST_ATTRIBUTES_REQUEST. It could be done using Script Transformation Node.

Expected Message Payload example:

{
  "firmware_version": "1.0.1",
  "serial_number": "SN-001"
}

After successful attributes saving, original Message will be passed to the next nodes via Success chain, otherwise Failure chain is used.


Save Timeseries Node

image

Stores Timeseries data from incoming Message payload to the database and associate them to the Entity, that is identified by the Message Originator. Configured TTL seconds is used for timeseries data expiration. 0 value means that data will never expire.

image

Expects messages with POST_TELEMETRY_REQUEST message type. If message Type is not POST_TELEMETRY_REQUEST, Message will be routed via Failure chain.

When timeseries data is published over existing API (HTTP / MQTT / CoAP / etc.) Message with correct payload and type will be passed into Input node of the Root Rule Chain.

In cases when it is required to trigger timeseries data saving inside Rule Chain, the Rule Chain should be configured to transform Message payload
to the expected format and set message type to POST_TELEMETRY_REQUEST. It could be done using Script Transformation Node.

Message Metadata must contain ts field. This field identifies timestamp in milliseconds of published telemetry.

Also, if Message Metadata contains TTL field, its value is used for timeseries data expiration, otherwise TTL from Node Configuration is used.

Expected Message Payload example:

{  
  "values": {
    "key1": "value1",
    "key2": "value2"
  }
}

After successful timeseries data saving, original Message will be passed to the next nodes via Success chain, otherwise Failure chain is used.


Assign To Customer Node

image

Assign Message Originator Entity to Customer.

Following Message Originator types are allowed: Asset, Device, Entity View, Dashboard.

Finds target Customer by customer name pattern and then assign Originator Entity to this customer.

Will create new Customer if it doesn’t exists and Create new Customer if not exists is set to true.

Configuration:

image

Message will be routed via Failure chain in the following cases:

In other cases Message will be routed via Success chain.


Unassign From Customer Node

image

Unassign Message Originator Entity from Customer.

Following Message Originator types are allowed: Asset, Device, Entity View, Dashboard.

Finds target Customer by customer name pattern and then unassign Originator Entity from this customer.

Configuration:

image

Message will be routed via Failure chain in the following cases:

In other cases Message will be routed via Success chain.