Filter Nodes

On this page

Filter Nodes

Filter Nodes are used for Message filtering and routing.

Check Relation Filter Node
Since TB Version 2.0.1

image

Checks the relation from the selected entity to originator of the message by type and direction.

image

If relation exists - Message is sent via True chain, otherwise False chain is used.

Note: Since TB Version 2.3 the rule node has the ability to check the existence of relation to a specific entity or
to any entity based on direction and relation type by disabling the following checkbox in the rule node configuration:

image

In case that checkbox disabled and any relation exists - Message is sent via True chain, otherwise False chain is used.

Check Existence Fields Node
Since TB Version 2.3

image

Rule node checks the existence of the selected keys from incoming message data and metadata.

image

If selected checkbox Check that all selected keys are present and all keys in message data and metadata exists - send Message via True chain, otherwise, False chain is used.
In case that checkbox is not selected, and at least one of the keys from data or metadata of the message exists - send Message via True chain, otherwise, False chain is used.

Message Type Filter Node
Since TB Version 2.0

image

In the Node configuration, administrator defines set of allowed Message Types for incoming Message. There are predefined Message Types in the system, like Post attributes, Post telemetry, RPC Request, etc. An administrator can also define any Custom Message Types in the node configuration.

image

If incoming Message Type is expected - Message is sent via True chain, otherwise False chain is used.

Message Type Switch Node
Since TB Version 2.0

image

Route incoming messages by Message Type. If incoming Message has known Message Type then it is sent to the corresponding chain, otherwise, message is sent to Other chain.

If you use Custom Message Types than you can route those messages via Other chain of Message Type Switch Node to the Switch Node or Message Type Filter Node configured with required routing logic.

Originator Type Filter Node
Since TB Version 2.1

image

In the Node configuration, administrator defines set of allowed Originator Entity types for incoming Message.

image

If incoming Originator Type is expected - Message is sent via True chain, otherwise False chain is used.

Originator Type Switch Node
Since TB Version 2.0

image

Routes incoming messages by Originator Entity type.

Script Filter Node
Since TB Version 2.0

image

Evaluates incoming Message with configured JavaScript condition.

JavaScript function receive 3 input parameters:

  • msg - is a Message payload.
  • metadata - is a Message metadata.
  • msgType - is a Message type.

Script should return Boolean value. If True - send Message via True chain, otherwise False chain is used.

image

Message payload can be accessed via msg variable. For example msg.temperature < 10;
Message metadata can be accessed via metadata variable. For example metadata.customerName === 'John';
Message type can be accessed via msgType variable. For example msgType === 'POST_TELEMETRY_REQUEST'

Full script example:

1
2
3
4
5
6
7
8
9
if(msgType === 'POST_TELEMETRY_REQUEST') {
    if(metadata.deviceType === 'vehicle') {
        return msg.humidity > 50;
    } else if(metadata.deviceType === 'controller') {
        return msg.temperature > 20 && msg.humidity > 60;
    }
}

return false;

JavaScript condition can be verified using Test JavaScript function.

You can see the real life examples, where this node is used, in the next tutorials:

Switch Node
Since TB Version 2.0

image

Routes incoming Message to one OR multiple output chains. Node executes configured JavaScript function.

JavaScript function receive 3 input parameters:

  • msg - is a Message payload.
  • metadata - is a Message metadata.
  • msgType - is a Message type.

The script should return an array of next Relation names where Message should be routed. If returned array is empty - message will not be routed to any Node and discarded.

image

Message payload can be accessed via msg variable. For example msg.temperature < 10;
Message metadata can be accessed via metadata variable. For example metadata.customerName === 'John';
Message type can be accessed via msgType variable. For example msgType === 'POST_TELEMETRY_REQUEST'

Full script example:

1
2
3
4
5
6
7
8
9
10
11
12
13
14
15
16
if (msgType === 'POST_TELEMETRY_REQUEST') {
    if (msg.temperature < 18) {
        return ['Low Temperature Telemetry'];
    } else {
        return ['Normal Temperature Telemetry'];
    }
} else if (msgType === 'POST_ATTRIBUTES_REQUEST') {
    if (msg.currentState === 'IDLE') {
        return ['Idle State', 'Update State Attribute'];
    } else if (msg.currentState === 'RUNNING') {
        return ['Running State', 'Update State Attribute'];
    } else {
        return ['Unknown State'];
    }
}
return [];

JavaScript switch function can be verified using Test JavaScript function.

In order to specify custom relation name Custom type should be selected. This will allow to input custom relation name. Custom relation names are case-insensitive.

image

GPS Geofencing Filter Node
Since TB Version 2.3.1

image

Filters incoming messages by GPS based parameters. Extracts latitude and longitude from data or metadata and checks if they are inside configured perimeter (geo fence).

image

The rule node fetches perimeter information from message metadata by default. If Fetch perimeter information from message metadata is unchecked, additional information should be configured.


Fetch perimeter information from message metadata

There are two options of area definition based on the perimeter type:

  • Polygon

    Metadata of the incoming message must include key with name perimeter and following data structure:

1
[[lat1,lon1],[lat2,lon2], ... ,[latN,lonN]]
  • Circle
1
2
3
4
5
"centerLatitude": "value1", "centerLongitude": "value2", "range": "value3"

All values for these keys are in double-precision floating-point data type.

The "rangeUnit" key requires specific value from a list of METER, KILOMETER, FOOT, MILE, NAUTICAL_MILE (capital letters obligatory).
Fetch perimeter information from node configuration

There are two options of area definition based on the perimeter type:

  • Polygon

image

  • Circle

image

if configured latitude and longitude are inside configured perimeter message sent via True chain, otherwise False chain is used.

Failure chain will to be used when:

  • incoming message has no configured latitude or longitude key in data or metadata.
  • missing perimeter definition;