Rule Engine

Try a comparison first

Create a writable Memory.ManualValue using Memory Computation, then use this isolated input for the first flow.

1. Create a disabled rule and drag Variable Notification Rule onto the canvas.
2. Set DeviceNames=Memory and VariableNames=ManualValue; leave other filters empty.
3. Add Greater Than and set its initial InputB to 100. Add JSON Numeric Extraction, connect notification Result to its Input, then connect its numeric Result to comparison InputA.
4. Validate, save, and enable the flow. Check the loaded revision. Write 101 to the memory point, select the comparison, open Runtime, and inspect Real-time Parameter Values: inputs should be 101 and 100, with Result=true.
5. Write 99 and then 100; both should produce false. Writing the same value repeatedly may produce no new change notification.
6. Disable the practice flow when finished.

The following image locates the Result field on the Runtime tab. The three-node wiring used in this exercise is shown in the subsequent examples.

Set initial inputs on the Configuration tab. View a connected InputA under Runtime → Real-time Parameter Values.

The rule engine is used to process collected data, memory variables, and external events through a visual process. Users can drag trigger nodes, check nodes, compute nodes, push nodes, etc., into the canvas, organize execution sequences by connecting lines, then save and activate workflows.

First, look at the terminology

Function Entry

After logging into TGateway Web, click the left menu “Develop Configuration → Rule Engine”.

Create and edit a flow

Process List

The rule list manages flow details, enablement, and rule packages. Export production flows before changing them.

New Process

1. Click “Add Rule” in the upper right corner of the list.
2. Enter the process name in the prompt box.
3. Click Create Disabled Rule. The system creates a disabled v1 flow and opens the editor.
4. Maintain process descriptions, trigger methods, nodes, wiring, and parameters in the editor.
5. Validate and resolve input, type, and cycle errors. Save the draft, then enable it and check the loaded revision. Disabled drafts may be incomplete, but must pass execution validation before enabling.

Revalidate after editing the draft. If another editor causes a version conflict, keep your changes and compare them with the latest flow before retrying. Saving an enabled flow reloads it; schedule that change for a suitable operating window.

Process Editor

Click “Details” in the flow line to enter the process editor.

Node Panel

Nodes in the node panel come from loaded built-in nodes and custom nodes. Common categories include holding, comparison operations, edge detection, variable RPC, constants, flip-flops, timers, counters, type conversion, logical operations, data statistics, data push, mathematical operations, conditional checks, and string processing.

If a node does not appear in the list, first confirm that the corresponding script or custom node has been successfully compiled, then refresh the rules engine page.

Canvas Operations

Use Quick Actions for copy, paste, and selection. After copying between flows, check node dependencies, device and variable names, and external connection settings, then validate.

Node Parameters

Node parameters are determined by the node type. Different nodes display different inputs, outputs, and input/output parameters.

Connections bind by port name. State/event semantics, nullability, array shape, and units must agree; use explicit conversion nodes when necessary. Cycles are rejected during validation. Stale save or control revisions require reloading and comparing the current definition before retrying.

Advanced Execution Policy

Select a node, open the Configuration tab, and expand Advanced Execution Policy. These settings govern that node and have no business input ports.

Allow enough total time for processing and backoff. A deadline does not undo a device write or message already sent. Once device writes, MQTT, email, or Webhook operations have started, an unconfirmed outcome can be UnknownEffect; increasing attempts does not blindly resend them. Check the actual device or receiver first. Business rejection, cancellation, and timeout are not general retry conditions.

Runtime Values and Execution Results

Open Runtime and check observation time, current activity, and latest execution result. Diagnostics includes the instance, loaded revision, sequence, execution completion time, execution ID, error code, and counters. Observation time is the sampling time; use execution completion time and result to check the latest input. After reloading, check the new instance and revision; counters belong to that instance. Samples expire after five seconds. Retry observation if the request fails.

Connect ExecutionResult to the execution-error catch node’s Input when an error branch is needed. The catch node ignores Succeeded and Skipped, emitting failures or cancellation. Connect business values separately.

Activity and connection observation

Waiting for trigger means no queued or running work; inspect the node’s waiting condition. Waiting for scheduling means accepted work is queued. Executing includes asynchronous waits. The previous result and current activity are independent: a successful node can currently be waiting.

Select the source node and expand Connection Runtime Details to inspect each target, reason, identity, and time. The last actual delivery result/time remain available after a later skip or unwritten output.

Green lasts three seconds after delivery; dashed green means coalesced, dashed yellow means skipped, red indicates failure, and gray indicates no propagation or activity. Expired samples clear success coloring. One rejected branch does not prevent other targets from receiving, and failures cannot roll back delivered inputs or explicitly committed intermediate output batches.

Import and Export

Use JSON rule packages to back up and exchange flows. Log exports do not restore configurations.

Back up existing flows before replacement. Same-name entries default to skip. Imported flows remain disabled. Deploy and compile required custom nodes first: packages list dependencies but do not contain their DLLs. Restore redacted secrets, validate, save, and explicitly enable each flow after checking devices and receivers. A saved configuration with a runtime reload error still requires investigation.

Nodes and triggers

Timers, state, and events

Use Boolean/JSON event-to-state or state-to-event converters when changing port semantics. Repeated Tick=true events do not require toggling false. Convert Count through Integer to Decimal before decimal calculations. Start with a one-second interval in an isolated disabled flow, validate and save before enabling, inspect downstream execution counts, and disable the practice flow afterward.

Stopping or reloading cancels pending waits and releases schedules. A new instance resets counters and internal state.

Data flow and shared context

Flush, Write, Read, and Remove consume each event regardless of its Boolean payload. Event envelopes carry correlation and sequence separately from their payload.

The default key is shared.value. Keys allow 1–64 ASCII letters, digits, dots, underscores, or hyphens. Each flow instance allows 128 keys, 64 KiB per value, and 1 MiB total. Context, pending joins, and batches are memory state; they are not shared across flows or restored after reload/restart. Send records to a persistent target when retention is required.

Variable, Event, and Writeback Nodes

These nodes consume Gateway variable, alarm, and device-status events directly. Event nodes do not require an upstream input. After the process is enabled, they wait for the corresponding event and emit only when all filters match. Separate multiple names or enum values with commas; leave a filter empty to match all values.

Variable Notification Rule

The Variable Notification Rule node under Trigger listens for value changes from online variables. Use it to feed collection values into threshold checks, recording, or notification flows. A successful match emits both the current value and the complete variable data object.

Offline variables do not trigger this node. Use VariableBasicData when the downstream payload needs the device name, variable name, collection group, online state, change time, or collection time.

Alarm Notification Rule

The Alarm Notification Rule node under Trigger listens for alarm lifecycle events and filters them by level, device, event type, and alarm type. A match emits the original alarm object through FilteredAlarmData.

Device Notification Rule

The Device Notification Rule node under Trigger listens for device-status changes. It is useful for offline alarms, recovery notices, and routing by collection plugin.

Variable RPC Node

The Variable RPC Node calls a variable’s RPC write capability from a rule flow. It resolves the variable by DeviceName and VariableName, converts WriteData to JSON, and invokes the variable runtime RPC. It does not bypass variable permissions or call a driver directly.

Place this node after a rising-edge, button, or interlock check to avoid repeated writes from high-frequency changes. Verify Result, the variable-write log, and the actual device action. Missing variables, disabled permissions, or paused devices produce a failed result.

MQTT Client Upload Node

The Mqtt Client Upload node under Data Push publishes each InputData event as UTF-8 JSON. It supports TCP MQTT and WebSocket MQTT. Initialization does not connect or upload. The first send, a disconnected client, or changed connection settings establish a connection within that execution; failures follow the execution policy.

Parameters

Minimal Setup and Verification

1. Drag in the node and fill in Url and Topic; add credentials if the broker requires them.
2. Connect the payload output to InputData, check the indicated type and event semantics, and connect ExecutionResult to an execution-error catch node.
3. Subscribe to the topic with an independent MQTT client first. Save and enable the process, then trigger a recognizable new payload.
4. Confirm Succeeded for this execution on the Runtime tab and verify the topic, JSON, and QoS at the subscriber. With Retain=false, subscribing after publishing misses that message.

For failures, inspect the latest execution status, error code, and runtime log. If the result is UnknownEffect, check subscriber records before deciding whether to resend.

Email Push Node

The Email Push node under Data Push sends rule data through SMTP after receiving a Data event. It prepares the SMTP channel on the first send or after mail settings change. Sending is subject to the total execution deadline.

Parameters

Minimal Setup and Verification

1. Fill in the SMTP host, port, credentials, sender, and at least one recipient.
2. Connect the alarm notification rule’s FilteredAlarmData event output to Data. For a variable notification snapshot, insert JSON State to Event first.
3. Adjust the subject or body template for the receiver, then save and enable the process.
4. Connect ExecutionResult to an execution-error catch node and trigger a test event. Confirm Succeeded and an advancing LastPushTime on the Runtime tab, then check substituted fields and formatting in the mailbox.

For authentication, certificate, or recipient errors, inspect the latest execution status and error code, then check the server port, SSL mode, and sender policy. Do not record passwords in rule logs or public documentation.

Webhook Push Node

The Webhook Push node under Data Push sends rule results to a DingTalk custom robot, a WeCom message-push webhook (formerly group robot), or a custom HTTP endpoint. Platform is an explicit selector in the properties panel; the node does not infer a vendor from the URL.

Parameters

Placeholders inside JSON strings escape quotes, backslashes, and line breaks. Placeholders used as JSON values preserve number, Boolean, array, or object types. A missing property becomes empty text inside a string and null in a value position.

When an Alarm Notification Rule feeds Data, use the following template for a custom HTTP endpoint. Alarm records expose Name for the variable name and AlarmCode for the trigger value; Value belongs to ordinary variable notifications.

{
  "device": "{{DeviceName}}",
  "variable": "{{Name}}",
  "message": "{{AlarmText}}",
  "level": {{AlarmLevel}},
  "value": {{AlarmCode}}
}

This is template text awaiting substitution. With level 1 and alarm value 101, level becomes the number 1, while value becomes the string "101": AlarmCode is a text field. An unquoted placeholder does not convert a string property into a number.

Connect the payload to Data and ExecutionResult to an execution-error catch node. Prepare the receiver, enable the flow, and trigger a recognizable new event. On the Runtime tab, verify the current execution ID, Succeeded, and an advancing LastPushTime, then check the body at the HTTP receiver or messaging client. An initialization timestamp or previous success does not prove this send.

DingTalk

1. Set Platform to DingTalk.
2. Enter the complete https://oapi.dingtalk.com/robot/send?access_token=<robot-token> URL in Url.
3. Fill in Secret only when the robot uses signing; leave it empty for keyword or IP allowlist security.
4. For a text message, enter this body with {{Name}} as the alarm variable name:

{
  "msgtype": "text",
  "text": {
    "content": "Device: {{DeviceName}}\nVariable: {{Name}}\nAlarm: {{AlarmText}}\nValue: {{AlarmCode}}"
  }
}

For DingTalk Markdown, use:

{
  "msgtype": "markdown",
  "markdown": {
    "title": "Gateway alarm",
    "text": "## {{DeviceName}}\n\n{{AlarmText}}"
  }
}

The node appends timestamp and sign using DingTalk HmacSHA256 rules. Do not add them manually. After HTTP 2xx, it also checks the JSON response; a confirmed successful send requires numeric errcode 0 (or the string "0").

WeCom

1. Set Platform to WeCom.
2. Enter the complete https://qyapi.weixin.qq.com/cgi-bin/webhook/send?key=<message-key> URL in Url.
3. Leave Secret empty. Use the same text.content body shown above and check the variable name and alarm value.
4. WeCom Markdown uses markdown.content, not DingTalk’s title and text fields:

{
  "msgtype": "markdown",
  "markdown": {
    "content": "# {{DeviceName}}\n{{AlarmText}}"
  }
}

The node requires HTTP 2xx and a WeCom response with an integer errcode of 0 before confirming a successful send.

Frequency and Security

DingTalk robots and WeCom message webhooks are limited to 20 messages per minute. For high-frequency variables, add an edge, threshold, hold, timer, or aggregation node before Webhook and send a summary. Webhook URLs contain credentials; do not put them in logs, screenshots, public documentation, or source control.

Trigger Method

Run and verify

Runlog

Rule Flow After running, you can view the runtime log at the bottom of the editor.

Runtime checks after enabling

1. Check the loaded revision.
2. Trigger the flow with safe test values and inspect node runtime values from upstream to downstream.
3. Check trigger time, execution path, outputs, and errors in runtime logs.
4. Confirm the result at the destination, such as a memory variable, alarm, message target, or external endpoint.

Verify the complete flow

Within one filter, multiple names form the permitted set; different filters are combined with AND. Limit notification sources before enabling control. Result from a variable notification is its value; VariableBasicData is the full identity/quality/time snapshot. Use numeric extraction before numeric comparison where needed.

Set comparison B to 100, connect upstream A, and verify 101, 99, 100 produce true, false, false. A connected input comes from upstream rather than its configured initial value. Check execution time even when output remains equal. Test both conditional branches with distinct outputs.

Variable RPC Result is the business write result; ExecutionResult is the node execution event. Verify both and read the real source back. Device/target special-method nodes resolve by name or accurate ID, with nonzero ID taking priority. Reselect methods after changing the object, follow their argument arrays, and distinguish method effects from normal polling/upload.

State outputs propagate changes by default; event outputs can repeat equal payloads. Choose continuous state or edge behavior deliberately to control repeated writes.

Hysteresis fan control

Connect scoped temperature notification → numeric extraction → threshold → fan variable RPC. Use Threshold=75, Hysteresis=5, and CompareOperator=>; connect Triggered to WriteData.

Starting off, 85 turns on, 75 keeps on, 65 turns off, and 75 keeps off. Hysteresis expands around the center: with strict >, exactly 80 does not enter from off and exactly 70 exits from on. Reload creates new state; inspect startup and the first notification. Verify the real coil and gateway readback. See Project Delivery.

Disable the practice flow before restoring temperature and fan state, so restoration does not trigger another control action.

Common Process Design

Use and troubleshoot

Fault Handling

Related Links

• Collection Configuration - Channel, Device, Variable Configuration
• Memory Calculation - Common Memory Variables for Maintenance Rule Flow
• Custom Nodes - Custom Node Management
• Script Management - Script Development and Management