Alarm Query

Open Data and Alarm → Alarm Query. Use Real-time Alarm for current alarm handling and Historical Alarm for events already saved by a historical alarm target. Recovery and acknowledgement are separate; the recovery-removal setting also affects which records remain in the realtime list.

To send an email when an alarm is generated, first enable alarms on the variable, then connect the "Alarm Notification Rule" and "Email Push" nodes in the rule engine. Mail server parameters are not maintained under "System Settings → Alarm Configuration." For the complete procedure, see Alarm Configuration and Email Notifications.

Configure and verify an alarm

First Look at Terms

Terms	On-site Understanding
Real-Time Alarms	Incidents that still require personnel attention may not have recovered or been confirmed, or may remain pending confirmation even after restoration.
Historical alarms	alarm records written to historical storage, used for traceability, export, shift reports, or accident analysis.
Alarm / Recovery	Alarm indicates that the condition has been triggered; Recovery means the variable value returns to the allowed range or the trigger condition disappears.
Acknowledge an alarm	Record that someone has seen the alarm. Acknowledgement does not change the source value or clear its condition.
HH / H / L / LL	High-high, high, low, and low-low limits. The configured alarm level determines severity.
Suppression Conditions	A Data Conversion script returns true to allow and false to block an alarm; empty adds no condition.
Alarm Recovery Configuration	Whether the alarm is automatically removed from the real-time alarm list after recovery must be set according to the on-site duty process.

Configure a test high-limit alarm

Use the writable ManualValue from Memory Calculation. Before testing, remove any write scaling that would change the intended input.

1. Open Development Configuration → Memory Calculation, edit ManualValue, and open Alarm Configuration.
2. Enable only the High group. Enter 100 in Alarm Code; this is the comparison limit, not an event identifier. Set text to Demo value high, level to 1, delay to 0, and leave suppression empty.
3. Save the variable. If this test must also produce history, enable its history target before generating the lifecycle.
4. Write 101, open Real-time Alarm, and refresh. Check Memory / ManualValue, value 101, limit 100, and the configured text.
5. Click Confirm, enter an optional note, and save. Open Details to check acknowledgement time and text. The value remains 101 and the alarm condition still holds.
6. Write 99 and refresh after any configured recovery delay. The record can leave the realtime list according to its acknowledgement and recovery-removal settings.

For actual collection variables, edit the variable in Collection Configuration and use the same alarm tab. Choose limits from the approved engineering range.

Alarm groups and conditions

Each group has independent enablement, text, severity, delay, and suppression. Disabling a group does not block variable collection or writes. Save, read back the actual input, and verify normal-to-trigger transitions.

One variable can trigger several groups simultaneously. With H=80 and HH=100, holding 101 can produce both H and HH. At 90, HH recovers after its delay while H remains triggered. Match each variable and alarm type separately; the active-record count is not the number of abnormal variables.

Group	Condition
Open / Close	Actual Boolean true / false.
H / HH	Strictly greater than the group's numeric limit. Equality does not trigger it.
L / LL	Strictly less than the limit.
Custom	Select a compiled Data Conversion condition script in Alarm Code. The result is Boolean; the name is not an event identifier.
State	Exact match against an enabled numeric state mapping.

Delay is milliseconds of a continuously met condition, for both alarm and recovery. Test a short excursion and one held beyond the delay. This does not delay the memory write itself. Suppression also uses Data Conversion, distinct from Memory Variable calculation scripts: true permits, false blocks, empty adds no constraint.

An offline variable does not supply a new process value for numeric or Boolean alarm evaluation. Offline quality does not establish that an existing alarm has recovered; check the connection, variable quality, and latest collection time together. Inspect expression errors and suppression settings as well before interpreting an empty realtime list as normal operation.

Numeric state mappings

Add rows for values such as 100 and 101, each with its own enablement, text, level, delay, and suppression. Enter each value, then an unmatched 99, and check matching, switching, and recovery. Enabled state values must be unique. A variable's State lifecycle changes with the matched mapping; each row is not a permanently independent active alarm. Deleting a mapping does not delete the variable or old history.

Combined temperature and pressure

Create a read-only memory calculation using both real Tag inputs for temperature greater than 100 and pressure greater than 5, then enable an Open alarm on the result. Verify (99,4), (101,4), and (99,6) remain false, while (101,6) becomes true. Test equality as well. Acknowledging the alarm does not change either source; returning pressure to 4 clears the condition.

History, filtering, and export

Add the alarm variable to an enabled group with an Alarm History target. After trigger, acknowledgement, and recovery, match identity and occurrence time across Alarm, Confirm, and ConfirmAndFinish; recovery without acknowledgement can use Finish. Multiple rows can represent one lifecycle.

The target's minimum level controls new storage. Query level filters existing rows. Raising storage minimum from 3 to 4 leaves old rows and realtime level-3 alarms intact but excludes their new events from that target. Query settings cannot backfill them.

Query the correct group/target over the full event-time window. The minimum query level includes higher levels. Export downloads the current page; other pages require separate exports. Column visibility does not remove other export fields. Inspect the timeline and acknowledgement text rather than inferring current state from row order.

View and handle alarms

On-site Handling Process

The alarm page is used for confirmation and tracing of alarms, and does not directly replace on-site handling. When duty or commissioning personnel see the alarm, it is recommended to handle it in the following order.

Sequence	Operation	Purpose
1	View real-time alarm devices, variables, alarm values, limits, and alarm times.	Determine the source and severity of the alarm.
2	Confirm the actual status of the equipment on site or in the upper-level system.	Eliminate communication anomalies, range errors, or false alarms.
3	Handle process or equipment issues according to on-site procedures.	Address on-site risks first, then system records.
4	Confirm the alarm on the alarm page and fill out the confirmation instructions.	Leave the handler, the processing time, and the handling conclusion.
5	When retrospective, enter the historical alarm query and export.	Used for class reports, accident analysis, or delivery archives.

Explanation

Acknowledgement records that someone has seen the alarm. Recovery follows the variable value, configured condition, and delay. The recovery-removal setting controls whether a recovered record remains in the realtime list; it does not change the process value or clear its condition.

Function Entry

Click the left menu "Data and Alarm → Alarm Query" to enter the page.

Alarm List

Columns	Descriptions
Level	Alarm Level (with color tags; level 4 and above is red, Level 3 is orange)
Equipment	Name of Alarm Device
Variable	Alarm Variable Name
Alarm Content	Description of the Alarm's Specific Content, prioritizing the alarm text in the variable configuration.
Alarm Value	Variable Value When Alarm Is Triggered
Limit	Alarm Threshold
Alarm Time	Alarm Occurrence Time
Event Type	Alarm/Recovery (with color tag, alarm is red, recovery is green)
Alarm Type	HH, H, L, LL, Open, Close, Custom, or State.
Confirmation Time	Alarm Confirmation Time, displays the "Not Confirmed" label when not confirmed

Alarm Type Description

Type	Description
HH / H	Current value is strictly greater than the corresponding high-high / high limit.
L / LL	Current value is strictly less than the corresponding low / low-low limit.
Open / Close	Current Boolean value is true / false.
Custom	A compiled Data Conversion condition returns true.
State	Current numeric value exactly matches an enabled state row.

Alarm suggestions

Alarm delay (ms) can be set to how long the alarm lasts before triggering to avoid momentary fluctuations causing false alarms.

Operation Functions

Functions	Description
Refresh	Manually refresh alarm list (requires permission)
Automatic refresh	Selectable options: 1 second,10 seconds,30 seconds, 1-minute refresh interval, or automatic refresh can be paused and then manually handled by alarm.
Alarm Level Filtering	Filtering current alarms by alarm level. The higher the level value, the more severe the condition usually is.
Keyword Search	Search for alarms by variable name, device name, or alarm text.
Column Settings	Show or hide the available alarm columns. This does not change stored event data.
Details	View alarm details (permission required)
Confirm	Confirm unconfirmed alarm events.

Alarm Confirmation

Click the "Confirm" button to confirm the alarm. An input box will pop up during confirmation, where you can enter the confirmation instructions:

Use the realtime list's confirmation action for an unacknowledged record; it is disabled for a confirmed alarm and requires permission. Confirmation records the acknowledgement time and note. Recovery still depends on the actual value and configured conditions.

Confirm Configuration

Field	Description
Confirmation Instructions	Optional, enter the remarks for alarm confirmation

prompt

Entering confirmation instructions can help with subsequent alarm handling; it is recommended to fill in the action or reason description. The confirmation alarm only marks the alarm as known and will not cancel it. The alarm automatically returns to the recovery state once the variable value returns to normal.

Alarm Details

Click the "Details" button to open the alarm details drawer, displaying the full alarm information in a partitioned format:

The details drawer is organized into fields such as "Basic Information, Alarm Information, Variable Information, Time Information, Confirmation Information," suitable for checking alarm sources and trigger thresholds , recovery time, and confirmation of processing records.

Partition	Main Content
Basic Information	Alarm ID, variable name, device name, description.
Alarm Information	Alarm level, alarm type, event type, alarm value, limit value, alarm text.
Variable Information	Data type, unit, variable address, and current variable state.
Time Information	Alarm time, recovery time, duration of alarm.
Confirmation Information	Confirmation status, confirmation person, confirmation time, confirmation explanation.

Historical Alarms

The historical alarm tab is used to query alarm records that have been stored in the database by historical alarm target, alarm level, keyword, and time range.

Filter Items	Description
Forwarding Target	Select the historical alarm storage target, which is configured in the data forwarding process.
Alarm Level	Minimum severity; for example, 2 includes levels 2 and above. Clearing the filter includes all stored levels.
Keywords	Search historical records by variable or device name.
Time Range	Filter by event time; include occurrence, acknowledgement, and recovery. Confirm the date/time selection, then refresh.
Export	Download the current page as Excel. Change pages and export separately when more records are required.
Column settings	Change page visibility. Hidden columns do not remove other fields from the export.

Basic Information

Information	Description
ID	Alarm Record ID
Variable Name	Alarm Variable Name
Device Name	Alarm Device
Description	Variable Description Information

Alarm Information

Information	Description
Alarm Level	Alarm Severity
Alarm Type	HH, H, L, LL, Open, Close, Custom, or State.
Event Type	Alarm, Confirm, Finish, or ConfirmAndFinish. Several rows can describe one lifecycle.
Alarm Value	Alarm Trigger Value
Alarm Limit	Alarm Threshold
Recovery Value	Variable Value at Recovery
Alarm Text	Alarm Description Text

Variable Information

Information	Description
Data Type	Variable Data Type
Register Address	Variable Address in Device

Time Information

Information	Description
Alarm Time	Alarm Occurrence Time
Event Time	Event Record Time
Recovery Time	Alarm Recovery Time
Confirmation Time	Alarm Confirmation Time; if not confirmed, display "Not Confirmed"

Custom Fields

If a variable is configured with a custom note field, the custom field range will be displayed in the details:

Field	Description
Note 1	Custom Note 1
Note 2	Custom Note 2
Note 3	Custom Note 3
Note 4	Custom Note 4
Note 5	Custom Note 5

Prompt

Custom fields are only displayed when the variable has the corresponding note.

Query a complete lifecycle

Start the historical alarm target before generating the test alarm. Select its group/target in the historical tab, choose a time range covering all phases, and refresh. For one day, use midnight at the start of the day through midnight of the following day, then confirm the picker selection.

Match alarm identity and occurrence time across the event rows. A later occurrence for the same variable and alarm type can reuse the alarm ID, so distinguish lifecycles by alarm ID plus occurrence time before comparing event times. Acknowledgement is performed on the current realtime record; opening a historical detail does not acknowledge it. Verify confirmation notes in history after the new confirmation event has been stored.

Alarm Configuration and Email Notifications

Email notifications are jointly handled by variable alarms and the rule engine, with the processing process as follows:

"System Settings → Alarm Configuration" only controls whether alarms are removed from the real-time alarm list after recovery; SMTP servers are not configured, nor will emails be sent automatically.

Step 1: Enable alarms for variables

1. Click Development Configuration → Collection Configuration and select the target variable from the persistent variable list.
2. Find the variable you want to monitor, click "Edit," then switch to the "Alarm Configuration" tab.
3. Enable Boolean alarms, limit alarms, or custom alarms according to variable data types, and fill in alarm text, alarm level, alarm delay, and suppression expression.
4. Save the variable and confirm that the variable, its affiliated device, and acquisition channel are all enabled.

Configuration Items	Description
Boolean alert / Boolean off alarm	Alarm occurs when the Boolean variable is in an open or closed state.
High, high, low, low-low alarms	Alarms occur when numerical variables exceed the corresponding limits; When multiple limits are enabled simultaneously, they should meet the conditions of "High High > High > Low > Low Low."
Custom alarms	Use expressions to determine alarm conditions, suitable for status codes or combination conditions.
Alarm Text	AlarmText in emails, it is recommended to specify the object, exception conditions, and handling direction.
Alarm Levels	range from 0 to 10; higher values indicate more serious issues; Can be filtered by email notification rules.
Alarm delay	Alarm only occurs after the alarm condition has been continuously reached for this time, measured in milliseconds; Used to filter transient shaking.
Suppression Expressions	Return true to allow, false to block, or leave empty for no extra condition. Verify the direction before using maintenance or interlock logic.

For details about variable alarm fields, see Alarm Configuration in Collection Configuration.

Step 2: Create an email notification rule stream

1. Click the left menu "Develop Configuration → Rule Engine" to create a new rule stream or open an existing rule stream.
2. Drag the "Alarm Notification Rules" node from the "Triggers" category on the left node panel.
3. Drag the "Data Push" category into the "Email Push" node.
4. Connect the FilteredAlarmData output of the "Alert Notification Rule" to the Data input of the "Mail Push".
5. Select two nodes separately and fill in the filter conditions and SMTP parameters.
6. Save the rule stream and confirm that both the rule stream and both nodes are enabled.

Key points for connection

"Alarm notification rules" will actively subscribe to alarm change events, eliminating the need to connect to variable input nodes. Only alarm data that passes filtering will be output from FilteredAlarmData and trigger subsequent email pushes.

Alarm notification rule parameter

parameter	Description
Minimum alarm level	Only forwards alarms greater than or equal to that level. Filling in 0 indicates that filtering is not by level.
Equipment Name	Accurately match equipment name; Multiple names are separated by English commas, leaving blanks to indicate all devices.
Event Types	Use comma-separated event names. For occurrence only, enter Alarm; to include recovery, enter Alarm,Finish,ConfirmAndFinish. Empty matches all lifecycle events.
Alarm Types	Open, Close, HH, H, L, LL, Custom, or State, separated by commas. Empty matches all types.
Debounce interval	Notify at most once for the same device and variable within this many milliseconds. 0 disables debounce.
Enable	Disable to stop the node from outputting alarm data.

Avoid duplicate emails

For production environments, it is recommended to at least fill in the "Event Type." If you only want notifications when an alarm occurs, please fill in Alarm; When you don't need to restore or confirm emails, don't leave them blank. For points that may experience frequent jitter, variable alarm delay or node anti-shake intervals should also be configured.

Recovery can emit Finish or ConfirmAndFinish, depending on acknowledgement and recovery-removal settings. Debounce is shared by all event types for the same device and variable, so a nearby recovery can be suppressed. Verify the full notification path with debounce 0 before applying the required interval.

Email push parameters

Parameters	Description
SMTP server address	SMTP hostname provided by your mail service provider, such as the SMTP address for a business email. Do not enter the webmail login URL.
SMTP server port	to fill in according to the email service provider's requirements; when enabling STARTTLS, the commonly used 587. The firewall must allow the gateway to access this port.
Enable SSL	enable when the mail server requests encrypted connections; It must match the requirements of the server port and service provider.
SMTP username	SMTP verified account, usually a full email address.
SMTP password	SMTP authorization code or dedicated password provided by the email service provider, which may not necessarily be a web login password.
Sender Address	The sender address shown in the email. Most service providers require it to match the SMTP verified account.
Sender Name	The sender name seen by the recipient, such as TGateway or the on-site name.
Recipient Address	Multiple addresses separated by English commas. Before saving, check for empty addresses or Chinese commas.
Email subject template	Supports {{property-name}} placeholders, such as [{{EventType}}] {{DeviceName}} - {{Name}}.
Email body template	supports the same placeholder; When the main text starts with <, send as an HTML email; otherwise, send as plain text.
Enable	After turning it off, no emails are sent, but node parameters can still be retained.
Push Data	Connect to the FilteredAlarmData output of the "Alarm Notification Rule"; manual filling is not required.

Common template variables are as follows. Variable names should correspond to {{Name}}, not {{VariableName}}; Non-existent properties will be replaced with empty strings.

Template Variable	Content
{{DeviceName}}	Equipment name.
{{Name}}	Variable name.
{{Description}}	Variable description.
{{AlarmLevel}}	Alarm level.
{{EventType}}	Event types, such as Alarm,Finish, Confirm.
{{AlarmType}}	alarm types, such as HH,H,Open, Custom.
{{AlarmText}}	Alarm text in variable alarm configuration.
{{AlarmCode}}	Variable values when an alarm is triggered.
{{AlarmLimit}}	Alarm limit or custom alarm conditions.
{{AlarmTime}}	Alarm generation time.
{{EventTime}}	The current timing of the alarm lifecycle event.
{{FinishTime}}	Alarm recovery time.
{{ConfirmTime}}	Alarm confirmation time.
{{ConfirmText}}	Instructions for Alarm Confirmation.
{{Remark1}} to {{Remark5}}	variable custom note fields.

Subject template example:

[{{EventType}}] {{DeviceName}} - {{Name}} - Level{{AlarmLevel}}

Plain text template example:

Equipment:{{DeviceName}}
Variable:{{Name}}
Event:{{EventType}}
Type:{{AlarmType}}
Level:{{AlarmLevel}}
Alarm value:{{AlarmCode}}
Limit:{{AlarmLimit}}
Contents:{{AlarmText}}
Alarm time:{{AlarmTime}}

Verification Email Notification

Before official use, a full verification should be completed in a test variable or secure debugging environment.

1. Save and enable the rule stream, confirming that the rule flow page is free of configuration errors.
2. Set the test value beyond the configured limit and hold it longer than the alarm delay.
3. In "Data and Alarm → Alarm Query → Real-Time Alarm," confirm that the corresponding alarm has been generated.
4. Return the rule stream, select "Alarm Notification Rules," and confirm that FilteredAlarmData has output alarm data.
5. Select Email Push → Runtime and inspect the current execution status and ExecutionResult. Succeeded means the SMTP send was confirmed. LastPushTime advances only after success and retains the last successful time on failure.
6. Go to your inbox to confirm the subject, body, and time are correct, and also check your spam folder.
7. If recovery notifications are required, restore the test value and compare the actual event type with the email's EventType. Test recovery both before and after acknowledgement so that the required Finish and ConfirmAndFinish events are covered.

If sending times out or returns UnknownEffect, the server may already have accepted the message. Check delivery records before sending again. See the shared execution policy and runtime results for deadlines, attempts, and error observation.

Security Instructions

Do not expose SMTP authorization codes in documents, screenshots, runlogs, or issue feedback. Before taking screenshots, the "SMTP password" should be covered. The production environment should use a dedicated sending account, with restrictions on the permissions and scope of the recipient.

Common Problems

Phenomena	Troubleshooting Methods
No alarm occurred	Check whether variables, devices, and channels are enabled, and whether alarm conditions, alarm delay, and suppression expressions are met.
FilteredAlarmData No output	Checks minimum alarm level, device name, event type, and alarm type; Name matching distinguishes the actual string; multiple values must use an English comma.
SMTP authentication failure	confirm that SMTP service has been enabled in the email backend, using an authorization code or dedicated password; Verify username and sender address.
Connection timeout or TLS failure	Check DNS, gateway, network and firewall ports on SMTP hosts, and confirm that the port matches the "SSL enabled" settings.
Sender rejected	Change the sender's address to one permitted by the SMTP account, or configure dropshipping permissions in the mail service backend.
Receive multiple duplicate emails	Restrict event types to Alarm and set alarm delay or anti-shake intervals; At the same time, confirm that no multiple enabled rule streams are handling the same alarm.
Current execution is Succeeded, but no email arrives	SMTP acceptance does not establish final delivery. Check spam, mail gateway policies, recipient addresses, and provider delivery logs.

Related Links

• System Overview - System Status Monitoring
• Collection Configuration - Channel, Device, Variable Configuration
• Rule Engine - Rule Stream Creation, Node Connection, and Runlog
• System Log - Log Query and Analysis