Filter Nodes

Filter Nodes are used for Message filtering and routing.

• Check Relation Filter Node
• Check Existence Fields Node
• Message Type Filter Node
• Message Type Switch Node
• Originator Type Filter Node
• Originator Type Switch Node
• Script Filter Node
• Switch Node
• GPS Geofencing Filter Node
  • Fetch perimeter information from message metadata
  • Fetch perimeter information from node configuration

Check Relation Filter Node

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

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:

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

Check Existence Fields Node

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

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

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.

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

Message Type Switch Node

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

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

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

Originator Type Switch Node

Routes incoming messages by Originator Entity type.

Script Filter Node

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.

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:

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:

• Create and Clear Alarms
• Reply to RPC Calls

Switch Node

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.

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:

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.

GPS Geofencing Filter Node

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).

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:

[[lat1,lon1],[lat2,lon2], ... ,[latN,lonN]]

• Circle

"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

• Circle

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;