Wiznet makers

PROJECT DESCRIPTION

esp32-opcua-gateway-rust is an open-source firmware project that explores how an ESP32-S3-based board can be used as a compact industrial IoT gateway. The project targets the Waveshare ESP32-S3-ETH board, which includes an ESP32-S3 MCU and an onboard WIZnet W5500 wired Ethernet chip. The board also provides an RJ45 Ethernet port, PoE module header, TF card slot, and camera interface, making it suitable for edge gateway and industrial IoT experiments.

The firmware is written in Rust on top of ESP-IDF. On first boot, the device uses AWS IoT Fleet Provisioning by Claim to obtain a unique X.509 identity, stores the device identity in NVS, and then connects to AWS IoT Core with its own certificate. For networking, the firmware tries wired Ethernet through the W5500 first and falls back to Wi-Fi if Ethernet link or DHCP is not available.

This project is valuable from a WIZnet perspective because it shows how the W5500 can be used not only for simple Ethernet connectivity, but also as part of a more advanced industrial IoT gateway architecture with secure provisioning, cloud MQTT communication, and remote firmware update capability.

KEY FEATURES

WIZnet W5500 Wired Ethernet

The project uses the WIZnet W5500 Ethernet chip as the primary network interface. The W5500 is connected to the ESP32-S3 through SPI and provides stable wired Ethernet connectivity through the RJ45 port on the Waveshare ESP32-S3-ETH board.

This is especially useful for industrial environments where Wi-Fi may be affected by interference, distance, metal structures, or unstable signal conditions.

Ethernet-first Network Design

The firmware attempts to initialize the W5500 Ethernet interface first. It brings up Ethernet using ESP-IDF’s esp_eth driver, waits for link and DHCP, and uses Ethernet as the main network interface when available.

Wi-Fi Fallback

If Ethernet link or DHCP is not available, the firmware falls back to Wi-Fi. This creates a hybrid network structure where wired Ethernet is used as the preferred connection and Wi-Fi is used as a backup option.

AWS IoT Zero-Touch Provisioning

The project supports AWS IoT Fleet Provisioning by Claim. During the first boot, the device connects using a claim certificate, requests a unique device certificate and private key, registers itself as an AWS IoT Thing, and stores the identity for later use.

MQTT-based Cloud Connection

After provisioning, the device connects to AWS IoT Core using its own device certificate. The firmware then keeps the MQTT connection open and can be extended to publish telemetry or receive cloud-side commands.

OTA Firmware Update

The firmware includes an OTA update structure using AWS IoT Jobs. When a firmware update job is received, the device can download a new firmware image from an HTTP or HTTPS URL and write it to the OTA partition.

Rust-based Embedded Firmware

The project is implemented in Rust using ESP-IDF. Rust is useful for embedded IoT development because it can help reduce memory safety issues while still allowing access to existing ESP-IDF networking, TLS, MQTT, and OTA features.

SYSTEM ARCHITECTURE

The system is composed of the following major parts.

1. ESP32-S3-ETH Device

The edge device is based on the Waveshare ESP32-S3-ETH board. The board includes an ESP32-S3R8 MCU, WIZnet W5500 Ethernet chip, RJ45 Ethernet port, PoE module header, TF card slot, and camera interface.

In this project, the Ethernet interface is the main hardware feature used by the firmware. The README notes that only the Ethernet chip is wired up so far, while the TF card slot, PoE module header, and camera interface are present on the board but not yet used by the current firmware.

2. WIZnet W5500 Ethernet Interface

The W5500 is connected to the ESP32-S3 through SPI. The project hardware documentation defines the W5500 SPI pin mapping as follows:

The firmware initializes the W5500 using ESP-IDF’s internal esp_eth SPI driver as an lwIP network interface. The code also notes that the implementation switched from a pure-Rust w5500-ll approach to esp_eth for TCP/IP and TLS support.

3. Network Layer

The device follows an Ethernet-first design.

At boot, the firmware starts the W5500 Ethernet interface and waits for Ethernet link and DHCP. If Ethernet becomes ready, the device uses W5500 Ethernet as the active network connection. If Ethernet is not available within the timeout, the firmware keeps the Ethernet handle alive and falls back to Wi-Fi.

This structure makes the device suitable for environments where Ethernet is preferred, while still allowing Wi-Fi operation when wired infrastructure is not available.

4. Device Identity and Provisioning

For secure cloud connection, the device uses AWS IoT Fleet Provisioning by Claim.

The provisioning flow works as follows:

1. The device connects to AWS IoT Core using a claim certificate.
2. It requests a unique device certificate and private key.
3. It sends a RegisterThing request with device parameters such as MAC address and secret.
4. A provisioning template and validation process approve the device.
5. The device stores the new certificate, private key, and Thing name in NVS. 

On later boots, the device checks whether a registered device identity already exists in NVS. If it exists, the device skips provisioning and connects directly with its stored identity.

5. AWS IoT Core and MQTT

After provisioning, the device connects to AWS IoT Core with its own certificate. The firmware uses the AWS IoT Thing name as the MQTT client ID and keeps the connection open.

The current firmware is mostly in connection/listening mode, but this structure can be extended to send sensor data, equipment status, gateway health information, or industrial telemetry to AWS IoT Core.

6. OTA Update System

The firmware subscribes to AWS IoT Jobs topics. When an update job is received, the device requests job details, checks whether the job operation is firmware_update, and then downloads the firmware from the provided URL.

The OTA module downloads the firmware using HTTP/HTTPS, writes it to the OTA partition, completes the update, and prepares the device for reboot.

HOW IT WORKS

The overall operation flow is as follows:

ESP32-S3-ETH Device → W5500 Ethernet / Wi-Fi → AWS IoT Provisioning → Device Certificate → MQTT Connection → AWS IoT Jobs / OTA

When the device boots, it first initializes the W5500 Ethernet interface. If the Ethernet cable is connected and DHCP succeeds, the device uses Ethernet as the primary network path. If Ethernet is unavailable, the device switches to Wi-Fi fallback.

After the network is ready, the firmware checks NVS to determine whether the device already has a registered identity. If no identity exists, the device starts AWS IoT Fleet Provisioning. It connects with the claim certificate, requests a unique certificate and private key, registers itself as a Thing, and stores the resulting credentials in NVS.

Once the device identity is available, the firmware connects to AWS IoT Core through MQTT using mutual TLS. From this point, the device can maintain a secure cloud connection and listen for AWS IoT Jobs. If an OTA update job is received, the device downloads the new firmware image and updates itself remotely.

This makes the project more than a simple Ethernet example. It demonstrates a practical device lifecycle flow for industrial IoT products: network connection, secure provisioning, cloud registration, MQTT operation, and remote update.

ROLE OF WIZNET W5500

In this project, the WIZnet W5500 provides the main wired Ethernet interface for the ESP32-S3 gateway.

Many ESP32-based IoT projects rely only on Wi-Fi, but industrial installations often require more stable and predictable communication. Ethernet is usually preferred for fixed equipment, factory devices, energy systems, and gateway products because it is less affected by wireless interference and signal quality issues.

The W5500 is a hardwired Internet controller with an integrated TCP/IP stack, SPI interface, 10/100 Ethernet MAC and PHY, 8 sockets, and internal memory for TX/RX buffers.

However, in this specific project, it is better to describe the W5500 usage carefully. The firmware uses W5500 through ESP-IDF’s esp_eth driver and lwIP network interface, rather than directly using WIZnet’s socket-level API. The source code also states that the implementation uses esp_eth for TCP/IP and TLS support.

Therefore, the most accurate description is:

W5500 is used as a stable wired Ethernet interface for an ESP32-S3-based industrial IoT gateway.

The project is still valuable because it shows how W5500 Ethernet can be combined with ESP32-S3 Wi-Fi, Rust firmware, AWS IoT provisioning, MQTT, and OTA updates in one embedded gateway architecture.

HYBRID NETWORK DESIGN

This project can be described as a hybrid network gateway because it combines wired Ethernet and Wi-Fi in the same firmware.

The device prioritizes W5500 Ethernet for stable operation. If the wired connection is not available, it falls back to Wi-Fi. This design is useful in real deployment scenarios because the same firmware can support different installation environments.

For example, an industrial site may use Ethernet for permanent installation, while a development site, demo setup, or temporary field test may use Wi-Fi. By supporting both, the gateway becomes more flexible without changing the core firmware.

INDUSTRIAL IOT GATEWAY POTENTIAL

Although the current implementation does not yet provide a complete OPC UA data conversion layer, it already includes several important building blocks for an industrial IoT gateway.

The project could be extended in the future to support OPC UA client functionality. In that case, the ESP32-S3 gateway could collect data from PLCs, HMIs, SCADA systems, or industrial controllers and forward that data to AWS IoT Core using MQTT.

It could also be extended to support other industrial protocols or local device interfaces, such as Modbus TCP, Modbus RTU, serial sensors, machine status inputs, or environmental monitoring devices.

Because the board also includes a PoE module header, the system could potentially be developed into a field-installed Ethernet gateway where power and data are supplied through a single Ethernet cable.

POSSIBLE APPLICATIONS

This project can be used as a reference for the following applications:

• Industrial IoT gateway development
• Smart factory equipment monitoring
• PLC or machine data collection
• OPC UA-to-cloud gateway experiments
• AWS IoT connected edge devices
• Ethernet-first ESP32-S3 gateway products
• Remote equipment monitoring
• Energy management systems
• Predictive maintenance data logging
• Secure device provisioning PoC
• OTA-enabled field device development
• Rust-based embedded IoT firmware research
• Hybrid Ethernet and Wi-Fi gateway design