Rule Engine

The rule engine is a simple framework for building event-based workflows. You can define event-based workflows without coding hours by dragging and dropping pre-programming graphics nodes.

The Rules Engine consists of three main components:

• Input message from telemetry data, attributes, or RPC Request
• Rule nodes with different functions
• Rule chains to form a connection between nodes

There are 5 types of categories based on the function of the rule nodes in the rules engine:

•  Filter

• Enrichment

• Transformation

• Action

• Externals

Filter nodes are used for message filtering based on specific conditions and send different results to different paths.

You can find a list of available filter nodes below.

• Check alarm status
• Check existence fields
• Check relation
• GPS geofencing filter
• Message type
• Message type switch
• Originator type
• Originator type switch
• Script
• Switch

Enrichment nodes are used to add metadata. The purpose of adding metadata is to identify the incoming message better.

The types of metadata that can be added to the input message using Enrichment nodes are below.

• Calculate delta
• Customer attributes
• Customer details
• Entity group attributes
• Entity group attributes by name
• Originator attributes
• Originator fields
• Originator telemetry
• Related attributes
• Related device attributes
• Tenant attributes
• Tenant details

Transformation Nodes are used for changing incoming message content or metadata.

The changes you can make to the input message using the transformation nodes are listed below.

• Change originator
• Duplicate message to entity group entities
• Duplicate to group by group name
• Script
• To email

Action nodes are used to execute various actions based on the incoming message.

Messages can enable the following operations with action nodes.

• Change owner
• Clear alarm
• Copy to view
• Create alarm
• Create relation
• Delay
• Delete relation
• Device profile
• Generator
• GPS geofencing events
• Log
• Message count
• Push to edge
• Remove from group
• RPC call reply
• RPC call request
• Save attributes
• Save timeseries
• Save to custom table
• Synchronization end
• Synchronization start

Analytics nodes are used to calculate and analyze data. They can perform calculations and data analysis in the following ways.

• Aggregate stream
• Alarms count
• Alarms count (deprecated)

Thingspod has provided the possibility to send rule engine information to external systems such as Kafka or other standard systems through REST API. Just select your external service and connect it to the message by drawing a line.

The types of external services to which you can directly send the information processed by the Platform include the following:

• Aws ans
• Aws sqs
• Azure iot hub
• Gcp pubsub
• Kaka
• Mqtt
• Rabbitmq
• Rest api call
• Send email
• Send sms

If data needs a heavy and long workflow for processing, you don't need to define the entire processing framework in a rule chain; You can define each part of the processing in a separate rule chain and connect them using the Rule Chain node to create a connection between the rule engines.

The Thingspod Rule Engine is a customizable framework for complex event processing. Here are some common use cases that can be configured via the Thingspod rule chains:

• Validation and correction of telemetry data or attributes before saving to the database.
• copy telemetry data or attributes from devices to related assets; For example, data from multiple devices can be aggregated into a related asset.
• Create, update, and delete alarms based on defined conditions.
• trigger actions based on device lifecycle events; For example, creating an alarm when the device is online or offline.
• Load additional data required for processing; For example, the temperature threshold value for a device defined in the tenant attribute or device's customer.
• Send REST API calls to external systems.
• Send email when complex events occur and use attributes of other entities in the email template.
• Apply user preferences during event processing.
• RPC calls based on defined conditions.
• Integration with Kafka, Spark, AWS services.

Let's assume your device uses a DHT22 sensor to collect temperature data and send it to the Thingspod. This sensor can measure temperatures from -40°C to +80°C.

In this tutorial, we will configure the Thingspod rule engine to store all temperatures in the range of -40°C to +80°C in the telemetry and log invalid temperatures in the system log.

Go to the Rule Chains section in the Thingspod user interface and open the Root Rule Chain.

Drag and drop the Script Filter rule node to the chain. The node configuration window will open.

We will use this script to check the validation of the data:

Copyreturn typeof msg.temperature === 'undefined'        
|| (msg.temperature >= -40 && msg.temperature <= 80);

The script returns True if the temperature is undefined or the temperature is valid, and False otherwise. If the script returns True, the input message is sent to subsequent nodes connected by the True relation.

Now, we want all telemetry requests to pass the validation script. We need to delete the Post Telemetry relation between the Message Type Switch node and the Save Telemetry node. Using the Post Telemetry relation, connect the Message Type Switch node to the Script Filter node.

Next, we need to connect the Script Filter node to the Save Telemetry node using the True relation. So all valid telemetry data is saved.

Also, using the False relation, we connect the Script Filter node to the Log node. So that all invalid telemetry is entered in the system log.

Press the Save button to apply the changes.

To validate the results, we need to create a device and send the telemetry data to the Thingspod. Therefore, we go to the devices section and create a new device.

We will use Rest API to send telemetry data. We need to copy the generated access token of the device (DHT22).

We send the temperature of 99 through the terminal.

Copycurl -v -X POST -d '{"temperature":99}' https://thingspod.com/api/v1/$ACCESS_TOKEN/telemetry --header "Content-Type:application/json"        

* You must replace ACCESS_TOKEN$ with the actual device access token.

You can see that the telemetry data is not added in the Latest Telemetry section of the device.

Now we send a message with a temperature of 24.

Copycurl -v -X POST -d '{"temperature":24}' https://thingspod.com/api/v1/$ACCESS_TOKEN/telemetry --header "Content-Type:application/json"        

We will see that the telemetry data has been saved successfully.