Rules - Understanding System Actions
System Actions allow for a user to configure logic in relation to notifications and/or Add-on devices (such as Control Units, Local Alerts). System Actions are used in conjunction with the Tasks tab when configuring Rules in the iMonnit Online Portal. Rules are triggered by a triggering Condition, and offer the following Tasks:
Monnit Support does not offer services for designing or reviewing logic in System Actions. Support inquiries regarding System Action logic will be referred to documentation.
- Send a notification (Email, SMS, or Voice Call)
- Send a Control Unit command
- Send a Local Alert message (message display, sound, or LED)
- Send a Thermostat command
- Execute a System Action
Therefore with the above functions, you can execute logic to interact with users or devices based on a triggering condition. When a Rule is triggered, any configured System Action on the triggering Rule will be executed on the target Rule (which may the same or completely different triggering Rule).
System Action functions
There are four System Actions as listed below. For reference understanding Disarm/Rearm, see this article.
- Acknowledge (also referred to as Disarm)
- Full Reset (also referred to as Rearm)
Acknowledge common use case
The Acknowledge System Action simply Disarms (Acknowledges) a Rule. A common use case would be to execute a System Action of a Rule to Disarm (Acknowledge) itself after it is triggered. The purpose behind this might be to make a Sensor Reading trigger and send a notification (such as SMS) on that triggering condition, but not continue to send repeat notifications on the Rule’s configured Snooze time (which by default is 60 minutes).
In this scenario, the Rule with a default 60 minute Snooze time would be triggered by configured condition, send out a single SMS notification to alert a User, and after the notification sent, the Rule would Disarm (Acknowledge) itself so it does not continue to send repeat notifications on the Snooze timer if the condition persists.
In other words, the user would receive a single notification when the triggering condition was reported, and no repeat notifications. When the triggering condition returned to normal, the Rule would be Rearmed (Reset), assuming if the Auto-Acknowledge setting was enabled. It would be prepared to trigger again on a future triggering condition reported by the sensor.
Full Reset common use case
The Full Reset would Rearm (Reset) a Rule when it is executed. A common scenario for this might be a User that wants to be immediately notified via SMS on a triggering condition every time the sensor reports a reading with that triggering condition (as opposed to utilizing the Snooze feature). By executing a Full Reset System Action on itself, the Rule is effectively Disarmed/Rearmed every time the sensor reports a reading that triggers the Rule. Therefore if you had a Rule that executed a Full Reset on itself, it would trigger a notification on every triggering reading reported by the sensor.
Activate and Deactivate
The Activate and Deactivate System Actions turn on or off the target Rule. This completely enables/disables the Rule from triggering. You might use this any time you wish a triggering condition to turn on or off a Rule.
Consider adding Delays
Each System Action has the ability to set up a Delay. This is useful for when you need to set up logic that happens in a planned sequence. If no delay is enabled, the System Action is executed immediately.
It is often a good idea to set up a delay of 1 minute to make sure the System Action logic is not executed so fast that it is out of sequence from other operations in the portal.
Creating a System Action
- Create a Rule or select an existing Rule.
- In the Tasks tab of the Rule, click the Create System Action button.
- In the System Action pane that appears, select the Action to be done.
- Select the Delay.
- Select the Target Rule.
- Select Add.
Using a System Action with a Scheduled Rule
A strategic component to using a System Action would be to create a Scheduled Rule. Scheduled Rules run according to a configured repeating Month/Week/Day/Hour/15 minute schedule. If you create a scheduled Rule, you can execute System Actions at desired times. This can be a powerful component to using System Actions.
A scheduled Rule is a Rule for which the trigger is a particular date/time, as opposed to adding a Schedule to a configured Rule.
System Action history
To view the history for which a System Action was executed, you can review the Rule History and identify the System Action in the sequence it was executed.
- Select the Rule
- Select the History tab
- Set the appropriate date range
- Select the Set button
- Locate the System Action in the history
System Actions can be a powerful tool in executing desired logical functions. If you have related inquiries, feel free to contact email@example.com.