E2C Field Software Product User Manual

Software Version: V2.0.3.0

Document Version: V1.0

About This Document

This document explains how to install, configure, operate, and maintain E2C Field. It helps users complete common tasks for Data Collection (including LoRaWAN device management and LNS configuration), Data to Cloud, Data Forwarding, automation and control, Alarm Management, visual analysis, and system administration.

www.robustel.com

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

Trademark Notice: Robustel is a trademark of Guangzhou Robustel Intelligent Technology 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 Field is industrial edge data software within the E2C Trinity product family, designed for distributed field environments and running on compatible Robustel edge computing gateways. It connects sensors, meters, controllers, and other field devices across dispersed locations through LoRaWAN and wired protocols such as Modbus, OPC UA, and BACnet. It provides edge data collection, processing, storage, visualization, and system integration, creating a unified data foundation for remote monitoring, field operations and maintenance, and integration with SCADA, BMS, EMS, and cloud platforms.

Built on the RobustOS Pro edge runtime, E2C Field includes an integrated LoRaWAN Network Server (LNS) based on ChirpStack, enabling direct LoRaWAN device management without an external network server. For supported devices, its built-in device codec library automatically decodes uplink payloads and generates tags, reducing manual decoding and mapping work. Together with wired protocol support and northbound interfaces, E2C Field aggregates wireless and wired device data on a single gateway and delivers usable data to local operational systems and cloud applications.

1.2 6C Core Capabilities

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

• Collect: Connect and manage LoRaWAN sensors through the integrated LNS and device codec library, while collecting data from wired devices across different vendors and protocols.
• Compute: Perform data processing, logic evaluation, and automation orchestration at the site through Node-RED, custom scripts, and Scenario Management, enabling faster local 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, improving data continuity in remote or weak-network environments.
• Canvas: Present equipment status, alarms, and trends through Web SCADA and charts, providing clear operational visibility across distributed sites.
• Connect: Deliver processed data to MQTT Brokers, HTTP servers, and cloud platforms through Data to Cloud, and provide data to SCADA, BMS, EMS, or other clients through Data Forwarding.
• Control: Trigger tag value updates and equipment control through local rules, alarm events, or cloud commands, supporting bidirectional workflows from monitoring to operational response where the connected devices allow it.

1.3 Typical Application Scenarios

Distributed Energy, Utilities, and Field Assets

Suitable for municipal water systems, pumping stations, distributed photovoltaic sites, oil and gas facilities, and other remote monitoring locations. E2C Field collects equipment status, environmental data, and operational metrics from LoRaWAN sensors, meters, and wired devices, and sends the data to headquarters or cloud platforms over cellular networks. During a network interruption, store-and-forward mechanisms retain relevant data locally and continue uploading it after connectivity is restored.

LoRaWAN Extension for Smart Buildings and Campuses

Suitable for retrofit projects that need to add wireless sensors to an existing BMS or building system. LoRaWAN devices for indoor air quality, temperature and humidity, water leakage, occupancy, and energy metering can be deployed without extensive rewiring. Their data can then be delivered to existing BMS, SCADA, and energy management systems through BACnet, Modbus, OPC UA, or other northbound interfaces.

Large-Area Outdoor and Agricultural IoT

Suitable for farms, growing areas, water infrastructure, and other outdoor environments where assets are dispersed, power is limited, or wired communication is impractical. Using LoRaWAN’s long-range, low-power connectivity, users can monitor soil conditions, weather, water levels, tanks, pumping stations, and other remote assets, while combining cellular backhaul, local data processing, and alarms in a centralized remote monitoring solution.

2. Software Architecture and Deployment Planning

2.1 Supported Hardware Models

The software is compatible with the LG3120 gateway model, which requires a minimum of 2 GB of RAM and RobustOS Pro version 2.4.111 or later.

2.2 Software Architecture and Working Principle

Figure 2-1: E2C Field software architecture panoramic diagram

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

• Southbound device connectivity: Use the built-in LNS to connect LoRaWAN sensors over long-range wireless links. Use applicable Drivers to connect wired PLCs, controllers, sensors, meters, or other data sources through Modbus, OPC UA, or BACnet protocols.
• Edge processing and applications: Perform Alarm Management, Logic Orchestration, Scenario Management, and SCADA tasks on the gateway. The built-in LNS manages LoRaWAN network parameters, device profiles, payload codecs, and live frame monitoring.
• Northbound system integration: Use Data to Cloud to deliver data to MQTT Brokers, HTTP servers, or cloud platforms through MQTT, HTTP, or Sparkplug B. Use Data Forwarding to provide data to SCADA, MES, BMS, ERP, or other clients through Modbus TCP Slave, OPC UA Server, or BACnet IP Server.

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

3. Installation, Upgrade, and Licensing

3.1 Deployment and Pre-installation Checks

Before installing and configuring E2C Field, prepare the gateway, management network, and field devices required by the project. Only the device types and communication links used in the actual project need to be prepared.

Figure 3-1: Hardware preparation and network architecture

3.1.1 Prepare the Gateway and Management Network

1. Connect the LG3120e to an appropriate industrial power supply according to its hardware installation guide, and securely install the antennas required by the project on their corresponding connectors. A LoRaWAN antenna is required when LoRaWAN devices are used. Install the cellular or Wi-Fi antennas only when the corresponding communication link is used.
2. Connect the management computer to the gateway network and ensure that the computer and gateway are on the same subnet.
3. 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.
4. 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."

Figure 3-2: Gateway web home page showing the firmware version

5. 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.
6. If the project connects to a local upper-level system, remote management platform, or cloud platform, plan the routing and network access from the gateway to the target system in advance. Ethernet, Wi-Fi, or a cellular network can be used to access public network services, depending on the project. When a cellular network is used, install a valid SIM card and confirm that its data service is available. Internet access is not required for deployments that only perform local data collection, processing, or forwarding.

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

3.1.2 Prepare LoRaWAN Devices (As Required)

When LoRaWAN devices are used, complete the following preparations:

• Confirm that the operating frequency band of each device matches the LoRaWAN frequency band supported by the LG3120e and the Region configured in the system, and that it complies with the spectrum requirements of the deployment location.
• Prepare the device manufacturer, model, and related product documentation so that a matching Device Profile and Payload Codec can be selected or created.
• For OTAA, prepare the DevEUI, JoinEUI, and AppKey. For ABP, prepare the device address and the corresponding session keys. These parameters are typically available on the device label, in its configuration tool, or in the manufacturer's documentation.
• Confirm that the device power supply or battery is in normal condition. During device onboarding and data verification, place the device within the LoRaWAN coverage area of the gateway.

For detailed Device Profile, Payload Codec, and device onboarding instructions, see Chapter 6, "LoRaWAN Device Management."

3.1.3 Prepare Wired Devices (As Required)

When wired devices are used, complete the following preparations:

• Complete the power supply and wiring according to the hardware installation guides for the gateway and field devices.
• Connect Ethernet-based devices to the gateway LAN interface or to an industrial network accessible from the gateway.
• Connect RS-232 or RS-485 devices to the corresponding serial port on the gateway, and confirm that the interface type and wiring are correct.
• Connect field switches, relays, alarm signals, or other I/O signals to the corresponding gateway interfaces, and confirm that the signal type and electrical specifications meet the gateway requirements.
• Prepare the applicable Driver, device network address or serial port parameters, device address, Tag addresses, data types, and other required configuration information.

For supported protocols, connection parameters, and configuration procedures, see Chapter 7, "Wired Device Management," and the applicable protocol user guide.

3.1.4 Confirm the Gateway Time

E2C Field 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 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:

Figure 3-3 NTP client configuration for an online gateway

• 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.
• 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.

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 Field 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 Field 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 Field 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: Installing E2C Field 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 Field" for instructions on opening E2C Field and using the main interface.

3.3 View or Upgrade the License

Figure 3-5: License Activation

The gateway includes the Free Edition of E2C Field by default. You can use the functions included in the Free Edition without uploading a license file. A software upgrade updates the E2C Field 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:

The system verifies hardware capabilities during license activation. Gateways with 2 GB of RAM support a maximum of 2,000 Tags. Gateways with 8 GB of RAM support up to 5,000 Tags. If the uploaded license file exceeds the hardware limit, the system aborts activation and displays a hardware limit error message.

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.

The activation process does not require a gateway restart and will not affect ongoing data collection or forwarding tasks.

3.4 Uninstall the Software

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

Warning: Uninstalling E2C Field 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-field 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-field is no longer displayed.

4. Getting Started with E2C Field

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

4.1 Open E2C Field

Figure 4-1: Edge Computing menu entry in the gateway navigation

Before you begin, make sure that E2C Field 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 Field.

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

E2C Field is enabled by default after installation. To verify or change its operating status, go to Edge Computing > E2C Field, and use the Enable toggle to enable or disable the software.

4.2 Understand the Main Interface

The main interface contains the following global areas:

Figure 4-2: Main Interface

• Menu navigation area: Located on the left side of the page. Use it to open E2C Field functions.
• Workspace: Located in the center of the page. It displays the list, configuration form, operating status, or operation result for the selected function.
• User menu area: Located in the upper-right corner. Use it to view the current account and software information, open common entries, or log out.

The available menus vary with the software license. If a function is not included in the current license, its corresponding menu is not displayed.

4.3 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.

5. Quick Start

This chapter uses a minimum example to complete a closed loop covering LoRaWAN Data Collection and Data to Cloud. The example onboards a Dragino LDDS75 LoRaWAN distance sensor, adds its distance Tag to a Tag Group, and reports the Tag to an MQTT Broker through Standard MQTT.

This chapter covers only the key settings required to complete the closed loop. For software installation, MQTT test-environment preparation, Data Forwarding, Alarm Management, troubleshooting, and other related tasks, see E2C Field Quick Start.

5.1 Before You Begin

Before starting the configuration, confirm the following:

• E2C Field is installed and can be opened, and the gateway network and system time are configured correctly.
• The LoRa antenna is installed correctly, and a real LoRaWAN device is available within the gateway coverage area. This example uses a Dragino LDDS75 operating in the EU868 Region.
• The LoRaWAN Region, MAC Version, Regional Parameters Revision, Activation Method, Device Class, Expected Uplink Interval, and heartbeat period supported by the device are available.
• The Device EUI, Join EUI when applicable, and Application Key used for OTAA are available.
• You know how to trigger a Join or Uplink by powering on, restarting, or manually operating the device.
• An MQTT Broker accessible from the gateway and a receiver capable of subscribing to and displaying MQTT messages are available.

A real device is required to validate LoRaWAN onboarding and radio data. Do not create a device by using a fabricated Device EUI, Join EUI, or Application Key.

If no MQTT Broker is available, follow the instructions in E2C Field Quick Start to prepare a temporary test environment with Mosquitto and MQTTX.

5.2 Configuration Workflow

Complete the following two main steps:

1. Collect LoRaWAN data: Confirm the Payload Codec, create and publish a Device Profile, add and publish the LoRaWAN device, and then validate the distance Tag.
2. Report MQTT data: Create a Tag Group and a Standard MQTT Cloud Service, configure a Publish message, and then validate the result at the MQTT receiver.

5.3 Step 1: Collect LoRaWAN Data

5.3.1 Prepare the Payload Codec and Device Profile

Go to LNS Configuration > Payload Codecs and locate the Codec for the target device. This example uses Dragino / LD / LDDS75.

• If the applicable Codec is available and published, continue to create the Device Profile.
• If no applicable Codec is available, follow the instructions in Chapter 6, “LoRaWAN Device Management,” to import, test, and publish the Codec. Then return to this section.

Go to LNS Configuration > Device Profiles, click Create New, and configure the Device Profile as follows. When using another device model or Region, replace the applicable values according to the device documentation.

Keep the default values for the other fields. After confirming the configuration, click Publish. A device can reference the Device Profile only after the Profile is published.

Figure 5-1 Create the LDDS75 Device Profile

5.3.2 Add and Publish the LoRaWAN Device

Go to Data Collection > LoRaWAN Devices, click Add Device, and configure the device as follows. Replace the Device EUI, Join EUI, and Application Key with the values configured for the actual device.

After completing the form, click Next to open Tag Verification. The system generates business Tags and system Tags according to the Payload Codec. Keep the Tags required by the project, confirm their names and data types, and then click Confirm.

This example keeps distance, whose Data Type is int (int32).

After returning to the device list, click Publish LoRa in the upper-right corner and wait until synchronization succeeds. A new or modified device configuration takes effect only after it is published.

Figure 5-2 Add and publish the LoRaWAN device

5.3.3 Validate LoRaWAN Data

1. Power on, restart, or manually trigger the sensor according to the manufacturer instructions so that the device generates a Join or Uplink.
2. Go to Data Collection > LoRaWAN Devices and confirm that LDDS75_Sensor_01 is online.
3. Click View Tags in the device operation column.
4. Confirm that the Data Type of distance is int (int32), and check its Latest Value and Update Time.
5. Trigger another Uplink or wait for one complete device reporting interval, and confirm that Update Time refreshes.

If the device does not join or distance has no value, first check Events for the device. To inspect raw messages and Codec decoding results, go to LNS Configuration > Live Frames.

Figure 5-3 Validate the distance Tag

Continue to Data to Cloud only after distance has a valid Latest Value and its Update Time continues to refresh.

5.4 Step 2: Report MQTT Data

This section adds the distance Tag of LDDS75_Sensor_01 to a Tag Group and reports its latest value through Standard MQTT.

5.4.1 Create a Tag Group

Go to Data to Cloud > Tag Group, click Create Group, configure the group as follows, and then click Save.

After the first save, locate LDDS75_Sensor_01 in the Tag selection window, add the published distance Tag to Group_01, and then click Save again.

The Tag Group takes effect when saved and does not need to be published separately.

The LoRaWAN device sends an Uplink according to its own reporting or heartbeat settings. The Tag Group reports the latest value already received by this system according to the interval configured in this section. Changing the MQTT reporting interval does not change how frequently the LoRaWAN device sends an Uplink.

5.4.2 Create a Standard MQTT Cloud Service

Go to Data to Cloud, click Create Cloud Service, set Cloud Service Type to MQTT, enter MQTT_Service_01 as the Name, and click Save.

Select the new Cloud Service and configure Connection Configuration as follows. The address and security settings in the table apply to the local test environment described in the standalone Quick Start. When connecting to a real MQTT service, replace them with the parameters provided by the target service.

The Off settings for SSL/TLS and User Authentication apply only to the local test environment. They are not default recommendations for production deployment.

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 distance is being reported.

Figure 5-4 Create and configure the Standard MQTT Cloud Service

5.4.3 Configure a Publish Message and Validate Data

In Message Management for MQTT_Service_01, select Publish, click Add, configure the message 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.

Figure 5-5 Configure the MQTT Publish message

Validate the reported data as follows:

1. When using the test environment, connect MQTTX to the corresponding MQTT Broker and subscribe to /field/quickstart/data. Keep the Client ID automatically generated by MQTTX and confirm that it is different from E2C_Field_Gateway_01.
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 Tag Group reporting interval and confirm that the received message contains distance and its latest value.
4. When it is safe to do so, change the measured distance and trigger an Uplink according to the device instructions, or wait for the next scheduled Uplink.
5. Confirm that the distance value received by the MQTT receiver matches the Latest Value displayed in Data Collection.

When validation succeeds, the complete data path from the LoRaWAN device to the MQTT Broker is operating correctly.

If the Cloud Service is connected but no data is received, check the following in order:

• distance has a valid Latest Value in Data Collection.
• Group_01 contains distance.
• The Publish message is enabled.
• The configured Topic exactly matches the topic subscribed to by the receiver.
• This system and the receiver are connected to the same MQTT Broker.

If the cause is still unclear, go to Debug Logs and review the Data to Cloud logs.

6. LoRaWAN Device Management

This chapter explains how to prepare the LNS, Payload Codec, and Device Profile required by a LoRaWAN device, add and publish devices, and verify device onboarding and data collection in E2C Field.

Before adding a device, ensure that the built-in LNS is operating normally and that a matching Payload Codec and Device Profile are available. A Payload Codec and Device Profile can normally be reused by multiple devices of the same model, while activation parameters such as the DevEUI, JoinEUI, and AppKey are specific to each device.

If the required LNS, Payload Codec, and Device Profile are already available, proceed directly to Section 6.2.

6.1 Prerequisites

Complete the following three prerequisite steps before adding a LoRaWAN device.

6.1.1 Prerequisite Step 1: Verify the LNS Service

The built-in LNS manages LoRaWAN network communication, device activation, and sessions. Before adding a device, confirm that the LNS is operating normally:

1. Go to LNS Configuration > Service Information.
2. Confirm that the LNS service status is Running.
3. Confirm that the configured Region matches the frequency band supported by the LG3120e, the operating frequency band of the LoRaWAN device, and the project deployment location.

If the LNS service is not running, restart the gateway and check again. If the issue persists, go to Debug Logs and review the LNS-related log entries.

6.1.2 Prerequisite Step 2: Prepare a Payload Codec

A Payload Codec converts an uplink payload from a LoRaWAN device into readable Tag values. If the device supports downlink control, it can also encode control data into a downlink payload that the device can interpret.

A Payload Codec is normally configured per sensor model. Multiple devices of the same model that use the same payload format can share one Codec.

6.1.2.1 Check the Codecs in the System

1. Go to LNS Configuration > Payload Codecs.
2. Use the page search function to enter the device manufacturer or model as a keyword.
3. Confirm whether the Codec in the search results matches the actual device model, firmware version, and payload format.
4. Review the fields provided by the Codec and confirm that they include the data that the project needs to collect or write.

If a matching Codec is available, proceed directly to Section 6.1.3 to prepare the Device Profile.

If no matching Codec is available, select one of the following methods:

• If the manufacturer provides a raw Codec file, use E2C Trinity Codec Converter to convert it into a TOML file supported by this system.
• If no convertible Codec is available, or if an existing Codec must be adjusted, an engineer familiar with JavaScript and the device payload specification can create a Codec or copy and modify a similar Codec.

6.1.2.2 Obtain a Manufacturer-provided Codec

Some LoRaWAN sensor manufacturers provide raw Codec files for integrating their devices with different LoRaWAN platforms. These files may be available from a product website, official GitHub repository, device documentation package, technical support, or another offline channel.

Confirm that the Codec file matches the actual device model and firmware version.

Sources for some common manufacturers and device repositories include:

• Milesight: https://github.com/Milesight-IoT/SensorDecoders
• Dragino: https://github.com/dragino/dragino-end-node-decoder
• Other vendor device repositories: https://github.com/TheThingsNetwork/lorawan-devices

Download the complete Codec file or archive and extract it on the management computer.

6.1.2.3 Convert the Codec File

If the manufacturer-provided Codec cannot be imported directly into this system, use E2C Trinity Codec Converter to convert it into a TOML file.

1. Download E2C Trinity Codec Converter from the E2C Field APP Download page.
2. Place the conversion tool and the extracted manufacturer Codec folder in the same directory.
3. Run e2c-trinity-codec-converter.exe.
4. Select the sensor Vendor and Model.
5. Click Generate Codec TOML to generate the TOML file.

Figure 6-1: E2C Trinity Codec Converter interface

For supported Codec formats, conversion preparation, and the complete procedure, see How to Convert LoRaWAN Sensor Codec Formats and Import to E2C Field.

6.1.2.4 Import the Codec

After conversion, import the generated TOML file into E2C Field:

1. Go to LNS Configuration > Payload Codecs.
2. Click Import Codec > Import from file.
3. Select the generated TOML file and complete the import.
4. Locate the imported Codec in the Payload Codecs list and confirm that its name, vendor, and model are correct.

Figure 6-2: Importing a Codec from a file

6.1.2.5 Test and Publish the Codec

Whether the Codec was imported from a file or created by an engineer, it must be tested before it is associated with a Device Profile:

1. Open Uplink Test for the Codec.
2. Enter a sample hexadecimal payload provided in the device documentation, and then click Run Decode.
3. Compare the decoded output with the expected result in the device documentation. Confirm that the field names, data types, and values are correct.
4. If the device supports downlink control, open Downlink Test, enter the test data, and confirm that the generated byte array and fPort comply with the device protocol.
5. If the test returns errors or warnings, correct the Codec and run the test again.
6. After the test passes, click Publish.

Notice: Successful code execution alone does not confirm that the decoded result is correct. Always validate the actual decoded values using a known payload and its expected result.

To create or modify a Codec, an engineer can write the uplink decoding and downlink encoding logic in JavaScript Code Preview. This requires knowledge of JavaScript and the device payload specification and is not covered in this user guide.

Figure 6-3: Available Codecs on the Payload Codecs page

6.1.3 Prerequisite Step 3: Prepare a Device Profile

A Device Profile defines the network and communication parameters shared by a type of LoRaWAN device, including its Region, LoRaWAN version, Regional Parameters Revision, activation method, and Device Class. It also associates the Payload Codec used to interpret device data.

The same Device Profile can be reused by multiple devices with the same model, Region, and communication configuration.

6.1.3.1 Check the Device Profiles in the System

1. Go to LNS Configuration > Device Profiles.
2. Search for a Profile matching the device model, Region, activation method, and LoRaWAN version.
3. If a matching Profile is available, confirm that it uses the correct Payload Codec.
4. If no matching Profile is available, click Create New or copy a Profile with similar settings, and adjust its parameters according to the device product documentation.

6.1.3.2 Configure the Device Profile

Configure the following key fields according to the device product documentation:

After completing the configuration, click Publish.

Figure 6-4: Creating a Device Profile

6.2 Configuration Workflow

This section assumes that the LNS is running and that the required Payload Codec and Device Profile have been prepared as described in Section 6.1.

Add and verify LoRaWAN devices in the following two steps:

1. Configuration Step 1: Add and Publish DevicesSelect Z-touch Onboarding, batch import, or single-device addition according to the number of devices and their Profile distribution. After adding the devices, synchronize their configuration with the LNS. Z-touch Onboarding publishes automatically. Batch import and single-device addition require Publish LoRa.
2. Configuration Step 2: Verify DataConfirm that the devices have joined the network, and check their latest Tag values and update times. If a device supports downlink control, also verify data writing.

6.3 Configuration Step 1: Add and Publish Devices

Select one device addition method according to the deployment scenario:

All three methods add LoRaWAN devices. Select only the method applicable to the current project.

6.3.1 Method 1: Z-touch Onboarding (Recommended for Initial Deployment)

Z-touch Onboarding adds LoRaWAN devices in batches. After device information is entered in an Excel template and uploaded, the system automatically completes data validation, device creation, Tag creation, and LNS synchronization and publishing. Devices using different Device Profiles can be included in the same template.

Go to Data Collection > Z-touch Onboarding.

The feature contains three tabs: Overview, Onboarding, and History.

6.3.1.1 Overview

The Overview page introduces the applicable scenarios and overall workflow of Z-touch Onboarding.

Key characteristics include:

• Batch device addition: Add multiple devices with a standard template without completing a form for each device.
• Automatic validation: Check required fields, DevEUI formats, duplicate data, Profile names, and license capacity, and identify the affected row.
• Multiple Profile support: Include devices using different Device Profiles in the same template.
• Automatic end-to-end execution: Create devices and Tags and synchronize and publish the configuration to the LNS.

The overall workflow is as follows:

1. Download and complete the template.
2. Upload and validate the file.
3. Automatically create devices and Tags.
4. Automatically synchronize and publish the configuration to the LNS.
5. Review the execution result and handle failed records.

Click Get Started to open the Onboarding tab.

6.3.1.2 Onboarding

Step 1: Download and Complete the Template

1. Click Download Template on the Onboarding page.
2. Open the downloaded XLSX file and complete the device information according to the field comments in the template.
3. Ensure that each Profile name exactly matches a published Profile name on the Device Profiles page, including capitalization.
4. A maximum of 2,000 devices can be imported in one task.

Step 2: Upload and Validate

1. Click the upload area and select the completed template.
2. Confirm that the file is correct, and then click Next.
3. The system checks the file format, required fields, device identifiers, duplicate data, Profile names, and license capacity.
4. If validation fails, correct the template according to the displayed row and failure reason, and then upload it again.

If the imported Tags exceed the current license capacity, reduce the import quantity or go to System Settings > License Activation to upgrade the license.

Step 3: Automatic Execution

After validation passes, the system performs the following tasks in sequence:

1. Validate the template content.
2. Create the devices.
3. Create the Tags associated with the devices.
4. Synchronize and publish the device configuration to the LNS.

The current progress is displayed on the page. After the task enters the LNS synchronization phase, other functions in the system can be opened. The result can later be reviewed in History.

During execution:

• Do not refresh or close the browser page.
• Do not modify or publish LoRaWAN devices in Data Collection > LoRaWAN Devices at the same time, because this may conflict with the current task.

After execution, the page displays:

• Total Devices: Total number of devices in the template.
• Successful: Number of devices that completed all steps.
• Failed: Number of devices that failed during any step.

Step 4: Handle Failed Records

If failed records exist, a failure list appears at the bottom of the page. Review the reason for each failure and export the failed records when required.

After correcting the template, click Upload again to upload it again.

If only LNS synchronization fails, the devices and Tags may have been created successfully, but their configuration has not been published to the LNS. In this case:

• Click Retry on the current task page; or
• Go to Data Collection and click Publish LoRa to synchronize again.

Figure 6-5: Z-touch Onboarding execution results and failed records

6.3.1.3 History

The History page displays up to 50 recent import records.

Each record contains the file name, import time, total number of devices, successful count, and failed count. The page supports:

• Searching for records by file name.
• Exporting history records.
• Exporting failed records from the Action column.
• Reviewing the result of a background task after leaving the execution page.

Figure 6-6: Z-touch Onboarding History page

When Z-touch Onboarding completes successfully, the device configuration has already been synchronized and published to the LNS. Do not click Publish LoRa again. Proceed to Section 6.4 to verify the data.

6.3.2 Method 2: Batch Import (Same Profile)

Batch import is intended for multiple devices using the same Device Profile, such as sensors with the same model, Region, and activation method.

1. Go to Data Collection > LoRaWAN Devices.
2. Click Batch Import.
3. Download the import template provided on the current page.
4. Complete the device names, device identifiers, and activation parameters according to the field comments in the template.
5. Upload the completed file. The system automatically validates the file and imports valid data.
6. Review the import result. If failed records exist, download the failure list, correct the data according to the failure reason, and import it again.
7. After the import is complete, click Publish LoRa to synchronize and publish the new devices to the LNS.

Batch import applies only to devices using the same Profile. If the same deployment includes multiple Profiles, use Z-touch Onboarding.

6.3.3 Method 3: Add a Single Device

Single-device addition is intended for adding only a few devices or confirming device parameters individually.

1. Go to Data Collection > LoRaWAN Devices.
2. Click Add Device.
3. Configure the device according to the following table:

4. Click Next to select Tags.
5. The system displays the Tags provided by the Payload Codec associated with the Device Profile.
6. Select the Tags that the project needs to collect or write, and then click Confirm.
7. Click Publish LoRa to synchronize and publish the device configuration to the LNS.

Figure 6-7: Add Device form with Tag association

6.4 Configuration Step 2: Verify Data

After adding and publishing the devices, power on or restart each LoRaWAN device and ensure that it is within the LoRaWAN coverage area of the LG3120e.

6.4.1 Verify Uplink Data

1. Go to Data Collection > LoRaWAN Devices.
2. Check the target device Status. A green status icon indicates that the device has successfully joined the network and is communicating with the LNS.

Figure 6-8: LoRaWAN Device list showing the connection status

3. Click the View Tags icon next to the device.
4. Review Latest Value and Update Time.
5. Confirm that Latest Value displays reasonable device data and that Update Time continues to update according to the device reporting interval.

Figure 6-9: Latest Value and Update Time in View Tags

If the device reports data but its Tag values are empty or incorrectly decoded, go to LNS Configuration > Live Frames, compare the raw payload with the decoded result, and confirm that the Device Profile uses the correct Payload Codec.

If the device does not join or report uplink data, check the following items in order:

• Confirm that the device is powered on and within the gateway coverage area.
• Confirm that the LNS service status is Running.
• Confirm that the Region matches the frequency band supported by the device and LG3120e.
• Confirm that the Device Profile matches the device configuration.
• Confirm that the DevEUI, JoinEUI, and AppKey are correct.
• Confirm that the actual device reporting interval is not longer than the current waiting time.
• Review Debug Logs for LNS or device activation errors.

6.4.2 Verify Downlink Data (Optional)

Perform the operations in this section only when both the LoRaWAN Device and its associated Payload Codec support downlink control.

LoRaWAN Tags generated automatically by the system use Read Only permission by default. Even when the Payload Codec contains downlink Tags and encoding logic, the user must manually configure the permission and downlink parameters of the target Tag.

1. Go to Data Collection > LoRaWAN Devices.
2. Click the View Tags icon beside the target Device.
3. Locate the Tag to be used for downlink control and click its edit icon.
4. Set R/W Permission to Read & Write.
5. Enter FPort and CmdType according to the definition of the corresponding downlink Tag in the Payload Codec.
6. Click Save.

Figure 6-10: Configuring a writable LoRaWAN Tag

After configuring the Tag, verify the downlink control:

1. In the Device View Tags page, locate the Tag configured as Read & Write.
2. Click the Modify Tag Value icon.
3. Enter the command or value to write, and then click Confirm.
4. Confirm that the command was executed by checking the actual Device state or subsequent uplink data.

Figure 6-11: Modify Tag Value dialog for a downlink command

Notes:

• FPort and CmdType must exactly match the definition of the corresponding downlink Tag in the Payload Codec. Otherwise, the Payload Codec may be unable to generate the correct downlink payload.
• A Tag can be used for downlink control only when the Payload Codec defines the corresponding downlink Tag and encoding logic. Manually changing an arbitrary Tag to Read & Write does not add downlink support when the Payload Codec does not support that Tag.
• Some LoRaWAN Devices enter sleep mode to reduce power consumption. For these Devices, a downlink command is queued and transmitted when the Device opens a receive window after its next uplink. A successful write result in the interface does not necessarily mean that the physical Device has executed the command immediately.

7. Wired Device Management

Wired device data collection is achieved through three steps: creating a device, adding or importing Tags, and publishing. Wired devices communicate with the gateway over Ethernet or serial connections using standard industrial protocols.

Supported Protocols

For connection parameters, Tag addresses, and detailed configuration instructions for a specific Driver, select the applicable protocol in the E2C Field How To.

7.1 Before You Begin

• Make sure network addresses, serial settings, unit IDs, Tag addresses, and data types match the field device.
• 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.
• Make sure the network addresses, serial settings, Unit IDs, Tag addresses, and data types match the field Device.

7.2 Configuration Workflow

1. The following general workflow applies to all wired Device protocols supported by this system. The fields displayed when adding a Device or Tag vary according to the selected Driver and connection method. Complete the configuration according to the field Device documentation and actual communication parameters.
2. Create a Device, add or confirm Tags, save the settings, and publish the configuration.
3. Check the Device Status and real-time Tag data.

For wired Devices, add Tags individually or import a point table.

For protocol-specific connection parameters, Tag-address rules, and configuration examples, refer to the following supplemental guides where applicable:

• E2C Trinity Modbus Protocol (Southbound) User Guide
• E2C Trinity BACnet Protocol (Southbound) User Guide

7.3 Create a Wired Device

7.3.1 Add a Wired Device

1. Go to Data Collection > Device and click Add.
2. Select the Driver and enter the device name and connection parameters required by that Driver.
3. 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 requires IP Address, Port, and Slave Address, while OPC UA requires Server URL and Authentication Method. Use the field device parameters and the form displayed for the selected Driver.
• Device status shows as online only after data is reported for the first time.

Figure 7-1: Add a Wired Device

7.3.2 Add a DI/DO Device

1. Go to Data Collection > Device and click Add.
2. Select protocol IO Device > DO/DI and fill in the device information.
3. Click Save. An IO device can only be added once. The polling period supports millisecond level, minimum 100 ms, default 100 ms.
4. Click Read IO to automatically obtain the current gateway IO information. No manual Tag addition is required.
5. Use the mode toggle to switch DI/DO mode. The system reads the latest data based on the actual mode.

Note: When DI is in counting mode, counting does not start from 0 upon publishing. Click the clear button to reset the value to zero.

7.4 Add Tags

The system supports two ways to add Tags for wired devices: adding them individually and importing a point table.

7.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.

Figure 7-2: Add a Tag

7.4.2 Import a Point Table

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.

To reduce troubleshooting costs caused by batch import errors, it is recommended to add one tag manually first, verify communication, and confirm the address format is correct before performing the batch import.

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, 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.

Figure 7-3: Import a Point Table

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.
• The file must be in xls or xlsx format. Do not rename or reorder the column headers, merge or split cells, or insert blank rows.
• The system uses the Tag name to determine whether to add or update. Tag names must be unique within the same Device and within the same Tag Group.
• If a Group named in the point table does not exist, the system creates it automatically.

Warning: When Delete Tags is selected, the system deletes existing Tags 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, and SCADA Management.

7.4.3 Export Tags

• Export Point Table : Go to Data Collection > Device and click Export Point Table to export device Tags for import into other devices.

7.5 Publish and Verify

After Device or Tag information changes, click Publish Wired. 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.

Modifications requiring device synchronization take effect only after successful sync via Publish. Device-agnostic changes (such as Tag units or device descriptions) take effect in the system instantly without sync.

7.5.1 Verify Collected Data

1. Review the import result first if a point table was imported. Correct rejected or skipped entries and import again.
2. Publish the configuration, then check the collection status of the target Device in the Device list.

Figure 7-4: Device Status

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.

Figure 7-5: Data Monitoring

7.6 Understand 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 use periodic read results. 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.
• Success/Failure Count: Records successful and failed collection communication events to help evaluate communication quality. It is not a count of Device online or offline transitions.
• 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.

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.

7.7 Manage Devices and Tags

7.7.1 Modify the Value of a Writable Tag

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.

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: 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.

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.

7.7.2 Manage Devices

The system supports the following device management operations:

• Edit a Device: Modify device information.
• Copy a Device: The device name is not copied. Tags are copied without their associated Groups.
• Enable or disable a Device: A disabled Device stops collecting data, and downstream functions that depend on it can no longer receive new data. After enabling the Device again, check each downstream function.
• Delete a Device: Cannot be undone and invalidates downstream configurations. Creating another Device with the same name does not guarantee restoration of original downstream configurations.

Notes:

• After editing or copying a Device, save the changes and publish the configuration again.
• Before deleting a Device, make sure related functions no longer use it. After deletion, check and reconfigure every affected function.

7.7.3 Manage Tags

The system supports the following Tag management operations:

• Edit a Tag: Modify Tag information.
• Delete a Tag: Can affect configurations that depend on it.
• Batch delete Tags: Select multiple Tags and delete them together.

Notes:

• After editing a Tag, publish the configuration again.
• Before deleting a Tag, check and remove any associations that are no longer required.
• Auto-generated IO tags are system-protected and cannot be deleted manually.

8. Data to Cloud

8.1 Overview

Data to Cloud sends data collected or processed by the gateway to a third-party cloud platform, MQTT Broker, or business system that provides an HTTP API.

8.2 Before You Begin

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.
• The gateway can access the target Server Address 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 commands or field-device writeback, also confirm that the target Tag is set to Read/Write, the southbound protocol and field Device support write operations, and the operation has been tested in a safe environment.

8.3 Configuration Workflow

A third-party Cloud Service cannot select an individual Device Tag directly. Organize the Tags to be reported into a Tag Group before configuring the Cloud Service.

After configuring the Tag Group, select the applicable Cloud Service section based on the connection method provided by the target platform:

Use the following reading sequence:

• MQTT data reporting: Read Section 8.4 first, followed by Sections 8.5.2, 8.5.3, and 8.5.5. If no real MQTT service is available, read Section 8.5.1 first. For cloud commands or Tag writeback, also read Section 8.5.4.
• HTTP data reporting: Read Section 8.4 first, followed by Sections 8.6.1 and 8.6.2.
• Sparkplug B data reporting: Read Section 8.4 first, followed by Sections 8.7.1, 8.7.2, and 8.7.3.

Tags in the same Tag Group are reported as one data set. When planning Tag Groups, consider the business relationship between Tags, their update frequency, reporting interval, and the target platform's processing method. Avoid putting Tags with substantially different purposes or reporting frequencies in the same Group.

For every Cloud Service, 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.

8.4 Tag Groups

A Tag Group organizes the Device Tags to be reported and applies unified reporting rules to them.

8.4.1 Create a Tag Group

Figure 8-1 Example Tag Group configuration using Group_01 and distance

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 Configure Tag] and select the published Tags to be reported.
4. Save the configuration. The Tag Group can then be selected as the data source of a Cloud Service.

Select a reporting mode according to the application:

• Period: Sends data at a fixed interval. Use it when the target platform requires continuous, complete data snapshots.
• Change: Sends data when a Tag value changes. Use it for status changes, event notifications, or scenarios where lower traffic is preferred.
• Change & Period: Sends data immediately when a value changes and also at a fixed interval. Use it when both timely changes and data continuity are required.

Notes:

• [Report Type] and [Cycle Unit] cannot be changed after creation. Confirm the target platform's timeliness and data-volume requirements before the first save.
• If High-speed Data Collection is enabled for a Device with a polling interval below 1 second, the system automatically generates a corresponding High-speed Data Collection Group. Its Name, Cycle Unit, and Report Interval are inherited from the Device configuration and cannot be changed in Tag Groups.
• Duplicate Tag names are not allowed in the same Tag Group because the receiver cannot reliably identify the data by name.
• After changing the Tags or reporting rules in a Group, validate the data received by the target platform again.

8.5 MQTT Cloud Service

An MQTT Cloud Service reports Tag Group data to an MQTT Broker through Publish messages and can receive cloud commands through Subscribe messages. If only data reporting is required, do not configure a Subscribe message.

The complete configuration contains up to five steps. Skip the optional steps that do not apply to your use case:

1. 8.5.1 Prepare an MQTT Test Environment: Use this step only when no real MQTT service is available. Skip it when a real Broker or target platform is available.
2. 8.5.2 Create and Configure an MQTT Cloud Service: Select Standard MQTT, Azure IoT, or AWS IoT and establish the connection.
3. 8.5.3 Configure a Publish Message: Reports Tag Group data. Skip it only when MQTT is used exclusively to receive cloud commands without reporting data.
4. 8.5.4 Configure a Subscribe Message: Receives cloud commands or writes values to Tags. Skip it when only data reporting is required.
5. 8.5.5 Validate MQTT Data and Troubleshoot: Validate the connection, Publish messages, and Subscribe messages according to the actual configuration.

8.5.1 Prepare an MQTT Test Environment (Optional)

If a real MQTT Broker or target platform is available, use its connection parameters and skip this section. If no MQTT service is available, Mosquitto can be used as a test Broker and MQTTX can be used to verify message reception.

Figure 8-2 Example of a locally running Mosquitto test Broker

For complete test-environment preparation and example parameters, see Chapter 4, Configure MQTT Reporting and Validate Data, in the E2C Field Quick Start. Section 4.2, Prepare an MQTT Test Environment (Optional), describes the Mosquitto and MQTTX test environment, while Sections 4.3 through 4.5 provide the complete Tag Group, MQTT Cloud Service, Publish message, and data-validation example. The test environment validates only the basic data path and does not replace validation of the real platform's authentication, permissions, security, or data format.

8.5.2 Create and Configure an MQTT Cloud Service

Figure 8-3 Example interface for creating an MQTT Cloud Service

1. Go to Data to Cloud and click [Create Cloud Service].
2. Set [Cloud Service Type] to MQTT, enter the [Cloud Service Name], and save the configuration. Cloud Service Type cannot be changed after creation.
3. Under [Connection Configuration], select the [Cloud Platform Type]. The system supports Standard MQTT, Azure IoT, and AWS IoT.
4. Complete the connection configuration according to the target-platform requirements and save it.
5. Check the Cloud Service connection status. After the connection succeeds, configure a Publish or Subscribe message as required.

Note: [Connected] means only that the system is connected to the MQTT Broker. It does not mean that Tag data has been successfully reported. Continue by configuring a Publish message and validating actual data at the receiver.

8.5.2.1 Standard MQTT

[Response Topic] and [Qos] under [Advanced Configuration] allow a custom function to return processing results to a specified Topic. Leave them unconfigured when the target platform does not require this response.

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

When sending production data over a public or untrusted network, use SSL/TLS and authentication as required by the target platform to avoid transmitting credentials and business data in plain text.

8.5.2.2 Azure IoT

8.5.2.3 AWS IoT

8.5.3 Configure a Publish Message

Figure 8-4 Example interface for configuring an MQTT Publish message

Saving the connection configuration does not start data 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 [Group] and [Qos].
3. Configure [Function Code] only when the default message structure must be changed for the target platform.
4. Save the configuration 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 the existing Subtopic configuration. Confirm the impact before making the change.

8.5.4 Configure a Subscribe Message (Skip When Only Reporting Data)

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. Under [Subscribe Topic], enter the [Topic Alias] and [Topic], and select the [Qos].
3. To return the processing result to the target platform, configure the [Topic] and [Qos] under [Response Topic]. Otherwise, leave them empty.
4. Configure [Tag Configuration] and [Function Code] to define downstream-message parsing and Tag write operations.
5. Save the configuration and confirm that the Subscribe message is enabled.

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

For writeback, also confirm the following:

• The target Device and Tag exist, have been published, and communicate normally.
• The target Tag is set to Read/Write.
• The write value matches the Tag data type and the range accepted by the field Device.
• The southbound protocol and field Device support write operations.

8.5.5 Validate MQTT Data and Troubleshoot

8.5.5.1 Validate a Publish Message

1. Confirm that both the Cloud Service and Publish message are enabled and that the Cloud Service status is [Connected].
2. Under [Data Collection], confirm that the source Tag has a valid [Latest Value] and that its [Update Time] continues to refresh.
3. On the real platform or in MQTTX, subscribe to the [Topic] configured in the Publish message.
4. Wait for at least one complete Report Interval and confirm that messages are received.
5. Check the fields, values, timestamps, data format, and reporting frequency.

8.5.5.2 Validate a Subscribe Message and Tag Writeback

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], confirm that the target Tag value changes as expected and that the field Device performs the intended action.
4. If a [Response Topic] is configured, confirm that the target platform receives the processing result.

8.5.5.3 Common Issues

If these checks do not identify the problem, go to [Debug Logs] and locate the error by Cloud Service name, event time, and error message.

8.6 HTTP Cloud Service

An HTTP Cloud Service sends Tag Group data to a cloud platform, Web server, or another system that provides an HTTP API through HTTP POST or PUT requests. Each HTTP Cloud Service is directly associated with one Group and does not require a separate Publish message.

An HTTP Cloud Service contains the following two steps:

1. 8.6.1 Create and Configure an HTTP Cloud Service: Configure the target API, Headers, and Tag Group. If the target API accepts the default JSON format, do not enable Packet Reassembly or configure Function Code.
2. 8.6.2 Validate HTTP Data and Troubleshoot: Confirm the request and actual data on the target server or in the business system.

8.6.1 Create and Configure an HTTP Cloud Service

Figure 8-5 Example interface for creating an HTTP Cloud Service

1. Go to Data to Cloud and click [Create Cloud Service].
2. Set [Cloud Service Type] to HTTP Server, enter the [Cloud Service Name], and save the configuration.
3. Select the [Method], enter the complete [Server Address], and configure Headers according to the target API requirements.
4. Select the [Group].
5. Configure [Packet Reassembly] and [Function Code] only when the default request body must be transformed, and set [Request Timeout] according to the target-server response time.
6. Save the configuration 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, its name must match exactly, and it must have a valid value. Otherwise, the system may generate an invalid address and the request may fail.

When sending production data over a public or untrusted network, use HTTPS and do not enter production credentials in a public test service.

8.6.2 Validate HTTP Data and Troubleshoot

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

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 HTTP response, server logs, and actual data on the target platform.

If these checks do not identify the problem, go to [Debug Logs] and continue troubleshooting with the target-server logs.

8.7 Sparkplug B Cloud Service

A Sparkplug B Cloud Service sends a Tag 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.

A Sparkplug B Cloud Service contains the following three steps, all of which are required to complete data reporting:

1. 8.7.1 Create and Configure a Sparkplug B Cloud Service: Establish the Broker connection and configure the Sparkplug B node identifiers.
2. 8.7.2 Configure Data Publishing: Associate the Tag Group and confirm the Device ID.
3. 8.7.3 Validate Sparkplug B Data and Troubleshoot: Check the Edge Node, Device, Tag values, and data quality on the target platform.

8.7.1 Create and Configure a Sparkplug B Cloud Service

Figure 8-6 Example interface for creating a Sparkplug B Cloud Service

1. Go to Data to Cloud and click [Create Cloud Service].
2. Set [Cloud Service Type] to Sparkplug B, enter the [Cloud Service Name], and save the configuration.
3. Enter the connection information and configure authentication and SSL/TLS as required by the target platform.
4. Save the configuration 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 impact 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.

8.7.2 Configure Data Publishing

1. Under [Message Management], click [Add].
2. Select the [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 target platform's Device plan. A Device ID must be unique within the same Sparkplug B Cloud Service.
4. Save the configuration 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 is_valid in the Sparkplug B Metric PropertySet to false and sets error_code to 500 (GeneralError). The target platform should evaluate Tag values together with is_valid and error_code.

8.7.3 Validate Sparkplug B Data and Troubleshoot

1. Confirm that the Cloud Service and Publish configuration are enabled and that the connection status is normal.
2. Confirm that the referenced Tag Group 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 Tag values, update times, and data quality continue to update.

If these checks do not identify the problem, go to [Debug Logs] and continue troubleshooting with the Broker logs and node status on the target Sparkplug B platform.

8.8 Function Code Advanced Configuration (Optional)

Use Function Code when the default message format or processing logic does not meet the requirements of the target platform. Function Code is supported in the following configurations:

• MQTT Publish messages: transforms the data sent to the MQTT Broker.
• MQTT Subscribe messages: parses received messages and performs Tag writes or other processing.
• HTTP Packet Reassembly: transforms the data sent in an HTTP request.

Sparkplug B does not support Function Code.

If the target platform can use the default message format provided by the system, Function Code is not required. For common examples, see Appendix A.2, Function Code Reference. For input and return structures, system APIs, and additional examples, see the E2C Trinity Script Development Guide.

8.8.1 Edit and Validate Function Code

The Function Code editor provides the following supporting functions:

To configure Function Code:

1. Write or adjust the Function Code according to the requirements of the target platform.
2. Use Data Format to confirm the input structure, and use View Tags, View Parameters, and View Help as required.
3. Enter representative test JSON data and click Run.
4. Under Result, confirm that the returned result is not empty and that its structure, fields, and values meet the requirements of the target platform.
5. Save the configuration only after the result has been verified.

If the function returns an empty result or an error, check the input structure, field names, parameter references, and return structure. Related execution information can also be reviewed under Debug Logs.

8.8.2 Use RSA Encryption or Decryption in Function Code

When the target platform requires RSA encryption or decryption of MQTT or HTTP message content, Function Code can use the following methods:

Before using these methods, upload the required public-key or private-key file as described in 17.4 Certificates.

The file name used in Function Code must include its file extension and exactly match the File Name displayed on the Certificates page. Before saving the Function Code, use Run to check the result. If the method returns an empty string, check the file name and extension, key type, and input content.

Note: Certificates in this section stores public-key and private-key files referenced by Function Code for RSA encryption or decryption. TLS certificates used by MQTT, HTTP, or Sparkplug B connections must still be uploaded or selected in the connection configuration of the applicable Cloud Service. These certificates serve different purposes.

9. 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 as mapping sources. The service configuration, mapping, and validation workflow is the same for all 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.

9.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.

9.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.

9.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.

9.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.

9.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 Field, follow the interface names, configuration rules, and supported features described in this manual and displayed in the actual software interface.

9.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.

The Port Number must not conflict with another service running on the gateway. If the service cannot start, check whether the configured Port is already in use. When changing the Port, configure the Modbus TCP client to use the same value.

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

9.3.2 Add a Slave

Modbus TCP mappings are organized by Slave. Each Slave has an independent Modbus Mapping Table.

Figure 9-1 Example interface for adding a Modbus TCP Slave

1. In the Slave list, click [Add].
2. Enter the [Mapping Table Name] and [Slave Address].
3. Click [Save]. Open the new Modbus Mapping Table to add Tag mappings.

9.3.3 Add Modbus Mappings

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

9.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:

9.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.

9.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.

9.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.

9.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.

If verification fails, check the applicable symptom below:

9.4 Configure Opcua Server

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

9.4.1 Create and Configure the Service

Figure 9-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.

9.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.

9.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.

9.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.

9.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:

9.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 Field, follow the interface names, configuration rules, and supported features described in this manual and displayed in the actual software interface.

9.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.

9.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.

9.5.2 Add BACnet Mappings

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

9.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.

9.5.2.2 Batch Add Mappings

Figure 9-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.

9.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.

9.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.

9.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.

10. Scenario Management

Scenario Management converts time schedules, system startup, field data, alarms, and cloud commands into automated tasks. A Scenario defines when a task is triggered, while an action defines the operation performed after the trigger. By combining Scenarios and actions, users can automate repetitive operations and respond to changes in field conditions.

10.1 Scenario Types

The system supports the following six Scenario types:

These examples illustrate common configuration approaches. Select the actual trigger conditions and actions according to the project requirements.

10.2 Action Types

Each Scenario can use one or more of the following action types:

An action can be configured in either of the following ways:

• Shared action: Create the action under Action Management, and then use Reference when configuring a Scenario. This is suitable when the same action is used by multiple Scenarios.
• Scenario-specific action: Use Add while configuring a Scenario. This action is used only by the current Scenario.

10.3 Before You Start

Complete the applicable preparations for the Scenario type and action:

• For Data Linkage, publish the target Device and Tags under Data Collection, and confirm that the Tags provide valid data.
• For Alarm Control, create the required Alarm Rule and confirm that the alarm can be triggered.
• For Cloud Command, configure the required Cloud Service and prepare the subscription Topic.
• For Write Tag Value, confirm that the target Tag supports writing and that Device communication is normal.
• For DO Control, check the target DO, external wiring, and connected equipment.
• For Execute Function, prepare and verify the function according to the intended processing or control logic.

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 Device, Tag, value, DO wiring, and site conditions. Use safe, controlled test conditions that do not affect normal operations.

10.4 Configuration Workflow

Configure and verify a Scenario as follows:

1. If the same action will be reused by multiple Scenarios, create a shared action under Action Management. See Section 10.5.
2. Create a Scenario, configure its trigger conditions and actions, and save it. See Section 10.6.
3. Enable the Scenario and verify the trigger and action results under safe test conditions. See Section 10.7.

If the action is used only by one Scenario, skip Step 1 and create the action directly while configuring the Scenario.

10.5 Configure a Shared Action (Optional)

Use Action Management to configure an action that can be referenced by multiple Scenarios.

Figure 10-1 Action Management page

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 settings for the selected action type.
5. Click Save.

After the action is saved, it can be selected through Reference when creating or editing a Scenario.

Use the operation controls on the applicable tab to edit or delete a shared action. Before editing or deleting an action, confirm whether it is referenced by an active Scenario and verify the affected Scenarios after the change.

10.6 Create a Scenario

1. Go to Scenario Management and click Add.
2. Enter the Scenario name and select the required Scenario Type.
3. Configure the trigger according to the selected Scenario type.

Figure 10-2 Add Scenario page

4. In the action area, click Reference to select a shared action from Action Management. To create an action used only by the current Scenario, click Add, select Execute Function, Write Tag Value, or DO Control, and complete the applicable settings.
5. Check the trigger condition and action target, and then click Save.

After saving, return to the Scenario list and enable the Scenario when it is ready to run.

10.7 Verify the Scenario

Verify the Scenario under safe, controlled conditions before using it for normal operations.

1. Select test equipment, a test Tag, or a DO that will not affect normal operations.
2. Enable the Scenario.
3. Trigger the Scenario according to its type:

• For Scheduled Control or Cycle Control, wait for the configured time or interval.
• For Power-on Execution, restart the system under controlled conditions.
• For Data Linkage, make the selected Tag meet the configured condition.
• For Alarm Control, trigger the selected alarm.
• For Cloud Command, send a test message to the configured subscription Topic through the selected Cloud Service.

4. Confirm that the function runs, the target Tag value changes, or the DO and connected equipment respond as expected.
5. Restore the test condition, written value, or equipment state after verification.

For Cycle Control, observe more than one execution interval to confirm that the Scenario runs at the configured frequency.

10.8 Manage Scenarios

Use the operation controls on the Scenario Management page to edit, delete, enable, or disable a Scenario.

Figure 10-3 Scenario management operations

• Edit: Modify the Scenario settings. After saving the change, verify the trigger and action again.
• Delete: Delete a Scenario that is no longer required. Confirm the deletion in the confirmation dialog.
• Enable: Start monitoring the configured trigger condition and allow the Scenario to run its actions.
• Disable: Stop the Scenario from running its actions without deleting its configuration.

Before deleting a Scenario or shared action, confirm that the configuration is no longer required.

10.9 Troubleshooting

10.9.1 An Enabled Scenario Does Not Run

Check the following items:

• Confirm that the Scenario is enabled.
• For Scheduled Control and Cycle Control, confirm that the gateway time, time zone, and configured execution time or interval are correct.
• For Data Linkage, confirm that the selected Tag provides valid data and meets the configured condition.
• For Alarm Control, confirm that the selected alarm has been generated.
• For Cloud Command, confirm that the selected Cloud Service is connected and that the subscription Topic matches the Topic used by the sender.
• Confirm that the Scenario references the intended shared action or contains the required Scenario-specific action.

10.9.2 The Scenario Runs but the Target Does Not Respond

• For Execute Function, check the function logic and the Device and Tag names referenced by the function.
• For Write Tag Value, confirm that the target Tag is writable, the Device is online, and the value is valid for the target equipment.
• For DO Control, check the selected DO, output settings, external wiring, and connected equipment.
• If a shared action is used, confirm that the correct action is referenced and that its current settings are valid.
• Repeat the verification with safe test equipment or conditions after correcting the configuration.

11. Logic Orchestration

Logic Orchestration builds on Node-RED's native visual flow capabilities and provides four dedicated nodes for subscribing to Device Tag and Tag Group data, updating device or Virtual Tag values, and controlling DO outputs. Users can create custom flows by dragging and connecting nodes to combine data input, conditional logic, data processing, and device control. Processing results written to Virtual Tags can also be reported to the cloud through Data to Cloud.

11.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 Node-RED nodes and the dedicated nodes under E2C Node. User-installed third-party nodes may cause compatibility issues and are outside the supported product scope.

11.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: select the object to read, update, or control, and then connect the dedicated node to the required built-in Node-RED nodes according to the business logic. For information about built-in nodes and additional orchestration methods, see the Node-RED documentation.

11.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.
• Confirm that Node-RED is installed and can be opened from the Logic Orchestration page.

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.

11.4 Create and Deploy the Flow

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

11.4.1 Configure the Inject Node

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

Figure 11-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.

11.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.

11.4.3 Connect and Deploy the Flow

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

11.5 Trigger and Verify the Flow

1. Trigger the Inject node manually.

Figure 11-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.

11.6 Troubleshooting

11.6.1 The Flow Does Not Run

• Confirm that the Node-RED flow is fully connected and that Deploy has been clicked.
• Confirm that the Inject node has been triggered and that the upstream node sends data to the downstream node.
• Check that the connections between nodes are in the correct direction.

11.6.2 The Target Tag Is Not Updated

• Confirm that the target Tag is published and writable and that Device communication is normal.
• Confirm that Mapping is set to {payload.Pressure}.
• Confirm that the upstream message contains the Pressure field and that the field name and capitalization match exactly.
• Confirm that the value data type and range meet the requirements of the target Tag and Device.
• After correcting the configuration, deploy the flow again and repeat the verification under safe test conditions.

12. Alarm Management

Alarm Management monitors abnormal states in Device Tags. Based on Alarm Rules, the system generates alarms for review and handling, displays active alarms under Real-time Alarms, and retains traceable records under Alarm History. When external notifications are required, the system can send alarms to specified Contacts through SMS, Email, or WeCom (Webhook Bot).

12.1 Functions

• Real-time Alarms: View and manually handle active alarms.
• Alarm Rules: Define the monitored Tags, trigger conditions, alarm content, alarm level, and notification strategy.
• Alarm History: Search and delete historical alarm records.
• Alarm Tags: Categorize alarms by location, Device type, business system, or responsibility.
• Alarm Notification Template: Configure the notification content for SMS, Email, and WeCom, together with the sending settings required for Email.
• Contacts: Maintain recipients and bind each Contact to SMS, Email, SMS and Email, or WeCom (Webhook Bot) through Alarm Notification Method.

12.2 Before You Start

Before configuration, make sure that:

• The Devices and Tags to be monitored have been published under Data Collection, and their Latest Value and Update Time are normal.
• You have planned the alarm names, levels, and categories.
• The recipients' phone numbers are available if SMS notifications are required.
• The recipients' email addresses and the sending mailbox's SMTP settings are available if Email notifications are required.
• A Webhook Bot has been created in the target WeCom group and its Robot Address is available if WeCom notifications are required.
• The current account has permission to configure Alarm Rules, Alarm Notification Template, and Contacts.

If alarms only need to be viewed and handled in this system, skip the notification-template and Contact configuration and disable Push Enabled in the Alarm Rule.

12.3 Configuration Workflow

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

1. Step 1: Configure Alarm Tags to categorize alarms. See Section 12.4.
2. Step 2: Configure Alarm Notification Templates to define the message content and related sending settings for each notification channel. See Section 12.5.
3. Step 3: Configure Contacts to maintain destination information and select an Alarm Notification Method for each Contact. See Section 12.6.
4. Step 4: Create an Alarm Rule to define the monitored objects, trigger conditions, and notification strategy. See Section 12.7.
5. Step 5: Verify alarm generation and notification delivery, and then view or handle alarms to confirm that the configuration is effective. See Sections 12.8 and 12.9.

If alarm categorization is not required, skip Step 1.

If external notifications are not required, skip Steps 2 and 3 and disable Push Enabled when creating the Alarm Rule.

If external notifications are required, configure the template for the applicable channel. Under Contacts, enter a Phone Number, Email, or Robot Address for the Contact and select the matching Alarm Notification Method.

Alarm History uses the default system storage rules. To adjust the maximum number of records or retention period, see Section 12.10.

12.4 Configure Alarm Tags (Optional)

Alarm Tags categorize alarms by location, production line, Device type, business system, or responsibility.

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

An Alarm Rule can be created without an Alarm Tag. Skip this step if alarm categorization is not required.

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.

12.5 Configure Alarm Notification Templates (When Notifications Are Required)

Alarm Notification Template defines the message content and related sending 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.

Figure 12-1 Alarm Notification Template

12.5.1 Configure an SMS Template

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

The destination phone number comes from Contacts. The Contact must contain a Phone Number, and Alarm Notification Method must be set to SMS or SMS and Email. When creating the Alarm Rule, also select the Contact under Push Target.

12.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 mail 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. The Contact must contain an Email address, and Alarm Notification Method must be set to Email or SMS and Email. When creating the Alarm Rule, also select the Contact under Push Target.

12.5.3 Configure a WeCom Template

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

The WeCom Robot Address is not configured in the template. It comes from Contacts. The Contact must contain a Robot Address, and Alarm Notification Method must be set to WeCom (Webhook Bot). When creating the Alarm Rule, also select the Contact under Push Target.

12.6 Configure Contacts (When Notifications Are Required)

Contacts maintains alarm recipients and their destination information. Alarm Notification Method specifies the notification channel bound to each Contact.

1. Go to Alarm Management > Contacts and click Add.
2. Complete the Contact information and select Alarm Notification Method.
3. Click Save.

Make sure that the destination information required by the selected Alarm Notification Method is complete. Otherwise, the notification cannot be delivered. For example, when SMS and Email is selected, both Phone Number and Email must be provided.

12.7 Create an Alarm Rule

1. Go to Alarm Management > Alarm Rules and click Add.
2. Complete the Alarm Rule configuration.
3. Review the configuration and click Save.

Figure 12-2 Alarm Rule configuration

The main Alarm Rule fields are described below.

12.7.1 Configuration Notes

If the selected Tags belong to multiple Devices, only Trigger if any condition is met is supported.

If external notifications are not required, disable Push Enabled. The Alarm is still displayed under Real-time Alarms and retained under Alarm History after it ends or is handled.

Select one or more Contacts under Push Target. The system sends notifications according to each Contact's Alarm Notification Method and its Phone Number, Email, or Robot Address.

12.8 Verify Alarms and Notifications

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

1. Make the target Tag satisfy the trigger conditions of the Alarm Rule.
2. Go to Alarm Management > Real-time Alarms, confirm that the alarm appears, and verify its name, level, content, and Tag information.
3. Under Data Collection, confirm that the alarm count for the applicable level is correct in the Device statistics.
4. If external notifications are enabled, confirm that every Push Target receives the alarm through its bound notification method.
5. Restore the test condition and resolve the actual abnormal condition, and then use Manual Clear when required.
6. Return to Data Collection and confirm that the applicable alarm count has decreased.
7. Go to Alarm History and confirm that the alarm record can be found and that its information is correct.

12.9 View and Handle Alarms

12.9.1 Real-time Alarms

Go to Alarm Management > Real-time Alarms to view active Alarms.

Figure 12-3 Real-time 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 status first, and then use Manual Clear for an individual Alarm or selected Alarms.

Note: Manual Clear handles only the active Alarm record in this system. It does not correct the actual abnormal condition of the Device or Tag. Resolve and confirm the field abnormality before performing this operation.

12.9.2 Alarm History

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

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.

12.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. The maximum value is 5000.
3. Set Discard after expiration. The maximum value is 180 days.
4. Click Save.

The system monitors both the record limit and retention period:

• When the total number of records reaches the configured limit, the system removes the oldest records on a first-in, first-out basis to make space for new records.
• The system performs a scheduled daily check and deletes records older than the configured number of days, regardless of whether the record limit has been reached.

12.11 Troubleshooting

12.11.1 No Alarm Is Generated

• Confirm that the target Device and Tag have been published and that the Tag provides valid data.
• Confirm that Device, Tag, Condition, and Comparison Value are configured correctly.
• Confirm that the selected any-condition or all-condition trigger logic meets the actual requirement.
• Check Trigger Interval and Trigger Count and confirm that the number of anomalies meets the trigger requirement.

12.11.2 An Alarm Is Generated but No Notification Is Received

• Confirm that Push Enabled is enabled in the Alarm Rule, and check Notification Method and its related parameters.
• Confirm that the correct Contacts are selected under Push Target.
• Under Contacts, check each Contact's Alarm Notification Method and corresponding information: Phone Number for SMS, Email for Email, and Robot Address for WeCom.
• Confirm that the applicable Alarm Notification Template has been saved. For Email, also check SMTP Server, Username, License Code, SSL, and Port.
• Confirm that the gateway can access the applicable SMS, Email, or WeCom service.
• After correcting the configuration, trigger the alarm again under controlled conditions and verify the notification.

12.11.3 Push by Rule Does Not Send a Notification

• Confirm that the number of anomalies within Time Window has reached Anomaly Count.
• Distinguish Trigger Interval and Trigger Count in the alarm-generation conditions from Time Window and Anomaly Count in the notification conditions. The former determine when an alarm is generated; the latter determine when Push by Rule sends a notification.
• To send a notification whenever a new alarm is generated, select Push Immediately according to the project requirements.

13. SCADA Management

SCADA Management is used to create and run visual monitoring pages. A page can display real-time Device Tags from Data Collection, alarms, charts, and key indicators. It can also provide Device control functions according to the project design and user permissions.

SCADA Management provides two usage modes:

• Design mode: Create and maintain SCADA pages.
• Runtime mode: View SCADA pages and perform authorized operations.

For detailed page-design instructions, component parameters, complete examples, and troubleshooting, see the E2C Trinity SCADA Manual.

13.1 Before You Begin

Before creating a SCADA project, make sure that:

• The Devices and Tags to be displayed have been published under Data Collection, and the Tags provide valid real-time data.
• If the page displays alarm information, the required Alarm Rules have been configured and can generate alarms correctly.
• You have planned the required Web Pages, Mobile Pages, or Popup Pages and the objects to display or control on each page.
• If the page includes Device control, the target Tags are writable, Device communication is normal, and the impact on field equipment has been assessed.
• The current account has the permissions required to create, design, run, or share a SCADA project.

13.2 Configuration Workflow

Creating and using a SCADA project normally involves the following steps:

1. Step 1: Create or import a SCADA project. See Section 13.3.
2. Step 2: Enter design mode, complete the page design, and save it. See Section 13.4.
3. Step 3: Enter runtime mode and verify the page display and interactions. See Section 13.5.
4. Optional Step 4: Share the SCADA runtime page. See Section 13.6.

13.3 Create or Import a SCADA Project

Go to SCADA Management in the left navigation menu. This menu is located below Alarm Management. Select an operation according to the task:

Figure 13-1 SCADA Management page

• Click Add to create a SCADA project.
• Click Import to import an existing SCADA project.
• Click Template Management to manage reusable SCADA templates.

After the project is created, select Design, Run, or Share on its project card.

13.4 Use Design Mode

Click Design for the target project. The system opens SCADA Designer in a new browser window.

Figure 13-2 SCADA Designer

Design mode provides the following main functions:

• Create and manage Web Pages, Mobile Pages, and Popup Pages.
• Build page layouts by dragging components onto the canvas.
• Bind real-time Device Tags from Data Collection and alarm information.
• Configure value, status, chart, list, and control components.
• Configure interactions such as page switching, popups, and conditional display.
• Preview, save, and reuse page designs.

After completing the design, save the project and return to SCADA Management to enter runtime mode. For detailed Designer operations, see the E2C Trinity SCADA Manual.

13.5 Use Runtime Mode and Verify the Page

1. Click Run for the target project.
2. The system opens the runtime page in a new browser window.
3. Confirm that real-time Tags, alarms, charts, and key indicators are displayed as designed.
4. If the page contains interactions or Device controls, verify the applicable operations under safe conditions.

Figure 13-3 SCADA runtime page

The content of the runtime page depends on the SCADA project design. Users with Designer permission can perform Device control operations configured on the page. Users with Client permission can only view the runtime page.

Warning: Before controlling a Device, verify the target Device, Tag, and write value, and confirm that the site conditions are safe. This prevents an incorrect operation from affecting field equipment.

13.6 Share a SCADA Runtime Page (Optional)

A SCADA runtime page can be shared through an intranet link or QR code. The recipient's network must be able to access the gateway.

1. Click Share for the target project.
2. Under Permission, select the option that grants Client or Designer permission.
3. Under Valid Period, select 1 Day, 3 Days, 7 Days, 14 Days, Permanent, or Custom Days.
4. Click Copy Link or Save QR Code.

A user with Designer permission can share links that grant Client or Designer permission. A user with Client permission can only share a link that grants Client permission.

Click Share Records to view generated sharing records and manage links that are no longer required.

Warning: A visitor with Designer permission may be able to control Devices from the runtime page. Verify the recipient and permission before sharing, and disable the link when it is no longer required.

14. Configuration Migration and Batch Deployment

Use Export Config and Import Config to migrate configurations from a source gateway to a target gateway, reducing repetitive work in similar projects or multi-gateway deployments. The exported configuration file can also be retained as a backup of the current configuration.

The import result depends on the software version, hardware resources, and License capacity of the target gateway. Unsupported configurations may be skipped. Insufficient License capacity or incompatible configuration structures may cause the entire import to fail.

Note: This chapter applies only to configuration migration between E2C Field gateways. Different E2C Trinity software products may have different functional modules and configuration structures. Do not migrate configuration files directly between different products.

14.1 Import and Export Scope

The exact scope of the configuration file is described on the Export Config page. Configurations and data not listed on that page are outside the scope of this function.

Note the following exclusions and migration limitations:

• Logs are not included in the import or export.
• SCADA Management projects are not included in the system configuration file. Use the separate import and export functions under SCADA Management.
• DI/DO configurations cannot be migrated through this function. The system skips these configurations during import without preventing other supported configurations from being imported.

14.2 Before You Begin

Before migrating configurations:

• Confirm that both the source and target gateways run E2C Field.
• Confirm that the configuration on the source gateway is complete and operating normally.
• Compare the gateway models, number of serial ports, and other hardware resources of the source and target gateways.
• Confirm that the target gateway License supports the Devices, Tags, protocols, and functions included in the configuration file.
• Use the same software version on the source and target gateways where possible. Avoid importing a configuration exported from a newer software version into an older version.
• If the target gateway already contains important configurations, back them up using Export Config before importing another file.

14.3 Configuration Workflow

A complete configuration migration consists of two steps:

1. Export the configuration from the source gateway.
2. Import the configuration to the target gateway and review the import result and migrated configuration.

If the configuration file is required only as a backup, complete the export step only.

14.4 Export the Configuration

Figure 14-1 Export Config page

1. Sign in to E2C Field on the source gateway.
2. Go to System Settings > Export Config.
3. Review the page description and confirm the configuration scope included in the file.
4. Click Export Configuration and save the generated configuration file locally.

Do not manually modify the contents or format of the exported file. Doing so may cause the import to fail.

14.5 Import the Configuration

Figure 14-2 Import Config page

1. Sign in to E2C Field on the target gateway.
2. Go to System Settings > Import Config.
3. Click Select File and select the JSON configuration file exported from the source gateway.
4. Click Import Configuration and wait for the system to finish processing.
5. Review the import result and check for any skipped or failed configurations.

A successful import result does not necessarily mean that every item in the configuration file was imported. The system may skip protocols unsupported by the target gateway, configurations that reference unavailable serial ports, or other incompatible content. After the import, always review both the import result and the actual configuration on the target gateway.

14.6 Configuration Compatibility and Processing Rules

Note: An unsupported newly added protocol and a structural change to an existing protocol produce different import results. The former normally causes only Devices using that protocol to be skipped. The latter may prevent the target version from parsing the configuration file and cause the entire import to fail.

14.7 Verify the Import

After the import is complete:

1. Review the import result and identify failed or skipped configurations.
2. According to the scope listed on the Export Config page, confirm that Devices, Tags, and related configurations were imported as expected.
3. Check for configurations skipped because of DI/DO, serial-port availability, protocol support, or software-version differences.
4. Confirm that the imported Devices, Tags, and functions do not exceed the License capacity of the target gateway.
5. Reconfigure any items that could not be migrated according to the hardware environment of the target gateway.
6. Publish the imported Data Collection configuration.
7. Check Device connection status, the latest Tag values, and related functions to confirm that the imported configuration operates correctly.

14.8 Troubleshooting

14.8.1 Configuration Import Fails

• Confirm that the configuration file was exported from E2C Field and has not been modified manually.
• Confirm that the target gateway software version is the same as or compatible with the source gateway version.
• Confirm that the target gateway License capacity can accommodate the Devices, Tags, and functions in the configuration file.
• Check whether the configuration structure of the same protocol cannot be parsed because of software-version differences.
• Resolve the compatibility issue before importing again. Do not repeatedly import the same file without addressing the cause.

14.8.2 The Import Succeeds but Some Configurations Are Missing

• Review the skipped items in the import result.
• Check whether the missing configuration is DI/DO or references a serial port unavailable on the target gateway.
• Confirm that the target software version supports the applicable protocol.
• Reconfigure the skipped items according to the target gateway hardware, License, and protocol capabilities.

14.8.3 Imported Devices Have No Data

• Confirm that the imported Data Collection configuration has been published.
• Check the target gateway network addresses, serial-port parameters, wiring, and Device communication conditions.
• Confirm the Device connection status, Tag status, latest value, and update time.
• If the configuration references a network or serial-port environment specific to the source gateway, reconfigure it for the target site.

15. User and Role Management

E2C Field uses the existing user accounts on the RobustOS Pro gateway. Users do not need a separate E2C Field account and can sign in with their RobustOS Pro username and password.

RobustOS Pro and E2C Field are responsible for different parts of access management: