Lightweight Embedded IoT Gateway for Smart Homes Based on an ESP32 Microcontroller

Abstract

The rapid expansion of the Internet of Things (IoT) demands scalable, efficient, and user-friendly gateway solutions that seamlessly connect resource-constrained edge devices to cloud services. Low-cost, widely available microcontrollers, such as the ESP32 and its ecosystem peers, offer integrated Wi-Fi/Bluetooth connectivity, low power consumption, and a mature developer toolchain at a bill of materials cost of only a few dollars. For smart-home deployments where budgets, energy consumption, and maintainability are critical, these characteristics make MCU-class gateways a pragmatic alternative to single-board computers, enabling always-on local control with minimal overhead. This paper presents the design and implementation of an embedded IoT gateway powered by the ESP32 microcontroller. By using lightweight communication protocols such as Message Queuing Telemetry Transport (MQTT) and REST APIs, the proposed architecture supports local control, distributed intelligence, and secure on-site data storage, all while minimizing dependence on cloud infrastructure. A real-world deployment in an educational building demonstrates the gateway’s capability to monitor energy consumption, execute control commands, and provide an intuitive web-based dashboard with minimal resource overhead. Experimental results confirm that the solution offers strong performance, with RAM usage ranging between 3.6% and 6.8% of available memory (approximately 8.92 KB to 16.9 KB). The initial loading of the single-page application (SPA) results in a temporary RAM spike to 52.4%, which later stabilizes at 50.8%. These findings highlight the ESP32’s ability to serve as a functional IoT gateway with minimal resource demands. Areas for future optimization include improved device discovery mechanisms and enhanced resource management to prolong device longevity. Overall, the gateway represents a cost-effective and vendor-agnostic platform for building resilient and scalable IoT ecosystems.

1. Introduction

IoT has emerged as a transformative force across modern society, interconnecting billions of sensors, actuators, and embedded devices to enable data-driven automation in domains ranging from industrial manufacturing to smart cities and personalized healthcare. This proliferation of connected devices, projected to exceed 29 billion globally by 2030 [1,2], has created an unprecedented need for robust middleware capable of managing heterogeneous hardware, diverse communication protocols, and the deluge of data generated at the network edge [2]. Within this landscape, IoT gateways have become indispensable architectural components, serving as intelligent intermediaries that bridge resource-constrained edge devices with cloud-based analytics platforms [3,4]. By performing critical functions such as protocol translation, data aggregation, and localized decision-making, these gateways address fundamental challenges of scalability, latency, and energy efficiency inherent to distributed IoT systems.

The strategic importance of IoT gateways extends beyond technical interoperability. In energy-sensitive applications like smart buildings or environmental monitoring, gateways enable real-time optimization of resource consumption, directly contributing to sustainability goals through granular control of HVAC systems, lighting, and power distribution [5,6]. Similarly, in industrial settings, gateway-mediated edge computing reduces reliance on centralized cloud processing, minimizing downtime caused by network latency or disruptions. This distributed architecture aligns with emerging paradigms such as fog computing, where computational workloads are dynamically partitioned across edge, gateway, and cloud tiers based on quality of service (QoS) requirements [7].

Despite their strategic role, contemporary IoT gateway implementations face three systemic limitations that hinder widespread adoption. First, proprietary solutions perpetuate vendor lock-in, forcing adopters into restrictive ecosystems with limited hardware/software compatibility. Second, conventional gateway platforms often demand x86-level computational resources and specialized IT expertise for deployment, requirements that are impractical for small-scale deployments or resource-constrained environments. Third, while microcontroller-based alternatives like the ESP32 offer compelling advantages in power efficiency and cost [8], their configuration typically involves complex toolchains and low-level programming, creating accessibility barriers for domain experts lacking embedded systems experience [9]. These challenges are particularly acute in use cases requiring rapid deployment cycles or operational autonomy from cloud infrastructure.

This study confronts these limitations through the design and implementation of an embedded IoT gateway architecture that combines the computational capabilities of the ESP32 microcontroller with the user-centric design philosophy of Shelly (https://shelly-api-docs.shelly.cloud/gen2/Devices/Gen2/ShellyPro3EM, accessed on 10 June 2025) smart devices. The Shelly platform was selected for its unique combination of enterprise-grade features (including MQTT support, REST APIs, and over-the-air programmability [10]) and consumer-friendly plug-and-play operation, attributes that bridge the gap between professional IoT systems and approachable automation for non-technical users. Our implementation demonstrates how this hybrid approach can deliver cloud-independent monitoring and control while retaining the extensibility expected from industrial solutions.

A defining characteristic of this work is its emphasis on full operational locality. The gateway hosts its own web-based management interface and decision-making logic without dependencies on external cloud services. This architectural choice responds to growing concerns about data sovereignty, General Data Protection Regulation (GDPR) compliance, and operational resilience in scenarios where Internet connectivity may be intermittent or undesirable. Early prototyping considered single-board computers like the Raspberry Pi [11] for their processing headroom, but their higher energy footprint (typically 3–5 W active compared to sub-1W for ESP32 solutions) and mandatory operating system overhead rendered them unsuitable for always-on embedded deployments. The Shelly 3EM hardware, built around a dual-core ESP32, emerged as an optimal compromise, providing native support for both MQTT telemetry [12] and WebSocket-based real-time control within a compact, fanless form factor.

The core contribution of this research is the demonstration that a carefully engineered ESP32-based system can fulfill all essential gateway functions—protocol mediation, edge computation, and user interaction—while matching the functional utility of conventional server-class gateways at a fraction of their cost and energy footprint. Field validation in an educational building deployment confirms the practical viability of this approach, showcasing capabilities such as real-time energy use analytics, equipment scheduling, and fault detection running entirely at the edge. By systematically addressing interoperability, usability, and sustainability constraints, this work provides a template for next-generation IoT gateways that are simultaneously powerful, accessible, and environmentally conscious.

While many hardware and firmware platforms exist for IoT gateway implementations [13,14], this study intentionally focuses on the ESP32-based Shelly platform. The selection reflects the deployment context: ESP32/Shelly devices were already integrated on site, enabling an embedded, always-on gateway without procuring additional equipment or altering existing infrastructure [15,16]. Other microcontroller options, such as Raspberry Pi’s RP2040/RP2350 family and STM32 or Arduino MKR-based boards, as well as RTOS-centric stacks, may offer comparable capabilities [17,18]. A systematic MCU-to-MCU benchmarking (e.g., ESP32 vs. RP2350) was outside our applied scope and is identified as future work.

The remainder of this article is organized as follows. Section 2 reviews related work, including IoT gateway architectures, hardware platforms, and the role of the ESP32 microcontroller. Section 3 details the proposed embedded gateway architecture and its core design principles. Section 4 presents a real-world deployment in an educational building, demonstrating practical feasibility. Section 5 reports experimental results on resource utilization, scalability, and reliability. Section 6 discusses implementation trade-offs for an Internet-connected smart-home gateway. Finally, Section 7 concludes the paper and outlines future work.

2. Literature Review

The rapid evolution of the IoT has necessitated advanced solutions for integrating heterogeneous devices across disparate networks. IoT gateways serve as critical enablers in this ecosystem, bridging edge devices with cloud platforms while addressing challenges of protocol diversity, data processing, and scalability. This section synthesizes key research on IoT gateway architectures, hardware platforms, and the pivotal role of the ESP32 microcontroller, culminating in a comparative analysis of design paradigms.

2.1. Analysis of Gateway Implementations

Modern IoT gateways serve as critical middleware, addressing three fundamental challenges in heterogeneous networks—protocol interoperability, distributed data processing, and scalable device management. Recent architectural innovations demonstrate how gateway designs are evolving to meet these demands across diverse application domains. Table 1 summarizes key gateway implementations and their respective design trade-offs.

Zachariah et al. [19] provide a critical examination of current IoT gateway designs, identifying a fundamental challenge—the conflation of network connectivity, in-network processing, and user interface functions. This integration limits scalability and restricts application-agnostic connectivity. To address these limitations, they propose a novel architecture leveraging Bluetooth Low Energy (BLE) radios to simplify the connection of IoT peripherals to the Internet. Drawing parallels with the transformative impact of Wi-Fi access points on laptop connectivity, their study advocates for a global deployment of modular IoT gateways. This approach would enable scalable, application-agnostic ecosystems while overcoming the limitations of stove-piped architectures.

Macias et al. [20] focus on the critical role of IoT gateways in achieving interoperability among diverse devices, particularly in scenarios where many IoT devices lack native IP-based communication. Their study introduces a multi-protocol IoT gateway capable of facilitating seamless data exchange across heterogeneous wireless technologies. Key features include remote configuration of wireless nodes, a flexible algorithm for unifying sensor data formats, and energy-efficient data transmission using the MQTT protocol. Through a proof-of-concept implementation, they demonstrate the feasibility and effectiveness of the gateway in managing environmental sensing applications, highlighting its low-energy consumption and multi-protocol capabilities. Guoqiang et al. [13] propose a smart IoT gateway to address the growing need for ubiquitous connectivity across heterogeneous networks such as Zigbee [21], Wi-Fi, and Ethernet. Their design introduces a pluggable architecture that allows modular integration of different communication protocols, ensuring scalability and adaptability for diverse IoT applications, including environmental monitoring, industrial automation, and smart homes. The gateway features a unified external interface that facilitates flexible software development while incorporating protocol translation mechanisms to standardize sensor data formats for seamless interoperability. Compared to similar designs, the proposed gateway offers enhanced scalability, cost efficiency, and improved multi-hop network support, making it a highly adaptable and resource-efficient solution for IoT ecosystems.

Table 1. Summary of representative IoT gateway implementations, highlighting platform focus, principal contributions, and the specific challenges addressed to enable interoperability, edge processing, and scalable device management.

Study	Platform / Focus	Key Contributions	Challenges Addressed
Zachariah et al. [19]	BLE-based modular gateway	Separation of network, processing, and UI; proposes scalable, application-agnostic architecture	Scalability, modularity
Macias et al. [20]	Multi-protocol gateway	Integrates non-IP devices; supports remote config and MQTT for low-power use cases	Protocol interoperability, energy efficiency
Guoqiang et al. [13]	Zigbee/Wi-Fi pluggable design	Modular architecture, unified interface, protocol translation	Heterogeneous networks, extensibility
Jewani et al. [22]	Edge computing-based gateway	Incorporates AI, ML, and 5G to enable decentralized processing	Latency, edge intelligence, security
Gloria et al. [23]	Raspberry Pi-based control system	Demonstrates real-time control using multi-protocol support in smart pool use case	Flexibility, low-cost deployment, practical feasibility

Table 1. Summary of representative IoT gateway implementations, highlighting platform focus, principal contributions, and the specific challenges addressed to enable interoperability, edge processing, and scalable device management.

Study	Platform / Focus	Key Contributions	Challenges Addressed
Zachariah et al. [19]	BLE-based modular gateway	Separation of network, processing, and UI; proposes scalable, application-agnostic architecture	Scalability, modularity
Macias et al. [20]	Multi-protocol gateway	Integrates non-IP devices; supports remote config and MQTT for low-power use cases	Protocol interoperability, energy efficiency
Guoqiang et al. [13]	Zigbee/Wi-Fi pluggable design	Modular architecture, unified interface, protocol translation	Heterogeneous networks, extensibility
Jewani et al. [22]	Edge computing-based gateway	Incorporates AI, ML, and 5G to enable decentralized processing	Latency, edge intelligence, security
Gloria et al. [23]	Raspberry Pi-based control system	Demonstrates real-time control using multi-protocol support in smart pool use case	Flexibility, low-cost deployment, practical feasibility

Jewani et al. [22] examine the integration of edge computing into IoT architectures, emphasizing its transformative potential in addressing the limitations of traditional cloud-centric models. Their analysis identifies significant advantages, including reduced latency, improved scalability, and enhanced data security. Emerging technologies, such as 5G, artificial intelligence (AI), and machine learning (ML), are explored as enablers of edge-based IoT solutions. However, the study acknowledges key challenges, including edge virtualization, interoperability, and security, which necessitate further research to unlock the full potential of edge computing in IoT gateways. Gloria et al. [23] present a practical IoT gateway for real-time monitoring and remote control in a swimming pool setting. Their Raspberry Pi-based design brokers bidirectional exchange between users and an Arduino sensor network, supports multiple communication protocols, and employs MQTT to reduce command latency and messaging overhead. They argue for low-cost, flexible, and scalable gateways while acknowledging the need for additional testing and optimization to ensure portability across scenarios. Building on these ideas, our work shows that comparable functionality can be delivered on a microcontroller-class platform (ESP32/Shelly), which lowers power consumption and setup complexity by eliminating a full OS, yet preserves multi-protocol interoperability, web-based interaction, and reliable control.

While these architectural innovations address protocol and processing challenges, the choice of hardware platform significantly impacts their real-world implementation. The following analysis compares two dominant approaches, namely, versatile single-board computers versus specialized microcontroller-based solutions.

2.2. Analysis of Raspberry Pi vs. Shelly Devices

The choice of hardware for IoT gateways plays a significant role in determining their scalability, efficiency, and accessibility. Raspberry Pi and Shelly devices represent two contrasting approaches to IoT gateway design, each with distinct advantages tailored to specific applications and user needs.

Raspberry Pi has gained popularity as a versatile IoT gateway due to its computational capacity, ability to run various operating systems, and extensive support for different programming environments. Morabito et al. [14] propose a lightweight edge gateway (LEGIoT) designed for IoT applications, focusing on efficiency, modularity, and scalability. Their study highlights the capability of Raspberry Pi-based gateways in handling advanced IoT tasks such as ML, data processing, and edge analytics, demonstrating their potential in lightweight edge computing architectures. The research emphasizes the use of container-based virtualization technologies (e.g., Docker [24]) to enhance flexibility and resource management, making the system hardware-agnostic and adaptable for various IoT use cases. However, their evaluation also underscores the increased computational demand and energy consumption of Raspberry Pi devices when executing resource-intensive tasks, necessitating a careful balance between performance and power efficiency. Despite these challenges, the study affirms the suitability of Raspberry Pi as an edge gateway, particularly when optimized for lightweight workloads. Raspberry Pi’s setup complexity can pose challenges for non-technical users. Aloul et al. [25], emphasize that managing edge devices in smart home environments often requires technical expertise, making it less accessible to general users. They advocate for user-friendly configurations and plug-and-play solutions to simplify deployment in home and small-business environments, addressing this critical barrier to adoption.

Shelly devices, in contrast, are built around the ESP32 microcontroller and prioritize simplicity, low power consumption, and ease of integration. The ESP32 offers features such as dual-core processing, integrated Wi-Fi and Bluetooth, and support for lightweight communication protocols like MQTT. Shelly devices capitalize on these features to deliver a plug-and-play experience, eliminating the need for extensive technical knowledge during setup. Kang et al. [26] highlight the importance of simplicity and user-friendliness in IoT gateway designs, particularly in large-scale deployments where reliability and scalability are crucial. Shelly devices align with these principles by offering self-configuration capabilities, ensuring reliable operation while reducing the burden on users. Their design makes them particularly well-suited for consumer-centric IoT applications, such as home automation and small-scale deployments. While Raspberry Pi excels in computational flexibility and supports resource-intensive applications, its complexity and energy consumption may limit its suitability for non-technical users and energy-sensitive deployments. On the other hand, Shelly devices trade computational power for simplicity and efficiency, making them ideal for scenarios where ease of use, low power consumption, and scalability are prioritized. It should be noted that other platforms, including STM32, Arduino MKR series, and Raspberry Pi’s RP2040/RP2350 microcontrollers, could also serve as candidates for embedded gateways [17,27,28,29]. However, we evaluate an ESP32-based solution because it was already integrated at the deployment site and provided the best balance of simplicity, cost, and energy efficiency for an always-on gateway.

Table 2. Comparison of Raspberry Pi and Shelly (ESP32) gateway platforms across key criteria: compute capability, power profile, setup complexity, extensibility, protocol support, target users, and typical use cases.

Feature	Raspberry Pi	Shelly Devices (ESP32)
Processing Power	High-performance multicore CPU; supports complex computation and ML workloads [14]	Dual-core ESP32; suitable for lightweight tasks and control logic [26]
Power Consumption	Relatively high; not ideal for battery-powered or energy-constrained environments	Very low; optimized for embedded and continuous operation
Setup Complexity	Requires OS installation, terminal config, network setup [25]	Plug-and-play; built-in firmware and web UI
Extensibility	Highly modular; supports multiple OS, containers (e.g., Docker) [24]	Limited extensibility; tailored for specific use cases
Network & Protocol Support	Full TCP/IP, MQTT, WebSockets, Bluetooth (optional)	Native support: Wi-Fi, MQTT, REST, Bluetooth
Target User Base	Developers, researchers, power users	Consumers, integrators, non-technical users
Ideal Use Case	Edge analytics, heavy control systems, prototyping	Home automation, lightweight sensing/control, fast deployment

summarizes the key hardware trade-offs between Raspberry Pi and Shelly devices. These hardware comparisons underscore the growing importance of microcontroller optimization in gateway design. The subsequent analysis of the ESP32’s technical specifications provides the foundation for understanding how modern embedded systems achieve cloud-grade functionality with edge-appropriate resource constraints.

2.3. Analysis of ESP32 Capabilities

According to Espressif’s technical documentation, the ESP32 integrates dual-core processing, 2.4 GHz Wi-Fi and Bluetooth radios, ample GPIO, and common on-chip peripherals (UART, SPI, I²C, ADC), together with multiple low-power sleep modes and OTA support [15]. As summarized in practitioner guides, these features enable a single microcontroller to handle local sensing/actuation, run lightweight web services, and sustain MQTT-based messaging without an external operating system [30]. In this work, we exploit exactly this mix—compute, radios, and peripherals—to host the SPA dashboard, execute device-facing HTTP actions, and perform edge logic with a small energy and memory footprint suitable for always-on smart-home gateways.

Another key advantage of the ESP32 is its low power consumption, which is critical for energy-sensitive and battery-powered IoT deployments. Its power management capabilities, including multiple sleep modes, allow it to operate efficiently for extended periods, making it well-suited for applications requiring continuous monitoring and control [15]. This energy efficiency, combined with its computational power, ensures its utility across various domains, including environmental monitoring and remote sensing. Flexibility is a defining characteristic of the ESP32, particularly in its ability to support a range of modern IoT protocols and applications. It can host a web server to deliver SPA, providing users with direct and intuitive interfaces for interacting with IoT devices [31]. Furthermore, its compatibility with lightweight communication protocols like MQTT and WebSockets ensures reliable and efficient data exchange, even in resource-constrained environments. The ESP32’s support for OTA updates enhances its utility by allowing firmware upgrades and maintenance to be performed remotely, ensuring seamless operation in scalable and distributed IoT deployments.

The ESP32’s unique combination of technical capabilities and flexibility makes it an ideal choice for embedded IoT gateways. Devices such as Shelly leverage the ESP32 to offer user-friendly, plug-and-play experiences while maintaining compatibility with diverse IoT ecosystems [32]. Its ability to combine localized processing, energy efficiency, and advanced features underscores its pivotal role in creating scalable and accessible IoT solutions.

The analysis of gateway implementations highlights that general-purpose platforms such as Raspberry Pi offer strong computational power and flexibility, but at the expense of higher complexity and energy consumption. Shelly devices, leveraging the ESP32 microcontroller, provide a lightweight, low-cost, and user-friendly alternative suitable for always-on embedded environments. Compared to earlier platforms such as ESP8266, which remains popular in many edge devices due to its simplicity and low cost, the ESP32 offers dual-core processing, integrated Bluetooth, lower idle power consumption, and broader protocol support. These features make the ESP32 particularly suitable for scalable gateway deployments that require a balance of performance, efficiency, and interoperability. This trade-off analysis informed our decision to design and evaluate an ESP32-based embedded gateway as the focus of this study.

3. Proposed Architecture

The proposed embedded IoT gateway is built around the ESP32-based Shelly 3EM device, integrating edge computing, local storage, and secure communication protocols to enable reliable and scalable control of smart environments. Designed to operate autonomously, the gateway minimizes reliance on cloud infrastructure while maintaining seamless interoperability with a wide range of IoT devices and user interfaces. As illustrated in Figure 1, the architecture is divided into four functional domains: IoT devices, user interfaces, the embedded gateway, and cloud services. At its core, the ESP32 microcontroller executes both local and remote logic, interacting with connected devices through lightweight protocols such as MQTT and HTTP/REST.

The gateway interfaces with IoT devices such as smart thermostats, smart meters, and lights using REST APIs over the local network. Customized HTTP requests enable direct control and monitoring, allowing seamless interaction with devices from different vendors. This vendor-agnostic approach eliminates interoperability barriers and supports flexible deployment in heterogeneous environments.

User interaction is achieved through a web-based SPA hosted on the embedded web server, accessible via local HTTP connections. Additionally, mobile applications can communicate with the same REST endpoints. This architecture prioritizes local-first interaction, enhancing privacy, security, and responsiveness by avoiding dependency on cloud-based dashboards. On-device edge computing logic empowers the gateway to execute control decisions locally. This includes rule-based automation and potential support for lightweight ML tasks using frameworks like TinyML [33]. By enabling real-time processing at the edge, the system reduces latency and ensures resilience in the event of internet disruptions or cloud service outages.

Sensitive operational data is stored locally, while only selected and anonymized telemetry is sent to the cloud to comply with GDPR requirements. The gateway includes a built-in key-value database for storing measurements, device states, and configurations. All critical data is stored locally, ensuring that sensitive information remains under user control. This local persistence also reduces bandwidth consumption and dependence on external infrastructure. For use cases requiring remote control or telemetry, the system supports MQTT-based cloud integration. The gateway acts as an MQTT client, publishing data to cloud brokers and subscribing to control topics. This asynchronous messaging layer ensures efficient communication with external platforms, and optionally forwards selected data to long-term cloud storage. The gateway uses MQTT over TLS (v5, TLS 1.2/1.3) for all remote interactions [34], providing end-to-end encryption and authentication during telemetry and control transactions.

The proposed architecture strikes a balance between local autonomy and cloud extensibility. It is designed to be modular, vendor-neutral, and privacy-conscious, making it well-suited for both smart home and industrial IoT applications. The combination of embedded intelligence, lightweight protocols, and secure local storage provides a robust platform for scalable and resilient deployments.

4. Case Study

The proposed embedded gateway was deployed in a real-world setting, an educational building (a kindergarten in Poland), as part of the European BuildOn project [35]. The facility serves 128 children and 22 staff members. During recent renovations, smart radiator valves were introduced. However, the building lacked an integrated control system, creating the need for a reliable and cost-effective automation framework capable of managing daily operations.

Shelly-based embedded gateways were chosen over alternatives such as Raspberry Pi, mini PCs, or commercial gateways, primarily due to their low cost, vendor-agnostic compatibility, and ease of integration with existing infrastructure. Given that an electricity monitoring setup was already installed, adopting Shelly devices offered a significant economic advantage. Additionally, Shelly gateways support the mJS scripting language [36], a lightweight JavaScript subset from the Mongoose OS framework [37], which allows edge-side customization of data acquisition and processing workflows. By enabling scripts to run directly on the gateway, mJS improves system efficiency and security, while offering the flexibility to define more advanced logic at the edge. One of the core functional requirements for the gateway was local device control using REST APIs. The embedded scripting language supports outbound HTTP requests, enabling bidirectional communication with other devices and services on the same network. Three primary use cases were identified—retrieving measurements, sending control commands, and enabling device-to-device communication. However, initial deployment revealed a major obstacle, namely, addressing dynamic device IPs.

IoT environments typically rely on DHCP, which dynamically assigns IP addresses to devices. Hardcoding static IPs is impractical for end users and introduces complexity. To resolve this, the system leverages the mDNS (multicast DNS) protocol [38], which is natively supported by Shelly devices. This protocol allows devices to be referenced via ‘.local’ hostnames without requiring a centralized DNS server. For improved scalability, device hostnames are stored in Shelly’s internal KVS, which can manage up to 50 key–value pairs. These hostnames are then dynamically retrieved by scripts to ensure seamless connectivity, even when IPs change.

Beyond TRV control, the deployment environment included additional sensing modalities (e.g., electrical telemetry via Shelly devices and BLE temperature/humidity sensors). In a separate implementation, the gateway has successfully ingested BLE environmental data (e.g., Netatmo T/H) alongside local REST traffic, confirming functional compatibility with heterogeneous sources. To maintain a controlled evaluation and isolate the effect of service discovery on control reliability, Section 5 reports quantitative results for TRV control only. Broader multi-sensor loads are reserved for follow-up experiments.

Additionally, although the gateway emphasizes local processing, some data and control functions must still be accessible remotely. To enable external connectivity, two approaches were evaluated—port forwarding and MQTT communication. The former introduces significant security risks and setup complexity, making it unsuitable for non-technical users. Instead, MQTT was selected as the primary method for remote interaction, given its reliability, lightweight footprint, and native support in Shelly gateways.

The gateway uses MQTT to both publish and subscribe to specific topics, enabling a full request–response cycle between cloud services and local devices.

Table 3. MQTT QoS levels with reliability guarantees and overhead trade-offs for telemetry and control workloads.

QoS Level	Description
0	Message is delivered at most once, without requiring acknowledgment. This is the fastest but least reliable mode.
1	Message is delivered at least once. Acknowledgment is required to ensure delivery, but duplicates may occur.
2	Message is delivered exactly once using a four-step handshake mechanism. This is the most reliable but has higher overhead.

outlines the supported QoS levels [39], which help tailor reliability to use case needs. For instance, real-time energy data can use QoS 0, while control messages rely on QoS 1 or 2 to ensure delivery. MQTT v5 enhancements [40] enable acknowledgment handling, allowing users to issue commands through a REST API, which are then routed via a cloud MQTT broker. The gateway listens to control topics, executes the instruction, and returns a confirmation via a dedicated MQTT response topic, ensuring robust end-to-end communication.

Figure 2 and Figure 3 depict the end-to-end command/response sequences for cloud-mediated and local control, respectively, highlighting the roles of the gateway (GW), MQTT, and device-facing HTTP calls. Concretely, in the cloud-mediated flow, a user action triggers a command that the cloud publishes to an MQTT request topic to which the gateway (GW) subscribes. Upon receipt, the GW resolves the target device on the LAN using its KVS (with mDNS .local lookup as fallback) and issues a device-facing HTTP request. The device’s HTTP response determines the acknowledgment published by the GW on a corresponding MQTT response topic so the cloud UI can correlate outcomes and update its state. QoS levels are chosen per use case (e.g., QoS 1 for control) to balance reliability and overhead, while the cloud–GW hop remains decoupled from the local HTTP data plane. In the local control flow, the user interacts with the GW-hosted SPA, which calls the GW’s REST endpoint. The GW then performs the same device lookup and HTTP action locally, returning status to the SPA for immediate UI updates. This local path avoids WAN round-trips, reduces latency, and continues to operate during Internet outages, whereas the cloud path provides a reliable remote control plane, centralized auditing, and uniform acknowledgment semantics. Both paths share the same device-facing mechanism, ensuring consistent behavior regardless of whether commands originate from the cloud or from the on-site web interface.

The gateway logic is implemented in Shelly Script (mJS), an embedded JavaScript runtime provided by the Shelly firmware. Scripts are uploaded via the device web UI/RPC and run as long-lived tasks with timer-driven handlers for polling, retries, and housekeeping. Core built-ins used include the HTTP client/server, MQTT client, timers, and storage (key–value store). The dashboard is a lightweight SPA in HTML/CSS/JavaScript using Bootstrap, and assets are served by the embedded HTTP server as static files. To reduce load time and flash wear, assets are minified offline and cached by the browser with conservative cache headers. No custom firmware (and thus no compiler flags) was needed, as all functionality relies on vendor firmware, on-device scripts, and static assets.

On the LAN, the SPA calls gateway REST endpoints for telemetry and control, and the gateway resolves targets via stored hostnames in the KVS (with mDNS .local fallback) and issues device-facing HTTP requests. When the user is remote, identical UI actions are relayed via MQTT v5: the cloud publishes to a request topic subscribed by the gateway, which executes the device action locally and then publishes an acknowledgment on a response topic to close the loop. Acknowledgments carry a command identifier and status to enable idempotency and precise UI updates. Transport choices follow the “local HTTP, remote MQTT” split—device endpoints stay confined to the LAN for privacy and latency, while cloud interactions are TLS-protected and auditable.

From a security perspective, the gateway ensures that all remote communications are performed using MQTT over TLS (v5, TLS 1.2/1.3) [34], providing encryption and authentication during cloud interactions. Locally, all sensitive operational data and configurations remain stored in the gateway’s internal database, and only anonymized telemetry is forwarded to the cloud to maintain GDPR compliance. For devices like TRVs, which currently lack native TLS support, the system operates within an isolated local network behind a firewall, reducing exposure and mitigating external attack risks. This layered approach balances security and functionality in the current deployment while enabling future upgrades to end-to-end encryption as device firmware evolves.

A key feature of any IoT gateway is a web-based dashboard to provide users with access to live data, system status, and device control. Shelly devices powered by the ESP32 can host a simple HTTP server [41], which serves as an interface for viewing device metrics and sending control commands. The inclusion of geolocation-based logic enables the system to differentiate between local and remote users, optimizing command routing by avoiding the cloud when users are on-site. A dedicated endpoint can return HTML-based web pages, facilitating direct interaction with home automation systems. Figure 4 shows a sample web interface developed to monitor Shelly TRVs [42] in the kindergarten deployment. The dashboard utilizes the Bootstrap library [43] for responsive UI elements and includes real-time visualization of device data. JavaScript-based controls issue HTTP requests directly to the gateway for immediate action, like adjusting radiator settings, allowing seamless interaction for both technical and non-technical users.

This case study validates the practical feasibility of deploying an ESP32-based embedded gateway in a real-world smart building. It demonstrates how local automation, edge processing, secure storage, and cloud integration can be harmonized in a compact, cost-efficient solution tailored to dynamic environments.

5. Results

Each run followed the same design flow as in the sequence diagrams: (i) simultaneously issue a control command to the TRVs under test; (ii) allow a 60 s stabilization window before the next run; and (iii) record RAM usage at 1 s intervals and control success as an acknowledged action within 60 s. MQTT configuration was fixed across runs (telemetry at QoS 0, control at QoS 1), as were Wi-Fi settings and gateway scripts. The dashboard was loaded once before measurements to avoid repeated asset fetches. Only the number of target devices and the number of gateways were varied, as reported in

Table 4. Control success across gateway configurations, expressed as the number of TRVs that acknowledged the command within 30 s per run; the bottom row reports average success as a percentage of attempted devices.

Run	5 TRVs (Baseline, 1 GW)	10 TRVs (Low Load, 1 GW)	20 TRVs (Mid Load, 1 GW)	32 TRVs (Full Load, 1 GW)	32 TRVs (Full Load, 3 GWs)
1	5	10	20	24	28
2	5	10	20	29	31
3	5	10	16	23	29
4	5	10	19	28	28
5	5	10	17	28	29
6	5	10	18	28	26
7	5	10	19	31	31
8	5	10	20	26	31
9	5	10	20	29	32
10	5	10	18	31	32
Average Control (%)	100	100	93.5	86.56	92.81

.

Figure 5 illustrates the RAM usage of the gateway device under three different scenarios. In the first scenario, a single script is deployed to transmit the device’s energy consumption, resulting in stable memory usage at approximately 122 KB. In the second scenario, an additional script subscribes to an MQTT broker to receive remote control commands, which increases average RAM usage by around 2 KB. In the final scenario, the SPA is hosted and served, causing a brief spike in memory usage as the full application code is processed. Once the SPA is fully loaded, usage stabilizes around 125 KB.

The ESP32-D0WDQ6 microcontroller used in the gateway includes 520 KB of RAM, of which approximately 248 KB is available for application use after accounting for system overhead. Baseline processes consume around 113 KB (45.6%), leaving a usable margin for custom implementations. Measured RAM utilization ranged from 49.2% in the first test to 52.4% during the SPA load, settling back to 50.8%. This corresponds to an active memory range between 8.92 KB and 16.9 KB, or 3.6–6.8% of available application memory. These results validate the gateway’s suitability for embedded environments with limited system resources. In contrast, general-purpose solutions like Raspberry Pi require significantly more memory and present higher complexity.

To evaluate system scalability and real-world performance, we conducted additional tests focusing on device control reliability under various gateway configurations. The setup involved managing up to 32 TRVs using one or more embedded gateways. As shown in Table 4, two configurations were tested—a single-gateway setup and a distributed setup with three gateways. In the single-gateway configuration, we attempted to control 5, 10, 20, and 32 TRVs using the mDNS protocol for device discovery. During each test, control commands were issued simultaneously to all TRVs under test, and the system was allowed to stabilize for one minute before the next iteration. This ensured a consistent communication pattern and avoided overlapping command executions across test runs.

The gateway achieved 100% control success for both 5 and 10 devices. However, as the number of devices increased, the control success rate dropped, averaging 93.5% for 20 devices and 86.56% for 32 devices. During these measurements, auxiliary sensor polling was minimized so that results reflect the behavior of the TRV control path rather than mixed workloads. This decline is primarily attributed to mDNS resolution challenges caused by the mesh network topology of the building. Devices connected to different mesh nodes experienced inconsistent hostname resolution, limiting gateway access. The observed dropouts stem from name resolution rather than from the HTTP actuation itself. The deployment relies on mDNS/DNS-SD to resolve .local hostnames, and in a Wi-Fi mesh, mDNS uses link-local IP multicast, which can suffer from packet loss, rate limiting, and cache divergence across mesh nodes [38,44]. Under concurrent, bursty lookups, this leads to intermittent failures to resolve a subset of devices within the 60 s window, preventing the gateway from reaching them. Once a hostname resolves, subsequent device-facing HTTP requests (GET/POST) complete reliably. Practical mitigations include DHCP reservations or static addressing, short-TTL caching of resolved addresses in the gateway’s KVS with staggered refresh, and (where available) use of the router’s unicast DNS entries to avoid multicast discovery on dense meshes.

To address this issue, we introduced a distributed configuration using three gateways, each assigned to a specific mesh node to manage only locally connected TRVs. This strategy significantly improved mDNS reliability and device control rates. The three-gateway configuration achieved an average control success rate of 92.81% for 32 devices, translating to approximately two additional devices controlled compared to the single-gateway setup. This represents a 6.25% improvement in reliability under the same workload.

6. Discussion

This section reflects on practical aspects of implementing an Internet-connected smart-home gateway on an ESP32-based Shelly device, focusing on design flow, toolchain choices, reliability, security, and generalizability. The combination of on-device scripting (mJS) and a static SPA maximizes simplicity; logic is deployed as scripts and static assets, avoiding custom firmware builds and external runtime dependencies. This accelerates iteration in field settings and lowers the barrier for operators without embedded expertise. Heavy analytics are intentionally excluded from the device and can be offloaded to the cloud or scheduled as batch jobs. Over-the-air (OTA) updates and centralized logging/metrics collection (e.g., periodic status topics) support ongoing maintainability and observability without physical access.A controlled MCU-to-MCU comparison (e.g., ESP32 versus RP2350) is left for future work to complement this deployment-driven evaluation.

A deliberate separation of control planes is used: MQTT (over TLS) for cloud–gateway messaging and local HTTP for gateway–device actions. This preserves low latency and privacy on the LAN while enabling remote operation and auditing. Idempotent commands, stable topic naming, and per-device serialization at the gateway prevent race conditions and double execution during concurrent actuation. Bottlenecks observed at larger device counts stem from service discovery (mDNS) under mesh topologies. Mitigations, distributed gateways per mesh node, and hostname caching in the KVS improved success rates without increasing device complexity. Additional gains are feasible via static addressing or a lightweight local directory service when environments allow it.

Cloud–gateway traffic is encrypted and authenticated via MQTT over TLS, and device-facing HTTP remains local and protected by network isolation. Sensitive operational data and credentials are stored on the gateway, with only selected and anonymized telemetry forwarded upstream. Where end devices lack TLS, the layered network boundary and least-privilege endpoints reduce exposure while awaiting vendor support for stronger link security.

Because the approach relies on vendor firmware with an embedded scripting engine, deep kernel customizations, and certain RTOS-level features are out of scope. Nonetheless, the design principles—local-first operation, scriptable gateway logic, clear separation of control planes, and minimal operator burden—transfer to other microcontroller gateways. Future deployments can incorporate additional low-power radios (e.g., BLE, Zigbee, Thread) and stronger local authentication while preserving the same design flow. A planned extension is a controlled multi-sensor and sampling-rate study on the same gateway. The experiment matrix will vary (i) device mix—TRVs over local HTTP, electrical telemetry over local REST/MQTT, and BLE/GATT environmental sensors (e.g., Netatmo temperature/humidity); (ii) sampling rates—from 1–5 s (high frequency) to 30–60 s (typical dashboards) and 5–10 min (energy reporting); and (iii) fan-out (device count). Metrics will include control success and latency, name-resolution success, MQTT delivery rate, RAM/heap occupancy, and gateway CPU load; where feasible, we will also log Wi-Fi airtime and multicast volume. The gateway will apply request pacing, per-device queues, and batching to bound burstiness, and will optionally aggregate sensor reads locally before cloud publication to reduce upstream load.

In summary, this architecture balances cost, energy efficiency, and usability while delivering the reliability and security properties required for Internet-connected smart-home components.

7. Conclusions

This study proposed and implemented an embedded IoT gateway based on Shelly devices powered by the ESP32 microcontroller. The gateway was designed as a cost-effective, vendor-agnostic, and user-friendly solution for monitoring and controlling IoT environments. By leveraging edge computing, the system enabled localized intelligence, secure data handling, and robust communication through lightweight protocols such as MQTT and REST APIs. Its real-world deployment in an educational building demonstrated practical advantages, including reduced dependence on cloud infrastructure, enhanced GDPR compliance, and reliable local control.

The evaluation confirmed the gateway’s efficient use of system resources. RAM consumption ranged between 3.6% and 6.8% of available memory (approximately 8.92 KB to 16.9 KB), even when executing scripts, managing MQTT subscriptions, and hosting a SPA. Although SPA loading triggered a brief RAM spike to 52.4%, memory usage stabilized at 50.8%, reaffirming the suitability of ESP32-based devices for lightweight edge computing. Scalability was further assessed through experiments involving the control of up to 32 TRVs in different gateway configurations. In a single-gateway setup, success rates decreased as device count increased, dropping from 100% for 10 TRVs to 86.56% for 32 TRVs, mainly due to mDNS resolution issues across mesh nodes. To address this, a distributed configuration using three gateways (one per mesh node) was tested, which improved control reliability to 92.81%. This 6.25% gain (translating to two additional devices successfully controlled) demonstrates the practical scalability of the system and the benefit of localized control in segmented networks.

Despite these successes, challenges were identified. Inconsistent mDNS behavior necessitated fallback mechanisms using static IPs stored in the device’s internal KVS. High volumes of write operations raised concerns about flash memory endurance, pointing to the need for more efficient data handling strategies. Future work will focus on strengthening device discovery through more robust service resolution (e.g., unicast DNS-SD, short-TTL caching, or a lightweight local directory) and on optimizing flash usage via buffered writes and compression. Adopting emerging interoperability standards such as Matter can further simplify multi-vendor integration, while incorporating lightweight ML (e.g., TinyML) enables adaptive edge automation. Furthermore, we will evaluate heterogeneous sensor mixes (HTTP/MQTT/BLE) and sampling-frequency sweeps to characterize scaling limits and resource trade-offs under realistic mixed workloads. We also plan to conduct broader scalability evaluations in smart-building, smart-city, and industrial settings to validate performance under heterogeneous topologies. Security enhancements—including stronger device authentication, intrusion detection, and role-based access control—are likewise essential for long-term operation. In addition, we will benchmark alternative microcontroller families (e.g., Raspberry Pi RP2040/RP2350 and STM32) and RTOS-based platforms (e.g., FreeRTOS, Zephyr) under identical workloads to quantify scalability, latency, energy, and security trade-offs, thereby extending the generalizability of the architecture. We will also extend radio support to low-power protocols such as BLE, Zigbee, and Thread to accommodate battery-operated devices and larger fleets. Finally, although the Shelly 3EM platform is known for a sub-1 W active power profile, we did not capture end-to-end gateway power in this deployment; future work will include a detailed power characterization across idle, burst control, SPA hosting, and sustained MQTT throughput conditions.

In summary, this work demonstrates that advanced IoT gateway functionality, including real-time monitoring, distributed control, edge intelligence, and web-based interaction, can be delivered through resource-efficient, ESP32-powered devices. The proposed system presents a compelling solution for scalable, secure, and locally autonomous IoT deployments across a wide range of smart environments.