RuleNodes

RuleNodes are the functional building blocks of a RuleChain in optiCLOUD. They determine how incoming messages are filtered, enriched, transformed, stored, or forwarded to other systems.

This page provides a practical overview of the available nodes and their areas of use:

Which nodes are available?
What are they used for?
Which outputs or relations do they provide?

Overview by Category

Filter Nodes

RuleNode	Purpose
Message Type Filter	Only allows specific message types to pass
Message Type Switch	Routes messages to different paths depending on message type
File Type Switch	Branches file messages by file type
File Names Filter	Filters file names by prefixes
Device Filter	Restricts processing to selected devices
Script (Filter)	Executes custom filter logic with JavaScript
Switch	Routes messages to dynamic outputs using a script
Check Existence Fields	Checks whether fields exist in the message or metadata
GPS Geofencing Filter	Only allows messages inside a geofence to pass

Action Nodes

RuleNode	Purpose
Save Timeseries	Stores telemetry as time series
Save Attributes	Stores attributes in a selected scope
Save Alarms	Stores alarm states from alarm messages
Create Alarm	Creates or updates an alarm
Clear Alarm	Clears an existing alarm
Alarm Counter	Counts alarms within a time window
Log	Writes debug or log output
Generator	Generates periodic messages
Message Count	Counts incoming messages and publishes the counter
Delay	Delays forwarding of a message
Aggregate OSF File	Reads OSF files and creates telemetry from them
Aggregate JSONL File	Reads JSONL files and creates telemetry from them
Process Raw Data File	Processes file operations in blob storage
Generate Report	Creates reports for a defined time period
Device System	Aggregates data across multiple devices
GPS Geofencing Events	Creates events when entering or leaving a geofence
RPC Call Request	Sends an RPC call to a device
RPC Call Reply	Replies to an incoming RPC call

Enrichment Nodes

RuleNode	Purpose
Originator Attributes	Loads attributes of the originator into metadata
Originator Telemetry	Loads telemetry of the originator into metadata
Originator Fields	Adds master data of the originator
Tenant Details	Adds tenant information

Transformation Nodes

RuleNode	Purpose
Script (Transform)	Changes the message, metadata, or message type using JavaScript
To Email	Builds an email object from a message

External Nodes

RuleNode	Purpose
REST API Call	Sends data to an external REST interface
MQTT	Publishes messages to an MQTT broker
Kafka	Publishes messages to a Kafka topic
RabbitMQ	Sends messages to RabbitMQ
AWS SQS	Sends messages to an SQS queue
AWS SNS	Publishes messages to an SNS topic
GCP Pub/Sub	Publishes messages to Google Pub/Sub
Send Email	Sends an email via SMTP

Scheduler Nodes

RuleNode	Purpose
Create Scheduled Task	Schedules a delayed one-time execution
Clear Scheduled Task	Deletes a previously scheduled task

Event and Alarm Nodes

RuleNode	Purpose
Complex Alarm	Creates alarms based on complex real-time patterns
Complex Event Processing	Evaluates file data using event rules
Enrich Alarm	Adds extra information to existing alarms

Detailed Overview

Filter Nodes

Message Type Filter

Category: Filter
Outputs: True, False

The node checks whether the message type of the incoming message is included in a configured list. If it matches, the message continues through True; otherwise through False.

Configuration

Label	Required	Description
Message Types Filter	Yes	List of allowed message types. At least one type must be entered.

Supported values include POST_ATTRIBUTES_REQUEST, POST_TELEMETRY_REQUEST, TO_SERVER_RPC_REQUEST, TO_DEVICE_RPC_REQUEST, ACTIVITY_EVENT, INACTIVITY_EVENT, CONNECT_EVENT, DISCONNECT_EVENT, BLOB_STORE_REQUEST, and POST_ALARMS.

Example

Use this node when only telemetry data should be processed further. In that case, configure POST_TELEMETRY_REQUEST and connect the True output to the next node. That downstream node will then only receive messages of type POST_TELEMETRY_REQUEST.

Message Type Switch

Category: Filter
Outputs: one per message type plus Other

The node distributes messages based on their message type to fixed outputs. It is useful as an early dispatcher in a RuleChain when different message types should be handled in separate branches.

Configuration

This node has no configurable options. The outputs are fixed.

Output	Condition
`POST_ATTRIBUTES`	Message type is `POST_ATTRIBUTES_REQUEST`
`POST_TELEMETRY`	Message type is `POST_TELEMETRY_REQUEST`
`POST_ALARMS`	Message type is `POST_ALARMS`
`BLOB_STORE_REQUEST`	Message type is `BLOB_STORE_REQUEST`
`RPC_REQUEST_FROM_DEVICE`	Message type is `TO_SERVER_RPC_REQUEST`
`RPC_REQUEST_TO_DEVICE`	Message type is `TO_DEVICE_RPC_REQUEST`
`ACTIVITY_EVENT`	Message type is `ACTIVITY_EVENT`
`INACTIVITY_EVENT`	Message type is `INACTIVITY_EVENT`
`CONNECT_EVENT`	Message type is `CONNECT_EVENT`
`DISCONNECT_EVENT`	Message type is `DISCONNECT_EVENT`
`Other`	All other message types

Example

In a root RuleChain, this node can be placed directly after the input to split telemetry, attributes, alarms, RPC messages, and file operations into separate processing branches.

File Type Switch

Category: Filter
Outputs: OSF, JSONL, Other

The node branches file messages based on the file extension. It is used in file pipelines after a file operation has been identified as BLOB_STORE_REQUEST.

Configuration

This node has no configurable options. Detection is based on the file extension in the metadata.

Output	Detected file extensions
`OSF`	`.osf`, `.osfz`
`JSONL`	`.log`, `.log.gz`
`Other`	All other file extensions

Example

Route .osf files to Aggregate OSF File.

File Names Filter

Category: Filter
Outputs: True, False

The node only forwards file messages through True if the file name starts with one of the configured prefixes.

Configuration

Label	Required	Description
File Prefixes	Yes	List of file name prefixes. The check is case-sensitive.

Notes

An empty prefix list causes all messages to go through False.
The file name is read from the message metadata, usually from fileName.

Example

If a device uploads files with data_ and config_, two File Names Filter nodes can be used to process both groups separately.

Device Filter

Category: Filter
Outputs: True, False

The node restricts processing to selected devices. Depending on the setting, the device list can be used as an allowlist or blocklist.

Configuration

Label	Required	Description
Devices	Yes	Device selection via multi-select.
Allow selected devices	Yes	Enabled: only selected devices go through `True`. Disabled: selected devices are blocked.

Outputs

Output	Condition
`True`	Device is allowed or not blocked
`False`	Device is not allowed or explicitly blocked

Example

If a rule should only run for specific devices, the Device Filter can be placed before it and only pass the selected devices to the next node.

Script (Filter)

Category: Filter
Outputs: True, False

The node executes a JavaScript function. If the script returns true, the message continues through True. If it returns false or the script fails, the message continues through False.

Configuration

Label	Required	Description
Filter Function	Yes	JavaScript function with the signature `Filter(msg, metadata, msgType)`.

Script Context

Variable	Description
`msg`	JSON message body
`metadata`	Message metadata
`msgType`	Message type

Example

var threshold = parseFloat(metadata.tempThreshold) || 50;
return msg.temperature > threshold;

Switch

Category: Filter
Outputs: dynamic via script

The node forwards a message to one or more named outputs. The output names are returned by a JavaScript function as an array.

Configuration

Label	Required	Description
Switch Function	Yes	JavaScript function with the signature `Switch(msg, metadata, msgType)`.

The script must return an array of strings. Each string corresponds to an output name.

Notes

Output names without a connection are ignored.
An empty array discards the message.
Matching connections should be created in the RuleChain for all possible return values.

Example

The following function checks the temperature value of a message and routes the message differently depending on the value.

The highTemp relation could be connected to an alarm node that creates a High Temperature alarm.
The lowTemp relation could be connected to an alarm node that creates a Low Temperature alarm.
The normalTemp relation could be connected to nodes that set an attribute such as TempStatus = OK.

function nextRelation(msg) {
    if(msg.temperature > 50){
      return ['highTemp'];
    } else if (msg.temperature < 20){
      return ['lowTemp'];
    } else {
      return ['normalTemp'];
    }
    
}
return nextRelation(msg);

Check Existence Fields

Category: Filter
Outputs: True, False

The node checks whether specific fields are present in the message body and/or metadata. This protects downstream nodes from incomplete messages.

Configuration

Label	Required	Description
Message Data	No	Field names that must exist in the message body.
Message Metadata	No	Field names that must exist in the metadata.
Check All Keys Present	Yes	Enabled: all listed fields must exist. Disabled: at least one field must exist.

At least one of the two fields messageNames or metadataNames must contain entries.

Example

Before a Script node, you can check whether all channels used in the script are actually present in the message. This prevents the script from failing and reduces script complexity, because you do not need additional if/else checks for missing channels.

GPS Geofencing Filter

Category: Filter
Outputs: True, False

The node checks whether GPS coordinates are inside a defined geofence. The check is stateless and evaluates only the current message.

Configuration

Label	Required	Description
Latitude Key Name	Yes	Field name for the latitude in the message body.
Longitude Key Name	Yes	Field name for the longitude in the message body.
Fetch Perimeter Info from Metadata	Yes	Enabled: the geofence definition is read from metadata. Disabled: the geofence is configured statically in the node.
Perimeter Type	Yes, for static configuration	`Circle` or `Polygon`.
Circle fields	Yes, for circle	Center point, radius, and unit of the circle.
Polygon Definition	Yes, for polygon	GeoJSON or WKT definition of the polygon.

Note

GPS Geofencing Events is used for stateful enter/leave events.

Example

Only process telemetry when a vehicle is within a defined zone. Otherwise, the telemetry is discarded.

Action Nodes

Save Timeseries

Category: Action
Outputs: Success, Failure

The node stores telemetry data from the message body as time series values in the database.

Configuration

Label	Required	Description
Default TTL	Yes	Lifetime of stored data points in seconds. `0` means no automatic deletion.
Enable Type Cast	Yes	Converts numeric or boolean string values to native data types.

Input

The message type must be POST_TELEMETRY_REQUEST. The message body must be a JSON object or an array of JSON objects containing a ts timestamp.

Save Attributes

Category: Action
Outputs: Success, Failure

The node stores key-value pairs from the message body as attributes of the originator entity.

Configuration

Label	Required	Description
Attribute Scope	Yes	Target scope for the attributes.
Enable Type Cast	Yes	Converts numeric or boolean string values to native data types.

Scope	Meaning
`CLIENT_SCOPE`	Attributes reported by the device and visible to the device.
`SHARED_SCOPE`	Server-side attributes that can be distributed to the device.
`SERVER_SCOPE`	Internal server attributes that are not sent to the device.

Input

The message body must be a JSON object. Each key is stored as an attribute name.

Save Alarms

Category: Action
Outputs: Activated, Deactivated, Sustained

The node processes messages of type POST_ALARMS and stores alarm states in the database. It maps alarm state transitions.

Outputs

Output	Meaning
`Activated`	A new alarm was opened or a cleared alarm became active again.
`Deactivated`	An active alarm was cleared.
`Sustained`	An already active alarm remains active.

Configuration

Label	Required	Description
Propagate	Yes	Specifies whether alarms are propagated to parent entities.

Input

The message must be of type POST_ALARMS and contain alarm data according to the platform alarm model.

Create Alarm

Category: Action
Outputs: Created, Updated, False

The node creates an alarm for the message originator or updates an existing alarm of the same type. Alarm details are built from the message and metadata using JavaScript.

Outputs

Output	Meaning
`Created`	A new alarm was created.
`Updated`	An existing alarm of this type was updated.
`False`	The script did not produce an alarm.

Configuration

Label	Required	Description
Alarm Details Builder	Yes	JavaScript function `Details(msg, metadata, msgType)` for building alarm details.
Alarm Type	Yes	Alarm type. Supports `${metadata.key}` patterns.
Alarm Severity	Yes	Severity: `CRITICAL`, `MAJOR`, `MINOR`, `WARNING`, `INDETERMINATE`.
Propagate	Yes	Propagates the alarm to parent entities.

Metadata after Processing

The node adds values such as alarmType, alarmIsNew, alarmSeverity, and alarmId.

Example

A preceding Script Filter checks msg.temperature > 80. On True, this node creates a HighTemperature alarm with severity MAJOR. The details function can, for example, keep the highest temperature seen while the alarm remains active and gets updated.

var details = {};
if (metadata.prevAlarmDetails) {
    details = JSON.parse(metadata.prevAlarmDetails);
    if (parseFloat(details.highestTemp) < msg.temperature){
        details.highestTemp = msg.temperature;
    }
}
return details;

Clear Alarm

Category: Action
Outputs: Cleared, False

The node clears an active alarm of the configured type for the message originator.

Outputs

Output	Meaning
`Cleared`	A matching active alarm was found and cleared.
`False`	No matching active alarm was found.

Configuration

Label	Required	Description
Alarm Details Builder	Yes	JavaScript function for the final alarm details when clearing the alarm.
Alarm Type	Yes	Alarm type that must exactly match the previously created alarm.

Metadata after Processing

The node adds alarmType and alarmId.

Example

If a device reports temperature < 70 again, Clear Alarm can clear the previously created HighTemperature alarm.

info

The alarm type is case-sensitive. If a Create Alarm node created an alarm of type HighTemperature, exactly that HighTemperature alarm type must also be configured in the Clear Alarm node so it can be cleared.

Alarm Counter

Category: Action
Outputs: Success, Failure

The node counts alarms based on configured criteria within a time window and stores the results as server attributes on the message originator.

Configuration

The node contains a list of counter definitions.

Label	Required	Description
Find by Field Name	Yes	Alarm field to filter by, for example `severity` or `type`.
With Field Value	Yes	Value the field must have, for example `CRITICAL`.
Save in Server Attribute	Yes	Name of the server attribute where the counter is stored.
Time Period Alarm Considered	Yes	Time window in seconds. `0` means no time limit.

Example

With

fieldName = severity
fieldValue = CRITICAL
attributeName = criticalAlarms24h
periodInSeconds = 86400

the number of critical alarms in the last 24 hours is counted and stored in the server attribute criticalAlarms24h.

Log

Category: Action
Outputs: Success, Failure

The node writes a JavaScript-generated text to the server log and forwards the original message unchanged.

Configuration

Label	Required	Description
Log Function	Yes	JavaScript function `ToString(msg, metadata, msgType)` that returns the log text.

Notes

The node is mainly intended for development, analysis, and troubleshooting.
It should be used sparingly and ideally only after consulting OptiMEAS, because a Log node is mainly useful when troubleshooting errors that the user may not be able to resolve independently.

Generator

Category: Action
Outputs: Success, Failure

The node generates periodic messages using JavaScript and feeds them into the RuleChain. It can be used for testing, simulation, or time-based workflows.

Configuration

Label	Required	Description
Message Count	Yes	Number of messages to generate. `0` means unlimited.
Period in Seconds	Yes	Interval between generated messages in seconds.
Originator	Yes	Origin device for the generated messages.
Generator Function	Yes	JavaScript function `Generate(prevMsg, prevMetadata, prevMsgType)`.

The function must return msg, metadata, and msgType.

Example

If you want to build and test a RuleChain but currently do not have a real device available, or no device is sending live data at that moment, you can use the Generator node to create artificial messages. For realistic testing, those generated messages should mirror the expected messages of a real device as closely as possible.

The following example creates messages with:

Telemetry channels: {"temperature": 42} and {"humidity": 77}

Metadata: {"data": 40}

Type: POST_TELEMETRY_REQUEST

var msg = { temperature: 42, humidity: 77 };
var metadata = { data: 40 };
var msgType = "POST_TELEMETRY_REQUEST";

return { msg: msg, metadata: metadata, msgType: msgType };

In the example above, the generated messages are static and always contain the same values (42, 77, 40). A generator can also produce varying data, for example:

var temp = Math.floor(Math.random() * max);
var hum = Math.floor(Math.random() * max);
var meta = Math.floor(Math.random() * max);

var msg = { temperature: temp, humidity: hum };
var metadata = { data: meta };
var msgType = "POST_TELEMETRY_REQUEST";

return { msg: msg, metadata: metadata, msgType: msgType };

Note

In production environments, the interval should be chosen carefully to avoid unnecessary message load.

Message Count

Category: Action
Outputs: Success, Failure

The node counts messages within a time interval and publishes the counter as telemetry.

Configuration

Label	Required	Description
Interval in Seconds	Yes	Length of the counting window in seconds.
Output Timeseries Key Prefix	Yes	Telemetry key for the counter value.

Output

At the end of each interval, a POST_TELEMETRY_REQUEST message is generated, for example:

{
  "messageCount": 42
}

Incoming messages are also forwarded unchanged through Success.

Delay

Category: Action
Outputs: Success, Failure

The node holds messages back for a configured duration and then forwards them. The delay can be static or determined via metadata.

Configuration

Label	Required	Description
Use Metadata Period Pattern	Yes	Enables a dynamic delay via metadata.
Period in Seconds	Yes, if static	Static delay in seconds.
Period in Seconds Pattern	Yes, if dynamic	Metadata field or `${...}` expression for the delay.
Max Pending Messages	Yes	Maximum number of queued messages.

Notes

Pending messages are lost on server restart because they are not stored persistently.
If too many queued messages are reached, new messages go through Failure.

Aggregate OSF File

Category: Action
Outputs: Success, Failure

The node loads a referenced OSF file from a BLOB_STORE_REQUEST and processes it.

Input and Output

Input: BLOB_STORE_REQUEST with method GET.
The metadata must contain the reference to the stored file.
For each detected time interval, the node creates a POST_TELEMETRY_REQUEST message with the measured values.

Processing Chain

File Type Switch [OSF]
  -> Aggregate OSF File [Success]
  -> Save Timeseries

Aggregate JSONL File

Category: Action
Outputs: Success, Failure

The node loads a JSONL file from a BLOB_STORE_REQUEST and processes it.

Input and Output

Input: BLOB_STORE_REQUEST with method GET.
The file must contain valid JSONL.
Each line generates a POST_TELEMETRY_REQUEST message through Success.

Processing Chain

File Type Switch [JSONL]
  -> Aggregate JSONL File [Success]
  -> Save Timeseries

Process Raw Data File

Category: Action
Outputs: Download, Upload, Delete, Other

The node classifies BLOB_STORE_REQUEST messages by file operation and forwards them to the matching output.

Configuration

Label	Required	Description
Selected Scopes	Yes	Attribute scopes that should be processed.
Selected Methods	Yes	HTTP methods or file operations that should be forwarded.

Method	Output	Meaning
`PUT`	`Upload`	File was uploaded.
`GET`	`Download`	File should be downloaded.
`DELETE`	`Delete`	File was deleted.
other	`Other`	Unknown or unconfigured operation.

Example

Upload can be connected to File Type Switch to distinguish OSF and JSONL files further.

Generate Report

Category: Action
Outputs: Success, Failure

The node creates a report for the message originator over a configured time window.

Configuration

Section	Fields
Report type	`reportType` with values such as `DEVICE_ACTIVITY`, `TELEMETRY`, `DEVICE_STATISTIC`, `ALARM`, `OSF_DATA`, `JASPER_TEMPLATE`.
Conditional fields	`alarmSearchStatus`, `templateId`, `keys`, `sources`, depending on the report type.
Time window	`useMetadataIntervalPatterns`, `startInterval`, `startIntervalTimeUnit`, `endInterval`, `endIntervalTimeUnit`, `startIntervalPattern`, `endIntervalPattern`.

Example

For a daily telemetry export, reportType = TELEMETRY can be configured with a one-day time window and the desired telemetry keys.

Device System

Category: Action
Outputs: Success, Failure

The node processes data that belongs to a device system. Data from multiple related devices can be aggregated or correlated.

Configuration

This node has no configurable UI options. Its internal version is set by the platform.

Notes

The originator must belong to a configured device system.
The structure of the device system is loaded from the database.
The node is only relevant when the device system feature is used.

GPS Geofencing Events

Category: Action
Outputs: Entered, Left, Inside, Outside

The node tracks the geofence state per device and creates events when entering or leaving an area. Unlike GPS Geofencing Filter, this node is stateful.

Configuration

The coordinate and geofence fields are the same as in GPS Geofencing Filter. In addition, minimum durations are configured:

Label	Description
Minimal Inside Duration	Time a device must remain inside the area before `Entered` is generated.
Inside Duration Unit	Time unit for `minInsideDuration`.
Minimal Outside Duration	Time outside the area before `Left` is generated.
Outside Duration Unit	Time unit for `minOutsideDuration`.

Outputs

Output	Meaning
`Entered`	Device stayed inside long enough and was previously outside.
`Left`	Device stayed outside long enough and was previously inside.
`Inside`	Device is inside, but the minimum duration has not been reached yet.
`Outside`	Device is outside, but the minimum duration has not been reached yet.

RPC Call Request

Category: Action
Outputs: Success, Failure, Timeout

The node sends an RPC call from the server to a device and waits for the response.

Configuration

Label	Required	Description
Timeout	Yes	Wait time in seconds before the message continues through `Timeout`.

Input and Output

The message body must contain method and params. The originator must be a device. On Success, the device response replaces the message body.

Example

{
  "method": "emergencyShutdown",
  "params": { "reason": "HighTemperature" }
}

info

The device must be configured accordingly so that it can actually execute the required Remote Procedure Calls.

RPC Call Reply

Category: Action
Outputs: Success, Failure

The node sends a response back to an RPC request coming from a device. The response content is built from the current message body.

Configuration

Label	Required	Description
Request ID Metadata Attribute	No	Metadata field containing the RPC request ID.

Input

The message must be of type TO_SERVER_RPC_REQUEST. serviceId, sessionId, and requestId are usually set by the platform.

Enrichment Nodes

Originator Attributes

Category: Enrichment
Outputs: Success, Failure

The node reads attributes and the latest telemetry values of the originator from the database and writes them into the message metadata.

Metadata Prefixes

Source	Prefix in metadata
Client attributes	`cs_`
Shared attributes	`shared_`
Server attributes	`ss_`
Latest telemetry	no prefix

Configuration

Label	Required	Description
Client Attributes	No	Client attributes added as `cs_<name>`.
Shared Attributes	No	Shared attributes added as `shared_<name>`.
Server Attributes	No	Server attributes added as `ss_<name>`.
Latest Timeseries	No	Latest telemetry values added without a prefix.
Tell Failure	Yes	Enabled: missing values lead to `Failure`. Disabled: missing values are skipped.

At least one attribute or telemetry key must be configured.

Example

If you want to define an offset value manually for a temperature channel, you can create a server attribute such as offset: 5. This node can then load that value and enrich the metadata so it can be used downstream by selecting the channel offset under Server Attributes.

In the following Script node, that value can then be accessed like this:

var offset = metadata.ss_offset;
var correctedTemperature = msg.temperature + offset;
return {
    msg: msg,
    metadata: metadata,
    msgType: msgType
};

Originator Telemetry

Category: Enrichment
Outputs: Success, Failure

The node reads historical telemetry values of the originator from a time window and adds them to the metadata.

Configuration

Section	Fields
Data selection	`latestTsKeyNames`, `fetchMode` with `FIRST`, `LAST`, or `ALL`.
Additional fields for `ALL`	`aggregation`, `orderBy`, `limit`.
Time window	`useMetadataIntervalPatterns`, `startInterval`, `startIntervalTimeUnit`, `endInterval`, `endIntervalTimeUnit`, `startIntervalPattern`, `endIntervalPattern`.

Notes

With FIRST or LAST, a single value per key is added.
With ALL, values are stored in metadata as a JSON array.

Example

To compare against the average of the last five minutes, temperature can be loaded with fetchMode = ALL and then evaluated in a Transform script.

Script node

var temperatureArray = metadata.temperatureArray;
var total = 0;
var avgTemp = 0;

for (var i = 0; i < temperatureArray.length; i++) {
    total += temperatureArray[i];
}

if (temperatureArray.length > 0) {
    avgTemp = total / temperatureArray.length;
}

msg.avgTemp = avgTemp;

return {
    msg: msg,
    metadata: metadata,
    msgType: msgType
};

Originator Fields

Category: Enrichment
Outputs: Success, Failure

The node reads originator master data fields, such as name or type, and writes them into the metadata under configurable names.

Configuration

Label	Required	Description
Fields Mapping	Yes	Mapping of entity field names to metadata keys.

Source field	Meaning
`name`	Display name of the device
`type`	Entity type, `DEVICE`
`label`	Label of the entity
`additionalInfo`	Additional information as JSON
`createdTime`	Creation timestamp in epoch milliseconds

Example

With name -> deviceName, a downstream To Email node can use ${deviceName} in the subject.

Tenant Details

Category: Enrichment
Outputs: Success, Failure

The node adds contact and address data of the tenant to the message body or metadata.

Configuration

Label	Required	Description
Details	Yes	Selected tenant fields. At least one field must be selected.
Add Details to Metadata	Yes	Enabled: values are written to metadata. Disabled: values are written to the message body.

Available fields are TITLE, EMAIL, PHONE, COUNTRY, CITY, STATE, ZIP, ADDRESS, ADDRESS2, and ADDITIONAL_INFO.

Transformation Nodes

Script (Transform)

Category: Transformation
Outputs: Success, Failure

The node changes the message body, metadata, and/or message type using JavaScript. The script result is passed to the next nodes.

Configuration

Label	Required	Description
Transform Function	Yes	JavaScript function `Transform(msg, metadata, msgType)`.

Return Value

The script must return an object with msg, metadata, and msgType.

Example

var newMsg = {};
newMsg.temperatureF = msg.temperature * 9 / 5 + 32;
newMsg.humidity = msg.humidity;

return {
    msg: newMsg,
    metadata: metadata,
    msgType: msgType
};

To Email

Category: Transformation
Outputs: Success, Failure

The node creates an email object from the current message and its metadata.

Configuration

Label	Required	Description
From	Yes	Sender address.
To	Yes	Recipient address or multiple recipients separated by commas.
CC	No	CC recipients.
BCC	No	BCC recipients.
Subject	Yes	Subject line.
Body	Yes	Email content.

All fields support placeholders in the format ${metadataKey}.

info

The To Email node only creates the email object. The actual sending is done by the Send Email node, which handles communication with the SMTP server.

Processing Chain

External Nodes

REST API Call

Category: External
Outputs: Success, Failure

The node sends an HTTP request to an external REST interface. The current message body is used as the request payload.

Configuration

Label	Required	Description
Endpoint URL Pattern	Yes	Target URL. Supports `${metadata}` placeholders.
Request Method	Yes	HTTP method: `GET`, `POST`, `PUT`, `DELETE`.
Use Simple Client HTTP Factory	No	Uses a simple HTTP client, for example for large responses.
Headers	No	HTTP headers as a key-value list.

Output

On success, status, statusCode, statusReason, and headers are written to metadata. The response body becomes the new message body.

MQTT

Category: External
Outputs: Success, Failure

The node publishes the current message body to an external MQTT broker. The topic can be built dynamically from metadata.

Configuration

Label	Required	Description
Topic Pattern	Yes	MQTT topic with optional `${metadata}` placeholders.
Host	Yes	Host name or IP address of the broker.
Port	Yes	Broker port, for example `1883` or `8883`.
Connection Timeout	Yes	Connection timeout in seconds.
Client ID	No	MQTT client ID.
Clean Session	No	Controls whether broker session data is discarded.
Enable SSL	No	Enables TLS/SSL.

Credentials

Supported modes are anonymous, basic with username/password, and cert.PEM for mTLS with PEM certificates.

Kafka

Category: External
Outputs: Success, Failure

The node publishes the current message body as a record to a Kafka topic.

Configuration

Label	Required	Description
Topic Pattern	Yes	Kafka topic, optionally with metadata placeholders.
Bootstrap Servers	Yes	Comma-separated list of brokers.
Auto Retry Times	No	Number of retry attempts.
Batch Size	No	Batch size in bytes.
Time to Buffer	No	Wait time for collecting records in milliseconds.
Buffer Max Size	No	Maximum producer buffer size.
Acks	Yes	Broker acknowledgement behavior.
Serializer	Yes	Serializer classes.
Other Properties	No	Additional Kafka producer properties.

Output

On success, offset, partition, and topic are written to metadata.

RabbitMQ

Category: External
Outputs: Success, Failure

The node publishes the message body to a RabbitMQ exchange. Exchange and routing key can be built from metadata.

Configuration

Label	Required	Description
Exchange Name Pattern	No	Exchange name. Empty means default exchange.
Routing Key Pattern	No	Routing key.
Message Properties	No	AMQP message properties.
Host	Yes	RabbitMQ host.
Port	Yes	AMQP port.
Virtual Host	No	RabbitMQ virtual host.
Credentials	No	Authentication.
Automatic Recovery	No	Automatic reconnection.
Timeouts	No	Connection and handshake timeouts.
Client Properties	No	Additional client properties.

AWS SQS

Category: External
Outputs: Success, Failure

The node sends the current message body to an AWS SQS queue. Standard and FIFO queues are supported.

Configuration

Label	Required	Description
Queue Type	Yes	Standard or FIFO queue.
Queue URL Pattern	Yes	URL of the SQS queue. Supports metadata placeholders.
Delay Seconds	No	Delay for standard queues.
Message Attributes	No	Additional SQS attributes.
AWS Credentials	Yes	IAM credentials.
AWS Region	Yes	AWS region of the queue.

Output

On success, values such as messageId, requestId, messageBodyMd5, messageAttributesMd5, and for FIFO queues sequenceNumber are added.

AWS SNS

Category: External
Outputs: Success, Failure

The node publishes the current message body to an AWS SNS topic.

Configuration

Label	Required	Description
Topic ARN Pattern	Yes	ARN of the SNS topic. Supports metadata placeholders.
AWS Credentials	Yes	IAM credentials.
AWS Region	Yes	AWS region of the topic.

Output

On success, messageId and requestId are written to metadata.

GCP Pub/Sub

Category: External
Outputs: Success, Failure

The node publishes the current message body to a Google Cloud Pub/Sub topic.

Configuration

Label	Required	Description
GCP Project ID	Yes	Google Cloud project ID.
Topic Name	Yes	Name of the Pub/Sub topic.
GCP Service Account Key	Yes	Upload of a JSON file with service account credentials.
Message Attributes	No	Additional Pub/Sub attributes.

Note

The service account requires the permission roles/pubsub.publisher for the target topic.

Output

On success, messageId is written to metadata.

Send Email

Category: External
Outputs: Success, Failure

The node sends an email object via SMTP. The email object must be created beforehand by the To Email node.

Configuration

Label	Required	Description
Use General SMTP Settings	Yes	Enables the system-wide SMTP settings.

If the system-wide SMTP settings are disabled, smtpProtocol, smtpHost, smtpPort, username, password, timeout, enableTls, requireTls, checkServerIdentity, and sslTrustHost can be configured.

Note

If the incoming message is not a valid email object, it is routed through Failure.

Scheduler Nodes

Create Scheduled Task

Category: Scheduler
Outputs: Success, Failure

The node schedules a one-time task for a later point in time. The task can generate a report or trigger a RuleChain.

Configuration

Label	Required	Description
Job Name	Yes	Unique name of the scheduled task.
Delay Before Start	Yes	Delay until execution.
Type	Yes	`REPORT` or `RULE_CHAIN`.
Rule Chain	Yes, for `RULE_CHAIN`	RuleChain to execute.
Report fields	depends on report type	Configuration for scheduled reports.

Notes

A task with the same jobName for the same entity is overwritten.

Clear Scheduled Task

Category: Scheduler
Outputs: Success, Failure

The node deletes a previously scheduled task before it is executed.

Configuration

Label	Required	Description
Job Name	Yes	Exact name of the task that should be deleted.

Notes

The name must match the name used in Create Scheduled Task.
The assignment is done per originator entity.
If no matching task exists, the message goes through Failure.

Event and Alarm Nodes

Complex Alarm

Category: Event Rule
Outputs: Success, Created, Cleared

The node creates or clears alarms based on an event rule for real-time telemetry. It is suitable for patterns that cannot be modeled with a simple single-value check.

Configuration

Label	Required	Description
Event Rule	Yes	Selection of an existing event rule.

Notes

The event rule must be created before the node is used. See Event Processing
Created means that a new alarm was opened.
Cleared means that an existing alarm was cleared.
Success means that no alarm state change took place.

Complex Event Processing

Category: Event Rule
Outputs: Success, Created, Cleared

The node applies complex event processing to already loaded OSF file data. It is the file-based variant of Complex Alarm.

Configuration

Label	Required	Description
Event Rule	Yes	Selection of the event rule for CEP evaluation.

Notes

The node is placed after Aggregate OSF File.
The event rule must already exist in the platform. See Event Processing

Enrich Alarm

Category: Event Rule
Outputs: Success, Failure

The node enriches an existing alarm with additional information from an Excel-based event rule.

Configuration

Label	Required	Description
Event Rule	Yes	Selection of an event rule with the associated Excel file for enrichment.

Notes

The event rule must already exist in the platform. See Event Processing
The event rule must include an Excel file with mappings for alarm types or conditions.
The node is used after Create Alarm or Complex Alarm.
The additional details are written back into the alarm record.

RuleNodes​

Overview by Category​

Filter Nodes​

Action Nodes​

Enrichment Nodes​

Transformation Nodes​

External Nodes​

Scheduler Nodes​

Event and Alarm Nodes​

Detailed Overview​

Filter Nodes​

Message Type Filter​

Configuration​

Example​

Message Type Switch​

Configuration​

Example​

File Type Switch​

Configuration​

Example​

File Names Filter​

Configuration​

Notes​

Example​

Device Filter​

Configuration​

Outputs​

Example​

Script (Filter)​

Configuration​

Script Context​

Example​

Switch​

Configuration​

Notes​

Example​

Check Existence Fields​

Configuration​

Example​

GPS Geofencing Filter​

Configuration​

Note​

Example​

Action Nodes​

Save Timeseries​

Configuration​

Input​

Save Attributes​

Configuration​

Input​

Save Alarms​

Outputs​

Configuration​

Input​

Create Alarm​

Outputs​

Configuration​

Metadata after Processing​

Example​

Clear Alarm​

Outputs​

Configuration​

Metadata after Processing​

Example​

Alarm Counter​

Configuration​

Example​

Log​

Configuration​

Notes​

Generator​

Configuration​

Example​

Note​

Message Count​

Configuration​

Output​

Delay​

Configuration​

Notes​

RuleNodes

Overview by Category

Filter Nodes

Action Nodes

Enrichment Nodes

Transformation Nodes

External Nodes

Scheduler Nodes

Event and Alarm Nodes

Detailed Overview

Filter Nodes

Message Type Filter

Configuration

Example

Message Type Switch

Configuration

Example

File Type Switch

Configuration

Example

File Names Filter

Configuration

Notes

Example

Device Filter

Configuration

Outputs

Example

Script (Filter)

Configuration

Script Context

Example

Switch

Configuration

Notes

Example

Check Existence Fields

Configuration

Example

GPS Geofencing Filter

Configuration

Note

Example

Action Nodes

Save Timeseries

Configuration

Input

Save Attributes

Configuration

Input

Save Alarms

Outputs

Configuration

Input

Create Alarm

Outputs

Configuration

Metadata after Processing

Example

Clear Alarm

Outputs

Configuration

Metadata after Processing

Example

Alarm Counter

Configuration

Example

Log

Configuration

Notes

Generator

Configuration

Example

Note

Message Count

Configuration

Output

Delay

Configuration

Notes