Quick Start

To give users a more intuitive and clear understanding, we use a practical example of "Data Collection and Reverse Control Based on a Modbus TCP Simulated Device" to guide users step-by-step, facilitating quick comprehension of the software's core functions and common configuration methods.

1. Configuration Workflow

2. Preparations

3.2.1. Hardware Preparation

Prepare an EG3110, EG5120, or EG5200 edge gateway.
Connect the computer's network port to the gateway's LAN port as shown in the topology diagram below, ensuring they are on the same subnet (in this example, assume the computer's IP is 192.168.0.89, and the gateway's LAN IP is 192.168.0.1).

3.2.2. Software Preparation

If the E2C Factory application is pre-installed on your gateway device, you can skip this step.

1) Firmware Version Requirement: ≥ 2.3.106
The firmware version information can be viewed from the gateway WEB homepage, as shown below:

Note: If the version is lower, please contact customer service or sales to obtain the latest firmware for upgrade. Specific upgrade operations can refer to the ROS Pro User Manual.

2) Install E2C Factory Software
Follow the prompts in the image below to perform the software installation.

3) Run and Open the E2C Factory Operation Interface
After installation, you can find the "Edge Computing" menu item in the left menu bar or the "Edge Computing - Data Collection" menu item at the top and open the E2C Factory software operation page.

A new tab will open, presenting the software main page as shown below(A new device will have no content):

3.2.3. Test Simulation Environment Preparation
1) Modbus Simulator
This example uses PeakHMI MB TCP Slave as the Modbus TCP Slave simulator. Users can download and install it from the PeakHMI official website.
After installation, start the simulator. Click Windows - Register data menu item to open the Tag configuration interface.

2) MQTT Broker
This example chooses to install Mosquitto on the same computer as the test MQTT Broker service. Users can download and install it from the Mosquitto website(https://mosquitto.org/download/) or choose their familiar MQTT Broker platform or software.

3. Collecting Modbus Southbound Data

3.1. Adding a Southbound Device

Select the Data Collection page, click the New Device button, and a dialog box as shown below will pop up.

Key Parameters:

• Name: Modbus Simulator (custom name for the southbound device)
• Protocol: Modbus TCP
• IP Address: 192.168.0.89 (simulator's IP address)
• Port: 502 (simulator listening port, default is 502)
• Slave Address: 1 (default Slave ID for PeakHMI simulator)
• Polling Period: 10 (seconds)
  
  After clicking Save, the newly added device will appear in the device list.

3.2. Adding Monitoring Tags

Select the newly added device, then click the Add button on the upper right side to open the Add Monitoring Data dialog box.

• Name: The Tag name, typically using a physically meaningful name
• Function Code: Corresponds to the function code in the Modbus protocol, options: 01, 02, 03, 04
• Address: Modbus register address. (Note: Usually calculated starting from 0; in the PeakHMI simulator, it starts from 1)
• Data Type: Data type, options: ushort, short, uint, int, float, etc.
• Read/Write Permission: Controls Tag read/write permissions. In Modbus, Holding Registers are typically read-only.

For ease of testing, we first add two Tags:

After adding, click Publish. Wait a moment (about one polling cycle), and you can see the latest values collected for each Tag in the Tag list page.

At this point, we have completed the configuration for southbound Data Collection and successfully collected data.

4. Reporting Data to MQTT

Next, we need to report the collected output voltage and output current values to the MQTT platform. Additionally, we will need to report the instantaneous power.
Before starting, we need to understand the reporting mechanism and the organization of the reported data. This introduces the concept of a Tag group. We can assign Tag data from different devices to a group. Note that a Tag can belong to at most one group. All reported data is based on groups. Each group can be configured with different reporting strategies (Periodic, Change, Change+Periodic).

4.1. Creating a Group

On the Data Collection page, click New Group, and a dialog box as shown below will pop up:

• Name: grp-group name
• Report Type: Change+Periodic - i.e., reporting strategy, options: Periodic, Change, Change+Periodic
• Period Unit: Seconds/Milliseconds; currently DI/DO protocols support millisecond-level.
• Report Period: When Report Type = Periodic or Change+Periodic, reports periodically at this time interval.

4.2. Adding Tags to the Group

Select the grp group we just added from the list on the left side of the Group page, then click the Add button on the right side. This will pop up the Add Monitoring Data to Group dialog box.

Select all Tags here, click the ">" button to add the selected Tags to the current group. Click OK to complete the operation; no publishing is required.

4.3. Creating an MQTT Service Connection

1) Create a Cloud Service
Select the Data to Cloud menu item, click New Cloud Service.

• Cloud Service Name: cloud - custom name for the cloud service for easy memory
• Cloud Service Type: MQTT

2) Configure Cloud Service Connection Information
Select the cloud cloud service just created to configure connection information.

• Server Address: 192.168.0.89 (change according to actual situation)
• MQTT Client ID: power_data
• Port: 1883
• MQTT Version: v3.1
  After configuration and saving, you can click Test Connection. Wait a moment to see if the cloud service status changes to Connected Successfully. Otherwise, check if the configuration information is correct, if the MQTT Broker server is running normally, or if the server's firewall is blocking traffic on port 1883.

4.4. Configuring Upload Groups

After successful connection, you can add specific data groups that need to be uploaded and their corresponding topics by pressing the "Add" button to the right of "message management" section.

After saving, we can open an MQTT client on the PC (here MQTTX is used; users can download and install it from the MQTTX official website) to observe if data from the device can be received. Normally, you should see a reported message like the one below:

json

{
  "messageId": "86d70ab8-401b-4cdd-b92b-f6ad8d0ca603",
  "messageType": "normal",
  "groupName": "grp",
  "groupTime": 1763524978582,
  "payload": {
    "V_out": {
      "time": 1763524968000,
      "value": "220.00",
      "deviceName": "Modbus Simulator",
      "Tag": "V_out"
    },
    "I_out": {
      "deviceName": "Modbus Simulator",
      "Tag": "I_out",
      "time": 1763524968000,
      "value": "2.45"
    }
  }
}

Up to this point, we have successfully completed southbound device Data Collection and uploaded the collected data to the specified MQTT platform.

4.5. Adjusting Reported Data Content and Format

As you can see from the results, the format of the reported data in the previous section may not be what we want. We hope to format the data according to the following method:

json

{
  "sn": "123456",
  "time": 1756880727169,
  "data": {
    "V_out": 220,
    "I_out": 2.0
  }
}

Through analysis, we know that converting from the existing format to the target format requires the following operations:

• Redefinition of data format
• Data type conversion
• Numerical calculation
  All these needs can be achieved by writing simple JS scripts:
  In Message Management, select the topic that needs adjustment, click the edit icon on the right side to open the Edit Publish dialog box.

We can copy the following code into the Function Code editing box:

javascript

// Extract time
const time = msg.groupTime
// Extract Tag data packet
const payload = msg.payload
// Assemble cloud upload data format
const result = {
  "sn": "123456",
  "time": time,
  "data": {
    "V_out": payload.V_out.value,
    "I_out": payload.I_out.value
  }
}
return result;

Click Save, then observe through the MQTT client whether the data published to MQTT has changed. Normally, a message in the following format should appear:

json

{
  "time": 1763542439184,
    "data": {
    "V_out": "220.00",
      "I_out": "2.45"
  },
  "sn": "123456"
}

Of course, you can modify the simulator's values and observe whether the data published to the cloud updates accordingly. Users can verify this themselves.

5. Alarm Triggering and Notification

Now we want to perform threshold judgment on the collected volTage value. When the volTage is greater than 920 volts, the system should trigger a high-volTage alarm and notify the pre-set user's email address via email.

5.1. Configuring Alarm Push Templates

5.2. Configuring Target Email Addresses

On the Contact tab page, you can add target users' email address information.

5.3. Adding an Alarm Rule

We can add an alarm rule under the Alarm Rules tab. This rule includes configuration for alarm source, trigger conditions, alarm level, and alarm push, etc.

• Name - Name of the alarm rule
• Device - Select the device for alarm detection
• Tag - Select the Tag for alarm detection
• Alarm Level - Set the urgency level of the alarm
• Alarm Condition - Set the trigger condition for the alarm
• Alarm Content - Set the meaning of the alarm
• Enable Push - Choose whether to push messages to specified users when the alarm is triggered
• Notification Mechanism - When alarm push is enabled, you can choose the timing or frequency of pushes
• Push Target - Select the user to receive alarm messages; this user list can be configured in section 3.4.2.

As shown in the image above, we add an alarm rule for output volTage V_out greater than 920 volts.
Now, modify the V_out in the simulator to 930.24 (can be any value greater than 920). Wait a moment, and we should see a high-volTage alarm message appear in Real-time Alarms.

6. Receiving and Processing Cloud Commands

6.1. Adding a Switch Tag

Tip: Remember to Publish after modifying Tags.

6.2. Adding Cloud Command Subscription

In the cloud service item created in the previous steps, you can add a subscription to a specified topic.

In the Add Subscription dialog box, fill in the following information:

• Topic - site01cmd
• Topic Alias - switch
• QoS - 1
• Belonging Group - grp
  Command Issuance Format:

json

{
  "device": "Modbus Simulator",
    "switch": "on"
}

To enable the gateway to trigger corresponding actions (writing to Modbus registers) upon receiving the command, you can add the following code in the Function Code dialog box.

javascript

let data = JSON.parse(msg);
let deviceName = data.device;
let swStatus = data.switch === 'on' ? 1 : 0;
Edge.WriteTags(deviceName, [{"Tag": "Switch", "value": swStatus}])

The final subscription configuration is as shown below:

After completing the above configuration, we can send commands to the topic site01cmd via MQTTX.

After sending the command, the bit at address 00001 of Coils in the simulator should change to 1. Subsequently, observing the latest reported data, the latest status of "switch" should also become true.

At this point, we have successfully completed a relatively comprehensive quick experience of Data Collection, cloud reporting, alarm configuration, and command issuance. During this process, there may be some anomalies. Don't worry; we can usually use a step-by-step troubleshooting method. For example, if data cannot be collected, we can first check if the simulator is configured correctly, if the PC's firewall is blocking external access to the simulator, if the connection information in the gateway is configured correctly, etc. If the issued command is not executed as expected, we can output the received message to the log via the <font style="color:rgb(15, 17, 21);background-color:rgb(235, 238, 242);">Edge.Log</font> function. Analyze through the log information whether the command was successfully received, if the command format is correct, etc.

For detailed instructions on how to use the functions, please refer to the "Edge2Cloud (E2C) Factory Software Manual".