Software Version: V2.0.3.0Document Version: V1.0

About This Document

This guide is intended for engineers, system integrators, and commissioning personnel using E2C Field for the first time. It provides repeatable examples for software installation, LoRaWAN Device onboarding, MQTT Data to Cloud, Modbus TCP Data Forwarding, local alarms, and optional Wired Device Data Collection.

This guide describes only the key settings required for initial validation. For all supported protocols, fields, function rules, and advanced settings, see the E2C Field Software Manual.

www.robustel.com

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

Trademark Notice: Robustel is a trademark of Guangzhou Robustel Co., Ltd. Other trademarks and trade names mentioned in this guide 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, the contents of this document may be updated or revised without notice.

Revision History

Terms and Abbreviations

Software Terms

Industry Terms and Abbreviations

Chapter 1 Quick Start Overview

1.1 Common Scenarios and Reading Guide

This guide uses the distance Tag collected from one LoRaWAN Device to introduce common tasks. When using this system for the first time, complete Chapter 2 and the LoRaWAN workflow in Section 3.2, and then read the function chapters required by the project. Wired Device Data Collection is provided as an optional alternative in Section 3.3.

Use project-specific parameters when a real Device or target system is available. When a real environment is unavailable, use the simulation or auxiliary validation tool introduced in the applicable chapter.

1.2 Third-Party Tools

When no real Device or target system is available, this guide uses the following third-party tools for simulation or auxiliary validation. If a real Device, MQTT service, or actual target system is available, use the actual environment instead. The corresponding tools are not required.

A real sensor is required to validate LoRaWAN radio join and data reporting. Offline Codec testing validates only the decoding logic and does not replace a real LoRaWAN radio link.

Chapter 2 Before You Begin

This chapter checks the gateway and RobustOS Pro, downloads and installs E2C Field, confirms the system time, and then opens E2C Field.

2.1 Workflow

Complete the following five tasks:

1. Check the gateway model, RobustOS Pro firmware version, and RAM.
2. Download E2C Field.
3. Install and enable E2C Field on the gateway.
4. Confirm that the gateway Time Zone and System Time are correct.
5. Open E2C Field.

2.2 Check the Gateway and RobustOS Pro

This guide uses LG3120. The environment requirements are as follows:

Connect the management computer to the network of the gateway LAN interface. Make sure that the computer and gateway are on the same subnet and can communicate. This guide uses the following example addresses:

Replace these addresses with those planned for the actual site.

1. 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.
2. Check the gateway model, RobustOS Pro version, and RAM on the home page and compare them with the requirements in this section.
3. If the firmware version is earlier than V2.4.111, obtain the applicable firmware and follow the RobustOS Pro upgrade guide for the gateway model and current version before continuing.

2.3 Download and Install the Software

Download the required files from E2C Field APP Download.

Skip the installation steps if the required version of E2C Field is already installed. Otherwise, complete the following operations:

1. In the gateway web interface, go to [System] > [App Center].
2. Select the E2C Field package, click [Install], and follow the on-screen prompts to confirm the installation and restart.
3. After the gateway restarts, sign in again and confirm that e2c-field appears in the installed application list.

Figure 2-1 Install E2C Field in App Center

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

2.4 Confirm the Gateway Time

E2C Field uses the RobustOS Pro system time and does not maintain a separate clock. Before using the 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 Alarm Management. Set the correct time before collecting, 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 network environment:

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

Figure 2-2 NTP Client configuration for an online gateway

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

Notice: Set the correct time before production data is generated whenever possible. If the gateway time is changed during operation, check the latest data.

2.5 Open E2C Field

1. Log in to the gateway management interface.
2. Locate [Edge Computing] in the left or top navigation area.
3. Open E2C Field. The operation page opens in a new browser tab.

Figure 2-3 Open E2C Field from the gateway management interface

Chapter 3 Collect Device Data

This chapter uses a LoRaWAN Device as the primary data source. Complete Section 3.2 and confirm that its data is received normally before continuing to Chapters 4–6. Section 3.3 describes Wired Device Data Collection and is optional. Skip it unless the project also needs to collect data from a Modbus TCP or other Wired Device.

3.1 Workflow

Complete the following four tasks:

1. Prepare the LoRaWAN Device information and confirm that the applicable Payload Codec is available.
2. Create and publish a Device Profile.
3. Add and publish one LoRaWAN Device.
4. Confirm that the distance Tag has a valid Latest Value and Update Time.

After completing the primary workflow, continue to Chapter 4, 5, or 6 according to the project requirements. Complete Section 3.3 only when a Wired Device Data Collection example is also required.

3.2 Onboard One LoRaWAN Device

This section describes the shortest workflow for onboarding a LoRaWAN Device. A real Device is required to perform and validate the configuration. You may read this section to understand the workflow, but do not create a Device using a false Device EUI, Join EUI, or Application Key.

3.2.1 Prepare Device Information and Check the Payload Codec

Before starting, prepare the following information:

• A LoRaWAN Device using the Region frequency plan for the project, with the gateway LoRa antenna installed correctly.
• The Device LoRaWAN Region, MAC Version, Regional Parameters Revision, Activation Method, Device Class, Expected Uplink Interval, and heartbeat period.
• Device EUI, Join EUI when applicable, and Application Key for OTAA.
• The Device manufacturer manual and the method for producing an uplink, such as power-on, restart, or manual reporting.

Go to [LNS Configuration] > [Payload Codecs] and find the Device model:

• If the applicable Codec is available, continue to create a Device Profile.
• If the Codec is unavailable, follow How to Convert LoRaWAN Sensor Codec Formats and Import to E2C Field to convert, import, run the Uplink Test, and publish the Codec, or see the detailed tutorial in the E2C Field Software Manual. Then return to this section and continue.

3.2.2 Create a Device Profile

A Device Profile defines the network parameters shared by sensors of the same model. Create one Profile and reuse it when adding identical sensors instead of entering the frequency and join settings for every Device.

Figure 3-1 Create the LDDS75 Device Profile

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

After confirming the configuration, click [Publish]. A Device can reference the Profile only after it is published.

3.2.3 Add a LoRaWAN Device and Confirm Tags

This step registers a physical LoRaWAN sensor with the gateway and selects the Tags to collect.

Go to [Data Collection] > [LoRaWAN Devices], click [Add Device], and configure the Device as follows. Replace Device EUI, Join EUI when applicable, 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 Codec. Keep the Tags required by the project, confirm their names and data types, and then click [Confirm]. This guide uses the distance business Tag, whose Data Type is int (int32), in the subsequent chapters.

After returning to the Device list, click [Publish LoRa] in the upper-right corner and wait until synchronization succeeds.

Figure 3-2 Add the LoRaWAN Device

3.2.4 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. Confirm that distance is a Device Tag with Data Type int (int32), and check its [Latest Value] and [Update Time].
4. Trigger another uplink according to the Device instructions, or wait for one complete Device reporting interval, and confirm that [Update Time] refreshes.
5. If the Device does not join or distance has no value, check [Events] for the Device. For raw messages and decoding results, go to [LNS Configuration] > [Live Frames].

Figure 3-3 Publish and validate the distance Tag

After distance has a valid Latest Value, continue to Chapter 4, 5, or 6. These chapters use LDDS75_Sensor_01 and distance as the primary example data source.

3.3 Collect One Modbus TCP Tag (Optional)

This section is optional. Skip it if you are using only the LoRaWAN Device to complete this guide. If you complete this section, you can also select the Inlet_Pressure Tag of Packaging-Machine-03 as a data source in the subsequent chapters. When using Inlet_Pressure for Modbus TCP Data Forwarding, configure the mapped data type and read quantity according to its short (int16) Data Type instead of copying the int (int32) settings used for distance in Chapter 5.

This section uses Inlet_Pressure as the example Tag. If a real Modbus TCP Device is available, use the actual Device connection parameters and Tag address. To avoid affecting production equipment, select a Tag that can be read safely and whose value can be checked easily.

If no real Modbus TCP Device is available, start with Section 3.3.1. If a real Device is available, skip Section 3.3.1, start with Section 3.3.2, and use the actual Device parameters.

3.3.1 Prepare Simulated Modbus TCP Data (Optional)

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

Figure 3-4 Configure the optional Modbus TCP simulator

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

3.3.2 Add a Modbus TCP Device

Figure 3-5 Configure the optional Modbus TCP Device

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

3.3.3 Add the Inlet_Pressure Tag

In the Tag list of Packaging-Machine-03, click [Add], complete the form as follows, and then click [Save].

3.3.4 Publish and Validate Wired Data

Click [Publish Wired] in the upper-right corner of the page to apply the new Wired Device and Tag configurations.

Figure 3-6 Validate the optional Inlet_Pressure Tag

1. Confirm that the collection status of Packaging-Machine-03 is normal.
2. Open its Tag list and confirm that Inlet_Pressure has a [Latest Value] and that [Update Time] continues to refresh.
3. Change the value corresponding to 400001 in PeakHMI and wait for one or more Polling Cycles.
4. Confirm that the [Latest Value] of Inlet_Pressure follows the simulator value.

If no data is displayed or the value is incorrect, check the data source, network, IP Address, Port, Slave Address, Function Code, Address, Data Type, and [Debug Log].

Chapter 4 Configure MQTT Reporting and Validate Data

This chapter adds the normally collected distance Tag of LDDS75_Sensor_01 to a Tag Group and reports its latest value to an MQTT Broker through MQTT. If a real MQTT Broker or target platform supporting Standard MQTT is available, skip Section 4.2 and enter the actual connection and security parameters provided by the target service when creating the Cloud Service.

If no real MQTT service is available, use Mosquitto and MQTTX to prepare a test environment as described in Section 4.2. This environment is used only to validate the data path and does not represent a production cloud platform or deployment.

4.1 Workflow

Complete the following four tasks:

1. If no real MQTT service is available, prepare an MQTT test environment. (Optional)
2. Create a Tag Group and add distance.
3. Create an MQTT Cloud Service.
4. Configure a Publish message and validate the data at the receiver.

4.2 Prepare an MQTT Test Environment (Optional)

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

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

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

Figure 4-1 Prepare an MQTT Test Environment

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

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

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

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

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

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

4.3 Create a Tag Group

Go to [Data to Cloud] > [Tag Group], click [Create Group], complete the form 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.

A LoRaWAN Device sends new radio data according to its own reporting or heartbeat behavior, while the Tag Group publishes the latest value already received by E2C Field according to the interval configured in this section. Changing the MQTT reporting interval does not change how frequently the LoRaWAN Device sends an uplink.

If you completed the optional Wired Device workflow in Section 3.3, you can also add Inlet_Pressure to this or another Tag Group. Duplicate Tag names are not allowed within the same Tag Group because the receiver would not be able to identify the data accurately by name.

4.4 Create an MQTT Cloud Service

Figure 4-2 Create and configure an 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 complete [Connection Configuration] as follows:

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

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

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

4.5 Configure a Publish Message and Validate Data

Figure 4-3 Configure an MQTT Publish message

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

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

Validate Reported Data

1. When using the Mosquitto test environment, connect MQTTX to the corresponding Broker and subscribe to /field/quickstart/data. Keep the Client ID automatically generated by MQTTX and confirm that it is different from E2C_Field_Gateway_01 used by E2C Field.
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. To validate a value change, change the measured distance only when it is safe to do so, and then manually trigger an uplink according to the Device instructions or wait for its next scheduled uplink.
5. Confirm that the distance value received by the MQTT receiver follows the Latest Value displayed in [Data Collection].

If the Cloud Service is connected but no data is received, return to [Data Collection] and confirm that distance has a valid Latest Value. Then check that Group_01 contains distance, that the Publish message is enabled, that the configured Topic Alias exactly matches the subscribed Topic, and that the receiver is connected to the same Broker.

Chapter 5 Forward Data Through Modbus TCP

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

This chapter maps the distance Tag of LDDS75_Sensor_01 to Modbus Holding Registers so that a SCADA system, HMI, host application, or other Modbus TCP client can read it. Because distance uses the int (int32) Data Type, the mapped value occupies two consecutive 16-bit Holding Registers. This example validates reading only and does not configure writeback. Use the actual target system for validation where possible. Use Modbus Poll only when the actual target system is temporarily unavailable or additional troubleshooting is required.

If the project objective is to forward LoRaWAN Device data through BACnet/IP, do not use this chapter as a substitute for that workflow. See the E2C Trinity LoRa Device to BACnet/IP Data Forwarding User Guide.

5.1 Workflow

Complete the following four tasks:

1. Create and configure a Modbus TCP Slave service.
2. Add one slave.
3. Map distance to two Modbus Holding Registers as an int (int32) value.
4. Validate the data in the actual target system or Modbus Poll.

5.2 Create and Configure a Modbus TCP Slave 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. Configure [Basic Settings] as follows, and then click [Submit].

If Port 502 is already used by another service on the gateway, select an unused Port and configure the client to use the same value.

5.3 Add a Slave

Figure 5-1 Add a Modbus TCP Slave

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

Click [Add] in the slave list, enter the following values, and then click [Save].

[Mapping Table Name] cannot be changed after saving. Slave Addresses within the same Modbus TCP Slave service must be unique.

5.4 Add One Modbus Mapping

Open the Modbus Mapping Table for Tank_A_SCADA and click [Add]. Select the Device and Tag, configure the mapped value, mapped data type, Function Code, and initial address, and then click [Save].

Different Modbus clients may use protocol offsets starting at 0 or reference addresses such as 40001. Configure the client according to the Function Code and Mapped Address shown in the mapping table, and confirm the address base used by the client. If the client uses a protocol offset starting at 0, Mapped Address 1 may need to be entered as 0. For Modbus Poll in this example, enter Address 1.

5.5 Validate Forwarded Data

5.5.1 Use the Actual Target System

1. Open the [Status] tab for Modbus TCP Slave and confirm that the service is started.
2. In the target system, enter gateway address 192.168.0.1 and service Port 502.
3. Set Slave ID to 1 and use Function Code 03 to read two Holding Registers starting at Mapped Address 1.
4. Interpret the two registers as one signed int (int32) value using the byte order configured in E2C Field, and compare the result with distance under [Data Collection].
5. Change or observe the measured distance only when it is safe to do so. After the Device sends the next uplink, confirm that the client value follows the updated Latest Value.

5.5.2 Use Modbus Poll (Optional)

Suggested download: Modbus Poll official download page

1. Start Modbus Poll and go to [Connection] > [Connect].
2. Select Modbus TCP/IP in the connection settings, set IP Address to 192.168.0.1 and Server Port to 502, and then connect to the gateway.
3. Go to [Setup] > [Read/Write Definition] and configure the read request as follows:

• Slave ID: 1
• Function: 03 Read Holding Registers (4x)
• Address: 1
• Quantity: 2

4. Configure the display so that the two registers are interpreted as one signed 32-bit integer using the byte order configured in E2C Field.
5. Confirm that Modbus Poll can read distance and compare the result with the Latest Value displayed in [Data Collection].
6. To validate an update, change the measured distance only when it is safe to do so, and manually trigger an uplink or wait for the next scheduled uplink. Confirm that Modbus Poll follows the updated Latest Value.

Figure 5-2 Validate Data Forwarding with Modbus Poll

If the client cannot connect, check that the service is enabled and started, that the gateway address and Port are correct, and that the network and firewall permit the connection. If the client connects but the value is incorrect or does not update, check the Slave ID, Function Code, address base, Quantity, Mapped Data Type, and byte order, and confirm that distance still has a valid Latest Value.

Chapter 6 Create and Validate an Alarm

This chapter creates a high-distance Alarm Rule based on the distance Tag of LDDS75_Sensor_01 and validates alarm activation, automatic recovery, and history. The example validates local alarms within E2C Field and does not configure external notifications. For notification-channel configuration, see the complete software manual.

6.1 Workflow

Complete the following three tasks:

1. Create an Alarm Rule that monitors distance.
2. Make distance meet the condition and check Real-time Alarms.
3. Restore the test value and confirm that the alarm recovers automatically and appears in Alarm History.

6.2 Create an Alarm Rule

Figure 6-1 Configure the distance Alarm Rule

Go to [Alarm Management] > [Alarm Rules], click [Add], configure the rule as follows, and then click [Save].

This example sets [Trigger Interval] to 1 sec and [Trigger Count] to 1 so that an alarm is generated promptly after the test condition is met. Keep the default values for the other fields.

Before saving the test rule, check the current distance value. Use 3000 only when the measured distance can safely move above and back to or below this value. Otherwise, replace the Comparison Value with a temporary threshold that can be triggered and restored safely without affecting production.

6.3 Trigger and Validate the Alarm

1. Make the measured distance greater than 3000 only when it is safe to do so.
2. Manually trigger an uplink according to the Device instructions, or wait for the next scheduled uplink. Confirm under [Data Collection] that the Latest Value of distance is greater than 3000.
3. Wait for the Alarm Rule evaluation.
4. Go to [Alarm Management] > [Real-time Alarms], confirm that Distance_High appears, and check its level, content, Device, Tag, Value, and Time.
5. Go to [Data Collection] and confirm that the alarm count for the applicable level has increased on the Device card.

Figure 6-2 View Real-time Alarms and alarm status

If no alarm is generated, confirm that the real-time Tag value meets the condition, that the correct Device and Tag are selected, and that Condition, Comparison Value, Trigger Interval, and Trigger Count are correct.

6.4 Restore the Test Condition and View Alarm History

1. Return the measured distance to 3000 or below under safe conditions.
2. Manually trigger another uplink, or wait for the next scheduled uplink, and confirm under [Data Collection] that the Latest Value no longer meets the alarm condition.
3. Return to [Real-time Alarms] and confirm that the alarm recovers automatically.
4. Go to [Data Collection] and confirm that the applicable alarm count on the Device card has decreased.
5. Go to [Alarm Management] > [Alarm History] and confirm that the Distance_High record can be found.

Figure 6-3 View Alarm History

If the alarm condition is still present, do not use Manual Clear as a substitute for resolving the actual abnormal condition. Correct the condition or restore the test value before handling the alarm record.

Chapter 7 Troubleshooting

This chapter groups common checks under general system operation, LoRaWAN Device onboarding, optional Modbus TCP Data Collection, MQTT Data to Cloud, Modbus TCP Data Forwarding, and Alarm Management. First confirm that the gateway network and system time are correct. For Data to Cloud, Data Forwarding, or Alarm Management issues, confirm that upstream Data Collection is operating normally. If the cause remains unclear, review [Debug Log] and the complete software manual.

7.1 General System Issues

7.2 LoRaWAN Device Onboarding Issues

7.3 Modbus TCP Data Collection Issues (Optional)

7.4 MQTT Data to Cloud Issues

7.5 Modbus TCP Data Forwarding Issues

7.6 Alarm Management Issues