Creating a scenario

• Name – the scenario name;
• Description – a detailed description of the scenario (optional).

• By cross-elements – this type of scenario uses cross-elements, which are abstract parameters that can be created directly within the scenario without being tied to a specific model. A scenario based on cross-elements is a reusable component that can be applied to objects with different models, after mapping the cross-elements and parameters from the model of the object on which the scenario will be launched;
• By parameters from model – this type of scenario is based on a specific selected model. If the scenario involves interaction between multiple objects, select the models that correspond to those objects.

💡

1. Save your scenario regularly. You can do this by clicking Save or using the keyboard shortcut Ctrl+S.
2. Unsaved changes are preserved when navigating between sections of the platform interface. However, they will be lost if you reload or close the page.
3. If you have a scenario open, and it is modified from another browser tab, another browser session, or by another user, you will see the message Scenario has been updated along with a button to refresh the data. If you have unsaved changes at that moment, they cannot be saved after the scenario has been updated.

Adding a State

Actions in states

1. Scenario actions — basic actions available in any scenario:

• Change value
• Generate event
• Change status
• Timer #... — timer control commands:
  • Start timer #...
  • Stop timer #...
• Scheduler #... — scheduler control commands:
  • Start scheduler #...
  • Stop scheduler #...

2. Event registration — actions used to record state entry and exit events:

• Show message
• Make HTTP request
• Send e-mail
• Send SMS
• Send Discord message
• Send Telegram message

3. Object actions — commands created within the scenario as cross-elements. This category remains empty until you create cross-elements of type Action inside the scenario.

Change value

• read a value from a configuration, state, or status parameter and write it unchanged to another configuration, state, or status parameter. The retrieved value is available as the variable $value;

• read a value from a configuration, state, or status parameter, run an expression to it, and write the result to another configuration, state, or status parameter. Simple arithmetic operations are supported: +, -, *, /;

• set a specific value within an expression and write it to a configuration, state, or status parameter.

Generate event

• Event — select the event created in the cross-elements;
• Payload — you can also specify additional details about the event and process them if it is expected that the event is also received by an external system connected via WebSocket.

Change Status

Start/stop timer #...

• Number – enter a Value representing the number of seconds, minutes, hours, or days after which the timer should trigger;

• Parameter – select a parameter created in the cross-elements section. The value of that parameter will be used as the timer duration;

• Configuration – select a configuration parameter created in the cross-elements section. Its value will be used as the timer duration.

Start/stop scheduler #...

• Time zone – is set by default to the time zone configured in your platform account, but can be changed;
• Type:
  • Simple – select only the day of the week;
  • Extended – select the month, day of the week, and day of the month;
• Month (if extended);
• Day of week;
• Day of month (if extended).

Simple	Extended

• Exact Time – the scheduler triggers at a specific time. For example, if you set 13:15, the Scheduler triggered event will occur exactly at 13:15:00.
• Interval Time – allows you to define a time range and a repetition interval within that range. For example, if you select a range from 13:00 to 14:00 with an interval of Every 2 minutes, the scheduler will trigger at 13:00:00, 13:02:00, 13:04:00, and so on.

Show message

Creating messages

• Informational;
• Important;
• Critical;

{
  "event": "Good conditions",
  "temperature": {{object.state["temperature"]}}
}

Viewing messages

💡

If new messages arrive that do not match the currently applied filters or search criteria, the configurable section of the message panel is briefly highlighted in red.

• Do not group – no grouping, messages are displayed as a complete list;

• By object – for each object, all messages will be grouped together. The number of messages in the group is displayed in the lower-left corner of the group card;

• By message – messages with the same text are grouped together. The number of messages in the group is displayed in the lower-left corner of the group card;

💡

If an object is deleted, messages previously received for that object will remain available in the message list. However, the object name will be replaced with a question mark. Click a message to expand it and view its contents. The identifier of the deleted object will still be available, allowing you to get its messages through the API if necessary.

Make HTTP request

• Method – the HTTP request method:
  • GET – get data from the specified resource;
  • POST – send data to a resource;
  • PUT – replace an entire resource with the provided data;
  • PATCH – similar to PUT, but updates only a specific portion of the resource;
  • DELETE – remove data from a resource;
• URL – the destination URL to which the request will be sent;
• Headers – additional metadata used to define how the request should be processed by the server. Headers can be used to specify authentication parameters, content language, request and response formats, connection settings, and other protocol-specific options;
• Body – the data payload to send with the request. This field is optional.

Send e-mail

• SMTP gateway (required) – the outgoing mail server that will be used to send the email via the SMTP protocol. Learn more about configuring an SMTP server >>>
• From (required) – the email address that the message will be sent from;
• To (required) – one or more email addresses that will receive the message. Multiple addresses can be specified as a comma-separated list;
• Subject (required) – the email subject line;
• Mail body (text) – the plain-text version of the message body;
• Mail body (html) – the message body in HTML format. If this field is populated, the Mail body (text) field is ignored.

Send SMS

• SMPP gateway (required) – the SMS gateway server used to send messages via the SMPP protocol;
• To (required) – one or more phone numbers that will receive the message. Multiple numbers can be specified as a comma-separated list;
• Message – the content of the SMS message.

Send Discord message

• Integration (required) – the Discord webhook to use for message delivery. Learn more about configuring a Discord integration >>>
• Message – the content of the message to send.

Send Telegram message

Action-type cross-elements

• Type – automatically set to Action and cannot be changed;
• ID – an identifier used internally by the system to reference the cross-element. It must be unique within the current scenario;
• Name – the display name of the action;
• Description – an optional description that provides additional information about the action.

Model commands

Creating a transition

💡

The Add/Edit Conditions button that appears when hovering over a transition card provides the same functionality as the corresponding button inside the card. The floating button is particularly useful when the transition card has been resized to save workspace space, as the controls inside the card may no longer be visible.

Events

Built-in events

1. Scenario Events:

• Instant transition – the transition is executed as soon as the scenario enters the state from which the transition originates;
• Timer #... – timer-related events:
  • Timer #... triggered – the transition is executed when the corresponding running timer expires;
• Scheduler #... – scheduler-related events:
  • Scheduler #... triggered – the transition is executed when the corresponding running scheduler is triggered.

2. Object Events:

• Data received – the transition is executed when a new data packet is received;
• Object edit – the transition is executed when changes are saved on the object's Edit tab;
• Status change – the transition is executed when the object's status changes;
• Geofences – location-based events:
  • Enter the geofence – the transition is executed when the object enters a monitored geofence;
  • Leave the geofence – the transition is executed when the object leaves a monitored geofence;
  • Enter the room – the transition is executed when the object enters a monitored room on a floor plan;
  • Leave the room – the transition is executed when the object leaves a monitored room on a floor plan;
  • Trip Enter – the transition is executed when the object approaches a predefined route to within 50 meters;
  • Trip Leave – the transition is executed when the object moves more than 50 meters away from the predefined route;
  • Waypoint Enter – the transition is executed when the object comes within 50 meters of a route checkpoint;
  • Waypoint Leave – the transition is executed when the object moves more than 50 meters away from a route checkpoint.
• Commands – events related to command execution on the object:
  • Command completed – the transition is executed when the command specified in the transition conditions completes successfully;
  • Command failed – the transition is executed when the command specified in the transition conditions fails. For example, this event may occur if the device does not acknowledge the command according to the communication protocol or loses its connection to the platform.

💡

To prevent runaway execution, scenarios include built-in protection against excessive numbers of transitions occurring within a short period of time. Keep this limitation in mind when designing scenarios that contain loops or cyclical execution paths.

For example, if a scenario is configured with an endless loop using Instant transition event, execution will eventually be stopped automatically and the scenario status will change to Emergency stop.

Event-type cross-elements

• Type – automatically set to Event and cannot be changed;
• ID – an identifier used internally by the system to reference the cross-element. It must be unique within the current scenario;
• Name – the display name of the event;
• Description – an optional description that provides additional information about the event.

Model events

Conditions

💡

When working with a large number of parameters, you can use the search field to quickly find the required parameter.

• a specific value – enter a numeric, string, or boolean value that matches the parameter's data type;
• another parameter – select a parameter to compare against;
• a level – select one of the levels defined for the parameter in the object model;
• a configuration value – select a parameter of type Configuration. Comparing against configuration parameters is useful when the same scenario logic is shared across multiple objects, but the condition thresholds differ. For example, one temperature range may be considered normal for a bedroom, while a different range is appropriate for a kitchen. In this case, there is no need to create separate climate-control scenarios for each room. Instead, you can define configuration parameters that store the acceptable temperature ranges for each object and compare the current temperature against those configuration values rather than hard-coded numbers.

💡

The Level section is available only when the scenario is of type By parameters from model and levels have been defined in the model for the selected parameter.

The Configuration section is available only when:

• the scenario of type By cross-elements contains cross-elements of type Configuration, or
• the scenario of type By parameters from model contains model nodes of type Configuration.

💡

The in operator can be used to:

• check whether a parameter value exists within an array of values;
• check whether a string contains a specific substring.

The not in operator

verifies that the selected parameter value is not present in an array and is not contained within a string.

• AND – all conditions must evaluate to true for the transition to occur;
• OR – at least one condition must evaluate to true for the transition to occur.

• Type – automatically set to Parameter and cannot be changed;
• ID – an identifier used internally by the system to reference the cross-element. It must be unique within the current scenario;
• Name – the display name of the parameter;
• Description – an optional description that provides additional information about the parameter;
• Data type – depending on the parameter's data type, a list of possible comparison operations is generated.

💡

You can also create cross-elements of type Parameter or Configuration directly while selecting the comparison value on the right side of the condition editor.