IoT System for Level Monitoring and Control with Point-to-Point LoRa Between Siemens S7-1200 PLCs

Abstract

Industrial supervision can be expanded through the Internet of Things (IoT) without moving the control logic outside the PLC. This study evaluates a level-monitoring and control architecture using a point-to-point LoRa link between two Siemens S7-1200 PLCs; LoRaWAN is used solely as a conceptual architectural reference, and no gateway, network server, or OTAA/ABP procedures were implemented. An Arduino Uno with an Ethernet Shield W5100 exchanges variables with the PLC through Modbus TCP and transfers them via UART to Heltec LoRa ESP32 modules. Factory I/O simulates the process, and Adafruit IO provides remote supervision. The field campaign covered twelve locations between 10 and 120 m and 1200 frames. Reception, packet loss, RSSI, SNR, and the latency value calculated by the firmware were recorded. Overall reception was 94.17%, packet loss was 5.83%, and the mean latency value was 727.17 ms. The main contribution is the separation of local control from wireless communication and the quantitative evaluation of the link. Because the PLC maintained control when frames were lost, the solution is suitable for supervising slow processes, but not for critical loops. The results are specific to the evaluated radio and firmware configuration.

1. Introduction

Industry 4.0, the Internet of Things (IoT), and the Industrial Internet of Things (IIoT) are now widely used in industrial automation. Together, they link field devices, industrial controllers, and digital platforms so that plant personnel can supervise processes, analyze data, and make better-informed decisions [1,2]. PLCs, supervisory control and data acquisition (SCADA) systems, and IoT services can therefore operate within more flexible and interoperable architectures [3]. Building such systems requires more than adding a connected device; automation hardware, industrial protocols, and digital services must work as a coordinated whole [3,4].

Industry 5.0 broadens this transformation by placing greater emphasis on people, sustainability, and resilience. In the architecture studied here, the control decision remains in the PLC, remote supervision supports rather than replaces local control, and the process can continue when the external IoT connection is unavailable [5]. A recent review likewise identifies edge computing, digital twins, IoT, and human–machine collaboration as important enabling technologies for Industry 5.0 [6].

LoRa and LoRaWAN are particularly useful when small packets must travel long distances without high energy demand [7,8]. LoRa provides the radio-frequency physical layer, whereas LoRaWAN adds the network architecture, including access control, gateways, and network servers [9,10]. Link studies commonly report received signal strength (RSSI), signal-to-noise ratio (SNR), and packet delivery ratio (PDR), because these metrics describe coverage and reliability from different perspectives [11,12]. The radio tests in this study used raw point-to-point LoRa between two Heltec LoRa ESP32 modules. LoRaWAN is discussed only as a conceptual model for possible future access control, security, gateways, and network services; none of those LoRaWAN functions formed part of the field experiment. Previous work also shows that radio settings, scalability, energy use, and simulation tools should be considered during design rather than after deployment [13].

A tank-level value is not simply information for a display. It determines when the pump starts, when the valves open or close, and when an alarm must be raised. Recent studies have therefore connected cisterns and water tanks to IoT platforms, allowing operators to check levels remotely and reducing routine manual inspections [14,15]. Research on LoRa/LoRaWAN water-management systems also shows that these technologies can carry water-related data from dispersed or hard-to-reach locations [14,16]. Other low-cost LoRa implementations send water variables to gateways, local servers, or visualization platforms [11].

Factory I/O and Adafruit IO had separate roles in the system. Factory I/O reproduced the process and allowed the automation strategy to be checked before any physical installation [17,18]. Adafruit IO organized the selected variables in feeds and web dashboards for remote viewing. It supported supervision, but the PLC remained responsible for every control decision [19].

Against this background, we developed an IoT architecture for monitoring and controlling the level in a simulated process. The Siemens S7-1200 retains the main control program. An Arduino Uno with an Ethernet Shield W5100 bridges Modbus over the Transmission Control Protocol (Modbus TCP) and the Universal Asynchronous Receiver-Transmitter (UART) interface used by the Heltec LoRa ESP32 modules. The study separates the local control loop from the wireless supervision layer and then examines the link quantitatively at several distances. Its practical value lies in retaining the PLC program and existing inputs and outputs while preventing radio failures from interrupting local control. The PLC itself is not claimed as a scientific novelty.

1.1. Related Work and Contribution

LoRa and LoRaWAN are common choices in water-management projects because distributed sensors can communicate without extensive cabling. Monitoring and leak-detection studies frequently highlight their range and low energy demand [14]. Reviews of the field also cover water-quality monitoring, tank and reservoir control, and distribution networks [16]. Across these applications, continuous data acquisition, wireless transport, and remote visualization appear repeatedly as core functions [20].

Abubeker and Nuthalapati proposed a cloud-connected LoRaWAN system that measures tank level, displays it remotely, and controls a pump [21]. Saban et al. combined a PLC, a web application, and LoRa/LoRaWAN for an agricultural installation [22]. Both are relevant to the present work, although our architecture leaves the control decision in the PLC and treats the wireless path as an external communication layer. In related water-quality research, Sendra et al. tested a LoRa network in coastal areas [23], and Murti et al. combined sensors, LoRa communication, and cloud storage [24].

A useful comparison requires more than listing the final results, so the measurement procedures used in the closest studies were also examined. Saban et al. [22] carried out an outdoor campaign on a farm in Valencia. Their gateway was installed at approximately 24 m, and a LoRa Mote II was moved among eleven locations from 50 to 795 m. Ten messages were exchanged at each point using 867.1–868.5 MHz, a bandwidth of 125 kHz, spreading factor 7, coding rate 4/5, and +14 dB transmission power. Reception was determined from confirmed messages, while RSSI and SNR were recorded at each distance. Reception remained at 100% up to 415 m, decreased to 90% at 550 m, and ranged from 50% to 70% between 640 and 795 m. RSSI ranged from −36 to −109 dBm and SNR from 9 to −4 dB. Their study did not report a timing metric equivalent to the firmware-calculated latency value used here.

Abubeker and Nuthalapati [21] evaluated an ESP32 LoRa tank-automation system with a JSN-SR04T ultrasonic sensor in several environments. They related the distance between the node and gateway to energy consumption, RSSI, and SNR, but their timing definition differed from the firmware-calculated latency value used here. In the present campaign, the transmitter antenna was positioned at a height of 5 m and the receiver antenna at 2 m. Tests were performed at twelve positions from 10 to 120 m, with 100 frames per position, a frequency of 915 MHz, a bandwidth of 125 kHz, and one attempt per frame. Reception ranged from 85% to 100%, RSSI from −91 to −126 dBm, and the recorded latency value from 361 to 1382 ms. These published values are used as quantitative reference points rather than direct comparisons because the frequency, topology, antenna heights, hardware, number of messages, and timing procedures were not the same.

The papers suggested during review also illustrate how low-power embedded nodes can be adapted to very different tasks. Vivek et al. combined LoRa and GPS to track children [25]. Maheswaran et al. used temperature sensors, an ESP32, and a Telegram bot for cold-chain monitoring [26]. Although neither application concerns tank control, both show that embedded nodes can acquire and transmit field information. The defining feature of our proposal is that the Siemens S7-1200 PLC retains control authority.

Many embedded solutions place both acquisition and control in the microcontroller. Here, those functions remain in the Siemens S7-1200, while the Arduino-W5100 and LoRa ESP32 provide the communication interface. Factory I/O was used to verify the process, while only the variables needed for supervision were sent to the IoT layer. This division of control, communication, and visualization is consistent with IIoT architectures that distribute tasks among field equipment, edge resources, and digital services [27].

1.2. Research Objective and Questions

The study aimed to design and evaluate a modular IoT architecture that transports level variables and actuator states between PLC-based systems without moving the control decision outside the Siemens S7-1200. Three questions guided the work: (1) Can the PLC-Arduino-LoRa path exchange the required variables while the PLC retains its program? (2) How do reception, RSSI, SNR, and recorded latency change with distance? (3) What do the recorded timing value and packet loss imply for supervision and for any future control action that depends on the wireless link? Therefore, the contribution lies in the functional separation and the experimental definition of the conditions of use, not in the incorporation of a single hardware component.

2. Materials and Methods

An applied experimental approach was used to design, implement, and test the IoT architecture. The work was divided into three practical stages: simulation of the level process in Factory I/O, control with Siemens S7-1200 PLCs, and wireless communication through the Arduino-W5100 bridge and Heltec LoRa ESP32 modules. This arrangement allowed each functional layer to be examined separately. The PLC kept the process logic, while the external devices extended communication and remote supervision. The principal hardware comprised Siemens S7-1200 PLCs (Siemens AG, Munich, Germany), Arduino Uno boards (Arduino S.r.l., Monza, Italy), Ethernet Shield W5100 boards based on the W5100 controller (WIZnet Co., Ltd., Seongnam, Republic of Korea), and Heltec WiFi LoRa 32 V3 modules (Heltec Automation, Chengdu, China). The software included TIA Portal (Siemens AG, Munich, Germany; exact release not retained), Factory I/O 2.x (Real Games, Gondomar, Portugal; exact minor release not retained), and Adafruit IO (Adafruit Industries, LLC, Brooklyn, NY, USA; web platform without a fixed desktop version). The electronic modules used in the prototype were sourced from a local electronics re-tailer in Latacunga, Ecuador.

Node separation was the independent variable. Packet reception, packet loss, firmware-calculated latency, RSSI, and SNR were treated as dependent variables. The transmitter remained at one location with its antenna at 5 m, while the receiver was moved among the test points with its antenna at 2 m. Antenna orientation, the 100-frame test size, and the communication settings were kept unchanged at each location. These controls made the field campaign an experimental evaluation of the link rather than merely a functional demonstration of the prototype.

2.1. Application of the OSI Model to the Proposed Architecture

The OSI model provided a practical reference for organizing the communication path [28,29]. In the prototype, the lower layers correspond to identifiable hardware elements: RJ45 cabling, electrical signaling, UART communication, the LoRa antennas, and the sub-GHz radio link of the Heltec LoRa ESP32 boards.

Ethernet, IP addressing, and Modbus TCP carry the variables from the Siemens S7-1200 to the Arduino Uno and its W5100 shield. The bridge then passes the values to LoRa for transmission to the remote node, without requiring any change to the PLC program. At the application end, Factory I/O provides the process simulation and Adafruit IO provides remote visualization. Figure 1 summarizes this mapping.

Figure 1. OSI model applied to the proposed communication system. Note: the figure represents the evaluated implementation; LoRaWAN is only cited as a conceptual architectural reference, and the implemented radio link corresponds to point-to-point LoRa.

2.2. System Architecture and Implementation

The prototype was assembled around three functional blocks. Factory I/O reproduced the tank, the Siemens S7-1200 PLCs executed the control sequence, and the Arduino-W5100 plus Heltec LoRa ESP32 hardware moved the selected variables across the wireless link. Adafruit IO provided the remote view [19]. Working with these blocks separately made it easier to verify the prototype step by step before considering a physical installation [30].

The PLC was programmed in TIA Portal and connected to the Arduino-W5100 over Ethernet using Modbus TCP [31]. Arduino collected the selected PLC variables and forwarded them by UART to the Heltec LoRa ESP32, which performed the wireless transmission. Control therefore stayed in the PLC; the remaining devices only carried the data.

Adafruit IO displayed the system variables through feeds and web dashboards. Because supervision was kept separate from industrial control, users could view tank level, actuator states, and LoRa-link conditions without changing the PLC program. Figure 2 summarizes the complete transmitter–receiver architecture.

Figure 2. General architecture of the IoT system for level monitoring and control using an S7-1200 PLC and a point-to-point LoRa link.

2.3. Equipment and Software Used

Hardware and software were chosen to match the available industrial automation equipment, support the required protocols, and allow the prototype to be assembled in modules. Table 1 lists each component and its role in the system.

Table 1. Equipment and software used in the proposed architecture.

Equipment/Software	Main Function	Technical Note
Siemens S7-1200 PLC	Runs the process logic and reads the required variables.	Controls tank level, pump operation, valve states, and alarms.
PC	Programming, simulation, and process supervision.	Hosts TIA Portal, Factory I/O, and the monitoring tools used in the tests.
Arduino Uno	Interface between the PLC network and the LoRa node.	The W5100 supplies the Modbus TCP Ethernet port; Arduino forwards the data to the ESP32 over 9600 bit/s UART (8N1).
Ethernet Shield W5100	Ethernet interface for the PLC connection.	Carries Modbus TCP traffic on the local wired network.
Heltec LoRa ESP32	Point-to-point wireless transmission.	Combines the ESP32, LoRa radio, and an OLED display on one board.
Factory I/O	Simulation of the tank-level process.	Allows the control sequence to be checked before physical tests [17,18].
LoRa antenna	Radio-frequency element of the link.	Radiates and receives the sub-GHz signal in the selected band.
TIA Portal	PLC programming and communication setup.	Defines the process variables, control blocks, and network settings.
RJ45 Ethernet cable	Wired connection between PLC and Arduino.	Links the PLC Ethernet port to the W5100 shield.

2.4. Process Variables

The variables were selected from the level-control sequence and from the states of the simulated actuators. Tank level was the main analog value. Digital variables reported the pump, valves, alarms, and the status of the LoRa link. The selected variables are summarized in Table 2.

Table 2. Process variables considered for level monitoring and control.

Variable	Type	Use in the System
Tank level	Analog/real	Represents the amount or percentage of fluid in the simulated tank.
Filling pump	Digital/BOOL	Turns the inflow on or off according to the PLC sequence.
Relief valve	Digital/BOOL	Discharges fluid after the programmed upper condition is reached.
Filling valve	Digital/BOOL	Opens or closes the inlet according to the condition evaluated by the PLC.
LoRa-link status	Digital/BOOL	Provides a diagnostic indication of link availability or communication loss.

2.5. Configuration of the Siemens S7-1200 PLCs

The Siemens S7-1200 PLCs were first configured in TIA Portal. The tank variable, pump and valve commands, and the addresses needed for Modbus TCP communication with the Arduino-W5100 were defined in the PLC project. This division left the control program inside the PLC and placed external communication in the bridge hardware.

2.6. PLC-LoRa Communication Bridge

The PLC-LoRa bridge used an Arduino Uno with an Ethernet Shield W5100 because this hardware provided the RJ45 interface available for Modbus TCP to connect to the Siemens S7-1200. Arduino read the PLC registers, arranged the selected variables in a serial frame, and sent the frame to the Heltec LoRa ESP32. The UART link operated at 9600 bit/s with 8 data bits, no parity, and 1 stop bit (8N1).

All decisions for the pump, valves, and alarms remained in the PLC. Arduino did not control the process. Its task was to maintain the Ethernet connection through the W5100, read the Modbus TCP registers, and pass those values to the ESP32 over UART. This choice reflected both the hardware available for the study and the intention to keep industrial control separate from wireless communication.

A design based solely on the ESP32 could connect directly to a Modbus TCP client through Wi-Fi or an external Ethernet controller, thereby reducing both the component count and the number of protocol stages. The Arduino-W5100 bridge was retained because it was the wired RJ45 hardware available for the study, allowed existing Modbus TCP code to be reused, reduced development time, and permitted the Ethernet and LoRa sections to be debugged independently. At 9600 bit/s with 8N1 framing, each transmitted byte occupies 10 serial bits (approximately 1.04 ms per byte); therefore, UART serialization, buffering, and parsing necessarily contributed to the minimum recorded delay of 361 ms. However, the payload length and stage-specific timestamps were not retained, so the exact UART contribution cannot be isolated, and the total delay should not be attributed solely to the LoRa radio. Figure 3 summarizes the Modbus TCP–UART–LoRa communication bridge.

Figure 3. Modbus TCP-UART-LoRa communication bridge of the proposed architecture, showing the separation between PLC control logic and wireless transmission.

2.7. LoRa ESP32 Module, Antenna, and Radio Frequency

Two Heltec LoRa ESP32 boards provided the wireless link. Each board combines an ESP32 controller, a LoRa transceiver, and an OLED display. The boards received the serial frame from the Arduino, sent it out, and displayed information to help confirm reception. The process generated a small data payload, so the range and energy demand were more important than a high data rate [32,33].

Each LoRa board was equipped with an external sub-GHz antenna. During the measurements, node height, orientation, and position were kept as stable as field conditions allowed because even small changes can affect RSSI, SNR, recorded latency, and packet reception. The antenna model, nominal gain, radiation pattern, polarization response, and cable/connector losses were neither recorded nor calibrated. Therefore, unknown pattern nulls or polarization mismatch, together with local multipath propagation, could contribute to non-monotonic RSSI values, including the lower RSSI at 10 m than at 20 m. The reported metrics describe the installed configuration as a whole—radio, antenna, settings, firmware, and propagation environment—and should not be interpreted as a general performance specification for all ESP32/LoRa modules.

LoRa employs the Chirp Spread Spectrum (CSS), spreading each symbol across the channel bandwidth as a chirp. Its processing gain and chirp correlation allow reception at negative SNR and improve resistance to noise, narrowband interference, and some multipath effects [33]. These characteristics strengthen the radio link, but they are not encryption. In a LoRaWAN network, upper-layer AES-128 mechanisms add device authentication, message integrity, and payload confidentiality [34].

2.8. Simulation in Factory I/O

Before the radio campaign, the level process was reproduced in Factory I/O. The main PLC read the simulated tank level and operated the pump and valves according to the programmed sequence. Testing the logic in simulation reduced the risk of making the first adjustments on a physical plant [17,18].

2.9. Experimental Configuration and LoRa Communication Test

Field tests were conducted in an open area in Lasso, Latacunga. The transmitter remained fixed with its antenna at 5 m. The receiver antenna was positioned at a height of 2 m and moved through twelve locations from 10 to 120 m in 10 m intervals. At each location, 100 frames were transmitted, for a total of 1200 transmissions. For each distance, the values displayed by the LoRa module and its firmware were recorded in consolidated form in a spreadsheet: RSSI, SNR, calculated latency, packets sent, received, and lost, and reception percentage. The OLED displays were checked on site to confirm transmission and reception. The distance campaign covered the 915 MHz LoRa link; Modbus TCP remained on wired Ethernet through TCP port 502. Frames were sent once, without automatic retries. Each distance was evaluated in one session, and the irregular results at 10, 70, and 120 m were not repeated. Reception, RSSI, SNR, and the recorded single-attempt latency were used to evaluate link quality.

The experimental configuration was as follows. The radio path used a Heltec LoRa ESP32 transmitter and a receiver in point-to-point configuration. The Arduino-ESP32 UART interface operated at 9600 bit/s, with 8 data bits, no parity, and 1 stop bit (8N1). The transmitting antenna was installed at 5 m, whereas the receiving antenna was placed at 2 m. At each point, 100 frames were transmitted, for a total of 1200 transmissions. LoRa operated at 915 MHz with a bandwidth of 125 kHz within the 915–928 MHz reference band. External sub-GHz antennas with SMA/IPEX connectors were used, although their model, gain, radiation pattern, and polarization response were not recorded. The PLC-Arduino connection used Ethernet/Modbus TCP on port 502. Adafruit IO used 2.4 GHz Wi-Fi for supervision and was outside the LoRa distance test. The spreading factor, coding rate, and transmission power were not retained in a verifiable record and were therefore excluded from the quantitative interpretation.

For the field route, the receiver moved sequentially from P1 to P12. Consecutive locations were 10 m farther from the transmitter, producing observations across the full 10–120 m range shown in Figure 4.

Figure 4. Location of the test points used to evaluate LoRa communication. Note: G denotes the fixed transmitter position, and P1–P12 denote the receiver test locations.

At each point, the available record was examined in terms of packet reception, packet loss, firmware-calculated latency, RSSI, and SNR. Together, these values indicated whether the frame arrived and how link conditions changed along the route.

The consolidated spreadsheet retains, for each of the twelve distances, the columns test, distance (m), calculated RSSI (dBm), calculated SNR (dB), calculated latency (ms), sent, received, lost, and reception (%). RSSI and SNR values were read from the LoRa module, whereas latency corresponds to the value displayed by the firmware during each test. Independent timestamps and reception acknowledgments were not retained to verify a one-way measurement or calculate round-trip time (RTT). Therefore, the manuscript reports this field as a timing indicator of the evaluated configuration, without attributing it to automatic synchronization between the nodes. Each frame had a single attempt, and no automatic retries were applied.

Equation (1). Packet-reception rate.

$${\mathrm{R}}_{\mathrm{p}}={\displaystyle \frac{{\mathrm{P}}_{\mathrm{r}}}{{\mathrm{P}}_{\mathrm{e}}}}\times 100$$

(1)

Equation (2). Packet loss.

$${\mathrm{P}}_{\mathrm{p}}={\displaystyle \frac{{\mathrm{P}}_{\mathrm{e}}-{\mathrm{P}}_{\mathrm{r}}}{{\mathrm{P}}_{\mathrm{e}}}}\times 100$$

(2)

Equation (3). Average recorded latency.

$${\mathrm{L}}_{\mathrm{p}\mathrm{r}\mathrm{o}\mathrm{m}}={\displaystyle \frac{{\displaystyle {\sum }_{\mathrm{i}=1}^{\mathrm{n}}}{\mathrm{L}}_{\mathrm{i}}}{\mathrm{n}}}$$

(3)

Equation (4). Mean RSSI.

$$\mathrm{R}\mathrm{S}\mathrm{S}{\mathrm{I}}_{\mathrm{p}\mathrm{r}\mathrm{o}\mathrm{m}}={\displaystyle \frac{{\displaystyle {\sum }_{\mathrm{i}=1}^{\mathrm{n}}}\mathrm{R}\mathrm{S}\mathrm{S}{\mathrm{I}}_{\mathrm{i}}}{\mathrm{n}}}$$

(4)

Equation (5). Mean SNR.

$$\mathrm{S}\mathrm{N}{\mathrm{R}}_{\mathrm{p}\mathrm{r}\mathrm{o}\mathrm{m}}={\displaystyle \frac{{\displaystyle {\sum }_{\mathrm{i}=1}^{\mathrm{n}}}\mathrm{S}\mathrm{N}{\mathrm{R}}_{\mathrm{i}}}{\mathrm{n}}}$$

(5)

Equation (6). Range of recorded latency.

$$\Delta \mathrm{L}={\mathrm{L}}_{\mathrm{m}\mathrm{a}\mathrm{x}}-{\mathrm{L}}_{\mathrm{m}\mathrm{i}\mathrm{n}}$$

(6)

Equation (7). RSSI change between the end points.

$$\Delta \mathrm{R}\mathrm{S}\mathrm{S}\mathrm{I}=\mathrm{R}\mathrm{S}\mathrm{S}{\mathrm{I}}_{\mathrm{f}\mathrm{i}\mathrm{n}\mathrm{a}\mathrm{l}}-\mathrm{R}\mathrm{S}\mathrm{S}{\mathrm{I}}_{\mathrm{i}\mathrm{n}\mathrm{i}\mathrm{c}\mathrm{i}\mathrm{a}\mathrm{l}}$$

(7)

where the field campaign did not include a separate spectrum analyzer measurement. The noise level was therefore estimated at each point from the receiver readings as N_est (dBm) = RSSI (dBm) − SNR (dB). This is a packet-level estimate, not a calibrated measurement of the ambient noise floor.

2.10. Criterion for Analyzing the Influence on Control Quality

The LoRa path was deliberately kept outside the fast feedback loop. Tank level, pump operation, and valve commands continued to be processed locally by the PLC. For that reason, the study does not link the wireless network to overshoot, settling time, or tracking error; those control indicators were not tested under packet loss. Communication was considered at two levels. Local control continuity did not rely on the radio link, whereas remote supervision or future remote commands could be affected by late or missing frames. No strict real-time deadline was specified, so the results are relevant to slow-process supervision but do not demonstrate deterministic wireless control.

Pr = packets received.

Pe = packets sent.

Li = latency value calculated by the firmware in each test.

n = total number of measurements.

RSSI = received signal strength.

SNR = signal-to-noise ratio.

Lmax = maximum recorded latency value.

Lmin = minimum recorded latency value.

2.11. Analysis and Reproducibility Strategy

The data were examined in two stages. First, reception, packet loss, recorded latency, RSSI, and SNR were calculated for each distance. Equation (11) reports the difference between the maximum and minimum recorded latency divided by the 110 m route length; it is a normalized range, not the slope between the endpoints. Equation (12) reports the change in RSSI between 10 and 120 m. A least-squares regression was then fitted to the twelve points to describe the overall trends in recorded latency and RSSI. The resulting slopes and R² values were used only as descriptive statistics.

Only one 100-frame session was available for each distance. Confidence intervals and inferential tests were therefore not appropriate. The interpretation is limited to this campaign and explicitly accounts for the non-monotonic behavior observed at several points.

3. Results

The two Siemens S7-1200 PLCs exchanged information successfully through the PLC-Arduino-LoRa path. The Arduino Uno and W5100 shield converted Modbus TCP data to UART, while the PLC continued to execute the level-control program.

At every distance, the transmitted frame carried tank level and actuator-state information. The Arduino-W5100 bridge read these variables from the PLC and delivered them to the LoRa module. The receiving node obtained the frame without a direct cable connection between the two PLCs. The functional validation is summarized in Table 3, and the distance-dependent results are presented in Table 4.

Table 3. Functional validation of the implemented architecture.

Stage	Function	Result	Observation
PLC-Arduino communication	Exchange through Ethernet/Modbus TCP	Correct operation	The PLC continues to hold the process logic.
Arduino-LoRa communication	Data transfer through UART	Communication established	Arduino converts the Modbus TCP data to the UART stream.
LoRa communication between nodes	Point-to-point wireless transmission	Transmission completed	The two nodes communicate without a direct wired connection.
Level data	Transmission of the tank variable	Data sent and received	Confirms transfer of the main analog process variable.
Valve and pump status	Transmission of digital signals	Correct operation	Provides remote visibility of the actuator states.
Factory I/O simulation	Validation of the level logic	Behavior observed	Allows the control sequence to be checked before field implementation.

Table 4. Experimental LoRa communication results as a function of distance.

Test	Distance (m)	RSSI (dBm)	SNR (dB)	Firmware-Calculated Latency (ms)	Packets Sent	Packets Received	Reception (%)
Test 1	10	−112	−7.24	361	100	96	96.00
Test 2	20	−91	10.75	423	100	100	100.00
Test 3	30	−99	11	452	100	100	100.00
Test 4	40	−106	8.26	465	100	99	99.00
Test 5	50	−107	9	477	100	97	97.00
Test 6	60	−109	4.5	504	100	98	98.00
Test 7	70	−121	−4	491	100	90	90.00
Test 8	80	−121	−2.75	748	100	94	94.00
Test 9	90	−117	−1.5	1245	100	92	92.00
Test 10	100	−115	−4	1323	100	89	89.00
Test 11	110	−125	−10.5	1382	100	85	85.00
Test 12	120	−126	−11.5	855	100	90	90.00

Factory I/O displayed the level process as it evolved. When the simulated tank reached the programmed thresholds, the PLC changed the pump and valve states according to the control sequence. This confirmed the logic before the wireless link was evaluated.

The overall behavior agrees with the type of application for which LoRa and LoRaWAN are commonly used: moving small amounts of information over distance [7,14]. RSSI, SNR, and packet reception were used to characterize the link because these measures are standard in LoRa performance studies [11,12]. The technology is also used in water-monitoring systems to push variables to storage and visualization services [15,35]. The RSSI and SNR trends are shown in Figure 5.

Figure 5. RSSI and SNR behavior as a function of distance.

The campaign transmitted 1200 packets, of which 1130 reached the receiver. Overall reception was therefore 94.17%, and packet loss was 5.83%. The latency calculated by the firmware was not constant. It ranged from 361 to 1382 ms, with a mean of 727.17 ms. The highest recorded delays occurred mainly beyond 90 m, especially at 90, 100, and 110 m. Signal attenuation may have contributed, although local interference and changes in propagation conditions are also plausible explanations. These timing values describe this campaign and do not constitute calibrated one-way latency measurements.

Distance did not produce a uniform change at every point. RSSI was −112 dBm at 10 m but improved to −91 dBm at 20 m. At 70 m, SNR was −4 dB, and the recorded latency was 491 ms. The 120 m point also interrupted the overall trend: reception was 90%, and recorded latency decreased to 855 ms, compared with 89% and 1323 ms at 100 m, and 85% and 1382 ms at 110 m. Multipath propagation, antenna orientation, temporary obstructions, and local interference may explain part of this variation. Because antenna gain and radiation pattern were not calibrated, a location-dependent pattern null or polarization mismatch could also help explain why RSSI was worse at 10 m than at 20 m. Since no distance was repeated, the contribution of each factor cannot be separated. Distance is therefore treated as an overall trend rather than an exact point-by-point predictor.

Equation (8). Overall reception based on the packets received.

$${\mathrm{R}}_{\mathrm{g}}={\displaystyle \frac{1130}{1200}}\times 100=94.17\%$$

(8)

Equation (9). Overall loss based on the packets not received.

$${\mathrm{P}}_{\mathrm{g}}={\displaystyle \frac{1200-1130}{1200}}\times 100=5.83\%$$

(9)

Equation (10). Latency range between the minimum and maximum values.

$$\Delta \mathrm{L}=1382-361=1021 \mathrm{ms}$$

(10)

Equation (11). Latency range normalized by route length.

$$\text{T\_L}={\displaystyle \frac{\Delta \mathrm{L}}{\Delta \mathrm{d}}}={\displaystyle \frac{(1382-361)}{(120-10)}}=9.28 \mathrm{m}\mathrm{s}/\mathrm{m}$$

(11)

Equation (12). RSSI rate of change between the end points.

$$\text{T\_RSSI}={\displaystyle \frac{\Delta \mathrm{R}\mathrm{S}\mathrm{S}\mathrm{I}}{\Delta \mathrm{d}}}={\displaystyle \frac{(-126-(-112\left)\right)}{(120-10)}}=-0.13 \mathrm{d}\mathrm{B}\mathrm{m}/\mathrm{m}$$

(12)

Across the twelve locations, mean RSSI was −112.42 dBm, with point averages ranging from −91 to −126 dBm. Mean SNR was 0.17 dB. Average reception was 98.33% between 10 and 60 m and 90.00% between 70 and 120 m, although adjacent points did not change monotonically. Equation (11) divides the recorded latency range (1382–361 ms) by the 110 m route and yields 9.28 ms/m; this value is a normalized range, not a regression coefficient. Equation (12) uses only the RSSI readings at 10 and 120 m and yields −0.13 dBm/m. When all twelve points were fitted, the slope of recorded latency was 8.69 ms/m (R² = 0.672), and the RSSI slope was −0.238 dBm/m (R² = 0.654). These regressions capture the overall trend but leave substantial local variation unexplained. The RSSI-SNR noise estimate had a mean of −112.59 dBm and ranged from −118.25 to −101.75 dBm. Because the noise floor was not measured independently, these values are reported only as estimates.

3.1. Effect of Recorded Latency and Packet Loss on the Control System

The mean recorded latency was 727.17 ms, and the maximum was 1382 ms. These values show that the implementation operates on a timing scale of hundreds of milliseconds; however, because clock synchronization was not verified, they should not be interpreted as an exact one-way latency measurement. A loss rate of 5.83% corresponds to approximately one missing frame in every seventeen transmissions. The observed delay and packet loss made the dashboard information less current and, without reception acknowledgment, could postpone or prevent a remote command.

The filling and emptying sequence remained unchanged during the tests because the PLC already contained the variables and logic required to operate the pump and valves. The link can therefore support monitoring of a relatively slow level process. The available evidence is not sufficient for safety interlocks, emergency stops, or fast control loops. Remote commands would require additional safeguards, including acknowledgments, bounded retries, timestamps, stale-data checks, timeouts, and a safe local mode after communication loss.

3.2. Remote Visualization Through Adafruit IO

Remote supervision was extended to a web dashboard in Adafruit IO. The dashboard used feeds for the level setpoint, measured level, pump state, filling-valve state, relief-valve state, general stop, operating mode, LoRa-link state, and alarm condition. This arrangement placed the key process and link variables on one screen. Adafruit IO remained a visualization layer, while the PLC continued as the main controller [20].

Figure 6 and Figure 7 show the two dashboard views used during supervision. Figure 6 combines the setpoint and current level with the states of the pump, valves, operating mode, alarm, and LoRa link. Figure 7 shows the dashboard field labeled “latency,” which in this manuscript corresponds to the firmware-calculated latency indicator described in Section 2.9, together with RSSI, SNR, packets sent, packets received, and reception. Table 5 contains the consolidated values used for interpretation. The interface therefore allows the operator to review process conditions and communication behavior from the same remote platform.

Figure 6. Control view of the Adafruit IO dashboard for the level system.

Figure 7. Monitoring view of the LoRa–link metrics on the Adafruit IO dashboard.

Table 5. Quantitative indicators obtained from the LoRa communication tests.

Indicator	Result	Interpretation
Packets sent	1200	Number of frames transmitted across the twelve locations.
Packets received	1130	Frames that reached the remote node and were counted as received.
Overall reception	94.17%	Share of all transmitted frames that were received successfully.
Overall packet loss	5.83%	Share of transmitted frames that did not reach the receiver.
Mean firmware latency	727.17 ms	Mean value of the “calculated latency” field recorded by the firmware for the complete route; it is used as a timing indicator of the evaluated configuration and not as a calibrated one-way latency.
Average RSSI	−112.42 dBm	Mean received-signal level calculated from the twelve test points.
Average SNR	0.17 dB	Mean signal-to-noise ratio calculated from the twelve test points.
Latency range normalized by route length	9.28 ms/m	Calculated as (maximum latency − minimum latency)/110 m. This value is a normalized range, not a regression slope.
RSSI rate of change between end points	−0.13 dBm/m	Computed from the RSSI values at 10 and 120 m only. It is not the slope of a fit to all points.
Linear regression: latency versus distance	8.69 ms/m; R2 = 0.672	Least-squares fit of the recorded latency values against distance using all twelve locations; descriptive only.
Linear regression: RSSI versus distance	−0.238 dBm/m; R2 = 0.654	Least-squares fit of RSSI against distance using all twelve locations.
Estimated mean noise level	−112.59 dBm	Calculated as RSSI − SNR; no independent spectrum-analyzer measurement was made.

3.3. Importance of Link-Quality Metrics

RSSI, SNR, and reception describe different parts of the wireless link. RSSI indicates the power observed at the receiver, SNR places that signal in relation to noise, and reception records the practical outcome—whether the process frame arrived. A frame cannot be judged from RSSI alone. Reading the three metrics together helps identify locations where communication still works but has less margin and a higher risk of late or missing information.

The three metrics did not order the test points in the same way. At 100 m, for instance, RSSI was −115 dBm, but reception was only 89%. At 70 and 80 m, RSSI was lower at −121 dBm, yet reception reached 90% and 94%, respectively. This result shows why RSSI, SNR, and reception should be considered together. In an uncontrolled outdoor setting, none of them is a deterministic predictor on its own.

The measured ranges should not be treated as a universal specification for the Heltec ESP32. They describe the operating envelope of the particular hardware, antennas, firmware, settings, and site used in this campaign. Their practical purpose is to indicate when antenna placement, radio settings, location, or acknowledgment mechanisms may need to be revised before deployment.

4. Discussion

The results show that an S7-1200 control system can be connected to an external IoT layer without transferring its main logic out of the PLC. This is consistent with recent IIoT research that links established automation equipment to digital platforms, industrial communication, and remote supervision [4,30]. Keeping local control separate from the IoT interface also contributes to resilience, an Industry 5.0 objective because the process can continue locally if the external connection is interrupted [5].

The architecture differs from the tank-automation system reported by Abubeker and Nuthalapati [21]. Their solution is embedded, whereas the present design retains the PLC, uses an industrial process simulation, and sends variables through a Modbus TCP-UART-LoRa path. Arduino-W5100 and LoRa are therefore communication resources outside the controller rather than the location of the control logic.

4.1. Comparison with Similar Studies

Table 6 compares the studies using the same practical questions: What is the application? Where are control and processing performed? Which communication route is used? What experimental evidence is reported? This avoids reducing the comparison to the simple presence or absence of a PLC.

Table 6. Structured comparison with related studies.

Study	Application and Functional Core	Communication and Validation	Difference from This Study
Wister et al. [15]	IoT-based monitoring of water levels in cisterns and storage tanks.	Level values are displayed remotely for supervision.	The work centers on monitoring and does not test the PLC-Modbus TCP-UART-LoRa path or distance-dependent radio behavior.
Abubeker and Nuthalapati [21]	Tank automation with level sensing, web visualization, and pump control.	Uses an ESP32 LoRa node and a JSN-SR04T sensor in several environments. Distance is related to energy consumption, RSSI, and SNR; its timing metric is not directly comparable with the firmware-calculated latency in the present study.	It offers a useful architectural and radio-metric reference, although its timing results cannot be compared directly with ours.
Saban et al. [22]	Agricultural monitoring and control through a PLC and a cloud web application.	The gateway was positioned at approximately 24 m, and a LoRa Mote II was evaluated at eleven locations from 50 to 795 m. Ten messages were sent per point at 867.1–868.5 MHz, 125 kHz, SF7, CR 4/5, and +14 dB. Reception, RSSI, and SNR were reported; no metric equivalent to firmware-calculated latency was included.	The referenced study reports reception, RSSI, and SNR over a longer route. In our campaign, the PLC retained level control, and the communication assessment also included a single-attempt latency indicator calculated by the firmware.
Calderón et al. [30]	Industrial IIoT framework combining automation hardware with IoT tools.	Demonstrates an experimental integration of industrial automation and IoT resources.	It provides broader industrial context but does not examine level control or the twelve-distance Modbus TCP-UART-LoRa link used here.
Pires and Gomes [35]	LoRa-based IoT monitoring of water-quality variables.	Environmental measurements are transported wirelessly for monitoring.	The focus is acquisition and observation; local PLC control and its isolation from radio failures are not addressed.
Present study	Level control remains in an S7-1200 PLC, with wireless communication used for external supervision.	The transmitter and receiver antennas were positioned at heights of 5 and 2 m. Twelve locations from 10 to 120 m were evaluated with 100 frames per point, at 915 MHz and 125 kHz, using one attempt per frame. Reception, RSSI, SNR, and recorded latency ranged from 85 to 100%, −91 to −126 dBm, −11.5 to 11 dB, and 361–1382 ms.	The study separates control from communication, quantifies the radio path, and discusses what the measured delay and loss mean for supervision and any future network-dependent control.

The comparison makes clear that the PLC is not proposed as a novel substitute for a microcontroller. The contribution comes from combining existing industrial control, protocol conversion, and a quantitative radio-link assessment, while separating ordinary supervision from time-critical control requirements.

Cost-Effectiveness, Energy Efficiency, and Architecture Selection

The reviewed systems use different combinations of microcontrollers, cloud services, and LoRa/LoRaWAN [15,21,22,24]. In [21], acquisition, communication, and automation are integrated into a compact embedded design. The present architecture distributes those tasks: the PLC performs local control, the Arduino-W5100 provides Ethernet and Modbus TCP, and the ESP32-LoRa handles the radio link. A compact embedded design may be preferable for a new stand-alone installation. A PLC-based design can be attractive when an existing program, field inputs and outputs, and established maintenance practices must be retained.

No equivalent comparison of purchase cost, engineering effort, maintenance, or energy consumption was included in the experiment. The study therefore does not claim that the PLC option is cheaper or more energy efficient. Cost-effectiveness would require a life-cycle assessment, and energy efficiency would require measurements from both architectures under comparable operating cycles. The evidence supports only the functional benefits observed here: local control continued, and communication failures remained isolated from the process logic.

4.2. Implications of Recorded Latency and Packet Loss

Frames were still received at 120 m, although the second half of the route generally showed weaker link conditions. The change was not continuous. RSSI at 10 m was worse than at 20 m, and the 120 m point had better reception and recorded latency than the 100 and 110 m points. Outdoor campaigns often show similar local variation because of multipath propagation, shadowing, antenna orientation, temporary obstacles, and interference [22]. In this campaign, the uncalibrated antenna gain and radiation pattern provide an additional possible explanation for the 10 m anomaly. The overall reception rate of 94.17% only applies to this hardware, site, and test session. The evaluated radio path was point-to-point LoRa rather than a LoRaWAN network, and it did not use encryption or authentication. The packet-loss and latency values are also specific to the unverified spreading factor, coding rate, and transmission-power configuration used by the firmware/library during the test. Local PLC operation was unaffected. However, a critical command that depended on this link could arrive late or fail to arrive; that scenario was outside the experiment.

4.3. Study Limitations

The hydraulic process was evaluated in Factory I/O rather than in a physical plant with installed sensors. Each distance was represented by one 100-frame session, and the unusual points at 10, 70, and 120 m were not repeated. Repeatability and within-location variation therefore cannot be quantified. In addition to distance, multipath propagation, temporary obstructions, radio interference, and antenna orientation may have influenced the measurements. The antenna model, nominal gain, radiation pattern, polarization response, and connector/cable losses were not calibrated, which limits interpretation of the non-monotonic RSSI behavior. The spreading factor, coding rate, and transmission power could not be recovered from a verifiable firmware record; consequently, the reception, packet-loss, and latency conclusions are specific to the unverified library configuration used in this campaign. In addition, no verifiable record of clock synchronization between the nodes was retained. The “calculated latency” field in the data sheet is therefore interpreted as a firmware timing indicator rather than a calibrated one-way latency or RTT. These limitations do not eliminate the value of the feasibility test, but they restrict the conclusions to the recorded configuration and campaign.

4.4. Scope of the Scientific Contribution

The work goes beyond assembling a set of devices. It separates PLC control from wireless communication, documents the complete Modbus TCP-UART-LoRa path, and evaluates that path through reception, packet loss, firmware-calculated latency, RSSI, and SNR. This structure allows the continuity of local control and the limitations of remote supervision to be analyzed separately.

The most transferable part of the study is its evaluation procedure. It shows how a modular architecture can be characterized, compared with related work, and reported without hiding irregular data points behind a single overall trend. The numerical results are specific to the evaluated hardware, antennas, radio settings, and propagation environment and are not presented as universal values. Because SF, CR, and transmission power were not retained in a verifiable form, packet loss and recorded latency should be interpreted only for this campaign and not as a reproducible performance specification for the Heltec platform.

5. Conclusions

An IoT architecture was designed and implemented to monitor and control levels through LoRa communication between Siemens S7-1200 PLCs. Factory I/O, the PLCs, an Arduino Uno, an Ethernet Shield W5100, and Heltec LoRa ESP32 modules were integrated in the prototype. The PLC remained the process controller; the external hardware formed the communication layer. The practical contribution is the separation of local control from wireless communication and the experimental definition of the operating range of that external layer.

Taken as a whole, the study offers a method for adding and evaluating a communication layer without removing process control from the PLC. The radio link is examined with complementary metrics, descriptive regressions, comparison with related work, and an explicit account of the experiment’s limitations.

The Arduino-W5100 bridge communicated with the PLC through Modbus TCP and transferred the variables to the LoRa board over UART at 9600 bit/s in 8N1 format. Arduino did not control the tank. It provided the Ethernet interface, read the PLC registers, and transferred their values to the ESP32. As a result, the S7-1200 retained the logic, and the wired and wireless sections could be evaluated independently. The 9600 bit/s serial stage necessarily added serialization, buffering, and parsing time.

The field campaign produced 94.17% overall reception, 5.83% packet loss, and a mean recorded latency value of 727.17 ms. Link conditions generally became less favorable with distance, although RSSI, SNR, reception, and recorded latency did not change monotonically at every location. The results support the link as a supervision channel for a slow process. They do not demonstrate its suitability for a time-critical wireless control loop. The packet-loss and timing results remain specific to the unverified radio configuration used during the campaign.

Factory I/O was used to verify the level sequence in simulation, and Adafruit IO served as the remote supervision layer. The conclusions only apply to the tested arrangement: a simulated process, 915 MHz LoRa, a 5 m transmitting antenna, a 2 m receiving antenna, and the parameters that were actually recorded. The experiment did not evaluate physical sensors, a verified spreading factor, coding rate, transmission power, calibrated antenna gain, radiation pattern, synchronized one-way timing, an independently measured noise floor, total cost, or comparative energy use. It also did not place the control loop on the network. Accordingly, no economic, energy-efficiency, deterministic-control, or calibrated one-way-latency advantage is claimed beyond the measurements reported.