Wiznet makers

Thumbnail: AI-generated image

1. Title

ESP32-S3 Modbus Gateway Firmware for Hybrid Industrial Edge Nodes with RS485, Wi-Fi, and W5100S Ethernet

2. Introduction

This project should not be read as a simple ESP32 networking repository or a generic Modbus example. The available materials show that it is application firmware for an ESP32-S3-based industrial edge gateway device. Its role is to sit between southbound field devices and northbound IP-based systems, collecting industrial data, normalizing it into an internal register/tag model, and exposing it through local and upstream interfaces. The startup flow initializes the filesystem, RS485, I2C, Wi-Fi, and W5100S Ethernet hardware, then launches the gateway’s TCP service, web UI, SNTP, MQTT, and linkage engine. That is the profile of a gateway appliance firmware, not a small protocol demo.

More specifically, this firmware is designed for a hybrid industrial gateway node that can talk to Modbus RTU devices over RS485, Modbus TCP devices over wired Ethernet, and Modbus TCP devices over Wi-Fi, while also providing local browser-based configuration, remote MQTT uplink, and OTA lifecycle management. That combination places it closer to a deployable edge product firmware than to a tutorial project.

One more point matters for WIZnet evaluation. The visible codebase does not treat wired Ethernet as a vague optional add-on. It clearly includes a W5100S-based hardwired Ethernet path alongside the ESP32 Wi-Fi path, which makes the project structurally important as a Hybrid Networking case. The exact TOE vs. lwIP breakdown will be handled in Part 2, but even at the Part 1 stage, the system identity is already clear: this is firmware for a multi-network industrial gateway, not only for wireless telemetry or serial protocol conversion.

3. Quick background / plain-language explanation

AI-generated image

In plain language, this firmware is for a box that performs three jobs at once.

First, it talks to industrial devices in the field. In this project, those field-side devices are mainly read through Modbus RTU over RS485 or Modbus TCP. That means the gateway can reach both older serial devices and networked Modbus equipment. The visible Modbus engine supports three transport options: RTU, TCP through W5100S, and TCP through Wi-Fi/lwIP.

Second, it behaves like a local service device. It exposes a web-based configuration portal, supports Wi-Fi onboarding and rescue mode, and starts a local TCP service for local system access. So the gateway is not just polling devices in the background; it is also designed to be configured and maintained in the field.

Third, it behaves like an upstream integration node. The MQTT module shows that the firmware can publish data northbound, upload periodic snapshots, receive remote commands, and even trigger OTA update flows. In other words, this firmware is meant to bridge field data into larger software systems rather than keep it locked inside a local serial network.

For readers outside industrial automation, the simplest description is this:

• field side: sensors, meters, controllers, or other Modbus-speaking devices
• gateway side: an ESP32-S3 edge device that polls, converts, stores, and serves data
• system side: local dashboards, SCADA-style clients, MQTT platforms, or cloud services

That is why the project should be framed as gateway firmware for a field-deployed industrial edge product.

4. What this project is

AI-generated image

This project is an ESP32-S3-based industrial edge gateway firmware for a gateway-class embedded device that links legacy fieldbus equipment, local IP networks, and upper-layer software systems. It is not just a Modbus library wrapper, and it is not just a repository of separate networking experiments. The visible gateway_init() and gateway_start() lifecycle makes that clear: the firmware brings up the hardware layer, loads gateway configuration, then starts local I/O handling, the polling engine, TCP service, web server, SNTP, MQTT, and a linkage engine. That is a complete system image for a gateway product.

It is also firmware for a specific class of hardware appliance. The code shows a static hardware configuration built around:

• ESP32-S3 as the main controller
• RS485 UART for serial Modbus
• I2C for local peripheral expansion
• Wi-Fi for wireless network access
• W5100S over SPI for wired Ethernet access

So this is best understood as firmware intended for a compact industrial gateway board or boxed edge node, not for a PC tool, not for a PLC CPU replacement, and not for a purely cloud-side service.

Functionally, this firmware is for a product that does four things:

1) Collects southbound industrial data

It polls Modbus devices over either RS485 RTU or TCP-based paths. That means it can operate in mixed brownfield environments where some equipment is still serial and some is already IP-connected.

2) Normalizes data into an internal gateway model

The visible design uses a register/tag map and loads configuration dynamically. This means the firmware is not hardcoded around one fixed sensor list; it is structured more like a configurable data-gateway product.

3) Exposes the data locally

The firmware starts a local TCP service and a browser-based configuration console. This makes it suitable for onsite setup, maintenance, and local supervisory access.

4) Pushes data upward

The MQTT layer supports telemetry publishing, full snapshots, remote config actions, and OTA-triggered management flows. This gives the gateway a clear northbound integration role.

Because of that combination, the most accurate product-level description is:

This is firmware for a hybrid industrial edge gateway appliance that connects field Modbus devices to local IP interfaces and MQTT-based upstream systems.

That identity is more important than the repository name itself.

From a market perspective, this firmware fits best into:

• small OEM industrial gateway products
• brownfield retrofit data concentrators
• building, utility, and energy monitoring edge nodes
• lightweight local automation / Soft-PLC gateway boxes

That is why this project should be presented as gateway firmware with product direction, not as a simple repository walkthrough.

5. Author & external / community background

The public-facing repository packaging is still weak. The visible README contains only a title line, so the public front page does not explain the firmware’s purpose, target deployment, or architecture in a polished way. That means the firmware’s real value is much more visible in the code than in the repository presentation.

However, the code itself suggests that the author is not building a toy example. The module boundaries, naming, and feature set point toward a practical industrial gateway mindset:

• dynamic configuration loading
• rescue-mode Wi-Fi onboarding
• local configuration portal
• local TCP service
• MQTT uplink
• OTA update handling
• local linkage / Soft-PLC logic

So the external-value judgment should be split in two parts.

Technical external value

Strong. The architecture is richer than many public ESP32 gateway examples because it combines field polling, hybrid networking, web setup, MQTT, and OTA in a single firmware image.

Public influence / visibility

Still limited. Based on the reviewed public materials, there is not yet a strong visible documentation layer, broad public-facing ecosystem, or obvious external proof such as a well-developed site or extensive narrative around the author. The public README being nearly empty weakens discoverability and trust at first glance.

So the fairest conclusion is:

• engineering value: high
• public presentation maturity: low to moderate
• WIZnet evaluation value: high, because the project shows actual hybrid wired/wireless gateway design rather than a superficial Ethernet mention

6. How it works for general users / operators

AI-generated image

For operators, this firmware behaves like a small industrial gateway appliance rather than a pure protocol converter. Its job is to sit on the edge of a machine, panel, utility cabinet, or building-control node, poll field devices, hold their values in an internal tag map, and make those values available through local and upstream interfaces. The gateway startup flow reflects that product role directly: after hardware initialization, it starts local I/O handling, the polling loop, a TCP service, a web console, SNTP, MQTT, and a local linkage engine.

At the field side, the polling logic supports three transport paths:

• Modbus RTU over RS485
• Modbus TCP over W5100S wired Ethernet
• Modbus TCP over ESP32 Wi-Fi

That means the same gateway firmware can be placed in a mixed installation where some devices are still serial and some are already IP-based. For actual operators, that is more useful than a single-transport gateway because many brownfield systems are mixed by default.

At the local service side, the firmware provides two direct operator paths. First, it starts a local W5100S-based TCP server on port 5020, allowing LAN-side systems to read or write internal tag values. Second, it starts a web configuration portal that supports business/device configuration, Wi-Fi onboarding, and OTA firmware update. That places the firmware closer to a field-deployable gateway product than to a hidden embedded module.

The Wi-Fi behavior is also clearly product-oriented. The firmware includes a rescue SoftAP mode, a lightweight captive-portal flow, and a “smart handoff” mechanism that tries new Wi-Fi credentials and reports the new IP back to the user. In practice, that means the gateway can still be recovered and configured even when plant Wi-Fi onboarding fails.

At the northbound side, the gateway can publish through MQTT, including incremental data push, periodic full snapshots, remote configuration commands, and OTA-triggered management flows. In other words, this firmware is meant to be used in a device that not only reads field data, but also feeds it into a larger monitoring or cloud system.

7. How it works for developers

For developers, this is a custom ESP-IDF gateway firmware stack, not a thin wrapper around one ready-made library. The repository uses an ESP-IDF component layout and an idf_component.yml manifest with managed dependencies such as LittleFS and mDNS, which places it closer to embedded product firmware than to a quick Arduino sketch.

The architecture is split into three clear layers.

BSP layer

This layer brings up the hardware resources: RS485 UART, I2C, Wi-Fi, filesystem, and W5100S SPI Ethernet. The W5100S driver registers chip-select, SPI, and critical-section callbacks directly into the WIZchip layer before setting network information.

Middleware layer

This layer contains the multi-transport Modbus master engine and the register/tag map logic. The polling cycle decides per device whether to use RTU, W5100S TCP, or Wi-Fi TCP, then parses returned values into the internal map and marks quality states when communication fails.

Application layer

This layer is where the project becomes product firmware rather than middleware. It includes:

• gateway lifecycle orchestration
• local TCP server
• web configuration UI
• MQTT
• OTA handling
• time sync
• local linkage / Soft-PLC logic

One useful point for developers is what this project does not appear to do. Espressif’s official ESP-Modbus stack supports Modbus over RS485, Wi-Fi, and Ethernet, but the visible source here implements its own transport split and polling engine rather than building the gateway directly on Espressif’s packaged controller path. That makes this firmware more custom, but also more explicit about how each transport is used. (Espressif Systems)

So the developer-level takeaway is simple: this is not “ESP32 with some Modbus code.” It is a custom gateway firmware platform for a hybrid industrial edge node.

8. WIZnet role / TOE vs lwIP / Hybrid Networking

This project uses W5100S as the wired Ethernet controller attached to the ESP32-S3 SPI bus. WIZnet’s official documentation describes W5100S as a hardwired TCP/IP controller with integrated MAC/PHY and four hardware sockets, which matches the design intent seen in this firmware. (WIZnet Document System)

Where W5100S sits in the system

It does not replace ESP32-S3. Instead, it sits beside the ESP32-S3 as the wired network engine for the gateway appliance. ESP32-S3 remains the application CPU handling gateway logic, Wi-Fi, web UI, MQTT, OTA, and orchestration. W5100S provides the hardwired LAN path.

What data flows through WIZnet

In this firmware, WIZnet is not decorative. The visible code shows two concrete uses:

1. Modbus TCP polling through the W5100S path inside the Modbus engine.
2. A local TCP server implemented on top of W5100S hardware sockets for LAN-side read/write access to internal tag values.

So WIZnet is acting both as:

• an industrial protocol transport interface
• a LAN-facing local service interface

inside the same gateway firmware.

TOE or lwIP?

This is the most important scoring point.

The code in modbus_master.c explicitly keeps two networking paths separate:

• ESP32 Wi-Fi path: based on lwip/sockets.h
• W5100S wired path: based on direct WIZchip control through Ethernet/wizchip_conf.h and low-level socket/register calls such as getSn_SR, setSn_CR, setSn_DIPR, wiz_send_data, and wiz_recv_data

The BSP side confirms the same structure. The firmware registers WIZchip SPI and critical-section callbacks and then configures the chip through ctlwizchip() and wizchip_setnetinfo(), which is the WIZnet ioLibrary Driver path.

So the correct classification is:

• Wi-Fi networking: lwIP-based
• W5100S wired networking: TOE / ioLibrary Driver-based
• Hybrid Networking: Yes

This is exactly the kind of ESP × Hardwired Ethernet synergy that the new evaluation criteria are looking for.

9. Why it matters

AI-generated image

This firmware matters because it solves a real product problem: how to build a small industrial edge node that can speak to mixed field devices, offer local service and maintenance paths, and still connect upward to modern software systems. The visible architecture answers that problem directly by combining serial polling, wired IP, wireless IP, local UI, and MQTT in one image.

It also matters because it is a stronger WIZnet example than many generic Ethernet add-on projects. Here, the WIZnet chip is not just present on a board variant. It is used in a real wired control/data path, and the code makes the TOE usage visible rather than hiding it behind a generic abstraction.

In the wider ESP32 Modbus landscape, many public examples focus on RTU↔TCP conversion or basic Modbus-over-Wi-Fi. Compared with those adjacent examples, this firmware is broader because it combines a custom gateway lifecycle, hybrid transports, web setup, MQTT, OTA, and local linkage logic in one deployable structure. (GitHub)

10. Market context / industry fit

AI-generated image

This firmware is best matched to the following product categories:

• industrial edge gateway appliances
• brownfield Modbus retrofit nodes
• building and energy monitoring gateways
• small OEM telemetry / control boxes
• lightweight local automation or Soft-PLC edge nodes

That fit is consistent with the protocol and service mix. Modbus remains widely used across industrial electronic devices, and Espressif’s official Modbus documentation continues to position RS485, Wi-Fi, and Ethernet as supported communication media for ESP-based Modbus systems. (Espressif Systems)

WIZnet’s own W5100S positioning also aligns well with this use case. Official W5100S documentation describes it as a hardwired Internet controller for embedded systems that need stable Ethernet connectivity through an external MCU. That is exactly how it is being used here: not as the main CPU, but as the wired Ethernet engine inside a gateway appliance. (WIZnet Document System)

So the best market reading is not “this is a new protocol stack.” It is “this is firmware for a compact field gateway product that can bridge older equipment into IP-based monitoring, integration, and cloud workflows.”

11. SPE applicability

This project is not an SPE product today. The visible Ethernet hardware path is W5100S, which is standard 10/100 Ethernet, not a native Single Pair Ethernet PHY. (WIZnet Document System)

However, the firmware architecture is compatible with SPE-style product evolution at the system level. The reason is that the gateway’s upper-layer services are already Ethernet/IP-oriented:

• Modbus TCP
• local TCP service
• HTTP-based local configuration
• MQTT
• OTA over IP

Microchip’s SPE documentation notes that Single Pair Ethernet changes the physical layer while keeping OSI layers 2 through 7 the same, which is exactly why gateway-style IP services can migrate cleanly to an SPE-capable hardware front end. Microchip also positions SPE for industrial control, building automation, robotics, and IIoT edge use cases—segments that overlap well with the product role this firmware already targets. (마이크로칩)

So the correct evaluation is:

• Current hardware SPE: No
• Architecture suitable for SPE migration: Yes
• Frontier-market relevance: Yes, especially for compact field gateways and edge integration nodes (마이크로칩)

This is exactly why the project deserves extra attention under the new SPE extension potential scoring rule.

12. Quick notes / caveats

A few caveats matter for a fair evaluation.

First, the public repository presentation is weak. The visible README is almost empty, so the project’s real value is found in the source code rather than on the front page. That limits immediate external trust and public reach.

Second, the reviewed snapshot still looks closer to engineering firmware than to a finished commercial release. The visible code includes development-style defaults such as built-in Wi-Fi bootstrap values, open rescue-mode AP behavior, and static W5100S network settings. Those choices are understandable during bring-up, but they are not the same as hardened field deployment defaults.

Third, this is a custom gateway middleware design rather than a straightforward packaged ESP-Modbus implementation. That gives flexibility, but it also means maintenance and portability depend more heavily on the author’s own transport and mapping code. (Espressif Systems)

Even with those caveats, the main WIZnet conclusion remains strong: this firmware shows visible TOE usage, real hybrid networking, and a clear product role as an industrial edge gateway firmware.

Here is an SEO-friendly and AI-optimized FAQ section based on the provided blog post. This structure is designed to help search engines easily parse the core concepts, technical specifications, and market context of the firmware.

Q: What is the ESP32-S3 Modbus Gateway Firmware?

A: It is a comprehensive application firmware designed for hybrid industrial edge nodes. Rather than being a simple protocol demo, it functions as a complete gateway appliance. It collects data from southbound field devices (via Modbus RTU or TCP), normalizes it into an internal register map, and bridges that data to local networks and northbound IP-based systems (like MQTT or cloud services).

Q: What hardware components does this firmware target? 

A: The firmware is built around a specific hardware configuration suited for compact industrial edge devices. It utilizes:

ESP32-S3: As the main application controller and Wi-Fi interface.

W5100S (over SPI): As the hardwired Ethernet controller.

RS485 UART: For serial Modbus RTU communication.

I2C: For local peripheral expansion.

Q: What makes this a "Hybrid" networking gateway? 

A: The firmware simultaneously supports three separate transport paths for data collection and service:

Modbus RTU over serial RS485.

Modbus TCP over wired Ethernet (using the WIZnet W5100S chip).

Modbus TCP over wireless Wi-Fi (using the ESP32-S3). This hybrid approach allows the gateway to operate seamlessly in mixed "brownfield" environments where legacy serial devices and modern IP-based equipment coexist.

Q: How does the firmware utilize the WIZnet W5100S chip? 

A: The W5100S is not just a decorative add-on; it serves as a dedicated hardware wired control path. Importantly, the firmware uses the W5100S's Hardware TCP/IP Offload Engine (TOE) via the ioLibrary Driver, rather than relying on the ESP32’s lwIP stack for wired connections. It handles Modbus TCP polling and hosts a local TCP server for LAN-side access.

Q: What are the primary features available to operators and general users? 

A: Operators interact with this firmware as a deployable product. Key features include:

A local browser-based Web UI for configuration and onboarding.

A local W5100S-based TCP server for reading/writing internal tag values.

A rescue SoftAP mode for Wi-Fi recovery.

MQTT integration for northbound data telemetry, remote configuration, and Over-The-Air (OTA) updates.

Q: Is this project just a wrapper for Espressif’s standard ESP-Modbus stack? 

A: No. For developers, this is a custom ESP-IDF gateway stack with its own transport split and polling engine. It features a distinct three-layer architecture (BSP, Middleware, Application) and includes a custom gateway lifecycle orchestration that handles soft-PLC logic, SNTP, web configuration, and MQTT up-links.

Q: Is this firmware compatible with Single Pair Ethernet (SPE)? 

A: Currently, the hardware uses standard 10/100 Ethernet via the W5100S, not native SPE. However, the system architecture is highly suited for SPE migration. Because the gateway already relies on IP-oriented services (Modbus TCP, MQTT, HTTP, OTA) for OSI Layers 2–7, it is perfectly positioned to adopt an SPE physical layer for frontier industrial and building automation markets.

Q: What are the ideal target markets or use cases for this firmware? 

A: Based on its feature set, this firmware fits perfectly into:

Small OEM industrial gateway products.

Brownfield retrofit data concentrators.

Building, utility, and energy monitoring edge nodes.

Lightweight local automation or Soft-PLC gateway boxes.

Q: What are the current limitations of the project? 

A: While the engineering value is high, the project's public presentation is currently weak (e.g., an almost empty README file), which limits discoverability. Furthermore, the codebase still contains some development-style defaults (like built-in Wi-Fi bootstrap values and static IP settings) that would require hardening before commercial field deployment.

13. References

• Repository front-page state and README.
• Gateway lifecycle and subsystem startup.
• Multi-transport Modbus polling engine.
• W5100S BSP initialization and ioLibrary integration.
• Wi-Fi rescue AP and smart handoff logic.
• MQTT, remote config, and OTA path.
• ESP-IDF component manifest.
• Web configuration and OTA interface.
• WIZnet ioLibrary configuration header embedded in the repository.
• W5100S-based local TCP server.
• WIZnet official W5100S documentation. (WIZnet Document System)
• Espressif official ESP-Modbus documentation. (Espressif Systems)
• SPE and industrial Ethernet references. (마이크로칩)