Software Version: V2.1.6.0

Document Version: V1.2

About This Document

This document explains how to install, configure, operate, and maintain E2C Factory. It helps users complete common tasks for Data Collection, Data to Cloud, Data Forwarding, automation and control, Alarm Management, Data Management, visual analysis, and system administration.

www.robustel.com

Copyright © 2021 Guangzhou Robustel Co., Ltd. All rights reserved.

Trademark Notice: Robustel is a trademark of Guangzhou Robustel Co., Ltd. Other trademarks and trade names mentioned in this manual belong to their respective owners.

Disclaimer: No part of this document may be reproduced in any form without permission from the copyright owner. Because products, designs, and manufacturing processes are continuously improved, this document may be updated or revised without prior notice.

Version History

Terms and Abbreviations

Software Terms

Industry Terms and Abbreviations

1. Product Overview

1.1 Product Introduction

E2C Factory is industrial edge data software within the E2C Trinity product family, designed for factory and automation environments and running on compatible Robustel edge computing gateways. It connects PLCs, controllers, sensors, and meters across different vendors and protocols, and provides field data collection, processing, storage, visualization, and system integration. This creates a unified data foundation for production monitoring, equipment maintenance, efficiency analysis, and integration with SCADA, MES, ERP, and cloud platforms.

1.2 6C Core Capabilities

Built on E2C Trinity’s 6C edge computing capabilities, E2C Factory establishes a complete data flow from field equipment to business systems:

• Collect: Connect PLCs, controllers, sensors, and meters across different vendors and protocols, bringing scattered field data together.
• Compute: Perform data processing, logic evaluation, and automation orchestration at the site, enabling faster response and reducing reliance on the cloud and central servers.
• Continuity: Use local storage and store-and-forward mechanisms to retain relevant data during network interruptions and continue uploading it after connectivity is restored.
• Canvas: Present equipment status, alarms, trends, and production efficiency through Web SCADA, charts, and OEE dashboards, providing clear visibility into site operations.
• Connect: Deliver processed data to SCADA, MES, ERP, MQTT Brokers, and cloud platforms, connecting field equipment with upper-level business systems.
• Control: Trigger tag value updates and equipment control through local rules, alarm events, or cloud commands, creating a closed loop from data collection to operational response.

1.3 Typical Application Scenarios

Lightweight Digitalization for Factories

Suitable for discrete manufacturing, injection molding, packaging, food processing, and component production. By collecting equipment status, alarms, and production data through a unified approach, users can gradually establish operational monitoring and OEE analysis to improve production visibility.

Digital Services for Machine Manufacturers

Suitable for manufacturers of injection molding machines, air compressors, packaging equipment, industrial robots, and other machinery. Adding data collection, operational monitoring, alarms, and integration capabilities provides a data foundation for post-delivery troubleshooting, maintenance services, and value-added digital applications.

Edge Data Processing and System Integration

Suitable for projects that need to connect field equipment to SCADA, MES, ERP, or cloud platforms. Data can be organized, calculated, filtered, and stored locally before the required information is delivered to the target system, reducing unnecessary data transmission and repeated integration work.

2. Software Architecture and Deployment Planning

2.1 Supported Hardware Models

The gateway that runs the software must meet the following model, RobustOS Pro firmware, and RAM requirements.

2.1.1 Supported Gateways and Minimum Firmware Versions

2.1.2 RAM

The gateway must have at least 2 GB of RAM.

2.2 Software Architecture and Working Principle

Figure 2-1 E2C Factory software architecture

E2C Factory establishes a data path between field devices and upper-level systems:

• Southbound device connectivity: Use the applicable Drivers to connect PLCs, controllers, sensors, meters, OPC Servers, databases, or other data sources.
• Edge processing and applications: Perform Data Management, Alarm Management, Logic Orchestration, Scenario Management, SCADA, and OEE tasks on the gateway.
• Northbound system integration: Use Data to Cloud or Data Forwarding to provide data to cloud platforms, SCADA, MES, BMS, ERP, or other clients.

See the applicable functional chapters for supported protocols, configuration procedures, and validation methods.

3. Installation, Upgrade, and Licensing

3.1 Pre-installation Check

Figure 3-1 Gateway information used for the pre-installation check

1. Connect the management computer to the gateway network and ensure that the computer and gateway are on the same subnet.
2. Open a browser, go to the default gateway management address http://192.168.0.1, and log in to the gateway web interface. Google Chrome is recommended.
3. Check the gateway model, RobustOS Pro firmware version, and RAM on the home page, and compare them with the requirements in Section 2.1, “Supported Hardware Models.”
4. If the firmware version is earlier than the minimum version required for the gateway model, visit the Robustel Support Center and find the RobustOS Pro upgrade guide applicable to the gateway model and current version.

Notice: Before upgrading the firmware, read the RobustOS Pro upgrade guide applicable to the gateway model and current version. Follow that guide for compatibility, configuration retention, restart, downtime, and recovery requirements.

3.1.1 Confirm the Gateway Time

E2C Factory uses the RobustOS Pro system time and does not maintain a separate clock. Before using this system for the first time, confirm that the gateway time zone and system time are correct.

An incorrect gateway time can cause incorrect timestamps or time displays in Data Collection, Data Management, Data to Cloud, Data Forwarding, and other functions. It can also affect time-based statistics and calculations, resulting in abnormal durations or even negative values. Set the correct time before collecting, archiving, reporting, or forwarding production data.

Log in to the RobustOS Pro web interface, go to Services > NTP, and configure the time according to the gateway's network environment:

• The gateway can access an NTP server: Select the Time Zone for the project location, enable the NTP client, and configure an NTP server accessible to the gateway. The default NTP Update Interval value of 0 synchronizes the time only once. An interval of 30 min is recommended for periodic synchronization. After submitting the configuration, open the Status tab and confirm that System Time and Last Update Time are correct.

Figure 3-2 NTP client configuration for an online gateway

• The gateway cannot access an NTP server: First confirm that the date, time, and time zone of the management computer are correct. Open the Status tab and click Sync to synchronize the gateway with the computer time. For a gateway operating offline for an extended period, check the system time regularly and synchronize it manually if a time difference is found.

Figure 3-3 Manual time synchronization for an offline gateway

Notice: Set the correct time before production data is generated whenever possible. If the gateway time is changed during operation, check the latest data and any time-based calculation results.

3.2 Install or Upgrade the Software

The software covered by this manual and its installation requirements are as follows:

Download all of the above software from the E2C Factory APP Download page. Uploading a package for the first time installs the software. If an earlier version is already installed, upload the new package directly to upgrade it. Installation and upgrade use the same entry and procedure.

3.2.1 Before You Start

• Confirm that the gateway meets the requirements in Section 2.1, “Supported Hardware Models,” and complete Section 3.1, “Pre-installation Check.”
• Download the package to install or upgrade from the E2C Factory APP Download page.
• Confirm that the management computer can access the gateway web interface.

Warning: Do not power off the gateway, close the current page, or submit the installation operation again during installation or restart.

Notice: To upgrade the software, upload the new package directly and install it over the existing version. Existing E2C Factory data is retained. Do not uninstall the earlier version first. Reinstalling after uninstallation deletes the existing data.

3.2.2 Installation or Upgrade Steps

Figure 3-4 Install software in App Center

1. Log in to the gateway web interface and go to [System] > [App Center].
2. Select the package to install or upgrade, and then click [Install].
3. Follow the on-screen prompt to confirm the installation.
4. When the restart prompt appears after installation, click [OK] to restart the gateway immediately.
5. After the gateway restarts, log in again. If other software must be installed or upgraded, repeat the same steps.

After installation, see “Getting Started with E2C Factory” for instructions on opening E2C Factory and using the main interface.

3.3 View or Upgrade the License

Figure 3-5 License Activation page

The gateway includes the Free Edition of E2C Factory by default. You can use the functions included in the Free Edition without uploading a license file. A software upgrade updates the E2C Factory version. A license upgrade increases Device or Tag capacity, protocols, or features. One does not replace the other.

3.3.1 View the Current License

Go to [System Settings] > [License Activation] and review the following information:

3.3.2 Upgrade the License

If the current license does not provide the required Device capacity, Tag capacity, protocols, or features, purchase and activate a new license to increase the available entitlements.

1. Provide the [Device Serial Number (SN)] shown on the [License Activation] page to the software supplier and obtain a license file.
2. Upload the license file on the [License Activation] page.
3. Click [Confirm Activation].
4. After the new license is activated, verify the displayed [License Version] and [Current Entitlements].

3.4 Uninstall the Software

When E2C Factory is no longer required, uninstall it through the gateway web interface.

Warning: Uninstalling E2C Factory deletes its existing data. Do not uninstall the application if you still need this data.

3.4.1 Uninstallation Steps

1. Log in to the gateway web interface.
2. Go to [System] > [App Center].
3. Locate e2c-factory in the installed application list, and then click [X].
4. Follow the on-screen prompt to confirm the uninstallation.
5. When the operation is complete, return to [System] > [App Center] and confirm that e2c-factory is no longer displayed.

4. Getting Started with E2C Factory

This chapter explains how to open E2C Factory, complete the initial setup, and use the global functions of the main interface.

4.1 Open E2C Factory

Figure 4-1 Open E2C Factory from the gateway management interface

Before you begin, make sure that E2C Factory is installed and enabled.

1. Log in to the gateway management interface.
2. Locate [Edge Computing] in the left or top navigation area.
3. Open E2C Factory.

The E2C Factory operation page opens in a new browser tab.

4.2 Select the License Region on First Access

Domestic and overseas markets use different license editions and entitlement systems. When you open E2C Factory for the first time, the system displays the License Region selection window.

1. Select the License Region for the market where the project is located.
2. Follow the on-screen prompt to confirm the selection.
3. After initialization is complete, the main interface opens.

Notice: The License Region cannot be changed directly in the system after confirmation. To change it, upgrade the license.

4.3 Understand the Main Interface

The main interface contains the following global areas:

Figure 4-2 E2C Factory main interface areas

• Application entry area: Located on the left side of the top bar. It currently contains E2C Factory and Data Analytics. After you select an application, the menus for that application appear on the left side of the page.
• Menu navigation area: Located on the left side of the page. Use it to open features in the current application. E2C Factory provides menus such as Data Collection, Data to Cloud, Scenario Management, and System Settings. Data Analytics provides SCADA Management, Device OEE Dashboard, and OEE Statistics Config.
• Workspace: Displays the list, configuration form, status, or operation result for the selected feature.
• User and language area: Located in the upper-right corner. Use it to view the current account information, open common entries, log out, or change the interface language.

The available menus vary with the software license. A menu is not displayed when its feature is not included in the current license.

4.4 Use the User Menu

Open the user menu in the upper-right corner to view the current account and software information and access common entries.

4.5 Switch the Interface Language

The current interface language is displayed in the upper-right corner. E2C Factory supports English and Chinese.

5. Quick Start

This section uses a minimum example to complete the closed loop from collecting Modbus inlet pressure data to reporting it through MQTT. When complete, this system collects one inlet pressure Tag from a Modbus TCP Device, adds the Tag to a Tag Group, and reports it to an MQTT Broker through Standard MQTT.

Both real and simulated environments can be used in this section. If a real Device or MQTT service is available, use its actual parameters. Otherwise, use the suggested simulation tools to complete the initial functional validation.

5.1 Before You Begin

Connect the computer to the network of the gateway LAN interface and make sure that the computer and gateway can communicate. This example assumes that the computer address is 192.168.0.89 and that the gateway uses its default address, 192.168.0.1.

Prepare the following items according to the environment being used:

• When using a real Device, prepare a Modbus TCP Device that the gateway can access, together with its IP Address, Port, Slave Address, and Tag address table.
• When using a real MQTT service, prepare an MQTT Broker address and Port accessible from the gateway, the MQTT Client ID requirements, and any User Authentication and SSL/TLS Encryption requirements.
• When no real Device or MQTT service is available, use the tools in the following table to prepare a simulation environment. These tools are used only for functional validation. They are not required software for this system and do not replace Devices or cloud platforms in a production environment.

Prepare only the tools required for the selected validation path. If a real Modbus TCP Device is available, skip PeakHMI. If a real MQTT Broker and data receiver are available, skip Mosquitto and MQTTX.

5.2 Configuration Workflow

Complete the following three main tasks:

1. Complete Data Collection: Add one Modbus TCP Device and one Tag in this system, publish the configuration, and confirm that valid data is collected continuously.
2. Create a Tag Group: Add the published Tag to a Tag Group to use it as the Data to Cloud source, and configure the reporting method and interval.
3. Complete Data to Cloud: Connect to a Standard MQTT service, configure a Publish message, and confirm that the reported data is received at the MQTT Broker data receiver.

5.3 Collect One Modbus TCP Tag

This section uses inlet pressure as the example Tag. If a real Modbus TCP Device is available for testing, skip Section 5.3.1 and use the actual Device connection parameters and Tag address in the following configuration. To avoid affecting production equipment, select a Tag that can be read safely and whose value can be checked easily.

If no real Device is available, prepare simulated data as described in Section 5.3.1 before configuring this system.

5.3.1 Prepare Simulated Modbus TCP Data (Optional)

1. Install and start PeakHMI MB TCP Slave on the computer at 192.168.0.89.
2. Click [Windows] in the top menu bar, and then select [Register Data] to open the data list.
3. Locate 400001 on the left side of the list and enter an easily recognizable test value, such as 20, in the corresponding value cell.
4. Keep PeakHMI MB TCP Slave running. This system will read the value through Port 502 and Slave Address 1 in the following steps.

These parameters are used only in this example. In the following configuration, enter the corresponding values directly as shown in the tables. You do not need to understand the internal data structure of the simulator first.

5.3.2 Add a Modbus TCP Device

Figure 5-1 Modbus TCP Device configuration in Quick Start

Go to [Data Collection] > [Device], click [Add], select Modbus TCP, complete the form as follows, and then click [Save and Configure Tag].

5.3.3 Add an Inlet Pressure Tag

In the Tag list of Modbus_Simulator, click [Add], complete the form as follows, and then click [Save].

If the real Device does not have inlet pressure data, select another read-only Tag whose value can be checked easily, and replace the example Name, Function Code, Address, and Data Type with the actual parameters.

5.3.4 Publish and Validate Collected Data

Click [Publish] in the upper-right corner of the page to apply the new Device and Tag configuration. After a Device or Tag configuration is changed, publish it again for the new Data Collection configuration to take effect in the runtime environment.

Figure 5-2 Tag status, latest value, and update time

1. In the Device list, confirm that the collection status of Modbus_Simulator is normal.
2. Open its Tag list, confirm that Inlet_Pressure has a [Latest Value], and check that the update time continues to refresh.
3. When using the simulator, change the value corresponding to 400001 in PeakHMI from 20 to another value. When using a real Device, change or observe the corresponding Tag only when it is safe to do so.
4. Wait for one or more polling cycles and confirm that the [Latest Value] of Inlet_Pressure follows the data source.

When the validation succeeds, Data Collection is operating correctly and you can continue to create the Tag Group. Do not continue with Data to Cloud while the collected data is invalid. Otherwise, the MQTT connection may be normal while no valid data is available for reporting.

If no data is displayed or the value is incorrect, check whether the data source is running, whether the network between the gateway and Device is reachable, and whether the IP Address, Port, Slave Address, Function Code, Address, and Data Type are correct. If the cause is still unclear, go to [Debug Logs] and review the collection information.

5.4 Configure MQTT Reporting and Validate Data

This section reports the collected Inlet_Pressure through Standard MQTT. Before configuring the system, select the MQTT environment:

• If a real MQTT Broker or target platform supporting Standard MQTT is available, skip Section 5.4.1 and enter the actual connection and security parameters provided by the target service when creating the Cloud Service.
• If no real MQTT service is available, use Mosquitto and MQTTX to prepare a test environment as described in Section 5.4.1. This environment is used only to validate the data path and does not represent a production cloud platform or deployment.

5.4.1 Prepare an MQTT Test Environment (Optional)

This manual uses Mosquitto 2.0.20 on a Windows x64 computer as the example. Download and install mosquitto-2.0.20-install-windows-x64.exe. This installation package includes the test configuration required for this example.

After installation, open the Mosquitto installation directory, hold down Shift, right-click an empty area, and select [Open PowerShell window here]. Paste the following command into PowerShell and press Enter:

1 .\mosquitto.exe -c .\mosquitto.conf -v

Keep the PowerShell window open. If Port 1883 is already in use, a Mosquitto service or another application may already be using the Port. Stop the duplicate Mosquitto service or process and try again.

Start MQTTX, create a connection, and enter the following information:

Click [Connect]. A successful connection indicates that MQTTX has connected to Mosquitto running on the local computer. Keep Mosquitto running. MQTTX can remain connected or reconnect after the Publish message has been configured.

Because MQTTX and Mosquitto run on the same computer, MQTTX can use localhost. This system runs on the gateway, so [Server Address] must be set to the LAN IP address of the computer that is accessible from the gateway. This example uses 192.168.0.89. Do not enter localhost or 127.0.0.1.

For other operating systems or hardware architectures, download the appropriate version from the Mosquitto website and follow its official instructions for installation, startup, and network access. The default configuration of Mosquitto 2.x may accept local connections only. When using a version downloaded from the official website, confirm that its listener and access settings allow the gateway to connect over the LAN. Configuration of other versions is outside the scope of this manual.

The Mosquitto configuration provided for this example is intended only for temporary functional testing on a controlled network. Do not use it directly in a production environment. Stop Mosquitto after testing.

5.4.2 Create a Tag Group

Figure 5-3 Tag Group configuration in Quick Start

Go to [Data to Cloud] > [Tag Group], click [Create Group], complete the form as follows, and then click [Save].

After the first save, locate Modbus_Simulator in the Tag selection window, add the published Inlet_Pressure to Group_01, and then click [Save] again. The Tag Group takes effect when saved and does not need to be published separately.

When using a real Device, select the actual Tag that passed the Data Collection validation in Section 5.3. Duplicate Tag names are not allowed within the same Tag Group because the receiver would not be able to identify the data accurately by name.

5.4.3 Create a Standard MQTT Cloud Service

Figure 5-4 Create a Standard MQTT Cloud Service in Quick Start

Go to [Data to Cloud], click [Create Cloud Service], set [Cloud Service Type] to MQTT, enter MQTT_Service_01 as the [Cloud Service Name], and click [Save]. Select the new Cloud Service, complete [Connection Configuration] as follows, and save the configuration.

The [User Authentication] and [SSL/TLS] values above apply only to the local simulation environment. They are not default recommendations for production deployment. When connecting to a real MQTT Broker or cloud platform, follow the connection parameters and security requirements provided by the target service instead of copying the Off settings from this example.

After saving, confirm that the Cloud Service is enabled and check its connection status. A [Connected] status confirms only that this system is connected to the MQTT Broker. It does not confirm that Inlet_Pressure is being reported. Complete the Publish message configuration in the next section.

If the connection fails, check the Server Address and Port, confirm that the gateway can access the target address and that the target Port is open, and verify that User Authentication, SSL/TLS, and the MQTT version meet the Broker requirements.

5.4.4 Configure a Publish Message and Validate Data

Figure 5-5 Standard MQTT Publish message configuration in Quick Start

In [Message Management] for MQTT_Service_01, select [Publish], click [Add], complete the form as follows, and then click [Save].

Do not configure a Subtopic in this example. Keep the default values for the other fields. After saving, confirm that the Publish message is enabled.

Validate Reported Data

1. When using the Mosquitto test environment, connect MQTTX to the corresponding Broker and subscribe to /factory/line1/inlet-pressure. Keep the Client ID automatically generated by MQTTX and confirm that it is different from E2C_Gateway_01 used by this system.
2. When using a real MQTT service, subscribe to or view the same Topic in the target platform, actual MQTT client, or data-viewing page provided by the platform.
3. Wait for at least one complete reporting interval and confirm that the received message contains Inlet_Pressure and its value.
4. When using the simulator, change the value corresponding to 400001 in PeakHMI. When using a real Device, change or observe the corresponding Tag only when it is safe to do so.
5. Confirm again that the Inlet_Pressure value received by the receiver follows the data source.

You have now completed the minimum closed loop: collect one Modbus TCP Tag, create a Tag Group, report the Tag through Standard MQTT, and validate the data at the receiver.

If the Cloud Service is connected but no message is received, first return to the Tag list and confirm that the live data of Inlet_Pressure is valid. Then check that [Data Source Type] is set to [Tag Data], [Group] is set to Group_01, the Publish message is enabled, the Publish Topic exactly matches the subscribed Topic, and the Report Type and Report Interval of the Tag Group are correct. Finally, confirm that the receiver is connected to the same MQTT Broker and that the Client ID automatically generated by MQTTX does not duplicate E2C_Gateway_01.

PeakHMI, Mosquitto, and MQTTX are used in this section only for initial functional validation. For production deployment, use the actual field Device and target MQTT Broker or cloud platform, and redefine the Tag, Report Interval, Topic, QoS, User Authentication, and SSL/TLS according to the project requirements. For MQTT subscription, Tag writeback, certificate configuration, and more detailed validation and troubleshooting, see [7.6 MQTT Cloud Service].

6. Data Collection

Data Collection connects the gateway to southbound devices and reads or writes Tags through the selected Driver.

Supported Protocols

The following sections describe the common configuration workflow for all collection Drivers. For connection parameters, Tag addresses, and detailed configuration instructions for a specific Driver, select the applicable protocol in the E2C Factory How To.

6.1 Before You Begin

• Make sure the southbound device is powered on and connected to the gateway through Ethernet, a serial port, or the required physical interface.
• Prepare the device Driver, connection parameters, and Tag address list. The device and Tag fields vary by Driver.
• Make sure network addresses, serial settings, unit IDs, Tag addresses, and data types match the field device.

6.2 General Configuration Workflow

1. Create a Device and add Tags, save the settings, and publish the configuration.
2. Check the Device Status and real-time Tag data.

6.3 Create a Device

Figure 6-1 Add Device page

1. Go to Data Collection > Device.
2. Click Add.
3. Select the Driver and enter the device name and connection parameters required by that Driver.
4. Click Save. To add Tags immediately, click Save and Configure Tag.

Configuration notes:

• The device name must be unique and cannot contain special characters or spaces.
• Each Driver requires different connection parameters. For example, Modbus TCP and OPC UA use different connection information. Use the field device parameters and the form displayed for the selected Driver.

6.4 Add Tags

The system supports two ways to add Tags: adding them individually (Section 6.4.1) and adding them in batches (Section 6.4.2).

6.4.1 Add Tags Individually

1. Select the target Device under Data Collection > Device.
2. Click Add above the Tag list.
3. Enter the Tag information required by the selected Driver.
4. Click Save.

6.4.2 Import a Point Table

Figure 6-2 Import dialog

Importing a point table allows you to add, update, or delete multiple Tags for the selected Device. Because Tag fields vary by Driver, use a point table that matches the Driver of the target Device.

1. Go to Data Collection > Device, select the target Device, and click Import.
2. If you already have a point table for the current Driver and software version, select that file. Otherwise, click Click to download the import template to download a template from the current system.
3. Complete the template, upload the file using Select File, and click Next Step.
4. Select Add Tags, Update Tags, or Delete Tags as required. You can select all three operations for the same import.
5. Start the import and review the result. The system processes valid entries and reports the Tags that were added, updated, deleted, skipped, or rejected. An invalid entry does not prevent other valid entries from being imported. Correct the reported rows and import the file again if necessary.

Import operations:

Point table rules:

• Download a new template from the software version currently in use. A template from an earlier version may not match the current fields.
• The point table must match the Driver of the target Device. Do not use a template created for another Driver.
• Chinese and English templates use different column headers. Use a template that matches the current display language of the system.
• The file must be in xls or xlsx format. Do not rename or reorder the column headers, change their capitalization, merge or split cells, or insert blank rows.
• The template contains fields used by different data types. Leave fields that do not apply to the selected data type blank; the system ignores them.
• The system uses the Tag name to determine whether to add or update a Tag. Tag names must be unique within the same Device.
• Tag names must also be unique within the same Tag Group, including Tags from different Devices. Otherwise, functions that use the Tag Group, such as Data to Cloud, cannot identify the intended Tag reliably.
• If a Group named in the point table does not exist, the system creates it automatically. Groups for high-speed Data Collection Devices are generated by the system, so the Group field does not need to be completed during import.

Warning: When Delete Tags is selected, the system deletes existing Tags on the selected Device that are not included in the point table. Before continuing, make sure the file contains every Tag that must be retained. It is recommended that you click Export Point Table to back up the current configuration first. Deleting a Tag can also invalidate downstream configurations that reference it, including Alarm Management, Scenario Management, Data to Cloud, Data Forwarding, SCADA Management, and Data Management.

6.5 Publish and Verify

After Device or Tag information changes, click Publish. The new Data Collection configuration takes effect only after it is deployed. Tags added, updated, or deleted through a point-table import must also be published.

1. If you imported a point table, review the import result first. For rejected or skipped entries, correct the reported rows based on the displayed reason and import the file again.
2. Publish the configuration, and then check the collection status of the target Device in the Device list.
3. Confirm that Latest Value is correct and that the update time continues to refresh.
4. If the result is abnormal, check device power, the physical connection, network or serial settings, the selected Driver, the Tag address, and the data type.
5. If the issue remains, open Debug Logs and review the collection success, failure, and runtime information.

6.6 Understand Device Status, Tag Status, and Communication Statistics

Figure 6-3 Device status, Tag status, and communication statistics

The status shown on the page represents the Data Collection communication state. It does not represent the physical online state or network connection state of the field device.

• Device Status: Indicates whether the collection engine determines that the Device can currently provide valid data. Polling Drivers mainly use periodic read results. Subscription Drivers mainly use received data events and may also use Driver-specific probing or keepalive mechanisms. The exact rule can vary by Driver.
• Tag Status: Indicates whether the Tag currently has valid collection data. A successful poll or a received subscription update refreshes the Tag data. The Tag may show an abnormal state when Device communication fails or the data is no longer valid.
• Success/Failure Count: Records successful and failed collection communication events to help evaluate communication quality and troubleshoot problems. It is not a count of Device online or offline transitions, and it does not necessarily equal the number of successful or failed Tags. The counted events depend on the collection method used by the Driver.
• Active Time: While Device Status is normal, the system continuously refreshes Active Time. When Device Status becomes abnormal, Active Time stops updating, and the retained time indicates approximately when the Device became abnormal. Active Time is blank if the Device has never entered a normal state.

When a status is abnormal, check the latest Tag value, update time, and Debug Logs together. Do not use only the status icon on the Device card to determine whether the field device is physically online.

6.7 Manage Devices and Tags

6.7.1 Modify the Value of a Writable Tag

Figure 6-4 Modify Tag Value

The write icon in the Latest Value column is available only when Read/Write Permission is set to Read & Write and the Tag currently has valid communication data. The value cannot be written from this page when the Tag is read-only or its communication state is abnormal.

1. Locate the target Tag and click the write icon in the Latest Value column.
2. In the Modify Tag Value dialog, enter or select a value that matches the Tag data type.
3. Click Save, and then confirm that the latest value and update time are as expected.

Write rules by data type:

• Bool: Select true or false from the drop-down list.
• Integer types: Enter an integer within both the data type range and the range accepted by the field device.
• Floating-point types: Enter an integer or decimal value. The actual precision and displayed result depend on the data type, southbound protocol, and field device.
• String, Raw Data, and BCD: These three data types use the same value-entry rules on this page. The value must not exceed the length configured for the Tag or supported by the field device, and its character encoding must match the field device.

Note: If Data Operation is configured for the Tag, the page displays the calculated value, but the write operation sends the raw device value. Convert the required displayed value back to its raw value before writing. For example, if a raw range of 0–1000 is scaled to 0–100.0, write 500 when the intended displayed value is 50.0.

Warning: This operation writes data to the field device and may change the device or process state. Before writing, confirm the target Tag, value, permitted range, and site conditions. Apply appropriate site safety measures before writing to heating, pressure, motion-control, or power circuits.

If the write fails or the result is not as expected, check the following:

• The Tag has Read & Write access and its communication state is normal.
• The value matches the Tag data type and the range accepted by the field device.
• If Data Operation is configured, the value entered is the raw device value.
• The byte order, string encoding, and value length match the field device.
• A PLC program, another master, Scenario Management, or Logic Orchestration is not continuously writing another value to the same address.
• Register addresses used by different Tags do not overlap.

For a failed write, go to System Settings > Logs and review recent operation records. If Tag communication is abnormal, open Debug Logs and review the Data Collection communication information.

6.7.2 Manage Devices

The system supports the following device management operations:

• Edit a Device.
• Copy a Device.
• Enable or disable a Device.
• Delete a Device.
• View and filter Devices in List View.
• Export Device Configuration.
• Import Device Configuration.

6.7.2.1 Edit, Copy, Enable, Disable, and Delete Devices

Edit a Device

Select the target Device and click Edit to modify its configuration. The Device name must be unique, and the Device protocol and connection parameters should match the field device.

Copy a Device

Select the target Device and click Copy to create a new Device with the same configuration.

When a Device is copied:

• The original Device name is not copied. The new Device must have a unique name.
• Tags under the Device are copied.
• Tag Group assignments are not copied.

Enable or Disable a Device

When a Device is disabled, data collection for the Device stops. Downstream functions that depend on the Device or its Tags, including Alarm Management, Scenario Management, Data Forwarding, Data to Cloud, SCADA Management, and Data Management, can no longer receive new data from the Device.

After enabling the Device again, check the related downstream functions to make sure they operate normally.

Delete a Device

Select the target Device and click Delete to remove it.

Deleting a Device removes the Device and its Tags and may invalidate downstream configurations that depend on them. The deletion cannot be undone.

Warning: Before deleting a Device, make sure that related functions, including Alarm Management, Scenario Management, Data Forwarding, Data to Cloud, SCADA Management, and Data Management, no longer use the Device. After deletion, check and reconfigure any affected functions.

6.7.2.2 Device List View

The Device page supports both Card View and List View. Use the view switch button to switch between the two views.

List View displays Devices in a table and supports filtering by protocol.

For devices that use channel management, such as DNP3 devices, you can further filter devices by channel.

Devices are sorted by Creation Time in descending order by default, with the most recently created Devices displayed first.

6.7.2.3 Export Device Configuration

Device Configuration Export saves Device information and its associated Tags to a JSON file, allowing Device configurations to be migrated to another gateway.

1. Go to Data Collection > Device and switch to List View.
2. Click Export Device, then select Export All or Export Selected.
3. To use Export Selected, select at least one Device first.
4. After the export is complete, the system automatically downloads a JSON file.

The exported JSON file is generated by the system and contains Device information and the associated Tag configuration. Devices of different protocols can be exported in the same file.

Note: Device Configuration Export is different from Export Point Table. Device Configuration Export includes Device-level configuration and associated Tags, while Point Table Export is used only for the Tag configuration of the current Device.

6.7.2.4 Import Device Configuration

Device Configuration Import allows you to create Devices and their associated Tags from a JSON file and can be used to migrate Device configurations between gateways.

1. Go to Data Collection > Device and switch to List View.
2. Click Import Device and select a JSON file exported by the system.
3. Review the import content as prompted, and then execute the import.
4. Check the import result after the operation is complete. If any items are skipped or fail, review the reasons shown on the page.
5. After the import is complete, click Publish to apply the configuration.

Import Processing Rules

The system does not provide a conflict-handling option for users to select. During the import, if an object contains invalid or incomplete information, the system skips that object and its related configuration.

The processing rules are as follows:

• If a Tag contains invalid information, that Tag is skipped while other valid Tags can still be imported.
• If a Device contains invalid information, the Device and all Tags under it are skipped.
• If a Channel contains invalid information, the Channel, all Devices under it, and their Tags are skipped.

In other words, if a parent object cannot be imported successfully, its child objects are not imported either. This prevents incomplete Device hierarchy configurations from being imported.

Note:

• The import file must be a JSON file exported by the system.
• During import, the system processes the configuration according to the hierarchy of Channels, Devices, and Tags.
• The imported Devices and Tags must be published before the configuration takes effect.
• When a Device is imported, its Creation Time and Update Time are reset to the time of the import operation. Historical timestamps in the exported file are not retained.

6.7.3 Manage Tags

The system supports the following Tag management operations:

• Edit a Tag.
• Delete a Tag.
• Batch delete Tags.
• Configure Data Operation.

6.7.3.1 Edit, Delete, and Batch Delete Tags

Edit a Tag

Select the target Tag and click Edit to modify its configuration. The fields that can be modified depend on the protocol and the current configuration.

Delete a Tag

Select the target Tag and click Delete to remove it from the current Device.

Deleting a Tag may invalidate downstream configurations that depend on it, including Alarm Management, Scenario Management, Data to Cloud, Data Forwarding, SCADA Management, and Data Management.

Batch Delete Tags

Use the multi-selection function in the Tag list to select multiple Tags, and then perform a batch deletion.

Warning: Tag deletion cannot be undone. Before deleting Tags, make sure that related downstream functions no longer use them. After deletion, check and reconfigure any affected functions.

6.7.3.2 Data Operation

Data Operation is used to convert raw data read from field devices into processed values used by the system. Data Operation does not modify the original data on the field device.

The following Data Operation modes are supported:

• None: No data operation is applied.
• Scaling: Converts the raw value using a multiplier and an offset.
• Linear Conversion: Performs a linear conversion based on the input range and output proportion range.
• Bit Extraction: Extracts a specified bit from an integer value and converts the result to a Boolean value.

Scaling

Formula:Displayed Value = (PLC Value × Multiplier) + Offset

The following parameters can be configured:

Linear Conversion

Formula:Displayed Value = (Upper Proportion Limit - Lower Proportion Limit) / (Upper Value Limit - Lower Value Limit) × (PLC Value - Lower Value Limit) + Lower Proportion Limit

The following parameters can be configured:

Bit Extraction

Bit Extraction extracts a specified bit from an integer value and converts it to a Boolean value.

Bit Offset specifies the bit to be extracted. Bit numbering starts from 0, where bit 0 is the least significant bit (LSB).

When Bit Extraction is selected, the Tag's read/write permission is automatically set to Read-only.

Decimal Places

Decimal Places sets the number of decimal places for the Data Operation result. The range is 0–6.

The system truncates extra decimal places directly without rounding. For example, when Decimal Places is set to 1:

Note: When Data Operation is configured for a Tag, the value displayed on the page is the processed value, while write operations use the raw value of the field device. For writable Tags, perform the reverse conversion according to the configured Data Operation rules before writing a value.

7. Data to Cloud

7.1 Overview

Data to Cloud sends data collected or processed by the gateway to third-party cloud platforms or Web services.

To upload data to a third-party cloud platform or business system through MQTT, HTTP, or Sparkplug B, start with [7.2 Prerequisites].

7.2 Prerequisites

Before configuration, confirm the following:

• The Devices and Tags to be reported have been published. Device communication is normal, and the Tags continuously generate valid data.
• When reporting data table records, the target Data Table has been created and continuously receives valid records.
• The gateway can access the target platform's network, and the required ports are open.
• You have obtained the Server Address, Port, authentication information, certificates, topics, or HTTP API information from the target platform administrator.
• You have confirmed the data format, reporting frequency, and validation method required by the target platform.

For cloud control or Tag writeback, also confirm that the target Tag's read/write permission is set to [Read/Write], the target Device supports write operations, and the Device action has been tested in a safe environment.

7.3 Configuration Process

7.3.1 Step 1: Prepare the Data Source

A third-party Cloud Service cannot select an individual Device Tag directly. Select the group type according to the data to be sent. You only need to read and configure the section applicable to your data.

7.3.2 Step 2: Select a Cloud Service

For all three Cloud Services, configure the connection, associate the data source, and validate the actual data on the target platform. A connected status or successful connection test confirms only the basic connection and does not replace actual data validation.

7.4 Tag Groups

A Tag Group organizes Device Tags to be reported as one data set and applies unified reporting rules. Use a Tag Group when sending the current values of Device Tags.

7.4.1 Creating a Tag Group

Figure 7-1 Tag Group configuration

1. Go to [Data to Cloud] > [Tag Group] and click [Create Group].
2. Enter the [Name], select the [Report Type], and configure the [Cycle Unit] and [Report Interval] as required.
3. Click [Save], and then select the published Tags to be reported.
4. Click [Save] again. The group can then be selected in the data source configuration of a Cloud Service.

Select a Report Type as follows:

• Period: Sends data at a fixed interval. Use it when the platform requires continuous, complete data snapshots.
• Change: Sends data when a Tag value changes. Use it for status changes or other events that require prompt notification with lower traffic.
• Change & Period: Sends data immediately when a value changes and also at a fixed interval. Use it when both real-time changes and periodic completeness matter.

Note:

• [Report Type] and [Cycle Unit] cannot be changed after creation. Confirm them against the target platform's timeliness and traffic requirements before the first save.
• If High-speed Data Collection is enabled for a Device in Data Collection (polling interval below 1 second), the system automatically generates the corresponding High-speed Data Collection Group. Its Name, Cycle Unit, and Report Interval are inherited from the Device's High-speed Data Collection configuration and cannot be changed in Tag Groups.

7.4.2 Managing a Tag Group

A Tag Group can be [Edited] or [Deleted]. If the group is referenced by a Cloud Service, remove the reference from the related configuration before deleting it. After changing the Tags or reporting rules, validate the data received by the target platform again.

7.5 Data Table Groups

A Data Table Group uses table records from [Data Management] as the Data to Cloud source. Use a Data Table Group for OEE data, calculation or aggregation results, and other Data Table records.

7.5.1 Creating a Data Table Group

Figure 7-2 Data Table Group configuration

1. Go to [Data to Cloud] > [Data Table Group] and click [Create Group].
2. Select the [Data Table], configure the [Report Interval] and [Package Count], and enter an optional [Description].
3. Click [Save].

Note: A Data Table Group sends new records continuously generated by the Data Table. If the Data Table has no new records, the target platform receives no new valid data even when the Cloud Service is connected.

7.5.2 Managing a Data Table Group

A Data Table Group can be [Edited] or [Deleted]. If the group is referenced by a Cloud Service, remove the reference from the related configuration before deleting it. After changing the Report Interval or Package Count, validate the data received by the target platform again.

7.6 Alarm Groups

Alarm Group is used to send alarm trigger and clear events to the cloud. Alarm Data uses Alarm Group as its data source. Alarm Groups are configured under Alarm Management. For information about creating and configuring Alarm Groups, refer to 11.4 Configure Alarm Groups.

Unlike Tag data and Data Table data, Alarm Data uses an event-driven mechanism:

• When an alarm is triggered, the system sends an alarm trigger event to the cloud.
• When an alarm is cleared, the system sends an alarm clear event to the cloud.
• Report Type and Report Interval are not required for Alarm Data.
• Alarm Data supports Function Code processing to transform the message content.

Note: Sparkplug B Cloud Services do not support Alarm Data. Use MQTT or HTTP Cloud Services when alarm information needs to be uploaded.

7.7 MQTT Cloud Service

An MQTT Cloud Service exchanges data with a cloud platform or MQTT Broker through MQTT publishing and subscription. The complete process contains up to five steps. Skip the optional steps that do not apply to your use case:

1. 7.6.1 Preparing a Simulation Environment: Required only when no real MQTT service is available; skip it when a real MQTT service is available.
2. 7.6.2 Adding and Configuring an MQTT Cloud Service: Establishes a connection to Standard MQTT, Azure IoT, or AWS IoT.
3. 7.6.3 Publishing Messages: Reports data from a Tag Group or Data Table Group to the MQTT Broker.
4. 7.6.4 Subscribing to Messages: Receives cloud commands or writes values to Tags; skip it when data reporting is the only requirement.
5. 7.6.5 MQTT Data Validation: Validates the simulation environment, Publish messages, and Subscribe messages according to the actual configuration.

7.7.1 Preparing a Simulation Environment (Skip When a Real MQTT Service Is Available)

If no MQTT service is currently available, use Mosquitto to create a test Broker and MQTTX to simulate cloud-side message reception and transmission. This environment validates basic data transmission only. It does not replace validation of the authentication, permissions, security, or data format of the real platform.

Software downloads:

• Windows x64 example version: mosquitto-2.0.20-install-windows-x64.exe
• Other operating systems or hardware architectures: Mosquitto website
• MQTT client: MQTTX website

The following procedure uses Mosquitto 2.0.20 on a Windows x64 computer. The provided Mosquitto installation package includes the test configuration required for this example.

Start Mosquitto

1. Install the provided Mosquitto 2.0.20 package on a Windows computer that can communicate with the gateway.
2. Open the Mosquitto installation directory, hold down Shift, right-click an empty area, and select [Open PowerShell window here].
3. Paste the following command into PowerShell and press Enter:

1 .\mosquitto.exe -c .\mosquitto.conf -v

4. Keep the PowerShell window open. Messages indicating that Mosquitto is listening on Port 1883 confirm that the Broker has started.

If Port 1883 is already in use, check whether the Mosquitto Windows service or another application is using the Port. Stop the duplicate service or process and try again.

For other operating systems or hardware architectures, download the appropriate version from the Mosquitto website and follow its official instructions for installation, startup, and network access. The default configuration of Mosquitto 2.x may accept local connections only. When using a version downloaded from the official website, confirm that its listener and access settings allow the gateway to connect over the LAN. Configuration of other versions is outside the scope of this manual.

The provided test configuration allows LAN Devices to connect to the Broker without a username or password. It is intended only for temporary functional testing on a controlled network and must not be used directly in a production environment. Stop Mosquitto after testing.

Connect MQTTX

Install and start MQTTX, create a connection, and enter the following information:

• Host: If MQTTX and Mosquitto are installed on the same computer, enter localhost or 127.0.0.1.
• Port: Enter 1883.
• Client ID: Keep the value automatically generated by MQTTX. It must be different from the Client ID used by this system and other connected MQTT clients.
• Username and Password: Leave these fields blank for this example.

Click [Connect]. A successful connection indicates that MQTTX has connected to Mosquitto running on the local computer. Keep Mosquitto running, and then configure the MQTT Cloud Service in this system.

Note:

• If MQTTX and Mosquitto run on different Devices, enter the LAN IP address of the Mosquitto computer that is accessible from MQTTX as [Host].
• When configuring the MQTT Cloud Service in this system, [Server Address] must be the LAN IP address of the Mosquitto computer that is accessible from the gateway. Do not enter localhost or 127.0.0.1.
• A successful MQTTX connection using localhost only confirms that MQTTX can connect to Mosquitto on the local computer. It does not confirm that the gateway can connect over the LAN.
• If MQTTX can connect but this system cannot, check that Mosquitto is still running, the [Server Address] and Port are correct, the network between the gateway and computer is available, and the computer firewall allows inbound connections on Port 1883.

7.7.2 Adding and Configuring an MQTT Cloud Service

Figure 7-3 Create an MQTT Cloud Service

1. Go to [Data to Cloud] and click [Create Cloud Service].
2. Select MQTT as the [Cloud Service Type], enter the [Cloud Service Name] and [Description], and click [Save]. The Cloud Service Type cannot be changed after creation.
3. Under [Connection Configuration], select the [Cloud Platform Type]. MQTT supports Standard MQTT, Azure IoT, and AWS IoT, which use different connection information and authentication methods.
4. Complete the applicable table below and click [Save].
5. Check the connection status in the Cloud Service list. After the connection succeeds, configure a Publish or Subscribe message as required.

Note:

• Valid connection information must be saved before a Publish or Subscribe message can be added. [Connected] means only that the system has connected to the MQTT Broker; it does not mean that the target platform has received business data.
• Before saving the configuration, confirm that the gateway can resolve and access the Server Address of the target platform and that outbound network access from the gateway and the target Port are open, regardless of whether Standard MQTT, Azure IoT, or AWS IoT is selected. For example, when using Azure IoT, confirm that the gateway can access the Azure IoT Hub domain name of the corresponding Device.

7.7.2.1 Standard MQTT

[Response Topic] and [Qos] under [Advanced Configuration] are used by a custom function to return processing results to a specified Topic. Leave them unconfigured if the target platform does not require this type of response.

[Last Will Message] allows the Broker to publish a preset message when the gateway disconnects unexpectedly, helping the target platform identify an abnormal gateway disconnection. Configure [Topic], [Qos], [Retain], and [Payload] only when the target platform uses this mechanism.

7.7.2.2 Azure IoT

7.7.2.3 AWS IoT

7.7.3 Publishing Messages

Figure 7-4 MQTT Publish message configuration

Saving the connection configuration does not start reporting. A Publish message must also be created and enabled.

1. Under [Message Management] in the Cloud Service details, select [Publish] and click [Add].
2. Enter the [Topic Alias] and [Topic], and select the [Data Source Type], [Group], and [Qos].
3. Configure the [Function Code] according to the target platform requirements.
4. Click [Save] and confirm that the Publish message is enabled.

To send different Tags in the same group to different Topic levels, use [Subtopic Configuration] to map Tags to subtopics. Changing the group referenced by a Publish message clears its existing subtopic configuration.

7.7.4 Subscribing to Messages (Skip When Data Reporting Is the Only Requirement)

A Subscribe message receives control commands, parameter settings, or other downstream data from an MQTT Broker or cloud platform.

1. Under [Message Management] in the Cloud Service details, select [Subscribe] and click [Add].
2. Enter the [Topic Alias], [Topic], and [Qos] under [Subscribe Topic].
3. To return the processing result to the target platform, configure [Topic] and [Qos] under [Response Topic]. Otherwise, leave them empty.
4. Configure [Tag Configuration] and [Function Code] to define message parsing and write operations.
5. Click [Save] and confirm that the Subscribe message is enabled.

Warning: Validate the target Tag, write value, and Device action in a safe test environment before first using cloud writeback. For commands that start or stop equipment or change parameters, make sure personnel and equipment safety will not be affected.

7.7.5 MQTT Data Validation

Perform the following validation steps according to your actual configuration:

1. 7.6.5.1 Validating the Simulation Environment: Perform this step when using Mosquitto and MQTTX; skip it when using a real MQTT service.
2. 7.6.5.2 Validating Publish Messages: Perform this step when a Publish message is configured.
3. 7.6.5.3 Validating Subscribe Messages and Tag Writeback: Perform this step when a Subscribe message is configured; skip it when data reporting is the only requirement.

7.7.5.1 Validating the Simulation Environment (Skip When Using a Real MQTT Service)

1. In MQTTX, connect to Mosquitto using an MQTT Client ID different from the gateway's ID.
2. Confirm that MQTTX and the gateway connect to the same Mosquitto instance with the same Server Address and Port.
3. Confirm that the MQTT Cloud Service status is [Connected].

If the connection fails, check whether Mosquitto is running, whether it is listening on the correct Port, and whether the computer firewall and network allow gateway access.

7.7.5.2 Validating Publish Messages

1. Confirm that the MQTT Cloud Service and Publish message are enabled and that the Cloud Service status is [Connected].
2. Confirm that the data source referenced by the Publish message continuously generates valid data.
3. On the real platform or in MQTTX, subscribe to the exact Topic configured for publishing.
4. Wait for at least one Report Interval and check whether messages are received.
5. Confirm that the fields, values, timestamps, data format, and transmission frequency are correct.

If the Cloud Service is connected but no data is received, check whether the Publish message is enabled, whether [Data Source Type] and [Group] are correct, whether the data source generates new data, whether the Topics match, whether the platform has subscription permission, and whether Function Code returns valid data.

7.7.5.3 Validating Subscribe Messages and Tag Writeback (Skip When Data Reporting Is the Only Requirement)

1. Confirm that the Subscribe message is enabled.
2. From the real platform or MQTTX, send a test message that meets the Tag Configuration and Function Code requirements to the [Topic] in the Subscribe configuration.
3. Under [Data Collection], check whether the target Tag value changes as expected and confirm that the field Device performs the intended action.
4. If a [Response Topic] is configured, confirm that the target platform receives the processing result.

If writeback fails, check the following in order:

• The cloud Publish Topic exactly matches the [Topic] in the Subscribe configuration.
• The downstream message structure, Tag name, and capitalization meet the [Tag Configuration] and [Function Code] requirements.
• The target Device and Tag exist, have been published, and communicate normally.
• The target Tag's read/write permission is [Read/Write], and the write value matches the Tag data type and the range allowed by the Device.
• The Data Collection protocol and target Device support write operations.
• If a [Response Topic] is configured, the target platform receives the success or failure result.

When Tag collection fails or a value is empty, the corresponding value may be reported as null. First check the Device status, live Tag value, and update time under [Data Collection].

7.7.6 Managing an MQTT Cloud Service

An MQTT Cloud Service can be [Edited], [Disabled], [Enabled], or [Deleted]. Disabling stops data transmission and reception while retaining the configuration. Deletion cannot be undone. After changing connection parameters or enabling the service again, validate the connection and actual data again.

7.8 HTTP Cloud Service

An HTTP Cloud Service sends data from a Tag Group or Data Table Group to a cloud platform, Web server, or another system that provides an HTTP API through HTTP POST or PUT requests.

An HTTP Cloud Service has no separate Publish message list. Each HTTP Cloud Service binds directly to one data group. After the service is saved and enabled, the system sends data according to the reporting rules of the selected group.

7.8.1 Adding and Configuring an HTTP Cloud Service

Figure 7-5 Create an HTTP Cloud Service

1. Go to [Data to Cloud] and click [Create Cloud Service].
2. Select HTTP Server as the [Cloud Service Type], enter the [Cloud Service Name] and [Description], and click [Save].
3. Select the [Method], enter the complete [Server Address], and configure the Header [Parameter Name] and [Parameter Value] as required.
4. Select the [Data Source Type] and [Group].
5. Configure [Packet Reassembly] and [Request Timeout] as required.
6. Click [Save] and confirm that the HTTP Cloud Service is enabled.

[Server Address] supports a Tag name enclosed in braces, such as {Tag Name}, as a placeholder for dynamically generating the request address from the Tag value. The referenced Tag must be in the current data source and have an exact name and valid value. Otherwise, an invalid address may be generated and the request may fail.

Note: Do not enter production credentials in a public test service. Use HTTPS when sending production data over a public network.

7.8.2 HTTP Data Validation

1. Confirm that the HTTP Cloud Service has been saved and enabled.
2. Confirm that the selected data source continuously generates valid data.
3. Wait for at least one Report Interval.
4. Check the API request records, server logs, or actual received data on the target server.
5. Confirm that the Method, Server Address, Headers, request content, data values, and transmission frequency meet the API requirements.

A successful server status means only that the request reached the server and received a response. It does not necessarily mean that the target business system processed the data correctly. Confirm the final result using the system logs, HTTP response, and actual data on the target platform.

If the target platform receives no data, check whether the Cloud Service is enabled, whether the Method and Server Address are correct, whether placeholder values are valid, whether the Headers and authentication information meet the API requirements, whether the data source generates new data, whether the network and Port are reachable, and whether Packet Reassembly Function Code returns valid data.

7.8.3 Managing an HTTP Cloud Service

An HTTP Cloud Service can be [Edited], [Disabled], [Enabled], or [Deleted]. After changing the API, authentication, or data source, validate the actual request and data again.

7.9 Sparkplug B Cloud Service

A Sparkplug B Cloud Service sends a Tag Group or Data Table Group to a supported industrial platform using standardized Device, Tag, and status structures. The system automatically handles standard Topics, the Protobuf data format, and Device lifecycle messages.

7.9.1 Adding and Configuring a Sparkplug B Cloud Service

Figure 7-6 Create a Sparkplug B Cloud Service

1. Go to [Data to Cloud] and click [Create Cloud Service].
2. Select Sparkplug B as the [Cloud Service Type], enter the [Cloud Service Name] and [Description], and click [Save].
3. Enter the connection information and configure authentication and SSL/TLS as required by the target platform.
4. Click [Save] and check the connection status.

The combination of [Group ID] and [Edge Node ID] must be unique in the system. Changing the Edge Node ID causes the existing offline data for that node to be lost; confirm the change before saving. Sparkplug B uses MQTT v3.1.1 and forces [Clear Session] off. These settings are locked and do not need to be changed.

7.9.2 Publishing Data

1. Under [Message Management], click [Add].
2. Select the [Data Source Type] and [Group].
3. Confirm the [Device ID]. By default, the system uses the Group ID as the Device ID. You can change it according to the Device plan of the target platform. A Device ID must be unique within the same Sparkplug B Cloud Service.
4. Click [Save] and confirm that the Publish configuration is enabled.

The system automatically handles standard Topics, Device Birth and Death messages, and data messages. You do not need to configure Topics manually. Sparkplug B does not support Function Code reassembly or Subscribe messages.

[Device ID] identifies the data source under the Edge Node ID. When Tag collection fails, the system sets the is_valid property in the Sparkplug B Metric PropertySet to false and sets error_code to 500 (GeneralError). The target platform should evaluate the Tag value together with is_valid and error_code.

7.9.3 Sparkplug B Data Validation

1. Confirm that the Cloud Service and Publish configuration are enabled and the connection status is normal.
2. Confirm that the referenced data source continuously generates valid data.
3. On the target platform, check whether the configured [Group ID] and [Edge Node ID] are displayed.
4. Check whether the corresponding [Device ID] is displayed under the node.
5. Wait for at least one complete Report Interval and confirm that the Tag values, update times, and data quality continue to update.

If the target platform does not display or update data, confirm that it actually supports Sparkplug B, verify the Broker connection and authentication information, ensure that the identifiers meet the platform plan and are unique, confirm that the Publish configuration is enabled, and check whether the data source continuously generates valid data.

7.9.4 Managing a Sparkplug B Cloud Service

A Sparkplug B Cloud Service can be [Edited], [Disabled], [Enabled], or [Deleted]. After changing the connection configuration or enabling the service again, validate the node, Device, and actual data on the target platform again.

8. Data Forwarding

Data Forwarding converts Tags collected by the system into standard industrial protocol data for SCADA, MES, BMS, HMI, host software, or other third-party systems. For a writable mapping, the third-party system can also modify the corresponding Tag through the forwarding protocol.

Data Forwarding supports Device Tags and Data Table fields under Data Management as mapping sources. The service configuration, mapping, and validation workflow is the same for both source types; this chapter uses Device Tags as the example.

The following forwarding services are supported:

Only one service of each forwarding type can be created. If a service of the same type already exists in the list, edit the existing service.

8.1 Before You Begin

Before configuring Data Forwarding, confirm the following:

• Complete the Device and Tag configuration under [Data Collection], and confirm that the Tags to be forwarded continuously provide valid data.
• Make sure the third-party system can reach the gateway IP address and planned service port.
• Determine the forwarding protocol, data type, address, and read/write permission required by the third-party system.
• Identify the actual target system that will receive the forwarded data. If the target system is temporarily unavailable or additional troubleshooting is required, prepare one of the optional test tools recommended in this chapter.
• For write-back, confirm that both the source Tag and southbound device support writes, and make sure a test write cannot cause unintended equipment operation.

Warning: Write-back changes the source Tag and may further affect field equipment or process states. For initial verification, use a safe test Tag and test value. Restore the Tag to its original state after verification.

8.2 Configuration Workflow and General Information

Complete the following four main tasks to configure Data Forwarding:

1. Create and configure a forwarding service.
2. Add Tag mappings.
3. Submit and apply the configuration.
4. Verify the forwarded data. If write-back is required, also verify data writes.

8.2.1 Select the Mapped Value

All three forwarding services can expose either the [Data Operation Value] or [Data Original Value] of a Tag.

[Mapped Value Setting] selects the value used by the current mapping. [Default Mapped Value Setting] in the service Basic Settings affects only mappings created afterward and does not change existing mappings. To change the value source or another non-editable setting of an existing mapping, delete and recreate the mapping.

8.2.2 Write-Back Requirements

The ability to read a mapping does not necessarily mean that the mapping is writable. Write-back requires all of the following conditions:

• The mapping permission allows writes.
• The Modbus function code, OPC UA node, or BACnet object type supports writes.
• The source Tag is configured as Read & Write.
• The southbound device and corresponding data address support writes.
• The written value matches the data type and permitted range of the target Device.

8.3 Configure Modbus TCP Slave

Modbus TCP Slave maps Tags to Coils, Discrete Inputs, Input Registers, or Holding Registers. A third-party Modbus TCP client reads the data by using the gateway IP address, service port, Slave Address, function code, and Mapped Address.

Related Guide: For an end-to-end example covering Modbus TCP Slave configuration, Tag-to-register mapping, client connection, data verification, and write-back testing, see the E2C Trinity Modbus TCP Slave Protocol (Northbound) User Guide.

The guide provides a complete application example for the E2C Trinity product family and may use another E2C application in its screenshots or procedures. For E2C Factory, follow the interface names, configuration rules, and supported features described in this manual and displayed in the actual software interface.

8.3.1 Create and Configure the Service

1. Go to [Data Forwarding] and click [Create].
2. Select Modbus TCP Slave for [Driver], and then click [Save].
3. Open the [Configuration] tab for Modbus TCP Slave and enable the service.
4. Complete the Basic Settings, and then click [Submit].

Click [Reset] to discard unsubmitted changes to the Basic Settings and restore the last submitted configuration.

8.3.2 Add a Slave

Modbus TCP mappings are organized by slave. Each slave contains an independent Tag mapping table.

Figure 8-1 Add a Modbus TCP Slave

1. Click [Add] in the slave list.
2. Enter the slave information, and then click [Save].

8.3.3 Add Modbus Mappings

Add mappings individually, or select multiple Tags from the same Device and assign consecutive addresses in a batch.

8.3.3.1 Add One Mapping

1. Open the Modbus Mapping Table for the required slave and click [Add].
2. Select [Device] and [Tag]. The system displays the source Tag's [R/W Permission] and [Original Data Type].
3. Configure the mapped value, mapped data type, function code, and initial address.
4. Click [Save].

The Modbus data areas and read/write methods are as follows:

8.3.3.2 Batch Add Mappings

1. Open the Modbus Mapping Table for the required slave and click [Batch Add].
2. Select [Initial Mapping Function Code] and [Initial Mapped Address].
3. Select a Device and then select the Tags to map.
4. Set [Mapped Value Setting] and [Mapped Data Type] for the selected Tags. Enter [Bit Position] when Bit mapping is required.
5. Check the addresses generated by the system, and then click [Save].

The system assigns consecutive addresses according to the initial address, Tag order, and register quantity occupied by each data type. For example, 32-bit data normally occupies two consecutive 16-bit registers. Address ranges occupied by different mappings must not duplicate or overlap.

Note:

• A mapping that extracts a specified Bit from an integer source and maps it to bool is Read Only.
• When editing an existing mapping, only [Initial Mapped Address] and [Bit Position] can be changed. To change another field, delete and recreate the mapping.
• Different Modbus clients may use offsets starting at 0 or reference addresses such as 00001, 30001, and 40001. When configuring the client, use the function code and Mapped Address displayed in the mapping table and confirm the address base used by the client.

8.3.4 Data Verification and Troubleshooting

After configuration, use the actual Modbus TCP master, SCADA, HMI, or host software to verify the forwarding result. Modbus Poll is optional and is only required when the actual target system is temporarily unavailable or additional troubleshooting is needed.

8.3.4.1 Verify with the Actual Target System

1. Open the [Status] tab and confirm that the service is started.
2. In the actual target system, enter the gateway IP address and service port, and configure the same Slave ID, function code, initial address, and quantity as the mapping.
3. Decode the data according to the Mapped Data Type and byte order, and compare the result with the source Tag under [Data Collection].
4. Change safe test data and confirm that the value in the target system updates accordingly.
5. If the project requires write-back, write a safe value to a Read & Write test mapping. After confirming that the source Tag and southbound device are updated, restore the original value.

8.3.4.2 Verify with Modbus Poll (Optional)

Recommended download: Modbus Poll official download page

1. Start Modbus Poll and go to [Connection] > [Connect].
2. Select Modbus TCP/IP as the connection method, enter the gateway IP address and configured service port, and then connect.
3. Go to [Setup] > [Read/Write Definition], and configure the same Slave ID, function code, initial address, and quantity as the mapping.
4. Set the data display format according to the Mapped Data Type. For example, for a float mapping, select the target registers in the data area and use [Format] to select a floating-point format that matches the service byte order.
5. Compare the Modbus Poll value with the source Tag under [Data Collection]. Change safe test data and confirm that the value updates accordingly.
6. To verify write-back, double-click a writable test Coil or register and write a safe test value. After confirming that the source Tag and southbound device are updated, restore the original value.
7. The Logs tab displays runtime logs for the current Data Forwarding service and can be used to troubleshoot forwarding issues.

If verification fails, check the applicable symptom below:

8.4 Configure Opcua Server

Opcua Server exposes Tags as OPC UA nodes for SCADA, MES, industrial software, or another system that supports OPC UA.

8.4.1 Create and Configure the Service

Figure 8-2 Opcua Server connection configuration

1. Go to [Data Forwarding] and click [Create].
2. Select Opcua Server for [Driver], and then click [Save].
3. Open the [Configuration] tab for Opcua Server and enable the service.
4. Complete the Basic Settings. For User authentication, enter the Username and Password. For Sign&Encrypt, upload the Server Certificate and Server Private Key.
5. Click [Submit] and apply the latest configuration.

Note: Username and Password are required when User is selected. Server Certificate and Server Private Key are required when Sign&Encrypt is selected.

8.4.2 Add Tag Mappings

Opcua Server adds mappings through batch selection. Select one or more Tags at a time.

1. Click [Add] in [OPCUA Mapping Table].
2. Select a Device and then select the Tags to expose to the OPC UA client.
3. Set [Mapped Value Setting] and [Mapped Data Type] for the selected Tags. Enter [Bit Position] when Bit mapping is required.
4. Click [Save] and apply the latest mapping configuration.

To change the value source, data type, or another non-editable setting, delete and recreate the mapping.

8.4.3 Data Verification and Troubleshooting

After configuration, use the actual OPC UA client, SCADA, MES, or other industrial software to verify the forwarding result. UaExpert is optional and is only required when the actual target system is temporarily unavailable or additional troubleshooting is needed.

The client connection address format is opc.tcp://gateway-IP-address:port, for example, opc.tcp://192.168.0.1:4840.

8.4.3.1 Verify with the Actual Target System

1. Open the [Status] tab and confirm that the service is started.
2. Add the Opcua Server connection address in the actual target system, and select the same Authentication Mode and Security Mode as the service.
3. Connect and browse the mapped nodes. Compare the node values with the source Tags under [Data Collection].
4. Change safe test data and confirm that the node value in the target system updates accordingly.
5. If the project requires write-back, write a safe value to a writable test node. After confirming that the source Tag and southbound device are updated, restore the original value.

8.4.3.2 Verify with UaExpert (Optional)

Recommended download: UaExpert official download page

1. Start UaExpert and click [Add Server] on the toolbar, or go to [Server] > [Add].
2. Under [Advanced], enter the Opcua Server connection address and select the same Authentication Mode and Security Mode as the service. For User authentication, also enter the Username and Password.
3. Connect. When using a secure connection for the first time, follow the UaExpert prompt to trust the Server Certificate.
4. Locate the mapped Tag nodes under [Address Space] and drag the required nodes to [Data Access View].
5. Compare the node values with the source Tags under [Data Collection]. Change safe test data and confirm that the node values update accordingly.
6. To verify write-back, double-click the Value of a writable test node and enter a safe test value. After confirming that the source Tag and southbound device are updated, restore the original value.

If verification fails, check the applicable symptom below:

8.5 Configure BACnet IP Server

BACnet IP Server converts Tags into standard BACnet objects for a BMS, building automation system, SCADA, or other BACnet client to discover and access.

Related Guide: For an end-to-end example covering BACnet IP Server configuration, Tag-to-BACnet-object mapping, and data verification with Yabe, see the E2C Trinity BACnet Protocol (Northbound) User Guide.

The guide provides a complete application example for the E2C Trinity product family and may use another E2C application in its screenshots or procedures. For E2C Factory, follow the interface names, configuration rules, and supported features described in this manual and displayed in the actual software interface.

8.5.1 Create and Configure the Service

1. Go to [Data Forwarding] and click [Create].
2. Select BACnet IP Server for [Driver], and then click [Save].
3. Open the [Configuration] tab for BACnet IP Server and enable the service.
4. Complete the Basic Settings. Enable BBMD and configure the BDT only when broadcasts must be forwarded across BACnet/IP networks.
5. Click [Submit] and apply the latest configuration.

8.5.1.1 Configure the BDT (Optional)

When the client and gateway are on different BACnet/IP networks and the project uses BBMD to forward broadcasts, enable [Enable BBMD] and maintain the [BDT List].

Each BDT entry contains the following information:

BDT entries with the same IP Address, Port Number, and Host Mask cannot be added more than once. BBMD is normally not required when devices are discovered and accessed directly within the same subnet.

8.5.2 Add BACnet Mappings

Add BACnet objects individually, or select one Mapping Object Type and add multiple Tags in a batch.

8.5.2.1 Add One Mapping

1. Click [Add] in [BACnet IP Mapping Table].
2. Select [Mapping Object Type], [Device], and [Tag].
3. Complete [Instance number], [Conversion Mode], [Enable +1 Offset], or [Status Count] as applicable to the selected object type.
4. Click [Save] and apply the latest mapping configuration.

8.5.2.2 Batch Add Mappings

Figure 8-3 BACnet batch add mapping configuration

1. Click [Batch Add] in [BACnet IP Mapping Table].
2. Select [Mapping Object Type], enter [Initial Mapped Address], and set [Conversion Mode] and [Offset Setting] as required.
3. Select a Device and then select the Tags to map.
4. Set [Mapped Value Setting] for the selected Tags. For a multi-state object, also check or enter [Status Count].
5. Check the consecutive instance numbers generated by the system, and then click [Save] and apply the latest mapping configuration.

The BACnet object types and conversion rules are as follows:

Note:

• When [Enable +1 Offset] or [Offset Setting] is enabled, source values 0, 1, 2, and 3 are converted to BACnet multi-state values 1, 2, 3, and 4. When disabled, the source values are preserved. A negative source value triggers a fault flag.
• For a BACnet source Device, [Status Count] is obtained from the Tag information. After changing Status Count under [Data Collection], delete and recreate the corresponding mapping.
• For a non-BACnet source Device, enter [Status Count].
• During batch addition, the system generates consecutive instance numbers from Initial Mapped Address. If any generated instance number duplicates an existing mapping, the entire batch fails to save. Change the initial address and save again.

8.5.3 Data Verification and Troubleshooting

After configuration, use the actual BMS, SCADA, or other BACnet client to verify the forwarding result. Yabe is optional and is only required when the actual target system is temporarily unavailable or additional troubleshooting is needed.

8.5.3.1 Verify with the Actual Target System

1. Open the [Status] tab and confirm that the service is started.
2. In the actual target system, select a network interface that can communicate with the gateway BACnet interface, and use the same BACnet/IP port as the service.
3. Discover BACnet devices and identify the service by its [Local Device ID].
4. Browse the mapped objects and compare Present_Value with the source Tag under [Data Collection].
5. Change safe test data and confirm that Present_Value in the target system updates accordingly.
6. If the project requires write-back, write a safe value to a writable test object. After confirming that the source Tag and southbound device are updated, restore the original value.

8.5.3.2 Verify with Yabe (Optional)

Recommended download: Yabe project download page

1. Start Yabe and click [Add device].
2. Select BACnet/IP, select a computer network adapter that can communicate with the gateway BACnet interface, set the same port as BACnet IP Server, and then start discovery.
3. Under [Devices], identify the BACnet Device provided by the system by its [Local Device ID].
4. Expand the Device, select the required object, and view Present_Value under [Properties].
5. Compare Present_Value with the source Tag under [Data Collection]. Change safe test data and confirm that Present_Value updates accordingly.
6. To verify write-back, execute [Write Property] on a writable test object such as AO, AV, BO, BV, MSO, or MSV, and modify Present_Value. After confirming that the source Tag and southbound device are updated, restore the original value.

If verification fails, check the applicable symptom below:

If a forwarding service must be accessed across an untrusted network, restrict its access source according to project security requirements and avoid exposing industrial protocol services directly to the public internet.

9. Scenario Management

Scenario Management converts time, system startup, field data, alarms, and cloud commands into automated tasks. A scenario determines when a task is triggered, and an action determines what happens after the trigger. By combining scenarios and actions, users can reduce repetitive operations and adjust equipment states when business conditions are met.

9.1 Common Use Cases

First identify what should trigger the task, and then select the required action.

These examples illustrate configuration approaches. Write Tag Value and DO Control directly affect field equipment. Determine the actual action according to process and safety requirements.

9.2 Action Types

9.3 Before You Start

Check the prerequisites for the planned scenario:

• Before using Data Linkage, publish the device and tags and verify that the tags provide valid data.
• Before using Alarm Control, configure the required alarm and verify that it can be generated.
• Before using Cloud Command, configure the cloud service and prepare the Topic and QoS.
• Before using Write Tag Value, make sure that the target tag can be written.
• Before using DO Control, complete a basic test of the target DO, external equipment, and wiring.
• Identify the equipment, process, and personnel that may be affected by automatic control, and select safe, controlled test conditions.

Warning: Execute Function, Write Tag Value, and DO Control can change equipment or process states. Before enabling a scenario for the first time, verify the target, write value, external wiring, and site conditions. For heating, pressure, motion, or power circuits, implement the required site safety measures first.

9.4 Configuration Workflow

Creating and verifying a scenario includes two main tasks:

1. Create a scenario, configure its trigger conditions and actions, and save it.
2. Verify the trigger result under safe, controlled conditions.

If multiple scenarios need to reuse the same action, create a shared action first and reference it from each scenario.

9.5 Configure a Shared Action (Optional)

When multiple scenarios need to reuse the same action, create a shared action in Action Management. If the current scenario uses a dedicated action, click Add while configuring the scenario.

Example: Reuse one protective action for multiple abnormal conditions

An air compressor may have separate alarm scenarios for high discharge temperature, low lubricating-oil pressure, and low coolant level. These conditions may require the same site response, such as stopping the compressor and activating an alarm indicator. In this case, create an Air Compressor Protective Shutdown shared action in Action Management, and use Quote in each alarm scenario. This avoids repeatedly configuring the same action and provides one place to maintain the response logic.

1. Go to Scenario Management > Action Management.
2. Select the Execute Function, Write Tag Value, or DO Control tab.
3. Click Add.
4. Enter the action name and complete the applicable settings.
5. Click Save.

For Execute Function, refer to the Scenario Management examples in Appendix A.2, Function Code Reference.

When creating a scenario, use Quote to select the action.

9.6 Create a Scenario

1. Go to Scenario Management.
2. Click Add.
3. Enter the basic scenario information, select Scenario Type, and configure the trigger condition as described in the following table.

Figure 9-1 Scenario trigger configuration

4. In the action area, click Quote to select a shared action. To configure an action only for the current scenario, click Add, select Execute Function, Write Tag Value, or DO Control, and complete the settings. A scenario can contain multiple actions. The system runs the actions from top to bottom; drag an action in the sorting column to change its order.
5. Check the trigger condition, action target, and execution order, and then click Save.

The scenario is enabled by default after it is saved and starts monitoring its trigger condition.

9.7 Verify the Scenario

The scenario is enabled by default after it is saved. Verify the actual action result after saving.

1. Select test equipment or a test tag that will not affect production.
2. Depending on the scenario type, wait for the configured time or interval, arrange a system startup, or trigger the test tag, test alarm, or test cloud command.
3. Check the target tag value, DO output, or equipment state to verify the action result.
4. Restore the test condition and equipment state after verification.

For Cycle Control, observe multiple execution intervals to verify the configured frequency and equipment response.

If the action does not run or the result is not as expected, open History Log to check whether the scenario generated an execution record, and use the record to troubleshoot the trigger conditions and action settings.

9.8 Routine Management

Use the operation controls in Scenario Management to edit, enable, disable, or delete a scenario. Shared actions can be edited or deleted in Action Management. After changing a scenario or shared action, verify the affected scenarios again. Before deleting a configuration, make sure that it is no longer required.

9.9 Troubleshooting

9.9.1 The Scenario Is Enabled but Does Not Run an Action

Check the following items:

• The scenario is enabled.
• The configured time, interval, tag condition, or alarm is met.
• For Cloud Command, the Cloud Service, Topic, and QoS match the sender.
• The tag used by Data Linkage provides valid data.
• History Log contains the corresponding execution record.

9.9.2 History Log Contains a Record but the Equipment Does Not Respond

Check whether the target tag can be written, whether the device is online, whether the DO wiring and output settings are correct, and whether the field equipment permits the action. For a shared action, also verify that the scenario quotes the intended action.

10. Logic Orchestration

Logic Orchestration builds on Node-RED’s native visual flow capabilities and provides four dedicated nodes—Subscription Device Data, Subscription Group Data, Update Device Data, and DO Control—for subscribing to Device Tag or Tag Group data, writing values to Device Tags, and controlling DO outputs. Users can combine these dedicated nodes with built-in Node-RED nodes to implement custom edge data processing and control logic. Processing results can also be written to virtual Tags and reported to cloud platforms through Data to Cloud.

10.1 E2C Nodes

The following four dedicated nodes are available under E2C Node in the node palette on the Logic Orchestration page.

Note: Use the built-in nodes and the dedicated nodes under E2C Node. User-installed third-party nodes may cause compatibility issues and are outside the supported product scope.

10.2 Example: Update Device Data

This example uses an Inject node to send test data and then uses Update Device Data to write specified data from the upstream message to a published writable test Tag. It demonstrates how a dedicated E2C node receives and uses data passed from an upstream node.

Other dedicated E2C nodes use the same basic approach: identify the object to read or control, and then connect the dedicated node to the required built-in Node-RED nodes. For information about built-in nodes and additional orchestration methods, see the Node-RED documentation.

10.3 Before You Begin

• Prepare a published writable test Tag under Data Collection and confirm that device communication is normal.
• Make sure the test value matches the data type of the target Tag and is within the range permitted by the device.
• Use a simulator or test equipment isolated from the production environment for the first verification.

Warning: Update Device Data and DO Control can change field equipment or process states. Before deploying a flow, verify the write target, Mapping, trigger conditions, and site safety measures. Do not run this example on production equipment before assessing its impact.

10.4 Create and Deploy the Flow

This example connects only the Inject node and Update Device Data.

10.4.1 Configure the Inject Node

In normal use, configure payload according to the data structure required by the downstream node.

Figure 10-1 Inject node configuration

1. Drag an Inject node to the workspace.
2. Open the node configuration, set the payload data type to JSON, enter {"Pressure":"20"}, and click Save.

10.4.2 Configure Update Device Data

1. Drag Update Device Data from E2C Node to the workspace.
2. Select the target Device and published writable test Tag, enter {payload.Pressure} in Mapping, and click Save.

In normal use, select the device and Tag to update, and configure Mapping according to the source of the value:

• When writing a fixed value, enter the value directly, for example 100.
• When using data from an upstream array, enter the applicable expression, for example {payload[0].value}.
• When using data from an upstream object, enter the applicable expression, for example {payload.value}.

In this example, {payload.Pressure} reads the Pressure field from the data sent by the Inject node, which is an example of using data from an upstream object.

10.4.3 Connect and Deploy the Flow

1. Connect the Inject node to Update Device Data. After confirming the configuration, click Deploy to apply the flow.

10.5 Trigger and Verify the Flow

1. Trigger the Inject node manually.

Figure 10-2 Node-RED Logic Orchestration flow

2. Under Data Collection or on the test device, confirm that the target Tag has been updated to 20.
3. After verification, restore the original value and disable or delete the test flow.

If the write fails, confirm that the target Tag is published and writable, Mapping is set to {payload.Pressure}, the upstream message contains the Pressure field, and communication with the target Device is normal.

11. Alarm Management

Alarm Management monitors abnormal states in device tags. Based on Alarm Rules, the system generates alarms for review and handling, keeps historical records, and can send notifications through SMS, email, WeCom, WhatsApp, or Telegram.

11.1 Functions

• Real-time Alarms: View and manually handle active alarms.
• Alarm Rules: Define monitored tags, trigger conditions, alarm content, and notification settings.
• Alarm History: Search and delete historical alarm records.
• Alarm Groups: Categorize alarms for filtering and management.
• Alarm Notification Template: Configure message content and connection settings for notification channels.
• Contacts: Maintain recipients for SMS and email notifications.
• History Log: Review notification results and failure information.

11.2 Before You Start

Make sure that:

• The devices and tags to be monitored have been published and the tags provide valid data.
• You have planned the alarm names, levels, and categories.
• Phone numbers or email addresses are available if SMS or email notifications are required.
• The required bot, account, or approved template has been prepared on the corresponding platform if WeCom, WhatsApp, or Telegram notifications are required.
• Your account has permission to configure Alarm Rules, Alarm Notification Template, and Contacts.

If external notifications are not required, you can skip the template and contact configuration and disable Enable Push in the Alarm Rule.

11.3 Configuration Workflows

The most complete workflow includes the following five steps. Read the referenced sections in order, and skip steps that are not required for your scenario.

1. Step 1: Configure Alarm Groups to categorize alarms. See 11.4.
2. Step 2: Configure Alarm Notification Templates to define the message content and connection settings for each notification channel. See 11.5.
3. Step 3: Configure Contacts to maintain recipient information for SMS and email notifications. See 11.6.
4. Step 4: Create an Alarm Rule to define the monitored object, trigger conditions, and notification method. See 11.7.
5. Step 5: Verify alarms and notification delivery, and then view or handle alarms to confirm that the configuration is effective. See 11.8 and 11.9.

If alarm categorization is not required, skip Step 1.

If notifications are not required, skip Step 2 and disable Enable Push when creating the Alarm Rule.

If the notification channel is not SMS or email, skip Step 3.

Alarm History uses the system default storage rules. To adjust the retention quantity or period, see 11.10.

11.4 Configure Alarm Groups (Optional)

Alarm Groups are used to categorize and filter Alarm Rules. They can also be used as the data source group when uploading alarm data to the cloud.

1. Go to Alarm Management > Alarm Groups.
2. Click Add.
3. Enter the tag name.
4. Click Save.

When creating an Alarm Rule, you can assign the rule to an Alarm Group.

In the Alarm Rules list, use Alarm Group to filter rules. You can also select multiple Alarm Rules and assign them to the same Alarm Group in a single operation.

If you do not need to categorize alarms or upload alarm data to the cloud, you can skip this step.

Warning:

• Deleting an Alarm Tag also deletes all Alarm Rules associated with that tag. Make sure that the rules are no longer required before deleting the tag.
• Before deleting an Alarm Group that is referenced by a Cloud Service, remove the related Cloud Service reference first.

11.5 Configure Alarm Notification Templates (When Notifications Are Required)

Alarm Notification Template defines the content and connection settings for each notification channel. A template can use the alarm variables provided by the system. When a message is sent, the system replaces the variables with data from the current alarm.

11.5.1 Configure an SMS Template

1. Go to Alarm Management > Alarm Notification Template > SMS.
2. Enter the SMS text in Template Content and add alarm variables as required.
3. Click Save.

The destination phone number comes from Contacts. In the Alarm Rule, also select a Push Target and SMS as a notification channel.

11.5.2 Configure an Email Template

1. Go to Alarm Management > Alarm Notification Template > Email.
2. Enter the email subject, sending server, username, authorization code, and port.
3. Set SSL according to the requirements of the email server.
4. Enter the email body in Template Content and add alarm variables as required.
5. Click Save.

The destination email address comes from Contacts. In the Alarm Rule, also select a Push Target and Email as a notification channel.

11.5.3 Configure a WeCom Template

1. Create a robot in the destination WeCom group and obtain its Webhook URL.
2. Go to Alarm Management > Alarm Notification Template > WeCom.
3. Enter the Webhook URL in Robot Address.
4. Enter the message in Template Content and add alarm variables as required.
5. Click Save.

The Robot Address in the template determines the destination group and does not change with the selected Contacts entry. To notify multiple users, add them to the applicable WeCom group.

Change API Base URL only when a private proxy, reverse proxy, or custom service address is required. An incorrect address prevents message delivery.

11.5.4 Configure a WhatsApp Template

WhatsApp alarm messages use a template approved by WhatsApp. Create and submit the template on the WhatsApp platform before configuring it in Factory.

1. Go to Alarm Management > Alarm Notification Template > WhatsApp.
2. Enter the Phone Number ID and Access Token.
3. Enter the approved template name and language.
4. Enter the approved content in Template Body.
5. Configure Placeholder Mapping to map template variables to the applicable system alarm variables.
6. Click Save.

Do not change the text or variable structure of an approved template in Factory. If the template is changed on the WhatsApp platform, enter the updated template again and verify all mappings.

Change API Base URL only when required by the network environment.

11.5.5 Configure a Telegram Template

1. Create a Telegram Bot and obtain its Bot Token.
2. Obtain the Chat ID of the destination chat or group.
3. Go to Alarm Management > Alarm Notification Template > Telegram.
4. Enter Bot Token and Chat ID.
5. Enter the message in Template Content and add alarm variables as required.
6. Click Save.

The Chat ID in the template determines the destination. To notify multiple users, use the Chat ID of the applicable group.

Change API Base URL only when required by the network environment.

11.6 Configure Contacts (SMS or Email Notifications)

Contacts stores recipients and their contact details for SMS and email notifications.

1. Go to Alarm Management > Contacts and click Add.
2. Complete the contact form.
3. Click Save.

Enter at least one of Phone Number or Email.

The notification channel selected in the Alarm Rule must match the information stored for the contact. For example, SMS cannot be delivered if the selected contact has no phone number.

WeCom, WhatsApp, and Telegram destinations are configured in Alarm Notification Template and do not change with the selected contact.

11.7 Create an Alarm Rule

Figure 11-1 Alarm Rule configuration

1. Go to [Alarm Management] > [Alarm Rules] and click [Add].
2. Complete the Alarm Rule form.
3. Click [Save].

The main Alarm Rule fields are described below.

11.7.1 Configuration Notes

11.8 Verify Alarms and Notifications

Use a safe, controlled test condition. Do not write a test value to production equipment if it could cause a hazardous action.

1. Make the target tag satisfy the trigger condition.
2. Go to Alarm Management > Real-time Alarms, confirm that the alarm appears, and verify the alarm information.
3. Go to Data Collection and confirm that the alarm count for the applicable level is correct on the device card.
4. If notifications are enabled, confirm delivery at each configured destination.
5. Restore the test condition, resolve the actual abnormal condition, or use Manual Clear.
6. Return to Data Collection and confirm that the applicable alarm count has decreased.
7. Go to Alarm History and confirm that the record can be found and its information is correct.

If the alarm does not appear or a notification is not received, open History Log to review the result and failure information.

11.9 View and Handle Alarms

11.9.1 Real-time Alarms

Figure 11-2 Real-time Alarms and handling

Go to Alarm Management > Real-time Alarms to view active alarms. When the alarm condition is no longer met, the system automatically clears the alarm and moves its record to Alarm History. For example, if a rule triggers when a status equals 1, the alarm is automatically cleared after the status returns to 0.

To end an alarm while its condition is still met, check the cause and device state, and then use Manual Clear for an individual alarm or selected alarms.

Notice: Manually clearing an alarm does not correct the underlying abnormal condition in the device or tag. Resolve the abnormal condition before clearing the alarm.

11.9.2 Alarm History

Figure 11-3 Alarm History page

Go to Alarm Management > Alarm History to search records that have ended or been handled. Use the filters provided on the page.

Before deleting an individual record or using Batch Delete, make sure that the record is no longer required for troubleshooting or audit.

Warning: Deleted Alarm History records cannot be recovered.

11.9.3 History Log

Open History Log to review notification processing. If a message is not delivered, first review the result and failure information, and then check the contact, template, and connection settings.

11.10 Configure Alarm History Storage (Optional)

By default, the system stores up to 1000 Alarm History records and retains each record for up to 30 days. To change these rules:

1. Go to System Settings > Storage > Alarm History.
2. Set Maximum number of records (Up to 5000).
3. Set Discard after expiration (Maximum 180 days).
4. Click Save.

Maximum number of records (Up to 5000) can be set to a maximum of 5000 records. Discard after expiration (Maximum 180 days) can be set to a maximum of 180 days. The system evaluates both conditions. When either condition is met, it deletes the records that have been stored for the longest time first.

11.11 Troubleshooting

11.11.1 An Alarm Was Generated but No SMS or Email Was Received

1. Confirm that Enable Push is enabled and the correct channel is selected.
2. Confirm the selected Push Target.
3. Check whether the contact contains the phone number or email address required by the selected channel.
4. Confirm that the SMS or email template has been saved.
5. Review the result and failure information in History Log.

11.11.2 No WeCom, WhatsApp, or Telegram Message Was Received

1. Confirm that the Alarm Rule selects the applicable channel.
2. Check the connection information and destination in the corresponding template.
3. For WhatsApp, verify the template name, language, approved content, and variable mappings.
4. If a proxy or custom service address is used, check API Base URL.
5. Review the result and failure information in History Log.

12. Data Management

Data Management stores device Tags, user-entered business information, and data generated by other E2C Factory functions in local tables for historical queries, configuration displays, Data to Cloud, and Data Forwarding.

12.1 When to Use Data Management

Device Tags normally represent the current state, such as the current temperature or pressure. When the business needs to understand not only what is happening now but also what happened over time, use Data Management to store Tags as continuous records according to business rules.

Data Management is useful in the following situations:

• Build production or process history: Store temperature, humidity, pressure, energy consumption, displacement, and other data at fixed intervals to review changes over time.
• Capture data when an important event occurs: Store a group of Tag values when a device starts, a process finishes, or a specified condition becomes true, so the event can be investigated later.
• Turn distributed Tags into business data: Select the information that matters from one or more devices and organize it in one Custom Data Table instead of processing every live Tag separately.
• Store calculated results: Apply formulas or combine fields and store the business result directly, rather than storing only raw Tag values.
• Prepare data for visualization and external systems: Use archived tables in SCADA trend displays, or send them to cloud platforms and other business systems through Data to Cloud or Data Forwarding.
• Retain site records while an external system is temporarily unavailable: Archive data locally in E2C Factory according to the configured rules so that business records do not depend entirely on a continuous real-time connection to a cloud or enterprise system.

For example, a customer needs to monitor environmental and operating changes for Device A and Device B. The required temperature, humidity, pressure, and displacement Tags from both devices can be organized in one Tag Archive Table. A rule can write one record every second, or at another interval required by the business. The resulting table can drive a trend chart in SCADA Management or be sent to a cloud platform through MQTT Data to Cloud. Instead of reporting only the current device value, this approach retains continuous historical records organized around the data the business actually needs.

12.2 Choose the Right Table

Data Management contains three table types. Select a table based on the data source and intended use, and then follow the corresponding configuration section.

Data in all three table types can be used as a source for Data to Cloud, Data Forwarding, or SCADA Management.

12.3 Configure a Tag Archive Table

12.3.1 Configuration Overview

Configuring a Tag Archive Table normally includes the following tasks:

1. Create the Tag Archive Table and configure the fields to store.
2. Configure the archive trigger.
3. Trigger archiving and verify the stored data.
4. Configure the retention period and backup before clearing as required.

12.3.2 Before You Begin

• Make sure that the required devices and Tags have been added and provide valid data.
• Decide whether to store original Tag values or calculated values.
• Decide whether data should be recorded at fixed intervals or triggered by a device state or production event.
• Determine the retention period based on business traceability requirements and gateway storage capacity.

12.3.3 Create a Tag Archive Table

Go to [Data Management]. To create a directory, click the Add Directory icon next to [Custom Data Tables], enter a directory name, and save it. Then click the Add icon in the target directory, select [Tag Archive Table], enter [Table Name], and continue to [Field Configuration].

Directories organize data tables. Directory names cannot be duplicated.

Warning: Deleting a directory also deletes all data tables in it, and the deleted data cannot be recovered. A deleted data table cannot be recovered either.

12.3.4 Configure Archiving Fields

Figure 12-1 Tag Archive Table field configuration

Click [Add] in [Field Configuration] and add one field for each item to be stored. Click [Save] after completing the field configuration.

12.3.4.1 Select the Correct Field Type

If the field type does not match the source data, the archived result may be empty or abnormal. For example, selecting [Number] for a text Tag prevents the system from storing the value as expected.

Boolean Tags are handled as text in Data Management. Select [Text], not [Number].

After a table contains records, its field types cannot be changed. Confirm the data type of each Tag when creating the table.

12.3.4.2 Select Related Tag or Formula

[Related Tag] and [Formula] configure the data source of the same field:

• To store the original Tag value, configure [Related Tag].
• To store a calculated result, configure [Formula].
• If both are configured, the system stores the formula result first.

12.3.4.3 Configure and Check a Formula

The [Formula Configuration] page provides functions, field names, and operators. After you select a function, [Help] displays its description and example.

Observe these guidelines when configuring a formula:

• Select fields from the [Field Name] list to avoid manual input errors.
• Select the operator required by the business conversion. For example, if a temperature value must be scaled up by 100, multiply the temperature field by 100 instead of dividing it by 100.
• Read [Help] for each function and confirm its parameters and return value.
• Check the archived result after saving. An incorrect formula may produce empty or abnormal data.

After the Tag Archive Table is saved, the system adds [Record Time] to record the archiving time of each entry.

12.3.5 Configure the Archive Trigger

Figure 12-2 Archive trigger configuration

Tag Archive Tables support [Timing Trigger] and [Tag Trigger]. You can configure multiple rules. Triggering any rule activates archiving.

12.3.5.1 Scenario A: Record Data at Fixed Intervals

Use [Timing Trigger] to create continuous trend data. For example, record device energy consumption, temperature, and pressure every 10 minutes to review changes over a period of time.

1. Select [Timing Trigger].
2. Configure [Trigger Time].
3. Configure [Repeat Frequency] and its time unit.
4. To restrict when data is stored, select [Meet All Conditions] and configure an expression.
5. Save the rule.

When [Meet All Conditions] is enabled, data is archived at the trigger time only if the expression result is true.

12.3.5.2 Scenario B: Record Data by Device State or Production Event

Use [Tag Trigger] when data should be stored only in a specific state. For example, record an energy value once when a device run signal changes from off to on. To continue recording at intervals while the device remains running, also configure [Repeat Frequency].

1. Select [Tag Trigger].
2. Configure an expression that returns true or false under [Trigger Action].
3. Select the result change.
4. To continue recording while the result remains unchanged, configure [Repeat Frequency].
5. Save the rule.

Without [Repeat Frequency], an unchanged expression result does not trigger another record. [True/False Change] does not support [Repeat Frequency].

12.3.6 Verify Archived Data

1. Wait for a timing rule to reach its trigger time, or change the Tag expression according to the configured result change.
2. Open the corresponding Tag Archive Table.
3. Confirm that the table contains a new record.
4. Check each field value and [Record Time].
5. Restore the device state or Tag value used for testing.

If no record is created, first check whether the trigger rule was met. If a record is created but a field is empty or abnormal, check [Field Type], [Related Tag], and [Formula] in sequence.

12.3.7 Configure Storage and Backup (Optional)

Tag Archive Tables retain data for three months by default. You can change [Retention Range].

1. Open [Storage Settings] for the Tag Archive Table.
2. Enable [Enable Auto Clear Data] as required.
3. Configure [Retention Range] and its time unit.
4. To preserve a backup before clearing, enable [Backup Before Clear Data].
5. Click [Save].

12.3.7.1 Understand Full-Hour Cleanup

The page states that the cleanup task runs every full hour. The system performs cleanup only on the hour; it does not count forward from the configuration time.

For example, if [Retention Range] is set to one hour at 8:15, the system does not clear data at 9:15. The first cleanup task runs at 10:00, followed by 11:00, 12:00, and subsequent full hours.

Warning: Automatic clearing deletes data outside the retention range. Before shortening the retention period, confirm the required business data period and enable backup before clearing when needed.

12.3.7.2 Manage Backups Before Clearing

After [Backup Before Clear Data] is enabled, open [Backup Center] at the bottom of the Data Management navigation to view and manage backups.

• When the retention range is less than one day, the backup task runs every full hour.
• When the retention range is greater than one day, the backup task runs daily at 24:00.
• Files downloaded from [Backup Center] are SQL files, not Excel files.

Backup files consume gateway storage. Go to [System Settings] > [Storage] and configure [Backup Data Cap] to set the maximum space available for Data Management backup files. When the limit is reached, the system automatically deletes the oldest backup.

12.4 Configure a Basic Data Table

A Basic Data Table maintains structured business data through forms. It does not require a device Tag association or an archive trigger.

12.4.1 Configuration Overview

Configuring a Basic Data Table normally requires these three steps:

1. Create a Basic Data Table and define its fields.
2. Add, edit, or delete business records.
3. Configure data retention and backup before clearing as required.

12.4.2 Create a Basic Data Table and Define Fields

Figure 12-3 Basic Data Table field configuration

1. Go to [Data Management] > [Custom Data Tables].
2. Click the Add icon under the target directory.
3. Select [Basic Data Table].
4. Enter [Table Name].
5. Click [Add] under [Field Configuration] and add the required fields.
6. Click [Save] after completing the field configuration.

After the table is saved, the system adds [Record Time] to record when each entry is written.

Warning: After a table contains records, its field types cannot be changed. Deleting a field also deletes all historical data in that field.

If a default value is configured when a new field is added, the system fills historical records with that value. To apply a default only to new records, add and save the field first, and then edit the field to configure its default value.

12.4.3 Maintain Business Records

12.4.3.1 Add a Record

1. Open the Basic Data Table.
2. Click [Add].
3. Complete the fields in the form.
4. Click [Save].

After saving, the record appears in the table with a system-generated [Record Time].

12.4.3.2 Edit or Delete a Record

In the [Operation] column, click the Edit icon to modify an existing record or the Delete icon to delete it.

Warning: A deleted record cannot be recovered. Confirm that the record is no longer required before deleting it.

12.4.4 Configure Storage and Backup (Optional)

1. Open the Basic Data Table.
2. Open [Storage Settings].
3. Enable [Enable Auto Clear Data] as required.
4. Configure [Retention Range] and its time unit.
5. To preserve a backup before clearing, enable [Backup Before Clear Data].
6. Click [Save].

Basic Data Tables retain data for three months by default. Cleanup, backup before clearing, and Backup Center follow the same rules as Tag Archive Tables. See Section 12.3.7, “Configure Storage and Backup (Optional).”

13. Private Protocols

13.1 Overview

Private Protocols let you connect devices for which E2C Factory has no built-in protocol support, provided that the device exchanges well-defined messages over a serial or network connection. Based on the device protocol specification, configure the communication method, collection or write commands, packet boundaries, and parsing rules, and then map the parsed values to Device Tags.

This function supports the following collection strategies:

• Inquiry: The system sends collection commands to the device at the configured interval. The device returns data after receiving a command.
• Subscription: The device actively reports data, and the system receives and parses the device messages.

For a continuous byte stream returned by a device, the system can identify complete packets by special character, fixed length, or receive time. After a complete packet is identified, a parsing script extracts the data and maps the results to Device Tags.

This function is intended for private protocols with a defined message structure and relatively simple interactions. Before configuration, obtain the complete device protocol specification and confirm the communication method, message structure, and data parsing rules.

13.2 Before You Begin

Prepare the following information before configuring a Private Protocol:

• The device communication method, such as Serial Communication or Network Communication.
• The Server IP and Port Number for a network device, or the communication parameters for a serial device.
• Whether the device uses Inquiry or actively reports data.
• The collection, heartbeat, or write commands that must be sent to the device.
• The complete response length, frame header, frame trailer, or interval between packets.
• The position, length, byte order, data type, and scaling factor of each value in the message.
• The mapping between Tag addresses and parsed results.
• A physical device or protocol simulator that can be used to verify communication.

This chapter uses a TCP temperature and humidity device to explain the complete configuration process. The example device uses the Inquiry strategy and the following communication rules:

According to the example rules, 00 24 is parsed as the temperature value 36, and 00 22 is parsed as the humidity value 34.

The example messages only illustrate the configuration relationship. For an actual device, rewrite the commands and parsing script according to its protocol specification. Do not reuse the examples in this chapter without modification.

13.3 Configuration Workflow

Configuring and using a Private Protocol consists of up to five steps:

1. Create a Private Protocol and select the Communication Method and Collection Strategy.
2. Configure the heartbeat or timeout settings.
3. Configure Downlink Commands.
4. Configure Uplink Protocol Parsing.
5. Create a Device and Tags with the Private Protocol, and then verify the data.

Depending on the application, you can skip the following tasks:

• When Subscription is used, the Collection Command Set is not required.
• If the device data is read-only, skip Command Control and write verification.
• If a physical device is available for testing, a separate protocol simulator is not required.

13.4 Create a Private Protocol

Open [Private Protocols], click [Add], and complete the basic settings.

The Communication Method and Collection Strategy cannot be changed after the configuration is saved. Confirm that both settings match the device protocol before continuing.

Changing the Collection Strategy while adding a Private Protocol may clear settings that do not apply to the newly selected strategy. Select the Collection Strategy before configuring the heartbeat and Downlink Command settings.

13.4.1 Configure the Timeout for Inquiry

When Inquiry is used, open [Heartbeat Configuration] and enter [Timeout Duration].

Figure 13-1 Configure the Timeout for Inquiry

[Timeout Duration] limits how long the system waits for a device response. The unit is ms. Consider the normal device response time, network latency, and Polling Cycle when setting this value.

If the Timeout Duration is too short, the system may report a timeout before the device completes its response. If it is too long, the system may take longer to identify a device communication failure.

13.4.2 Configure the Heartbeat for Subscription

When Subscription is used, configure the following settings according to the device protocol:

The heartbeat message format and interval must follow the device protocol specification. If the protocol does not require the system to send a heartbeat, determine whether this setting is required according to the actual device behavior.

13.5 Configure Downlink Commands

Downlink Commands convert collection requests or Tag write operations from the system into messages that the device can recognize.

Open [Downlink Command]. Configure [Collection Command Set] and [Command Control] as required.

13.5.1 Configure the Collection Command Set

[Collection Command Set] is used only with Inquiry. The system sends collection commands to the device in the configured order and receives the returned data.

Under [Collection Command Set], click [Add] and complete the command settings.

Figure 13-2 Add a collection command

The Collection Command in this example is 00 01. The corresponding Command Content is as follows:

1 return new Uint8Array([0x00, 0x01]);

When multiple collection commands are configured, confirm the response message for each command. Set the Execution Order and Delay Time appropriately to prevent the next command from being sent before the previous command is complete.

[Delay Time (ms)] controls the wait time between collection command executions. [Polling Cycle] sets the overall data collection cycle for the Device. These fields have different purposes.

13.5.2 Configure Command Control (Optional)

Configure [Command Control] when the device supports write operations and its Tag values must be modified through the system.

The Command Control script receives the Tag write information and generates a message that the device can recognize according to the Tag address and write value.

The script input parameter msg is an array containing one command object. The command object includes the following information:

The script must return a byte array of the Uint8Array type.

For common Command Control patterns, see the Private Protocol examples in Appendix A.2, Function Code Reference.

The following example only illustrates how to generate a message from the temperature Tag address tm and the write value. The example assumes that the temperature write message consists of the command bytes 00 03 and two value bytes:

 1 const command = msg[0];
 2 const writeValue = parseInt(command.Value, 10);
 3 const highByte = (writeValue >> 8) & 0xFF;
 4 const lowByte = writeValue & 0xFF;
 5  
 6 if (command.Address === "tm") {
 7     return new Uint8Array([0x00, 0x03, highByte, lowByte]);
 8 }
 9  
10 return new Uint8Array([]);

Figure 13-3 Configure the Collection Command Set and Command Control

In an actual configuration, process the address, command bytes, data type, value range, byte order, and checksum for each Tag according to the device protocol.

If the device is read-only or its Tag values do not need to be modified through the system, Command Control is not required.

13.6 Configure Uplink Protocol Parsing

Uplink Protocol Parsing processes the raw byte stream sent or returned by a device. The system first identifies a complete packet according to the configured method and then converts the packet into Tag values through the parsing script.

Open [Uplink Protocol Parsing], and configure [Packet Disassembly Method] and [Driver Parsing].

13.6.1 Select the Packet Disassembly Method

The [Packet Disassembly Method] must match the packet boundary defined by the device protocol.