Energy Efficiency-Driven Selection of Wireless Communication Stacks for Industrial Retrofitting Applications

Abstract

The digital integration of existing industrial equipment (retrofitting) is a central element of the Industry 4.0 paradigm, wherein the energy efficiency of Internet of Things (IoT) gateways is a decisive design consideration. This research aims to experimentally compare various wireless and wired communication protocols—ESP-NOW, Bluetooth Low Energy (BLE), Bluetooth Classic (Serial Port Profile, SPP), Message Queuing Telemetry Transport (MQTT), and S7 Protocol—within a legacy Programmable Logic Controller (PLC)-based environment. A dedicated testbed was developed using Siemens S7-300 PLCs and ESP32-based gateway devices to ensure measurement reproducibility. Energy consumption was determined using a high-precision power profiler with payloads ranging from 50 to 15,000 bytes, applying the trapezoidal rule while considering both active transaction and standby states. The specific energy consumption metric (μJ/byte) introduced in this study highlights the distinct scaling limitations of the protocols. While ESP-NOW proved highly efficient for small telemetry packets, Bluetooth Classic exhibited superior scalability for bulk data volumes. Furthermore, a critical energetic crossover point was identified for ESP-NOW due to hardware fragmentation limits, whereas MQTT demonstrated massive energetic overhead for small payloads. Standby measurements confirmed that the continuous baseline consumption of the wired Ethernet interface significantly dominates the energy budget compared to wireless alternatives. These empirical findings are synthesized into a formal Qualitative Decision Matrix to help engineers optimize protocol selection based on the expected duty cycle, facilitating the development of sustainable industrial digitalization solutions.

1. Introduction

In our increasingly interconnected world, the Internet of Things (IoT) and wireless communication technologies have revolutionized the way we interact with our environment. A primary challenge of Industry 4.0 is the establishment of vertical networks that seamlessly link smart production systems with design teams, suppliers, and the front office [1]. Realizing this vision requires comprehensive data collection from both machinery and products throughout the entire smart factory ecosystem [2]. Smart factories are defined as flexible, fully integrated facilities capable of leveraging continuous data streams from operational and production systems [3]. From smart homes to large-scale industrial automation, advancements in wireless communication and IoT device development have ushered in a new era of connectivity.

Industry 4.0 is becoming increasingly intertwined with the concept of the Industrial Internet of Things (IIoT). IIoT encompasses a wide range of disciplines, the understanding and management of which are crucial for fully exploiting the potential inherent in this technology [4]. By appropriately applying IIoT solutions, companies can significantly enhance their productivity, efficiency, and profitability. However, the implementation of Industrial IoT presents a substantial challenge for Small and Medium-sized Enterprises (SMEs), as they often rely on legacy machinery that lacks native data connectivity [5]. Furthermore, SMEs have been grappling with additional economic hardships following the disruptions caused by the COVID-19 pandemic and the subsequent increase in global geopolitical and economic volatility; nevertheless, the adoption of Industry 4.0 technologies remains essential for maintaining their competitiveness [6]. While the retrofitting of legacy equipment is a viable pathway for modernization, it poses significant hurdles, including sensor integration, real-time data processing, and ensuring seamless interoperability between disparate systems [7].

While IoT devices and wireless communication technologies offer numerous benefits, they also raise significant concerns regarding energy consumption [8]. Consequently, the optimization of power usage is paramount for the long-term viability and sustainability of IoT deployments [9]. To mitigate these challenges, there is a continuous focus on the development of low-power IoT chipsets, energy-efficient communication protocols, and advanced power management strategies.

This paper presents the laboratory-scale retrofitting of a manufacturing cell equipped with a legacy PLC, with a central focus on energy efficiency. Throughout the research, we aim to address the following four fundamental Research Questions (RQs):

• RQ1: What is the magnitude of energy consumption associated with integrating legacy PLCs into IoT networks across various software and hardware architectures?
• RQ2: Can significant energetic differences be identified between various wireless technologies (ESP-NOW, BLE, Bluetooth Classic, MQTT) under identical industrial conditions?
• RQ3: How does the payload size influence the specific energy consumption (μJ/byte), and are there technological crossover points where one protocol becomes more efficient than another?
• RQ4: What is the relative weight of the standby consumption of network interfaces within the total energy footprint compared to active data transmission phases?

To address these questions, a dedicated testbed was developed to enable the objective, comparable, and reproducible analysis of the measurement results. While existing literature predominantly evaluates wireless IoT protocols based on latency, transmission range, or network throughput, this study introduces a novel, energy-centric framework specifically tailored for industrial retrofitting applications. The primary novelties and scientific contributions of this work are threefold:

• Extended Payload Analysis and Crossover Identification: In contrast to conventional studies limited to low-volume telemetry, this research investigates a broad payload spectrum (from 50 to 15,000 bytes). This wide-range profiling uniquely identifies the critical “energetic crossover points” where protocol efficiency sharply inverses due to underlying mechanisms (e.g., BLE fragmentation versus Bluetooth Classic continuous streaming).
• Deterministic Energy Profiling for Legacy Integration: The study provides a high-precision, zero-data-loss energetic baseline that directly compares modern wireless communication stacks (ESP-NOW, BLE, Bluetooth Classic, MQTT) with established legacy wired standards (Siemens S7 Protocol). This provides a quantitative framework for integrating legacy PLCs into modern Industry 4.0 architectures.
• Introduction of the Specific Energy Metric in Standby and Active States: By utilizing a highly controlled hardware environment to eliminate environmental stochasticity, the research accurately maps the specific energy consumption (μJ/byte) across both active transactions and prolonged standby states, which is a critical necessity for the thermal and energetic design of enclosed industrial IoT gateways.

2. Literature Review

In the manufacturing industry, automation systems typically operate within a layered, hierarchical structure known as the automation pyramid, based on the ISA-95 standard [10]. Various general, high-level reference architectures have been proposed in the literature to provide a structured approach to the design of Industry 4.0 systems [11]. Among these, the most prevalent and widely accepted model is the Reference Architecture Model Industrie 4.0 (RAMI 4.0) [12]. While these architectures establish a comprehensive framework for the theoretical conceptualization of I4.0 systems, their high level of abstraction and the significant freedom of application they allow often mean they fail to provide direct guidance for specific industrial implementations [13]. Consequently, their practical application is associated with numerous challenges [14].

The fundamental prerequisite for implementing industrial digitalization is the availability of real-time data acquisition, condition monitoring, and communication capabilities within production equipment. However, these features are typically absent or only limitedly available in legacy machinery [15]. Such equipment often operates using closed, obsolete controllers and proprietary protocols, which are unsuitable for interoperable data exchange with modern IoT platforms or cloud-based systems [16]. Furthermore, the tracking and optimization of energy consumption in traditional machines is frequently only partially implemented or entirely missing, thereby hindering sustainable and cost-effective operations [17].

For industrial companies, the wholesale replacement of existing machinery—which is often still fully functional but technologically obsolete—with modern digital equipment would entail substantial capital expenditure [18]. Retrofitting offers a viable solution to this challenge by enabling the subsequent modernization of the existing machine fleet. During this process, conventional machines are equipped with sensors, control units, and communication modules, empowering them with data acquisition and networking capabilities, thereby facilitating their seamless integration into smart manufacturing systems.

Retrofitting also serves as a key enabler for promoting sustainable industrial production. From an environmental standpoint, it contributes to extending the service life of machinery, asset reuse, more efficient resource utilization, and the mitigation of waste generation, thereby reducing the overall environmental footprint of industrial activities [19]. Regarding economic aspects, retrofitting enhances cost-efficiency by minimizing operational expenditures (OPEX), losses from scrap, and unplanned downtime, while simultaneously fostering improvements in productivity and competitiveness [20]. From a social perspective, the advantages of retrofitting include improved occupational safety, the promotion of active operator participation in production and decision-making processes, and a contribution to the social recognition and technological integration of the workforce [21].

Alqoud et al. [7] classified the retrofitting of legacy machinery into three distinct categories based on the degree of interoperability and connectivity between legacy systems and emerging technologies:

• Starter Kit Solutions
• Embedded Streaming Gateway Solutions
• IoT Hardware-Based Solutions.

The first category, “Starter Kit Solutions” (also known as sensor kits), involves a comprehensive package installed by a third-party provider, encompassing sensors, connectivity software, hardware, and a dedicated data analytics platform. The second category, “Embedded Streaming Gateway Solutions,” establishes a connection to the IoT network by updating the existing machine software without the need for additional hardware. However, the feasibility of this approach is contingent upon the PLC possessing sufficient processing capacity to handle the additional computational overhead. The third category is “IoT Hardware-Based Solutions,” which ensures compatibility and connectivity with legacy systems through the integration of dedicated IoT hardware. This represents the most prevalent approach in retrofitting, as it facilitates the extraction of original data from legacy machinery while enabling the use of supplementary sensors to generate meaningful insights.

A cornerstone of Industry 4.0 implementation is the data collection process [22]; consequently, the primary objective of smart retrofitting is the extraction of data from the automated systems governing production equipment. PLCs serve as the core components of these systems, providing access to data generated at the field level of the manufacturing process. Given that the primary function of PLCs is process control, any intervention affecting fundamental control operations can lead to significant safety and reliability risks. Furthermore, modifying existing control logic is often impractical, as these systems typically rely on long-established, stable solutions where any interference could result in costly production downtime. Consequently, from a functional standpoint, the smart retrofit concept must not compromise the control capabilities of the PLC [13]. For these reasons, among the three categories defined by Alqoud et al. [7], IoT Hardware-Based Solutions emerge as the most effective approach, a domain in which several related works have already been established.

2.1. Related Works to IoT Hardware-Based Solutions

Niemeyer et al. [23] established an IoT platform within a learning factory designed for SME training, utilizing Kepware and Thingworx to connect Siemens and Wago PLCs. This platform enabled comprehensive data collection and real-time monitoring. Lins and Oliveira [24] demonstrated retrofitting on a Cyber–Physical Production System (CPPS) by replacing the factory controller of a 6-axis robot arm with a Linux-based embedded board, specifically a BeagleBone Blue. This modification allowed the authors to integrate additional peripherals and functions, including a USB camera, metal detector, energy meter, webserver, remote access, cloud computing, and a Wi-Fi interface, thereby making the robot arm not only Industry 4.0-ready but also more energy-efficient. Keshav Kolla et al. [5] proposed a retrofitting architecture applicable to any legacy machine. Their approach first defines IoT nodes (such as microcontrollers, PLCs, or computers) and subsequently establishes a secure IIoT gateway linked to IIoT middleware, bridging the physical and cyber layers. Based on this architecture, the authors retrofitted a legacy drilling machine using a Raspberry Pi running Node-RED as middleware, along with Hall effect and infrared distance sensors to determine drilling depth and speed. Data were stored in an InfluxDB database and visualized using Grafana.

Rosas et al. [25] supplemented a legacy PLC-controlled reduced-scale model of a distribution line with an ESP8266 microcontroller (Espressif Systems, Shanghai, China). The PLC and the ESP8266 were interfaced via resistors and optocouplers, with the ESP8266 functioning as an Access Point to provide wireless connectivity for mobile devices and laptops. Haskamp et al. [26] enabled IoT capabilities in a model flexible manufacturing system using the dataFEED OPC Suite software (version 4.30) gateway. The system integrated four Siemens PLCs (S7-300 and S7-400 models) communicating via TCP/IP with the dataFEED OPC Suite, which forwarded data to an Azure IoT Hub for storage, processing, and visualization through a graphical user interface (GUI) similar to an HMI. Kostoláni et al. [27] utilized a Siemens Simatic IOT2040 gateway alongside a Siemens S7-1500 PLC, running a Node-RED server to extract, transform, and process PLC data while providing remote access. Similarly, Lima et al. [28] employed a Simatic IOT2040 gateway for the retrofitting of a CNC machine to measure its energy consumption. The setup included an energy sensor transmitting data via ZigBEE to a Power Link device, which then communicated with the Simatic IOT2040 through the Modbus protocol.

Givehchi et al. [15] developed an interoperability layer for mapping physical and cyber layers using a Raspberry Pi with Node-RED and a PLC. Nsiah et al. [29] detailed the application of the NIKI4.0 toolkit, enabling process tracking and real-time visualization, where OPC UA provided secure data exchange and MySQL was used for historical data storage. Naimuddin et al. [30] made an Emotron PLC remotely monitorable and controllable using an ESP8266. By running a webserver on the ESP8266 accessible via Wi-Fi, they provided a cost-effective solution for Industry 4.0 compliance. Boonmeeruk et al. [31] developed an ESP32-based IIoT gateway for a Siemens S7-1200 PLC. The gateway communicated with the PLC via Modbus TCP and forwarded data to cloud systems using MQTT and REST APIs, offering a low-cost alternative to the SIMATIC IOT2050. Dwiyaniti et al. [32] designed an IoT module utilizing an ESP32 and the Thingsboard platform to monitor the induction motor speed of a Schneider PLC and store historical data. The ESP32 communicated with the PLC via TCP/IP and transmitted data to Thingsboard using MQTT. Finally, Chen et al. [33] presented an ESP32-based wireless IIoT gateway capable of S7 Protocol parsing and MQTT conversion. The gateway features a layered architecture with remote configuration and persistent data storage capabilities, offering an efficient data acquisition and communication framework between industrial systems and the cloud.

Based on the reviewed literature, it is evident that diverse approaches exist for designing IoT gateways. However, the technical justification for selecting specific hardware components is often omitted or only briefly addressed. Since high-end commercial solutions—such as those offered by Siemens, Moxa, HMS, or Sensata—are frequently financially inaccessible for SMEs, low-cost alternatives are typically prioritized in research and development. Among these alternatives, the Raspberry Pi platform is particularly prevalent, Tran et al. [34] highlight it as a preferred solution due to its affordability, ease of configuration, and extensive open-source ecosystem. While the Raspberry Pi is indeed a cost-effective device with significant computational power, its available resources are often underutilized in many industrial application contexts, leading to unnecessary energy overhead.

2.2. Related Work on Determining the Energy Efficiency of Wireless Protocols

In the design and implementation of IoT Gateways, the selection of the optimal communication protocol is of decisive significance alongside the choice of the hardware platform. Based on an analysis of the relevant literature, both wired and wireless data transmission solutions are prevalent; however, the present research focuses specifically on wireless communication technologies and their associated protocols. Several comparative studies have already analyzed wireless protocols from various perspectives. Khan et al. [35] compared the energy consumption, data rate, power output, communication range, coexistence, and frequency bands of Bluetooth, ZigBee, and Wi-Fi to assist in protocol selection. Denisov et al. [36] evaluated various Wi-Fi, Bluetooth, and LoRa modules based on the communication ranges required to maintain specific data rates.

Pegah et al. [37] investigated the energy consumption of CoAP and MQTT protocols using an ESP32 microcontroller, incorporating encryption into the communication. Their results indicated that CoAP is more suitable for small data volumes, whereas MQTT performs better for larger payloads. Furthermore, Eridani et al. [38] compared ESP-NOW, Wi-Fi, and Bluetooth in terms of range, speed, latency, energy consumption, and barrier resistance. Their findings showed that while Wi-Fi offers robust connectivity and high overall performance, ESP-NOW provides a long range with low transmission latency, and Bluetooth remains a low-power solution ideal for long-term applications.

Laura et al. [39] compared Wi-Fi and LoRa regarding energy usage, concluding that as the consumption of the two technologies is comparable, the decisive factors for selection are range and data rate. Finally, Mutescu et al. [40] estimated the energy efficiency of LoRa and SigFox protocols across different modules. Their results revealed distinct transmission profiles: certain modules (LoRa) transmit using high current peaks for short durations, while others (SigFox) utilize lower current peaks over longer periods.

To ensure a rigorous and standardized comparison, this study investigates which wireless communication protocols—when integrated into IoT Gateways—offer the most favorable energy efficiency within a cell-level industrial retrofitting scenario. This context is characterized by the short-range communication typical of brownfield digitalization, where legacy PLCs and modern gateways operate in close proximity. The investigation is specifically tailored to industrial data profiles, comparing the efficiency of frequent, low-volume telemetry against intermittent, bulk diagnostic data. Furthermore, the evaluation accounts for a realistic, multi-frequency environment, the coexistence of 2.4 GHz and 5 GHz Wi-Fi networks, alongside 5G mobile infrastructure within the university setting, provides a representative “noise floor” for modern, digitally dense workspaces. By maintaining identical testing conditions, this research provides a quantitative basis for selecting the optimal protocol that balances energetic sustainability with the specific data-handling requirements of legacy system integration.

3. Methodology

While the literature review has examined various retrofitting methodologies and compared wireless communication protocols across several dimensions, previous studies have not specifically addressed the energy efficiency of IoT gateway protocols employed in the retrofitting of manufacturing cells controlled by legacy PLCs. To address this gap, the objective of this research is to develop an experimental framework that provides quantitative support for selecting the energy-optimal communication protocol for industrial digitalization.

3.1. Experimental Setup

The experiment was conducted at the Laboratory of Cyber–Physical Manufacturing Systems at Széchenyi István University, which houses several educational manufacturing cells operated by legacy PLCs. For the purposes of this research, a dedicated testbed was developed to ensure controlled and reproducible measurements. The testbed incorporates two identical Siemens S7-300 series legacy PLCs (Siemens AG, Munich, Germany), which are widely utilized in industrial environments. One PLC functions as the data sender, representing a manufacturing cell controller, while the second PLC serves as the receiver, corresponding to a higher-level control system.

An integrated Human–Machine Interface (HMI) facilitates the initiation and termination of measurements and provides process status feedback, connected to the PLCs via an industrial switch. This network connection is exclusively dedicated to uploading control programs and managing the measurement workflows. Experimental data transmission and reception occur through the secondary ports of the PLCs, to which two IoT devices are connected. These IoT devices are hardwired to their respective PLCs while communicating with each other wirelessly, the architecture of this setup is illustrated in Figure 1. To evaluate the energy efficiency of the wireless communication protocols, the testbed is equipped with a high-precision power profiling device, which is interfaced with a computer for recording and processing energy consumption data.

The device functioning as the IoT gateway is an ESP32-based M5Stack Core2 microcontroller (M5Stack Technology Co., Ltd., Shenzhen, China). Despite its compact form factor, it offers a broad range of functionalities, including support for various wireless protocols, a touchscreen display, and multiple sensor and peripheral connectivity options. A key feature of this device is its modular, stackable architecture, which facilitated the seamless integration of the LAN module required for communication with the PLC. As shown in Figure 2, which illustrates the physical setup of the testbed, an essential component of the system is the Otii Arc Pro power profiler (Qoitech AB, Lund, Sweden). This instrument serves as both a stable power supply and a precision multimeter for comprehensive energy analysis. The current measurement accuracy is $\pm (0.05\%+25\mathrm{nA})$ within a range of −5 to 5 A, with a resolution of 0.4 nA, while the voltage measurement accuracy is $\pm (0.01\%+1\mathrm{mV})$. Data processing is handled by a 24-bit ADC, which employs auto-ranging to ensure high precision throughout the entire duration of the investigation.

3.2. Communication Protocols and Configuration

During the experiment, the energy consumption associated with data reading and writing operations between the IoT devices and the PLCs, as well as the energy required for wireless data transmission and reception, is quantitatively determined. The high-precision power profiling tool enables the independent evaluation of individual IoT devices, facilitating the isolation of energy consumption characteristics on a per-component basis. For the experimental measurements, the volume of data transferred between the two PLCs was categorized into four distinct payload sizes to evaluate performance across different orders of magnitude:

• 50 bytes,
• 500 bytes,
• 5000 bytes,
• 15,000 bytes.

This scaling allows for a comprehensive comparison of energy consumption across the various communication protocols. In the preparatory phase of the experiment, 15,000-byte data arrays were established on both the sending and receiving PLCs, dedicated to writing and reading the test data. Due to the static memory management characteristics of the PLCs, a single 15,000-byte array is sufficient to accommodate any of the selected payload sizes.

The desired payload size is selected via the HMI user interface. Once selected, the operator can specify the number of cyclic repetitions for data transmission, enabling an arbitrary number of measurements to be executed sequentially in a fully automated manner. A two-second delay is introduced between cycles to ensure that individual measurements are properly isolated and to facilitate the accurate determination of standby energy consumption. Subsequently, the communication link between the IoT devices and the PLCs was established using the S7 Protocol. Following the configuration of the PLC-to-gateway link, the wireless communication protocols selected for evaluation were defined as follows:

• ESP-NOW,
• Bluetooth Classic (SPP),
• BLE,
• MQTT.

Leveraging the touchscreen capabilities of the IoT device, a dedicated menu system was developed to allow the selection of payload sizes, the desired communication protocol, and the number of measurement cycles, mirroring the functionality of the HMI. To ensure consistency, the number of cycles must be synchronized with the value specified on the HMI. Prior to initiating the measurement sequence, these parameters are configured to ensure the IoT devices are primed for communication. For the MQTT-based evaluations, a local broker was deployed using Eclipse Mosquitto v2.0.22.

When evaluating the energy profiles of the selected technologies, it is critical to clarify that this study compares complete implemented communication stacks rather than equivalent layers of the Open Systems Interconnection (OSI) model. For instance, technologies such as ESP-NOW and Bluetooth Low Energy (BLE) operate primarily at the lower network layers (Physical and Data Link layers), inherently providing lightweight, low-overhead communication. Conversely, MQTT is an Application-layer protocol. In a wireless IoT gateway context, deploying MQTT necessitates the execution of a comprehensive underlying stack, specifically 802.11 Wi-Fi, IP, and TCP. Consequently, the measured energy consumption for MQTT is a cumulative value that intrinsically includes the substantial physical and network-layer overheads, such as maintaining the Wi-Fi connection, TCP handshakes, and IP packet encapsulation. From an industrial retrofitting perspective, an engineer must deploy the complete protocol stack to successfully integrate a legacy PLC with a modern broker. Therefore, analyzing these complete implemented stacks provides the most accurate reflection of the true energy budget required for real-world deployments. To achieve higher granularity and precision in the results, the energy consumption for reading from the source PLC and writing to the target PLC was measured independently from the data transmission and reception phases between the IoT devices. This methodological separation enables the distinct quantification of energy requirements for data acquisition from the sending PLC, transmission via the various wireless technologies, and the final data commitment to the receiving PLC.

It is important to clarify that the Siemens S7 Protocol (operating over a wired Ethernet interface) is not evaluated in this study as a direct technological alternative to wireless protocols like ESP-NOW, BLE, or MQTT. Rather, it represents the mandatory legacy interface required to extract data from existing PLCs in a brownfield retrofitting scenario. While wireless protocols are optimized for intermittent, low-power transmissions, the wired Ethernet interface necessitates a continuous, high-energy baseline to maintain physical link status. Including the S7 Protocol in this comparative analysis is essential to illustrate the complete energy budget of an industrial IoT gateway. It demonstrates that the unavoidable wired connection to the legacy equipment often represents the most significant continuous energy drain, ultimately dictating the minimum power and thermal requirements of the entire system. Designing the firmware for the IoT devices and effectively evaluating the results necessitates a thorough understanding of the specific characteristics of each investigated protocol. The theoretical maximum data rates and payload constraints relative to the utilized hardware are summarized in

Table 1. Theoretical specifications and technical limits of the investigated communication protocols [38,41,42,43,44,45,46,47].

Protocol	Maximum Data Rate	Maximum Payload
Bluetooth Classic (SPP)	3 Mbps	251 B
BLE	2 Mbps	20 B *
MQTT(Wi-Fi)	150 Mbps	1–8 KB
ESP-NOW	150 Mbps	250 B (v1.0)/1470 B (v2.0)
S7 Protocol	100 Mbps	240 B

* Default legacy configuration (ATT_MTU = 23 B) without Data Length Extension (DLE).

.

Based on these considerations, all protocols were rigorously tested, ensuring they operated at the maximum payload capacities that guarantee zero data loss—a critical requirement in industrial automation environments. Aside from these constraints, each protocol was maintained in its default out-of-the-box configuration.

To ensure strict experimental reproducibility, it is imperative to define the underlying network and physical layer parameters governed by the ESP32 framework (ESP-IDF). To avoid software-induced energy overhead, no application-level retransmission mechanisms were implemented. Instead, data reliability was guaranteed by the inherent lower-layer mechanisms: MAC-layer hardware retries for ESP-NOW unicast communication, Link Layer Automatic Repeat reQuest (ARQ) for the Bluetooth stacks, and TCP-level packet management for MQTT (configured with QoS 0). Documenting the exact software builds and development environment is critical, as sub-version optimizations in the core network stacks can fundamentally alter the energy profiling results. Therefore, all firmware, network, and physical layer parameters—including transmission powers, library versions, and protocol-specific maximum transmission units (MTUs)—are explicitly summarized in

Table 2. Detailed software and network configuration parameters for reproducibility.

Parameter Category	Configured Value/Specification
Firmware and Software Environment
Development Environment	Visual Studio Code with PlatformIO
Core Firmware Framework	ESP32 Arduino Core (v. 3.3.7)
Hardware Management Library	M5Core2 Library (v. 0.2.0)
Application Layer Libraries	PubSubClient (v. 2.8) for MQTT, Settimino (v. 2.0.0) for S7
Physical (PHY) and MAC Layer Settings
Wi-Fi Channel (ESP-NOW & MQTT)	Channel 1 (2412 MHz)
Wi-Fi Transmission Power	+19.5 dBm (Hardware Default)
Bluetooth Transmission Power	+3 dBm (Hardware Default)
ESP-NOW PHY Rate	1 Mbps (Default 802.11b PHY for robust range)
Protocol-Specific Constraints (Intervals & MTUs)
ESP-NOW Maximum Payload	250 Bytes per frame (v1.0 legacy constraint)
BLE Connection Interval	15–30 ms (Stack auto-negotiated default)
BLE ATT_MTU	23 Bytes (Standard default ATT_MTU yielding 20 B payload)
Bluetooth Classic (SPP) RFCOMM MTU	∼990 Bytes (Stack auto-negotiated)
MQTT (Wi-Fi/TCP) MTU	1500 Bytes (Standard 802.11 MTU), QoS 0
Siemens S7 (Ethernet) PDU Size	240 Bytes (Standard S7-300 PDU limit)

. Maintaining these baseline parameters ensures that the energy profiling accurately reflects the fundamental technological characteristics of the protocols rather than application-specific software optimizations. Unless specifically manipulated for the purpose of the measurement, the ESP-IDF framework’s out-of-the-box hardware defaults were maintained to reflect standard industrial retrofitting conditions.

While optimizing protocol-specific parameters (e.g., MTU size or connection interval) could yield further performance gains, such granular optimization remains outside the scope of the present research, which focuses on characterizing baseline operational performance. Guided by these principles, the maximum payload sizes ensuring lossless communication were established for each data category, a detailed breakdown of these configurations is presented in

Table 3. Configured maximum payload sizes for loss-free communication across the investigated data volumes.

Protocol	50 B	500 B	5000 B	15,000 B
Bluetooth Classic (SPP)	50 B	512 B	512 B	512 B
BLE	20 B	20 B	20 B	20 B
MQTT (Wi-Fi)	50 B	512 B	512 B	512 B
ESP-NOW	50 B	250 B	250 B	250 B
S7 Protocol	50 B	240 B	240 B	240 B

.

3.3. Measurement Procedure

To guarantee strict reproducibility and isolate the energy footprint of the communication protocols, a highly controlled measurement procedure was implemented. Energy consumption was recorded using the aforementioned high-precision power profiler, supplying a constant $5\mathrm{V}$ DC to the gateway. The measurement chain captured voltage and current data at a continuous high-frequency sampling rate of $4000\mathrm{Hz}$. The automated measurement sequence was initialized by configuring the communication protocol, payload size, and number of measurement cycles via the ESP32 touchscreen display and the HMI. Upon initiation, the HMI toggled a specific control bit within the PLCs, which was continuously monitored by the gateway devices. Detecting this trigger, the ESP32 microcontrollers activated the requisite radio hardware and established the mutual connection. To accurately delineate the active data transaction phases, hardware-level GPIO synchronization was employed and directly fed into the Otii profiler. The transmitting ESP32 pulled a dedicated GPIO pin HIGH at the exact onset of data transmission and pulled it LOW immediately upon completing the data dispatch. Correspondingly, the receiving ESP32 pulled its respective GPIO pin HIGH upon detecting the first incoming data packet and LOW once the entire payload was successfully received. Furthermore, specific hardware-level boundary conditions were enforced to prevent external variables from distorting the energy profiles. The measurements strictly reflect the power consumption of the IoT Gateway device; the mains-powered legacy Siemens S7-300 PLC was entirely excluded from the energy metrics. To eliminate unnecessary energy overhead, the M5Stack Core2 IPS display, backlight, vibration motor, and speaker were explicitly powered down using the integrated AXP192 Power Management IC (PMIC) during the active measurement phase. Importantly, during the evaluation of the wireless communication stacks, the external Ethernet LAN module was powered independently via the PLC’s 9–24 V power supply rather than drawing current from the ESP32. This ensured its baseline current did not negatively skew the wireless energy evaluations. Conversely, during the wired S7 Protocol measurements, the LAN module was powered directly by the ESP32 to capture the complete energy footprint of the wired gateway. To minimize measurement uncertainty and enhance statistical reliability, ten measurement cycles were executed with a two-second interval maintained between cycles to accurately characterize the standby energy consumption. The raw voltage, current, and GPIO state data captured by the power profiler were subsequently exported and evaluated using a custom Python (3.14.6) script. The total transaction energy (E) was determined by numerical integration of the measured current–time curve between the strict GPIO temporal boundaries using the trapezoidal rule, according to the following equation:

$$E=V·\sum {\displaystyle \frac{I_i+I_{i+1}}{2}}·\Delta t$$

(1)

where V represents the constant supply voltage ($5\mathrm{V}$), $I_i$ and $I_{i+1}$ denote the instantaneous current measurements at consecutive sampling points, and $\Delta t$ is the constant time interval between samples (determined by the $4000\mathrm{Hz}$ sampling frequency). Given that network latency significantly influences the active duration of the radio interface, the Total Energy per Transaction was selected as the primary metric for protocol comparison. Average values were calculated as the arithmetic mean of the total energy consumption recorded across the ten independent measurement runs; consequently, variations in transaction duration are directly reflected in the final results. Data are reported as mean values accompanied by their respective standard deviation ($\pm \mathrm{SD}$).

4. Results and Discussion

In this section, the results of the experimental measurements are presented and analyzed, providing quantitative answers to the formulated Research Questions (RQ1–RQ4). To rigorously validate the empirical findings, formal statistical hypothesis testing was conducted on the raw measurement data. A One-Way Analysis of Variance (ANOVA) was performed to evaluate the variance in energy consumption across the investigated communication stacks. This was followed by a Tukey HSD post hoc test to identify specific pair-wise differences. All statistical tests and subsequent boundaries were strictly evaluated utilizing 95% confidence intervals ($\alpha =0.05$). While the macroscopic sample size of independent measurement cycles was $N=10$ per protocol, the statistical robustness of these trials is exceptionally high. Each energy value is derived from continuous high-precision power profiling at 4000 Hz, integrating thousands of instantaneous readings per cycle. Furthermore, due to strict MTU constraints, large payload transmissions (e.g., 15,000 bytes) necessitate the sequential repetition of dozens or hundreds of identical packet transactions within a single cycle. This inherent packet-level repetition heavily suppresses hardware variance. Consequently, the ANOVA yielded exceptionally large F-statistics (e.g., $F(4,45)=6822.82$ for the 5000-byte transmission phase). These values represent a massive statistical effect size, mathematically demonstrating that the choice of the communication protocol almost entirely accounts for the observed differences in energy consumption. In all evaluated scenarios, the hypothesis testing indicated a highly significant difference ($p<0.001$), firmly substantiating the energetic crossover points and scalability claims presented in this study. The detailed ANOVA matrices and 95% confidence interval bounds are provided in Appendix A (see

Table A1. Master summary of One-Way ANOVA results comparing energy consumption across protocols ($N=10$ per group, $d{f}_{between}=4$, $d{f}_{within}=45$). Statistical significance at the $p<0.001$ level is denoted by ***.

Measurement Scenario	Degrees of Freedom	F-Statistic	p-Value	Significance
Active Transmission (TX Context/Write)
50 B Payload	(4, 45)	166.73	<0.001	***
500 B Payload	(4, 45)	865.36	<0.001	***
5000 B Payload	(4, 45)	6822.82	<0.001	***
15,000 B Payload	(4, 45)	2197.78	<0.001	***
Active Reception (RX Context/Read)
50 B Payload	(4, 45)	186.94	<0.001	***
500 B Payload	(4, 45)	74.22	<0.001	***
5000 B Payload	(4, 45)	141.01	<0.001	***
15,000 B Payload	(4, 45)	586.32	<0.001	***
Standby (Idle) Mode
Standby (RX Interface)	(4, 45)	15,041.6	<0.001	***
Standby (TX Interface)	(4, 45)	14,025.0	<0.001	***

). With the statistical validity of the baseline established, the energetic magnitude of the active data transmission phases was evaluated (addressing RQ1 and RQ2). However, to ensure the precise interpretation of the empirical results, the operational boundaries of the evaluated contexts must be explicitly defined. As established in the methodology, the energy required for data acquisition (reading from the source PLC) and data commitment (writing to the target PLC) was measured independently to isolate the performance of the wireless communication stacks. Consequently, the terms used in the subsequent tables refer exclusively to the wireless transaction phases:

• TX Context (Transmitting Gateway): Refers strictly to the energy footprint of the source IoT gateway during the active wireless transmission phase. This encompasses protocol encapsulation, radio frequency (RF) transmission, and the latency incurred while awaiting MAC-layer or TCP-layer acknowledgments (ACK).
• RX Context (Receiving Gateway): Refers strictly to the energy footprint of the target IoT gateway during the active wireless reception phase. This encompasses RF reception, protocol decapsulation, and the dispatching of necessary acknowledgments.

This terminological distinction is critical, as the inherent energy asymmetry between transmitting and receiving operations constitutes a fundamental characteristic of the evaluated protocol architectures.

Table 4. Numerical results of average energy consumption [mJ] and standard deviation (±SD) for different protocols and payload sizes.

Payload	ESP-NOW		BLE		Bluetooth Classic (SPP)		MQTT (Wi-Fi)		S7 Protocol
Size	RX Context	TX Context	RX Context	TX Context	RX Context	TX Context	RX Context	TX Context	RX Context	TX Context
50 byte	$11.34\pm 0.50$	$1.64\pm 0.02$	$3.61\pm 0.28$	$5.65\pm 1.21$	$1.62\pm 0.25$	$5.62\pm 0.99$	$169.46\pm 36.58$	$74.37\pm 16.56$	$27.26\pm 5.74$	$24.88\pm 0.87$
500 byte	$23.28\pm 0.75$	$8.04\pm 0.18$	$12.64\pm 2.50$	$15.83\pm 0.30$	$7.38\pm 0.93$	$7.41\pm 0.17$	$223.77\pm 74.05$	$183.71\pm 19.09$	$80.98\pm 9.68$	$113.09\pm 1.47$
5000 byte	$221.13\pm 3.95$	$76.87\pm 0.35$	$133.54\pm 2.72$	$139.15\pm 2.18$	$60.55\pm 1.55$	$60.67\pm 3.28$	$609.54\pm 148.64$	$300.64\pm 33.13$	$565.97\pm 24.30$	$996.31\pm 4.09$
15,000 byte	$462.18\pm 2.62$	$943.66\pm 1.33$	$396.57\pm 1.66$	$412.97\pm 6.66$	$182.80\pm 3.71$	$173.84\pm 1.85$	$1130.96\pm 179.64$	$1212.35\pm 165.49$	$1676.27\pm 18.42$	$2963.01\pm 5.52$

summarizes the mean energy consumption and standard deviation of the isolated communication protocols across the four payload sizes.

Analyzing the data presented in Table 4 reveals several critical correlations that provide direct answers to the proposed research questions. Regarding RQ2, the ESP-NOW protocol demonstrated outstanding efficiency for small data packets ($1.64\pm 0.02\mathrm{mJ}$). Throughout the investigation, this technology proved to be the most stable, as evidenced by consistently low standard deviation values. In contrast, the highest measurement uncertainty was observed with the MQTT protocol, particularly at a payload size of 15,000 bytes ($\mathrm{SD}=179.64\mathrm{mJ}$). This is a direct consequence of significant network layer overhead and the jitter (latency fluctuation) inherent in broker-based architectures.

Furthermore, the analysis highlights a critical energetic crossover point between the two Bluetooth technologies, providing primary evidence for RQ3. While the energy demands of BLE Indication ($5.65\mathrm{mJ}$) and Bluetooth Classic Transmission ($5.62\mathrm{mJ}$) are nearly identical for a 50-byte payload, the trend changes drastically as data volume increases. At 15,000 bytes, Bluetooth Classic proved to be 2.4 times more efficient ($173.84\mathrm{mJ}$) than BLE ($412.97\mathrm{mJ}$). This mathematically confirms that the fragmentation mechanism of BLE—which necessitates splitting large datasets into numerous small packets—imposes a significant energetic disadvantage compared to the continuous, streaming-based data transmission of Bluetooth Classic. To more clearly illustrate these performance variations across several orders of magnitude, the results are visualized on a logarithmic scale in Figure 3.

These findings also elucidate the directional energy efficiency (RX/TX asymmetry) of the protocols, further addressing RQ1 and RQ2. For ESP-NOW, it is observable that at small payloads, the receiving operation ($11.34\mathrm{mJ}$) is significantly more resource-intensive than sending ($1.64\mathrm{mJ}$). This discrepancy is attributable to the quiescent current of the radio’s “listening” mode. Such an asymmetry represents a critical design consideration for legacy system integration, where the gateway must remain in a continuous state of readiness to intercept incoming data. In the investigation of the wired S7 Protocol, the most pronounced asymmetry was recorded at the 15,000-byte threshold: writing data to the PLC ($2963.01\mathrm{mJ}$) required nearly twice as much energy as reading. This phenomenon can be explained by the internal write cycle times of the PLC processor and the complex acknowledgment mechanisms inherent in S7 transactions, highlighting the significant energetic overhead of wired industrial stacks.

To explore protocol efficiency more deeply and provide conclusive evidence for RQ3, the specific energy consumption (μJ/byte) was calculated, with results summarized in

Table 5. Specific energy consumption [μJ/byte] for data reception and transmission across various payload sizes.

Payload	ESP-NOW		BLE		Bluetooth Classic (SPP)		MQTT (Wi-Fi)		S7 Protocol
Size	RX Context	TX Context	RX Context	TX Context	RX Context	TX Context	RX Context	TX Context	RX Context	TX Context
50 byte	226.80	32.80	72.20	113.00	32.40	112.40	3389.20	1487.40	545.20	497.60
500 byte	46.56	16.08	25.28	31.66	14.76	14.82	447.54	367.42	161.96	226.18
5000 byte	44.23	15.37	26.71	27.83	12.11	12.13	121.91	60.13	113.19	199.26
15,000 byte	30.81	62.91	26.44	27.53	12.19	11.59	75.40	80.82	111.75	197.53

. The data clearly validate the principle of economies of scale: at low data volumes (50 B), the receiving direction of MQTT exhibits the highest specific cost (3389.20 μJ/byte), primarily due to the maintenance overhead of the TCP-based connection. In terms of scalability, Bluetooth Classic emerged as the most efficient, with specific costs dropping to 11.59 μJ/byte for large payloads, reinforcing the advantages of streaming-based transmission for bulk data. Conversely, an energetic breaking point was identified for ESP-NOW at 15,000 bytes (62.91 μJ/byte), confirming that beyond a certain size, the overhead of software-defined fragmentation and Wi-Fi stack management can no longer be compensated for by the raw speed of the protocol.

The sharp variation in specific energy consumption (μJ/byte) observed across varying payload sizes can be attributed to the architectural principle of fixed overhead amortization. For small data packets (e.g., 50 bytes), the energy expenditure is heavily dominated by fixed transactional costs. These include the physical layer overheads—such as radio transceiver wake-up transients and Phase-Locked Loop (PLL) calibration—as well as the transmission of mandatory MAC, network, and transport layer headers. Because this substantial fixed energy is divided by a very small payload, the resulting specific energy consumption is inherently high.

As the payload volume increases, these initial setup and header costs are amortized over a significantly larger number of bytes, leading to the observed steep, non-linear decline in specific energy. However, the exact trajectory of this decline is strictly governed by the MTU and the fragmentation mechanism of each respective protocol. For instance, technologies like BLE have heavily constrained MTUs, necessitating the fragmentation of larger datasets into numerous smaller packets. This fragmentation introduces recurring overhead penalties (repeated headers and inter-frame spacing), which halts the decline of specific energy and eventually flattens the curve. Conversely, stream-oriented protocols like Bluetooth Classic or persistent TCP/IP connections (MQTT, S7) maintain a continuous data flow, allowing the protocol to bypass recurring setup costs and achieve superior specific energy efficiency at payloads of 15,000 bytes.

When interpreting the scalability limitations and specific energy crossover points of the evaluated technologies, a strict technical distinction must be made between fundamental protocol limits and default software implementation constraints. For example, the 250-byte maximum payload of ESP-NOW reflects the constraints of the ESP-NOW v1.0 specification, which is limited by the size of a single vendor-specific Information Element (IE) within the IEEE 802.11 Action Frame [48]. While the newer ESP-NOW v2.0 standard extends this payload limit to 1470 bytes utilizing extended frames, the v1.0 baseline was maintained in this study to ensure backward compatibility with older legacy IoT nodes. Consequently, under these v1.0 legacy configurations, large datasets must be fragmented at the application layer, inherently capping the protocol’s energy efficiency at higher volumes. In contrast, the 20-byte payload constraint utilized for BLE in this study represents an out-of-the-box software implementation limit based on the legacy default 23-byte ATT_MTU. This default configuration was purposefully maintained to represent a “lowest common denominator” baseline, reflecting scenarios where gateways must interface with older legacy sensors limited to the Bluetooth 4.0 specification. However, it is highly relevant to note that modern implementations (BLE 4.2 and later) support Data Length Extension (DLE) and dynamic MTU negotiation (up to 512 bytes). Implementing a larger MTU would fundamentally alter the BLE energy profile for large payloads by minimizing recurring header overheads and inter-frame spacing, resulting in significantly lower specific energy consumption (μJ/byte). Therefore, the energetic degradation of BLE observed in this study reflects unoptimized, baseline legacy compatibility rather than the theoretical maximum efficiency of the modern BLE stack. Future deployment strategies should strictly prioritize MTU negotiation when integrating BLE into high-throughput industrial networks.

Beyond the active phases, the overall energetic profile of IoT-based systems is fundamentally dictated by the characteristics of their quiescent periods. To address the question posed in RQ4 and establish the “energetic baseline” of the network interfaces, a precise quantification of the Standby energy demand is indispensable, as this metric represents the continuous operational footprint of the system. During the automated measurement sequences, a specific one-second steady-state window was extracted from the two-second idle period inserted between individual transactions to serve as the basis for quantification. Consistent with the methodology applied to the active phases, energy values were determined using the trapezoidal rule based on the arithmetic mean of ten independent measurement runs, accompanied by their respective standard deviation ($\pm \mathrm{SD}$). The resulting data are summarized in

Table 6. Baseline power consumption in standby (idle) mode [mW] and standard deviation (±SD) for various communication protocols.

Condition	ESP-NOW		BLE		Bluetooth Classic (SPP)		MQTT (Wi-Fi)		S7 Protocol
	RX Context	TX Context	RX Context	TX Context	RX Context	TX Context	RX Context	TX Context	RX Context	TX Context
Standby	$607.14$	$533.42$	$85.04$	$353.91$	$592.01$	$524.93$	$664.03$	$626.60$	$912.49$	$913.44$
±SD	$\pm 0.28$	$\pm 0.25$	$\pm 0.46$	$\pm 0.43$	$\pm 0.38$	$\pm 0.26$	$\pm 17.36$	$\pm 12.26$	$\pm 0.17$	$\pm 0.19$

.

The data presented in Table 6 indicate that the energy demand in the standby state exhibits significant variance across the different physical interfaces (Wi-Fi, Bluetooth, and Ethernet). While the numerical values reflect the high precision of the measurement methodology, the orders-of-magnitude differences between protocols and the distinct “energetic baselines” of the respective technologies are more effectively illustrated in the bar chart provided in Figure 4.

The bar chart in Figure 4 visually confirms the results presented in Table 6 and, with respect to RQ4, highlights the drastic differences between the energetic baselines of the investigated technologies. The superiority of BLE technology in receive standby (RX context) is particularly striking, as its energy demand is orders of magnitude lower compared to Wi-Fi-based solutions. In contrast, the constant, high baseline consumption of wired S7 communication (∼913 mW) clearly indicates that Ethernet-based interfaces (W5500) are optimized for deterministic industrial data transmission rather than energy minimization. This data confirms that when implementing wired retrofit solutions, the continuous maintenance cost of the network stack is a dominant factor in the overall energy balance. The combined evaluation of active and standby measurements provides a comprehensive answer to RQ4, emphasizing the critical design consideration that low active transaction energy (e.g., ESP-NOW) alone does not guarantee a favorable energy footprint for a retrofit solution if the quiescent consumption of the interface is high. This correlation underscores a fundamental “performance vs. standby” trade-off: the selection of the network stack must be optimized as a function of the expected reporting frequency (duty cycle). In scenarios with low reporting frequency, the weight of standby consumption is decisive, whereas at high data densities, the specific efficiency of the active phase becomes the priority.

Based on the empirical standby measurements (reported as average continuous power in mW), it is evident that practical protocol selection cannot rely exclusively on the energy cost of active data transmission. In a real-world industrial retrofitting scenario, the optimal communication stack is fundamentally dictated by the expected duty cycle of the IoT gateway. To establish a comprehensive energy budget, engineers must calculate the total energy consumption ($E_{total}$) over a specific operational period (e.g., one hour or one day) using the following relationship:

$$E_{total}=\sum (E_{active}·N)+(P_{standby}·T_{idle})$$

(2)

where $E_{active}$ is the specific energy required for a single active data transaction (in mJ), N is the number of transactions during the period, $P_{standby}$ is the average standby power (in mW), and $T_{idle}$ is the total time spent in the idle state (in s). This relationship highlights the critical importance of the duty cycle. For low-frequency telemetry applications (e.g., transmitting machine status once per minute), $T_{idle}$ is massive, making the baseline $P_{standby}$ the dominant factor. In such scenarios, protocols with aggressive sleep states and low standby overhead (such as BLE) are the most sustainable choices. Conversely, in high-frequency, continuous data streaming scenarios (e.g., real-time vibration analysis), the $E_{active}\times N$ component dictates the energy budget. In these cases, protocols that minimize the active transmission time and specific energy per byte—such as ESP-NOW for small packets or Bluetooth Classic for large payloads—become significantly more efficient, despite their potentially higher standby power requirements.

Limitations of the Study

A notable boundary condition of the current experimental setup is the evaluation of unencrypted communication protocols. While implementing cryptographic standards (e.g., TLS for MQTT, or AES-CCMP for ESP-NOW and BLE) is paramount for internet-facing Industrial IoT deployments, this study intentionally focused on establishing a fundamental, unencrypted energetic baseline. This baseline is essential for accurately quantifying the inherent network overhead (e.g., fragmentation, header sizes, and connection maintenance) prior to introducing the computational burden of cryptographic algorithms. Furthermore, in many practical brownfield retrofitting applications, IoT gateways are deployed within strictly isolated, air-gapped Operational Technology (OT) networks. In such localized edge environments, perimeter firewalls and physical isolation often mitigate the immediate necessity for node-level encryption, allowing engineers to prioritize energy efficiency and ultra-low latency. Nevertheless, quantifying the specific energy degradation introduced by encryption overhead remains a highly relevant direction for future research. Furthermore, a critical limitation of this study is its reliance on a single hardware platform (the ESP32-based M5Stack Core2). Consequently, the absolute energy metrics presented in this research (μJ/byte and mW) are inherently tied to the specific Xtensa dual-core architecture and the radio transceiver efficiency of the ESP32 silicon. Different microcontroller families commonly used in industrial IoT—such as ARM Cortex-M-based STM32 devices or Nordic Semiconductor’s nRF series—feature fundamentally different sleep state architectures, peripheral power domains, and radio implementations. While the relative energetic differences between the communication stacks (e.g., the high TCP/IP overhead of MQTT versus the fragmentation penalty of BLE) are expected to exhibit similar trends across different hardware, the absolute values cannot be broadly generalized. Therefore, future cross-platform evaluations are essential to determine exactly how different silicon architectures influence the overall efficiency of these wireless protocols in industrial retrofitting scenarios. Finally, it is important to note that the present study focuses on establishing a fundamental energetic baseline for the investigated protocols. Consequently, the measurements were conducted under controlled, near-ideal laboratory conditions. This methodological approach was necessary to isolate the inherent energy overheads of the protocols—such as header sizes, fragmentation mechanisms, and baseline standby architectures—without the unpredictable variance introduced by environmental noise. We acknowledge that practical industrial environments introduce significant challenges, including severe electromagnetic interference (EMI), multipath fading from dense metal structures, and 2.4 GHz co-channel coexistence. While these real-world factors will inevitably trigger retransmissions and increase the overall energy consumption, the near-ideal baseline established in this study provides the essential comparative data required for the thermal and energetic design of IoT gateways. Investigating the degradation of protocol efficiency under specific industrial interference profiles remains a highly relevant direction for future work. It should be noted that Low-Power Wide-Area Network (LPWAN) technologies (such as LoRaWAN, NB-IoT, and Sigfox) were intentionally excluded from this specific comparative analysis to prevent the distortion of the energetic baseline. The protocols evaluated in this study (Wi-Fi, BLE, Bluetooth Classic) are characterized by relatively high data transmission rates suitable for localized cell-level communication. Conversely, LPWANs operate at significantly lower data rates, which would result in orders-of-magnitude differences in active transmission times and specific energy metrics, thus requiring a separate evaluation framework. Furthermore, a primary architectural objective of this retrofitting setup was to utilize a generic, low-budget microcontroller ecosystem (ESP32) relying solely on its integrated transceiver, without the energetic and financial overhead of additional, dedicated LPWAN hardware modules. The energetic evaluation of low-cost LPWAN solutions in brownfield scenarios remains a critical subject for our future research.

5. Conclusions

This research successfully established a novel, energy-centric framework for the IoT-based retrofitting of manufacturing cells equipped with legacy PLCs. By utilizing a highly controlled, dedicated testbed, the study provided a deterministic, zero-data-loss energetic baseline that directly compared modern wireless communication stacks with established legacy wired standards (Siemens S7 Protocol). Supported by rigorous statistical hypothesis testing (ANOVA and Tukey HSD, $p<0.001$), the experimental results clearly validate the fundamental premise of this research: the selection and configuration of the communication protocol significantly influence the overall energy balance of the retrofit architecture. The extended payload analysis (spanning from 50 to 15,000 bytes) and the introduction of specific energy consumption metrics (μJ/byte) provided deeper insights, highlighting the principle of “economies of scale” in industrial data transmission. While Bluetooth Classic proved to be the most scalable—reducing specific costs tenfold to as low as 11.59 μJ/byte as payload increased—a critical energetic breaking point was identified for the ESP-NOW protocol at 15,000 bytes. At this threshold, the value of 62.91 μJ/byte indicates that software-defined fragmentation and Wi-Fi stack management overhead begin to outweigh the protocol’s inherent speed advantages. Furthermore, the extremely high receiving cost of MQTT at small packet sizes (3389.20 μJ/byte) underscores that network layer maintenance can, in certain scenarios, become a more dominant factor than the actual data payload. The identification of a sharp energetic crossover point between BLE and Bluetooth Classic confirms that precise knowledge of the transmitted data volume is essential for optimal protocol selection, as the streaming-based approach of Bluetooth Classic is energetically superior to the fragmented transmission of BLE for large datasets. Moreover, the results confirm that the Standby state of the network interface is as critical as the active phase. Retrofitting via wired Ethernet demonstrated the highest steady-state energy demand (∼913 mW), a factor that fundamentally dictates the thermal and energetic design of enclosed IoT gateways in industrial environments. In summary, by accurately mapping both active transactions and prolonged standby states, this study synthesized the empirical findings into a formal Qualitative Decision Matrix, as presented in

Table 7. Qualitative decision matrix for industrial IoT protocol selection.

Protocol	Optimal Payload Range	Standby Power Profile	Key Energetic Limitation	Recommended Industrial Use Case
ESP-NOW	Very Small (<500 B)	Medium	Severe fragmentation penalty at large payloads	Ultra-low latency machine telemetry
BLE	Small to Medium	Very Low	High overhead due to restricted MTU size	Battery-powered sensor nodes
Bluetooth Classic	Large (>5000 B)	Medium	Suboptimal for small, frequent transmissions	Bulk data transfer (e.g., diagnostics, OTA)
MQTT (Wi-Fi)	Any (TCP/IP scalable)	High	Massive overhead for small data packets	Cloud-integrated IT/OT gateways
S7 (Ethernet)	Any (Wired deterministic)	Very High	Constant high baseline energy demand	Mission-critical legacy PLC networking

. These results provide a robust, quantitative foundation for engineers to optimize protocol selection based on the expected duty cycle, bridging the gap between legacy industrial automation and sustainable Industry 4.0 architectures.

Future Works

Building upon the findings of this study, several avenues for future research remain to be explored. First, the investigation could be extended to analyze the impact of encryption (e.g., TLS for MQTT or AES for ESP-NOW) on energy consumption, as security is a paramount concern in industrial IoT deployments. Second, evaluating the performance of these protocols under real-world industrial interference (high electromagnetic noise environments) would provide further insights into the reliability–energy trade-off. Additionally, future studies should focus on the energy efficiency of Deep Sleep modes and wake-up strategies in battery-powered or energy-harvesting-based sensor nodes, where the standby energy baseline becomes the most critical factor. Finally, expanding the measurement series to include other LPWAN technologies, such as LoRaWAN or NB-IoT, would allow for an even broader comparison of retrofitting solutions for large-scale manufacturing facilities.