Data Forwarding Manual

Data forwarding sends collected variables, device status, alarms, and plugin events to external systems or internal real-time/history targets. The page is organized as "forwarding group + forwarding target": the group defines data range and trigger behavior, while the target defines destination plugin and connection parameters.

Area	Description
Forwarding groups	Upper-left list. Add, edit, delete, enable, disable, or restart groups.
Forwarding targets	Lower-left list under the selected group. The list shows a selected-group hint so operators can confirm the target belongs to the intended group before adding, editing, or configuring variable properties.
Detail area	Right side: details, group logs, target logs, and debug.
Refresh interval	Controls automatic detail refresh.

Configuration Flow

1. Confirm the target plugin is enabled in plugin management.
2. Create a forwarding group and define variable range, trigger mode, online filtering, and batching.
3. For manual range, maintain group variables.
4. Create one or more forwarding targets under the group.
5. Configure target variable properties if the external system requires per-variable mappings.
6. Enable group and target, then observe status and logs.
7. Use the Debug tab to validate MQTT, Kafka, RabbitMQ, or server behavior.

Forwarding Group

Field	Description
Name	Group name. Use a business-readable name.
Enable	Whether the group participates in runtime forwarding.
Log level	Group log verbosity. Use Debug/Trace only while troubleshooting.
Variable range	All variables, manual selection, collection device, or collection group.
Range configuration	Device/group names when range is device or collection group.
Trigger mode	Change, interval, or interval/change.
Interval	Used when interval triggering is enabled.
Online filter	Forward only variables from online devices.
Batch mode	Batch by data group, device, collection group, or plugin-supported strategy.
Max batch size	Limit variables per batch.
Atomic enqueue	Enqueue the whole batch together.

Forwarding Target

Select a forwarding group first, then add or edit targets in the target list. A target only consumes variables matched by its own group and does not read variables from other groups.

Field	Description
Forwarding group	The group that owns this target.
Target name	Unique within a forwarding group.
Enable	Only enabled targets enter runtime and show the corresponding debug page.
Plugin	Destination plugin, such as MQTT, Kafka, RabbitMQ, Webhook, ModbusSlave, or OpcUaServer.
Log level	Target log verbosity.
Startup timeout	Time allowed for initialization.
Plugin properties	Dynamic fields from the selected plugin.
Redundancy	Optional standby target and failover policy.

Runtime Diagnostics And CacheDB Outbox

After enabling a forwarding group and target, the target card and detail area show the current in-memory runtime summary. Use this area to confirm whether the plugin instance was created, initialized, started, and connected, and whether offline cache data is still waiting to be resent.

Item	Description
Plugin runtime	Shows instance creation, runtime type, start state, initialization state, scheduler state, visible variable count, visible device count, channel type, and channel online state.
Online state	Shows the target or inner channel online state. Interpret it together with recent errors and target logs because different plugins detect online state differently.
Reliable History	Historical data and historical alarm targets show support state, Journal target keys, and unsupported reason. Only supported standard SQL write paths participate in redundant historical replay and de-duplication.
CacheDB outbox	Shows model count, memory queue, CacheDB pending count, retained retry count, oldest pending time, and errors for targets that use offline cache. A continuously growing backlog means the destination is unavailable or cannot consume data fast enough.
Last active / last error	Use these fields to determine the last successful processing time and the latest runtime error before exporting target logs.

An empty CacheDB outbox only means there is no pending resend data. It does not prove that the external system is online, so check online state, recent errors, and the debug tab together.

MQTT Target

Field	Description
IP / Port	MQTT Broker host and port.
Connection Type / WebSocket Path	TCP or WebSocket connection settings.
Client ID / Keep Alive / Clean Session	MQTT client identity and session behavior.
Enable SSL / TLS Certificates	TLS switch, target host, client certificate, CA, protocol, and certificate revocation options.
Username / Password	Broker credentials.
QoS Level / Retain	Default publish QoS and retain flag.
Device / Variable / Alarm / Plugin Event Topic Templates	Topic templates for different data categories.
JSON options	Formatting, null handling, and upload structure options.
Cache and queue	Offline cache, max cache file length, split size, queue count, and concurrency.

Kafka and RabbitMQ Targets

Target	Important fields
Kafka	Service address, publish timeout, security protocol, SASL mechanism, username, password, topic templates, cache, and queue settings.
RabbitMQ	IP, port, username, password, virtual host, exchange name, exchange type, queue/exchange declaration flags, timeout, templates, cache and queue settings.

Historical SQL Targets And Reliable History

Historical data targets write variable history for reports, trends, and traceability. Historical alarm targets write alarm and recovery events for audit and analysis. When gateway redundancy is enabled and historical reliable sync remains enabled, supported standard SQL targets are written through a Journal, peer acknowledgment, target-database Epoch leases, and record keys that avoid duplicated inserts during failover or replay.

Check	Description
Supported target types	Historical data targets and historical alarm targets.
Supported databases	SqlServer, MySql, Sqlite, and PostgreSql through the standard write path.
Required write mode	Do not enable custom SQL mode or historical table scripts for targets that must participate in reliable history.
Offline cache	Keep offline cache enabled for high-traceability targets and size CacheDB plus Journal capacity for the expected outage duration.
Diagnostics	Check the target detail Reliable History tag and Journal target keys. For pending peer sync, pending database writes, or event-level troubleshooting, open System Management > System Settings > Hot Standby and use the Historical-Data Protection area.

Dual-Database Mirroring

Historical data and historical alarm targets can enable Dual-Database Mirroring for coordinated writes and consistency maintenance across a primary and secondary database. Prepare two independent physical database destinations first, and verify table structure, account permissions, connectivity, and long-term disk capacity.

Setting	Description
Enable	Enable dual writes, Journal handling, and consistency maintenance. When disabled, the target writes only to the primary database.
Secondary database type / connection	Select and connect the secondary database. Primary and secondary must be different physical databases, not equivalent connection strings to the same instance, file, or target.
Journal max pending rows	Cap events not yet committed to both databases. Size it for peak write volume and the longest expected outage, with enough local disk capacity.
Peer pending limit	Cap events visible in one database but not yet copied to the other. A sustained high value indicates connectivity, permission, or write-performance problems.
Consistency interval	Compare both databases periodically in minutes; 0 disables scheduled checks. Large time ranges and high write volume add database load.
Automatic repair	Fill missing records in both directions after a scheduled check. Before production use, validate structure, time range, and permissions with a manual comparison and repair.

Target details show primary, secondary, Journal, and backlog status. You can compare a selected time range and repair missing records from primary to secondary or secondary to primary. Confirm the direction before a manual repair so that the wrong side is not treated as authoritative.

Support boundary

Mirroring supports only standard historical-data and historical-alarm tables on SqlServer, MySql, Sqlite, and PostgreSql. QuestDB, TDengine, custom SQL mode, historical table scripts, and historical alarm table scripts are unsupported. Mirroring protects two database copies for one forwarding target; hot-standby historical compensation protects pending writes between two gateway nodes. They are independent and can be enabled separately.

Target Variable Properties

Field	Description
Variable	Variable to map or override for this target.
Plugin variable properties	Dynamic fields provided by the target plugin.
Add/update variable property	Save the selected variable's target-specific mapping.
Configured variable list	Existing per-variable target properties.

For manual variable ranges, add the variable to the forwarding group's variable list before saving target variable properties. Target variable properties describe how a target uses a variable; they do not add the variable to the group by themselves.

Debug Targets

Debug type	Purpose
MQTT Client	Publish messages, subscribe/unsubscribe topics, inspect message log.
MQTT Server	Publish messages, inspect topic statistics and connected clients.
Kafka	Publish a test message to a Topic.
RabbitMQ	Publish a test message with a Routing Key.

Troubleshooting

Symptom	Suggested action
Target does not start	Check group/target enable flags, plugin status, and connection parameters.
No data is forwarded	Check variable range, variable enable state, trigger mode, online filter, and group variables.
MQTT publish fails	Check Broker, port, TLS, credentials, Topic permission, and target logs.
Kafka publish fails	Check bootstrap servers, security protocol, authentication, Topic permission, and timeout.
RabbitMQ publish fails	Check exchange, routing key, virtual host, queue bindings, and credentials.
CacheDB backlog keeps growing	Check destination availability, target online state, upload split size, concurrency, rate limits, target logs, and remaining disk space.
Reliable History is unsupported	Confirm the target is a historical data/alarm target, the database is SqlServer/MySql/Sqlite/PostgreSql, and custom SQL or table scripts are not enabled.
Historical-data protection has pending peer-sync/database-write rows	Filter by Journal target key under System Settings > Hot Standby > Historical-Data Protection, then check peer links, target database connectivity, database-write authorization, and offline-cache recovery.
Debug tab is empty	Select an enabled runtime target. Disabled targets do not show debug pages.